ads:
1
RONI QUEIROZ DIAS
ADOÇÃO DAS PRÁTICAS DE TESTES DO MODELO CMMI NA
MELHORIA DA QUALIDADE DOS PRODUTOS E SERVIÇOS DE
TESTES DE SOFTWARE EM INSTITUIÇÕES FINANCEIRAS
Dissertação apresentada ao Curso de Mestrado em
Sistemas de Gestão, da Universidade Federal
Fluminense, como requisito parcial para obtenção do
Grau de Mestre em Sistemas de Gestão.
Área de Concentração: Gestão pela Qualidade Total
Orientador: Prof. Heitor Luiz Murat de Meirelles Quintella D.Sc.
Niterói
2005
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
2
RONI QUEIROZ DIAS
ADOÇÃO DAS PRÁTICAS DE TESTES DO MODELO CMMI NA
MELHORIA DA QUALIDADE DOS PRODUTOS E SERVIÇOS DE
TESTES DE SOFTWARE EM INSTITUIÇÕES FINANCEIRAS
Dissertação apresentada ao Curso de Mestrado em
Sistemas de Gestão, da Universidade Federal
Fluminense, como requisito parcial para obtenção do
Grau de Mestre em Sistemas de Gestão. Área de
Concentração: Gestão pela Qualidade Total
Aprovada em: de Outubro de 2005.
BANCA EXAMINADORA
Prof. Heitor Luiz Murat de Meirelles Quintella D.Sc.
Universidade Federal Fluminense
Profº Anníbal Parracho Sant'anna D.Sc.
Universidade Federal Fluminense
Profº Arndt von Staa Ph.D.
Pontifícia Universidade Católica do Rio de Janeiro
Niterói
2005
ads:
3
Dedico este trabalho
À minha esposa pela compreensão durante a elaboração do mesmo e pelo apoio sempre
recebido.
4
AGRADECIMENTOS
À Deus pela minha vida e pelos dons que me concedeu.
Ao meu orientador Prof. Heitor Quintella pelo apoio, pela confiança depositada, pelas
sugestões e pelo profissionalismo na orientação desta dissertação.
À Aline pela paciência, incentivo, compreensão e principalmente pelo amor em todos os
momentos desta nossa jornada.
À minha família, em especial aos meus pais Joscelino e Dulce e meus irmãos pelo
constante apoio e confiança que foram fundamentais para realização dos meus sonhos e
que souberem compreender minha ausência.
Ao meu amigo e tio Cleber, por me acompanhar e incentivar neste desafio.
Aos colegas do grupo de pesquisa Fatores Humanos e Tecnológicos da Competitividade,
pela troca de experiências e informações que tanto contribuíram para realização deste
trabalho.
5
“O homem pode tanto quanto sabe.”
(Francis Bacon)
6
RESUMO
Este estudo busca identificar os impactos na qualidade dos produtos e serviços de testes de
software com a adoção das práticas baseadas nas áreas de processo de Verificação e
Validação do modelo CMMI (Capability Maturity Model Integration) em instituições
financeiras. Dentro deste contexto, esta pesquisa buscou identificar por meio de uma amostra
de 40 produtos que foram testados por um fornecedor o nível de aderência a estas práticas.
Após esta análise, verificou-se juntos aos clientes por meio de questionários dos modelos de
avaliação de qualidade de software ISO/IEC 9126 e qualidade de serviços SERVQUAL seus
respectivos impactos. Os referenciais teóricos utilizados são Testes de Software, ISO/IEC
9126, o CMMI (Capability Maturity Model Integration) do SEI (Software Engineering
Institute), da Carnegie Mellon University e (SERVQUAL) de Valerie A. Zeithaml, A.
Parasuraman e Leonard L. Berry.
Palavras-chave: Testes de Software, CMMI, ISO/IEC 9126, SERVQUAL
7
ABSTRACT
This research intends to identify the impacts of product quality and software testing services
with the use of practices based in process areas of Verification and Validation of the model
CMMI(Capability Maturity Model Integration) in banking organizations. Inside this context,
such research has searched for indentifing through 40 products that were tested by a supplier
the level of tack to such practices. After this analise, it was noticed together with the client
using questionnaires of the avaliation models of software quality ISO/IEC 9126 and service
quality SERVQUAL and its respectively impacts in quality. The theorical references used are
Software Testing, ISO/IEC 9126, the CMMI (Capability Maturity Model Integration) of SEI
(Software Engineering Institute), of the Carnegie Mellon University and (SERVQUAL) from
Valerie A. Zeithaml, A. Parasuraman and Leonard L. Berry.
Key-words: Software Testing, CMMI, ISO/IEC 9126, SERVQUAL
8
LISTA DE FIGURAS
Figura 1 - Estrutura lógica da dissertação.............................................................................21
Figura 2 - Localização da pesquisa.......................................................................................26
Figura 3 - Contexto dos referenciais teóricos........................................................................35
Figura 4 - Atividades do processo de teste............................................................................ 36
Figura 5 - Documentação do processo de testes segundo a norma IEEE 829......................... 44
Figura 6 – Modelo em V de Testes de Software ...................................................................45
Figura 6 - Processo de software............................................................................................48
Figura 7 - Representação do CMMI como integrador dos diversos CMMs........................... 52
Figura 8 - Níveis de maturidade na representação contínua ..................................................54
Figura 9 - Níveis de maturidade na representação em estágios..............................................55
Figura 10 - Componentes do modelo CMMI.......................................................................56
Figura 11 - Avaliação do cliente sobre a Qualidade do Serviço. ...........................................69
Figura 12 - Modelo conceitual da Qualidade do Serviço.......................................................73
Figura 13 - Modelo do processo para a medição e aperfeiçoamento contínuos da Qualidade do
Serviço......................................................................................................................... 78
Figura 14 - Modelo ampliado das discrepâncias na Qualidade do Serviço. ........................... 79
Figura 15 - Estrutura da série de normas ISO/IEC 9126 .......................................................88
Figura 16 - Modelo de qualidade interna e externa segundo a ISO/IEC 9126- 1....................89
Figura 17 - Modelo de qualidade em uso segundo a ISO/IEC 9126- 1..................................94
Figura 18 - Relação entre níveis, tipos e técnicas de teste..................................................... 96
Figura 19 - Processo de teste e seu relacionamento com o processo de desenvolvimento......99
Figura 26 - Visão geral do modelo TPI............................................................................... 117
Figura 27 - Comparação entre CMM – Nível 2 & PMBOK................................................ 146
Figura 28 - Método hipotético dedutivo segundo Popper.................................................... 178
Figura 29 - Esquema do método adaptado para a pesquisa.................................................. 179
9
LISTA DE TABELAS
Tabela 1 - Custos de desenvolvimento de testes para uma empresa de 10.000 funcionários. .22
Tabela 2 - Métodos utilizados para detecção de defeitos no Brasil........................................23
Tabela 3 - Integração dos processos de desenvolvimento e teste...........................................47
Tabela 4 - Quadro de correspondência entre as dimensões do SERVQUAL e os dez critérios
iniciais de avaliação da Qualidade do Serviço ......................................................................71
Tabela 5 - Declarações para cada uma das dimensões de avaliação da Qualidade do Serviço 81
Tabela 6 - Importância das dimensões SERVQUAL em quatro setores de serviços ..............82
Tabela 7 - Comparação das expectativas dos clientes com as percepções dessas expectativas
pelo pessoal de direção.........................................................................................................85
Tabela 8 - Dados sobre os projetos realizados – primeira parte........................................... 102
Tabela 9 - Indicadores de projeto usados na análise de teste............................................... 104
Tabela 12 - Indicadores de melhoria do CMM.................................................................... 115
Tabela 13 - Matriz de maturidade de teste.......................................................................... 124
Tabela 14 - Sumário de benefícios e impactos: RETORNO SOBRE INVESTIMENTOS... 148
Tabela 15 - Sumário de benefícios e impactos: PRAZOS................................................... 148
Tabela 16 - Sumário de benefícios e impactos: CUSTO ..................................................... 149
Tabela 17 - Sumário de benefícios e impactos: SATISFAÇÃO DE CLIENTES................. 150
Tabela 18 - Sumário de benefícios e impactos: QUALIDADE ........................................... 150
Tabela 19 - Características de qualidade x tarefas............................................................... 165
Tabela 20 - Definição de requisitos de qualidade................................................................ 168
Tabela 21 - Definição dos níveis de pontuação................................................................... 169
Tabela 22 - Definição dos graus de qualidade..................................................................... 170
Tabela 23 - Usuários que responderam questionário........................................................... 170
Tabela 24 - Pontuação de cada resposta de cada usuário..................................................... 171
Tabela 25 - Pontuação das características da Norma ISO/IEC 9126 por usuário ................. 172
Tabela 26 - Julgamento do grau de qualidade do software por características da Norma
ISO/IEC 9126.................................................................................................................... 172
Tabela 28 - Escores médios das sub-características ordenados pelo valor t – ISO/IEC 9126.
.......................................................................................................................................... 194
Tabela 29 - Análise global dos aspectos do modelo SERVQUAL ......................................200
Tabela 30 - Escores médios das questões ordenadas pelo valor t - SERVQUAL................. 201
10
LISTA DE QUADROS
Quadro 1 - Justificativa da Questão para Teste da Hipótese.................................................. 34
Quadro 2 - Áreas de Processo por Nível de Maturidade........................................................ 61
Quadro 3 - Características da Área de Processo Verificação.................................................65
Quadro 4 - Características da Área de Processo Validação ................................................... 66
Quadro 5 - Áreas Chaves do Modelo TPI........................................................................... 119
Quadro 6 - Níveis de Maturidade de Áreas Chaves do Modelo TPI....................................122
Quadro 7 - Fatores de Influência para Adoção do Modelo CMM........................................129
Quadro 8 - Relacionamento entre os Modelos CMM SW v1.1 e SPICE v1.0...................... 132
Quadro 9 - Comparação entre as Atividades do Ciclo de Vida e os Modelos ...................... 133
Quadro 10 - Como o PSP e o TSP Abrangem as Áreas-chave do Processo do CMM.......... 133
Quadro 11 - Processos a Serem Implementados em Cada Ciclo de Melhoria...................... 135
Quadro 12 - Visão Geral do Mapeamento entre uma Cláusula da ISO 9001 e Áreas de
Processo e Práticas-Chave do CMM................................................................................... 143
Quadro 13 - Similaridades e diferenças.............................................................................. 151
Quadro 14 - Resultado da Pesquisa SERVQUAL em Informática ...................................... 157
Quadro 15 - Tabulação Geral dos "Gaps" pelas Dimensões................................................ 158
Quadro 16 - Comparação de visão entre Gerentes/Supervisores e Usuários pelas Dimensões.
.......................................................................................................................................... 159
Quadro 20 - Cálculo do percentual relativo de qualidade.................................................... 169
Quadro 22 - Relacionamento de hipóteses com suas respectivas questões-chave ................ 187
11
LISTA DE GRÁFICOS
Gráfico 1 - Regra 10 de Myers ............................................................................................47
Gráfico 2 - Importância relativa das dimensões SERVQUAL quando os usuários utilizaram
uma escala de 100 pontos.....................................................................................................84
Gráfico 3 - Média das pontuações de SERVQUAL em função das dimensões sobre o serviço
(n=1.936)............................................................................................................................. 85
Gráfico 4 - Resultado do julgamento do grau de qualidade do software por características.172
Gráfico 5 - Escore médio da característica Funcionalidade................................................. 195
Gráfico 6 - Escore médio da característica Confiabilidade.................................................. 195
Gráfico 7 - Escore médio da característica Usabilidade ...................................................... 196
Gráfico 8 - Escore médio da característica Eficiência......................................................... 196
Gráfico 9 - Escore médio da característica Manutenibilidade.............................................. 197
Gráfico 10 - Escore médio da característica Portabilidade .................................................. 197
Gráfico 11 - Escore médio do aspecto Elementos Tangíveis............................................... 202
Gráfico 12 - Escore médio do aspecto Confiabilidade ........................................................ 202
Gráfico 13 - Escore médio do aspecto Capacidade de Resposta.......................................... 203
Gráfico 14 - Escore médio do aspecto Segurança ............................................................... 204
Gráfico 15 - Escore médio do aspecto Empatia ..................................................................204
Gráfico 16 – Distribuição dos Projetos – Avaliação CMMI................................................ 205
12
LISTAS DE ABREVIATURAS
CMM - Capability Maturity Model
CMMI - Capability Maturity Model Integration
GG - Generic Goals
GP - Generic Practices
IPD-CMM - Integrated Product Development Capability Maturity Model
ISM - Integrated Software Management
ISO - International Organization of Standardization
KPA - Key Process Area
ML - Maturity level
OPD - Organization Process Definition
OPF - Organization Process Focus
P&D - Pesquisa e Desenvolvimento
PA - Process Area
PCM - Process Change Management
PLC - Product Life Cycle
PMBOK - Project Management Body of Knowledge
PMI - Project Management Institute
PR - Peer Reviews
PSP - Personal Software Process
RM - Requirements Management
SCM - Software Configuration Management
SEI - Software Engineering Institute
SG - Specific Goals
SP - Specific Practices
SPE - Software Product Engineering
SPICE -
Software Process Improvement and Capability Determination
SPP - Software Project Planning
SQA - Software Quality Assurance
SSM - Software Subcontract Management
TCM - Technology Change Management
TI - Tecnologia da Informação
TP - Training Program
TPI - Test Process Improvement
TSP - Team Software Process
13
SUMÁRIO
1 INTRODUÇÃO..................................................................................................19
1.1 ESTRUTURA LÓGICA ......................................................................................21
1.2 FORMULAÇÃO DA SITUAÇÃO PROBLEMA.................................................22
1.3 QUESTÃO DA PESQUISA.................................................................................25
1.4 OBJETIVOS DO ESTUDO.................................................................................25
1.5 JUSTIFICATIVAS.............................................................................................. 26
1.6 HIPÓTESES E/OU QUESTÕES..........................................................................30
1.6.1 Hipótese I............................................................................................................30
1.6.2 Hipótese II..........................................................................................................30
2 REFERENCIAL TEÓRICO .............................................................................35
2.1 TESTES DE SOFTWARE...................................................................................36
2.1.1 Introdução..........................................................................................................36
2.1.2 Objetivos do Teste..............................................................................................39
2.1.3 Técnica de Testes Estáticas e Dinâmicas...........................................................39
2.1.4 Tipos de Teste.....................................................................................................40
2.1.5 Documentação de Testes....................................................................................42
2.1.6 Integração dos Processos de Desenvolvimento e Teste .....................................44
2.1.7 Importância do Processo de Testes....................................................................47
2.2. CMMI..................................................................................................................48
2.2.1 Processo de Software.......................................................................................... 48
2.2.2 O Modelo CMM/CMMI ....................................................................................49
2.2.3 Áreas de Conhecimento .....................................................................................52
2.2.4 Formas de Representação..................................................................................53
2.2.4.1 Representação Contínua.......................................................................................53
2.2.4.2 Representação em Estágios ..................................................................................54
2.2.5 Componentes e Estrutura do Modelo................................................................55
2.2.5.1 Níveis de Maturidade...........................................................................................56
2.2.5.1.1 Nível de Maturidade 1: Inicial .............................................................................57
2.2.5.1.2 Nível de Maturidade 2: Gerenciado .....................................................................57
2.2.5.1.3 Nível de Maturidade 3: Definido..........................................................................58
2.2.5.1.4 Nível de Maturidade 4: Quantitativamente Gerenciado........................................59
2.2.5.1.5 Nível de Maturidade 5: Em Otimização................................................................ 60
14
2.2.5.2 Áreas de Processo por Nível de Maturidade ......................................................... 61
2.2.5.3 Componentes Requeridos..................................................................................... 61
2.2.5.3.1 Metas Genéricas (GG)......................................................................................... 62
2.2.5.3.2 Metas Específicas (SG) ........................................................................................ 63
2.2.6 Áreas de Processo Relacionadas a Testes.......................................................... 63
2.2.6.1 Verificação ..........................................................................................................63
2.2.6.2 Validação............................................................................................................. 65
2.3 QUALIDADE EM SERVIÇOS - PESQUISA PARASURAMAN ET AL............67
2.3.1 O Consumidor e a Qualidade do Serviço..........................................................68
2.3.2 Definição de Qualidade do Serviço....................................................................69
2.3.3 Fatores que influenciam as expectativas...........................................................69
2.3.4 Dimensões da Qualidade do Serviço..................................................................70
2.3.5 Modelo Conceitual da Qualidade do Serviço....................................................72
2.3.6 SERVQUAL: Um Instrumento para Medir a Qualidade do Serviço ..............77
2.3.6.1 Desenvolvimento do SERVQUAL.......................................................................80
2.3.6.2 Resultados da aplicação do SERVQUAL .............................................................81
2.3.6.3 Validação do SERVQUAL...................................................................................85
2.4 NORMA ISO/IEC 9126 (ISO, 2001)....................................................................87
2.4.1 ISO/IEC 9126 .....................................................................................................87
2.4.2 ISO/IEC 9126-1..................................................................................................88
2.4.1.1 Modelo de qualidade para qualidade externa e interna.......................................... 89
2.4.1.2 Modelo de qualidade para qualidade em uso ........................................................ 93
3 REVISÃO DE LITERATURA..........................................................................95
3.1 TESTES DE SOFTWARE...................................................................................95
3.1.1 Uma Metodologia para Teste de Software no Contexto da Melhoria de
Processo (Crespo et al., 2003) ...........................................................................95
3.1.1.1 Objetivo do trabalho............................................................................................. 95
3.1.1.2 Resultados do Estudo........................................................................................... 95
3.1.1.3 Relação com a Presente Pesquisa .......................................................................102
3.1.2 Melhoria da Qualidade de Produto e de Processo de Software a partir da
Análise de Indicadores de Teste (NITA , 2003)............................................... 102
3.1.2.1 Objetivo do trabalho........................................................................................... 102
3.1.2.2 Resultados do Estudo......................................................................................... 103
3.1.2.3 Relação com a Presente Pesquisa .......................................................................105
15
3.1.3 Teste em Ambiente Cliente-Servidor: Uma Estratégia e um Estudo de Caso
(VOLPI, VIRGILIO, 2002).............................................................................. 105
3.1.3.1 Objetivo do trabalho........................................................................................... 105
3.1.3.2 Resultados do Estudo......................................................................................... 105
3.1.3.3 Relação com a Presente Pesquisa ....................................................................... 107
3.1.4 Erros de Teste Clássicos (MARICK, 1997)..................................................... 107
3.1.4.1 Objetivo do trabalho........................................................................................... 107
3.1.4.2 Resultados do Estudo......................................................................................... 107
3.1.4.3 Relação com a Presente Pesquisa ....................................................................... 115
3.1.5 Introdução a Melhoria do Processo de Testes e o Impacto na Organização
(WOODRUFF, 2003) ....................................................................................... 115
3.1.5.1 Objetivo do trabalho........................................................................................... 115
3.1.5.2 Resultado do Estudo........................................................................................... 115
3.1.5.3 Relação com a presente pesquisa....................................................................... 116
3.1.6 Melhoria do Processo de Teste (POL e TEUNISSEN 2003)........................... 116
3.1.6.1 Objetivo do trabalho........................................................................................... 116
3.1.6.2 Resultado do estudo........................................................................................... 116
3.1.6.3 Relação com a Presente Pesquisa .......................................................................125
3.2 CMMI................................................................................................................ 126
3.2.1 Implantação do Modelo CMM de Qualidade de Software no Brasil: Estudos de
Caso (Costa, 2000)............................................................................................ 126
3.2.1.1 Objetivo do trabalho........................................................................................... 126
3.2.1.2 Resultado do estudo........................................................................................... 126
3.2.1.3 Relação com a presente pesquisa....................................................................... 129
3.2.2 Os Efeitos da Maturidade do Processo no Esforço de Desenvolvimento de
Software (CLARK, 1997)................................................................................. 130
3.2.2.1 Objetivo do trabalho: ......................................................................................... 130
3.2.2.2 Resultados do estudo:......................................................................................... 130
3.2.2.3 Relação com a presente pesquisa........................................................................ 130
3.2.3 Integrando CMM com Outros Modelos de Qualidade (MELHORETO, 1999)
.......................................................................................................................... 130
3.2.3.1 Objetivo do trabalho........................................................................................... 130
3.2.3.2 Resultados do trabalho ....................................................................................... 131
3.2.3.3 Relação com a Presente Pesquisa .......................................................................135
16
3.2.4 Comparação entre ISO 9001 x CMM (PAULK, 1994)...................................136
3.2.4.1 Objetivo do estudo............................................................................................. 136
3.2.4.2 Resultado do Trabalho ....................................................................................... 136
3.2.4.3 Relação com a Presente Pesquisa .......................................................................144
3.2.5 PMBOK & CMM + CMMI (SOTILLE, 2003)............................................... 144
3.2.5.1 Objetivo do estudo............................................................................................. 144
3.2.5.2 Resultados do estudo.......................................................................................... 144
3.2.5.3 Relação com a presente pesquisa........................................................................ 147
3.2.6 Demonstrando o Impacto e Benefícios do CMMI: uma Atualização e
Resultados Preliminares (GOLDENSON & GIBSON, 2003)......................... 147
3.2.6.1 Objetivo do trabalho........................................................................................... 147
3.2.6.2 Resultado do estudo........................................................................................... 148
3.2.6.3 Relação com a presente pesquisa........................................................................ 151
3.2.7 Explorando o CMMI e ISO 9001:2000. Sinergia no Desenvolvimento de uma
Estratégia de Melhoria de Processos (MUTAFELIJA, 2003). ....................... 151
3.2.7.1 Objetivo do trabalho........................................................................................... 151
3.2.7.2 Resultado do estudo........................................................................................... 151
3.2.7.3 Relação com a presente pesquisa........................................................................ 153
3.2.8 CMM e Qualidade: Estudo de Caso DATAPREV (OSÓRIO, 2003)............. 153
3.2.8.1 Objetivo do trabalho........................................................................................... 153
3.3.8.2 Tratamento dos dados. ....................................................................................... 154
3.2.8.3 Resultado do estudo........................................................................................... 154
3.2.8.4 Relação com a presente pesquisa....................................................................... 154
3.3 QUALIDADE EM SERVIÇOS (SERVQUAL) ................................................. 155
3.3.1 Qualidade dos Serviços na Área de Informática - Um modelo para Avaliação
(MORGADO, WATSON, 2004)...................................................................... 155
3.3.1.1 Objetivo do trabalho........................................................................................... 155
3.3.1.2 Resultado do estudo........................................................................................... 155
3.3.1.3 Relação com a presente pesquisa....................................................................... 159
3.3.2 Qualidade em Serviços Liderança Gerencial nas Empresas de Informática
(ALVARADO, 2001)........................................................................................ 159
3.3.2.1 Objetivos do Estudo........................................................................................... 159
3.3.2.2 Referencial Teórico Empregado......................................................................... 160
3.3.2.3 Tratamento do Dados......................................................................................... 160
17
3.3.2.4 Resultados do Estudo......................................................................................... 161
3.3.2.5 Relação com a Presente Pesquisa .......................................................................161
3.3.3 Qualidade em Serviços e Liderança: Avaliação dos Serviços Internos de
Informática em uma Grande Empresa. (CRISÓSTOMOS, 2002)................. 161
3.3.3.1 Objetivo do Estudo ............................................................................................ 162
3.3.3.2 Metodologia Aplicada no Estudo ....................................................................... 162
3.3.3.3 Resultados do Estudo......................................................................................... 163
3.3.3.4 Relação com a Presente Pesquisa .......................................................................163
3.4 ISO/IEC 9126 .................................................................................................... 164
3.4.1 Aplicando o Modelo ISO/IEC 9126 para Avaliação de Sistema E-Learning
(Chua, Dyson, 2004)....................................................................................... 164
3.4.1.1 Objetivo do trabalho........................................................................................... 164
3.4.1.2 Metodologia Aplicada no Estudo ....................................................................... 164
3.4.1.3 Resultado do estudo........................................................................................... 165
3.4.1.4 Relação com a presente pesquisa....................................................................... 167
3.4.2 Análise da Qualidade de Software de Gestão Empresarial utilizando a Norma
ISO/IEC 9126 (SCARTON e NAU, 2002) ..................................................... 167
3.4.2.1 Objetivo do trabalho........................................................................................... 167
3.4.2.2 Metodologia Aplicada no Estudo ....................................................................... 168
3.4.2.3 Resultado do estudo........................................................................................... 172
3.4.2.4 Relação com a presente pesquisa........................................................................ 174
4.1 TIPO DE PESQUISA ........................................................................................ 175
4.2 MÉTODO DE ABORDAGEM.......................................................................... 176
4.3 PROCEDIMENTOS E TÉCNICAS...................................................................176
4.4 ANÁLISE DAS HIPÓTESES............................................................................ 180
4.4.1 Tipologia........................................................................................................... 180
4.4.2 Fundamentação................................................................................................ 180
4.5 VALIDAÇÃO DAS HIPÓTESES...................................................................... 181
4.5.1 Teste de Importância ....................................................................................... 181
4.5.2 Teste de Necessidade........................................................................................ 181
4.6 EMPRESAS ALVO DE PESQUISA ................................................................. 182
4.7 INSTRUMENTOS DE MEDIDA UTILIZADOS .............................................. 184
4.8 COLETA DE DADOS....................................................................................... 184
4.9 TRATAMENTO E ANÁLISE DE DADOS....................................................... 185
18
4.10 LIMITAÇÕES DO MÉTODO........................................................................... 188
5 ANÁLISE E DISCUSSÃO DOS RESULTADOS........................................... 189
5.1 TESTE DA HIPÓTESE ..................................................................................... 189
5.2 MÉTODO ESTATÍSTICO................................................................................. 189
5.3 ANÁLISE DOS RESULTADOS ....................................................................... 192
5.3.1 Resposta ao Objetivo 1..................................................................................... 192
5.3.2 Respostas ao Objetivo 2................................................................................... 199
5.3.3 Respostas ao Objetivo 3................................................................................... 205
6 CONCLUSÕES E RECOMENDAÇÕES ....................................................... 206
6.1 SOLUÇÃO DO PROBLEMA............................................................................ 206
6.2 VERIFICAÇÃO DAS HIPÓTESES...................................................................208
6.3 CONCLUSÕES.................................................................................................213
6.4 SUGESTÕES PARA FUTUROS ESTUDOS..................................................... 215
REFERÊNCIAS BIBLIOGRÁFICAS............................................................................ 216
GLOSSÁRIO ................................................................................................................... 223
APÊNDICES.................................................................................................................... 226
19
1 INTRODUÇÃO
Na sociedade moderna, os softwares passaram a ter um papel vital na condução e
execução dos negócios nas organizações, sendo em alguns casos parte intrínseca dos seus
negócios. Segundo Rooijmans (1996) a quantidade de software incorporado em produtos de
consumo duplica a cada 18 meses. Com a crescente demanda por novas tecnologias pelas
empresas e a sociedade em geral, esta importância tende a se multiplicar nos próximos anos.
Diante deste cenário, a confiabilidade dos softwares passa a ser um fator crucial para os
fabricantes junto aos seus clientes, que buscam fornecedores capazes de produzir softwares de
alta qualidade em prazos cada vez menores.
Atualmente, existe uma crescente preocupação das empresas de software com a
satisfação de seus clientes, com a produtividade de suas equipes e com os custos de seus
projetos. Segundo Martin&McClure (1983) 90% dos softwares liberados possuem erros
críticos. De acordo com o relatório “The Economic Impact of Inadequate Infraestrutre for
Software Testing” (NIST, 2002) estima-se que os custos com defeitos em softwares custem às
empresas americanas um valor próximo de 1% do PIB dos Estados Unidos.
A engenharia de software evoluiu significativamente nas últimas décadas procurando
estabelecer técnicas, critérios, métodos e ferramentas para a produção de software. O processo
de desenvolvimento de software envolve uma série de atividades nas quais, apesar de toda a
evolução nas ultimas décadas, erros nos produtos e na oferta de serviços ainda podem ocorrer.
Atividades ligadas à Garantia de Qualidade de Software têm sido introduzidas ao longo de
todo o processo de desenvolvimento, entre elas, atividades de teste, com o objetivo de
minimizar a ocorrência de erros e riscos associados.
O objetivo do processo de teste é encontrar erros na implementação de um software e
validar os requisitos definidos pelos usuários. Vale reafirmar que o processo de teste tem um
papel chave na qualidade do produto de software. Porém, em muitos casos, o
desenvolvimento e execução dos testes são feitos sem métodos estruturados. Além disso,
freqüentemente os testes são selecionados de forma aleatória e os casos de teste são
desenvolvidos de uma forma não estruturada e não sistemática. Esta é uma realidade
20
encontrada no desenvolvimento de softwares, onde há recursos limitados e tempo escasso
para o processo de teste.
A insuficiência dos testes é indicada por Caper Jones em “Patterns of Software System
Failure and Sucess” como um dos principais motivos de falha nos projetos de
desenvolvimento de software e, segundo o Gartner Group (1996), apenas 7% das aplicações
entregues atendem os requisitos de tempo de resposta e performance.
Diante deste cenário de incertezas e descrédito quanto à qualidade dos softwares,
usuários têm elevado cada vez mais o nível de exigências junto aos fabricantes, que em
contra-partida investem em programas de qualidade como forma de resolver problemas
relacionados aos custos de correção de erros e o efeito negativo de falhas na qualidade
percebida pelo cliente.
21
1.1 ESTRUTURA LÓGICA
A estrutura lógica da dissertação é apresentada na figura 1 a seguir, mostrando que os
capítulos 2 e 3 são os pilares técnicos para a discussão central – que ocorre no capítulo 5 – a
qual é concluída no capítulo 6.
Figura 1 - Estrutura lógica da dissertação
Fonte: Elaboração própria.
22
1.2 FORMULAÇÃO DA SITUAÇÃO PROBLEMA
O desenvolvimento de software com qualidade, dentro de prazos, custos e que satisfaça os
usuários exigem dos fabricantes a melhoria dos processos da engenharia de software.
Segundo dados de pesquisa realizada pelo Departamento de Comércio Americano mais de
60% das organizações reportaram grandes erros na utilização de softwares e 80% reportaram
pequenos erros. Aliado a este patamar de qualidade, cabe ressaltar que apenas 1,3% dos
projetos de softwares entregues avaliam a satisfação do cliente (ISBSG, 2003).
Os impactos nos custos pela inadequada infraestrutura de testes na industria de software foi
identificado por meio de estudo realizado nos Estados Unidos pelo Instituto Nacional de
Padrões e Tecnologia (NIST, 2002) conforme tabela 1 a seguir:
Tabela 1 - Custos de desenvolvimento de testes para uma empresa de 10.000 funcionários.
Fonte: Instituto Nacional de Padrões e Tecnologia – (NIST, 2002)
No Brasil, segundo dados do Ministério da Ciência e Tecnologia menos de 30% das
empresas de desenvolvedoras de software do país possuíam processos estruturados de
Custos Atuais de
Infraestrutura de Testes
Custos pela Infraestrutura
Inadequada de Testes
Potencial Redução de Custos com a
Melhoria da Infraestrutura de Testes
Testes de Software
$54.512.640,00
$20.884.777,00
$9.190.119,00
Número de Testadores
400
153
67
Taxa Valor/Hora
$67,60
$67,60
$67,60
Hardware para Testes
$40.000,00
$15.325,00
$6.743,00
Serviços Externos de Testes
$100.000,00
$38.312,00
$16.859,00
Custos de Serviços Pós-venda
$545.126,00 $208.848,00 $91.901,00
Total de Custos Anuais com Testes
$55.197.766,00
Redução Anual de Custos com Testes
$21.147.397,20
$9.305.622,00
Percentual de Redução Comparada a
Atual Infraestrutura
38,79% 17,07%
Percentual de Economia Sobre as
Vendas Anuais
1,80% 0,80%
CUSTOS DE DESENVOLVIMENTO DE TESTES PARA UMA EMPRESA DE 10.000 FUNCIONÁRIOS
23
planejamento e documentação de testes. Estes números indicam um baixo grau de maturidade
na área de testes conforme mostrado na tabela 2 a seguir.
Tabela 2 - Métodos utilizados para detecção de defeitos no Brasil.
Fonte: Pesquisa Qualidade e Produtividade no Setor de Software Brasileiro – MCT (2001)
Nos últimos anos abordagens e experiências para a melhoria do processo de software
baseadas em modelos têm sido utilizadas com sucesso pelos fabricantes, entre eles destacam-
se o CMMI, ISO12207 e ISO15504. Estes modelos identificam processos fundamentais para
a engenharia de software. Todos eles identificam de forma direta ou indiretamente, teste de
software com um destes processos. Teste é fundamental para a avaliação do software
desenvolvido. Entretanto, testar software não é uma atividade simples, e exige conhecimentos,
habilidades e infra-estrutura específica.
Até a década de 80, o processo de teste era executado no fim do ciclo de desenvolvimento,
normalmente pelos próprios desenvolvedores. O foco era avaliar se o software estava
funcionando e o objetivo era procurar erros. Não haviam ainda profissionais especializados na
atividade de testar aplicações e nem metodologias estruturadas de teste.
O fim da década de 80 marcou o surgimento dos grupos de garantia de qualidade na estrutura
da área de TI e mais recentemente os grupos de teste, quando a atividade de testar software
passou a fazer parte de um processo independente do processo de desenvolver software,
embora continuassem integradas.
24
A criação de um processo independente de teste demandou algumas necessidades de
metodologias, métricas e de melhorias, que já existiam no processo de desenvolvimento de
software original, mas que precisavam ser adaptadas a este novo processo.
Os processos de testes de software descritos pelo CMMI se refletem atualmente no
comportamento das empresas na busca em implantar ou mesmo melhorar o processo de teste
utilizado. Ainda que as técnicas de teste de software mais utilizadas foram criadas por volta
dos anos 80, as empresas têm uma grande dificuldade com a atividade de teste.
25
1.3 QUESTÃO DA PESQUISA
Em função desse cenário, temos o seguinte questionamento:
Quais os impactos na qualidade dos produtos e serviços de testes de software sob a
ótica do cliente na adoção dos processos de testes baseados no modelo CMMI?
1.4 OBJETIVOS DO ESTUDO
Os objetivos do presente trabalho de dissertação são:
Objetivo Geral: Avaliar os impactos na qualidade dos produtos e serviços de testes
sob a ótica do cliente na adoção dos processos de testes de software baseados no modelo
CMMI (Capability Maturity Model Integration).
Objetivos Específicos:
1. Avaliar os impactos na qualidade dos produtos de software junto aos clientes com
a utilização de processos de testes baseados no modelo CMMI (Capability
Maturity Model Integration).
2. Avaliar os impactos na qualidade dos serviços de testes de software junto aos
clientes com a utilização de processos de testes baseados no modelo CMMI
(Capability Maturity Model Integration).
3. Identificar o nível de aderência dos processos de testes segundo o modelo CMMI
(Capability Maturity Model Integration) de cada produto e serviço.
26
O contexto empresarial e os objetivos onde a pesquisa se encontra localizada podem ser vistos
na figura 2 a seguir:
Figura 2 - Localização da pesquisa
Fonte: Elaboração própria.
1.5 JUSTIFICATIVAS
O presente trabalho de dissertação torna-se justificável pelos seguintes motivos:
Ordem Pessoal
O presente trabalho irá contribuir para o desenvolvimento acadêmico e profissional do
autor, que atua na área de Qualidade e Testes de Software, bem como ministra cursos na área
de Engenharia de Software. Sendo assim, o tema proposto permitirá uma integração dos
conceitos e modelos teóricos com a experiência profissional do autor.
Em decorrência da qualidade de um software ser altamente influenciada pela qualidade
do processo de teste utilizado no seu desenvolvimento e manutenção.
Com isso é possível, por meio de uso de testes e análise dos diversos métodos
propostos por autores diversos, por outros estudos e as adaptações feitas pelo próprio
pesquisador, levar a cabo contribuições ao tema, permitindo o desenvolvimento da sua
capacidade profissional para atuação junto às empresas.
27
Além disso, os resultados obtidos em tal estudo permitirão ao pesquisador desenvolver
mais sua experiência no controle da qualidade de softwares, bem como no aperfeiçoamento
dos conceitos a serem utilizados no treinamento de profissionais da área de testes de software.
A oportunidade de aplicar e testar diretamente novos conceitos da área de qualidade de
software em projetos reais.
Ordem Teórica
A qualidade de um produto de software não pode ser imposta após a finalização do
mesmo, estando ela fortemente relacionada à qualidade do processo de software. Normas
importantes, como ISO 9000, ISO/IEC 12207 e o modelo CMMI (Capability Maturity Model
Integration), sugerem a melhoria da qualidade dos produtos (software) por meio da melhoria
de seu processo (Weber, 2001).
Com o objetivo de desenvolver softwares de qualidade, as empresas cada vez mais
investem em modelos para obter controle de seus processos e evoluir em direção a uma
cultura de excelência de engenharia e gestão.
Uma das maneiras de controlar a qualidade, tanto do produto como do processo, é com
o teste de software, que define um conjunto de atividades de validação e verificação com o
objetivo de encontrar defeitos no produto e no processo de software.
Tendo como referenciais teóricos o modelo CMMI (Capability Maturity Model
Integration), Testes de Software, ISO/IEC 9126 e Qualidade em Serviços, este trabalho
pretende contribuir para demonstrar os benefícios e contribuir para a consolidação de sua
efetividade.
Ordem Prática
A análise dos benefícios da adoção dos processos de testes exigidos pelo modelo CMMI
(Capability Maturity Model Integration) será fundamental para expansão de sua aplicação
permitindo maior competitividade às organizações.
28
O resultado do nível de maturidade dos processos de testes no de desenvolvimento de
softwares será de fundamental importância e permitirá que as empresas se aperfeiçoem na
entrega de um produto de boa qualidade.
A partir do momento em que a empresa toma conhecimento da necessidade de melhorar
a qualidade dos seus produtos e passa a ter um processo de desenvolvimento definido,
praticado, gerenciado, medido e controlado (maturidade do processo), ela segue rumo a
melhoria de processo e qualidade.
Ordem Contextual
No cenário brasileiro de desenvolvimento de software, observa-se, no passar dos últimos
anos, uma crescente conscientização por parte das empresas com relação qualidade de seus
produtos (Weber, 2001).
Apesar de toda a evolução tecnológica, problemas ainda persistem quanto à condução e
implementação de projetos e desenvolvimento de produtos, principalmente quanto a prazos,
custos e satisfação dos usuários.
As empresas estão cada vez mais exigentes e com os recursos financeiros mais limitados. É
possível observar que muitas empresas não estão tentando melhorar o seu processo de
desenvolvimento de produto ao investir grandes somas de dinheiro em tecnologia, buscando
somente produtividade.
Por outro lado, estudos para implantação de processos de melhoria da qualidade são
contribuições ao aperfeiçoamento do processo de desenvolvimento de produto, buscando
qualidade nos mesmos, o que vem sendo abordados por diversos autores.
Ordem Institucional
O processo de testes é geralmente uma atividade de custos elevados no processo de
desenvolvimento de um software. Em alguns casos, os processo de testes são responsáveis por
mais de 50% dos custos envolvidos (Sommerville, 2003). Isto se dá em função porque uma
29
parte dessas atividades ainda é executada de forma desordenada, sem a utilização de
processos estabelecidos.
Mesmo com o importante papel na aferição da qualidade de um produto (Myers, 1979)
e sua execução de forma incompleta ou inadequada possa causar danos e prejuízos, eles ainda
são deixados de lado por algumas organizações. Freqüentemente, atrasos nas atividades de
desenvolvimento são compensados por meio da redução ou eliminação das atividades de teste
(Aranha e Borba, 2002).
A qualidade dos produtos de software tornou-se uma arma estratégica para posicionar as
empresas em condições de competir num mercado acirrado, em termos de concorrência, dada
a importância que o tema tem merecido e o seu rápido crescimento. Isto tem levado as
Universidades a darem uma nova vertente aos seus programas de curso, incluindo disciplinas
no campo da qualidade dos produtos de software, preparando seus alunos para um mercado de
trabalho cada vez mais competitivo.
Este estudo pretende contribuir para o progresso da pesquisa de Fatores Humanos e
Tecnológicos e Competitividade, dirigida pelo Prof. D.Sc. Heitor Luiz Murat de Meirelles
Quintella na Universidade Federal Fluminense (Quintella, 1997), ao analisar os impactos da
adoção dos processos de testes de software exigidos pelo CMMI (Capability Maturity Model
Integration) aplicados no desenvolvimento de produtos e serviços.
30
1.6 HIPÓTESES E/OU QUESTÕES
1.6.1 Hipótese I
A adoção dos processos de testes baseados no modelo CMMI (Capability Maturity
Model Integration) aplicados no desenvolvimento de produtos de software impacta na
qualidade sob a ótica do cliente.
1.6.2 Hipótese II
A adoção dos processos de testes baseados no modelo CMMI (Capability Maturity
Model Integration) aplicados no desenvolvimento de serviços de testes de software
impacta na qualidade sob a ótica do cliente.
Questões – Chave para atender ao objetivo número 1. (Questionário ISO/IEC 9126)
1. Funcionalidade: O conjunto de funções satisfaz as necessidades explícitas e implícitas para
a finalidade a que se destina o produto?
2. Confiabilidade: O desempenho se mantém ao longo do tempo e em condições
estabelecidas, ou seja, é tolerante a falhas?
3. Usabilidade: O software é fácil de usar?
4. Eficiência: Os recursos e os tempos utilizados são compatíveis com o nível de desempenho
requerido pelo produto?
5. Manutenibilidade: É fácil corrigir, atualizar e alterar o software?
6. Portabilidade: É possível utilizar o produto em diversas plataformas com pequeno esforço
de adaptação?
31
Questões – Chave para atender ao objetivo número 2. (Adaptação Questionário
SERVQUAL)
1. Qual a qualidade percebida pelo cliente em relação aos serviços de testes de software, nos
seguintes itens: aparência das instalações físicas, equipamento, pessoal e materiais de
comunicação?
2. Qual a qualidade percebida pelo cliente, quanto à habilidade na disponibilização dos
serviços de testes de software conforme prometido, de forma confiável, precisa e consistente?
3. Qual a qualidade percebida pelo cliente em relação aos serviços de testes de software,
quanto à disposição para auxiliar os clientes e proporcionar o serviço imediatamente?
4. Qual a qualidade percebida pelo cliente em relação aos serviços de testes de software, nos
seguintes itens: conhecimento para responder a todas as perguntas relacionadas com o produto
de software, atenção mostrada pelas equipes de atendimento e suas habilidades para transmitir
confiança, segurança e credibilidade?
5. Qual a qualidade percebida pelo cliente em relação aos serviços de testes de software,
quanto à atenção individualizada, facilidade de contato, acesso e comunicação?
Questões – Chave para atender ao objetivo número 3. (Questionário CMMI)
1. Os produtos foram selecionados para verificação?
2. O ambiente de verificação foi devidamente estabelecido?
3. Os procedimentos e critérios de verificação foram estabelecidos?
3. A revisão pelos participantes foi devidamente preparada?
4. A revisão foi devidamente conduzida?
5. Os dados de revisão dos participantes foram analisados?
6. A verificação foi realizada?
7. Os resultados das verificações foram analisados e ações de correção foram identificadas?
8. Os produtos foram selecionados para validação?
9. O ambiente de validação foi devidamente estabelecido?
10. Os procedimentos e critérios de validação foram estabelecidos?
11. A validação foi realizada?
12. Os resultados das validações foram analisados e ações de correção foram identificadas?
32
Justificativa do Emprego das Questões Chave para a Hipótese
Questões Chave – Questionário
ISO/IEC 9126
Justificativa da Questão para Teste da Hipótese
1. Funcionalidade: O conjunto de
funções satisfaz as necessidades
explícitas e implícitas para a finalidade
a que se destina o produto?
O objetivo desta questão é identificar a
característica Funcionalidade por meio da aplicação
do questionário do Apêndice A, questões 1 a 5.
2. Confiabilidade: O desempenho se
mantém ao longo do tempo e em
condições estabelecidas? ou seja, é
tolerante a falhas?
O objetivo desta questão é identificar a
característica Confiabilidade por meio da aplicação
do questionário do Apêndice A, questões 6 a 8.
3. Usabilidade: O software é fácil de
usar?
O objetivo desta questão é identificar a
característica Usabilidade por meio da aplicação do
questionário do Apêndice A, questões 9 a 11.
4. Eficiência: Os recursos e os tempos
utilizados são compatíveis com o nível
de desempenho requerido pelo
produto?
O objetivo desta questão é identificar a
característica Eficiência por meio da aplicação do
questionário do Apêndice A, questões 12 a 13.
5. Manutenibilidade: É fácil corrigir,
atualizar e alterar o software?
O objetivo desta questão é identificar a
característica Manutenibilidade por meio da
aplicação do questionário do Apêndice A, questões
14 a 17.
6. Portabilidade: É possível utilizar o
produto em diversas plataformas com
pequeno esforço de adaptação?
O objetivo desta questão é identificar a
característica Portabilidade por meio da aplicação
do questionário do Apêndice A, questões 18 a 21.
Questões Chave – Adaptação
Questionário SERVQUAL
Justificativa da Questão para Teste da Hipótese
1. Qual a qualidade percebida pelo
cliente em relação aos serviços de
testes de software, nos Seguintes itens:
aparência das instalações físicas,
equipamento, pessoal e materiais de
comunicação?
O objetivo desta questão é verificar do ponto de
vista do cliente as seguintes características dos
serviços prestados: equipamentos (hardware e
software) avançados para o suporte ao processo de
teste, por meio da aplicação do questionário do
Apêndice B, questões 1 a 4.
2. Qual a qualidade percebida pelo
cliente, quanto à habilidade na
disponibilização dos serviços de testes
de software conforme prometido, de
forma confiável, precisa e consistente?
O objetivo desta questão é verificar do ponto de
vista do cliente as seguintes características dos
serviços prestados: área dedicada à execução e
suporte aos processos de testes., por meio da
aplicação do questionário do Apêndice B, questões
5 a 9.
3. Qual a qualidade percebida pelo
cliente em relação aos serviços de
testes de software, quanto à disposição
para auxiliar os clientes e proporcionar
o serviço imediatamente?
O objetivo desta questão é verificar do ponto de
vista do cliente as seguintes características dos
serviços prestados: empregados
organizados na
execução das atividades de testes, por meio da
aplicação do questionário do Apêndice B, questões
10 a 13.
4. Qual a qualidade percebida pelo
cliente em relação aos serviços de
O objetivo desta questão é verificar do ponto de
vista do cliente as seguintes características dos
33
testes de software, nos Seguintes itens:
conhecimento para responder a todas
as perguntas relacionadas com o
produto de software, atenção mostrada
pelas equipes de atendimento e suas
habilidades para transmitir confiança,
segurança e credibilidade?
serviços prestados: elementos materiais
relacionados com o serviço (planos, procedimentos
e relatórios) visualmente atraentes, por meio da
aplicação do questionário do Apêndice B, questões
14 a 17.
5. Qual a qualidade percebida pelo
cliente em relação aos serviços de
testes de software, quanto à atenção
individualizada, facilidade de contato,
acesso e comunicação?
O objetivo desta questão é verificar do ponto de
vista do cliente as seguintes características dos
serviços prestados: Projetos de testes agendados são
executados na data acordada, por meio da aplicação
do questionário do Apêndice B, questões 18 a 22.
Questões Chave – Adaptação
Questionário CMMI
Justificativa da Questão para Teste da Hipótese
1. Os produtos foram selecionados para
verificação?
O objetivo desta questão é verificar se os produtos a
serem testados foram selecionados conforme prática
de teste do modelo CMMI.
2. O ambiente de verificação foi
devidamente estabelecido?
O objetivo desta questão é veri
ficar se o ambiente
foi devidamente estabelecido conforme prática de
teste do modelo CMMI.
3. Os procedimentos e critérios de
verificação foram estabelecidos?
O objetivo desta questão é verificar se os
procedimentos e critérios de verificação foram
estabelecidos conforme prática de teste do modelo
CMMI.
3. A revisão pelos participantes foi
devidamente preparada?
O objetivo desta questão é verificar se a revisão
pelos participantes foi devidamente preparada
conforme prática de teste do modelo CMMI.
4. A r
evisão foi devidamente
conduzida?
O objetivo desta questão é verificar se a revisão foi
devidamente conduzida conforme prática de teste do
modelo CMMI.
5. Os dados de revisão dos
participantes foram analisados?
O objetivo desta questão é verificar se os dados de
revisão dos participantes foram analisados conforme
prática de teste do modelo CMMI.
6. A verificação foi realizada? O objetivo desta questão é validar se a verificação
foi realizada conforme prática de teste do modelo
CMMI.
7. Os resultados das verificações foram
analisados e ações de correção foram
identificadas?
O objetivo desta questão é verificar se os resultados
das verificações foram analisados e ações de
correção foram identificadas conforme prática de
teste do modelo CMMI.
8. Os produtos foram selecionados para
validação?
O objetivo desta questão é verificar se os produtos
foram selecionados para validação conforme prática
de teste do modelo CMMI.
9. O ambiente de validação foi
devidamente estabelecido?
O objetivo desta questão é verificar se o ambiente
de validação foi devidamente estabelecido conforme
prática de teste do modelo CMMI.
10. Os procedimentos e critérios de
validação foram estabelecidos?
O objetivo desta questão é verificar se os
procedimentos e critérios de validação foram
estabelecidos conforme prática de teste do modelo
34
CMMI.
11. A validação foi realizada? O objetivo desta questão é verificar se a validação
foi realizada conforme prática de teste do modelo
CMMI.
12. Os resultados das validações foram
analisados e ações de correção foram
identificadas?
O objetivo desta questão é verificar se os resultados
das validações foram analisados e ações de correção
foram identificadas conforme prática de teste do
modelo CMMI.
Quadro 1 - Justificativa da Questão para Teste da Hipótese
Fonte: Elaboração própria
35
2 REFERENCIAL TEÓRICO
Neste capítulo serão abordados os referenciais teóricos utilizados para o desenvolvimento
e análise do tema. Os referenciais presentes nessa dissertação são:
Testes de Software;
CMMI (Capability Maturity Model Integration);
Qualidade em Serviços - SERVQUAL ;
Qualidade de Produtos de Software - ISO/IEC 9126
A estrutura e abrangência dos referenciais utilizados podem ser visto na figura abaixo:
Figura 3 - Contexto dos referenciais teóricos
Fonte: Elaboração própria
36
2.1 TESTES DE SOFTWARE
2.1.1 Introdução
Existem diversas definições para teste de software:
verificar se o software está fazendo o que deveria fazer, de acordo com os
requisitos, e não fazendo o que não deveria fazer;
processo de executar um programa ou sistema com a intenção de encontrar
erros (Myers, 1979).
qualquer atividade que a partir da avaliação de um atributo ou capacidade de
um programa ou sistema seja possível determinar se ele alcança os resultados
desejados (Hetzel, 1988).
Basicamente podemos dizer independente do autor que: Teste de software é o processo
de executar o software de uma maneira controlada com o objetivo de avaliar se o mesmo se
comporta conforme o especificado.
O processo de teste envolve:
Entradas: envolvendo a especificação de requisitos e do projeto do projeto;
Processos: utilização dos planos de procedimentos de testes, bem como
ferramentas para auxílio na depuração e no teste propriamente dito e ;
Saídas: avaliação dos resultados obtidos na fase anterior.
Figura 4 - Atividades do processo de teste.
Fonte: Inthurn (2001)
Segundo Myers (1979) um bom caso de teste é aquele que tem alta probabilidade de
encontrar um erro ainda não descoberto. Se o teste for conduzido de maneira bem-sucedida,
ele descobrirá erros de software.
37
Terminologia de Testes de Software
Erro: Engano ou omissão causado por uma ação humana.
Falta (Fault) – resultado ou representação de um erro.
Falta de comissão – representação incorreta.
Falta de omissão – representação ausente.
Falha (Failure) – inabilidade manifestada de um sistema ou componente de executar uma
função requisitada dentro de certos limites. É evidenciado através de saída incorreta, término
anormal, não satisfação de restrições de tempo e espaço.
Incidente – Sintoma associado à falha que alerta o usuário de sua ocorrência.
Abend – Terminação abrupta do programa (abort, crash).
Omissão – Capacidade requisitada que não está presente em uma implementação.
Os testes têm como objetivo a detecção de defeitos e existem diversos meios de tornar
mais eficientes e efetivos os esforços relacionados aos testes. O teste de software é um
elemento crítico da garantia de qualidade de software e representa a revisão final da
especificação, projeto e geração de código.
Os processos de teste de software fornecem diretrizes sistemáticas para a execução da
lógica interna dos componentes do software, executam domínios de entrada e saída do
programa para descobrir erros na função, comportamento e desempenho.
Pressman afirma que a atividade de teste de software é um elemento crítico da garantia
de qualidade de software e representa a última revisão de especificação, projeto e codificação.
Citamos (DEUTSCH, 1995):
O desenvolvimento de sistemas de software envolve uma série de
atividades de produção em que as oportunidades de introdução de falhas
humanas são enormes. Erros podem começar a acontecer logo no começo
do processo, onde os objetivos podem estar errônea ou imperfeitamente
especificados, além de erros que venham a ocorrer em fases de projeto e
38
desenvolvimento posteriores...Por causa da incapacidade que os seres
humanos têm de executar e comunicar com perfeição, o desenvolvimento
de software é acompanhado por uma atividade de garantia de qualidade.
Os princípios de testes de software, segundo Pressman (1995) são:
Todos os testes devem ser relacionados aos requisitos do cliente;
Os testes devem ser planejados muito antes do início do teste;
O princípio de Pareto se aplica ao teste de software, isto é, 80% de todos os
erros descobertos durante o teste vão provavelmente ser relacionados a 20% de
todos os componentes do programa. O problema é isolar os componentes
suspeitos e testá-los;
O teste deve começar “no varejo”, isto é, nos componentes individuais, para
depois progredir até o teste “no atacado”, em todo o sistema;
Teste completo não é possível, mas pode-se cobrir adequadamente a lógica do
programa e garantir que todas as condições no projeto ao nível de componente,
tenham sido exercitadas.
A testabilidade de software é a facilidade com que um programa de computador pode
ser testado. Um software é testável quando possui as características:
Operabilidade: quanto melhor funciona, mais eficientemente pode ser testado.
Observabilidade: o que se vê é o que se testa.
Controlabilidade: quanto mais se pode controlar o software, mais o teste pode
ser automatizado e otimizado.
Decomponibilidade: controlando o escopo do teste, pode-se isolar problemas
mais rapidamente e realizar retestagem mais racionalmente.
Simplicidade: quanto menos há a testar, mais rápido se pode testar.
Estabilidade: quanto menos modificações, menos interrupções no teste.
Compreensibilidade: quanto mais informações se têm, mais racionalmente será
testado.
Com relação aos testes, Pressman (1995), sugerem os seguintes atributos para um bom
teste:
39
Um bom teste tem uma alta probabilidade de encontrar um erro;
Não é redundante;
Deve ser boa cepa: em um grupo de teste que têm um objetivo semelhante, as
limitações de tempo e recursos podem ser abrandadas no sentido da execução
de apenas um subconjunto desses testes;
Um bom teste não deve ser muito simples, nem muito complexo.
2.1.2 Objetivos do Teste
O objetivo da atividade de teste pode ser entendido da seguinte forma:
no início de cada fase verificar se esta etapa do projeto reflete exatamente os
requisitos e definições da fase imediatamente anterior, para com isso garantir que o
produto encomendado e o gerado pela atividade de desenvolvimento do software será
o mesmo por meio dos diferentes níveis de refinamento do projeto;
verificar se não existem erros de lógica no projeto e código, no fluxo de dados, no
entendimento de requisitos, de codificação, tipográficos ou de interface em todas as
fases do projeto;
identificar e interferir na presença do erro, iniciando-se a depuração, sendo que quanta
antes for descoberta a falha, menos custoso será para adequá-la;
ter em mente que, uma vez que errar é humano e atividade de desenvolvimento de
software é um exercício complexo, os erros existem e devem ser descobertos, portanto
o sucesso em um teste consiste em descobrir os erros e corrigi-los.
2.1.3 Técnica de Testes Estáticas e Dinâmicas
De acordo a literatura existem classificações das formas de teste de acordo com a forma de
execução. Alguns autores, como Pressman (2000), não consideram que as atividades estáticas
sejam de fato atividades de testes de software, mas uma revisão técnica formal – ou seja, o
teste de software seria uma atividade essencialmente dinâmica e ambas as abordagens seriam
complementares.
40
Já Hetzel (1987) e Peters (2001) consideram que a revisão de software é uma atividade
estática de testes de software, e não um complemento da mesma. Uma breve descrição das
duas abordagens é dada a seguir:
Testes Estáticos: também conhecidos como teste não computacional e revisão de software,
este tipo de teste não envolve a execução propriamente dita do programa. As técnicas de teste
estático se valem da leitura ou inspeção visual de programas por um grupo de pessoas com o
objetivo de encontrar erros. O custo de correção de erros encontrados por este método parece
ser mais baixo visto que a origem precisa do erro é localizada, enquanto que os testes
dinâmicos acusam apenas sintomas dos erros. Porém, estes métodos não são eficazes na
detecção de erros de modelagem ou análise de requisitos. Exemplos clássicos de técnicas de
teste estático são as inspeções de código, o percorrimento e as avaliações por pares ou peer-
reviews (Myers, 1979).
Testes Dinâmicos: objetiva encontrar erros no software por meio de execução do mesmo.
Os testes estáticos e dinâmicos são complementares por encontrarem tipos diferentes de erros,
e a detecção dos mesmos vai sofrer se um ou outro não estiver presente (Myers, 1979).
2.1.4 Tipos de Teste
Segundo (Hetzel,1988), (Myers,1979), (Beizer,1995), os tipos de testes podem ser definidos
como:
Testes Caixa Preta (Black Box): visam verificar a funcionalidade e a aderência aos
requisitos, em uma visão externa ou do usuário, sem conhecimento do código e da
lógica interna do componente testado.
Testes Caixa Branca (White Box): visam avaliar asa clausulas de código, a lógica
interna do componente codificado, as configurações e outros elementos técnicos.
Testes de Unidade: estágio mais baixo da escala de testes e são aplicados nos
menores componentes de código criados.
Testes de Integração: são executados em combinação de componentes para
verificar se eles funcionam corretamente juntos.
41
Testes de Regressão: visam garantir que o software permaneça intacto depois de
novos testes serem realizados.
Testes de Carga: visam avaliar a resposta de um software sob uma pesada carga de
dados, repetição de certas ações de entrada de dados, entrada de valores numéricos
grandes, consultas complexas a base de dados, grande quantidades de usuários
simultâneos para verificar o nível de escalabilidade.
Testes Back-to-back: o mesmo teste executado em versões diferentes do software e
os resultados são comparados.
Testes de Configuração: verificam se o software está apto a funcionar em
diferentes versões ou configurações de ambientes (hardware e software).
Testes de Usabilidade: verificam o nível de facilidade de uso do software pelos
usuários.
Testes de Instalação: verificam o processo de instalação parcial, total ou
atualização do software.
Testes de Segurança: validam a capacidade de proteção do software contra acessos
interno ou externo não autorizados.
Testes de Recuperação: validam a capacidade e qualidade da recuperação do
software após falhas de hardware ou problemas externos.
Testes de Compatibilidade: validam a capacidade do software de executar em um
particular ambiente de hardware/software/sistema operacional ou rede.
Testes de Desempenho/Performance: visam garantir que o sistema atende os níveis
de desempenho e tempo de resposta acordados com usuários e definidos nos
requisitos.
Testes Funcionais: grupos de testes que validam se o que foi especificado foi
implementado.
Teste de Qualidade de Código: grupos de testes com o intuito de verificar o código
fonte dos programas em consonância com padrões, melhores práticas, instruções
não executadas e outros.
Testes de Alterações: visam rastrear alterações de programas durante o processo de
teste.
Testes de Recuperações de Versões: verificam a capacidade de retornar a uma
versão anterior do software.
Testes de Interoperabilidade: avaliam as condições de integração com outros
softwares e /ou ambientes.
42
Testes de Sobrevivência: avaliam a capacidade do software em continuar operando
mesmo quando algum elemento (software ou hardware) fica inoperante ou para de
funcionar.
Testes Estéticos: avaliam toda a documentação do projeto, tais como modelos,
requisitos, etc.
Teste Embutido: avalia a capacidade de integração entre o hardware e o software.
Teste de Conferência de Arquivos: verificam alterações nos arquivos usados.
Testes Alfa: são executados quando o desenvolvimento está próximo a sua
conclusão.
Testes Beta: são executados quando o desenvolvimento e testes estão praticamente
concluídos.
Teste de Verificação de Sites Web: verificam problemas que possam haver no site
como links inválidos, arquivos órfãos, ligações entre páginas (Molinari, 2003).
2.1.5 Documentação de Testes
A Norma IEEE 829 descreve um conjunto de documentos para as atividades de teste de um
produto de software. Os 8 documentos definidos pela norma, que cobrem as tarefas de
planejamento, especificação e relato de testes, são apresentados a seguir:
Plano de Teste – Apresenta o planejamento para execução do teste, incluindo a abrangência,
abordagem, recursos e cronograma das atividades de teste. Identifica os itens e as
funcionalidades a serem testados, as tarefas a serem realizadas e os riscos associados com a
atividade de teste.
A tarefa de especificação de testes é coberta por 3 documentos:
Especificação de Projeto de Teste – Refina a abordagem apresentada no Plano de
Teste e identifica as funcionalidades e características a serem testadas pelo projeto e
por seus testes associados. Este documento também identifica os casos e os
procedimentos de teste, se existirem, e apresenta os critérios de aprovação.
Especificação de Caso de Teste – Define os casos de teste, incluindo dados de entrada,
resultados esperados, ações e condições gerais para a execução do teste.
43
Especificação de Procedimento de Teste – Especifica os passos para executar um
conjunto de casos de teste.
Os relatórios de teste são cobertos por 4 documentos:
Diário de Teste - Apresenta registros cronológicos dos detalhes relevantes
relacionados com a execução dos testes.
Relatório de Incidente de Teste - Documenta qualquer evento que ocorra durante a
atividade de teste e que requeira análise posterior.
Relatório-Resumo de Teste – Apresenta de forma resumida os resultados das
atividades de teste associadas com uma ou mais especificações de projeto de teste e
provê avaliações baseadas nesses resultados
Relatório de Encaminhamento de Item de Teste – Identifica os itens encaminhados
para teste no caso de equipes distintas serem responsáveis pelas tarefas de
desenvolvimento e de teste.
A norma separa as atividades de teste em três etapas: preparação do teste, execução do teste e
registro do teste. Os documentos que são produtos da execução de cada uma das fases e os
relacionamentos entre eles podem ser vistos na figura a seguir:
44
Figura 5 - Documentação do processo de testes segundo a norma IEEE 829
Fonte: IEEE (1998)
2.1.6 Integração dos Processos de Desenvolvimento e Teste
O processo de teste deve ser integrado ao processo de desenvolvimento. À medida
que o projeto de desenvolvimento evolui uma etapa de testes deve ser realizada. Com esta
abordagem a identificação de erros ocorre de forma antecipada minimizando os custos de
correção (Myers,1979)
Segundo Molinari (2003) adotando o modelo de testes em V podemos identificar
como as atividades de teste podem ser embutidas em cada etapa do processo de
desenvolvimento do software. Conforme o modelo proposto por Myers (1979) o ciclo de vida
de software conta com as fases de elicitação de requisitos, projeto, implementação e operação
e manutenção.
45
Figura 6 – Modelo em V de Testes de Software
Fonte: Molinari (2003)
Elicitação de Requisitos
De acordo com Pressman (2000), alguns dos itens que devem ser verificados nesta
fase são:
O domínio de informação é completo, consistente e acurado?
A divisão do problema em partições é completa?
As interfaces externas e internas são adequadamente definidas?
O modelo de dados reflete adequadamente os objetos de dados, seus atributos e relações?
Todos os requisitos são rastreáveis em nível de sistema?
O desempenho é atingível, dentro das restrições impostas por outros elementos do
sistema?
Os requisitos têm consistência com os prazos, os recursos e o orçamento?
Os critérios de validação estão completos?
Projeto
A lista de verificação indicada por Pressman (2000) para esta etapa é:
Os requisitos de software se refletem na arquitetura do software?
É conseguida uma efetiva modularidade? Os módulos são funcionalmente independentes?
A arquitetura de programa é fatorada?
46
São definidas interfaces para os módulos e para os elementos de sistema externos?
A estrutura de dados é consistente com o domínio de informação?
A estrutura de dados é consistente com os requisitos de software?
A manutenibilidade foi levada em consideração?
Os fatores de qualidade foram explicitamente avaliados?
O algoritmo executa a função desejada?
O algoritmo está logicamente correto?
A interface é consistente com o projeto arquitetural?
A complexidade lógica é razoável ou deve-se dividir as funções de um módulo em dois ou
mais sub-módulos?
O tratamento de erros foi especificado?
As estruturas de dados locais foram adequadamente definidas?
As construções de programação estruturadas são usadas do princípio ao fim?
Os detalhes de projeto são adequados à linguagem de implementação?
Quais particularidades são usadas: do sistema operacional ou dependentes da linguagem?
Implementação
A lista de verificação indicada por Pressman (2000) para esta etapa é:
O projeto foi adequadamente traduzido em código?
Há erros de ortografia ou tipográficos?
As convenções da linguagem foram adequadamente utilizadas?
Existe concordância em relação aos padrões de codificação quanto ao estilo da linguagem,
comentários e cabeçalho do modular?
Há comentários incorretos ou ambíguos?
Os tipos de dados e a declaração de dados são apropriados?
As constantes físicas estão corretas?
Operação e Manutenção
Durante o ciclo de desenvolvimento ocorre uma integração entre os processos de
desenvolvimento e testes conforme tabela 3 a seguir.
47
Tabela 3 - Integração dos processos de desenvolvimento e teste
Fonte: Pressman (2000)
2.1.7 Importância do Processo de Testes
De acordo com o relatório “The Economic Impact of Inadequate Infraestrutre for Software
Testing” (NIST, 2002) estima-se que os custos com defeitos em softwares custem às empresas
americanas aproximadamente, um valor próximo de 1% do PIB dos Estados Unidos.
A insuficiência dos testes é indicada por Caper Jones em “Patterns of Software System
Failure and Sucess” como um dos principais motivos de falha nos projetos de
desenvolvimento de software e, segundo o Gartner Group (2001), apenas 7% das aplicações
entregues atendem os requisitos de tempo de resposta e performance.
Segundo Myers (1979) os erros identificados após a execução de cada fase de
desenvolvimento tem seu custo de correção elevado conforme gráfico 1 a seguir:
Gráfico 1 - Regra 10 de Myers
Fonte: Myers (1979)
48
2.2. CMMI
2.2.1 Processo de Software
Segundo Paulk (1993), o software é resultado do processo de desenvolvimento, onde a
qualidade de um sistema de software é altamente influenciada pela qualidade do processo que
o gera.
Processo pode ser definido como:
Conjunto de atividades, métodos, práticas e transformações que as pessoas
utilizam para desenvolver e manter os produtos associados Gonçalves & Boas.
(2002b);
Conjunto de atividades interrelacionadas, que transforma entradas em saídas.
(NBR, 2001);
Seqüência de passos realizados para um determinado propósito. Esta definição
pode ser aplicada a qualquer atividade, seja ela da manufatura ou não.
IEEE(2001);
Paulk (1993) define Processo de software com um conjunto de atividades, métodos,
práticas e tecnologias que as pessoas utilizam para desenvolver e manter software e seus
produtos relacionados.
Figura 6 - Processo de software
Fonte: Paulk (1993)
49
Para um processo funcionar satisfatoriamente, ele deve possuir:
Procedimentos e métodos que descrevam a relação entre as tarefas.
Ferramentas e equipamentos que dêem suporte à realização das tarefas,
simplificando e automatizando o trabalho.
Pessoas com perfis adequados, treinadas nos métodos e nas ferramentas para
poderem realizar as atividades adequadamente.
2.2.2 O Modelo CMM/CMMI
Um processo é o ponto de alavanca para melhoria da organização. O propósito do
CMMI é fornecer orientação para melhorar os processos de uma organização e sua habilidade
em gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços.
O Modelo de Maturidade da Capabilidade de Software fornece às organizações de
software um guia de como obter controle de seus processos para desenvolver e manter
software e como evoluir em direção a uma cultura de engenharia de software e excelência de
gestão. O CMM foi projetado para guiar as organizações de software no processo de seleção
das estratégias de melhoria, determinando a maturidade atual do processo e identificando as
poucas questões mais críticas para a qualidade de software e melhoria do processo. Focando
em um conjunto limitado de atividades e trabalhando agressivamente para concluí-las com
êxito, a organização pode melhorar o processo de software na organização toda para
possibilitar ganhos contínuos e duradouros na capabilidade do processo de software.
Segundo (PAULK , 1993A) E (PAULK, 1993B), APUD (FIORINI, STAA E BAPTISTA,1998),
a definição de CMM é:
CMM é uma estrutura (framework) que descreve os principais elementos de um
processo de software efetivo
1
. O CMM descreve os estágios por meio dos quais
organizações de software evoluem quando elas definem, implementam, medem
controlam e melhoram seus processos de software. O CMM fornece uma diretriz
para a seleção de estratégias de melhoria de processos, permitindo a determinação da
capacitação dos processos correntes e a conseqüente identificação das questões mais
críticas para a melhoria de processo e qualidade de software. Desta forma, provê e
descreve um caminho de melhoria evolutiva a partir de um processo ad hoc para um
processo maduro e altamente disciplinado. Este caminho de melhoria é definido por
1
Um processo de software efetivo é um processo que pode ser caracterizado como
praticado, documentado, indispensável, medido e passível de melhoria.
50
cinco níveis de maturidade: Inicial, Repetitivo, Definido, Gerenciado e Em
Otimização.
Segundo (FIORINI, STAA E BAPTISTA ,1998), os objetivos do CMM são:
Ajudar organizações a conhecerem e melhorarem seus processos de
desenvolvimento e manutenção de software. Para atingir este objetivo, o CMM
descreve os elementos essenciais de um processo de software efetivo.
O CMM guia organizações de software, que querem obter controle sobre seus
processos de software, de modo que possam evoluir em direção a uma cultura de
engenharia de software e de excelência em gerência. Focalizando em um conjunto
limitado de atividades e trabalhando agressivamente para atingi-las, uma
organização pode melhorar continuamente o processo de software de toda a
organização, habilitando-a a auferir ganhos contínuos e duradouros de capacitação
do processo de software.
O CMM fornece uma estrutura conceitual para melhorar continuamente e de uma
maneira disciplinada a gerência e o desenvolvimento de software. Entretanto, o CMM não
garante que o software será sempre construído com sucesso, nem assegura que todos os
problemas de engenharia e gerência serão resolvidos. O CMM não aborda todas as questões
importantes para um projeto de sucesso. O CMM identifica práticas para um processo de
software maduro, definindo as características de um processo de software efetivo. Entretanto,
a organização deve endereçar muito mais que isso, incluindo todas as questões essenciais para
um projeto de sucesso e, além dos processos, deve incluir as pessoas e a tecnologia utilizada.”
Com base no sucesso do CMM (como citado, hoje conhecido como SW-CMM),
outros CMMs foram criados, procurando cobrir outras áreas de interesse (SOTILLE, 2003).
Assim surgiram os seguintes modelos:
Software Acquisition CMM (SA-CMM), utilizado para avaliar a maturidade de
uma organização em seus processos de seleção, compra e instalação de software
desenvolvido por terceiros;
Systems Engineering CMM (SE-CMM), que avalia a maturidade da organização
em seus processos de engenharia de sistemas, concebidos como algo maior que o
software, ao incluir hardware e quaisquer outros elementos que participam do
produto completo. Sotille (2003) cita que se um novo caça está sendo
desenvolvido, o avião é o “sistema”, incluindo ai todo o software nele embarcado;
People CMM (P-CMM), que avalia a maturidade da organização em seus
processos de administração de recursos humanos, no que se refere a software:
51
recrutamento e seleção de desenvolvedores, treinamento e desenvolvimento,
remuneração, etc;
Integrated Product Development CMM (IPD-CMM): ainda mais abrangente que o
SE-CMM, inclui também os processos necessários à produção e suporte ao
produto, tais como suporte ao usuário, processos de fabricação, etc. O IPD-CMM
foi desenvolvido pela Enterprise Process Improvement Collaboration (EPIC) para
servir de base para a melhoria de processos para todo o ciclo de vida do produto e
para integração dos esforços de desenvolvimento de produtos por toda a
organização. As melhores práticas do IPD-CMM foram incorporadas no CMMI –
Capability Maturity Model Integration (SEI, 1997), sendo a fonte de IPD para a
versão IPPD (Integrated Product and Process Development) do CMMI (Software
Productivity Consortium, 2004).
O surgimento de todos esses modelos gerou alguns problemas, conforme Sortille
(2003):
Nem todos usavam a mesma terminologia, de modo que um mesmo conceito podia
receber nomes diferentes em cada modelo, ou o mesmo termo ter significados
diferentes nos vários modelos;
A estrutura carecia de um formato padrão: os modelos tinham diferentes números
de níveis ou formas diferentes de avaliar o progresso;
Altos custos de treinamento, avaliação e harmonização para organizações que
tentassem usar mais de um modelo.
Surgiu então o CMM Integration (CMMI) buscando suprir as limitações do modelo
CMM, com a criação de um framework comum, eliminando inconsistências e permitindo a
inclusão de novos modelos ao longo do tempo, sempre que surgirem necessidades específicas.
Esse modelo foi construído sobre a base dos modelos anteriores e com a extensão de suas
melhores práticas (SEI, 2004), com os seguintes objetivos:
Preservar os investimentos já realizados pelos organismos governamentais, pelas
empresas privadas, pelos fornecedores e pela indústria, no processo de transição;
Unificar os vários modelos CMM existentes;
Implementar melhorias no SW-CMM, a partir das experiências adquiridas com os
projetos já implementados;
52
Reduzir o custo do treinamento, das implementações, da formação de avaliadores
oficiais e das avaliações propriamente;
Ligar mais explicitamente as atividades de gerenciamento e engenharia para com
os objetivos de negócio;
Expandir o escopo e a visibilidade do ciclo de vida do produto e atividades de
engenharia, de forma a assegurar que o produto ou serviço atende as expectativas
dos clientes;
Incorporar lições aprendidas (lessons learned) de áreas outras de melhores práticas,
com, por exemplo, mensuração, gerenciamento de risco e gerenciamento de
cadeia de fornecimento;
Implementar mais práticas de robustez de maturidade;
Atender mais adequadamente as práticas ISO relevantes.
Figura 7 - Representação do CMMI como integrador dos diversos CMMs
Fonte: baseado em Sortille (2003).
Conforme o SEI (2004), o projeto do CMMI foi desenvolvido para preservar os
investimentos governamentais e da indústria em melhoria de processos e para substituir e
melhorar os múltiplos modelos de CMM, além de facilitar o uso de tecnologia CMM em
diversas disciplinas, pelo uso de terminologias, componentes, métodos de avaliação e material
de treinamento comuns.
2.2.3 Áreas de Conhecimento
O CMMI contém quatro áreas de conhecimento (disciplinas) em seu modelo:
Engenharia de Sistemas (CMMI-SE);
Engenharia de Software (CMMI-SW);
53
Fonteamento de Fornecedores (CMMI-SS); e
Desenvolvimento Integrado de Produto e Processo (CMMI-IPPD).
Este último (IPPD) será o motivo de estudo nessa dissertação. O IPPD é uma
abordagem sistemática que permite a colaboração ao longo do tempo das partes envolvidas
(stakeholders) por toda a vida do produto, de forma a melhor satisfazer as necessidades,
expectativas e requerimentos dos clientes, sendo seus processos integrados com os outros
processos na organização(SEI, 2004).
2.2.4 Formas de Representação
O CMMI pode ter duas formas diferentes de representação, que permitem a avaliação,
monitoramento e melhoria contínua dos processos envolvidos. São estas a representação
contínua e a representação em estágios ou degraus, cada uma com suas vantagens e
desvantagens. A organização deve optar por qual representação mais se adequa ao seu
negócio, ainda que, utilizados para melhorias de processos ou avaliações, ambas as
representações oferecem essencialmente o mesmo resultado.
2.2.4.1 Representação Contínua
Na representação contínua, a organização estabelece as áreas em que vai buscar maior
aperfeiçoamento e elevação do nível de maturidade, sem a buscar necessariamente o
enquadramento no mesmo patamar em todas as áreas que venham a definir o nível de
maturidade da organização. São esperadas as seguintes características nesse modelo de
representação (SEI, 2001a):
Permite a seleção da seqüência de melhorias melhor atendem os objetivos de
negócio da organização e suas áreas de risco;
Permite a comparação entre e por dentre organizações no que tangem suas áreas de
processos;
Permite fácil migração da EIA/IS 731 para o CMMI; e
Pela sua similaridade com a área de processos da ISO/IEC 15504, permite uma
fácil comparação em termos de melhorias de processos.
54
A figura a seguir mostra um exemplo de representação contínua em modelos de
maturidade de capabilidade.
Informação
Contato
Conhecimento
Demonstração
Testes piloto
Adoção
Institutionalização
Modelo de adoção de Maher-Myers e como o
IPD-CMM suporta a transição entre degraus
Práticas usadas para desafiar
e guiar implementação
Avaliação de práticas não atendidas
Práticas usadas como base de avaliação
Sugestões de medição
Liderança para mudança
Políticas em nível 2
Práticas colaborativas
em nível 3
Apresentação e gráficos
Adoção de tecnologia por
uma organização
Tempo
Figura 8 - Níveis de maturidade na representação contínua
Fonte: adaptado de SEI (1997)
2.2.4.2 Representação em Estágios
São esperadas as seguintes características nesse modelo de representação (SEI, 2001):
Provê uma seqüência de melhorias, começando por práticas básicas de
gerenciamento, progredindo ao longo dos níveis sucessivos, no qual cada um serve
de fundação para o próximo;
Permite a comparação entre e por dentre organizações no que tangem seus níveis
de maturidade;
Permite fácil migração do SW-CMM para o CMMI; e
Fornece um escore único, que sumaria o resultado de avaliação e permite a
comparação entre organizações.
55
Figura 9 - Níveis de maturidade na representação em estágios
Fonte: adaptado de SEI (1997)
Neste trabalho, estará sendo utilizada esta representação (por estágios) como base para
avaliação do nível de maturidade, por conta de sua similaridade como o Modelo de
Maturidade de Capabilidade mais conhecido e utilizado no momento atual, que é o CMM para
software (SW-CMM).
2.2.5 Componentes e Estrutura do Modelo
O modelo CMMI é desenhado para descrever níveis discretos de melhoria de
processos. Na representação em estágios, os níveis de maturidade estabelecem uma ordem
recomendada para melhoria dos processos, organizando as áreas de processos. Estas, por sua
vez, contém metas gerais e específicas, bem como práticas também genéricas e específicas. A
figura a seguir mostra a estrutura e os componentes do modelo CMMI:
56
Figura 10 - Componentes do modelo CMMI
Fonte: SEI (2001a)
2.2.5.1 Níveis de Maturidade
A contínua melhoria do processo é baseada em muitas e pequenas etapas evolutivas ao
invés de inovações revolucionárias (Imai, 1986). O CMMI fornece uma estrutura para
organizar essas etapas evolutivas, em cinco níveis de maturidade, que coloca fundamentos
sucessivos para a contínua melhoria do processo. Esses cinco níveis de maturidade definem
uma escala ordinal para medir a maturidade de melhoria de processos de uma organização e
para avaliar a sua capabilidade do processo diversos.
Nível de maturidade é um estágio evolutivo bem definido em direção à melhoria de
processo. Cada nível de maturidade fornece uma camada de fundamentos para a melhoria
contínua do processo, provendo a forma de predizer a performance futura da organização em
uma disciplina (ou conjunto de disciplinas), visto que cada nível compreende um conjunto de
objetivos de processos que, quando satisfeitos, estabilizam componentes importantes de
processo, resultando em um crescimento na capabilidade do processo da organização. Os
níveis de maturidade são designados por números, de 1 a 5:
57
1. Inicial;
2. Gerenciado;
3. Definido;
4. Quantitativamente Gerenciado;
5. Em Otimização.
2.2.5.1.1 Nível de Maturidade 1: Inicial
No Nível de Maturidade 1, a organização tipicamente não fornece um ambiente estável
para desenvolvimento de processos. Quando uma organização não dispõe de práticas de
gestão bem estabelecidas, os benefícios das boas práticas de desenvolvimento de produtos são
minados pelo planejamento ineficiente e por sistemas onde os compromissos são sempre
reativos, ou seja, uma reação a algum acontecimento não planejado.
Durante uma crise, os projetos tipicamente abandonam os procedimentos que foram
planejados, partindo para ações caóticas e ad hoc. O sucesso depende inteiramente da
competência e ações isoladas da equipe e não pelo uso de processos pré-definidos e
comprovados. Mesmo um forte processo de desenvolvimento não pode superar a instabilidade
criada pela ausência de práticas sólidas de gestão.
A capabilidade de processo de uma organização de Nível 1 é imprevisível, pois os
mesmos são constantemente alterados ou modificados, à medida que o trabalho progride (ou
seja, o processo é “ad hoc”). Os cronogramas, os orçamentos, as funcionalidades e a
qualidade do produto são geralmente imprevisíveis. O desempenho depende da capacidade
dos indivíduos e varia com as suas habilidades, conhecimentos e motivações inatas. Existem
poucos processos estáveis em evidência e o desempenho só pode ser previsto por meio da
habilidade individual ao invés da capabilidade da organização.
2.2.5.1.2 Nível de Maturidade 2: Gerenciado
No nível de maturidade 2, todos os projetos da organização asseguram que os
requerimentos, produtos e serviços são gerenciados e que os processos são planejados,
58
executados, medidos e controlados. O status dos produtos e serviços são visíveis para a
gerência em pontos específicos (milestones).
A disciplina de processo ajuda a assegurar que as práticas existentes são mantidas
durante os momentos de crise, com os projetos executados e gerenciados conforme os planos
documentados.
Compromissos são estabelecidos entre as partes interessadas (stakeholders) conforme
a necessidade, sendo os produtos revistos por estes, para validação do atendimento de seus
requerimentos, padrões e objetivos.
A capabilidade do processo das organizações de nível 2 pode ser resumida como sendo
disciplinada porque o planejamento e o acompanhamento do projeto são estáveis e os
sucessos mais recentes podem ser repetidos. Os processos do projeto estão sob o controle
efetivo do sistema de gestão de projeto, seguindo os planos estabelecidos
2.2.5.1.3 Nível de Maturidade 3: Definido
No nível de maturidade 3, os processos são bem caracterizados e compreendidos,
sendo descritos conforme padrões, procedimentos, ferramentas e métodos. Os processos
padrão de desenvolvimento e manutenção em toda a organização são documentados,
incluindo padrões de gestão, sendo que esses processos são integrados em um todo coerente.
O conjunto de processos padrão, utilizados para estabelecer consistência ao longo de toda a
organização, são estabelecidos e melhorados ao longo do tempo.
A gerência da organização estabelece objetivos de processo baseados neste conjunto
de processos padrão e assegura-se que esses objetivos são seguidos de forma apropriada. Os
projetos adaptam os processos padrão da organização para desenvolver seus próprios
processos, que levam em conta as características únicas do projeto. Um processo bem
definido pode ser caracterizado como possuidor de critérios de disponibilidade, entradas,
padrões e procedimentos para realização do trabalho, mecanismos de verificação (tais como
revisões por pares), saídas e critérios de finalização. Como o processo é bem definido, a
gerência tem uma boa percepção do progresso técnico em todos os projetos.
59
Os processos estabelecidos no nível 3 são utilizados (e alterados, quando apropriado)
para ajudar a gerência e o pessoal técnico a atuar mais efetivamente. Um programa de
treinamento é implementado para garantir que o pessoal e os gerentes tenham os
conhecimentos e as habilidades requeridas para cumprir os papéis a eles designados.
A capabilidade do processo das organizações de nível 3 pode ser resumida como sendo
padrão e consistente porque a engenharia e as atividades de gestão são estáveis e repetíveis.
Dentro de linhas estabelecidas de produtos, o custo, o cronograma e as funcionalidades estão
sob controle e a qualidade é acompanhada.
2.2.5.1.4 Nível de Maturidade 4: Quantitativamente Gerenciado
No Nível de maturidade 4, a organização além de estabelecer metas quantitativas de
qualidade para os produtos e performance de processos, utiliza os mesmos como critério de
gerenciamento: os objetivos quantitativos são baseados nas necessidades dos clientes,
usuários finais, implementadores de processo e a própria organização como um todo. A
produtividade e a qualidade são medidas para as atividades importantes do processo
gerenciamento em todos os projetos, como parte de um programa organizacional de medidas,
com os processos instrumentalizados com medições consistentes e bem definidas. Essas
medições estabelecem a fundamentação para avaliar os processos e os produtos do projeto.
Os projetos conseguem o controle sobre seus produtos e processos reduzindo a
variação no desempenho dos seus processos, para cair em limites quantitativos aceitáveis. A
qualidade e a performance dos processos são compreendidos em termos estatísticos, sendo
gerenciados ao longo de toda a vida dos processos. As variações significativas no
desempenho dos processos podem ser distinguidas das variações aleatórias (ruídos),
particularmente dentro de linhas de produtos estabelecidas. A causa raiz de variações é
identificada e, quando apropriado, são corrigidas de forma a prevenir ocorrências futuras. Os
riscos envolvidos na introdução de um novo domínio de aplicação são conhecidos e
cuidadosamente gerenciados.
A capabilidade do processo das organizações de nível 4 pode ser resumida como sendo
previsível porque o processo é medido e opera dentro de limites mensuráveis. A capabilidade
de processo desse nível permite que a organização preveja as tendências na qualidade dos
60
produtos e dos processos dentro das fronteiras quantitativas desses limites. As medições de
qualidade e performance de processos são incorporadas a um repositório (base de dados) da
organização, de forma a suportar o processo futuro de tomada de decisões baseadas em fatos.
2.2.5.1.5 Nível de Maturidade 5: Em Otimização
No Nível 5 de maturidade, a organização inteira está focada na melhoria contínua da
performance de processo, tanto por melhoria incremental (contínua) como por inovações
tecnológicas. Objetivos mensuráveis de melhoria de processos são estabelecidos,
continuamente revisados para refletir mudanças nos objetivos de negócio e utilizados como
critério na melhoria do processo de gerenciamento. Os dados sobre a efetividade dos
processos são usados para realizar análises de custo benefício das novas tecnologias e das
mudanças propostas.
A organização tem meios para identificar as oportunidades de melhoria e fortalecer o
processo de maneira pró-ativa, com o objetivo de prevenir a ocorrência de falhas. As equipes
de projeto das organizações de nível 5 analisam as falhas para determinar suas causas. Os
processos são avaliados para prevenir tipos conhecidos de falhas que se repetem e as lições
aprendidas são disseminadas para outros projetos.
A otimização de processos velozes e inovativos depende da participação e
empowerment da força de trabalho, alinhada com os objetivos e valores da organização e seus
negócios. A habilidade da organização em responder às mudanças e oportunidades é
alavancada ao serem achadas formas de acelerar e massificar o aprendizado. As inovações
que aproveitam o melhor das práticas de engenharia são identificadas e transferidas para toda
a organização. Melhoria de processos passa a ser parte da atividade de todos, levando a um
ciclo de melhoria contínua.
A capabilidade do processo das organizações de nível 5 pode ser resumida como sendo
melhoria contínua porque as organizações estão continuamente se esforçando para melhorar o
alcance de sua capabilidade de processo, melhorando, por meio disso, o desempenho dos
processos de seus projetos. As melhorias ocorrem por meio de avanços incrementais nos
processos já existentes e por meio de inovações que utilizam novos métodos e tecnologias.
61
2.2.5.2 Áreas de Processo por Nível de Maturidade
O quadro a seguir mostra as áreas de processo correspondentes a cada nível de
maturidade, servindo de base portanto, para o enquadramento da organização no nível
adequado de CMMI:
Áreas de Processo (PA’s) Nível de Maturidade
Gerência de Requisitos
Planejamento do Projeto
Monitoração e Controle do Projeto
Gerência de Acordos com Fornecedores
Medição e Análise
Garantia da Qualidade do Processo e do
Produto
Gerência de Configuração
2
Desenvolvimento de Requisitos
Solução Técnica
Integração do Produto
Verificação
Validação
Foco no Processo Organizacional
Definição do Processo Organizacional
Treinamento Organizacional
Gerência de Projeto Integrada
Gerência de Riscos
Integração da Equipe
Análise de Decisão e Resolução
Ambiente Organizacional para Integração
3
Desempenho do Processo Organizacional
Gerência Quantitativa do Projeto
4
Inovação e Deployment Organizacional
Análise e Resolução de Causas
5
Quadro 2 - Áreas de Processo por Nível de Maturidade
Fonte: Elaboração própria
2.2.5.3 Componentes Requeridos
Estes componentes devem ser alcançados pelos processos de planejamento e
implementação da organização, sendo essenciais para o processo de atingimento dos níveis de
maturidade. O atingimento ou satisfação das metas é utilizado em avaliações como base para
62
atendimento das áreas de processo e determinação do nível de maturidade da organização.
Fazem parte do grupo de componentes requeridos as metas genéricas e específicas. Uma área
de processo é avaliada como “satisfeita” somente se todas as suas metas genéricas e metas
específicas forem avaliadas como “satisfeitas”. Se ao menos uma das metas for avaliada como
“não-satisfeita”, a área de processo será avaliada como “não satisfeita” (SEI, 2001b).
2.2.5.3.1 Metas Genéricas (GG)
As metas genéricas tem esse nome porque a mesma meta aparece em áreas de
processo múltiplas. No caso da representação em estágios, cada área de processo contém uma
única meta genérica. O atingimento da meta genérica em uma área de processo é entendido
como controle de planejamento e implementação dos processos associados com esta área de
processo, indicando portanto que esses processos devem ser efetivos, repetitíveis e
duradouros. A meta genérica que caracteriza o nível de maturidade em cada área de processo
é:
Para nível de maturidade 2: O processo é institucionalizado como um processo
gerenciado (GG 2). Um processo gerenciado é institucionalizado quando:
Adere às políticas organizacionais;
Segue planos estabelecidos e processos descritos;
São providos recursos adequados (incluindo fundos, pessoas e ferramentas);
São designadas responsabilidades e autoridade para executar os processos;
As pessoas que executam e suportam os processos são treinadas;
Os produtos estão em níveis apropriados de gerenciamento de configuração;
As partes interessadas (stakeholders) de relevância são identificadas e
envolvidas;
A performance dos processos é monitorada e controlada contra os planos
estabelecidos e ações corretivas são tomadas;
Os processos, seus subprodutos e serviços são avaliados objetivamente quanto
à aderência às descrições de processos, objetivos e padrões, sendo o não
enquadramento endereçado;
As atividades, status e resultados de processo são revistos com a alta gerência e
ações corretivas são tomadas.
63
Para o nível de maturidade 3 e superiores: O processo é institucionalizado como um
processo definido (GG3). Um processo definido é institucionalizado quando atende todos os
itens citados em GG2 e ainda:
Estabelece a descrição do processo definido para o projeto ou para a unidade
organizacional;
São coletados os produtos, medidas e informações de melhoria derivadas do
planejamento e execução do processo definido.
2.2.5.3.2 Metas Específicas (SG)
As metas genéricas abordam características únicas que descrevem o que deve ser
implementado para satisfazer uma área de processo. São utilizadas em avaliações para
determinar se uma área de processo é satisfeita.
2.2.6 Áreas de Processo Relacionadas a Testes
No modelo CMMI, existem duas áreas direcionadas paras as atividades de testes: Verificação
e Validação.
2.2.6.1 Verificação
As metas, práticas e sub-práticas da área de processo de Verificação do modelo podem ser
identificadas conforme o quadro 3 a seguir:
METAS
ESPECIFICAS /
GENÉRICAS
PRÁTICAS ESPECIFICAS
/ GENÉRICAS
SUB-PRÁTICAS
SG 1 Preparar para a
Verificação
SP 1.1 Selecionar os produtos
para verificação
1. Identificar os produtos para verificação.
2. Identificar os requisitos a serem satisfeitos por cada
produto.
3. Identificar os métodos de verificação que estão
disponíveis para uso.
4. Definir os métodos de verificação que serão usados para
cada produto.
5. Mandar os produtos a serem verificados, os requisitos a
serem satisfeitos e os métodos a serem usados para
integração com o plano de projeto.
SP 1.2 Estabelecer o ambiente
de verificação
1. Identificar os requisitos do ambiente de verificação.
64
2. Identificar os recursos de verificação disponíveis para
reuso e modificação.
3. Identificar os equipamento e ferramentas de verificação.
4. Adquirir equipamento de suporte e ambiente de
verificação, como equipamentos de teste e softwares.
SP 1.3 Estabelecer os
procedimentos e critérios de
verificação
1. Gerar um conjunto de procedimentos de verificação
compreensível e integrado para os produtos e para
qualquer produto comercial, conforme a necessidade.
2. Desenvolver e refinar os critérios de verificação quando
necessário.
3. Identificar os resultados esperados, quaisquer tolerâncias
permitidas na observação e outros critérios para cumprir os
requisitos.
4. Identificar qualquer equipamento e componentes do
ambiente necessários para a verificação.
SG 2 Revisão pelos
participantes
SP 2.1 Preparar revisão pelos
participantes
1. Determinar o tipo de revisão que será conduzida.
2. Definir os requisitos para a coleta de dados durante a
revisão.
3. Estabelecer e manter critérios de entrada e saída para a
revisão.
4. Estabelecer e manter critérios para a requisição de uma
nova revisão.
5. Estabelecer e manter checklists para garantir que os
produtos sejam revisados constantemente.
6. Desenvolver uma agenda de revisão detalhada,
incluindo as datas para o treinamento de como fazer
revisão e de quando o material para revisão estará
disponível.
7. Certificar-se de que o produto cumpre os critérios de
entrada para revisão antes da distribuição.
8. Distribuir o produto para revisão e as informações
relacionadas entre os participantes com uma antecedência
suficiente para que eles se preparem adequadamente para a
revisão.
9. Designar papéis para a revisão apropriadamente.
10. Preparar-se para a revisão dos participantes fazendo
uma revisão do produto antes de conduzir a revisão dos
participantes.
SP 2.2 Conduzir a revisão
pelos participantes
1. Desempenhar os papéis da revisão.
2. Identificar quaisquer defeitos nos documentos e outros
aspectos do produto.
3. Guardar os resultados da revisão, incluindo os itens de
ação.
4. Coletar os dados da revisão pelos participantes.
5. Identificar os itens de ação e levar a questão aos
stakeholders relevantes.
6. Conduzir quaisquer revisões necessárias se os critérios
definidos indicarem a necessidade.
7. Certificar-se de que os critérios de saída da revisão
foram satisfeitos.
SP 2.3 Analisar os dados da
revisão pelos participantes
1. Guardar os dados relacionados a preparação, condução e
resultados das revisões.
2. Guardar os dados para futura referência e análise.
3. Proteger os dados para garantir que não sejam usados
de inapropriadamente.
4. Analisar os dados da revisão.
65
SG 3 Verificar os
produtos selecionados
SP 3.1 Realizar a verificação 1. Verificar se os produtos estão de acordo com seus
requisitos.
2. Guardar os dados das atividades de verificação.
3. Identificar os itens de ação resultantes da verificação
dos produtos.
4. Documentar o método de verificação "as-run" e os
desvios dos métodos e procedimentos disponíveis
descobertos durante a sua realização.
SP 3.2 Analisar os resultados
da verificação e identificar as
ações de correção
1. Comparar os resultados reais aos resultados esperados.
2. Baseando-se nos critérios de verificação estabelecidos,
indentificar os produtos que não cumprem seus requisitos
ou identificar os problemas nos métodos, procedimentos,
critérios e ambiente de verificação.
3. Analisar os dados da verificação sobre os defeitos.
4. Guardar todos os resultados da análise num relatório.
5. Use os resultados da verificação para comparar a
performance real com os parâmetros técnicos de
performance.
6. Prover informação de como os defeitos deverão ser
resolvidos (incluindo os métodos de verificação, critérios e
ambiente de verificação) e formalize num plano.
Quadro 3 - Características da Área de Processo Verificação
Fonte: Elaboração própria
2.2.6.2 Validação
As metas, práticas e sub-práticas da área de processo de Validação do modelo podem ser
identificadas conforme o quadro 4 a seguir:
METAS
ESPECIFICAS /
GENÉRICAS
PRÁTICAS
ESPECIFICAS /
GENÉRICAS
SUB-PRÁTICAS
SG 1 Preparar para a
validação
SP 1.1 Selecionar os
produtos para
validação
1. Identificar os princípios chave, características e fases para a
validação dos produtos ou componentes por meio da vida do
projeto.
2. Determinar quais categoria de necessidades do usuário
(operacionais, de manutenção, de treinamento ou suporte) deverão
ser validadas.
3. Selecionar os produtos e componentes que deverão ser
validados.
4. Selecionar os métodos de validação para os produtos e
componentes.
5. Revisar a seleção de validações, restrições e métodos relevantes
com os stakeholders.
SP 1.2 Estabelecer o
ambiente de validação
1. Identificar os requisitos do ambiente de validação.
2. Identificar os produtos fornecidos pelos clientes.
3. Identificar ops itens de reuso.
4. Identificar os equipamentos e ferramentas de teste.
66
5. Identificar os recursos de validação que estarão disponíveis para
reuso e modificação.
6. Planejar a disponibilidade de recursos detalhadamente.
SP 1.3 Estabelecer os
procedimentos e
critérios de validação
1. Revisar os requisitos do produto para garantir que as questões
que afetam a validação do produto e seus componentes foram
identificadas e resolvidas.
2. Documentar o ambiente, o cenário operacional, os
procedimentos a entrada, a saída e os critérios para a validação od
produto ou componente selecionado.
3. Avalie o projeto durante sua maturação no contexto do ambiente
de validação para identificar as questões de validação.
SG 2 Validar Produtos ou
Componentes do Produto
SP 2.1 Realizar a
validação
1. Relatórios de validação.
2. Resultados de validação.
3. Matriz de referência cruzada da validação.
4. Log de procedimento "como executar".
5. Demonstrações operacionais.
SP 2.2 Analisar os
resultados da
validação
1. Comparar resultados obtidos com os esperados.
2. Baseando-se nos critérios de validação estabelecidos, identificar
os produtos e componentes que não tiveram a performance
desejada no seu ambiente de operação, ou identificar problemas
nos métodos, critérios e ou ambiente.
3. Analisar os dados de validação sobre os defeitos.
4. Registrar os resultados das analises e identificar os casos a serem
tratados
5. Usar os resultados da validação para comparar as medições
feitas e performance obtida com o uso pretendido ou necessidades
operacionais.
Quadro 4 - Características da Área de Processo Validação
Fonte: Elaboração própria
67
2.3 QUALIDADE EM SERVIÇOS - PESQUISA PARASURAMAN ET AL.
Em 1983, A. Parasuraman, Valarie A. Zeithaml e Leonard L. Berry iniciaram um
estudo sobre a qualidade do serviço, interessados em responder às seguintes questões:
O que é qualidade do serviço?
Quais são as causas dos problemas na qualidade dos serviços?
Que podem fazer as organizações para resolver esses problemas e melhorar seus serviços?
O estudo consistiu em quatro fases:
A fase I consistiu em um estudo qualitativo do serviço aos clientes e aos executivos de
empresas de serviços que, como resultado, permitiu desenvolver o modelo conceitual de
qualidade do serviço.
A fase II consistiu num estudo empírico em grande escala que se centrou no ponto de
vista do cliente no modelo de qualidade do serviço desenvolvido na fase I, desenvolvendo-se
a partir desta fase, uma metodologia para medir a qualidade do serviço, a "SERVQUAL".
A fase III consistiu num estudo empírico centrado na outra metade do modelo de
qualidade do serviço, os fornecedores do serviço.
As fases I, II e III foram compostas de entrevistas, sessões de grupo com clientes,
sessões de grupo para empregados, entrevistas em profundidade com executivos, estudos do
consumidor, sondagens a diretores e empregados da linha de frente de atendimento ao
público. Essas fases foram realizadas em seis áreas do setor de serviços: conserto e
manutenção de equipamentos, cartões de crédito, companhias de seguros, ligações telefônicas
de longa distância, serviços bancários e corretagem de valores.
A fase IV centrou-se nas expectativas que os clientes têm sobre o serviço, a forma
como os usuários criam suas expectativas e os fatores-chave que afetam o processo. Incluem-
se nesta fase outros serviços, que não haviam sido incluídos nas fases anteriores, tais como:
serviços automotores, serviços de equipamento industrial, hotéis e aluguéis de caminhões.
68
Parasuraman et al. (1985) consideram algumas contribuições centradas na qualidade
dos serviços:
Para o usuário, a qualidade do serviço é mais difícil de avaliar que a qualidade dos
produtos tangíveis. Em conseqüência, é possível que os critérios que os usuários utilizam
para avaliar a qualidade do serviço sejam mais difíceis de compreender para o pessoal de
marketing.
Os usuários avaliam a qualidade de um serviço não só valorando o resultado final que
recebem como também levando em consideração o processo de recepção do serviço.
Os únicos critérios que realmente contam na avaliação da qualidade de um serviço são os
que estabelecem os clientes. Só os usuários julgam a qualidade; todos os demais juízos são
essencialmente irrelevantes.
De modo mais específico, “a percepção da qualidade do serviço se estabelece, em
função de quão bem o fornecedor realiza a prestação, avaliada em contraste com as
expectativas que tinha o cliente com respeito ao que esperava que realizasse o fornecedor”.
2.3.1 O Consumidor e a Qualidade do Serviço
Na primeira fase da investigação exploratória, foi selecionada uma ampla amostra de
usuários de serviços de quatro empresas de serviços: banco de varejo, cartões de crédito,
corretagem de valores, conserto e manutenção de equipamentos (Parasuraman et al., 1985).
O objetivo era lograr uma visão sobre a qualidade do serviço que fosse
suficientemente profunda e que, ao mesmo tempo, não fosse limitada a um único setor da área
de serviços.
Os resultados dessa primeira fase apresentaram certos padrões nas respostas dos
entrevistados que ajudaram a definir a qualidade do serviço, os fatores que influem nas
expectativas e os critérios de avaliação da qualidade do serviço, como mostra a figura 11.
69
Critérios sobre a
qualidade do
serviço
Elementos
tangíveis
Confiabilidade
Capacidade de
resposta
Profissionalismo
Cortesia
Credibilidade
Segurança
Acessibilidade
Comunicação
Compreensão do
cliente
Comunicação
boca a ouvido
Necessidades
pessoais
Experiências Comunicações
externas
Serviço
esperado
Serviço
percebido
Qualidade
Percebida
do
Serviço
Figura 11 - Avaliação do cliente sobre a Qualidade do Serviço.
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service.
New York: The Free Press, 1990
2.3.2 Definição de Qualidade do Serviço.
Os resultados da primeira fase mostraram que os clientes consideram que o fator-
chave para lograr um alto nível de qualidade no serviço é igualar ou superar as expectativas
que têm em relação ao serviço.
Zeithaml et al. (1990) definem a qualidade do serviço do ponto de vista do cliente
como: “a amplitude da discrepância ou diferença que exista entre as expectativas ou desejos
dos clientes e suas percepções”.
2.3.3 Fatores que influenciam as expectativas.
Os resultados da primeira fase mostraram que os fatores que influenciam as
expectativas dos clientes são os seguintes:
O que os usuários escutam de outros usuários - comunicação boca a ouvido - constitui um
dos fatores potenciais na determinação das expectativas.
70
As expectativas dos usuários mostram variações dependendo das suas características e
circunstâncias individuais, o que sugere que as necessidades pessoais dos clientes podem,
até certo ponto, condicionar suas expectativas.
A extensão das experiências que se tem com o uso do serviço pode influenciar o nível das
expectativas dos clientes.
A comunicação externa dos fornecedores do serviço tem um papel-chave na conformação
das expectativas dos clientes.
O preço do serviço também é importante formador de expectativas que pode ser
incluído na categoria geral de comunicação externa, já que os consumidores de serviços
geralmente associam os níveis de suas expectativas aos níveis de preços praticados pelo
fornecedor.
Segundo Zeithaml et al. (1990), um fator que influi nas expectativas e que subjaz na
influência geral da comunicação externa é o preço. Esse fator tem um importante papel em
ajustar as expectativas particularmente aos clientes potenciais de um serviço.
2.3.4 Dimensões da Qualidade do Serviço.
Os resultados da primeira fase mostraram que dez critérios gerais foram usados pelos
clientes para julgar a qualidade do serviço:
1. Elementos tangíveis: aparência das instalações físicas, dos equipamentos, do pessoal e
dos materiais de comunicação.
2. Confiabilidade: execução do serviço de forma confiável, precisa e cuidadosa.
3. Capacidade de Resposta: disposição em ajudar os clientes e provê-los de um serviço
rápido.
4. Profissionalismo: habilidades requeridas e conhecimento sobre a execução do serviço.
5. Cortesia: atenção, consideração, respeito e amabilidade do pessoal de contato.
6. Credibilidade: veracidade, crença, honestidade no serviço que se provê.
7. Segurança: minimização de perigos, riscos e dúvidas.
8. Acessibilidade: facilidade de acesso ao pessoal de contato.
9. Comunicação: capacidade de escutar verdadeiramente os clientes e de e mantê-los
informados, utilizando uma linguagem que possam entender.
71
10. Compreensão do cliente: busca do conhecimento dos clientes e de suas necessidades.
Zeithaml et al. (1990) argumentam que a colocação dos dez critérios gerais da
qualidade do serviço é exaustiva e apropriada para avaliar a qualidade em uma ampla
variedade de serviços.
Estudos estatísticos posteriores na estruturação do SERVQUAL - ver item 3.1.3,
adiante - mostraram uma importante correlação entre os critérios, concluindo que eles podem
ser representados por apenas cinco dimensões. As correlações sugeriram a consolidação dos
últimos sete critérios dentro de duas amplas dimensões denominadas segurança e empatia, os
critérios restantes permaneceram sem mudanças, como mostra a tabela 4.
Tabela 4 - Quadro de correspondência entre as dimensões do SERVQUAL e os dez critérios
iniciais de avaliação da Qualidade do Serviço
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service. New York:
The Free Press, 1990
As cinco dimensões foram definidas da seguinte maneira:
11. Elementos tangíveis: aparência das instalações físicas, equipamento, pessoal e
materiais de comunicação.
72
12. Confiabilidade: habilidade para realizar o serviço de forma confiável precisa e
consistente.
13. Capacidade de resposta: disposição e vontade para ajudar os clientes e proporcionar o
serviço prontamente.
14. Segurança: conhecimentos e atenção mostrados pelos empregados e suas habilidades
para transmitir confiança, segurança e credibilidade.
15. Empatia: atenção individualizada, facilidade de contato (acesso) e comunicação que as
empresas oferecem aos clientes.
Zeithaml et al. (1990) afirmam que o conteúdo dos itens finais que integram as duas
novas dimensões - ver Tabela 11, acima -, segurança e empatia, também representam as
caraterísticas-chave dos sete critérios anteriormente considerados. Em conseqüência, ainda
que o SERVQUAL tenha só cinco dimensões diferenciadas, essas incluem todas as facetas
dos dez critérios que originalmente foram definidos. Os itens resultantes dos critérios
consolidados também fornecem definições concisas desses.
2.3.5 Modelo Conceitual da Qualidade do Serviço
Baseados nos resultados obtidos na fase exploratória da primeira fase, aplicada nos
níveis gerenciais de quatro empresas pertencentes aos quatro setores de serviços com os que
se realizaram as sessões de grupo: banco de varejo, cartões de crédito, corretagem de valores e
reparação e manutenção de equipamentos, surgiram certos padrões notavelmente consistentes
que ofereceram insights importantes com respeito às medidas que deveriam ser tomadas para
lograr um controle de qualidade eficaz nos serviços.
Esses insights foram distribuídos em quatro classes de discrepâncias ou hiatos que se
relacionam com as percepções que os executivos têm sobre a qualidade dos serviços e as
funções associadas com a sua prestação aos clientes.
O modelo proposto por Parasuraman et al. (1988) vincula as discrepâncias que os
clientes percebem na qualidade dos serviços - hiato 5 - com as discrepâncias internas que
existem nas empresas fornecedoras de serviços - hiato 1 a hiato 4.
73
Portanto, segundo Parasuraman et al. (1988) a qualidade do serviço é percebida pelos
consumidores como uma função do tamanho e direção da discrepância 5 que, por sua vez, é
função das discrepâncias associadas às especificações, marketing e prestação de serviços.
Qualidade do Serviço = f (Hiato 5) = f (P-E)
Qualidade do Serviço = f (Hiato 5) = f (P-E)
Hiato 5 = f (hiato 1, hiato 2, hiato 3, hiato 4)
Hiato 5 = f (hiato 1, hiato 2, hiato 3, hiato 4)
onde P = Percepção e E = Expectativa
A figura 12 apresenta o modelo conceitual de qualidade do serviço proposto por
Parasuraman et al. (1988).
Comunicação
boca a ouvido
Necessidades
pessoais
Experiências
Serviço Esperado
Serviço Percebido
Comunicação
externa aos
clientes
Percepções dos
gerentes sobre as
expectativas dos
clientes
Prestação do
Serviço
Especificações da
qualidade do
serviço
CLIENTE
FORNECEDOR
Hiato 5
Hiato 2
Hiato 3
Hiato 4
Hiato 1
Figura 12 - Modelo conceitual da Qualidade do Serviço.
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service. New
York: The Free Press, 1990
74
Hiato 1: Discrepância entre as expectativas dos usuários e as percepções da gerência
Ocorre porque os gerentes das empresas nem sempre são cientes das características
que indicam, para os clientes, uma alta qualidade do serviço. É possível que não conheçam
algumas características fundamentais do serviço que são capazes de satisfazer o desejo dos
usuários; ou, mesmo estando cientes delas, é possível que não conheçam o nível de atuação
que os usuários desejam no que diz respeito a essas características.
Zeithaml et al. (1990) argumentam que a compreensão deficiente por parte dos
gerentes das expectativas e preocupações autênticas dos usuários, com muita probabilidade
provocará que o serviço que se presta não satisfaça plenamente suas expectativas - hiato 5.
Portanto, o primeiro e imprescindível passo no aperfeiçoamento da qualidade dos
serviços, isto é, a redução do hiato 5, consiste em que a gerência da empresa adquira
suficiente informação sobre as expectativas dos usuários, que lhe permita diminuir as
discrepâncias ocasionadas pelo hiato 1.
As principais razões para que se produzam essas discrepâncias são:
Inexistência de uma cultura orientada à pesquisa de marketing evidenciada por:
Insuficiente pesquisa de marketing.
Uso inadequado dos resultados dessas pesquisas de marketing.
Falta de interação entre os gerentes e os usuários.
16. Inadequada comunicação vertical ascendente.
17. Excessivos níveis hierárquicos de mando.
Hiato 2: Discrepância entre as percepções dos gerentes e as especificações ou normas de
qualidade
Ocorre quando existem dificuldades para converter as percepções dos gerentes sobre
as expectativas dos usuários em especificações ou normas de qualidade do serviço.
75
Segundo Zeithaml et al. (1990), quando não existem normas padrão para a prestação
do serviço ou quando as normas que se aplicam não refletem as expectativas do consumidor, a
qualidade do serviço é percebida pelos clientes de maneira inadequada. Pelo contrário,
quando existem normas que refletem o que os usuários esperam, é muito provável que a
percepção da qualidade se incremente.
Em conseqüência, diminuir a dimensão do hiato 2 estabelecendo normas que
respondam às expectativas dos clientes deve produzir um impacto favorável nas expectativas
que têm os clientes sobre a qualidade do serviço.
As principais razões para que se produza essa discrepância são:
18. Deficiências no compromisso que assume a direção com a qualidade do serviço.
19. Percepção de inviabilidade.
20. Erros no estabelecimento das normas ou padrões para a execução das tarefas.
21. Ausência de objetivos.
Hiato 3: Discrepância entre as especificações da qualidade do serviço e a prestação do
serviço
Ocorre quando o processo de prestação do serviço não cumpre as especificações ou
normas da qualidade do serviço, estabelecidas pelos gerentes.
Segundo Zeithaml et al. (1990), quando a prestação do serviço não cumpre com as
normas - hiato 3 - tampouco cumprirá com as expectativas dos usuários quanto à qualidade do
serviço - hiato 5. A relação direta e implícita entre os hiatos 3 e 5 sugere que a diminuição do
hiato 3 - assegurando-se que se utilizem todos os recursos para lograr que as normas se
implantem - deveria reduzir o hiato 5.
As principais razões para explicar essa discrepância são:
Ambigüidade das funções.
22. Conflitos funcionais.
76
23. Desajuste entre os empregados e suas funções.
24. Desajuste entre a tecnologia e suas funções.
25. Sistemas inadequados de supervisão e controle.
26. Falta de controle percebido.
27. Falta de sentido de trabalho em equipe.
Hiato 4: Discrepância entre a prestação do serviço e a comunicação externa
Esta discrepância reflete a ruptura entre a coordenação que deve existir entre os
responsáveis por prestar os serviços e os responsáveis por sua descrição/promoção.
Quando esses últimos não entendem a realidade da prestação do serviço, podem cair
na tentação de fazer promessas exageradas ou não comunicar aos clientes os aspectos que se
têm incorporado ao serviço para servir-lhes melhor, tendo como resultado uma baixa
percepção da qualidade do serviço.
Zeithaml et al. (1990) afirmam que as comunicações externas podem não só afetar as
expectativas do usuário sobre o serviço em si, como também sua percepção sobre a prestação
do mesmo serviço. As discrepâncias entre a prestação de um serviço e as comunicações
externas que fazem sobre ela afetam negativamente a avaliação que os clientes fazem sobre a
qualidade do serviço.
O hiato 4 poderá ser reduzido por meio de uma coordenação eficaz das características
reais da prestação do serviço com sua comunicação externa e, em conseqüência, também
ficará reduzido o hiato 5.
Os fatores causais dessa discrepância são:
28. Deficiências na comunicação horizontal.
29. Tendência a prometer em excesso.
77
Hiato 5: Discrepância entre as expectativas do serviço e o serviço percebido.
Este hiato representa as discrepâncias potenciais que podem existir, do ponto de vista
do cliente, entre o serviço esperado e o serviço percebido.
Em conseqüência, podemos afirmar que o elemento-chave para diminuir o hiato 5
consiste em diminuir os hiatos 1 a 4 e mantê-los no nível mais baixo possível, já que na
medida em que existem hiatos - 1 a 4 - os usuários percebem quedas na qualidade do serviço.
Baseado no modelo conceitual das cinco deficiências, foi desenvolvido o modelo que
mostra o processo lógico que as empresas poderiam empregar para medir e melhorar a
qualidade de seus serviços. Ver figura 14.
Pode-se observar que o processo começa pela compreensão da natureza e da dimensão
do hiato 5 e passa pela identificação de evidências relativas à existência dos hiatos 1 a 4, para
então iniciar as correções que sejam necessárias.
Zeithaml et al. (1990) esquematizam o resultado de seus estudos em um modelo
ampliado das discrepâncias da qualidade do serviço, em que se apresentam as deficiências da
qualidade do serviço, suas causas e as dimensões que os clientes consideram na avaliação da
qualidade do serviço, como mostra a figura 5.
Cabe assinalar que a presente pesquisa só vai analisar os hiatos 1 e 5 do modelo
conceitual da Qualidade do Serviço.
2.3.6 SERVQUAL: Um Instrumento para Medir a Qualidade do Serviço
Com base na definição conceitual da qualidade em serviços e nos dez critérios
encontrados na investigação exploratória, foi feita uma fase quantitativa com a finalidade de
desenvolver um instrumento que permitisse medir as percepções dos usuários sobre a
qualidade do serviço - SERVQUAL. (Parasuraman et al., 1988)
78
SIM
NÃO
SIM
NÃO
SIM
NÃO
Percebem seus consumidores
que suas ofertas igualam ou
superam suas expectativas?
Você tem um conhecimento
correto sobre o que seus clientes
esperam?
Existem normas padrão para
satisfazer as expectativas dos
usuários?
Suas ofertas igualam ou superam
essas normas?
Está certa a informação que
comunica a seus clientes suas
ofertas?
Continue controlando as
expectativas e as
percepções dos usuários
Corrija
Corrija
Corrija
Corrija
SIM
NÃO
NÃO
SIM
Figura 13 - Modelo do processo para a medição e aperfeiçoamento contínuos da Qualidade do
Serviço.
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service. New
York: The Free Press, 1990
79
Compromisso que assume
a direção com a qualidade
do serviço
Objetivos
Estabelecimento de
normas padrão para a
execução de tarefas
Falta de sentido de
trabalho em equipe
Percepção de inviabilidade
Ambigüidade das funções.
Desajuste entre a
tecnologia e suas funções
Sistemas inadequados de
supervisão e controle
Falta de controle percebido
Desajuste entre os
empregados e suas
funções
Conflitos funcionais
Comunicação descendente
Propensão a prometer em
excesso
Hiato 1
Hiato 4
Hiato 2
Hiato 5
(Qualidade do
serviço)
Elementos tangíveis
Confiabilidade
Capacidade de resposta
Segurança
Empatia
Cultura orientada à
investigação
Comunicação ascendente
Níveis de comando
Hiato 3
Figura 14 - Modelo ampliado das discrepâncias na Qualidade do Serviço.
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service. New
York: The Free Press, 1990
Essa investigação abrangeu o estudo de usuários de cinco diferentes setores de
serviços: reparação e manutenção de equipamentos, banco de varejo, ligações de longa
distância, corretores de valores e cartões de crédito.
O instrumento (SERVQUAL) compreende 2 seções:
uma referente às expectativas, que contém 22 declarações dirigidas a identificar as
expectativas gerais dos usuários em relação ao serviço; e
80
uma referente às percepções, que contém 22 declarações para medir a percepção da
qualidade do serviço relativa a uma determinada empresa da categoria de serviços
analisada.
2.3.6.1 Desenvolvimento do SERVQUAL
Com base na recopilação de dados e em várias análises que incluíam os dez critérios
da qualidade do serviço identificados na fase exploratória, foram desenvolvidos 97 itens.
Cada item foi condensado em pares de declarações, uns para medir as expectativas,
com respeito à generalidade das empresas que se situam dentro da categoria do serviço que
está sendo pesquisada, e os outros para medir as percepções, com respeito à empresa em
particular cuja qualidade do serviço esteja sendo investigada.
Cada declaração foi posta na escala de Likert de 7 pontos, que vai de 1 (discordo
muito) até 7 (concordo muito).
Após essa primeira fase de 97 itens, foram feitos vários processos de depuração para
eliminar itens que demonstraram ser incapazes de discriminar com precisão entre os
entrevistados com diferentes percepções da qualidade com respeito às empresas avaliadas.
A informação obtida dos questionários foi trasladada a uma pontuação que mostra a
valoração "percepção menos expectativas" para os diferentes itens. Pontuação que vai desde
+6 até -6, sendo as pontuações positivas maiores as que representam uma qualidade melhor
do serviço percebida. Analisando as diferenças de pontuação recorrendo a diversas análises
estatísticas, foi possível eliminar aproximadamente duas terças partes dos itens selecionados a
princípio e consolidar alguns critérios que mostraram um alto nível de coincidência em vários
critérios novos e combinados.
Parasuraman et al. (1988) verificaram a confiabilidade e validade da escala
condensada, aplicando-a a quatro amostras independentes de aproximadamente 190 usuários
cada. A análise de dados proveniente das quatro amostras permitiu depurar ainda mais o
instrumento e confirmar sua confiabilidade e validade, chegando esse instrumento a conter 22
declarações que incluem as cinco dimensões da qualidade dos serviços: elementos tangíveis,
81
confiabilidade, capacidade de resposta, segurança e empatia. As declarações para cada uma
das dimensões são apresentadas no Tabela 12, a seguir.
2.3.6.2 Resultados da aplicação do SERVQUAL
Zeithaml et al. (1990) afirmam que as cinco dimensões SERVQUAL conformam uma
representação precisa das dimensões que os usuários utilizam para avaliar a qualidade dos
serviços já que constituem o resultado da análise sistemática das avaliações realizadas com
centenas de entrevistados em vários setores do serviço. Em conseqüência, é razoável concluir
que os usuários poderiam considerar muito importantes as cinco dimensões sem excluir
nenhuma.
Tal como se pode observar na tabela 4, os entrevistados dos quatro setores avaliaram a
importância das dimensões SERVQUAL numa escala de 1 - nada importante - e 10 - muito
importante - e a dimensão mais importante em sua avaliação da qualidade de um serviço. A
pesquisa foi feita em quatro setores de serviços: cartões de crédito, reparação e manutenção de
equipamento, ligações de longa distância e banco de varejo.
Tabela 5 - Declarações para cada uma das dimensões de avaliação da Qualidade do Serviço
Dimensões
De Avaliação
Declarações
Elementos
Tangíveis
Têm equipamentos mais avançados tecnologicamente
Têm as instalações físicas visualmente atraentes
Têm empregados de boa aparência – bem vestidos, limpos e organizados
Têm elementos materiais relacionados com o serviço (folhetos, manuais
etc.) visualmente atraentes
Confiabilidade
Quando marcam algo para uma certa data, o fazem
Quando os clientes têm um problema, mostram um sincero interesse em
resolvê-lo
Realizam bem o serviço da primeira vez
Concluem o serviço no tempo prometido
Insistem em manter um histórico de trabalhos sem erros
Capacidade de
Resposta
Têm empregados que comunicam aos clientes quando se concluirá a
realização do serviço
Têm empregados que prestam um serviço mais rápido a seus clientes
Têm empregados que sempre estão dispostos a ajudar os clientes
Têm empregados que nunca estão muito ocupados para responder às
82
perguntas dos clientes
Segurança
Têm empregados que transmitem, por seu comportamento, confiança aos
clientes
Fazem que o cliente se sinta seguro em suas transações com a organização
Têm empregados que são sempre amáveis com os clientes
Têm empregados com conhecimentos suficientes para responder às
perguntas dos clientes
Empatia
Dão aos seus clientes um atendimento individual
Têm horários de trabalho mais convenientes para todos os clientes
Têm empregados que oferecem um atendimento personalizado aos seus
clientes
Preocupam-se pelos melhores interesses de seus clientes
Têm empregados que compreendem as necessidades específicas de seus
clientes
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service.
New York: The Free Press, 1990
Os valores mais altos - na escala de 10 pontos - foram assinalados para confiabilidade,
responsividade e segurança. No entanto, a empatia obteve uma qualificação acima de nove
nas quatro áreas de serviço e a dimensão de elementos tangíveis com pontuação mais baixa
em comparação com as outras dimensões, encontra-se na parte superior da escala de 10
pontos. Pode-se observar também que a confiabilidade foi considerada a dimensão mais
importante quando se avalia a qualidade dos serviços e que os elementos tangíveis são menos
importantes.
Tabela 6 - Importância das dimensões SERVQUAL em quatro setores de serviços
83
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service.
New York: The Free Press, 1990
Estudos posteriores, baseados nas respostas de 1936 usuários e aplicados em 5
empresas de serviços (dois bancos, duas companhias de seguros e uma empresa de ligações de
longa distância), mostram a importância que percebem os usuários em cada uma das cinco
dimensões, utilizando uma escala de 1 a 100 pontos. Ver figura 6.
Pode-se observar que a dimensão mais importante é a confiabilidade, seguida de
capacidade de resposta, segurança e empatia. Já a dimensão elementos tangíveis é considerada
de menor importância relativa.
Esses estudos permitiram concluir que, ainda quando possível, a qualificação relativa
das dimensões varia em função das percepções dos usuários. A preocupação número um dos
usuários de hoje em dia, à margem do tipo de serviço, refere-se à confiabilidade; e, em termos
gerais, a dimensão que tem menor importância para os usuários na avaliação da qualidade dos
serviços é a dos elementos tangíveis (Zeithaml et al., 1990).
84
Importância Relativa das Dimensões
SERVQUAL
11%
32%
22%
19%
16%
Elementos Tangiveis
Confiabilidade
Rapidez na Resposta
Segurança
Empatia
Gráfico 2 - Importância relativa das dimensões SERVQUAL quando os usuários utilizaram
uma escala de 100 pontos.
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service.
New York: The Free Press, 1990
Baseados na mesma amostra, os resultados das cinco empresas pesquisadas
mostraram, em relação à pontuação SERVQUAL para o Hiato 1 (percepção - expectativa) em
cada uma das cinco dimensões sobre o total da amostra de usuários o seguinte (ver figura 7).
Pode-se observar do ponto de vista dos clientes as deficiências na qualidade do
serviço. Observa-se que a dimensão mais importante, Confiabilidade, tem a pontuação mais
baixa em SERVQUAL e a segunda dimensão mais importante, Capacidade de Resposta, tem
a segunda pontuação mais baixa.
A dimensão menos importante, elementos tangíveis, mostra uma pontuação positiva
em SERVQUAL, o que quer dizer que as empresas pesquisadas superam em média, as
expectativas nessa dimensão.
-2,00
-1,50
-1,00
-0,50
0,00
0,50
1,00
Elem entos
Tangiveis
Confiabilidade Capacidade de
Resposta
Segurança Em patia
85
Gráfico 3 - Média das pontuações de SERVQUAL em função das dimensões sobre o serviço
(n=1.936)
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service. New
York: The Free Press, 1990.
Da mesma maneira, foi aplicado o questionário SERVQUAL aos membros da direção
das empresas pesquisadas para a medição do Hiato 1 (discrepâncias entre as expectativas dos
clientes e as percepções dos gerentes sobre essas expectativas). Os resultados são mostrados
na tabela 2.
Pode-se observar que, para a dimensão elementos tangíveis, existe uma diferença
considerável em comparação às outras dimensões, na percepção das expectativas por parte da
direção. Nos critérios Confiabilidade, Capacidade de Resposta e Segurança, a percepção do
pessoal diretivo foi significativamente mais precisa que no critério de empatia. Mas, no nível
geral, as avaliações tanto dos clientes como da direção não mostraram diferenças
consideráveis.
Tabela 7 - Comparação das expectativas dos clientes com as percepções dessas expectativas
pelo pessoal de direção
Fonte: Zeithaml, V. A.; Parasuraman, A.; Berry L. L. Delivering Quality Service. New York:
The Free Press, 1990
2.3.6.3 Validação do SERVQUAL.
Desde a sua publicação em 1988, o SERVQUAL não esteve isento de críticas.
Diversos autores têm questionado a validade do modelo e a existência de certos problemas na
aplicação, propondo modelos alternativos. Já os autores do SERVQUAL têm revisado o
questionário e o modelo de qualidade do serviço, respondendo às criticas e sugestões
apresentadas por diversos autores.
86
Cronin e Taylor (1992, 1994) propõem um instrumento de medição alternativo, a
escala SERVPERF, a qual está composta dos 22 itens da escala SERVQUAL, utilizados
exclusivamente para medir as percepções do serviço. Já Parasuraman et al. (1994a)
ratificaram seu modelo com base na diferença entre percepções e expectativas.
Buttle (1996) realiza dois tipos de críticas, teóricas e operacionais. Entre as críticas
teóricas, menciona o paradigma em que se baseia o SERVQUAL, a utilização de diferenças
entre percepção e expectativas como base para a avaliação do serviço, a orientação ao
processo e não ao resultado do serviço e o número de dimensões.
Entre as críticas operacionais, faz referência às expectativas, o número de itens na
escala, a influência dos momentos de verdade na avaliação da qualidade do serviço, a
confusão que origina duplicar as perguntas para as expectativas e percepções e a escala
utilizada, entre outras.
Com respeito ao paradigma em que se baseia o SERVQUAL, Teas (1993, 1994) e
Cronin e Taylor (1992, 1994), questionam a relação causa-efeito entre qualidade do serviço e
satisfação do consumidor e sobre ambas na intenção de compra. Parasuraman et al. (1994)
propõem a realização de mais pesquisas sobre o assunto e a hipótese a ser testada numa
relação causa-efeito de satisfação do consumidor e qualidade do serviço.
Outros autores têm defendido o uso do SERVQUAL na avaliação da qualidade do
serviço. Bigné et al. (1997) realizaram um estudo comparativo para comparar a confiabilidade
dos instrumentos SERVQUAL e SERVPERF, assim como a universalidade das cinco
dimensões de avaliação da qualidade do serviço. Suas conclusões foram que as cinco
dimensões analisadas podem ser universais para medir a qualidade do serviço e que a escala
SERVQUAL é mais confiável que a SERVPERF pelo menos nos serviços que foram objeto
de estudo - hospitais e universidades.
As diversas críticas e defesas do modelo de avaliação da qualidade do serviço, tanto
teóricas como operacionais, e o uso do SERVQUAL, têm demonstrado o interesse dos
pesquisadores, o que faz que esses conceitos estejam num processo de melhoria, sendo cada
vez mais utilizados em diversas áreas.
87
2.4 NORMA ISO/IEC 9126 (ISO, 2001)
2.4.1 ISO/IEC 9126
Convém que a qualidade de produtos de software seja avaliada usando um modelo de
qualidade definido e que este modelo seja usado durante o estabelecimento de metas de
qualidade para produtos de software finais e intermediários (ISO,2001). A série de normas
ISO/ IEC 9126 (NBR 13596) descreve um modelo de qualidade para produtos de software
categorizando a qualidade hierarquicamente em um conjunto de características e
subcaracterísticas que devem ser atendidas para que o produto seja dito de qualidade. Esta
série também propõe métricas que podem ser utilizadas durante a avaliação dos produtos de
software (medição, pontuação e julgamento dos produtos de software).
A série de normas ISO/IEC 9126 pode ser aplicada nas seguintes ocasiões:
Definição dos requisitos de qualidade de um produto de software;
Avaliação das especificações do software durante o desenvolvimento para verificar se
os requisitos de qualidade estão sendo atendidos;
Descrição das características e atributos do software implementado, por exemplo, nos
manuais de usuário;
Avaliação do software desenvolvido antes da entrega ao cliente.
A série de normas ISO/IEC 9126 é dividida em quatro partes:
ISO/ IEC 9126- 1 - Modelo de qualidade – Define um modelo de qualidade para produtos
de software, apresentando um conjunto de características de qualidade e suas respectivas
sub- características;
ISO/ IEC 9126- 2 - Métricas externas – Apresenta métricas externas para medir os
atributos das características de qualidade definidas na ISO/ IEC 9126- 1. Estas métricas
representam a perspectiva externa da qualidade do produto de software quando o mesmo
já está pronto para execução;
ISO/ IEC 9126- 3 - Métricas internas – Apresenta métricas internas para medir os
atributos das características de qualidade definidas na ISO/ IEC 9126- 1. Estas métricas
representam a perspectiva interna da qualidade
88
do produto de software e estão associados a produtos intermediários, como projeto e código;
ISO/ IEC 9126- 4 - Métricas de qualidade em uso – Apresenta métricas de qualidade
em uso para medir os atributos das características de qualidade definidas na ISO/ IEC
9126- 1. Estas métricas representam a perspectiva do usuário para a qualidade do
produto de software.
Figura 15 - Estrutura da série de normas ISO/IEC 9126
Fonte: ISO (2001)
2.4.2 ISO/IEC 9126-1
A primeira parte da norma ISO/IEC 9126 (NBR 13596) descreve um modelo de qualidade do
produto de software, composto de duas partes: a) qualidade interna e qualidade externa e b)
qualidade em uso. A primeira parte do modelo especifica seis características para qualidade
interna e externa, as quais são por sua vez subdivididas em sub- características. Estas sub-
características são manifestadas externamente, quando o software é utilizado como parte de
um sistema computacional, e são resultantes de atributos internos do software. Esta parte da
norma não apresenta o modelo de qualidade interna e externa além do nível de sub-
características.
A segunda parte do modelo especifica quatro características de qualidade em uso, mas não
apresenta o modelo de qualidade em uso além do nível de característica. Qualidade em uso é o
efeito combinado das seis características de qualidade do produto de software.
Esta parte da norma ISO/ IEC 9126 (NBR 13596) permite que a qualidade do produto de
software seja especificada e avaliada em diferentes perspectivas pelos envolvidos com
aquisição, requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia de
qualidade e auditoria de software. Assim, pode ser utilizada por adquirentes, desenvolvedores,
89
responsáveis pela garantia da qualidade e avaliadores independentes, responsáveis por
especificar e avaliar qualidade do produto de software.
2.4.1.1 Modelo de qualidade para qualidade externa e interna
O modelo de qualidade externa e interna categoriza os atributos de qualidade de software em
seis características (funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e
portabilidade) as quais são, por sua vez, subdivididas em subcaracterísticas. As sub-
características podem ser medidas por meio de métricas externas e internas.
Figura 16 - Modelo de qualidade interna e externa segundo a ISO/IEC 9126- 1
Fonte: ISO (2001)
Cada característica e sub-característica do software, que influenciam a característica de
qualidade, possui uma definição. Para cada característica e sub- característica, a capacidade
do software é determinada por um conjunto de atributos internos que podem ser medidos.
Exemplos de métricas internas são dados na norma ISO/ IEC 9126-3. As características e sub-
características podem ser medidas externamente pelo grau da capacidade do sistema contendo
o software. Exemplos de métricas externas são dados na norma ISO/IEC 9126- 2 .
As características pretendem abranger todos os aspectos de qualidade de software, de forma
que se possa especificar qualquer requisito de qualidade utilizando uma das seis
características.
90
Definição das características e sub- características de qualidade interna e externa
segundo a ISO/IEC 9126- 1:
Funcionalidade: capacidade do produto de software de prover funções que atendam às
necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições
específicas.
Adequação: capacidade do produto de software de prover um conjunto apropriado de
funções para tarefas e objetivos do usuário especificados.
Acurácia: capacidade do produto de software de prover, com o grau de precisão
necessário, resultados ou efeitos corretos ou conforme acordados.
Interoperabilidade: capacidade do produto de software de interagir com um ou mais
sistemas especificados.
Segurança de Acesso: capacidade do produto de software de proteger informações e
dados, de forma que pessoas ou sistemas não autorizados não possam lê- los nem
modificá- los e que não seja negado o acesso às pessoas ou sistemas autorizados.
Conformidade: capacidade do produto de software de estar de acordo com normas,
convenções ou regulamentações previstas em leis e prescrições similares relacionadas
à funcionalidade.
Confiabilidade: capacidade do produto de software de manter um nível de desempenho
especificado, quando usado em condições específicas.
Maturidade: capacidade do produto de software de evitar falhas decorrentes de
defeitos no software.
Tolerância a Falhas: capacidade do produto de manter um nível de desempenho
especificado em casos de defeitos no software ou de violação de sua interface
especificada.
Recuperabilidade: capacidade do produto de software de restabelecer seu nível de
desempenho especificado e recuperar os dados diretamente afetados no caso de uma
falha.
Conformidade: capacidade do produto de software de estar de acordo com normas,
convenções ou regulamentações relacionadas à confiabilidade.
Usabilidade: capacidade do produto de software de ser compreendido, aprendido, operado e
atraente ao usuário, quando usado sob condições específicas.
91
Inteligibilidade: capacidade do produto de software de possibilitar ao usuário
compreender se o software é apropriado e como ele pode ser usado para tarefas e
condições de uso específicas.
Apreensibilidade: capacidade do produto de software de possibilitar ao usuário
aprender sua aplicação.
Operacionalidade: capacidade do produto de software de possibilitar ao usuário operá-
lo e controlá- lo.
Atratividade: capacidade do produto de software de ser atraente ao usuário.
Conformidade: capacidade do produto de software de estar de acordo com normas,
convenções, guias de estilo ou regulamentações relacionadas à usabilidade.
Eficiência: capacidade do produto de software de apresentar desempenho apropriado, relativo
à quantidade de recursos usados, sob condições específicas.
Comportamento em relação ao tempo: capacidade do produto de software de fornecer
tempos de resposta e de processamento, além de taxas de transferência, apropriados,
quando o software executa suas funções, sob condições estabelecidas.
Comportamento em relação aos recursos: capacidade do produto de software usar
tipos e quantidades apropriados de recursos, quando o software executa suas funções,
sob condições estabelecidas.
Conformidade: capacidade do produto de software de estar de acordo com normas e
convenções relacionadas à eficiência.
Manutenibilidade: capacidade do produto de software de modificado. As modificações
podem incluir correções, melhorias ou adaptações do software devido a mudanças no
ambiente e nos seus requisitos ou especificações funcionais.
Analisabilidade: capacidade do produto de software de permitir o diagnóstico de
deficiências ou causas de falhas no software, ou a identificação de partes a serem
modificadas.
Modificabilidade: capacidade do produto de software que uma modificação especifica
seja implementada.
Estabilidade: capacidade do produto de software de evitar efeitos inesperados
decorrentes de modificações no software.
Testabilidade: capacidade do produto de software de permitir que o software, quando
modificado, seja validado.
92
Conformidade: capacidade do produto de software de estar de acordo com normas ou
convenções relacionadas à manutenibilidade.
Portabilidade: capacidade do produto de software de ser transferido de um ambiente para
outro.
Adaptabilidade: capacidade do produto de software de ser adaptado para diferentes
ambientes especificados, sem necessidade de aplicação de outras ações ou meios além
daqueles fornecidos para essa finalidade pelo software considerado.
Capacidade de ser instalado: capacidade do produto de software ser instalado em um
ambiente especificado.
Coexistência: capacidade do produto de software de coexistir com outros produtos de
software independentes, em um ambiente comum, compartilhando recursos comuns.
Capacidade para substituir: capacidade do produto de software de ser usado em
substituição a outro produto de software especificado, com o mesmo propósito e no
mesmo ambiente.
Conformidade: capacidade do produto de software de estar de acordo com normas ou
convenções relacionadas à portabilidade.
As definições das características e sub- características propostas pela ISO/ IEC 9126- 1 são
tais que não permitem sobreposição. Como exemplo, a definição da característica
confiabilidade não permite que se considerem fatores que são próprios da característica
manutenibilidade. Contudo, a norma admite que um atributo de qualidade possa influenciar
mais de uma sub- característica ou característica. Por exemplo, número de linhas de código é
atributo tanto da sub- característica analisabilidade quanto da subcaracterística adaptabilidade.
A ISO/ IEC 9126- 1 nos leva a um entendimento dos conceitos relacionados com as
características e sub- características de qualidade de produtos de software, porém, na prática
ainda não facilita o suficiente a definição dos requisitos de qualidade a partir dela. As
definições das características de qualidade nos dão uma visão geral dos possíveis requisitos de
qualidade associados com os conceitos apresentados, mas não permitem elaborar uma
definição de requisitos mais detalhada a partir delas. Não há sentido em se dizer que “um
produto de software deve ter uma eficiência de 1,5”, pois não existe uma escala clara
associada a este valor, impossibilitando uma medida direta e quantitativa da característica de
qualidade.
93
O primeiro desdobramento em sub- características serve para delimitar melhor o amplo
universo que a característica engloba. Introduz conceitos mais detalhados que ajudam a
especificação de requisitos, fazendo- nos pensar na característica em termos de seus
componentes. Mais este desdobramento ainda não é suficiente pra especificar os requisitos de
qualidade. Uma definição como “o comportamento em relação ao tempo deve ser igual a 0,7”,
continua sem fazer sentido, pois não existe uma escala clara associada a este valor,
impossibilitando uma medida direta e quantitativa da sub-característica de qualidade.
Assim, é preciso que o usuário da norma, elaborando uma declaração de requisitos, faça o
próximo desdobramento; os atributos que não estão presentes na ISO/ IEC 9126- 1,
identificando aspectos relevantes ao produto de software e que se enquadrem nas sub-
características e características citadas. Desta forma, uma declaração do tipo “O tempo de
resposta para completar uma tarefa deve ser inferior a 2 segundos”, por exemplo, é adequada
como requisito da sub- característica comportamento em relação ao tempo, que faz parte da
característica eficiência. Vemos que foi necessário descer ao nível do atributo “tempo de
resposta para completar uma tarefa” para que o requisito pudesse ser declarado de forma
objetiva e não ambígua.
As partes 2 e 3 da norma ISO/ IEC 9126 definem métricas externas e internas respectivamente
que se associam a atributos de qualidade e que podem servir de referência inicial, na definição
de atributos.
2.4.1.2 Modelo de qualidade para qualidade em uso
O modelo de qualidade em uso categoriza os atributos de qualidade de software em quatro
características (eficácia, produtividade, segurança e satisfação). A qualidade em uso é a visão
da qualidade sob a perspectiva do usuário. A obtenção de qualidade em uso é dependente da
obtenção da necessária qualidade externa, a qual, por sua vez é dependente da obtenção da
necessária qualidade interna. Normalmente, são necessárias medidas em todos os três níveis,
pois atender aos critérios para medidas internas em geral não é suficiente para garantir o
atendimento aos critérios para medidas externas, e atender aos critérios para medidas externas
de sub- características em geral não é suficiente para garantir o atendimento aos critérios para
qualidade em uso. Exemplos de métricas de qualidade em uso são dados na ISO/IEC 9126- 4
94
Figura 17 - Modelo de qualidade em uso segundo a ISO/IEC 9126- 1
Fonte: ISO (2001)
Definição das características de qualidade em uso segundo a ISO/IEC 9126- 1:
Eficácia: capacidade do produto de software de permitir que usuários atinjam metas
específicas com acurácia e completude, em um contexto de uso específico.
Produtividade: capacidade do produto de software de permitir que seus usuários
empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um
contexto de uso especificado.
Segurança: capacidade do produto de software de apresentar níveis aceitáveis de riscos
de danos a pessoas, negócios, software, propriedades ou ambiente, em um contexto de
uso especificado.
Satisfação: capacidade do produto de software de satisfazer usuários, em um contexto
de uso especificado.
95
3 REVISÃO DE LITERATURA
Neste capítulo será feita a revisão de literatura pertinente ao tema da presente
dissertação e seus referenciais teóricos.
3.1 TESTES DE SOFTWARE
3.1.1 Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo
(Crespo et al., 2003)
3.1.1.1 Objetivo do trabalho
O objetivo dos autores foi apresentar uma visão geral do processo de desenvolvimento
e aplicação da metodologia de testes desenvolvida pelo CenPRA. Esta metodologia permite a
implantação ou melhoria do processo de testes em empresas desenvolvedoras de software.
Para experimentação e validação desta metodologia, ela foi aplicada em uma micro empresa
de software como parte de um projeto de melhoria de processo. Nesta empresa o processo de
teste foi executado nos últimos sete projetos realizados.
3.1.1.2 Resultados do Estudo
Metodologia de Teste
Visando atender as necessidades dessas empresas o CenPRA, por meio do grupo de teste da
Divisão de Melhoria de Processos de Software - DMPS, desenvolveu um projeto que teve
como objetivo criar uma metodologia para a introdução ou melhoria do processo de teste de
software em empresas produtoras de software, englobando técnicas, procedimentos e
ferramentas, capacitando-as a desenvolver produtos de melhor qualidade[Crespo,2002],
[Crespo, 2003]. A metodologia está fundamentada na adoção de um processo de teste e nos
artefatos sugeridos pela Norma IEEE 829-1998 [IEEE,1998], que descreve os documentos
que devem ser gerados na atividade de gerência do teste de software. A metodologia de teste
foi projetada e desenvolvida de uma forma que as empresas pudessem instanciar o processo
de teste de acordo com as suas necessidades e disponibilidade de recursos. Além disso, a
96
metodologia de teste pode ser aplicada a qualquer tipo de software, seja ele sistema de
informações ou software científico. Nesta metodologia, a implantação do processo de teste
envolve um conjunto de atividades que vai desde o levantamento das necessidades da
empresa, passa pela realização de treinamentos da equipe técnica e vai até ao
acompanhamento dos trabalhos realizados, constituindo assim, um completo ciclo de
implantação da atividade de teste dentro da empresa.
Figura 18 - Relação entre níveis, tipos e técnicas de teste
Fonte: Crespo Et al. (2003)
A metodologia, que preconiza a realização de testes sistemáticos, pode ser empregada tanto
por empresas que desenvolvem quanto por empresas que adquirem software, e está dividida
em 3 componentes: Treinamento, Processo de Teste e Suporte para Geração de Documentos:
1. Treinamento: Através de cursos, consiste da capacitação em conceitos básicos sobre teste
de software, técnicas de teste, documentação de teste e processo de teste. Estes cursos estão
divididos em módulos e sua aplicação pode ser adaptada às necessidades específicas de cada
empresa.
2. Processo de Teste: A metodologia define um processo genérico de teste que prevê a
realização das atividades de planejamento, projeto, execução e acompanhamento dos testes de
unidade, integração, sistemas e aceitação. A partir deste processo genérico cada empresa deve
instanciar um processo específico que melhor atenda suas necessidades.
3. Suporte para Geração de Documentos: Consiste da aplicação de uma técnica para a criação
de documentos que serão utilizados para a gerência do processo de teste, tanto na fase de
preparação para a atividade de teste quanto na fase de registro dos resultados do teste. Este
97
componente da metodologia está baseado na Norma IEEE 829-1998, que descreve um
conjunto de 8 documentos que cobrem as tarefas de planejamento, especificação e registro das
atividades de teste de um produto de software. Esta Norma pode ser usada para o teste de
qualquer tipo de software, seja ele comercial, científico ou militar, sendo definida de forma
independente de técnicas, métodos, estratégias, recursos e ferramentas de teste.
O processo de teste instanciado pode ser considerado como o processo de teste empregado de
forma global para todos os projetos da organização ou especificamente para cada um de seus
projetos. A seção do Plano de Teste que trata a estratégia a ser empregada em cada projeto
deve fazer referência ao processo empregado. O processo de teste proposto na metodologia
está baseado em alguns pressupostos básicos:
- Os testes de sistema e aceitação são projetados e executados sob a responsabilidade da
equipe de teste.
- Os testes de sistema, e eventualmente também o de aceitação, são realizados de forma
iterativa, havendo, antes do início de cada ciclo de teste, uma avaliação rápida do produto.
O processo de teste não contempla automação do teste, medida tomada para manter a
descrição inicial do processo simples.
Uma organização pode adotar outros pressupostos, devendo realizar as alterações necessárias
no processo de teste instanciado. Uma premissa básica da metodologia de teste proposta é que
o processo de teste, quando adequadamente definido, pode ter um impacto positivo nos
resultados de diversas outras atividades de desenvolvimento. Desta forma, o enfoque das
atividades de teste não é somente identificar problemas, mas principalmente prevenir
problemas. Estas premissas estão presentes em diversas referências sobre teste preventivo
(Beiser,1995), (Craig,2002).
O fato do processo genérico proposto não contemplar a automação de teste reflete a visão de
que um processo só deve ser suportado por ferramentas quando estiver convenientemente
definido e consistentemente adotado. Zallar afirma que o processo de automação de teste tem
maior probabilidade de ser bem sucedido para organizações que possuam uma equipe de teste
bem definida e com um processo padrão de documentação seguido, [Zallar,2001]
98
Aplicação da Metodologia de Teste
Como parte da experimentação e validação da metodologia de teste, foi realizado um projeto
de melhoria de processo em uma micro empresa desenvolvedora de software. A empresa na
qual a metodologia foi aplicada é uma pequena empresa de desenvolvimento de projetos de
software, fundada em 1995 e instalada em Campinas, SP, nas proximidades da Universidade
de Campinas (UNICAMP), no distrito de Barão Geraldo. Esta empresa tem, desde o início de
suas atividades, como foco principal o desenvolvimento de projetos de software. Esta área
representa cerca de 90% de seu faturamento mensal. Os seus clientes são, em sua maioria,
grandes empresas, multinacionais em muitos casos. Os projetos têm entre 2 e 6 meses de
duração e envolvem entre 2 e 4 profissionais.
Neste projeto de melhoria foram tratados vários processos, incluindo o processo de teste. O
projeto de melhoria seguiu a Abordagem de Melhoria de Processo do CenPRA [Salviano,
2003]. Esta abordagem suporta a escolha de diferentes modelos de referências e diferentes
metodologias para a melhoria de processos específicos. Neste projeto, por exemplo, foi
utilizado o modelo de processo da ISO/IEC TR 15504-5 [ISO/IEC 1998] como referência e
duas metodologias para dois processos específicos: a metodologia baseada no ProGer para o
processo de gerência de projeto e a metodologia de teste do CenPRA para o processo de teste.
ProGer é um modelo de processo para gerenciamento de projetos para organizações de
desenvolvimento de software de pequeno porte [Roullier, 2001].
O projeto foi iniciado em Janeiro de 2002. Seguindo a Abordagem de Melhoria de Processo
do CenPRA, o projeto foi executado em seis fases seqüenciais: (1) Início dos Trabalhos e
Definição de Metas, (2) Avaliação das Práticas Correntes, (3) Planejamento das Ações de
Melhoria, (4) Implantação das Ações de Melhoria, (5) Verificação dos Resultados e
Aprendizado, e (6) Institucionalização da Melhoria.
A primeira fase foi composta pela elicitação do negócio da empresa, estratégias e objetivos. A
escolha da ISO/IEC TR 15504 se deu devido à flexibilidade para adaptações às necessidades
da empresa. Decidiu-se utilizar cinco processos da futura norma, para o nível 2 de capacidade.
Os processo escolhidos foram: CUS.2 Supply (Fornecimento), CUS.3 Requirement
Elicitation, (Elicitação de Requisitos) MAN.2 Project Management (Gerência de Projeto),
ENG.1.6 Software Test (Teste de Software) e ORG.5 Measurement (Medição). Estes
processos foram selecionados de forma a cobrir as necessidades de melhoria de processo da
empresa.
99
Uma equipe do CenPRA realizou a avaliação para estes cinco processos, até o nível 3 de
capacidade, para descobrir as práticas utilizadas. A avaliação foi feita de acordo com o
método de avaliação criado pelo CenPRA. Os resultados indicaram nível 2 de capacidade para
ORG.5 Measurement e nível 1 para os outros.
Após a avaliação foram realizadas as outras fazes do projeto. Uma descrição mais detalhada
deste projeto de melhoria e de resultados preliminares foram apresentados e discutidos em
outras conferências da área [Silva 2003a, Silva 2003b].
Figura 19 - Processo de teste e seu relacionamento com o processo de desenvolvimento
Fonte: Crespo Et al. (2003)
100
Resultados da melhoria
A melhoria do processo de teste, associada à melhoria do processo de desenvolvimento de
software como um todo, permitiu observar os seguintes aspectos, dentre outros:
Maior controle durante a execução do projeto, devido principalmente ao planejamento
prévio e aos pontos de medição, sendo etapas do teste de software alguns dos
principais pontos existentes atualmente. Este controle permite ainda que os líderes de
projeto nos clientes sejam acionados imediatamente, sempre que houver qualquer
desvio em relação ao previsto.
Estudos e análises, realizadas após o encerramento do projeto e entrega do produto
gerado, reforçando os pontos positivos e criando ações corretivas para os pontos
negativos detectados no processo como um todo.
Qualidade do produto final gerado, no sentido da verificação (requisitos definidos
implementados corretamente). No sentido da aceitação, a documentação de projeto
completa ajuda a fornecer subsídios para que o usuário possa verificar o aspecto da
adequação às necessidades.
Outro ponto quanto à qualidade é que a documentação gerada permite perceber mais
claramente as falhas relacionadas a detalhamentos incorretos ou incompletos de
requisitos.
Os clientes parecem compreender melhor as dificuldades inerentes à produção de
software, aumentando o respeito pelas informações transmitidas, documentação
apresentada, necessidades explicitadas, aceitando até maiores prazos para entrega de
produtos com maior qualidade. A questão de maiores custos associados ainda é uma
variável a ser medida.
Há um aumento nos custos gerais de produção de software, esperados certamente no
início da implementação dos novos processos, mas que poderão ser diluídos apenas no
longo prazo.
O objetivo da empresa é, a partir dos dados gerados pelo processo de teste, medir
sistematicamente cada projeto de software corrigindo desvios e modificando
conseqüentemente as prioridades e ações corretivas a serem tomadas; em outras palavras,
aprimorando os processos com o aprendizado.
101
Após a implantação do processo de teste na empresa, as seguintes melhorias foram
observadas:
Existe um menor número de defeitos descobertos após instalação do software,
diminuindo de forma significativa os custos e problemas associados a correções
urgentes de um sistema em produção.
A equipe de programação está mais atenta: às tarefas de verificação, antes da
liberação de uma versão para teste, causando inclusive uma melhoria no produto,
trazendo além de menor desgaste da equipe, menores custos para a empresa.
Os clientes, verificando os resultados iniciais obtidos, têm dado mostras significativas
que estão dispostos a esperar mais pelo produto final. Mesmo assim, nem sempre
aceitam aumento nos custos. Em seguida, eles passam a exigir tal comportamento, em
projetos posteriores ao primeiro onde tiveram contato com o processo interno em
implantação, ou seja, passam a não querer mais versões do software não devidamente
testadas.
Os testes sistemáticos têm fornecido dados e informações relevantes à melhoria tanto
do próprio processo de teste quanto do processo de desenvolvimento como um todo,
aumentando sua eficiência e/ou abrangência, e permitindo a criação de pessoal
capacitado para as práticas necessárias.
Os testes sistemáticos têm se mostrado, ainda, um bom ponto de partida para
medições, relacionadas ao processo geral de desenvolvimento, ao processo de teste, e
ainda a outros processos internos da empresa.
Pelo lado do investimento, os testes sistemáticos tendem à “se pagar” somente num
horizonte de médio e longo prazo. Espera-se que o processo de teste continue em
evolução, tanto para seu contínuo aperfeiçoamento quanto, em um prazo mais longo,
para a incorporação de ferramentas.
102
Tabela 8 - Dados sobre os projetos realizados – primeira parte
Fonte: Crespo Et al. (2003)
3.1.1.3 Relação com a Presente Pesquisa
O estudo apresentou o desenvolvimento, aplicação e benefícios obtidos com a
implantação de uma metodologia de testes de software, o que corrobora com a hipótese
defendida nesta pesquisa que a adoção de processos estruturados de testes impactam a
qualidade dos produtos.
3.1.2 Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise
de Indicadores de Teste (NITA , 2003)
3.1.2.1 Objetivo do trabalho
O objetivo do trabalho de Nita foi descrever a experiência de uma empresa na utilização dos
indicadores de teste para melhoria de seu produto e processo de desenvolvimento, tendo como
objetivo principal a diminuição de custos, além do ganho de produtividade e aumento da
satisfação de seus clientes. Nas seções a seguir, será abordado como foi montada a equipe
responsável pelos testes e análise dos indicadores, como foi definida a metodologia de teste, a
escolha, obtenção e análise dos indicadores, e a apresentação dos resultados.
103
3.1.2.2 Resultados do Estudo
Definição de Indicadores
Para se obter os indicadores que serviriam de base para a melhoria da qualidade do processo,
foi preciso primeiro fazer a medição dos projetos. Para isso, foi necessário, antes de tudo, ter
definido um conjunto de medidas que trouxessem dados das atividades executadas. A
definição das medidas foi baseada nas atividades realizadas e artefatos produzidos durante o
processo de desenvolvimento utilizado na empresa. Foram selecionadas atividades
consideradas relevantes de se medir e as métricas que se gostaria de obter [4]. Foi elaborada
uma primeira versão com um pequeno conjunto de medidas que seriam coletadas dos
projetos. Após as primeiras análises feitas sobre as medidas extraídas dos projetos, sentiu-se a
necessidade de outras medidas que não faziam parte do conjunto de medidas de projeto para
complementar linhas de raciocínio e se chegar a algumas conclusões. Por isso, elaborou-se um
segundo conjunto se medidas, um pouco mais complexo mas que dava maior argumentação
no momento de se concluir as análises feitas sobre os resultados dos projetos. Existiram,
ainda, outros ciclos de melhoria, antes de se chegar ao conjunto de indicadores atual. Essas
melhorias sempre são motivadas pela necessidade dos próprios projetos em ter mais
informações para analisar os seus resultados. A Tabela 8 mostra um subconjunto atual dos
indicadores de projeto da empresa.
104
Tabela 9 - Indicadores de projeto usados na análise de teste
Fonte: NITA (2003)
Resultados
Durante o último ano ficaram evidentes os ganhos dessa abordagem do uso de
indicadores de teste e seus relacionamentos com outros indicadores dos projeto. Merecem
destaque, dentre os resultados positivos alcançados até agora:
maior comprometimento com os resultados: ficou claro para todos da equipe o
significado de cada indicador dentro do projeto, principalmente os relacionados aos
defeitos. O assunto "defeitos", antes recebido com resistência pela equipe, agora é
abertamente abordado nas reuniões de status, com discussões sobre causas de
defeitos, e boas práticas para evitá-los;
diminuição no número de defeitos: com as iniciativas de melhoria propostas pelo
grupo de teste nas atividades de implementação, houve uma queda de mais de 20% na
inserção de defeitos durante a implementação;
105
ganho de produtividade: com as iniciativas de melhoria propostas pelo grupo de teste
nas suas próprias atividades, houve um ganho de mais 15% na produtividade de
planejamento e execução de testes;
aumento da satisfação do cliente: com o trabalho feito pelo grupo de testes para
diminuir o número de defeitos de implementação, houve um aumento de quase 8% na
satisfação do cliente;
diminuição dos atrasos de entrega: com o trabalho feito pelo grupo de testes para
diminuir a taxa de retrabalho, houve uma queda de 10% nos desvios de esforço de
projeto;
diminuição dos custos: com o trabalho feito pelo grupo de testes para se encontrar o
quanto antes o maior número possível de defeitos, houve uma queda de quase 5% nos
desvios de custo de projeto.
3.1.2.3 Relação com a Presente Pesquisa
Nita apresenta os positivos resultados da implementação de um processo de teste estruturado
aliado à monitoração e análise de indicadores. A implementação e acompanhamento de
indicadores são peças chaves na validação das hipóteses defendidas nesta pesquisa.
3.1.3 Teste em Ambiente Cliente-Servidor: Uma Estratégia e um Estudo de Caso
(VOLPI, VIRGILIO, 2002)
3.1.3.1 Objetivo do trabalho
Volpi e Virgilio apresentam um estudo cujo objetivo consistiu em avaliar, por meio de
questionários e entrevistas, como a atividade de teste era realizada em uma organização e
quais as principais dificuldades encontradas.
3.1.3.2 Resultados do Estudo
Com a finalidade de levantar a situação da atividade de teste realizada nos sistemas dentro
desta empresa foi elaborado um questionário e distribuído para 138 pessoas, das quais 35%
responderam, entre gerentes e coordenadores, analistas e líderes de projeto e programadores e
106
técnicos de suporte. O objetivo é verificar a eficiência e os problemas existentes para a
realização do teste.
As respostas coletadas foram analisadas estatisticamente e o resumo das principais conclusões
que serviram como base para a ETACS (Estratégia de Testes em Ambientes Cliente-
Servidor) são apresentados a seguir:
o estabelecimento de uma estratégia é bastante importante, pois, a partir dela, roteiros
e ferramentas poderão ser estabelecidos;
a estratégia deve fornecer uma maneira sistemática para realizar o teste, incluindo um
conjunto de fases, e estabelecer os documentos a serem produzidos em cada fase;
esclarecer que tipos de teste e critérios devem ser aplicados, considerando a
arquitetura cliente-servidor;
teste de performance e regressão devem ser enfatizados, bem como testes estruturais,
pois estes raramente são realizados e podem revelar erros de lógica, apontados como
os principais problemas;
prover um meio de auxiliar na aplicação dos testes funcionais com dados gerados a
partir dos requisitos do usuário, pois testes funcionais são bem utilizados na empresa,
e propor meios mais eficientes de geração de dados;
a elaboração de um plano e o registro dos recursos de tempo e dos defeitos
encontrados durante a atividade de teste, pois auxiliam na obtenção de uma relação
custo-benefício que pode justificar a importância de dedicar um tempo específico a
essa atividade no cronograma do projeto;
contemplar uma maneira de manter arquivados os dados de teste usados, podendo
atualizá-los a fim de manter um histórico e permitir que possam ser usados no teste de
regressão, ou seja, um ambiente de teste;
fazer com que os testadores estejam motivados a encontrar erros nos programas;
comprovadas a necessidade e expectativa de um roteiro, o que pode ser simplista
demais, que auxilie a atividade de teste. A maior expectativa é que a utilização de uma
ferramenta auxilie a execução desta tarefa;
falta conhecimento formal de métodos de teste. Atualmente, os testes são realizados de
maneira intuitiva. Um resultado observado é a necessidade de treinamento que
comprove esse fato.
107
Com isso, conclui-se que é imprescindível a elaboração de uma estratégia de teste para
auxiliar essa atividade na empresa.
3.1.3.3 Relação com a Presente Pesquisa
O estudo apresentou o levantamento dos problemas enfrentados por uma organização
na realização da atividade de testes. Os resultados obtidos corroboram as premissas levantadas
nesta pesquisa, sobre as dificuldades encontradas na realização da atividade de teste.
3.1.4 Erros de Teste Clássicos (MARICK, 1997)
3.1.4.1 Objetivo do trabalho
O objetivo de MARICK foi apontar os principais erros cometidos nos projetos de testes de
software e oferecer soluções cada falha identificada.
3.1.4.2 Resultados do Estudo
Os erros relacionados ao problema de se testar software comercial estão agrupados neste
artigo em cinco grupos importantes. Erramos, quando implementamos processos de teste, nos
seguintes pontos:
No propósito da atividade de teste
No planejamento dos testes
No pessoal que contratamos para testar
Na execução dos testes em si
Na aplicação da tecnologia aos testes
Estes ítens serão abordados a fundo nas próximas seções.
108
O Propósito de Testar
Os erros apontados nesta seção envolvem não entender bem qual o sentido de se fazer a
atividade de testar, e de não aproveitar os resultados de forma eficaz. Os erros comuns são:
Atribuir a responsabilidade pela qualidade unicamente à equipe de teste
A responsabilidade de qualidade é de todos os envolvidos no projeto em todas as etapas; não é
motivante culpar a equipe de teste pelo resultado de se auditar a qualidade do produto
desenvolvido.
Achar que a tarefa de equipe de testes é simplesmente encontrar erros.
A tarefa mais importante da equipe de testes é encontrar os bugs importantes; o comum, no
entanto, é focar na quantidade de bugs e não na relevância dos erros implicar em riscos
importantes para o projeto.
Não encontrar os erros importantes.
Fundamentalmente importantes são os erros que trazem risco significativo à viabilidade do
projeto com relação ao usuário final -- seja do ponto de vista de execução do sistema em si,
seja do ponto de vista da usabilidade e aplicabilidade do sistema ao problema do cliente.
Não informar sobre erros de usabilidade.
Se o teste de usabilidade não informa sobre a qualidade das interfaces do sistema, e existirem
problemas de usabilidade, o produto será visto como ruim pelo cliente, não importando se é
um problema formalizado pelo teste aplicado ou não.
Não focar em estimar a qualidade.
Um objetivo importante de fazer teste é estimar a qualidade do produto sendo criado (e
estimar a qualidade desta estimativa). A técnica mais efetiva para avaliar a qualidade geral é
fazer uma análise `em largura' do produto completo.
Oferecer estatísticas de erros sem o contexto relevante
A estatística associada ao erro tende a ser analisada de forma muito otimista se não são
oferecidos dados adicionais referentes ao volume de testes executados e à experiência
109
anteriormente obtida; estes dados podem dar um parecer mais realista da situação na qual o
projeto se encontra.
Começar a testar tarde demais
Se os testes são preparados e executados em todas as fases do projeto -- começando antes da
implementação em si -- a chance de se encontrar erros de especificação em uma etapa inicial é
muito maior.
O Planejamento dos Testes
Estes erros são relacionados à fase de planejamento dos testes que serão executados:
Concentrar exageradamente em teste funcional
O teste funcional não testa a interação entre as diferentes funções. Produtos de software são
orientados a tarefas, e como estas envolvem uma série de funções em conjunto, o teste deve
verificar como estas funções diferentes interagem.
Não enfatizar o teste de configuração
Testar a interação de diversos tipos de software e hardware com o produto garante que este
software realmente funcionará em qualquer ambiente; isto tem relevância muito maior para
produtos de software comerciais com aplicação geral.
Deixar o teste de carga para o final do processo
Escalabilidade é uma questão de alto impacto em um software; deixar o teste para o final
implica em sobrar pouco tempo para consertar problemas que possam surgir.
Não testar a documentação e não testar a instalação
Má documentação e instalações imperfeitas são ótimas formas de se fazer uma má impressão
inicial do produto, e são problemas que atenção direcionada pode resolver de forma
relativamente simples.
Confiar exageradamente no teste beta
Os usuários de um beta teste não são os usuários mais comuns. Em geral não usam o produto
a fundo, e não informam sobre problemas de usabilidade em geral. Muitas vezes, não
110
reportam os bugs que encontram, e os bugs reportados tem um custo alto de processamento e
compreensão.
Dito isto, beta testes são excelentes para fazer teste de configuração e um marketing inicial do
produto.
Executar os testes de forma estritamente consecutiva
Esperar um teste terminar por completo para iniciar outro retarda a descoberta de erros;
idealmente, é melhor saber um pouco sobre todos os componentes de um sistema do que saber
muito sobre os poucos que foram testados até agora.
Não identificar áreas de risco
O objetivo principal do teste é, mais especificamente, identificar o risco que problemas
desconhecidos podem trazer. Utilizar dados históricos e analisar opiniões de uma variedade
boa de usuários oferece uma base melhor para avaliar estes riscos.
Insistência em aplicar um plano de teste ineficaz
O problema com o teste é que a equipe tende a se concentrar em projetar e implementar testes,
e não encontrar os problemas importantes. Se o teste não encontra estes problemas, acaba
sendo fundamentalmente irrelevante.
As Questões de Pessoal
Ao se escolher a equipe que conduzirá os testes, é importante se concentrar nos seguintes
erros comuns:
Usar o teste como um trabalho temporário para programadores novos
Testar requer prática e experiência; programadores novos têm desejo de sair logo da área de
teste para uma área de maior visibilidade: o desenvolvimento.
Recrutar ex-programadores (ruins) para a equipe de teste
Maus programadores muitas vezes têm hábitos ruins - falta de atenção, desorganização - que
os levarão a ser maus testadores.
Usar testadores que não conhecem o domínio da aplicação
111
Muitas vezes, o testador não conhece a fundo o domínio do problema, e os problemas que
serão encontrados por ele serão menos relevantes que os problemas encontrados por um
usuário experiente.
Não contratar pessoal do suporte técnico e documentação
O pessoal destes departamentos tem experiência em contato com os problemas do usuário, e
sabem em geral o que é importante, o que é confuso, e o que é difícil de explicar -- aspectos
que estão intimamente ligados ao surgimento de problemas importantes.
Insistir que testadores sejam programadores
O bom testador não necessariamente é um programador, e uma equipe de testadores que é
composta unicamente de programadores tem o problema de baixa diversidade, o que leva ao
problema seguinte.
Não utilizar uma equipe de teste diversificada
Uma equipe de testes pouco variada tende a encontrar bugs concentrados em áreas
específicas. O objetivo do teste é encontrar problemas de forma ampla, e não em
profundidade.
Separar fisicamente testadores e programadores
Uma relação de trabalho boa e eficiente é importante se queremos obter o máximo proveito da
equipe de teste; muito do trabalho será depuração feita em conjunto, que é muito complicada
quando se separam as equipes envolvidas.
Acreditar que programadores não podem testar seu próprio código
Em efeito, programadores testam o seu código todo o tempo, e encontram muitos problemas.
No entanto, encontram problemas de tipo bem selecionado, e a ação conjunto do teste de
programadores com uma equipe de teste variada tende a ser a mais eficiente.
Não treinar e nem motivar os programadores para testar
Até que se valorize o teste feito por desenvolvedores, a equipe de teste terá que concentrar-se
em executar os testes que os desenvolvedores fazem e os testes que só a equipe de teste tem
capacidade de executar.
112
O Trabalho de Testar
Durante a execução dos testes, um conjunto de problemas comuns é:
Dar mais atenção à execução dos testes do que ao seu projeto
Um testador que não é sistemático e não planeja o seu teste deixará de encontrar erros
importantes, e não observará casos especiais.
Não rever os projetos de teste
Assim como programadores, testadores podem se beneficiar de análise conjunta do projeto
dos testes. Testar em isolamento é uma técnica pouco eficiente de se conduzir a avaliação de
qualidade.
Ser específico demais nas entradas e procedimentos do teste
Embora o teste deva conter uma descrição da configuração, entradas e saídas esperadas, ser
muito específico na descrição dos passos a ser tomados torna a manutenção do teste mais
cara, a sua elaboração mais complexa, e reduz a chance de se encontrar um problema
associado à atividade mas não exatamente dentro do caso analisado.
Não notar e nem explorar irregularidades peculiares
Muitas vezes, irregularidades são esquecidas como irrelevantes, enquanto a verdade é que
freqüentemente são fontes de problemas. Um bom teste utiliza os casos de teste como um
ponto de partida para uma exploração do produto.
Checar que o produto faz o que deve, mas não verificar se ele não faz o que não deve
O teste deve, além de focar na execução correta da ação, verificar se nada mais foi alterado
além do estritamente desejado. Este ponto é muitas vezes esquecido durante a execução dos
testes.
Elaborar suítes de teste compreendidas apenas por seus criadores
Se os testes são muito particulares, grande custo é implicado na saída de seus
desenvolvedores, e alto custo de sua manutenção ocorre como conseqüência.
Testar apenas por meio da interface com o usuário
113
É uma boa técnica oferecer uma interface associada específica para executar os testes, porque
muitos problemas não são encontrados diretamente por meio da interface com o usuário.
Informar problemas incompleta ou ineficientemente
Encontrar os problemas é uma das metades do trabalho da equipe de teste. Informar os testes é
muito importante, mas muitas vezes não há informação de como reproduzir o erro, do que
exatamente ocorreu de errado, do nível de prioridade do erro, e se oferece pouco apoio para
fazer a depuração em si.
Adicionar apenas testes de regressão quando problemas são encontrados
Problemas tendem a se concentrar em áreas do produto; problemas encontrados em uma área
determinada do produto implicam na necessidade de se fazer uma análise mais profunda
daquela região, e não apenas em acrescentar à regressão.
Não manter um histórico de anotações para os próximos testes
Os produtos criados por uma empresa em geral tem grande semelhança entre si, e os
problemas serão muitas vezes parecidos. Manter anotações a respeito dos problemas
encontrados em um produto serve como base importante para análises futuras.
O uso da Tecnologia
A aplicação de tecnologia à atividade de teste é muitas vezes benéfica, mas nem sempre, e
nunca desenfreadamente. Os erros seguintes envolvem o foco tecnológico do teste:
Tentar automatizar todos os testes
Automatizar os testes, embora possa a longo prazo reduzir o custo total do teste, tem
aplicação específica. Muitas vezes, um teste não justifica o esforço requerido na sua
automação.
Esperar re-executar testes manuais
Se a maior parte dos testes terá de ser re-executado manualmente, o tempo gasto no seu
desenvolvimento e documentação será desperdiçado.
Usar ferramentas de automação de interface para reduzir o custo do teste
114
Como mudanças de interface são comuns, e há grande uso de widgets customizados, é difícil
aplicar testes de interface automatizados, e há custo alto na sua implementação. Usar scripts
para testar a interface é uma alternativa interessante que pode ser utilizada de forma mais
proveitosa.
Esperar que testes de regressão encontrem uma grande proporção dos defeitos
introduzidos
Embora os testes de regressão capturem problemas em partes já existentes do software
causados por mudanças no sistema, a maior parte dos problemas estão justamente
relacionados à funcionalidade nova criada em si, o que terá de ser analisada em novos testes.
Abraçar exageradamente a análise de cobertura do código
A análise de cobertura de código é uma observação de quanto do código está coberto por
casos de teste. No entanto, problemas múltiplos podem acontecer em uma única linha do
programa, e dependem de como é executado aquela parte do código. Apoiar-se apenas em
cobertura do código, portanto, não oferecerá uma análise de qualidade sólida.
Remover testes da suíte de testes de regressão porque não aumentam a cobertura
Testes de regressão não têm como objetivo cobrir todo o código, e sim observar se mudanças
no software implicaram na introdução de erros. Removê-los indiscriminadamente significará
reduzir o poder da suíte de teste.
Usar cobertura como um objetivo primário para a equipe de teste
Usar a cobertura para avaliar a equipe é uma forma numericamente simples de se verificar a
sua performance. O problema com avaliar a equipe de teste por meio da cobertura é que a
equipe passa a se focar neste objetivo, e não no objetivo real da tarefa. Como a cobertura não
é uma avaliação real da qualidade do software, não pode ser usada para avaliar a performance
da equipe.
Não analisar a cobertura de código em absoluto
Tendo dito tudo isso, a análise da cobertura oferece uma análise simples da avaliação do
código, e, embora frustrante se utilizada como a ferramenta única de qualidade, oferece uma
base importante o suficiente para não ser abandonado por completo.
115
3.1.4.3 Relação com a Presente Pesquisa
O estudo apresentado permite identificar os problemas existentes na execução de um processo
de testes, analisar as soluções propostas pelo autor e confronta-las com as defendidas nesta
pesquisa.
3.1.5 Introdução a Melhoria do Processo de Testes e o Impacto na Organização
(WOODRUFF, 2003)
3.1.5.1 Objetivo do trabalho.
O objetivo do estudo foi descrever o processo de melhoria dos testes e seus impactos em uma
organização num período de quatro anos na execução de testes em produtos de software.
3.1.5.2 Resultado do Estudo
Após quatro anos de implantação de processos de melhoria baseados nas KPA do modelo
CMM junto às atividades de testes de produtos de software e contínua avaliação de
indicadores, os seguintes benefícios foram identificados, conforme tabela 12 a seguir:
Tabela 12 - Indicadores de melhoria do CMM
Fonte: WOODRUFF (2003)
Os benefícios apresentados mostraram um aumento na produtividade, destacando que durante
o período de avaliação, não houve inclusão de novos recursos para as atividades de testes,
pelo contrário, a final de três anos de projeto, um recurso foi perdido. Os processos
implementados permitiram com exatidão o dimensionamento dos esforços e tempos para as
116
atividades de testes. Cabe ressaltar que os prazos durante o projeto raramente sofreram
atrasos.
3.1.5.3 Relação com a presente pesquisa.
O estudo apresentou os resultados de benefícios obtidos com a implantação dos
processo baseado no modelo CMM tema principal abordado nesta pesquisa. Os benefícios
identificados corroboram para a validação da hipótese defendida pelo autor.
3.1.6 Melhoria do Processo de Teste (POL e TEUNISSEN 2003)
3.1.6.1 Objetivo do trabalho.
O objetivo de POL, TEUNISSEN e VEENDENDAAL foi desenvolver em sua obra um
modelo maturidade baseado nas melhores práticas da indústria relativas à melhoria do
processo de testes. O modelo inclui guias práticas para avaliar o nível de maturidade de
testes de uma organização bem como os passos para melhorar o processo.
3.1.6.2 Resultado do estudo.
O modelo se compõe de 20 Áreas Chaves, cada uma com diferentes níveis de maturidade.
Os níveis de todas as Áreas Chaves estão integrados em uma Matriz de Maturidade. Cada
nível está descrito por vários Pontos de Verificação. Também fazem parte do modelo
algumas Sugestões de Melhoria que ajudam a atingir o nível desejado. O documento inclui
uma descrição geral da aplicação do modelo, que indica como se devem implantar e
consolidar as melhoras atingidas.
Descrição do Modelo
O modelo pode ser visualizado de seguinte maneira:
117
Figura 26 - Visão geral do modelo TPI
Fonte: POL, TEUNISSEN, VEENDENDAAL (2003)
Área Chaves
Em cada processo de teste existem áreas que precisam de atendimento específico com o
objetivo de se alcançar um processo de testes maduro. Estas Áreas Chaves constituem a base
para melhoraria e estruturação do processo de testes. O modelo TPI possui 20 Áreas Chaves.
ÁREA-CHAVE DESCRIÇÃO
1 Estratégia dos Testes
Deve focar encontrar as falhas mais importantes de forma mais
rápida e barata. Deve definir qu
ais requerimentos e quais riscos
serão cobertos pelos testes.
2 Modelo de Ciclo de Vida
Neste processo devem ser definidas as fases como, planejamento,
preparação, especificação, execução e finalização. Em cada fase
várias atividades são executadas. Para
cada atividade, os
seguintes aspectos devem ser definidos: o propósito, os inputs, o
processo, os outputs, as dependências, as técnicas e ferramentas
aplicáveis, as facilidades requeridas, a documentação e etc.. A
importância de se utilizar um Modelo de Ci
clo de Vida é que ele
possibilita prever e controlar o processo de teste, pois suas
diferentes atividades podem ser planejadas e monitoradas de
forma coesa.
3
Momento do Envolvimento
no Teste
Apesar de normalmente o processo de teste começar após o
sistem
a ficar pronto, ele deveria começar muito antes. O
momento de iniciar o teste deve ser o mais cedo possível, ou
seja, durante o desenvolvimento ou até durante o início do
projeto, e não após o sistema estar pronto. Iniciar os testes junto
com o desenvolvimento ajuda a evitar falhas ou encontrá-
las
mais rápida e facilmente e também propicia ajustar os diferentes
testes a seram feitos.
4 Estimativa e Planejamento
Aqui devem ser definidos quais atividades têm que ser
executadas e que recursos (humanos) são ne
cessários para cada
uma. Bons planejamento e estimativa são muito importantes,
pois são a base para alocação de recursos. São importantes
também para cumprimento de prazos.
5
Técnicas de Especificação
dos Testes
A definição de Técnicas de Especificação de
Testes é "uma
forma padronizada de descobrir test cases por meio de
informações (entrevistas, documentações, etc.)". A aplicação
destas técnicas nos levam a "insights" sobre a qualidade e
profundidade dos testes, além de tornar o teste reutilizável
(padronização).
118
6 Técnicas de Teste Estático
Nem todo programa pode ser testado automaticamente.
Inspecionar um produto sem rodar nenhum programa ou avaliá-
lo de acordo com uma certo grau de qualidade é chamado de
Teste Estático (Testes Manuais). Checklists (re
quisitos) são
muito úteis para isso.
7 Métricas
Métricas são observações quantitativas sobre características de
um produto ou processo. Para o processo de teste, métricas do
progresso do processo e do progresso da qualidade do produto
são muito importante
s. São utilizadas para controlar o processo
de teste, para substanciar os avisos de teste e também para
possibilitar comparar sistemas e processos. Por que um sistema
apresenta menos falhas em operação que um outro? Ou, por que
um processo de teste é mais
rápido que outro? Especialmente por
aperfeiçoar processos, métricas são muito importantes por
avaliarem as conseqüências do aperfeiçoamento de certas ações,
comparando um dado anterior com uma atual após executar esta
ação.
8 Automação de Testes
Automação
em processos de teste existe de várias formas e tem,
em geral, um ou mais dos seguintes objetivos: diminuir tempo de
teste, aumentar a flexibilidade do teste, testes mais profundos,
maior quantidade de combinações, maior motivação dos
testadores, etc..
9 Ambiente de Teste
Existe ambiente de teste de acordo com a demanda. Este
ambiente é composto principalmente pelos seguintes
componentes: hardware, softwares de apoio, formas de
comunicação, facilidade de montar ou utilizar banco de dados,
etc. O ambiente
deve ser composto e disponibilizado de forma a
otimizar o resultado dos testes e a atender as necessidades do
objeto a ser testado. O ambiente de teste tem uma grande
influência na qualidade, na condução do tempo, no custo e no
processo do teste. Outros as
pectos importantes deste ambiente
são: responsabilidades, gerenciamento, avaliação de tempo e
flexibilidade.
10
Local de Trabalho dos
Testadores
O local de trabalho dos testadores também é muito importante
(salas, móveis, PCs, impressoras, telefones, etc.
). Um ambiente
adequado, agradável e disponibilizado a tempo motiva as pessoas
e facilita a comunicação interna e externa, tornando o trabalho
mais eficiente.
11
Comprometimento e
Motivação
Comprometimento e motivação das pessoas envolvidas é muito
import
ante para uma boa fluência no processo de teste. A todas
elas, gerente ou testador, deve ser atribuída muita importância,
pelo menos para que seja viabilizada criatividade sobre boas
condições de teste. Elas devem contar com tempo, dinheiro e
recursos para otimização de seus resultados.
12
Funções de Teste e
Treinamento
Num processo de testes a composição correta do "time" de
testadores é muito importante. Diferentes formações,
conhecimentos e habilidades são fundamentais. Além de
expertise em testes, conh
ecimento sobre o negócio, a instituição
e conhecimentos gerais sobre TI também são necessários.
Habilidade no trato com pessoas (cliente e funcionários) também
é muito importante. Para se obter este mix, treinamento é
fundamental.
13 Escopo da Metodologia
Para cada processo de teste na organização, uma certa
metodologia ou método de trabalho é utilizado, incluindo
119
atividades, procedimentos, regulamentos, técnicas e etc..
Metodologias muito diferentes ou muito genéricas têm efeitos
negativos neste processo.
O objetivo é que a organização utilize
metodologia suficientemente genérica para que possa ser
aplicada em qualquer situação, mas esta metodologia deve conter
detalhes suficientes para que não seja necessário repensar
processos a toda hora.
14 Comunicação
Num processo de teste, comunicação com todas as pessoas
envolvidas é muito importante. Tanto com o time de testadores,
como com os desenvolvedores, usuários, clientes e etc. Estas
formas de comunicação são importantes para facilitar o processo
teste, pa
ra criar boas condições e otimizar a estratégia de teste.
Assim como também deixar todos informados sobre o progresso
e qualidade do produto.
15 Reporte
Reportar não é só apresentar a lista de falhas detectadas,
mostrando o nível de qualidade do produto.
O reporte deve
também informar, recomendar e aconselhar os desenvolvedores e
o cliente sobre o produto em foco (SUT).
16 Gerenciamento de Falhas
Apesar do gerenciamento das falhas ser de responsabilidade do
projeto, e não especificamente dos testadores,
este está muito
ligado a Equipe de Testes. Um bom gerenciamento deve ser
capaz de mostrar o ciclo de vida das falhas e sugerir
melhoramentos substanciados pela falhas detectadas. Uma boa
Equipe de Testes deve acompanhar e cobrar o tempo de conserto
das falhas (pelo menos mostrar estatisticamente).
17
Gerenciamento do
Testware (artefatos do
teste)
Os produtos dos testes devem ser passíveis de manutenção, de
serem reutilizados e de serem gerenciados. Além de produtos
como plano de testes, especificações, b
ase de dados, e arquivos,
é importante também que seja gerenciado o processo anterior,
como a definição das funções. Isto é necessário, para que, no
caso de uma versão errada, o processo possa ser retomado sem
perdas do que já foi executado e para acompanh
ar a evolução do
produto. Deve poder ser utilizado em qualquer projeto de teste.
18
Gerenciamento do processo
de teste
Para gerenciar cada atividade e cada processo, os 4 passos do
ciclo de Deming são essenciais: planejar, fazer, checar e agir
(influir).
O gerenciamento tem importância vital na otimização
do teste que é sempre realizado num processo turbulento.
19
Avaliação dos Produtos
Intermediários do
Desenvolvimento
Avaliar significa verificar os produtos intermediários do
desenvolvimento, como os req
uerimentos ou as definições das
funções. A importância da avaliação está em achar as falhas o
mais cedo possível durante o desenvolvimento. Isto faz o
retrabalho custar muito menos.
20
Testes "Low-level"
(testes realizados pelos
desenvolvedores)
Os testes “low-
level” são aqueles realizados pelos
desenvolvedores. Os mais conhecidos são o teste unitário e
o testes de integração. Assim como a avaliação, estes testes
detectam falhas mais cedo, ou seja, durante o
desenvolvimento. São eficientes por necessitare
m de pouca
comunicação já que são achados e consertados pelos que
estão produzindo o software.
Quadro 5 - Áreas Chaves do Modelo TPI
Fonte: POL, TEUNISSEN, VEENDENDAAL (2003)
120
A forma em que estão organizadas as Áreas Chaves dentro de um processo de testes
determina a “maturidade” do processo. É óbvio que nem toda Área Chave terá o mesmo
atendimento nem profundidade: cada processo de testes tem seus pontos fortes e fracos.
Com o objetivo de permitir uma visão do status de cada Área Chave, o modelo proporciona
Níveis (A, B e C). Como média, existem três níveis por cada Área. Cada nível superior (
onde C é maior do que B, e B é maior do que A ) é melhor do que seu nível prévio em
termos de tempo, recursos financeiros, e/ou qualidade. Ao usar níveis podemos avaliar sem
ambigüidades a situação prevalecente do processo de testes. Também incrementa a
possibilidade de recomendar melhorias graduais. Cada nível implica no cumprimento de
certos requisitos para a Área Chave. Os requisitos ( = Pontos de Verificação ou Checkpoints )
de um verdadeiro nível também incluem os requisitos de níveis prévios: um processo de
provas de nível B satisfaz os requisitos de ambos niveles A e B. Se um processo de provas
não satisfaz os requisitos para o nível A, considera-se que se encontra no nível mais baixo e,
por tanto num nível indefinido para dita área em particular.
Níveis
Área-chave
A B C D
1
Estratégia dos
Testes
Estratégias
individualizadas
para os testes
"high-level"
(5A, 11A)
Estratégias
coordenadas para
testes "high-level"
(2A, 5B, 11B,
14B, 18B)
Estratégias
coordenadas para
testes "high-level"
mais testes "low-
level", ou testes
"high-level" mais
avaliação (3C,
19B) OU (20C)
Estratégias
coordenadas para
todos os testes
("high-level" +
"low-level") e
níveis de avaliação
(3C, 19B, 20C)
2
Modelo de
Ciclo de Vida
Fases de
Planejamento,
Especificação,
Execução (11A)
Fases de Planejamento, Preparação, Especificação,
Execução, e Conclusão (6A, 17A)
3
Momento do
Envolvimento
no Teste
Conclusão da
documentação
que serve base
para o teste
(2A)
Início na
elaboração da
documentação que
serve de base para
o teste (2B)
Início na definição
dos requerimentos
Início do projeto
(11C)
4
Estimativa e
Planejamento
Estimativa e
planejamento
substanciados
(2A)
Estimativa e planejamento estatisticamente substanciados
(7B, 15B)
5
Técnicas de
Especificação
dos Testes
Técnicas
informais
Técnicas formais (12A, 17A)
121
6
Técnicas de
Teste Estático
Inspeção da
documentação
utilizada como
base para o teste
Checklist
7
Métricas
Métricas do
Projeto de testes
-
produtos (11B,
15B, 16A, 18B)
Métricas do
projeto de testes -
processo (15C,
16B)
Métricas em
termos de Sistema
(13B, 14C, 18C)
Métricas em
termos da
organização (mais
de 1 sistema)
8
Automação de
Testes
Uso de
ferramentas
Automação de
testes gerenciada
(5A ou 5B, 12
A
)
Automação de testes otimizada
9
Ambiente de
Teste
Ambiente de
teste gerenciado
e controlado
(12A)
Testando no
ambiente mais
adequado (1B)
Ambiente de testes sob demanda
10
Local de
Trabalho dos
Testadores
Local de trabalho dos testadores adequado e disponibilizado a tempo
11
Comprometime
nto e Motivação
Definição de
orçamento e de
tempo
Teste totalmente
integrado com a
organização do
projeto (2A, 15B,
16
A
, 18B)
Engenharia de testes (1C, 3C, 8B,
15C)
12
Funções de
Teste e
Treinamento
Gerente de
testes e
testadores
Suporte
Metodológico,
Técnico e
Funcional, e
Gerenciamento do
processo de teste,
testware e infra-
estrutura
Quality Assurance interno formal
(13A)
13
Escopo da
Metodologia
Específica por
Projeto (2A, 5B,
16
A
, 17A, 18B)
Genérica para a
organização
Metodologia genérica em constante
aprimoramento (11B, 18C)
14
Comunicação
Comunicação
dentro da
equipe de teste
Comunicação
dentro do Projeto -
falhas, controle de
alterações (2A,
15B, 16A)
Comunicação dentro da organização
sobre a qualidade do processo de testes
(13B)
15
Reporte
Falhas Progresso ( Status
do Teste e do
Produto ),
Atividades ( custo
e tempo,
andamento do
cronograma),
classificação das
falhas por
prioridade (2A,
16
A
, 18B)
Riscos e
recomendações
baseadas em
métricas (1A, 5B,
7A, 16B)
As recomendações
têm caráter de
aperfeiçoamento
do processo de
software (1C, 11C)
16
Gerenciamento
de Falhas
Gerenciamento
das falhas pela
equipe de testes
Gerenciamento
extensivo da falha
com flexibilidade
e facilidade de
Gerenciamento das falhas no projeto
122
reporte
17
Gerenciamento
do Testware
(artefatos do
teste)
Gerenciamento
Interno de
versões do
testware -
Equipe de
Testes
Gerenciamento
externo de versões
(Equipe de
projeto) da
documentação que
serve de base para
o teste e do objeto
de teste
Testware
reutilizável (5B)
Rastreabilidade
dos requisitos de
sistema com as
"test cases"
18
Gerenciamento
do processo de
teste
Planejamento e
Execução
Planejamento,
Execução,
Monitoramento e
Ajuste
Monitoramento e ajuste dentro da
organização (13B)
19
Avaliação dos
Produtos
Intermediários
do
Desenvolviment
o
Técnicas de
avaliação
Estratégia de avaliação
20
Testes "Low-
level" (testes
realizados pelos
desenvolvedores
)
Ciclo de vida do
teste:
planejamento,
especificação e
execução
Técnicas de testes
caixa-branca
Estratégia de testes "low-level"
(estratégia para testes realizados pelos
desenvolvedores)
Quadro 6 - Níveis de Maturidade de Áreas Chaves do Modelo TPI
Fonte: POL, TEUNISSEN, VEENDENDAAL (2003)
Pontos de Verificação ( Checkpoints )
Com o objetivo de determinar os Níveis, o modelo TPI se baseia num instrumento de
medição objetiva. Os requisitos para cada nível estão definidos em forma de Pontos de
Verificação (Checkpoints ): são perguntas que precisam ser respondidas afirmativamente
para poder qualificar a nível em questão. A partir das listas de verificação se pode avaliar um
processo de testes e se pode determinar para cada Área Chave o Nível atingido. À medida
que se considera melhoria de cada Área Chave, os Pontos de Verificação são acumuláveis:
para poder classificar para o nível B, o processo de testes precisa responder afirmativamente
tanto aos Pontos de Verificação do nível B como do nível A.
123
Matriz de Maturidade
Depois de determinar os níveis para cada Área Chave, deve-se dirigir o atendimento para
quais são os passos de melhoria que se deve realizar. Isto é necessário para que todas as
Áreas Chaves e Níveis têm a mesma importância. Por exemplo, uma boa estratégia de
provas (nível A da Área Chaves “Estratégia de Testes”) tem mais importante do que uma
descrição da metodologia de testes utilizada (nível A da Área Chave “Alcance da
Metodologia”). Além destas prioridades, existe uma dependência entre os níveis de diferentes
Áreas Chaves. Antes de poder receber estatísticas dos defeitos encontrados (nível A da Área
Chave“Métricas”), o processo de testes tem que se qualificar para o nível B do Área Chave
“Gerenciamento de Defeitos”. Portanto, todos os Níveis e Áreas Chaves estão inter-
relacionados numa Matriz de Maturidade de Testes. A Matriz concebeu-se como uma boa
maneira de expressar as prioridades internas e dependências entre Níveis e Áreas Chave. O
eixo vertical da matriz indica Áreas Chave, o eixo horizontal da matriz mostra escalas de
maturidade.
Na matriz, cada nível está relacionado com verdadeira escala de maturidade de testes.
Resultando assim 13 escalas de maturidade de provas. As células abertas entre diferentes
Níveis não têm significado por si mesmas, mas indicam que o conseguir uma maior
maturidade para uma Área Chave está relacionado com a maturidade de outras Áreas Chave.
Não existe graduação entre Níveis: enquanto um processo de provas não esteja classificado
inteiramente como nível B, permanecerá no nível A.
124
Tabela 13 - Matriz de maturidade de teste
Fonte: POL, TEUNISSEN, VEENDENDAAL (2003)
O propósito principal da matriz é mostrar os pontos fortes e fracos do atual processo de testes
e oferecer o suporte na definição de prioridade das ações de melhoria. Uma matriz com dados
reais oferece a todos os participantes uma visão clara da situação atual do processo de testes.
A matriz é utilizada da esquerda para a direita de tal forma que as Áreas Chaves pouco
maduras sejam melhoradas em primeiro lugar. Como conseqüência da dependência entre
Níveis e Áreas Chaves, a prática demonstra que os “campeões isolados” (Áreas Chaves com
alta escala de maturidade rodeadas de Áreas Chaves com escalas de maturidade média ou
baixa ) não são um bom investimento.
Sugestões de Melhoria
As ações de melhoria podem definir-se em função dos Níveis superiores que se desejem
atingir. Para atingir um nível superior, os Pontos de Verificação proporcionam suporte a esta
tarefa. Além destes, o modelo tem outros meios de suporte para a melhoria do processo de
testes: As “Sugestões de Melhoria”, que são diferentes tipos de idéias ou conselhos que
ajudam a atingir um verdadeiro nível de maturidade de testes. A diferença entre os Pontos
125
de Verificação é que o seu uso não é obrigatório. Cada nível está composto de várias
Sugestões de Melhoria.
3.1.6.3 Relação com a Presente Pesquisa
A obra de Pol está relacionada com a presente pesquisa por demonstrar um modelo de
avaliação do nível de maturidade do processo de testes. As práticas exigidas pelo modelo
citado, alinham-se as práticas do CMMI e confirma sua aderência a outros modelos de
avaliação.
126
3.2 CMMI
3.2.1 Implantação do Modelo CMM de Qualidade de Software no Brasil: Estudos de
Caso (Costa, 2000)
3.2.1.1 Objetivo do trabalho.
O objetivo da pesquisa foi verificar, com base em referências teóricas prévias, quais são os
fatores que influenciam, positiva ou negativamente, a implantação do modelo CMM em
organizações de desenvolvimento de software no Brasil.
3.2.1.2 Resultado do estudo.
Como resultado desta pesquisa, os fatores de influência propostos para verificação por
nossa metodologia foram avaliados conforme descrito a seguir.
Nº
FATOR DE INFLUÊNCIA
1
Suporte e monitoração pela Alta Administração. Verificamos uma unanimidade com
relação a este fator, tanto nas referências teóricas quanto nas organizações
pesquisadas. A ausência deste fator sempre causou sérios problemas na implantação
do CMM.
Existe, portanto, uma forte evidência no sentido de que este fator deva
sempre estar presente em uma implantação de CMM, sob o risco de inviabilização do
programa de melhorias.
2
Propensão da gerência a assumir riscos. De modo geral, nossa pesquisa manteve-
se
coerente com as fontes teóricas, isto é, este fator parece ter pouca influência na
implantação do CMM, uma vez que não foi considerado importante em nenhuma das
organizações pesquisadas.
3
Distribuição adequada de responsabilidades. Este fator também confirmou a teoria,
sendo considerado importante, no sentido de que sua ausência dificulta a implantação
do CMM. É interessante observar que este fator pôde ser observado tanto em sua
presença, quando as organizações o consideraram uma ajuda, quanto em s
ua ausência,
quando, em GAMMA, a concentração de responsabilidade nas mãos do SEPG causou
tanto a sobrecarga de trabalho sobre este grupo quanto a percepção de exclusão pelos
desenvolvedores, que se consideraram pouco envolvidos.
4
Entendimento dos proble
mas dos desenvolvedores pela gerência. Neste fator, houve
alguma diferença entre nossas observações e a teoria, que reportou este fator como
irrelevante, isto é, que sua presença ou ausência não influem no processo. Em três das
organizações pesquisadas, considerou-
se que este conhecimento existia e que foi
positivo. Na Quarta organização, levantou-
se que este fator estava presente apenas
parcialmente, e que, quando ausente, a equipe ressentiu-se e considerou esta ausência
como problemática. A falta de maior oportunidade para mais explicações teóricas,
confirmando a noção de que esta ausência é realmente um importante fator negativo,
127
proíbe-nos de afirmá-lo com maior firmeza.
5
Opinião de que a melhoria atrapalha o trabalho real. Confirmou-se que a presença
desta opinião realmente atrapalha a implantação do CMM, gerando resistência e até
mesmo sabotagem por parte dos desenvolvedores que a expressam. Inversamente,
naquelas organizações onde esta opinião não é difundida, as resistências se mostraram
menores, não prejudicando a implantação do modelo. Este fator, portanto, apresenta-
se em nossa pesquisa coerente com a teoria.
6
Envolvimento e respeito ao pessoal técnico. Este é mais um dos fatores cuja presença
ou ausência claramente influenciam a implantação d
o CMM. De forma similar ao
fator 3, fica clara a necessidade de envolver e distribuir adequadamente as
responsabilidades, especialmente entre SEPG e os grupos de trabalho formados pelos
desenvolvedores (PATs), conforme já nos anunciava a teoria.
7
Envolvimento de usuários e clientes. Neste caso, as organizações pesquisadas
claramente se subdividem em dois grupos: um no qual os requisitos de software são
claramente definidos, documentados e controlados (as empresas que desenvolvem
software embarcado); e o outro, no qual a relação com os usuários na definição dos
requisitos de software é mais informal (desenvolvimento de software administrativo).
No caso das empresas de software embarcado, o envolvimento direto dos usuários na
implantação do CMM não existiu
e não causou problemas. Por outro lado, no caso
das organizações de software administrativo, este envolvimento também foi
considerado insuficiente, mas, neste caso, esta ausência foi sentida como empecilho
importante na implantação do modelo. Isto sugere que a necessidade de envolvimento
dos usuários ou clientes varia conforme o tipo de software desenvolvido, ou, mais
especificamente, conforme o grau tradicional de formalização na especificação dos
requisitos de software. Assim, quanto mais informal é a definição destes requisitos,
maior é a necessidade de se envolver os usuários ou clientes no processo de
implantação do CMM.
8
Envolvimento e estilo da gerência média. Este fator não apresentou um resultado
consistente entre as empresas pesquisadas. As múltiplas possibilidades e combinações
de modos de envolvimento e estilos requereriam outras pesquisas mais detalhadas e
focadas para revelar de modo mais confiável este relacionamento. O que ficou
relativamente claro é que existe um impacto substancial da atit
ude do gerente em
relação ao CMM sobre a execução dos processos de software pela equipe por ele
gerenciada.
9
Benefícios tangíveis e recompensas. Em concordância com nossas fontes teóricas, e
Ao contrário do que se poderia imaginar, este fator esteve ause
nte em todas as
organizações pesquisadas, e não foi percebido em nenhuma delas como de maior
importância ou influência na implantação do modelo. Em GAMMA, no entanto,
houve referência a um fator correlato, a avaliação periódica de desempenho, na qual
foi percebida incoerência entre esta avaliação e a aderência dos desenvolvedores aos
processos do CMM. Isto sugere que um estudo mais aprofundado poderia ser feito
para o melhor entendimento das relações entre aderência ao modelo e avaliações de
desempenho.
10
Política organizacional e proteção de espaço. Novamente em concordância com a
teoria, verificou-se que o excesso de política e proteção de espaço dificulta a adoção
do modelo CMM, enquanto a ausência destas atitudes parece facilitar o diálogo e a
cooperação entre áreas e gerências, facilitando o programa de melhorias. Em DELTA,
pode-
se observar uma leve competição entre as diversas áreas, mas, na medida em
que estas são fortemente independentes, isto parece não afetar as atividades do dia-a-
dia da adoção do modelo.
128
11
Desencorajamento e cinismo por tentativas frustradas. Verificou-se que esta atitude,
confirmando a teoria, influi negativamente, se presente, e positivamente, se ausente,
na implantação do CMM na organização. Apenas em GAMMA foi detectada a
presença desta atitude, e verificou-
se a existência de resistência e mesmo sabotagem
onde presente, de modo coerente com a teoria.
12
Alocação adequada de tempo e recursos. Considerada adequada em três das
organizações pesquisadas, a alocação de recursos e
tempo para as mudanças foi
considerada como um fator positivo. Reforçando esta hipótese, na empresa em que
esta alocação foi considerada insuficiente, considerou-se também negativo o impacto
desta ausência, como nos sugeria já a teoria.
13
Assistência ex
terna. Em todas as organizações pesquisadas foi verificado que este
auxílio externo foi considerado essencial. Nas empresas onde este apoio existiu, os
entrevistados opinaram que teria sido muito mais difícil sem ele. Nas demais, opinou-
se que muitos erros teriam sido evitados caso esta ajuda existisse. Observe-se que o
fato de este apoio estar fisicamente presente não parece relevante, uma vez que uma
empresa (ALPHA) contou com auxílio apenas a distância, de parte de sua matriz nos
EUA.
14
Metas de melhoria claramente apresentadas e compreendidas. Confirmando a hipótese
sugerida pela teoria, a apresentação e compreensão claras das metas de melhoria
ajudou quando presente e dificultou quando ausente. Nas empresas em que esteve
ausente, este fator não ajudou os desenvolvedores a entender o porquê das atividades
sugeridas, gerando resistência.
15
Propostas compatíveis com valores da organização. Na empresa em que foram
sugeridas melhorias incompatíveis com os valores da organização, houve muita
resistência na adoção destas melhorias. Nas demais, esta compatibilidade ajudou.
16
Recomendações muito ambiciosas. Ao contrário do que nos sugeriu a teoria, este fator
não pareceu exercer influência consistente no programa de melhorias. Embora se
acreditasse, pela te
oria, que sua presença levaria ao desânimo e, portanto, dificultaria
a adoção do modelo, verificou-
se em duas das empresas que, embora as metas
originais fossem muito ambiciosas, quando foi feita a revisão destas metas não houve
atitudes de desânimo. Ao co
ntrário, a revisão das recomendações para metas mais
realistas surgiu como fator estimulante.
17
Oportunidade de experimentação. Outro fator verificado como coerente com a teoria.
As empresas que usaram-se de projetos piloto consideraram -nos fundamentais
, e as
demais ressentiram-se de sua falta. Ficou claro que tentar implementar os processos
do CMM sem um “teste” que permita correções, adaptações e o aculturamento em
relação ao mesmo gera problemas mais difíceis de corrigir, uma vez que já estão
disseminados e oficializados na organização inteira.
18
Dependência da organização-mãe em relação a software. Este fator mostrou-se
contraditório em relação à teoria. Em tese, todas as quatro organizações pesquisadas
possuem uma forte dependência em relação a software. No entanto, este fato não
parece ter influenciado consistentemente as empresas. Sugere-se, porém, que não é a
dependência em si que conta, mas a percepção desta dependência pela alta
administração. Assim, nas duas empresas em que o software é parte do produto
entregue ao cliente final (software embarcado, ALPHA e DELTA), era clara esta
dependência para a alta administração, garantindo recursos para o programa. Nas duas
outras, o fato de o software ser administrativo parece ter feito com que a percepção de
sua importância pela alta administração tenha sido menor.
19
Ciclo esparso de tecnologia. Fator verificado como coerente com a teoria. Onde a
tecnologia muda menos ao longo do tempo, fica facilitada a implantação do CMM.
129
20
Rotatividade de pesso
al. Como sugeria a teoria, empresas onde a rotatividade é alta
tiveram maior dificuldade na implantação do modelo, devido às necessidades de
retreinamento de novos funcionários e à perda de conhecimento e experiência
associada à saída de funcionários experientes. No entanto, foi observado que a
rotatividade em nível de programação, em algumas das empresas uma atividade
Terceirizada, teve baixo impacto negativo no programa.
21
Mudanças na gerência chave. Em nenhuma das empresas pesquisadas ocorreu este
fato. Assim, embora os entrevistados tenham declarado a ausência deste fator como
positiva, não foi possível a replicação teórica, que reforçaria a hipótese de que a
presença deste fator influenciaria, inversamente, de forma negativa o processo de
adoção do CMM.
22
Mudanças na gerência média e técnicos. Quanto a este fator, não foi possível concluir
a favor ou contra a teoria, já que as empresas pesquisadas apresentaram resultados
contraditórios. Enquanto a presença ou ausência deste fator, em duas das empresas,
tiveram influência respectivamente negativa e positiva no processo de adoção, nas
duas outras, esta mesma presença ou ausência não revelaram influência. Sugere-se
que, naquelas empresas onde não houve influência, os processos do CMM estivessem
melhor i
nstitucionalizados, fazendo com que a dependência de pessoas específicas
fosse menor. No entanto, mais estudos seriam necessários para comprovar esta
hipótese.
23
Grau de formalismo na organização. De modo coerente com a teoria, quanto maior o
nível tradicional de formalismo na organização, maior a facilidade na implantação do
modelo. Inversamente, nas organizações onde este nível de formalismo era menor,
houve maiores resistências.
24
Esforço excessivo de aprendizado. Neste ponto também houve compatibilidade entre
nossa pesquisa e nossa referência teórica. Nas empresas em que este esforço foi
considerado excessivo, percebeu-se uma maior dificuldade na implantação do modelo
em relação a este fator.
25
Porte da organização. Por último, o porte da organização foi considerado importante
em todas as organizações. De fato, constatou-se que quanto maior a organização,
maior a dificuldade em implantar e institucionalizar os novos processos.
Quadro 7 - Fatores de Influência para Adoção do Modelo CMM
Fonte: Costa (2000)
3.2.1.3 Relação com a presente pesquisa
O presente estudo está relacionado com a presente pesquisa por identificar os fatores que
facilitaram ou dificultaram a implementação do CMMI utilizado como ferramenta na
melhoria da qualidade dos produtos e serviços avaliados nesta pesquisa.
130
3.2.2 Os Efeitos da Maturidade do Processo no Esforço de Desenvolvimento de
Software (CLARK, 1997)
3.2.2.1 Objetivo do trabalho:
O objetivo do trabalho de Clark (1997) foi identificar os impactos relacionados no nível de
maturidade do processo de software no desenvolvimento de produtos. O trabalho, teve como
hipótese “o aumento do nível de maturidade do processo de software diminui o esforço
requerido para o desenvolvimento de produtos de software”.
3.2.2.2 Resultados do estudo:
Em 100% dos 12 projetos utilizados na amostra, a maturidade do processo de software foi um
fator de impacto no esforço do desenvolvimento de produtos. Após a estabilização dos efeitos
de outros fatores de alteração de esforço, o processo de maturidade resultou em uma redução
de 15% a 21% no esforço.
3.2.2.3 Relação com a presente pesquisa.
O estudo de Clarck está relacionado com a presente pesquisa por evidenciar os benefícios da
aplicação dos processos baseados no modelo CMMI no desenvolvimento de produtos de
software.
3.2.3 Integrando CMM com Outros Modelos de Qualidade (MELHORETO, 1999)
3.2.3.1 Objetivo do trabalho.
O objetivo do trabalho de Melhoreto (1999), apud Osório (2003) foi traçar o processo
evolutivo dos modelos de maturidade de capabilidade e correlacioná-los com diversos
modelos de qualidade.
Muitas organizações de software desejam estabelecer e manter uma posição
competitiva e forte em relação à qualidade dos fornecedores de sistemas.
Estando a questão “Por quê?” respondida, a próxima questão imediata é “O que deve
ser feito para de adquirir maior capacidade para o desenvolvimento de software?” Essa é a
principal questão abrangida pelos modelos de melhoria de processos. A estrutura de níveis de
131
maturidade e um sistema de avaliação relacionando-os ajudam as organizações a entenderem
suas capacidades. Através da comparação de suas práticas atuais no processo de
desenvolvimento com as apresentadas pelos modelos CMM e SPICE (agora a norma
ISO15504), pode-se verificar quais atividades elas precisam adicionar ou melhorar.
Estando a organização sabendo o que fazer para melhorar o processo de
desenvolvimento, a próxima questão que se impõe é “Como fazer essas melhorias?”. A
questão envolve vários níveis de dimensão de processo. O CMM e a norma ISO 15504
abrangem a dimensão organizacional ou de gerenciamento, o TSP (Team Software Process), a
dimensão de equipes de projeto e o PSP (Personal Software Process), além dos Engenheiros
de Software. Quanto ao gerenciamento, o Grupo de Processos de Engenharia de Software
(SEPG) ajuda a estabelecer a definição, o controle e a melhoria das tarefas que se fazem
necessárias para lançar um programa de melhoria. No próximo nível, o TSP guia as equipes
de projeto e seus gerentes na aplicação de princípios de processo para atingir os objetivos do
projeto. Finalmente, o PSP mostra aos engenheiros (analistas, técnicos, dentre outros) que
desenvolvem produtos de software o caminho para melhorar os seus processos pessoais de
desenvolvimento.
A capacidade organizacional é construída de dentro para fora, enquanto o suporte a
projeto e a motivação da engenharia de software são fornecidos de fora para dentro. Um
funcionamento eficaz nas três dimensões é requerido para que a organização de software seja
plenamente produtiva.
3.2.3.2 Resultados do trabalho
O quadro a seguir mostra o relacionamento entre os Modelos CMM SW v1.1 e SPICE
v1.0.
Nível CMM
Área-chave do processo CMM
Categoria de processo SPICE
2 RM PRO.4
2 SPP PRO.1, PRO.2, PRO.4
2 SPT&O PRO.7
2 SSM PRO.8
2 SQA SUP.3
2 SCM SUP.2, SUP.4
3 OPF
3 OPD ORG.2
132
3 TP ORG.4
3 SPE
3 IC CUS.3, PRO.3, ORG.1
3 ISM
3 PR SUP.5
4 QPM ORG.2
4 SQM PRO.5
5 PCM ORG.1, ORG.3
5 TCM
Quadro 8 - Relacionamento entre os Modelos CMM SW v1.1 e SPICE v1.0
Fonte: DEVELOPERS’ MAGAZINE (1999)
A partir deste quadro, pode-se obter o grau de cobertura do CMM em relação ao
SPICE, ou seja, qual o percentual das atividades descritas no modelo SPICE que está também
descrito no modelo CMM. A partir do grau de cobertura, verificamos quais categorias de
processos presentes no modelo SPICE não são plenamente consideradas pelo modelo CMM.
Esse mesmo relacionamento pode ser efetuado entre os modelos CMM, SPICE e PSP,
considerando-se como critério de comparação todas as atividades que fazem parte do ciclo de
vida do desenvolvimento de software. Cada atividade pode ser implementada como definido
pelo modelo que a possui.
O quadro a seguir apresenta o relacionamento entre as atividades do ciclo de vida de
software com os modelos CMM, SPICE e PSP. A partir desse relacionamento, obtêm-se as
práticas que podem ser realizadas de acordo com o proposto pelos modelos.
Ciclo de vida de desenvolvimento Modelo / Processo
Requisitos e Design de Sistema SPICE / ENG.1
Alocação de Requisitos de Software CMM / Engenharia de Produto de Software
(Atividade 2)
Design de Software CMM / Engenharia de Produto de Software
(Atividade 3)
Codificação CMM / Engenharia de Produto de Software
(Atividade 4)
Revisão de Design e Código PSP / PSP2
Integração do Software SPICE / ENG.5
Teste do Software CMM / Engenharia de Produto de Software
(Atividade 5)
Teste de Integração CMM / Engenharia de Produto de Software
133
(Atividade 6)
Teste de Sistema e Aceitação CMM / Engenharia de Produto de Software
(Atividade 6)
Manutenção do Sistema e do Software SPICE / ENG.7
Quadro 9 - Comparação entre as Atividades do Ciclo de Vida e os Modelos
Fonte: DEVELOPERS MAGAZINE (1999).
Como mostrado no quadro a seguir, o PSP e o TST guiam os engenheiros de software
e as equipes de desenvolvimento em quase todas as áreas-chave do processo do CMM.
Nível CMM Área-chave do Processo PSP TSP
Prevenção de Defeitos X X
Gerenciamento de Mudança de Tecnologia X X
5. Otimizado
Gerenciamento de Mudança de Processo X X
Gerenciamento Quantitativo do Processo X X
4. Gerenciado
Gerenciamento de Qualidade do Software X X
Foco no Processo da Organização X X
Definição do Processo da Organização X X
Programa de Treinamento
Gerenciamento Integrado de Software X X
Engenharia de Produto de Software X X
Coordenação Intergrupo X
3. Definido
Revisão pelos Pares X X
Gerenciamento de Requisitos X
Planejamento do Projeto de Software X X
Rastreamento do Projeto de Software X X
Garantia de Qualidade do Software X
Gerenciamento de Configuração de Software X
2. Repetível
Gerenciamento de Subcontrato de Software
Quadro 10 - Como o PSP e o TSP Abrangem as Áreas-chave do Processo do CMM
Fonte: DEVELOPERS’ MAGAZINE.(1999).
O TSP guia essas equipes no lançamento de seus projetos e no planejamento e
gerenciamento de seus trabalhos. Talvez o mais importante seja o fato de que o TSP mostra
aos gerentes como guiar e treinar suas equipes de software a desempenharem as suas tarefas
da melhor forma. Tendo em vista que o PSP tem por objetivo melhorar a qualidade com que
os engenheiros de software da organização desenvolvem os produtos, é necessário que exista
uma infra-estrutura básica de projeto para que as práticas introduzidas pelo PSP possam ser
exercidas.
134
Um programa de melhoria que vise aumentar a capacidade da organização, da equipe
de projeto e dos engenheiros de software pode implementar as atividades em quatro ciclos.
O foco principal do primeiro ciclo de melhoria será fornecer uma base de
gerenciamento de controle e projeto, além da definição das fases do ciclo de vida de
desenvolvimento da organização.
Tendo-a obtido a infra-estrutura básica de projeto, a organização deve enfocar a
melhoria dos seus desenvolvedores pela adoção do PSP e a implementação de melhoria em
nível organizacional. Essa melhoria organizacional, a ser efetuada em um segundo ciclo, deve
ser independente de projetos e visa consolidar as melhorias implementadas no primeiro ciclo.
Com a introdução do PSP, a organização pode obter dados relevantes para a
introdução do TSP, que tem por objetivo melhorar o rendimento das equipes de
desenvolvimento. Além disso, a organização deve implantar, de maneira qualitativa e
quantitativa, o gerenciamento da qualidade de software. Esse foco do terceiro ciclo da
melhoria.
No quarto ciclo, a organização deve enfocar a melhoria contínua de seus processos
pela implantação do gerenciamento de processos e pela detecção de defeitos. O objetivo desse
ciclo é capacitar a organização a agir pró-ativamente, se prevenindo da ocorrência de
problemas com o processo de desenvolvimento.
O quadro a seguir apresenta os processos a serem implementados em cada um dos
ciclos de melhoria de processos do método integrado, as práticas ou atividades de cada um
dos processos e o modelo correspondente onde tais processos se encontram definidos.
Ciclo Processos Modelos
Definição do Processo da Organização CMM Nível 3
Engenharia de Produto de Software CMM Nível 3
Desenvolvimento de Requisitos e Design do Sistema SPICE ENG.1
Integração e Teste do Software SPICE ENG.5
Manutenção do Sistema e do Software SPICE ENG.7
Definição do Processo SPICE ENG.2
Revisão de Design e Código PSP.2
Gerenciamento de Requisitos CMM Nível 2
Planejamento de Projeto de Software CMM Nível 2
Rastreamento e Supervisão de Projeto de Software CMM Nível 2
1
Gerenciamento de Configuração de Software CMM Nível 2
135
Garantia de Qualidade de Software CMM Nível 2
Aquisição de Produto e/ou Serviços de Software SPICE CUS.1
Identificação das Necessidades do Cliente SPICE CUS.3
Fornecimento de Instalações de Trabalho SPICE ORG.7
Gerenciamento de Mudança de Tecnologia CMM Nível 5
Processo Pessoal de Software PSP
Definição do Processo da Organização CMM Nível 3
Engenharia de Produto de Software CMM Nível 3
Peer Review CMM Nível 3
Foco no Processo da Organização CMM Nível 3
Programa de Treinamento CMM Nível 3
Gerenciamento Integrado de Software CMM Nível 3
Coordenação Intergrupo CMM Nível 3
Gerenciamento de Mudança de Tecnologia CMM Nível 5
Empacotamento, Entrega e Instalação do Software SPICE CUS.5
Fornecimento de Serviços no Cliente SPICE CUS.7
Avaliação da Satisfação do Cliente SPICE CUS.8
2
Facilitação do Reuso SPICE ORG.5
Processo da Equipe de Software TSP
Gerenciamento Quantitativo do Processo CMM Nível 4
Gerenciamento da Qualidade de Software CMM Nível 4
Construção de Equipes de Projeto SPICE PRO.3
3
Suporte à Operação do Software SPICE CUS.6
Prevenção de Defeitos CMM Nível 5
4
Gerenciamento da Mudança do Processo CMM Nível 5
Quadro 11 - Processos a Serem Implementados em Cada Ciclo de Melhoria
Fonte: DEVELOPERS’ MAGAZINE.(1999).
3.2.3.3 Relação com a Presente Pesquisa
Melhoretto (1999) apresenta um método de melhoria que integra as três dimensões do
processo de software:
1. O CMM (Modelo de Maturidade e Capabilidade de Software), referencial teórico
deste estudo;
2. O TSP (Team Software Process), parte da revisão de literatura deste estudo;
3. SPICE (Software Process Improvement and Capability Determination – ISO 15504),
parte da revisão de literatura deste estudo.
Tal estudo demonstra a importância e a abrangência dos modelos de maturidade de
capabilidade, ferramenta utilizada na presente pesquisa.
136
3.2.4 Comparação entre ISO 9001 x CMM (PAULK, 1994)
3.2.4.1 Objetivo do estudo
O artigo de Paulk examina a relação entre dois documentos, com o intuito de
mostrar a diferença entre o CMM – Modelo de Maturidade de Capabilidade de Software e a
norma ISO9001. Foi feito um mapeamento das cláusulas da ISO 9001, relacionando-as com
práticas-chave do CMM. Este mapeamento baseia-se na análise da ISO 9001, da ISO 9000-3,
da TickIT (um guia britânico para a utilização das ISO 9000-3 e 9001) e do material de
treinamento do TickIT. A ISO 9000-3 elabora de modo significativo algumas questões da ISO
9001, enquanto o material de treinamento da TickIT ajuda na interpretação tanto da ISO
9000-3 quanto da ISO 9001.
3.2.4.2 Resultado do Trabalho
A análise envolveu o mapeamento das 20 cláusulas da ISO 9001 com relação a
práticas-chave do CMM desde o nível da sentença até o das subpráticas. É uma análise
confessamente subjetiva - tanto a ISO 9001 quanto a CMM podem ser interpretadas de outras
formas (a confiabilidade e consistência das interpretações e avaliações é um grande desafio
em estimativas baseadas no CMM e/ou na ISO 9001) – o que se espera é que haja
objetividade suficiente para que a análise seja válida para aqueles que perguntem onde a
certificação ISO 9001 cabe em uma estratégia de aprimoramento contínuo da qualidade. O
quadro a seguir apresenta uma visão geral do mapeamento sumário entre a ISO 9001 e o
CMM.
Cláusula da ISO 9001 CMM
Cláusula 4.1: Responsabilidade da
Administração. A ISO 9001 exige
que as organizações definam,
documentem, entendam,
implementem e mantenham uma
política de qualidade;
Definam responsabilidades e
autoridade do pessoal que gerencia,
executa e verifica trabalhos que
afetem a qualidade; e
Identifiquem e forneçam recursos de
verificação.
A designação de um gerente assegura
que o programa de qualidade seja
A responsabilidade pela política e verificação de
qualidade são abordados pelo CMM no nível 2.
Isto inclui a identificação de responsabilidades por
exercer todas as funções do projeto, o
estabelecimento de um grupo treinado para a
Garantia da Qualidade do Software (GQS) e a
designação de supervisão das atividades de GQS à
alta administração da organização.
O CMM identifica como prática dentro das
características comuns a responsabilidade da
administração - tanto no nível da alta administração
como no da gerência de projetos - por supervisionar
o projeto de software, dar apoio a auditorias de
GQS, fornecer orientação e liderança, estabelecer
137
implementado e mantido.
estruturas organizacionais para apoiar a engenharia
de software e alocar recursos.
Pode-se argumentar que esta cláusula também trata
da política de qualidade descrita no nível 4 do
CMM, mas a política de qualidade do nível 4 é
quantitativa.
Cláusula 4.2: Sistema de
qualidade. A ISO 9001 demanda
que as organizações estabeleçam um
sistema de qualidade, incluindo neste
um manual e planos de qualidade,
procedimentos e instruções. Este
sistema de qualidade é caracterizado
pela ISO 9001 como um processo
integrado durante todo o seu ciclo de
vida.
O CMM trata das atividades de sistema de
qualidade no nível 2. Os procedimentos e padrões
utilizados por um projeto de software são
especificados no plano de desenvolvimento de
software. No nível 3, a organização já deve Ter
definidas as tarefas de engenharia de software que
são integradas com processos gerenciais e deve
estar executando-as de forma consistente. Tais
exigências correspondem diretamente à orientação
da ISO 9001 para a interpretação desta cláusula.
O CMM identifica, como prática dentro da
característica comum de Verificação de
Implementação, a auditoria, para assegurar a
conformidade aos padrões e procedimentos
especificados.
Cláusula 4.3: Análise Crítica de
Contratos. A ISO 9001 exige que as
organizações realizem uma análise
crítica de seus contratos para
determinar se os requisitos estão
definidos corretamente, concordam
com o orçamento e podem ser
implementadas
O CMM trata do estabelecimento de contratos no
nível 2. A organização deve documentar e analisar
requisitos de clientes, no que diz respeito aos
softwares, esclarecendo quaisquer requisitos
faltantes ou ambíguos. No entanto, porque a CMM
é restrita à perspectiva do software, os requisitos
dos clientes estão, em geral, além do escopo da
área-chave de processo Gerenciamento de
Requisitos.
Também no nível 2, o CMM descreve a proposta,
descrição de tarefas e plano de desenvolvimento de
software que estabelecem compromissos
(contratuais) externos, revisados pelo grupo de
engenharia de software e a alta administração.
O CMM também trata especificamente de como a
organização pode adquirir softwares por meio da
subcontratação de um cliente externo ou outro tipo
de subcontratado (o fornecedor também pode ser
um cliente). A cláusula de análise crítica de
contratos na ISO 9001 não descreve explicitamente
a função do fornecedor quando este está na posição
de cliente de um subcontratado.
Cláusula 4.4: Controle de Projeto.
A ISSO 9001 exige que as
organizações estabeleçam
procedimentos para controlar e
revisar o projeto. Estes incluem:
Atividades de planejamento, design e
desenvolvimento;
O CMM descreve as atividades do ciclo de vida da
análise de requisitos, design, código e ensaios no
nível 3. O nível 2 trata do planejamento e
rastreamento de todas as atividades de projeto,
incluindo as acima citadas, assim como do
gerenciamento dos produtos de trabalho de
software.
138
Definição de interfaces
organizacionais e técnicas;
Identificação de entrada e saída
Análise crítica, verificação e
validação de projeto; e
Controle de alterações no projeto.
A ISO 9000-3 fornece mais detalhes
sobre esta cláusula, com cláusulas
sobre a especificação de requisitos do
cliente (5.3), planejamento de
desenvolvimento (5.4), planejamento
de qualidade (5.5), design e
implementação (5.6), ensaios e
validação (5.7) e gerenciamento de
configurações (6.1).
A ISO 9001, em sua versão revisada em 1994,
requer análises críticas de projeto. A ISO 9000-3
afirma que o fornecedor deve executar análises
críticas para garantir que os requisitos estão sendo
cumpridos e que os métodos de projeto estão sendo
aplicados corretamente. No entanto, apesar da
exigência de análises críticas de design, há diversas
opções, de revisões técnicas a inspeções, que
podem ser usadas pelas organizações para satisfazer
esta cláusula. O CMM, ao contrário, demanda
especificamente as revisões conjuntas (peer
reviews) no nível 3 e identifica uma série de
produtos de trabalho que devem sofrer tais revisões.
O treinamento da TickIT esclarece a perspectiva da
ISO 9001 listando 3 exemplos de análises críticas
de projeto: inspeções FAGAN, walkthroughs
estruturados e revisões conjuntas (no sentido de
uma revisão sumária). O treinamento também
afirma que “um auditor terá de ficar convencido, a
partir dos procedimentos e registros disponíveis, de
que as análises críticas realizadas na organização
são satisfatórias, considerando o tipo e criticidade
do projeto sendo revisto.”
2
O CMM descreve aspectos mais formais e
quantitativos do processo de design no nível 4, mas
a ISO 9001 não exige este grau de formalidade.
Cláusula 4.5: Controle de
documentos e dados. A ISO 9001
exige que as organizações controlem
a distribuição e as alterações de
documentos e dados.
O CMM descreve no nível 2 as práticas de
gerenciamento de configurações que caracterizam o
controle de documentos e dados e a documentação
exigida para a operação e manutenção do sistema é
listada de modo específico no nível 3. Os
procedimentos, padrões e outros documentos que
podem ser colocados sob o gerenciamento de
configurações são identificados nas diferentes
áreas-chave de processo na característica comum
Atividades Realizadas.
Cláusula 4.6: Aquisição. A ISO
9001 demanda que as organizações
certifiquem-se de que os produtos
adquiridos sigam as exigências
especificadas. Isto inclui avaliar
subcontratados em potencial e
verificar produtos adquiridos.
O CMM aborda o desenvolvimento de software
customizado no nível 2, incluindo a avaliação de
subcontratados e a aceitação e teste de software
cujo desenvolvimento foi terceirizado.
Cláusula 4.7: Controle de produto
fornecido pelo cliente. A ISO 9001
exige que as organizações
A única prática do CMM que descreve a utilização
de software comprado é uma sub-prática do nível 3,
situada no contexto da identificação de programas
2
PAULK (1993a), M.C.; CURTIS, B.; CHRISSIS, M.B. and WEBER, C.V. Capability Maturity Model for
Software. Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24, 1993.
139
verifiquem, controlem e realizem a
manutenção de qualquer material
fornecido pelo cliente. A ISO 9000-3
discute esta cláusula no contexto de
produtos de software embutidos
(6.8), discutindo também programas
de software “de prateleira”.
“de prateleira” ou reutilizáveis como parte do
planejamento. A integração de programas “de
prateleira” e reutilizáveis é uma das área
s mais
fracas do CMM. Na verdade, esta cláusula,
principalmente no modo como foi detalhada e
expandida na ISSO 9000-3, não pode ser
considerada como sendo coberta de modo adequado
pelo CMM. Seria sensato, mas não suficiente,
aplicar a prática de teste de aceitação para
programas subcontratados no nível 2 para qualquer
produto de software incluído.
Foi escrita uma solicitação de mudança para a
versão 1.1 do CMM para que incorpore práticas que
tratem da avaliação de produtos de software e da
inclusão de programas de software “de prateleira” e
outros tipos de programas cujo desenvolvimento
não foi feito internamente.
Cláusula 4.8: Identificação e
rastreabilidade de produto. A ISO
9001 exige que as organizações
possam identificar e rastrear um
produto por meio de todos os
estágios de produção, entrega e
instalação
O CMM cobre esta cláusula essencialmente no
nível 2, no contexto do gerenciamento de
configurações, mas afirma a necessidade de
consistência e rastreabilidade entre produtos de
trabalho de software no nível 3.
Cláusula 4.9: Controle de processo.
A ISSO 9001 demanda que as
organizações definam e planejem
seus processos de produção. Isto
inclui realizar a produção dentro de
condições controladas, de acordo
com instruções documentadas.
Quando uma organização não tem
como verificar completamente os
resultados de um processo após o
fato, deve monitorar e controlar
continuamente o processo. As
cláusulas da ISO 9000-3 incluem
projeto e implementação (5.6),
regras, práticas e convenções (6.5); e,
ferramentas e técnicas (6.6).
No CMM, os procedimentos e padrões a serem
utilizados no processo de produção de software são
especificados no plano de desenvolvimento de
software no nível 2. A definição e integração de
processos de produção de software e as ferramentas
para dar suporte a estes processos são descritas no
nível 3. O nível 4 trata dos aspectos quantitativos do
controle, exemplificados por um controle estatístico
de processos, mas geralmente não é necessário que
a organização demonstre tal nível de controle para
satisfazer esta cláusula. A cláusula 6.6 na ISO
9000-
3 também afirma que “o fornecedor deve
aprimorar essas ferramentas e técnicas conforme
requisitado.” Isto corresponde à incorporação de
entrada de uma nova tecnologia na organização, um
assunto enfocado no nível 5.
Cláusula 4.10: Inspeção e ensaios.
A ISO 9001 exige que as
organizações inspecionem ou
verifiquem materiais recebidos antes
de serem utilizados e que realizem
inspeções e ensaios durante o
processo. A organização também
deve realizar inspeções e ensaios
finais antes de os produtos acabados
serem lançados, mantendo registros
Já foi descrito como o CMM lida com questões
relativas à inspeção de material recebido (“Cláusula
4.7: Controle de produto fornecido pelo cliente”). O
CMM descreve ensaios e inspeções durante o
processo (estritamente para programas de software)
no nível 3.
140
de inspeção e ensaio.
Cláusula 4.11: Controle de
equipamentos de inspeção,
medição e ensaios. A ISO 9001
requer que as organizações
controlem, calibrem e façam a
manutenção de todo e qualquer
equipamento usado para demonstrar
conformidade. Caso seja utilizado
qualquer hardware ou software de
ensaios, este deve ser verificado
antes do uso e verificado novamente
em intervalos definidos previamente.
A ISO 9000-3 esclarece esta cláusula
com cláusulas sobre ensaios e
validação (5.7); regras, práticas e
convenções (6.5); e, ferramentas e
técnicas (6.6).
O CMM aborda esta cláusula de modo geral sob as
práticas de ensaios em Engenharia de Produtos de
Software. A característica comum Capacidade para
Realizar determina o uso de software de ensaio na
prática que descreve ferramentas de apoio aos
ensaios (Habilidade 1.2).
Cláusula 4.12: Status de inspeção e
ensaios. A ISO 9001 exige que as
organizações mantenham o status de
inspeções e ensaios para os itens
enquanto estes passam pelas diversas
etapas de processamento.
O CMM aborda esta cláusula com práticas sobre
relatórios de problemas e status de configuração no
nível 2 e com práticas de ensaios no nível 3.
Cláusula 4.13: Controle de
produto não conforme. A ISO 9001
exige que as organizações controlem
produtos não conformes – aqueles
que não satisfazem requisitos
específicos – para evitar seu uso ou
instalação indevidos. A ISO 9000-3
mapeia este conceito para as
cláusulas de design e implementação
(5.6); teste e validação (5.7);
replicação, entrega e instalação (5.9)
e gerenciamento de configurações
(6.1).
O CMM não trata especificamente de produtos não
conformes. Na ISO 9000-3, a questão do controle
desaparece essencialmente em meio a uma série de
processos relacionados abrangendo todo o ciclo de
vida de software. No CMM o status dos itens de
configuração, que incluiria o status de itens com
defeitos conhecidos mas ainda não consertados, é
mantido no nível 2. O design, a implementação, os
ensaios e a validação são discutidos no nível 3.
Cláusula 4.14: Ação corretiva e
preventiva. A ISO 9001 demanda
que as organizações identifiquem as
causas de um produto não conforme.
A ação corretiva visa a eliminação
das causas de não conformidades
existentes. A ação preventiva visa a
eliminação das causas de não
conformidades potenciais. A ISO
9000-3 cita esta cláusula verbatim,
Uma leitura literal desta cláusula envolveria muitas
das práticas da área chave de processo do nível 5 do
CMM, Prevenção de Defeitos. Segundo o guia de
auditores da TickIT
3
(pág. 139 e 140) e discussões
com auditores da ISO 9001, a ação corretiva é
impulsionada primeiramente por reclamações de
clientes. O g
rupo de engenharia de software deve
observar defeitos de campo, analisar os motivos de
sua ocorrência e realizar ações corretivas. Isto
normalmente aconteceria por meio de atualizações
3
Guia Britânico para a utilização das ISO 9000-3 e 9001) {TickIT] Issue 4.0 of TickIT Guide,
http://www.tickit.org, acessado em dezembro de 2001.
141
sem fornecer detalhes, a partir da
versão de 1987 da ISO 9001.
de software e de remendos (patches) distribuídos
para o programa.
De acordo com esta interpretação da cláusula, ela
poderia ser mapeada para os relatórios de problema
do nível 2, seguido de problema do nível 2, seguido
de manutenção controlada de produtos de trabalho
de linha de base.
Outra interpretação descrita na seção 23 da
literatura de treinamento da TickIT é que a ação
corretiva deve tratar da não conformidade
identificada em uma auditoria, seja ela interna ou
externa. Por esta interpretação, a cláusula pode ser
mapeada para a área-chave de processo do nível 2
do CMM, Garantia da Qualidade do Software.
A interpretação do termo “ação preventiva” é um
ponto controverso na aplicação da ISO 9001 à área
de software. Alguns auditores parecem esperar um
sistema de prevenção de defeitos parecido com o
encontrado em um ambiente de manufatura. Outros
demandam somente que a organização lide com
relatórios de problemas de usuários. O quanto da
análise causal processual do nível 5 do CMM é
necessária para satisfazer esta cláusula é uma
questão passível de discussão.
Cláusula 4.15: Manuseio,
armazenagem, embalagem,
preservação e entrega. A ISO 9001
demanda que as organizações
estabeleçam e mantenham
procedimentos para manuseio,
armazenagem, embalagem e entrega.
A ISSO 9000-3 mapeia isto para
cláusulas sobre aceitação (5.8) e
replicação, entrega e instalação (5.9).
O CMM não cobre a replicação, a entrega ou a
instalação. Ele trata da criação e lançamento de
produtos de software no nível 2 e dos testes de
aceitação no nível 3. Não descreve, entretanto,
práticas para a entrega e instalação do produto.
Paulk (1994) enviou uma solicitação de mudança
para que a versão 1.1 do CMM incorporasse uma
prática para estas áreas.
Cláusula 4.16: Controle de
registros de qualidade. A ISO 9001
determina que as organizações
recolham e mantenham registros de
qualidade.
No CMM, as práticas definindo a manutenção da
qualidade estão distribuídas por meio das áreas-
chave de processo como parte da característica
comum Atividades Realizadas. O relatório de
problemas descrito no nível 2 e as práticas de
ensaios e de revisão conjunta, em especial o
recolhimento e análise de dados de defeitos, são
específicos a esta cláusula.
Cláusula 4.17: Auditoria interna
de Qualidade. A ISO 9001 exige
que as organizações
planejem e
realizem auditorias. Os resultados
das auditorias são comunicados à
administração e quaisquer
deficiências encontradas são
corrigidas.
O CMM descreve o processo de auditorias no nível
2. As práticas de auditorias para garantir a
conformidade com os padrões e procedimentos
estabelecidos são identificadas na característica
comum Verificação da Implementação.
142
Cláusula 4.18: Treinamento. A ISO
9001 determina que organizações
identifiquem necessidades de
treinamento, ofereçam treinamento
(já que determinadas tarefas
selecionadas podem demandar
pessoal qualificado) e mantenham
registros de treinamento.
O CMM identifica necessidades específicas de
treinamento nas práticas de treinamento e
orientação na característica comum Capacidade
para Realizar, descrevendo a estrutura geral de
treinamento, inclusive a manutenção de registros de
treinamento, no nível 3.
Cláusula 4.19: Serviços associados.
A ISSO 9001 demanda que as
organizações realizem atividades
serviços associados, quando tais
atividades fazem parte de um
requisito especificado. A ISO 9000-3
aborda esta cláusula como
manutenção (5.10).
Apesar do CMM ser aplicado tanto no ambiente de
desenvolvimento como no de manutenção de
software, suas práticas não abordam diretamente os
aspectos singulares que caracterizam o ambiente de
manutenção. A manutenção está embutida por todo
o CMM, mas as organizações devem interpretar
estas práticas corretamente no contexto do
desenvolvimento ou no da manutenção. Ela não é,
portanto, um processo separado no CMM.
Solicitações de mudança para a versão 1.0 do CMM
expressaram preocupação com a utilização do
CMM para projetos de manutenção e, a partir disto,
o SEI alterou a escrita na versão 1.1 do CMM para
que se adeqüe melhor ao ambiente de manutenção.
O SEI acredita que este permanecerá sendo um
tópico de discussão, pois oferece orientação para a
adaptação do CMM a diferentes ambientes, como a
manutenção, e começa o novo ciclo de revisões do
CMM com discussões sobre o assunto.
Cláusula 4.20: Técnicas
estatísticas. A ISO 9001 afirma que
as organizações precisam identificar
técnicas estatísticas adequadas e usá-
las para verificar a aceitabilidade da
capacidade dos processos e das
características dos produtos. A ISO
9000-3 caracteriza esta cláusula
simplesmente como medição (6.4).
No CMM a medição de produtos costuma ser
incorporada às várias práticas dentro da
característica comum Atividades Realizadas. A
medição de processos é descrita como parte da
característica comum Medição e Análise.
O nível 3 descreve o estabelecimento de um banco
de dados de processos único para toda a
organização, que serviria para recolher dados de
processos e produtos. É provável que a maior parte
dos auditores aceitem dados de nível de projeto
(como descrito no nível 2) para satisfazer esta
cláusula. No entanto, alguns auditores pelo menos,
exigem um histórico de dados geral de toda a
organização e o uso de gráficos de controle
estatístico simples.
Se a partir desta cláusula inferirmos o controle
estatístico de processos, uma organização a
satisfaria no nível 4. Citando a ISSO 900-3, contudo
“não há atualmente nenhuma medida
universalmente aceita para a qualidade de
software”. Alguns auditores buscam a utilização de
ferramentas estatísticas, como a análise Pareto.
Outros consideram satisfatório qualquer
143
recolhimento e utilização consistente de dados de
medições. Em geral, a única certeza absoluta é que
há uma variação significativa na forma como os
auditores interpretam esta cláusula.
Quadro 12 - Visão Geral do Mapeamento entre uma Cláusula da ISO 9001 e Áreas de
Processo e Práticas-Chave do CMM.
Fonte: DEVELOPERS’ MAGAZINE (1999).
Segundo Paulk (1994) a maior diferença entre os dois documentos é a ênfase explícita
do CMM no aprimoramento contínuo de processos. A ISO 9001 trata apenas dos critérios
mínimos para um sistema de qualidade aceitável. A outra diferença é que o CMM concentra
seu foco exclusivamente em software, enquanto a ISO 9001 tem um escopo muito mais
amplo, englobando hardware, software, materiais processados e serviços.
A maior semelhança entre os dois documentos é a seu princípio essencial: “Diga o que
você faz; faça o que você diz.” A premissa fundamental da ISO 9001 é que as organizações
devem documentar todos os processos importantes e verificar a qualidade de cada um de seus
resultados por meio de uma atividade de controle de qualidade. A ISO 9001 exige que a
empresa tenha documentação que contenha instruções ou orientações sobre o que deve ser
feito ou como deve ser feito. O CMM compartilha dessa ênfase em processos documentados e
praticados como na documentados. Frases como conduzido “de acordo com procedimentos
documentados” e seguindo “políticas organizacionais escritas” caracterizam as áreas-chave de
processo no CMM.
À primeira vista, uma organização com certificado ISO 9001 teria de estar no nível 3
ou 4 do CMM. Na realidade, algumas organizações de nível 1 possuem a certificação. Uma
razão para esta discrepância é o alto nível de abstração da ISO 9001, que faz com que
diferentes auditores a interpretem de diferentes formas. Se o auditor que está certificando a
organização recebeu treinamento da TickIT, por exemplo, as análises críticas de projeto na
ISO 9001 corresponderão diretamente às revisões conjuntas do nível 3 do CMM. Mas nem
todos os auditores possuem bons conhecimentos a respeito de desenvolvimento de software.
A grande virtude de programas como o TickIT é que produzem auditores que entendem como
aplicar a ISO 9001 à área de software.
144
Outro motivo para a discrepância é que um auditor pode não exigir o domínio para que
a cláusula correspondente na ISO 9001 seja satisfeita.
3.2.4.3 Relação com a Presente Pesquisa
O estudo de Paulk mostrou a abrangência do modelo CMM quando comparado com a
norma ISO 9000. O conceito dos níveis de maturidade mostra-se a principal diferença, contra
um conceito de passa/não-passa da ISO 9000.
3.2.5 PMBOK & CMM + CMMI (SOTILLE, 2003)
3.2.5.1 Objetivo do estudo.
O objetivo do trabalho de Sotille foi fazer a comparação entre o PMBOK - Project
Management Body of Knowledge – desenvolvido pelo PMI (Project Management Institute) e
o CMM, correlacionando seus principais aspectos, além de discorrer sobre a evolução desse
último, até a implementação do CMM. O PMBOK é um guia onde se descreve a somatória de
conhecimento e as melhores práticas dentro da área de gerência de projetos. Ele é um material
genérico que serve para todas as áreas de conhecimento, ou seja, tanto para construção de
edifício ou processo de fabricação industrial como para a produção de software.
3.2.5.2 Resultados do estudo
O PMBOK é organizado em áreas de conhecimento e, por sua vez, cada área de
conhecimento é descrita por meio de processos. Cada área de conhecimento se refere a um
aspecto a ser considerado dentro da gerência de projetos. As áreas de conhecimento são:
Gerência de Integração – Envolve os processos necessários para garantir que os
vários elementos do projeto sejam coordenados de forma apropriada. Envolve as negociações
dos conflitos entre objetivos e alternativas concorrentes, com a finalidade de atingir ou
exceder às necessidades e expectativas dos stakeholders interessados.
Gerência de Escopo – Envolve os processos necessários para assegurar que o projeto
contém todo o trabalho necessário para completar o projeto com sucesso. O seu foco principal
está na definição e controle do que está ou não considerado no projeto.
145
Gerência de Tempo – Envolve os processos requeridos para garantir o término do
projeto no tempo certo.
Gerência de Custo – Envolve os processos requeridos para garantir o término do
projeto dentro do orçamento aprovado.
Gerência da Qualidade – Envolve os processos requeridos para assegurar que o
projeto irá satisfazer as necessidades para o qual foi criado. Isto inclui “todas” as atividades
de gerência geral que determina os objetivos, a política e as responsabilidades em relação à
qualidade e suas implementações tais como: planejamento, controle, garantia e melhoria de
qualidade dentro do sistema de qualidade.
Gerência de Recursos Humanos – Envolve os processos requeridos para tornar o uso
mais efetivo das pessoas que estão envolvidas no projeto.
Gerência de Comunicação – Envolve os processos requeridos para assegurar a
geração, coleção, disseminação, dissertação, armazenamento e disposição final de informação
de projeto adequada e apropriada. Provê as ligações acerca de pessoas, idéias e informação
que são necessárias para o sucesso do projeto. Todos os envolvidos devem ser preparados
para enviar e receber comunicações na “linguagem” do projeto e devem entender como as
comunicações individuais afetam o projeto como um todo.
Gerência de Risco – Envolve os processos relacionados à identificação, análise e
resposta aos riscos de projetos. Isso inclui maximizar os resultados de ocorrências positivas e
minimizar as conseqüências de eventos diversos.
Gerência de Aquisição – Envolve os processos requeridos para adquirir bens e
serviços externos à organização.
O autor elaborou uma comparação entre o CMM & PMBOK mostrada na figura a
seguir.
146
Figura 27 - Comparação entre CMM – Nível 2 & PMBOK
Fonte: Sotille (2003)
No estudo apresentado por Jaeger Neto e Bocoli (2002), apud Sotille (2003) são
mostradas as dimensões da competência. Competência é um termo amplamente utilizado, mas
que pode significar coisas diferentes para diferentes pessoas. Geralmente é aceito que
competência envolve conhecimento, habilidades, atitudes e comportamento que podem ser
atribuídos como responsáveis por um desempenho superior na execução de um trabalho.
Competência é um grupo relacionado de conhecimentos, atitudes, habilidades e de
outras características pessoais que:
Afetam a maior parte de um trabalho (isto é, uma ou mais responsabilidades ou
papéis chaves).
147
Estão relacionadas com o desempenho de um trabalho.
Podem ser avaliadas contra padrões aceitáveis de desempenho.
Podem ser aperfeiçoadas por meio de treinamento e desenvolvimento.
Podem ser separadas em dimensões de competência.
No estudo apresentado, as dimensões da competência aplicadas ao gerenciamento de
projetos, são definidas: segundo os mesmos, as dimensões da competência aplicadas ao
gerenciamento de projetos, a competência pode ser descrita em três dimensões separadas:
1. Conhecimento sobre Gerência de Projetos - O que você sabe sobre
gerenciamento de projeto.
2. Desempenho na Gerência de Projetos - Qual a sua habilidade em fazer ou
executar seu trabalho aplicando estes conhecimentos.
3. Competência Pessoal - Qual o seu comportamento pessoal quando está
executando um projeto ou atividade.
3.2.5.3 Relação com a presente pesquisa
O estudo apresentou as similaridades entre o CMM e o PMBOK, demonstrando a
abrangência do segundo e a correlação com o aspecto de gerenciamento de projetos.
3.2.6 Demonstrando o Impacto e Benefícios do CMMI: uma Atualização e Resultados
Preliminares (GOLDENSON & GIBSON, 2003)
3.2.6.1 Objetivo do trabalho
O objetivo do relatório de Goldenson e Gibson foi apresentar os resultados da
utilização do CMMI em 12 estudos de casos em organizações de diversos portes nos Estados
Unidos, Europa e Austrália. As organizações estudadas foram:
Accenture Consulting;
Boeing Australia, Limited;
Bosch Gasoline Systems;
General Motors Information Systems and Services;
JP Morgan Chase;
Lockheed Martin Management & Data Systems;
148
Northrop Grumman Information Technology;
Sanchez Computer Associates, Inc;
Thales Air Traffic Management (ATM); e
Thales Training & Simulation (TT&S).
3.2.6.2 Resultado do estudo
Os autores apresentaram resultados nas áreas de custo, prazos, qualidade, satisfação de
clientes e retorno sobre investimentos (ROI), os quais estão sumariados nas tabelas a seguir:
Tabela 14 - Sumário de benefícios e impactos: RETORNO SOBRE INVESTIMENTOS
Resultados Organização
Modelo
utilizado
ROI de 5:1 para atividades de qualidade Accenture CMMI
ROI de 13:1 calculado na base de defeitos
evitados por horas gastas em treinamento e
prevenção de defeitos
Northrop Grumman
CMMI
Implementados processos para detecção
antecipada de defeitos, melhoria de gerenciamento
de riscos e melhor controle de projetos
implementados após positivos resultados de ROI
de fase piloto
Thales (TT&S) CMMI
Fonte: Goldenson & Gibson (2003)
Tabela 15 - Sumário de benefícios e impactos: PRAZOS
Resultados Organização
Modelo
utilizado
Redução pela metade o tempo requerido para
lançamentos
Boeing CMMI
60% de redução de trabalhos necessários e menos
ações pendentes após os pré-testes e auditorias
pós-testes
Boeing CMMI
Aumento da quantidade de marcos de
desenvolvimento (milestones) atingidos de
aproximadamente 50% para aproximadamente
General Motors CMMI
149
95%
Redução do número médio de dias de atraso, de
aproximadamente 50 para menos de 10
General Motors CMMI
Aumento de velocidade de geração, resultando em
mais transações por ano
JP Morgan CMMI
Aumento de 30% na produtividade de software Lockheed Martin CMMI
Melhoria e estabilização do Índice de Performance
de Schedule
Northrop Grumman
CMMI
Atingimento de todos os marcos (milestones) no
prazo - 25 em seqüência – com alta qualidade e
satisfação dos clientes
Northrop Grumman
CMMI
10% de melhoria no first pass yield (teste
eletrônico), levando à redução no retrabalho
Bosch SW-CMM
15% de melhoria no indicador de entrega interna
no prazo
Bosch SW-CMM
Melhorou a previsibilidade do prazo de entrega J P Morgan SW-CMM
Variação nos prazos de entrega reduziu com o
aumento do nível de maturidade
Thales (TT&S) SW-CMM
Fonte: Goldenson & Gibson (2003)
Tabela 16 - Sumário de benefícios e impactos: CUSTO
Resultados Organização
Modelo
utilizado
Redução de 33% no custo médio para conserto de
defeitos
Boeing CMMI
20% de redução no custo unitário de software Lockheed Martin CMMI
15% de redução no custo de localização e conserto
de defeitos
Lockheed Martin CMMI
4.5% de redução no overhead Lockheed Martin CMMI
Melhoria e estabilização do Índice de Performance
de Custo
Northrop Grumman
CMMI
Economia de US$ 2M nos seis primeiros meses
após a obtenção do nível de maturidade 3
Sanchez Computer SW-CMM
150
20% de redução na variação média de custos Thales (ATM) SW-CMM
60% de redução no custo de aceitação do cliente Thales (ATM) SW-CMM
Variação de custos reduziu com o aumento do
nível de maturidade
Thales (TT&S) SW-CMM
Fonte: Goldenson & Gibson (2003)
Tabela 17 - Sumário de benefícios e impactos: SATISFAÇÃO DE CLIENTES
Resultados Organização
Modelo
utilizado
Aumento de 55% na taxa de prêmio quando
comparado com baseline anterior no nível de
maturidade 2
Lockheed Martin CMMI
Recebimento de mais de 98% das taxas de prêmio
possíveis
Northrop Grumman
CMMI
Obtenção da classificação “Excepcional” em todas
as categorias possíveis de sua pesquisa de
avaliação de performance
Northrop Grumman
SW-CMM
Fonte: Goldenson & Gibson (2003)
Tabela 18 - Sumário de benefícios e impactos: QUALIDADE
Resultados Organização
Modelo
utilizado
Alcançou a meta de 20 +- 5 defeitos por KLOC Northrop Grumman
CMMI
Somente 2% dos defeitos localizados no campo Northrop Grumman
CMMI
Redução nos defeitos de 6.6 por KLOC para 2.1
em 5 ciclos casuais analisados
Northrop Grumman
CMMI
Aumento no foco na qualidade pelos
desenvolvedores
Northrop Grumman
CMMI
Redução dos eventos de erro na fábrica, na faixa
de uma ordem de magnitude
Bosch SW-CMM
Redução no número e severidade dos defeitos pós-
lançamento
J P Morgan SW-CMM
Mais de US$ 2M de economia resultante de
Sanchez Computer SW-CMM
151
detecção antecipada e eliminação de defeitos
Melhoria da qualidade de código Sanchez Computer SW-CMM
Fonte: Goldenson & Gibson (2003)
3.2.6.3 Relação com a presente pesquisa.
O estudo de Goldenson e Gibson mostrou resultados de melhoria de performance em
diversas organizações por conta da implementação do CMMI, que é o parâmetro utilizado na
presente pesquisa para medição do nível de maturidade dos processos de testes.
3.2.7 Explorando o CMMI e ISO 9001:2000. Sinergia no Desenvolvimento de uma
Estratégia de Melhoria de Processos (MUTAFELIJA, 2003).
3.2.7.1 Objetivo do trabalho.
O objetivo do trabalho de Mutafelija e Stromberg foi destacar as similaridades,
diferenças e relações entre o CMMI e as normas ISO 9000 de sistemas de qualidade (versão
2000).
3.2.7.2 Resultado do estudo
Os autores apresentaram, no nível macro, as seguintes comparações, mostradas nos
quadros a seguir:
ISO 9000:2000 CMMI
Norma Modelo
Direção difusa e ampla Detalhado, provendo práticas, subpráticas,
resultados típicos e amplificações
Grupo de requerimentos a serem satisfeitos Etapas progressivas (níveis)
Sem guia para implementação: requer o
estabelecimento de Sistema de Gerenciamento
da Qualidade, mas não explicita requerimento
de institucionalização.
Guia para institucionalização e
implementação, com forte ênfase na
institucionalização por meio de metas
genéricas e práticas genéricas.
Requer interpretação nas organizações com
diversos programas
Acomoda organizações com diversos
programas
Quadro 13 - Similaridades e diferenças
Fonte: Mutafelija e Stromberg (2003)
152
Os autores desenvolveram ainda a comparação com base nos oito princípios da norma
ISO:
1 Foco no cliente:
GP 2.7: Identificar e envolver stakeholders relevantes;
PP (Planejamento do Projeto), SP 2.6: Planejar envolvimento de stakeholders;
RD (Desenvolvimento dos Requerimentos), TS (Solução Técnica); e
CMMI não tão “forte” nesse princípio quanto é a norma ISO.
2 Liderança:
GP 2.1: Estabelecer política organizacional;
GP 2.4: Definir responsabilidades;
GP 2.10: Revisar status com Alta gerência; e
OPF (Foco no Processo Organizacional).
3 Envolvimento das pessoas:
GP 2.3: Prover recursos;
GP 2.5: Treinar as pessoas; e
GP 2.7: Identificar e envolver relevantes stakeholders.
4 Abordagem de processos:
GP 2.2: Planejar o processo;
GP 3.1: Estabelecer um processo definido; e
OPD (Definição do Processo Organizacional), IPM (Gerenciamento Integrado do
Projeto).
5 Abordagem de sistemas:
GP 3.1: Estabelecer um processo definido.
6 Melhoria contínua:
Foco por todo o CMMI na capabilidade e nível de maturidade.
7 Abordagem factual para tomada de decisão:
GP 2.8: Monitorar e controlar o processo; e
PMC (Monitoramento e Controle do Projeto), MA (Medição e Análise), IPM
(Gerenciamento Integrado do Projeto) e DAR (Análise da Resolução e Solução).
8 Relações de benefícios mútuos com fornecedores:
SAM (Gerenciamento de Acordo com Fornecedores);
153
CMMI é menos específico sobre “colaboração”; e
CMMI é mais focado em “controle”.
Como conclusão final, os autores ressaltam o que consideram como a “maior força do
CMMI”, que é sua “ênfase na institucionalização por meio de metas genéricas e práticas
genéricas”. Segundo os mesmos, tal característica é crítica para o sucesso na melhoria do
processo como um todo.
3.2.7.3 Relação com a presente pesquisa
O estudo de Mutafelija e Stromberg comparou as normas ISO 9000 com o CMMI, que
é o método utilizado na presente pesquisa para avaliação do nível de maturidade das
organizações, no que tange seu processo de desenvolvimento de produtos.
3.2.8 CMM e Qualidade: Estudo de Caso DATAPREV (OSÓRIO, 2003)
3.2.8.1 Objetivo do trabalho.
A dissertação de Osório buscou identificar os impactos na qualidade de produtos de software
da empresa de tecnologia e informações da Previdência Social (DATAPREV) sob a ótica do
cliente, ocasionados pela utilização das práticas e proposições do CMM no desenvolvimento
de projetos de software. Tal estudo resultou num derivativo na forma de artigo, publicado por
Quintella e Osório (2003).
Os objetivos do estudo foram:
1. Identificar em que nível do CMM está classificado cada projeto de software da
empresa; e
2. Avaliar a percepção que os usuários têm da qualidade dos produtos de software
gerados pelos projetos.
A hipótese apresentada foi que o uso do CMM (Modelo da Maturidade de Capabilidade
de Software) no desenvolvimento de projetos de software promove a melhora da qualidade
percebida pelo usuário. Os referenciais teóricos foram o instrumento de avaliação de
qualidade de serviço SERVQUAL de Zeithaml, Parasuraman e Berry e o Modelo de
Maturidade de Capabilidade de Software do SEI.
154
3.3.8.2 Tratamento dos dados.
Utilizando-se do método hipotético-dedutivo, a autora realizou pesquisas nos estados do
Rio de Janeiro, Paraná, Santa Catarina, Minas Gerais, Espírito Santo e São Paulo, avaliando
vinte projetos da DATAPREV: 60 gerentes de projeto de software e/ou responsáveis pelo
processo de desenvolvimento identificaram, por meio de questionário próprio o nível CMM
de cada projeto de software. Em seguida, 60 usuários opinaram sobre suas percepções sobre a
qualidade dos produtos de software gerados pelos projetos.
Utilizando o teste t de Student, foi verificado se existia diferença significativa nos
escores médios dos aspectos do SERVQUAL e nas questões individuais entre os dois grupos
estabelecidos no questionário do CMM. A autora adotou o critério de que o projeto
pertenceria ao maior nível cujo escore médio, obtido pelo CMM, fosse maior ou igual a 3.
3.2.8.3 Resultado do estudo.
A autor concluiu que a expectativa dos usuários relativo à “segurança” ou de forma
“geral” estão de acordo com a avaliação dada pelos gerentes. Concluiu também que as
práticas utilizadas pelo CMM promovem a melhora da qualidade, segundo percepção do
usuário.
3.2.8.4 Relação com a presente pesquisa.
A dissertação de Osório apresenta as seguintes características de similaridade com a
presente pesquisa:
Inserida na pesquisa Fatores Humanos e Tecnológicos da competitividade, dirigida pelo
Prof. D.Sc. Heitor Quintella, na Universidade Federal Fluminense;
Utiliza o método hipotético-dedutivo; e
Utilizou modelos de maturidade de capabilidade para avaliação de performance no
desenvolvimento de projetos.
155
3.3 QUALIDADE EM SERVIÇOS (SERVQUAL)
3.3.1 Qualidade dos Serviços na Área de Informática - Um modelo para Avaliação
(MORGADO, WATSON, 2004)
3.3.1.1 Objetivo do trabalho.
O objetivo do artigo dos autores foi avaliar a qualidade dos serviços na área de informática. O
modelo de SERVQUAL foi aplicado a uma organização de médio porte brasileira.
3.3.1.2 Resultado do estudo.
Sobre a empresa onde foi realizada a pesquisa.
A empresa é localizada em uma grande cidade do centro-oeste paulista. Esta empresa,
fundada na década de 30, é líder no setor de produtos de papelaria. Conta com cerca de 1200
funcionários, e figura entre as 500 maiores empresas do país, segundo a classificação da
revista Exame.
A estrutura de Informática desta empresa é baseada em máquinas Digital - um MicroVax
3100/80 e uma VaxStation 4000/90 para o processamento centralizado e uma rede DecNet.
Existem aproximadamente 70 usuários diretos, que trabalham ligados on-line, sendo a maior
parte, aproximadamente 40, por meio de terminais e o restante à partir de microcomputadores
padrão IBM-PC. O número total de usuários diretos da Informática é estimado em cerca de
120 funcionários.
A empresa é altamente informatizada, utilizando sistemas desenvolvidos, em sua maior parte,
internamente. Esses sistemas processam folha de pagamento, cargos e salários, benefícios,
contabilidade, ativo fixo, livros fiscais, controle financeiro, contas a pagar e receber, crédito,
faturamento, estoque de produtos acabados, controle de comissões, estatísticas de vendas,
carteira de pedidos, armazenagem, expedição, DRP - Digitação Remota de Pedidos e o MRP
II para planejamento e controle da produção.
Além dos usuários desses sistemas, existem os usuários da microinformática,
aproximadamente 40 – a maioria ligada em rede, que recebem treinamento terceirizado e
156
suporte pelo Departamento de Informática. O Departamento de Informática conta com 11
pessoas, sendo um gerente, 8 analistas / programadores na área de desenvolvimento e 2
operadores.
A metodologia de pesquisa.
Os questionários foram traduzidos, adaptados da pesquisa Pitt et al (1993), e apresentados à
Gerência de Informática da empresa para os ajustes. Nesta reunião foi definido que os
questionários seriam enviados para todos os usuários diretos dos serviços de Informática. Por
usuários diretos, estimados em 120, entende-se todos os funcionários que utilizassem
terminais ou microcomputadores, de forma regular ou eventual, para suas atividades
profissionais; mais os supervisores e/ou gerentes de áreas usuários. Os funcionários tiveram
duas semanas para responder e enviar de volta os questionários.
Resultados
Foram recebidas 78 respostas, o que representa um índice de resposta de 65%. Os resultados
da pesquisa para todas as questões podem ser vistos no Quadro 1. Os valores obtidos das
Expectativas são bastante elevados, significando que os usuários desta organização são
bastante exigentes, o que pode ser associado ao processo de implantação de um programa de
Qualidade Total pela organização. Apesar disto, as altas avaliações atribuídas à Percepção
fizeram com que os "gaps" não fossem muito elevados. Em termos gerais, podemos dizer que
na visão dos seus usuários, a Informática está um aquém das expectativas.
157
Onde: E=Expectativa e P=Percepção.
Quadro 14 - Resultado da Pesquisa SERVQUAL em Informática
Fonte: MORGADO e WATSON (2004)
Para servir de orientação para os executivos de Informática, diagnosticando quais as
dimensões precisam de mais atenção, é mais útil o Quadro 2, onde podemos ver os "gaps"
para cada uma das dimensões deste modelo de avaliação de qualidade. Os resultados obtidos
foram coerentes com os resultados obtidos por Kavan et al [4:p24], dado que a dimensão
"confiabilidade" é a que tem o maior "gap". Pelos diversos motivos expostos anteriormente, a
área de Informática tem grandes dificuldades para fornecer serviços confiáveis aos seus
usuários. Os usuários, normalmente atribuem à área de Informática uma quantidade muito
grande de responsabilidades, muitas delas fora de seu controle direto, ocasionando esta grande
dissonância para a dimensão "confiabilidade".
158
DIMENSÃO Questões Expectativa
Percepção GAP
Confiabilidade: capacidade para
realizar um serviço prometido de
forma confiável e precisa.
5 a 9 6,76 5,54 -1,23
Prontidão: disposição ou desejo
de ajudar os usuários e a lhes
prestar um bom serviço.
10 a 14 6,46 5,30
-1,17
Tangíveis: visual das instalações
físicas, equipamentos, pessoal e
material de comunicação.
1 a 4 6,16 5,36
-0,81
Empatia: atendimento prestado
aos usuários pautado na atenção
individualizada aos usuários.
18 a 22 6,23 5,62
-0,61
Garantia: conhecimento e
cortesia, que inspiram confiança e
segurança ao usuário.
14 a 17 6,70 6,25
-0,46
GAP TOTAL -0,856
Quadro 15 - Tabulação Geral dos "Gaps" pelas Dimensões.
Fonte: MORGADO e WATSON (2004)
Para a gerência da Informática, o Quadro 2 fornece uma visão mais clara sobre quais aspectos
deverão ser objeto de atenção. A estratégia a ser utilizada para melhorar o "gap" de cada uma
das dimensões pode ser diferente, pois como já vimos, é possível atuar tanto na redução de
expectativas como na melhoria da percepção dos usuários.
Para aumentar o refinamento desta análise, podemos construir o Quadro 3 onde é possível
comparar a visão dos usuários Gerentes/Supervisores, com a visão dos usuários Operacionais.
DIMENSÃO Gerentes
Supervisores
(11 usuários)
Operacionais
(67 usuários)
Confiabilidade: capacidade para realizar um
serviço prometido de forma confiável e precisa.
-1,44 -1,19
Prontidão: disposição ou desejo de ajudar os
usuários e a lhes prestar um bom serviço.
-1,27 -1,15
Tangíveis: visual das instalações físicas, -0,09 -0,93
159
equipamentos, pessoal e material de
comunicação.
Empatia: atendimento prestado aos usuários
pautado na atenção individualizada aos usuários.
-0.67 -0,60
Garantia: conhecimento e cortesia, que inspiram
confiança e segurança ao usuário.
-0,41 -0.47
Quadro 16 - Comparação de visão entre Gerentes/Supervisores e Usuários pelas Dimensões.
Fonte: MORGADO e WATSON (2004)
Como vemos, não ocorrem alterações na ordem de classificação das dimensões, entretanto
podemos observar que existe uma grande diferença de visão quanto à dimensão "tangíveis" e
uma pequena diferença em relação à dimensão "confiabilidade". Os quadros 2 e 3 podem ser
de grande utilidade para os gerentes e a equipe de Informática discutirem causas e alternativas
de melhoria.
3.3.1.3 Relação com a presente pesquisa.
O estudo de Morgado e Watson mostrou aplicação e os resultados da avaliação da
qualidade percebida pelo cliente na prestação de serviços de informática, corroborando com a
adoção do questionário SERVQUAL na avaliação dos processos de testes de software,
utilizados nesta pesquisa.
3.3.2 Qualidade em Serviços Liderança Gerencial nas Empresas de Informática
(ALVARADO, 2001)
3.3.2.1 Objetivos do Estudo
Comparar as percepções expectativas dos clientes sobre a qualidade dos serviços de
informática.
Comparar as expectativas dos clientes sobre a qualidade dos serviços de informática com
as percepções que as empresas de informática têm dessas expectativas.
Identificar qual a importância relativa das dimensões de avaliação da qualidade dos
serviços de informática do ponto de vista das empresas de informática e seus clientes.
Comparar o nível de liderança dos executivos das empresas de informática com sua
percepção das expectativas dos clientes sobre a qualidade do serviço.
160
3.3.2.2 Referencial Teórico Empregado
O trabalho de dissertação de Alvarado, Williams (2001) é baseado nos livros
“Delivering Quality Service” (Zeithalml, Parasuraman & Berry, 1990) “Serviços de
Satisfação Máxima” (Berry, 1996), foram utilizados no que diz respeito à avaliação da
qualidade do serviço. O livro “O Desafio da liderança” (Kouzes e Posner, 1997) foi utilizado
para a avaliação dos princípios básicos da liderança.
3.3.2.3 Tratamento do Dados
A pesquisa foi realizada com 19 executivos de oito empresas de informática de médio e
grande porte que realizam atividades relacionadas a prestação do serviço.
As empresas que foram relacionadas inicialmente para a pesquisa são: IBM Brasil,
Unisys, SID Informática, Gtech, Hew lett-Packard, EDS, ADP Systems e Cobra.
Também participaram desta pesquisa 15 executivos de cinco empresas clientes que
exercem atividades relacionadas a área de informática.
As empresas clientes foram fornecidas pelas empresas de informática pesquisadas, são
elas: Dannemann Siemsen Bigler, Fundação Ary Franzino, AIG Brasil Interamericana, Banco
Real, Companhia de Eletricidade do Rio de Janeiro.
Os entrevistados selecionados foram: gerentes, coordenadores e supervisores. Foram
utilizados testes para avaliar a qualidade dos serviços de informática SERVQUAL tanto para
as empresas de informática e seus clientes, e como também testes de práticas de liderança LPI
– nas empresas de informática.
A coleta de dados no campo foi feita em duas etapas, a saber:
A primeira etapa consistiu em entrevistas individuais aos executivos das empresas de
informática com atividades relacionadas à área de serviço ao cliente.
A segunda etapa consistiu em entrevistas com executivos da empresas clientes, com
atividades relacionadas à área de informática.
Nas etapas acima foram utilizados os questionários: SERVQUAL e LPI.
161
3.3.2.4 Resultados do Estudo
Os dados obtidos por meio dos questionários, foram tabulados utilizando o Microsoft Excel
97. O conjunto de dados obtidos foram correlacionados para testar as hipóteses formuladas.
As hipóteses 1, 2 e 3 foram verificadas por meio de testes paramétricos – t student –
assumindo populações com distribuição normal. Já para testar a hipótese 4, foi feito uma
análise de regressão linear simples e aplicado o teste de significância da regressão.
3.3.2.5 Relação com a Presente Pesquisa
O trabalho de Alvarado, Williams (2001) serviu de referência para este trabalho
quanto ao instrumento para avaliar a qualidade dos produtos de software (SERVQUAL). O
SERVQUAL é um instrumento de escala múltiplo com alto nível de viabilidade e validez,
baseado na definição conceitual da qualidade do serviço e em cinco dimensões que
encontram-se na pesquisa feita, que ajuda as empresas a compreender melhor as expectativas
e percepções que os clientes têm com respeito ao serviço.
De forma semelhante ao trabalho de Alvarado, Williams, este estudo empregou o método
hipotético dedutivo de Popper que se inicia pela percepção de uma lacuna nos conhecimentos,
acerca da qual se formulam as hipóteses, pelo processo de inferência dedutiva e se testa a
predição da ocorrência de fenômenos abrangidos pela hipótese. Alvarado, Williams formulou
quatro hipóteses, neste estudo, foi formulada uma única hipótese.
3.3.3 Qualidade em Serviços e Liderança: Avaliação dos Serviços Internos de
Informática em uma Grande Empresa. (CRISÓSTOMOS, 2002)
Segundo Crisóstomo, Antônio (2002) a pesquisa teve por finalidade analisar a
qualidade dos serviços informáticos em uma grande empresa (CERJ), após a terceirização dos
mesmos e, por outro, comparar as ações levadas a cabo pelos executivos da empresa com as
características de liderança defendidas por Kouzes e Posner. O objetivo é observar como é
que os serviços de informática, prestados por uma empresa terceirizada, são vistos pelos
162
funcionários da CERJ, além de analisar se as ações levadas cabo pelos seus executivos estão
de acordo com as características de liderança.
3.3.3.1 Objetivo do Estudo
O objetivo da sua pesquisa foi:
“Comparar as percepções e expectativas dos usuários com o que eles efetivamente
percebem como resultado do serviço percebido, e dessa forma julgar se eles estão encantados,
satisfeitos ou insatisfeitos com tal serviço.
Analisar, dentro das dimensões de qualidade em serviços, quais as dimensões que os
usuários dos serviços de informática da CERJ atribuem uma importância maior.
Comparar o nível de liderança dos executivos da CERJ com relação aos níveis de
liderança considerados ideais, segundo Kouzes&Posner, além de perceber se seus atos levam
a um serviço de qualidade.”
3.3.3.2 Metodologia Aplicada no Estudo
O universo da pesquisa foi o conjunto de todas as empresas de energia elétrica e
esteve representado pelo conjunto de todas as empresas de energia elétrica da Companhia de
Eletricidade do Rio de Janeiro – CERJ, de grande porte. Neste sentido se considera a empresa
como uma componente das 4 (quatro) regionais e a administração central, levando em conta
todas as agências e centros operativos da empresa, espalhados pelo interior do estado do Rio
de Janeiro.
A pesquisa foi enviada a 300 usuários dos recursos computacionais lotados no prédio
da administração central e nas distintas regionais, centros operativos e agências da empresa.
Em relação à questão liderança foram feitas entrevistas com 22 executivos das
diversas áreas da empresa, representando todas as diretorias onde se tentou mostrar visão
sobre a forma pessoal de exercer a liderança.
A coleta de dados no campo se deu da seguinte forma: num primeiro momento foram
realizadas entrevistas (individuais) com os executivos da amostra tentando ver o nível de
163
exercício de liderança, tendo sido utilizado o questionário SERVQUAL. Num segundo
momento, foram enviados questionários aos usuários dos serviços de informática da CERJ,
tendo sido utilizado o questionário SERVQUAL.
3.3.3.3 Resultados do Estudo
Segundo Crisóstomo, Antônio (2002), a primeira hipótese surge da existência de
diferenças entre as percepções e expectativas que os usuários das empresas de informática têm
da qualidade dos serviços de informática. Os dados referentes a esta hipótese comprovaram a
existência de discrepâncias entre as percepções e expectativas dos usuários em todas as
dimensões de avaliação da qualidade dos serviços de informática. Foi concluído que os
serviços de informática prestados pela prestadora de serviços da CERJ são vistos, pelos
usuários, como sendo de baixa qualidade, em algumas declarações e dimensões.
A segunda hipótese de estudo investigou quais dimensões, dentre as dimensões da
qualidade em serviços, os usuários atribuem uma maior importância, pré-concebendo a
dimensão confiabilidade. A dimensão confiabilidade foi considerada, mais importante pelos
usuários.
A terceira hipótese investigou as ações dos executivos da CERJ com relação à
liderança, prevendo que dentre os princípios haveria uma certa predominância o princípio
permitir que os outros ajam. Foi conformado que o princípio de permitir que os outros ajam é
o predominante em relação aos outros princípios.
3.3.3.4 Relação com a Presente Pesquisa
O estudo de Crisóstomo mostrou aplicação e os resultados da avaliação da qualidade
percebida pelo cliente na prestação de serviços de informática, alinhando-se a aplicação
questionário SERVQUAL na avaliação dos processos de testes de software, utilizados nesta
pesquisa.
164
3.4 ISO/IEC 9126
3.4.1 Aplicando o Modelo ISO/IEC 9126 para Avaliação de Sistema E-Learning (Chua,
Dyson, 2004)
3.4.1.1 Objetivo do trabalho.
O objetivo do trabalho foi aplicar uso do Modelo de Qualidade ISO 9126 como ferramenta
para a avaliação de sistemas E-Learning, especialmente para professores e administradores
educacionais. Os autores demonstram a validade do modelo num estudo de caso em que o
aplicam a um sistema de e-learning disponível e mostram como pode ser usado para detectar
falhas de projeto. É proposto que a métrica pode ser aplicável a outros sistemas de e-learning
e que pode ser usada como base para a comparação entre sistemas.
3.4.1.2 Metodologia Aplicada no Estudo
Os pesquisadores usaram as características e sub-características de qualidade para avaliar um
sistema de e-learning, o Blackboard v6.1. Do ponto de vista do educador, as primeiras três
características (Funcionalidade, Confiabilidade e Usabilidade) e a primeira sub-característica
de Eficiência (Comportamento ao longo do Tempo - Time Behaviour) são facilmente
avaliáveis, enquanto as outras características são difíceis de serem avaliadas a não ser por
profissionais de TI treinados (Valenti et al. 2002). A avaliação foi feita observando o uso do
sistema Blackboard por estudantes e professores de uma cadeira, durante um semestre. A
cadeira estava sendo ensinada em uma faculdade de Tecnologia da Informação e os estudantes
tiveram alguma experiência na utilização do sistema numa cadeira do semestre anterior. Os
estudantes usaram o sistema tanto no ambiente de sala de aula assim como fora. Em nossa
investigação, vários métodos de avaliação foram usados. Primeiro, foi focado no uso sistema
observando os estudantes enquanto os ensinávamos durante o semestre. Depois a própria
experiência como professores foi registrada. Depois as contribuições dos estudantes e
professores para listas de discussão dentro do sistema de e-learning foram examinadas como
evidência de atividade. Depois testamos as várias ferramentas dentro do sistema baseados nas
características e sub-características do modelo ISO 9126, incluindo timing, detecção de falhas
e usabilidade geral e funcionalidade. Em geral, a avaliação foi qualitativa, apesar de que para
avaliar a sub-caracterísitica Comportamento ao Longo do Tempo (Time Behaviour), foi
165
conduzido um teste de performance do sistema em dois computadores diferentes, um mais
antigo e um mais novo, uma máquina rápida, ambos operando numa rede rápida, de 100Kbps.
O teste de performance foi feito em classe, quando até 120 estudantes acessavam o sistema
simultaneamente.
3.4.1.3 Resultado do estudo.
Os resultados foram sumarizados numa tabela (adaptada de Abel e Rout (1993)) relacionando
as características e sub-características de às principais ferramentas oferecidas pelo sistema de
e-learning. Um asterístico na tabela significa que a ferramenta satisfaz os requisitos da sub-
característica. As deficiências são indicadas por um número e uma explicação sobre elas é
dada na legenda abaixo.
Tabela 19 - Características de qualidade x tarefas
Fonte: Chua e Dyson, (2004)
166
Legenda:
1. Aceita conteúdo nulo quando não deveria.
2. A falta de indicações de campos obrigatórios dificulta o uso.
3. O tamanho das fontes é muito pequeno. Grandes inconsistências entre as fontes das páginas.
4. Quando foi feito o upload de uma foto de um membro do staff que tinha o tamanho fora do padrão, uma
mensagem incorreta foi exibida.
5. O sistema não checa a validade de datas de quando o material de ensino estará disponível.
6. Navegação ruim. Um menu de botões de navegação é necessário, ao invés do botão existente, e estes deverão
ser nomeados de forma mais clara, de acordo com as suas funções.
7. Carregar a página do grupo foi muito lento quando muitos usuários estavam on-line.
8. Problema com a interpretação de terminologia não padronizada.
9. A sala de bate-papo inicializa muito lentamente devido a necessidade de se instalar um plugin Java.
10. Não se pode salvar ou exportar desenhos no sistema.
11. Devido ao fato de o upload de gráficos e desenhos ser anônimo, houve problemas com o envio de imagens
pornográficas.
12. A função de alguns botões não foi de fácil compreensão. Dicas são necessárias.
13. Houve um problema de sincronismo, pois há um intervalo de tempo entre o momento em que um estudante
desenha algo e quando estudantes conseguem ver.
14. Funcionalidade ruim e difícil de entender como usar. Incapaz de exibir uma lista.
15. Não é possível pesquisar pelo primeiro nome do usuário e não há como listar todos os membros de um
grupo. O botão Listar, então, é difícil de compreender.
16. O sistema não suporta descrições longas de grupos sendo criados.
17. Adicionar um estudante a um grupo necessita de sete cliques no mouse dê um lado da tela ao outro para cada
estudante. A maioria dos botões envolvidos não podem ser ativados pelo teclado. Isso tem impacto no Time
Behaviour.
18. A ordem dos grupos não é em ordem alfabética.
19. Layout inconsistente.
Discussão
Pela avaliação, os pesquisadores descobriram muitas falhas no sistema. Algumas são críticas
para a satisfação do cliente e algumas são menores. Isso depende de quem é o usuário
(coordenador da cadeira, professor ou estudante). O modelo ISO 9126 fornece uma indicação
para os educadores e administradores educacionais da qualidade de um sistema que eles
estejam considerando comprar e fornece uma base de comparação entre sistemas.
Apesar de os nossos resultados demonstrarem que o modelo ISO 9126 é útil na avaliação de
sistemas de e-learning, os pesquisadores também têm algumas recomendações de melhorias.
Primeiro, acreditamos que ele pode ser melhorado se passar a ter uma característica global
para sumarizar a satisfação geral dos usuários. Para determinar o nível de satisfaçào dos
usuários, não é possível simplesmente somar o número de sub-características com problemas.
Usuários diferentes terão prioridades diferentes que influenciarão em que características eles
colocarão maior ênfase. Com isso, precisamos considerar a incorporação de uma característica
final para o usuário determinar se a ferramenta que está sendo avaliada é aceitável ou não. Em
167
segundo lugar, a sub-característica Aparência é muito vaga e cobre muitos fatores diferentes e
por isso não ajuda muito. É recomendado que as sub-características sob Usabilidade sejam
estendidas para incluir fatores ligados a apar6encia mais específicos, baseados nos princípios
aceitos de Usabilidade HCI. Por exemplo, Usabilidade deveria incluir as sub-características
consistência, simplicidade, legibilidade e uso de cor (Preece, Rogers & Sharp, 2002).
3.4.1.4 Relação com a presente pesquisa.
O estudo de CHUA e DYSON mostrou aplicação do modelo de avaliação da qualidade de
produtos de software direcionados a educação a distância. Sua utilização corrobora para a
aplicação questionário ISO/IEC 9126 na avaliação dos produtos de software, utilizados nesta
pesquisa.
3.4.2 Análise da Qualidade de Software de Gestão Empresarial utilizando a Norma
ISO/IEC 9126 (SCARTON e NAU, 2002)
3.4.2.1 Objetivo do trabalho.
O trabalho de SCARTON e NAU teve como objetivo avaliar a qualidade de um software,
baseado na Norma ISO/IEC 9126.
168
3.4.2.2 Metodologia Aplicada no Estudo
Definição de Requisitos de Qualidade
Tabela 20 - Definição de requisitos de qualidade
Fonte: SCARTON e NAU (2004)
Definição dos Níveis de Pontuação
Os níveis de pontuação são os valores que os usuários utilizarão para avaliar cada um dos
requisitos de qualidade. Estes valores não expressam o grau de qualidade do software .
Os níveis de pontuação disponibilizados são visualizados na tabela 21.
169
Tabela 21 - Definição dos níveis de pontuação
Fonte: SCARTON e NAU (2004)
Definição dos Critérios de Julgamento
Os critérios de julgamento devem estar previamente estabelecidos para que seja possível
realizar o julgamento imparcial do grau de qualidade de cada uma das características de
qualidade do software. O grau de qualidade de cada uma das características de qualidade a
serem avaliadas é calculado da seguinte forma:
1. Calcula-se o percentual relativo de qualidade da característica sendo analisada, utilizando a
Fórmula 1 mostrada no quadro a seguir:
Quadro 20 - Cálculo do percentual relativo de qualidade
Fonte: SCARTON e NAU (2004)
2. Aplica-se o valor calculado no passo 2 à Tabela 22, a qual define a faixa de valores dos
graus de qualidade.
170
Tabela 22 - Definição dos graus de qualidade
Fonte: SCARTON e NAU (2004)
Caso algum usuário não tenha respondido alguma das perguntas, por não ser de seu
conhecimento ou por qualquer outro motivo, será atribuído o valor “Total ausência” para a
resposta.
Medição
A forma de medição dos requisitos de qualidade do software será a aplicação de questionários
aos usuários do software, conforme descrito na seção “2.1 Definição de requisitos de
qualidade”. Contudo, a Norma ISO/IEC 9126 define características de qualidade que podem
ser avaliadas por todos os usuários e características que podem ser avaliadas apenas por
determinados usuários (como a manutenibilidade – neste caso os usuários seriam os
desenvolvedores), dependendo do domínio de aplicação e do tipo de usuário. Para o software
sendo avaliado, os questionários serão aplicados a 4 usuários, os quais estão descritos na
Tabela 23, sendo que eles são de áreas distintas dentro da empresa. Sendo assim, serão
aplicados questionários diferentes aos usuários, dependendo da área de atuação de cada um
deles.
Tabela 23 - Usuários que responderam questionário
Fonte: SCARTON e NAU (2004)
171
Pontuação
Após aplicados os questionários aos usuários da Tabela 21, foram contabilizadas as respostas
dos mesmos. Na tabela 24 são apresentadas as pontuações de cada resposta de cada usuário
para cada pergunta. Já na tabela 25 são visualizadas as pontuações das características da
Norma ISO/IEC 9126 de cada usuário.
Tabela 24 - Pontuação de cada resposta de cada usuário
Fonte: SCARTON e NAU (2004)
172
Tabela 25 - Pontuação das características da Norma ISO/IEC 9126 por usuário
Fonte: SCARTON e NAU (2004)
3.4.2.3 Resultado do estudo
Seguindo os critérios de julgamento que foram definidos para esta avaliação, e com base na
pontuação obtida, o resultado do julgamento das características da Norma ISO/IEC 9126 é
visualizado na Tabela 26 (o resultado também é visualizado por meio do Gráfico 4).
Tabela 26 - Julgamento do grau de qualidade do software por características da Norma
ISO/IEC 9126
Fonte: SCARTON e NAU (2004)
Gráfico 4 - Resultado do julgamento do grau de qualidade do software por características
Fonte: SCARTON e NAU (2004)
173
Avaliação
Com base na Tabela 26 podem ser feitos alguns comentários para as características de
qualidade, os quais são feitos abaixo:
Funcionalidade. O resultado tão positivo que foi obtido é justificado pelo fato de que o
software foi desenvolvido para atender as necessidades da empresa. Portanto, possui
todas as funções de que os usuários necessitam.
Confiabilidade. O ponto forte desta característica é a preocupação que o software tem
com a garantia da integridade das informações. E pode-se justificar a não obtenção de
um resultado melhor para esta característica, pelo fato de terem sido feitas algumas
perguntas relacionadas ao backup. Pois, como o backup das informações do software
é feito por um gerente de informática, o usuário final não tem contato com backups
(tanto que o software não disponibiliza aos mesmos esta opção), as respostas a estas
perguntas acabaram baixando o nível de qualidade do software avaliado para esta
característica. E no caso de futura comercialização do software deve-se estudar se será
necessário disponibilizar estas opções aos novos usuários ou não.
Usabilidade. O ponto forte do software é a padronização na utilização dos jargões do
domínio da aplicação e na definição dos layouts das telas e relatórios. O ponto fraco é
a ausência de manuais de utilização do software, porém é justificado pelo fato do
software ainda não estar sendo comercializado e por ser desenvolvido pela própria
empresa, desta forma qualquer dúvida que o usuário final tenha ele pode se dirigir à
equipe de desenvolvimento do software. Além da questão do manual, há também
outro ponto que merece destaque, que é a necessidade de melhorar as mensagens
exibidas aos usuários, para que as mesmas sejam mais facilmente compreendidas
pelos usuários.
Eficiência. Esta é uma característica que possui a sua avaliação num estágio
preocupante, pois fica próximo do valor de julgamento “bom”. Esta preocupação é
justificada pelo fato do software utilizar os recursos da Internet para que o usuário
acesse o software, portanto as rotinas do software devem priorizar o desempenho, uma
vez que quanto maior for o número de usuários acessando ao mesmo tempo o
software, maior será a probabilidade de baixar o desempenho do mesmo.
Manutenibilidade. Pode-se notar que a preocupação com a legibilidade é ponto forte
do software. E o ponto fraco do mesmo é a questão de testes, o qual deverá ser revisto
para evitar futuros problemas quando o software começar a ser comercializado fora da
empresa.
174
Portabilidade. Com relação à portabilidade o ponto fraco do software gira em torno da
plataforma sob a qual ele pode ser utilizado, que é máquinas Unisys e browser
Microsoft Internet Explorer versão 5.5 ou superior. Porém, deve-se destacar o fato do
software utilizar os recursos da internet para o usuário acessa-lo, pois desta forma, por
exemplo, um gerente poderá acessar o software em qualquer lugar que esteja (desde
que possua os requisitos mínimos para se conectar à Internet).
Conclusão
A medição da qualidade de software é uma área importante na gerência de projetos, pois
possibilita que os gerentes e os profissionais envolvidos no processo de desenvolvimento de
software aprimorem os processos aplicados no desenvolvimento do software. Isto porque, a
qualidade do software tem relação direta com a qualidade do processo de desenvolvimento
do software.
Portanto, é importante que sejam aplicados mecanismos de avaliação da qualidade do
software, como a Norma ISO/IEC 9126, para poder identificar as características de menor
qualidade do software. E então, posteriormente poder utilizar estes dados para tentar rastrear
qual etapa do desenvolvimento de software pode ter causado o baixo índice de qualidade para
a característica em questão.
No que diz respeito ao software avaliado, como as medidas de qualidade adotadas para esta
avaliação não foram medidas exatas (são medidas subjetivas), podem haver alguns resultados
divergentes, dependendo das pessoas para as quais forem aplicados os questionários.
Sendo que vários fatores poderiam interferir, como por exemplo, tempo de uso do software
pelo usuário e nível de conhecimento do domínio da aplicação. Para evitar este problema da
divergência de resultados na avaliação do software deste trabalho, poderiam ser consultado
um número maior de usuários do software, porém como o escopo deste trabalho é acadêmico,
fica a sugestão de realizar isto no futuro (por parte da empresa proprietária do software), caso
seja de interesse do gerente de desenvolvimento do software avaliado.
3.4.2.4 Relação com a presente pesquisa.
O estudo de SCARTON e NAU mostrou aplicação do modelo de avaliação da qualidade de
produtos de software, alinhando-se a aplicação questionário ISO/IEC 9126 na avaliação dos
produtos de software, utilizados nesta pesquisa.
175
4 METODOLOGIA
4.1 TIPO DE PESQUISA
Os critérios para a classificação dos tipos de pesquisa variam de acordo com o enfoque
dado pelo autor.
Conforme a classificação proposta por Auder-Egg (apud Marconi e Lakatos, 1996),
esta dissertação pode ser classificada quantos os fins, como pesquisa aplicada e descritiva.
Aplicada, porque se caracteriza por seu interesse prático, em que os resultados sejam
utilizados na solução de problemas que ocorram na realidade.
Descritiva, porque aborda quatro aspectos: descrição, registro, análises e interpretação do
problema, objetivando seu funcionamento no presente.
Conforme a classificação proposta por Marconi e Lakatos (1996), esta dissertação
pode ser classificada, quanto aos meios, como pesquisa de campo com caráter exploratório.
De campo, porque é utilizada com o objeto de conseguir informações e/ou
conhecimentos acerca do problema, para o qual procuramos uma resposta, por meio de
fatos e fenômenos tal como ocorrem espontaneamente, na coleta de dados a eles
referentes e no registro de variáveis que se presumem relevantes para analisá-las.
Exploratória, porque visa a formulação do problema, com a finalidade de desenvolver
hipóteses, aumentar a familiaridade do pesquisador com um ambiente, fato ou fenômeno,
para a realização de pesquisas futuras ou modificar e clarificar conceitos.
A pesquisa também apresenta características de pesquisa de ação. Segundo Quintella
(1994), o objetivo da pesquisa de ação é desenvolver novas aptidões com a aplicação direta
do estudo ao mundo real. As características da pesquisa de ação são:
Ser de natureza prática e diretamente relevante a uma atuação real no mundo do trabalho.
Nesta dissertação, o problema é totalmente prático e a análise feita pode auxiliar as
empresas no processo de desenvolvimento de software e serviços de testes.
176
Ser de natureza empírica por estar apoiada em observações reais de opinião e de
comportamento.
As hipóteses e as questões-chave desta pesquisa estão apoiadas nas situações reais
que vivem as empresas e nos itens dos questionários utilizados.
Prover uma estrutura ordenada para resolução de problemas e novos desenvolvimentos.
A dissertação está estruturada em hipóteses e questões-chave que são analisadas
com base nos questionários respondidos pelas empresas e seus clientes, que nos permitem
fazer novas formulações para a realização de uma pesquisa futura.
Ser flexível e adaptável, permitindo mudanças durante o período de experimentação e
sacrificando o conceito de controle sobre variáveis em favor de experimentações locais e
inovações nos métodos de investigação e coleta de resultados.
4.2 MÉTODO DE ABORDAGEM
O método de abordagem utilizado para a presente dissertação foi o método hipotético-
dedutivo.
O método hipotético dedutivo segundo Lakatos e Marconi (1991) se inicia pela
percepção de uma lacuna nos conhecimentos, acerca da qual se formulam as hipóteses e, pelo
processo de inferência dedutiva, testa a predição da ocorrência de fenômenos abrangidos pela
hipótese, como mostra a figura 28.
4.3 PROCEDIMENTOS E TÉCNICAS
Popper propôs o método hipotético-dedutivo que se inicia com um problema ou lacuna
no conhecimento científico, passando pela formulação de hipóteses e por um processo de
inferência dedutiva que testa a predição da ocorrência de fenômenos abrangidos pela hipótese.
Portanto, neste método, a pesquisa científica inicia-se com o descobrimento de um problema e
com sua descrição clara e precisa para que facilite a obtenção de um modelo simplificado e a
identificação de outros conhecimentos e instrumentos relevantes ao problema que auxiliarão o
177
pesquisador em seu trabalho. Após este estudo preparatório, o pesquisador passa para a fase
de observação que é a fase de teste do modelo simplificado em que é observado um
determinado aspecto do universo, objeto da pesquisa.
A fase seguinte é a formulação de hipóteses consistentes com o que foi
observado. Estas são utilizadas para fazer prognósticos que serão validados ou não por meio
de testes, experimentos ou observações mais detalhadas. Em virtude dos resultados destes
testes, as hipóteses podem ser modificadas dando início a um novo ciclo até que não haja
discrepâncias entre a teoria e os experimentos e/ou observações.
Este método busca a regularidade e relacionamentos causais entre seus
elementos e seu critério original, a verificabilidade, toma por base o princípio de que a
proposição não passível de comprovação científica não faz sentido.
A Figura 28 apresenta o diagrama que ilustra o emprego do método hipotético-
dedutivo de Karl Popper, esquematizando o seu desenvolvimento:
178
Figura 28 - Método hipotético dedutivo segundo Popper
Fonte: Adaptado de Lakatos, E. M. & Marconi, M.A. Metodologia Científica. São Paulo:
Atlas,1991
179
Figura 29 - Esquema do método adaptado para a pesquisa
Fonte: Adaptado de Lakatos e Marconi (1991)
180
4.4 ANÁLISE DAS HIPÓTESES
4.4.1 Tipologia
Segundo a classificação de Selltiz et al (apud Lakatos e Marconi,1991), as hipóteses
formuladas nesta dissertação, podem ser classificada, quanto à freqüência, em hipóteses que
podem afirmar que algo é maior, menor ou igual que outras coisas, ao estabelecer relações de
diferença.
Segundo a classificação de Goode e Hatt, (apud Lakatos e Marconi,1991), as hipóteses
desta dissertação podem ser classificadas, quanto à ordem crescente de abstração, em
hipóteses que se referem a tipos ideais complexos, que visam verificar a existência de relações
logicamente derivadas entre uniformidades empíricas.
As hipóteses nesta dissertação foram formuladas para testar se:
I - A adoção dos processos de testes baseados no modelo CMMI (Capability Maturity
Model Integration) aplicados no desenvolvimento de produtos de software impacta na
qualidade sob a ótica do cliente.
II - A adoção dos processos de testes baseados no modelo CMMI (Capability Maturity
Model Integration) aplicados no desenvolvimento de serviços de testes de software impacta
na qualidade sob a ótica do cliente.
4.4.2 Fundamentação
Baseados nos fundamentos das hipóteses propostos por Lakatos e Marconi (1991), as
hipóteses desta dissertação, podem se fundamentar em:
Hipóteses que se referem a conjuntos de unidades com mais de um elemento, porque nos
referimos ao processo de desenvolvimento dos projetos de software (unidades) e ao
elemento qualidade percebida pelo cliente (percepção).
181
Hipóteses que se referem a proposições cujas unidades se distribuem probabilisticamente
num espaço de variáveis, porque elas podem mudar de uma qualidade deficiente a uma
qualidade excelente do produto.
4.5 VALIDAÇÃO DAS HIPÓTESES
4.5.1 Teste de Importância
Segundo a importância das hipóteses proposta por Kerlinger (apud Lakatos e
Marconi,1991), as hipóteses desta dissertação foram formuladas porque elas:
São instrumentos de trabalho da teoria, pois novas hipóteses podem dela ser deduzidas.
Podem ser testadas e julgadas como provavelmente verdadeiras ou falsas.
Constituem instrumentos poderosos para o avanço da ciência, pois sua comprovação
requer que se tornem independentes dos valores e opiniões dos indivíduos.
Dirigem a investigação, indicando ao investigador o que procurar ou o que pesquisar.
Pelo fato de serem comumente formulações regionais gerais, permitem ao pesquisador
deduzir manifestações empíricas específicas, com elas correlacionadas.
Desenvolvem o conhecimento cientifico, auxiliando ao investigador a confirmar (ou não)
sua teoria.
Incorporam a teoria (ou parte dela) em forma testável ou quase testável.
4.5.2 Teste de Necessidade
Segundo a necessidade das hipóteses proposta por Bunge (apud Lakatos e
Marconi,1991), as hipóteses desta dissertação se fazem necessárias quando:
Tenta-se resumir e generalizar os resultados de nossas investigações.
Tenta-se interpretar generalizações anteriores.
Tenta-se justificar, fundamentando, nossas opiniões.
Planeja-se um experimento ou investigação para a obtenção de mais dados.
Pretende-se submeter uma "conjectura" à comprovação.
182
4.6 EMPRESAS ALVO DE PESQUISA
Para a obtenção de um estudo mais completo sobre o problema apresentado neste
trabalho de dissertação seria necessário fazer a pesquisa em outras empresas com clientes de
outros segmentos de mercado. Além disso, tendo em consideração as restrições de tempo,
custo e número de pessoas envolvidas, optou-se por delimitar a pesquisa a empresa Tools
Software Ltda como empresa fornecedora dos produtos e serviços e como clientes avaliadores
quatro empresas da atual base de clientes do mercado financeiro.
No processo de seleção das empresas clientes, os seguintes critérios foram utilizados:
Base de produtos instalada
Tempo de relacionamento com a fornecedora dos produtos e serviços
Atendendo aos critérios estabelecidos, foram selecionadas as seguintes instituições:
GE Capital
IBI Bank
Banco Cruzeiro do Sul
Banco Emblema
4.6.1 População
Sendo o universo da pesquisa definido como “um conjunto de elementos (empresas, produtos,
pessoas, por exemplo), que possuem as características que serão objeto de estudo”
(VERGARA, 1997), adotou-se como universo da presente pesquisa o formado pela empresa
Tools Software, na qual a adoção dos processos de testes baseado no CMMI se encontra em
fase de implantação e seus clientes que são compostos por empresas do setor mercado
financeiro.
4.6.2 Amostra
Foram escolhidos 40 produtos da Tools Software disponibilizados para os quatro
clientes pré-selecionados, conforme quadro 21.
183
Quadro 21: Produtos utilizados na amostra
Fonte: Próprio Autor
A expectativa era relacionar um número maior de projetos, mais era necessário que os
produtos e serviços possuíssem o mesmo conjunto de características indicadas a seguir:
Produtos
Arquitetura Cliente-Servidor
Linguagem de Programação
Tempo de Vida do Produto no Mercado (5 Anos)
184
Nº de Funcionalidades
Serviços
Nº de Horas de Testes
4.7 INSTRUMENTOS DE MEDIDA UTILIZADOS
Utilizou-se como referencial de medida para avaliação da qualidade dos produtos de
software o questionário ISO/IEC 9126, para a avaliação dos serviços de testes o questionário
adaptado de Zeithaml et al (1990) - SERVQUAL - e para identificação do nível de aderência
aos processos de testes do modelo CMMI, utilizou-se o questionário elaborado para esta
dissertação baseado nas sub-práticas das áreas de processo de verificação e validação do
CMMI(2001).
4.8 COLETA DE DADOS
A coleta de dados no campo foi feita em duas etapas, a saber:
A primeira etapa consistiu em pesquisa via e-mail com 20 analistas e/ou responsáveis
pelo processo de testes, com o objetivo de:
1. Identificar o nível de aderência às práticas de testes do modelo CMMI em cada produto
e serviço de testes (ver Apêndice 9.3 ).
Nesta etapa foi utilizado o QUESTIONÁRIO CMMI.
A segunda etapa consistiu em pesquisa via e-mail com os 40 usuários e/ou equipes de
atendimento dos produtos de software visando:
1. Avaliar as percepções que os usuários têm da qualidade dos produtos e serviços de
testes de software prestado (ver apêndices 9.1 e 9.2 ).
Nesta etapa foram utilizados os questionários ISO/IEC 9126 e SERVQUAL.
185
4.9 TRATAMENTO E ANÁLISE DE DADOS
O quadro 22 relaciona a hipótese com suas respectivas questões - chave e as questões
dos questionários - ver apêndices 9.1, 9.2 e 9.3 que irá proporcionar resposta a essas questões.
Quadro 22: Relacionas as hipóteses com suas respectivas questões-chave e as questões dos
questionários – ver apêndices 9.1, 9.2 e 9.3 que irá proporcionar resposta a essas questões.
HIPÓTESE I
QUESTÕES-CHAVE
Questionário – ISO/IEC
9126
ITENS DO
QUESTIONÁRI
O
REFERENCI
AL TEÓRICO
Funcionalidade
1. O conjunto de funções
satisfaz as necessidades
explícitas e implícitas para a
finalidade a que se destina o
produto ?
Itens 1
– 5
Confiabilidade
2. O desempenho se mantém
ao longo do tempo e em
condições estabelecidas? ou
seja, é tolerante a falhas?
Itens 6 – 8
Usabilidade
3. O software é fácil de usar
?
Itens 9 – 11
Eficiência
4. Os recursos e o tempos
utilizados são compatíveis
com o nível de desempenho
requerido pelo produto?
Itens 12 – 13
Manutenibilidade
5. É fácil corrigir, atualizar e
alterar o software?
Itens 14 – 17
A adoção dos processos
de testes baseados no
modelo CMMI
(Capability Maturity
Model Integration)
aplicados no
desenvolvimento de
produtos de software
impacta na qualidade
sob a ótica do cliente.
Portabilidade
6. É possível utilizar o
produto em diversas
plataformas com pequeno
esforço de
adaptação?
Itens 18 – 21
ISO/IEC 9126
(2001)
186
HIPÓTESE II
QUESTÕES-CHAVE
Questionário -
SERVQUAL
ITENS DO
QUESTIONÁRI
O
REFERENCI
AL TEÓRICO
1. Qual a qualidade
percebida pelo cliente em
relação aos produtos de
software, nos seguintes
itens: aparência das
instalações físicas,
equipamento, pessoal e
materiais de
comunicação?
Itens 1 - 4
2. Qual a qualidade
percebida pelo cliente,
quanto à habilidade na
disponibilização dos
produtos de software
conforme prometido, de
forma confiável, precisa
e consistente?
Itens 5 - 9
3. Qual a qualidade
percebida pelo cliente
em relação aos produtos
de software, quanto à
disposição para auxiliar
os clientes e proporcionar
o serviço imediatamente?
Itens 10 - 13
A adoção dos processos
de testes baseados no
modelo CMMI
(Capability Maturity
Model Integration)
aplicados no
desenvolvimento de
serviços de testes de
software impacta na
qualidade sob a ótica
do cliente.
4. Qual a qualidade
percebida pelo cliente
em relação aos produtos
de software, nos
seguintes itens :
conhecimento para
responder a todas as
perguntas relacionadas
com o projeto de
software, atenção
mostrada pelas equipes
de atendimento e suas
habilidades para
transmitir confiança,
seguranças e
credibilidade?
Itens 14 - 17
Zeithaml,
Parasuraman,
Berry
(1990)
187
5. Qual a qualidade
percebida pelo cliente em
relação aos produtos de
software, quanto
à atenção
individualizada,
facilidade de contato,
acesso e comunicação?
Itens 18 – 22
HIPÓTESE I e II
QUESTÕES-CHAVE
Questionário – CMMI
ITENS DO
QUESTIONÁRI
O
REFERENCI
AL
TEÓRICO
Os produtos foram
selecionados para
verificação?
Itens 1- 5
O ambiente de verificação
foi devidamente
estabelecido?
Itens 6 - 9
Os procedimentos e critérios
de verificação foram
estabelecidos?
Itens 10 - 13
A revisão pelos participantes
foi devidamente preparada?
Itens 14 - 23
A revisão foi devidamente
conduzida?
Itens 24 - 30
Os dados de revisão dos
participantes foram
analisados?
Itens 31 - 34
A verificação foi realizada? Itens 35 - 38
Os resultados das
verificações foram
analisados e ações de
correção foram
identificadas?
Itens 39 - 44
Os produtos foram
selecionados para validação?
Itens 45 - 49
O ambiente de validação foi
devidamente estabelecido?
Itens 50 - 55
Os procedimentos e critérios
de validação foram
estabelecidos?
Itens 56 - 58
A validação foi realizada? Itens 59 - 63
I - A adoção dos
processos de testes
baseados no modelo
CMMI (Capability
Maturity Model
Integration) aplicados
no desenvolvimento de
produtos de software
impacta na qualidade
sob a ótica do cliente.
II - A adoção dos
processos de testes
baseados no modelo
CMMI (Capability
Maturity Model
Integration) aplicados
no desenvolvimento de
serviços de testes de
software impacta na
qualidade sob a ótica
do cliente.
Os resultados das validações
foram analisados e ações de
correção foram
identificadas?
Itens 64 - 68
M.C. Paulk,
B. Curtis,
M.B.
Chrissis, C.V.
Weber
(1993)
Quadro 22 - Relacionamento de hipóteses com suas respectivas questões-chave
Fonte: Próprio Autor
188
4.10 LIMITAÇÕES DO MÉTODO
Os dados obtidos através dos e-mail, não garantem que possam refletir a realidade,
devido à existência de respostas distorcidas, causadas pelo grau de motivação do entrevistado,
a falta de conhecimentos sobre o assunto pesquisado, assim como, a inadequação do
questionário (excessivo número de perguntas, escala utilizada e tempo, entre outros).
Há também a possibilidade dos respondentes aumentarem propositalmente os escores, de
forma a não transmitir uma avaliação ruim de si próprios ou de suas empresas, mesmo com a
indicação de que a pesquisa não tem por objetivo selecionar o entrevistado ou a empresa.
Da mesma forma, o entrevistador exerce influência sobre as respostas dos entrevistados,
assim como a apresentação e explicação dos itens, que podem ter influenciado no
comportamento dos respondentes (HASSEGAWA, 2002).
189
5 ANÁLISE E DISCUSSÃO DOS RESULTADOS
5.1 TESTE DA HIPÓTESE
HIPÓTESE I
A adoção dos processos de testes baseados no modelo CMMI (Capability Maturity
Model Integration) aplicados no desenvolvimento de produtos de software impacta na
qualidade sob a ótica do cliente.
HIPÓTESE II
A adoção dos processos de testes baseados no modelo CMMI (Capability Maturity
Model Integration) aplicados no desenvolvimento de serviços de testes de software
impacta na qualidade sob a ótica do cliente.
5.2 MÉTODO ESTATÍSTICO
A análise estatística foi realizada pelo teste t de Student (Jerrold, 1999) para
amostras independentes, para verificar se existe diferença significativa nos escores médios das
características/aspectos da ISO/IEC 9126 e SERVQUAL nas questões individuais entre dois
grupos estabelecidos pelo questionário do CMMI.
O critério de determinação de significância adotado foi o nível de 5%, ou seja,
quando o p valor do teste estatístico for menor ou igual a 0,05, então existe significância
estatística.
Os grupos foram definidos de acordo com o seguinte critério:
O produto pertencerá ao maior nível cujo escore médio, obtido pelo CMMI, for
maior ou igual a 3.
Desta forma, foi observado que:
- 12 produtos atingiram escore médio < 3;
190
- 28 produtos atingiram escore médio 3
Foi definido, para fins de análise estatística, dois grupos:
- Grupo 1: 12 produtos (Não aderente às práticas do CMMI)
- Grupo 2: 28 produtos (Aderente às práticas do CMMI)
Teste t de Student para amostras independentes
O procedimento geral usado para testar uma hipótese consiste nos seguintes passos:
1. Verificar as suposições ou condições básicas para aplicabilidade do teste. O
conjunto de dados (escores) tem distribuição aproximadamente normal (Gaussiana), e foi
selecionado de uma amostra aleatória.
2. Estabelecer as hipóteses.
Hipótese 1 A hipótese nula (H
o
) seria que a média dos escores associada ao
questionário ISO/IEC 9126 do conjunto de produtos classificados no Grupo 1 (Não aderente
às práticas do CMMI) não é significativamente diferente do conjunto de produtos
classificados no Grupo 2 (Aderente às práticas do CMMI). A hipótese alternativa (H
a
) seria
que as médias dos escores são estatisticamente diferentes entre os dois grupos, ou seja, esta
hipótese testa se a qualidade avaliada pelo questionário ISO/IEC 9126 está relacionada com o
nível de aderência das práticas de testes do modelo CMMI.
Hipótese 2 A hipótese nula (H
o
) seria que a média dos escores associada ao
questionário SERVQUAL do conjunto de serviços de testes classificados no Grupo 1 (Não
aderente às práticas do CMMI) não é significativamente diferente do conjunto de produtos
classificados no Grupo 2 (Aderente às práticas do CMMI). A hipótese alternativa (H
a
) seria
que as médias dos escores são estatisticamente diferentes entre os dois grupos, ou seja, esta
hipótese testa se a qualidade avaliada pelo questionário SERVQUAL está relacionada com o
nível de aderência das práticas de testes do modelo CMMI.
As hipóteses, em termos matemáticos, são:
191
H
o
:
1
=
2
H
a
:
1
2
onde,
1
e
2
correspondem as médias populacionais dos escores do grupo 1 e 2,
respectivamente.
3. Especificar o nível de significância . O nível de significância, usualmente
conhecido como p valor, de 5% ou 0,05 define o critério de determinação de significância do
teste, ou seja, se o p valor do teste estatístico obtido for igual ou menor que 0,05, então existe
diferença significativa nas médias entre os dois grupos.
4. Calcular o valor teste estatístico. Sob as suposições e hipóteses acima
descritas, o valor do teste estatístico t é obtido pela seguinte fórmula:
t = x
1
- x
2
se
onde, x
1
é a média aritmética dos escores do grupo 1;
x
2
é a média aritmética dos escores do grupo 2;
se é o erro padrão da diferença entre médias
Esta estatística tem distribuição t de Student com n
1
+n
2
-2 graus de liberdade. Onde, n
1
e n
2
são o número de projetos do grupo 1 e 2, respectivamente.
5. Especificar a regra de decisão do teste. Se o módulo do valor da estatística t
calculado for maior ou igual ao valor crítico tabelado (t
*
) para o nível de 5% e n
1
+n
2
-2 graus
de liberdade, então rejeita a hipótese nula, ou seja,
se | t | t* então rejeita H
o
, caso contrário, não rejeita a H
o
6. Interpretar a conclusão do teste. Por exemplo, se t = 4,2 maior que t* = 2,1, então
rejeita-se a hipótese nula, ou seja, existem evidencias para concluir que a diferença nas
192
médias dos escores entre os dois grupos não é ao acaso. Provavelmente, a diferença pode ser
explicada pelo nível no qual se encontram.
5.3 ANÁLISE DOS RESULTADOS
5.3.1 Resposta ao Objetivo 1
Avaliar os impactos na qualidade dos produtos de software junto aos clientes com a utilização
de processos de testes baseados no modelo CMMI (Capability Maturity Model Integration).
5.3.1.1 Análise global das características e sub-característica segundo a norma ISO/IEC
9126
A tabela 27 fornece a média, erro padrão (EP), mínimo, máximo dos escores das
características e sub-características da norma ISO/IEC 9126 segundo os grupos. O valor da
estatística t e o respectivo nível de significância (p valor) foram calculados para as vinte e
duas sub-características.
193
Tabela 27 – Análise global das características e sub-característica da segundo norma ISO/IEC
9126
Conclusão: Analisando as questões observou-se que o escore médio de todas as sub-
características do do grupo 2 foi significativamente maior que o grupo 1. Isto evidência que,
os usuários do grupo do grupo 2 percebem maior presença de características de qualidade nos
produtos avaliados.
194
5.3.1.2 Análise das Sub-característica Segundo a Norma ISO/IEC 9126 mais impactadas
Tabela 28 - Escores médios das sub-características ordenados pelo valor t – ISO/IEC 9126.
Conclusão: Analisando as sub-características observou-se que os escores médios das sub-
características “Maturidade”, “Testabilidade” e “Estabilidade” são os de maior diferença entre
os grupos avaliados. Observa-se também que as características de “Portabilidade” apresentam
as menores diferenças entre os grupos avaliados.
195
Análise Individual das Sub-característica Segundo a Norma ISO/IEC 9126
Os gráficos a seguir fornecem o valor da estatística t e o respectivo nível de significância (p
valor) das sub-características segundo a norma ISO/IEC 9126.
Gráfico 5 - Escore médio da característica Funcionalidade
Conclusão: Analisando as sub-características observou-se que o escore médio de
“Adequação” apresenta a maior diferença entre os grupos avaliados. A menor média
identificada nesta sub-característica foi o item “Interoperabilidade”.
Gráfico 6 - Escore médio da característica Confiabilidade
196
Conclusão: Analisando as sub-características observou-se que o escore médio de
“Maturidade” apresenta a maior diferença entre os grupos avaliados. A menor média
identificada nesta sub-característica foi o item “Recuperabilidade”.
Gráfico 7 - Escore médio da característica Usabilidade
Conclusão: Analisando as sub-características observou-se que o escore médio de
“Operacionabilidade” apresenta a maior diferença entre os grupos avaliados. A menor média
identificada nesta sub-característica foi o item “Apreensibilidade”.
Gráfico 8 - Escore médio da característica Eficiência
197
Conclusão: Analisando as sub-características observou-se que o escore médio de “Recursos
Utilizados” apresenta a maior diferença entre os grupos avaliados. A menor média
identificada nesta sub-característica foi o item “Tempo de Execução”.
Gráfico 9 - Escore médio da característica Manutenibilidade
Conclusão: Analisando as sub-características observou-se que o escore médio de
“Testabilidade” apresenta a maior diferença entre os grupos avaliados. A menor média
identificada nesta sub-característica foi o item “Analisabilidade”.
Gráfico 10 - Escore médio da característica Portabilidade
198
Conclusão: Analisando as sub-características observou-se que o escore médio de “Facilidade
de Instalação” apresenta a maior diferença entre os grupos avaliados. A menor média
identificada nesta sub-característica foi o item “Conformidade com Portabilidade”.
199
5.3.2 Respostas ao Objetivo 2
Avaliar os impactos na qualidade dos serviços de testes de software junto aos clientes com a
utilização de processos de testes baseados no modelo CMMI (Capability Maturity Model
Integration).
5.3.2.1 Análise Global dos Aspectos do SERVQUAL
A tabela 29 fornece a média, erro padrão (EP), mínimo, máximo dos escores dos
aspectos e questões do modelo SERVQUAL segundo os grupos. O valor da estatística t e o
respectivo nível de significância (p valor) foram calculados para as vinte e uma questões.
200
Tabela 29 - Análise global dos aspectos do modelo SERVQUAL
Conclusão: Analisando as questões observou-se que o escore médio dos aspectos “Elementos
Tangíveis”, “Confiabilidade” e “Segurança” do grupo 2 foi significativamente maior em todas
as questões do que grupo 1. Isto evidência que os usuários do grupo 2 percebem maior
presença de características de qualidade nos produtos avaliados.
Podemos afirmar que existe uma tendência (isto é, p valor 0,05 e 0,10) do grupo 2 em
apresentar escore médio do aspecto “Capacidade de Resposta” superior para as questões 12 e
13, para as outras duas questões o valor de p foi inferior a 0,05.
201
Para o aspecto “Empatia” observou-se que em todas as questões os valores do escore médio
do grupo 2 não apresentam diferenças estatísticas significativamente maiores que o grupo 1.
Sendo assim, não se poder afirmar que os usuários do grupo 2 percebem maior presença dos
aspectos de qualidade nos serviços avaliados.
5.3.2.2 Análise dos Aspectos do modelo SERVQUAL mais impactados
Tabela 30 - Escores médios das questões ordenadas pelo valor t - SERVQUAL.
Conclusão: Analisando as questões observou-se que os escores médios dos aspectos
“Confiabilidade“, “Elementos Tangíveis” são os de maior diferença entre os grupos avaliados.
Observa-se também que as características de “Empatia” apresentam as menores diferenças
entre os grupos avaliados.
202
5.3.2.3 Análise das Questões do SERVQUAL
Os gráficos a seguir fornecem o valor da estatística t e o respectivo nível de significância (p
valor) das questões segundo o modelo SERVQUAL.
Gráfico 11 - Escore médio do aspecto Elementos Tangíveis
Conclusão: Analisando as questões observou-se que o escore médio da questão 4 (Têm
elementos materiais relacionados com o serviço visualmente atraentes?) apresenta a maior
diferença entre os grupos avaliados. A menor média identificada neste aspecto foi a questão 2
(Possui uma área dedicada à execução e suporte aos processos de testes?).
Gráfico 12 - Escore médio do aspecto Confiabilidade
203
Conclusão: Analisando as questões observou-se que o escore médio da questão 1 (Os testes
são realizados corretamente na primeira vez?) apresenta a maior diferença entre os grupos
avaliados. A menor média identificada neste aspecto foi a questão 6 (Na identificação de
erros, os analistas de testes demonstram interesse na resolução dos mesmos?).
Gráfico 13 - Escore médio do aspecto Capacidade de Resposta
Conclusão: Analisando as questões observou-se que o escore médio da questão 10 (A equipe
de testes comunica aos clientes quando irá concluir os testes programados?) apresenta a maior
diferença entre os grupos avaliados. A menor média identificada neste aspecto foi a questão
12 (Os analistas de testes estão sempre dispostos à ajudar os clientes?).
204
Gráfico 14 - Escore médio do aspecto Segurança
Conclusão: Analisando as questões observou-se que o escore médio da questão 17 (Têm
analistas de testes com conhecimentos suficientes para responder às perguntas dos clientes?)
apresenta a maior diferença entre os grupos avaliados. A menor média identificada neste
aspecto foi a questão 14 (Têm analistas de testes que transmitem por meio de seu
comportamento, confiança à seus clientes?).
Gráfico 15 - Escore médio do aspecto Empatia
205
Conclusão: Analisando as questões observou-se que o escore médio da questão 22 (Têm
empregados que compreendem as necessidades específicas de seus clientes?) apresenta a
maior diferença entre os grupos avaliados. A menor média identificada neste aspecto foi a
questão 20 (A maioria dos participantes do grupo de testes participa das atividades de teste em
tempo integral?).
5.3.3 Respostas ao Objetivo 3
Identificar o nível de aderência dos processos de testes segundo o modelo CMMI (Capability
Maturity Model Integration) de cada produto e serviço.
Os grupos foram definidos de acordo com o seguinte critério:
O produto pertencerá ao maior nível cujo escore médio, obtido pelo CMMI, for maior ou
igual a 3.
Desta forma, foi observado que:
12 produtos atingiram escore médio < 3;
28 produtos atingiram escore médio >= 3
Grupo 1: 12 produtos (Não aderente às práticas do CMMI)
Grupo 2: 28 produtos (Aderente às práticas do CMMI)
Gráfico 16 – Distribuição dos Projetos – Avaliação CMMI
206
6 CONCLUSÕES E RECOMENDAÇÕES
6.1 SOLUÇÃO DO PROBLEMA
O problema formulado neste estudo, no capítulo 1, foi descrito da seguinte forma:
Quais os impactos na qualidade dos produtos e serviços de testes de software sob a ótica
do cliente na adoção dos processos de testes baseados no modelo CMMI?
Após análise estatística dos resultados obtidos em cada questão dos questionários
aplicados, concluiu-se que todas as características de qualidade segundo a norma ISO/IEC
9126 são impactadas positivamente sob a perspectiva do usuário com a adoção dos processos
de testes baseados no modelo CMMI.
Com relação aos impactos na prestação de serviços de testes, concluí-se que os
aspectos “Elementos Tangíveis”, “Confiabilidade” e “Segurança” são impactos pela adoção
dos processos. No aspecto “Capacidade de Resposta” apenas metade das questões sofreram
impactos e no aspecto “Empatia” não ocorreram diferenças significativas que comprovassem
uma melhor percepção por parte dos usuários, quando adotado tais processos.
De forma analítica, a resposta ao problema apresentado neste estudo poder ser
formulada da seguinte forma: Os impactos na qualidade dos produtos e serviços de testes de
software sob a ótica do cliente na adoção dos processos de testes baseados no modelo CMMI
são:
Qualidade dos Produtos:
Adequação
Acurácia
Interoperabilidade
Conformidade
Segurança de acesso
Maturidade
Tolerância à falhas
Recuperabilidade
Inteligibilidade
Apreensibilidade
Operacionalidade
Tempo de Execução
207
Recursos Utilizados
Analisabilidade
Modificabilidade
Estabilidade
Testabilidade
Adaptabilidade
Facilidade para Instalação
Facilidade para Substituição
Conformidade com Portabilidade
Qualidade dos Serviços:
Elementos Tangíveis
Confiabilidade
Capacidade de Resposta (Parcialmente impactado)
Segurança
Empatia (Não impactado)
208
6.2 VERIFICAÇÃO DAS HIPÓTESES
A metodologia aplicada se baseia no teste de falseabilidade das hipóteses levantadas, por
meio do método da hipótese nula, ou seja, pela aplicação de um teste estatístico adequado à
natureza das variáveis e da amostra analisada, de forma a verificar-se o grau de significância
dos resultados obtidos.
Desta forma, pôde-se analisar, validando total ou parcialmente ou refutando, cada hipótese
levantada e responder as questões-chave associadas. A seguir, estão relacionadas cada
hipótese, sua análise com validação total, parcial ou refutação e a resposta a cada questão-
chave.
Hipótese I Resposta à Hipótese I
A adoção dos processos de testes baseados
no modelo CMMI (Capability Maturity
Model Integration) aplicados no
desenvolvimento de produtos de software
impacta na qualidade sob a ótica do cliente.
A hipótese foi corroborada, logo, conclui-
se
que a adoção dos processos de testes baseados
no modelo CMMI (Capability Maturity Model
Integration) aplicados no desenvolvimento de
produtos de software impacta na qualidade sob
a ótica do cliente.
Questões Chave – Questionário ISO/IEC
9126
Respostas às Questões Chave
Funcionalidade
1. O conjunto de funções satisfaz as
necessidades explícitas e implícitas para a
finalidade a que se destina o produto ?
Analisando os escores médios das questões
referente a característica de qualidade
Funcionalidade observou-se, que os escores
médios das questões 1, 2 , 3 , 4 e 5 do grupo 2
foi significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade no produtos avaliados, conforme
mostrado na Tabela 27.
209
Confiabilidade
2. O desempenho se mantém ao longo do
tempo e em condições estabelecidas? ou
seja, é tolerante a falhas?
Analisando os escores médios das questões
referente a característica de qualidade
Confiabilidade observou-se, que os escores
médios das questões 6, 7 , e 8 do grupo 2 foi
significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade no produtos avaliados, conforme
mostrado na Tabela 27.
Usabilidade
3. O software é fácil de usar?
Analisando os escores médios das questões
referente a característica de qualidade
Usabilidade observou-se, que os escores
médios das questões 9, 10 , e 11 do grupo 2 foi
significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade no produtos avaliados, conforme
mostrado na Tabela 27.
Usabilidade
3. O software é fácil de usar?
Analisando os escores médios das questões
referente a característica de qualidade
Usabilidade observou-se, que os escores
médios das questões 9, 10 , e 11 do grupo 2 foi
significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade no produtos avaliados, conforme
mostrado na Tabela 27.
Eficiência
4. Os recursos e os tempos utilizados são
Analisando os escores médios das questões
referente a característica de qualidade
210
compatíveis com o nível de desempenho
requerido pelo produto?
Eficiência observou-se, que os escores médios
das questões 12 e 13 do grupo 2 foi
significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade no produtos avaliados, conforme
mostrado na Tabela 27.
Manutenibilidade
5. É fácil corrigir, atualizar e alterar o
software?
Analisando os escores médios das questões
referente a característica de qualidade
Manutenibilidade observou-se, que os escores
médios das questões 14, 15, 16 e 17 do grupo 2
foi significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade no produtos avaliados, conforme
mostrado na Tabela 27.
Portabilidade
6. É possível utilizar o produto em diversas
plataformas com pequeno esforço de
adaptação?
Analisando os escores médios das questões
referente a característica de qualidade
Portabilidade observou-se, que os escores
médios das questões 18, 19, e 21 do grupo 2 foi
significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade no produtos avaliados, conforme
mostrado na Tabela 27.
Hipótese II Resposta à Hipótese II
A adoção dos processos de testes baseados
no modelo CMMI (Capability Maturity
Model Integration) aplicados no
A hipótese foi parcialmente corroborada,
logo, conclui-se que a adoção dos processos de
testes baseados no modelo CMMI (Capability
211
desenvolvimento de serviços de testes de
software impacta na qualidade sob a ótica
do cliente.
Maturity Model Integration) aplicados no
desenvolvimento de serviços de testes de
software impacta parcialmente na qualidade sob
a ótica do cliente.
Elementos Tangíveis
1. Qual a qualidade percebida pelo
cliente em relação aos produtos de
software, nos seguintes itens: aparência das
instalações físicas, equipamento, pessoal e
materiais de comunicação?
Analisando os escores médios das questões
referente ao aspecto Elementos Tangíveis
observou-se, que os escores médios das
questões 1, 2, 3 e 4 do grupo 2 foi
significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
qualidade nos serviços de testes avaliados,
conforme mostrado na Tabela 29.
Confiabilidade
2. Qual a qualidade percebida pelo
cliente, quanto à habilidade na
disponibilização dos produtos de software
conforme prometido, de forma confiável,
precisa e consistente?
Analisando os escores médios das questões
referente ao aspecto Confiabilidade observou-
se, que os escores médios das questões 5, 6, 7, 8
e 9 do grupo 2 foi significativamente maior que
o grupo 1. Isto evidência que, os usuários do
grupo do grupo 2 percebem maior presença de
características de qualidade nos serviços de
testes avaliados, conforme mostrado na Tabela
29.
Capacidade de Resposta
3. Qual a qualidade percebida pelo
cliente em relação aos produtos de
software, quanto à disposição para auxiliar
os clientes e proporcionar o serviço
imediatamente?
Analisando os escores médios das questões
referente ao aspecto Capacidade de Resposta
observou-se, que os escores médios das
questões 12 e 13 do grupo 2 foi
significativamente maior que o grupo 1. Isto
evidência que, os usuários do grupo do grupo 2
percebem maior presença de características de
212
qualidade nos serviços de testes avaliados. Na
análise das questões 10 e 11 observou-se que
existe uma tendência (isto é, p valor 0,05 e
0,10) do grupo 2 em apresentar escore médio
superior, conforme mostrado na Tabela 29.
Segurança
4. Qual a qualidade percebida pelo
cliente em relação aos produtos de
software, nos seguintes itens :
conhecimento para responder a todas as
perguntas relacionadas com o projeto de
software, atenção mostrada pelas equipes
de atendimento e suas habilidades para
transmitir confiança, seguranças e
credibilidade?
Analisando os escores médios das questões
referente ao aspecto Segurança observou-se,
que os escores médios das questões 14, 15, 16 e
17 do grupo 2 foi significativamente maior que
o grupo 1. Isto evidência que, os usuários do
grupo do grupo 2 percebem maior presença de
características de qualidade nos serviços de
testes avaliados. Conforme mostrado na Tabela
29.
Empatia
5. Qual a qualidade percebida pelo
cliente em relação aos produtos de
software, quanto
à atenção individualizada, facilidade de
contato, acesso e comunicação?
Analisando os escores médios das questões
referente ao aspecto Empatia observou-se, que
os escores médios das questões 18, 19, 20, 21 e
22 do grupo 2 não apresentam diferenças
estatísticas significativamente maiores que o
grupo 1. Sendo assim, não se poder afirmar que
os usuários do grupo 2 percebem maior
presença dos aspectos de qualidade nos serviços
avaliados.
213
6.3 CONCLUSÕES
Após a verificação de cada hipótese e resposta às questões-chave, pôde ser feita uma análise
dos resultados com relação à contextualização do problema e, a partir desta análise, fazer
inferências sobre os impactos na qualidade dos produtos e serviços sob a ótica dos clientes
com a adoção dos processos de testes baseados no modelo CMMI. Pode-se, a partir dos
resultados encontrados, concluir que:
A Confiabilidade dos produtos perante o cliente aumenta significativamente com a
adoção dos processos de testes. Isto permite que empresas que investirem na adoção
destes processos possam se beneficiar frente a seus concorrentes, por se tratar de um
aspecto fundamental na seleção de fornecedores.
A Manutenibilidade é uma característica altamente impactada com a adoção dos
processos de testes. Levando em conta que estudos apontam o custo de manutenção
como sendo responsável por 40% dos custos totais, pode-se afirmar que a
aplicabilidade do modelo permite a redução de custos de desenvolvimento e
manutenção de produtos.
A adoção de um processo de testes estruturado permite melhor desenvolvimento das
sub-características de Funcionalidade, por exigir durante sua execução dos testes que
se tenha maior entendimento dos requisitos do produto frente ao cliente.
Os processos de testes ainda oferecem poucos benefícios nas áreas de Usabilidade e
Portabilidade. Cabe ressaltar que estas características estão em uma posição inferior
nas prioridades do cliente em geral.
Os serviços de testes prestados assim como os produtos desenvolvidos ganham maior
confiabilidade frente ao cliente.
Aspectos diretamente ligados ao relacionamento com o cliente como os do grupo
“Empatia” sofrem baixa interferência frente ao cliente.
214
A implantação de processos de melhoria de qualidade é mais que uma tendência nas
empresas de software é um requisito primordial para enfrentar o mercado competitivo
e atender às exigências de seus clientes.
A metodologia do teste de software se reflete atualmente no comportamento das
empresas na busca de implantar, ou mesmo melhorar o processo de teste utilizado.
Torna-se necessário uma política de qualidade em todos os processos no
desenvolvimento do software, aliada a uma equipe de testes organizada e treinada, de
modo a auxiliar e minimizar os erros que possam passar despercebidos pelas equipes
de desenvolvimento.
215
6.4 SUGESTÕES PARA FUTUROS ESTUDOS
O tema desta pesquisa não se esgota neste trabalho, o estudo dos impactos da adoção dos
processos de testes do modelo CMMI no desenvolvimento de produtos e serviços possui
vários outros aspectos que são passíveis de uma investigação mais aprofundada. A seguir, são
feitas algumas sugestões de futuros estudos, que podem complementar e aprofundar o
trabalho aqui apresentado:
Pesquisas que identifiquem qual a relação custo/benefício da adoção dos processos de
testes de baseados no modelo CMMI.
Estudos que avaliem o nível de aderência do modelo CMMI a outros modelos de
maturidade de testes como o TPI, TMM, TOM e TAP.
Pesquisas que busquem aprimorar a escolha nas estratégias de testes utilizadas pelos
modelos de maturidade, objetivando a otimização do processo dos testes.
Pesquisas de avaliem os impactos do modelo IT Service Capability Maturity Model no
processo de prestação de serviços de testes de software.
Estudos que avaliem o nível de importância de cada característica de qualidade do modelo
ISO/IEC 9126 junto aos clientes.
216
REFERÊNCIAS
ALVARADO, Williams O. Qualidade em Serviços Liderança Gerencial nas Empresas de
Informática, 2001. 216 f. Dissertação (Mestrado). Universidade Federal Fluminense, Niterói,
2001.
ARANHA, E., BORBA, P. Testes e Geração de Código de Sistemas Web. Anais do 16º
Simpósio Brasileiro de Engenharia de Software, Outubro, Gramado, Rio Grande do Sul,
Brasil. 2002.
BEIZER, B.. Software System Testing and Quality Assurance. New York: Van Nostrand
Reinhold, 1984.
BIGNË, J.E; MOLINER, M.A.; VALLET, T.M e SANCHEZ, J. Un studio Comparativo de
los Instrumentos de Medición de la Calidad de los Servicios Públicos. Revista Española de
Investigación de Marketing ESIC, pp. 33-53, Setembro, 1997.
BARRY BOEHM, E VICTOR R. BASILI, Software Defect Reduction Top 10 List,
University of Southern California
BUTTLE, F. SERVIQUAL: review, critique, research agenda. European Journal of
Marketing, v. 30, n. 1, pp. 8-32, 1996.
CRESPO ET AL, Uma Metodologia para Teste de Software no Contexto da Melhoria de
Processo. UNICAMP, Campinas 2003.
CHUA, Bee B., DYSON Laurel E. , Applying the ISO 9126 model to the evaluation of an
e-learning system , Faculty of Information Technology University of Technology, Sydney,
2004.
CRISÓSTOMO, Antônio P. Qualidade e liderança: Avaliação dos Serviços Internos de
Informática em uma Grande Empresa. 171 f. Dissertação (Mestrado). Universidade
Federal Fluminense, Niterói, 2002.
217
CMM & PMBOK. Disponível em:
http://www.pmirs.orgs/Documentos/GerenciaProjetosSoftwareCMM_PMBOK.PDF . Acesso
em nov. 2002.
CRONIN, J.J; TAYLOR, S.A. Measuring service quality: a reexamination and extension.
Journal of Marketing, v.56, pp. 55-68, Jul, 1992.
______ . S.A. SERVPERF versus SERVQUAL: reconciling performance-based and
perceptiuons-minus-expectations measurement of service quality. Journal of Marketing,
v.58. pp. 125-131. Jan, 1994.
CROSBY P.B. Quality is Free. New York: McGraw-Hill, 1979.
CROSBY, Phillip. Qualidade é Investimento – A arte de Garantir a Qualidade, 2a.
Edição. Rio de Janeiro: José Olympio, 1986.
DEMING, W. Edwards. Out of the Crisis, MIT Center for Advanced Engineering Study.
Cambridge, 1986.
DEUTSCH, M. Verification and Validation. In: PRESSMAN, Roger. Engenharia de
Software. São Paulo: Makron Books, 1995. p. 780-781
DEVELOPERS’ MAGAZINE. Integrando CMM com Outros Modelos de Qualidade.
Fevereiro, 1999.
DEVELOPERS’ MAGAZINE. Qualidade de Software: O Que Há de Novo no Mercado?
Abril, 2002.
FAGAN, M.E. Advances in Software Inspections, IEEE Transaction on Software
Engineering, Vol.12, No. 7, July 1986, pp744-751.
FIORINI, Soeli T.; STAA, A.V. e BAPTISTA, R.M. Engenharia de Software com CMM.
Rio de Janeiro: Brasport,1998,pp346.
218
GARTNER GROUP, Testing client/server applications: challenges, strategies and
solutions for success. Stamford: 22 Nov. 1996. (Strategic Analysis Report).
GERÊNCIA DE PROJETOS DE SOFTWARE CMM & PMBOK. Disponível em:
http://www.pmirs.org/Documentos/GerenciaProjetosSoftwareCMM_PMBOK.PDF. Acesso
em nov. 2002.
GOLDENSON, Dennis; GIBSON, Diane. Demonstrating the Impact and Benefit of
CMMI: An Update and Preliminary Results. Special Report CMU/SEI-2003-SR-009.
Software Engineering Institute, Carnegie Mellon University, 2003.
HETZEL, Bill. The Complete Guide to Software Testing - Second Edition, John Wiley &
Sons, 1988.
HUMPHEY, W.S.; Characterizing the Software Process: A Maturity Framework,
Software Engineering Institute, CMU/SEI-87-TR-11, ADA182895, June 1987.
_______. Characterizing the Software Process, IEEE Software, VoL.5, No.2, March, 1988,
pp73-79.
HUMPHEY, W.S.; KITSON, D.H.; and GALE, J. A Comparison of U.S. and Japanese
Software Process Maturity, Proceedings of the 13 th International Conference on Software
Engineering. Austin, TX,13-17 May 1991, pp.38-49.
_______. The Personal Software Process (PSP); Software Engineering Institute, Carnegie
Mellon University, TECHNICAL REPORT CMU/SEI-2000-TR022 ESC-TR-09 2000-022;
Janeiro 2000.Disponível em:
http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr022.pdf Acesso em fev. 2003
_______. The Team Software Process (TSP); Software Engineering Institute, Carnegie
Mellon University, TECHNICAL REPORT CMU/SEI-2000-TR023 ESC-TR-09 2000-023;
November 2000.Disponível em:
http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr023.pdf Acesso em fev. 2003.
219
IEEE, The Institute of Electrical and Electronics Engineers. IEEE Std 829: Standard for
Software Test Documentation. New York: IEEE Computer Society, September, 1998.
INTHURN, Cândida. Qualidade e Teste de Software, Visual Books, 2001.
ISBSG. International Software Benchmarking Standards Group. The Benchmarking,
Release 8, 2003.
ISO, International Standart Organization; ISO/IEC 9126 – Software Engineering - Product
Quality, 2001.
LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Metodologia Científica. 2 ed. São
Paulo: Atlas, 1991.
MARICK, Brian, Classic Testing Mistakes, in Proceedings, Software Testing Analysis and
Review (STAR) Testing Foundations ,1997.
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Técnicas de pesquisa:
planejamento e execução de pesquisas, amostragens e técnica de pesquisa, elaboração,
análise e interpretação de dados. 3 ed. São Paulo: Atlas, 1996.
MARTIN J. & MCCLURE C., Software Maintenance: The Problem and Its Solutions'
Prentice-Hall, 1984
MOLINARI, Leonardo. Testes de Software: Produzindo Sistemas Melhores e Mais
Confiáveis, São Paulo: Érica, 2003.
MYERS, Glen. The Art of Software Testing. New York: Wiley, 1979.
NIST, Instituto Nacional de Padrões e Tecnologia . Relatório The Economic Impact of
Inadequate Infraestrutre for Software Testing, 2002.
NITA, Erika ; Melhoria da Qualidade de Produto e de Processo de Software a partir da
Análise de Indicadores de Teste, CI&T Systems, Campinas, 2003.
220
OSÓRIO, Rosana. CMM e Qualidade: Estudo de Caso DATAPREV. 205 f. Dissertação
(Mestrado). Universidade Federal Fluminense, Niterói, 2003.
PARASURAMAN, A.; ZEITHAML, Valarie A.; BERRY, Leonard L. A conceptual Model
of Service Quality and Its Implicans for Future Research. Journal of Marketing, v. 49, pp
41-50, Fall, 1985.
PAULK, M.C.; CURTIS, B.; CHRISSIS, M.B. e WEBER, C.V. Capability Maturity Model
for Software. Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24, 1993 a.
Disponível em http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf Acesso em
jan. 2003.
PAULK, M.C. HOW ISO 9001 COMPARES WITH THE CMM. Software Engineering
Institute, Pittsburgh, january.1994.
PAULK, M.C.; GARCIA, S.M.; CHRISSIS, M.B.; WEBER, C.V, BUSH, M.; Key Pratices
of the Capability Maturity Model, Version 1.1; Software Engineering Institute, Carnegie
Mellon University, CMU/SEI-93TR-25, ESC-TR-93-178.; February 1993 b. Disponível em
http://wwwsei.cmu.edu/pub/documents/93.reports/pdf/tr25.93.pdf Acesso em jan.2003.
PAULK, M.C. HOW ISO 9001 COMPARES WITH THE CMM. Software Engineering
Institute, Pittsburgh, january.1995.
PESQUISA DO SEI – Software Engineering Institute da Carnegie Mellon University. Perfil
do Processo de Maturidade da Comunidade de Software no ano de 2001. Disponível em
http://www.sei.cmu.edu/semapdf2002aug.pdf . Acesso em nov. 2002.
PETERS, James. Engenharia de Software. RJ: Campus. 2001.
PRESSMAN, Roger. Engenharia de Software. São Paulo: Makron Books, 1995.
POL, M., TEUNISSEN R., VEENENDAAL E. van, Test Process Improvement - A
practical step-by-step guide to structured testing Addison-Wesley , UK 2003.
221
QUINTELLA, Heitor; OSORIO, Rosana. CMM e Qualidade: caso Dataprev.
TR0903_1438 - In: ENEGEP ICIE. Ouro Preto: ABEPRO, 2003. v. 1. p. 21-31.
QUINTELLA, Heitor. Fatores Humanos e Tecnológicos da Competitividade. Relatório de
Pesquisa. UFF, 1997.
______ . M. Manual de Psicologia Organizacional da Consultoria Vencedora. São Paulo:
Makron Books, 1994.
SEI. Capability Maturity Model Integration for Systems Engineering, Software
Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD),
version 1.1. Software Engineering Institute, Carnegie Mellon, 2001a.
______. Standard CMMI Appraisal Method for Process Improvement (SCAMPI),
version 1.1. Method Definition Document (CMMI-SEI-2001-HB-001). Software
Engineering Institute, Carnegie Mellon, 2001b.
______. Integrated Product Development (IPD-CMM). Software Engineering Institute,
Carnegie Mellon, 1997. Disponível em http://www.sei.cmu.edu/cmm/ipd-cmm.html. Acesso
em 01 julho 2004.
______. CMMI General Information. Software Engineering Institute, Carnegie Mellon,
2004. Disponível em http://www.sei.cmu.edu/cmmi/general/general.html. Acesso em 10
agosto 2004.
ROCHA, A. MALDONADO, J. WEBER, A. A Qualidade de software - Teoria e Prática.
Prentice Hall. 2001.
ROOIJMANS, A. AND GENUCHTEN, M. Software Quality in Consumer Electronic
Products, IEEE Software, January 1996, 55-64.
SCARTON, Evandro M., NAU Rodrigo D., Análise da Qualidade de Software de Gestão
Empresarial utilizando a Norma ISO/IEC 9126, Instituto Catarinense de Pós-Graduação ,
Santa Catarina, 2002.
222
SIEGEL, J. A. L., et al. National Software Capacity: Near –Term Study. Software
Engineering Institute, CMU/SEI-90-TR-12-ADA226694, May 1990.
SOFTWARE PRODUCTIVITY CONSORTIUM. IPD-CMM. The Software Productivity
Consortium NFP, Inc, 2004. Disponível em
http://www.software.org/quagmire/descriptions/ipdcmm.asp. Acesso em 01 julho 2004
SOMMERVILLE, Ian. “Processos de Software”, Engenharia de Software., Tradução da 6a
edição, Addison Wesley, 2003.
SOTILLE, Mauro. PMBOK & CMM + CMMI. Disponível em http://www.pmtech.com.br,
2003. Acesso em fev 2004.
THE TEAM SOFTWARE PROCESS (TSP). Disponível em:
http://www.sei.cmu.edu/tst/tsp.html. Acesso em jun. 2002.
VOLPI, LISIANE M., VIRGILIO, SILVIA R., Teste em Ambiente Cliente-Servidor: Uma
Estratégia e um Estudo de Caso, UFPR , Curitiba, 2002.
WATSON, R. T.; PITT, L. F.; CUNNINGHAM, C. J.; NEL, D; "User satisfaction and
service quality of the IS department: closing the gaps". Journal of Information
Technology. 1993
WEBER, K. ROCHA, A. NASCIMENTO, C. Qualidade e Produtividade em software.
Makron Books. 2001.
WOODRUFF, Wayne D., Introduction of Test Process Improvement and the Impact on
the Organization, American Society for Quality, USA, 2003.
ZEITHAML, Valarie A.; PARASURAMAN, A.; BERRY, Leonard L. Delivering Quality
Service. New York: The Free Press, 1990.
223
GLOSSÁRIO
Área-chave de processo:(key process área): Grupo de atividades correlatas que,
quando executadas coletiva e rotineiramente, satisfazem um conjunto de metas consideradas
importantes para estabelecer a capacitação do processo. As áreas-chaves de processo são
agregadas em níveis de maturidade. São os principais itens que apóiam a determinação da
capacitação do processo de software de uma organização e permitem identificar as melhorias
necessárias para avançar em direção a níveis de maturidade mais elevados.
Capacitação (Capabilidade) do Processo: É o intervalo ou faixa de tolerância dos
resultados esperados, que podem ser alcançados seguindo um processo de software. A
capacitação do processo de software é a habilidade inerente ao processo de software em
produzir resultados planejados. Quanto maior a capacitação menor será a incerteza e,
consequentemente, mais estreita será a distribuição estatística dos erros de estimativa, ou seja,
menor será a tolerância inerente ao processo. Dessa forma, a capacitação fundamenta a
expectativa de que o consumo de recursos e os resultados da realização do processo se situem
em patamares de produtividade e qualidade esperados.
Características comuns (common features): Organização das áreas-chaves de processo do
CMM. As características comuns indicam se a implementação e a institucionalização de uma
área-chave de processo são efetivas, repetíveis e duradouras. As características comuns do
CMM são as seguintes:
· Compromissos em executar (commitment to perform): São as ações que a
organização deve tomar para garantir que o processo estará estabelecido e será duradouro.
Envolve tipicamente políticas organizacionais e responsabilidades da gerência sênior.
· Habilitações para executar (ability to perform): São as pré-condições que devem
existir no projeto ou na organização para implementar o processo de software de maneira
efetiva. Habilitação para executar tipicamente envolve assegurar a disponibilidade de
recursos, de estruturas organizacionais e de treinamento.
· Atividades executadas (activities performed): São as ações, papéis e procedimentos
necessários para implementar uma área-chave do processo. Envolvem tipicamente o
estabelecimento de planos e procedimentos, execução do trabalho, seu acompanhamento e a
tomada de ações corretivas quando necessário.
224
· Medições e análise (measurement and analysis): São as ações de medição necessárias
para determinar o estado de implementação do processo. São usadas para controlar e melhorar
o processo.
· Verificação da implementação (verifying implementation): São as ações realizadas
para assegurar que as atividades são executadas de acordo com os processos que foram
estabelecidos. Implementação da verificação tipicamente abrange revisões e auditorias pela
gerência e pelo grupo de garantia de qualidade de software.
CMM: (Capability Maturity Model): Descrição dos estágios através dos quais as
organizações de software evoluem quando definem, implementam, medem, controlam e
melhoram seus processos de software. Esse modelo provê em guia para selecionar estratégias
de melhoria de processo, facilitando a determinação da capacitação do processo corrente e a
identificação dos pontos mais críticos para a qualidade de software e melhoria de processo.
Desempenho do Processo: É o resultado das medições de consumo de recursos e da
qualidade dos resultados decorrentes da realização de determinado processo de software. Ou
seja, o desempenho do processo de software focaliza os resultados efetivamente encontrados,
enquanto que a capacitação do processo de software focaliza resultados esperados. Tendo em
vista as características de um projeto específico e o contexto dentro do qual esse processo é
conduzido, o desempenho do processo pode não refletir acuradamente a capacitação do
processo. Isto ocorre, pois acidentalmente, um processo maduro pode ter um desempenho
semelhante a um processo imaturo, pois está limitado a um ambiente.
Gerente de projeto: (project manager): Cargo com total responsabilidade de negócio para o
projeto inteiro. É a pessoa que dirige, controla, administra e regula um projeto de
desenvolvimento de um sistema envolvendo hardware e software. O gerente de projeto é a
pessoa efetivamente responsável por todo o projeto frente ao cliente.
Maturidade do Processo: É a extensão para qual um processo específico é explicitamente
definido, praticado, gerenciado, medido e controlado. Implica num potencial de crescimento
em capacitação, indicando o potencial do processo de software da organização, bem como a
consistência com a qual é aplicado em projetos.
225
Nível de Maturidade (maturity level): Patamar bem definido, direcionado ao
estabelecimento de um processo de software maduro. Os cinco níveis de maturidade do CMM
são:
· Inicial: O processo de software é caracterizado como não explicitado.
· Repetitivo: Estão estabelecidos processo de gerência básica de projetos para
acompanhar custo, cronograma e funcionalidades.
· Definido: O processo de software, tanto para as atividades de gerência como para as
de engenharia, é documentado, padronizado e integrado num processo de software padrão
para a organização.
· Gerenciado: São colecionadas e registradas medidas detalhadas do processo de
software e qualidade de produto.
· Em Otimização: É habitado um processo de melhoria contínua através da
realimentação quantitativa proveniente do processo e a partir de experimentos (pilotos) de
idéias e tecnologias inovadoras.
Produto de trabalho: (work product): Conjunto completo, ou qualquer item individual do
conjunto de produtos, procedimentos, documentação associada e dados destinados a serem
entregues a um cliente ou usuário final.
226
APÊNDICES
227
CARTA DE APRESENTAÇÃO
ADOÇÃO DAS PRÁTICAS DE TESTES DO MODELO CMMI NA MELHORIA
DA QUALIDADE DOS PRODUTOS E SERVIÇOS DE SOFTWARE
Prezado(a) Senhor(a):
Este questionário faz parte de uma tese do curso de MESTRADO PROFISSIONAL
EM SISTEMAS DE GESTÃO, UFF. O pesquisador busca investigar se a adoção dos
processos de testes do modelo CMMI, no desenvolvimento de produtos e serviços de testes de
software, impacta na qualidade percebida pelo usuário.
A pesquisa de campo será realizada na Tools Software, pelo pesquisador Roni Queiroz
Dias, que está realizando um subprojeto da pesquisa “Fatores Humanos e Tecnológicos e
Competitividade” Quintella (1997).
Agradecimentos antecipados pela sua participação neste estudo.
Atenciosamente,
___________________________________________
Prof. D.Sc. Heitor Luiz Murat de Meirelles Quintella
Líder de Projeto “Fatores Humanos e Tecnológicos e Competitividade”
228
QUESTIONÁRIO ISO/IEC 9126
AVALIAÇÃO DA QUALIDADE DO PRODUTO DE SOFTWARE
Este questionário contém questões sobre características e sub-características da
qualidade dos produtos de software segundo a norma ISO/IEC 9126, que são utilizadas por
organizações que pretendem avaliar a qualidade de seus produtos de software.
Os 21 (vinte e um) itens a seguir apresentados procuram identificar as principais
características que determinam a excelência de produtos de software.
Neste sentido, gostaríamos de saber a sua opinião sobre até que ponto, os produtos de
software da Tools Software possuem as características e sub-características descritas em
cada um dos itens enumerados.
Também neste caso, assinalar “x” no número 1, significa que aquela sub-característica
NUNCA esta presente no produto de software. Marcar o número 5 significa que aquela sub-
característica esta presente SEMPRE.
Você pode assinalar “x” em qualquer um dos números intermediários que melhor
representem suas convicções a respeito.
Não há respostas certas ou erradas só estou interessado no número que reflete com
precisão a existência da sub-característica de qualidade de software.
Informe o nome do produto:
..........................................................................................................................................
229
Perguntas Escala
1
Nunca
2
Raramente
3
Às vezes
4
Freqüentemente
5
Sempre
Funcionalidade
1. Sub-característica Adequação: Quanto
das funções solicitadas/necessárias, elas
realizam as funções de modo apropriado?
2. Sub-característica Acurácia: O
software realiza o que foi proposto
corretamente?
3. Sub-característica Interoperabilidade:
O software interage facilmente com os
sistemas especificados?
4. Sub-característica Conformidade: O
software está de acordo com as normas,
convenções ou regulamentações
previstas em leis?
5. Sub-característica Segurança de
acesso: O software evita acesso não
autorizado, acidental ou deliberado a
programas e dados?
Confiabilidade
6. Sub-característica Maturidade: com
que freqüência o software apresenta
falhas?
7. Sub-característica Tolerância à falhas:
como o software reage na ocorrência de
falhas?
8. Sub-característica Recuperabilidade: o
software é capaz de restabelecer a
operação em caso de falha?
Usabilidade
9. Sub-característica Inteligibilidade: é
fácil entender o conceito e a aplicação ?
10. Sub-característica Apreensibilidade:
é fácil aprender a usar o software ?
11. Sub-característica Operacionalidade:
é fácil de operar e controlar o software ?
Eficiência
12. Sub-característica Tempo: Os tempos
utilizados são compatíveis com o nível
de desempenho requerido pelo produto?
13. Sub-característica Recursos: Os
recursos utilizados são compatíveis com
o nível de desempenho requerido pelo
produto?
230
Manutenibilidade
14. Sub-característica Analisabilidade: É
fácil encontrar uma falha quando a
mesma ocorre? É fácil determinar uma
alteração?
15. Sub-característica Modificabilidade:
É fácil modificar, adaptar e remover
defeitos? É fácil executar uma alteração?
16. Sub-característica Estabilidade: Não
existem grandes riscos de ocorrência de
bugs quando se faz uma alteração?
17. Sub-característica Testabilidade: É
fácil testar quando se faz alterações?
Portabilidade
18. Sub-característica Adaptabilidade: É
fácil adaptar a outros ambientes sem
aplicar outras ações ou meios além dos
fornecidos para esta finalidade no
software considerado?
19. Sub-característica Capacidade para
ser instalado: É fácil instalar em outros
ambientes?
20. Sub-característica Capacidade para
substituir: É fácil usá-lo para substituir
outro software?
21. Sub-característica Conformidade:
Está de acordo com padrões ou
convenções de portabilidade?
231
CARTA DE APRESENTAÇÃO
ADOÇÃO DAS PRÁTICAS DE TESTES DO MODELO CMMI NA MELHORIA
DA QUALIDADE DOS PRODUTOS E SERVIÇOS DE SOFTWARE
Prezado(a) Senhor(a):
Este questionário faz parte de uma tese do curso de MESTRADO PROFISSIONAL
EM SISTEMAS DE GESTÃO, UFF. O pesquisador busca investigar se a adoção dos
processos de testes do modelo CMMI, no desenvolvimento de produtos e serviços de testes de
software, impacta na qualidade percebida pelo usuário.
A pesquisa de campo será realizada na Tools Software, pelo pesquisador Roni Queiroz
Dias, que está realizando um subprojeto da pesquisa “Fatores Humanos e Tecnológicos e
Competitividade” Quintella (1997).
Agradecimentos antecipados pela sua participação neste estudo.
Atenciosamente,
___________________________________________
Prof. D.Sc. Heitor Luiz Murat de Meirelles Quintella
Líder de Projeto “Fatores Humanos e Tecnológicos e Competitividade”
232
QUESTIONÁRIO SERVQUAL
PERCEPÇÃO DA QUALIDADE DO SERVIÇO DE TESTES DE SOFTWARE
Os 22 (vinte e dois) itens a seguir apresentados procuram identificar as principais
características que determinam a excelência de serviços de testes de software.
Neste sentido, gostaríamos de saber a sua opinião sobre até que ponto, os serviços de
testes da Tools Software possuem as características descritas em cada um dos itens
enumerados.
Também neste caso, assinalar “x” no número 1, significa que aquela característica
NUNCA esta presente no serviço de testes de software. Marcar o número 5 significa que
aquela característica esta presente SEMPRE.
Você pode assinalar “x” em qualquer um dos números intermediários que melhor
representem suas convicções a respeito.
Não há respostas certas ou erradas só estou interessado no número que reflete com
precisão a existência da característica de qualidade do serviço de testes de software.
Informe o nome do produto testado:
..........................................................................................................................................
233
Nº
Característica Escala
1
Nunca
2
Raramente
3
Às vezes
4
Freqüentemente
5
Sempre
P01
Têm equipamentos (hardware e software)
avançados para o suporte ao processo de
teste?
P02
Possui uma área dedicada à execução e
suporte aos processos de testes?
P03
Têm empregados organizados na execução
das atividades de testes?
P04
Têm elementos materiais relacionados com o
serviço (planos, procedimentos e relatórios)
visualmente atraentes?
P05
Projetos de testes agendados são executados
na data acordada?
P06
Na identificação de erros, os analistas de
testes demonstram interesse na resolução dos
mesmos?
P07
Os testes são realizados corretamente na
primeira vez?
P08
O projeto de testes é concluído conforme o
tempo prometido?
P09
A equipe de testes mantém um histórico de
trabalhos sem erros?
P10
A equipe de testes comunica aos clientes
quando irá concluir os testes programados?
P11
Os analistas de testes prestam um serviço
rápido a seus clientes?
P12
Os analistas de testes estão sempre dispostos
à ajudar os clientes?
P13
Têm analistas de testes que nunca estão muito
para ocupados ajudar os clientes?
P14
Têm analistas de testes que transmitem por
meio de seu comportamento, confiança à seus
clientes?
P15
Fazem que o cliente se sinta seguro com os
processo de testes adotados pela empresa?
P16
Têm analistas de testes que se preocupam
com a segurança do ambiente e dados
utilizados para testes?
P17
Têm analistas de testes com conhecimentos
suficientes para responder às perguntas dos
clientes?
P18
Têm analistas de testes com bom
relacionamento entre as outras áreas do
projeto e da organização.?
P19
Têm horários de execução dos processos de
testes convenientes para todos os clientes?
234
P20
A maioria dos participantes do grupo de testes
participa das atividades de teste em tempo
integral?
P21
Preocupam-se pelos melhores interesses de
seus clientes.
P22
Têm empregados que compreendem as
necessidades específicas de seus clientes.
235
CARTA DE APRESENTAÇÃO
ADOÇÃO DAS PRÁTICAS DE TESTES DO MODELO CMMI NA MELHORIA
DA QUALIDADE DOS PRODUTOS E SERVIÇOS DE SOFTWARE
Prezado(a) Senhor(a):
Este questionário faz parte de uma tese do curso de MESTRADO PROFISSIONAL
EM SISTEMAS DE GESTÃO, UFF. O pesquisador busca investigar se a adoção dos
processos de testes do modelo CMMI, no desenvolvimento de produtos e serviços de testes de
software, impacta na qualidade percebida pelo usuário.
A pesquisa de campo será realizada na Tools Software, pelo pesquisador Roni Queiroz
Dias, que está realizando um subprojeto da pesquisa “Fatores Humanos e Tecnológicos e
Competitividade” Quintella (1997).
Agradecimentos antecipados pela sua participação neste estudo.
Atenciosamente,
___________________________________________
Prof. D.Sc. Heitor Luiz Murat de Meirelles Quintella
Líder de Projeto “Fatores Humanos e Tecnológicos e Competitividade”
236
QUESTIONÁRIO – CMMI
Este questionário contém questões sobre a adoção de práticas e sub-práticas das áreas
de processo Verificação e Validação do modelo CMMI, que são utilizadas por organizações
que pretendem melhorar seus processos de desenvolvimento de produtos e serviços de
software. Informe-nos, por favor, até que ponto considera que essas práticas e sub-práticas
são aplicadas no desenvolvimento dos produtos e serviços de testes de software.
Também neste caso, assinalar “x” no número 1, significa que aquela prática NUNCA
foi aplicada no desenvolvimento do projeto de software. Marcar o número 5 significa que
aquela prática e sub-práticas vem sendo utilizada SEMPRE.
Você pode assinalar “x” em qualquer um dos números intermediários que melhor
representem suas convicções a respeito.
Não há respostas certas ou erradas só estou interessado no número que reflete com
precisão a utilização das práticas e sub-práticas das áreas de processos de Verificação e
Validação do modelo CMMI.
Informe o nome do produto:
..........................................................................................................................................
237
Perguntas Escala
1
Nunca
2
Raramente
3
Às vezes
4
Freqüentemente
5
Sempre
1 - Os produtos a serem verificados
foram identificados?
2 - Os requisitos a serem satisfeitos para
cada produto foram identificados?
3 - Os métodos de verificação
disponíveis foram identificados?
4 - Os métodos de verificação para cada
produto foram definidos?
5 - Os produtos a serem verificados, os
requisitos a serem satisfeitos e os
métodos a serem usados para integração
com o plano de projeto foram enviados?
6 - Os requisitos do ambiente de
verificação foram identificados?
7 - Os recursos de verificação
disponíveis para reuso e modificação
foram identificados
8 - Os equipamentos e ferramentas de
verificação foram identificados?
9 - Os equipamentos de suporte e
ambiente de verificação, como
equipamentos de teste e softwares foram
adquiridos?
10 - Um conjunto de procedimentos de
verificação compreensível e integrado
para os produtos, conforme a necessidade
foi gerado?
11 - Os critérios de verificação foram
desenvolvidos e refinados quando
necessário?
12 - Os resultados esperados, quaisquer
tolerâncias permitidas na observação e
outros critérios para cumprir os
requisitos foram identificados?
13 - Equipamentos e componentes do
ambiente necessários para a verificação
foram identificados?
14 - O tipo de revisão que será conduzida
foi determinado?
15 - Os requisitos para a coleta de dados
durante a revisão foram definidos?
16 - Os critérios de entrada e saída para a
revisão foram estabelecidos e mantidos?
17 - Os critérios para a requisição de uma
nova revisão foram estabelecidos e
mantidos?
238
18 - Os checklists para garantir que os
produtos sejam revisados constantemente
foram estabelecidos e mantidos?
19 - Uma agenda de revisão detalhada,
incluindo as datas para o treinamento de
como fazer revisão e de quando o
material para revisão estará disponível
foi desenvolvida?
20 - Foi certificado que o produto
cumpre os critérios de entrada para
revisão antes da distribuição?
21 - O produto foi distribuído para
revisão e as informações relacionadas
entre os participantes com uma
antecedência suficiente para que eles se
preparem adequadamente para a revisão?
22 - Os papéis para a revisão foi
designados apropriadamente?
23 - A revisão dos participantes fazendo
uma revisão do produto antes de
conduzir a revisão foi preparada?
24 - Os papéis da revisão foram
desempenhados?
25 - Defeitos nos documentos e outros
aspectos do produto foram identi
ficados?
26 - Os resultados da revisão, incluindo
os itens de ação foram armazenados?
27 - Os dados da revisão pelos
participantes foram coletados?
28 - Os itens de ação foram identificados
e levados a questão aos stakeholders
relevantes?
29 - Revisões necessárias se critérios
definidos indicassem necessidade foram
conduzidas?
30 - Foi certificado que os critérios de
saída da revisão foram satisfeitos?
31 - Os dados relacionados a preparação,
condução e resultados das revisões foram
armazenados?
32 - Dados para futura referência e
análise foram armazenados?
33 - Os dados foram protegidos
garantindo que não fossem usados de
inapropriadamente?
34 - Os dados da revisão foram
analisados?
35 - Foi verificado que os produtos estão
de acordo com seus requisitos?
239
36 - Os dados das atividades de
verificação foram armazenados?
37 - Os itens de ação resultantes da
verificação dos produtos foram
identificados?
38 - Foi documentado o método de
verificação "como executar" e os desvios
dos métodos e procedimentos
disponíveis descobertos durante a sua
realização?
39 - Os resultados reais aos resultados
esperados foram comparados?
40 - Baseando-se nos critérios de
verificação estabelecidos, foi identificado
os produtos que não cumpriam seus
requisitos ou identificados os problemas
nos métodos, procedimentos, critérios e
ambiente de verificação?
41 - Os dados da verificação sobre os
defeitos foram analisados?
42 - Os resultados da análise foram
registradas num relatório?
43 - Foram utilizados os resultados da
verificação para comparar a performance
real com os parâmetros técnicos de
performance?
44 - A informação de como os defeitos
deverão ser resolvidos (incluindo os
métodos de verificação, critérios e
ambiente de verificação) foram providas
e formalizadas em um plano?
45 - Os princípios chave, características e
fases para a validação dos produtos
foram identificados?
46 - Categoria de necessidades do
usuário (operacionais, de manutenção, de
treinamento ou suporte) que deveriam ser
validadas foram determinadas?
47 - Os produtos e componentes que
deveriam ser validados foram
selecionados?
48 - Os métodos de validação para os
produtos e componentes foram
selecionados?
49 - A seleção de validações, restrições e
métodos relevantes foram revisadas com
os stakeholders?
50 - Os requisitos do ambiente de
240
validação foram identificados?
51 - Os produtos fornecidos pelos
clientes foram identificados?
52 - Os itens de reuso foram
identificados?
53 - Os equipamentos e ferramentas de
teste foram identificados?
54 - Os recursos de validação que
estariam disponíveis para reuso e
modificação foram identificados?
55 - A disponibilidade de recursos foi
planejada detalhadamente?
56 - Foi feita revisão nos requisitos do
produto para garantir que as questões que
afetam a validação do produto e seus
componentes foram identificadas e
resolvidas?
57 - O ambiente, o cenário operacional,
os procedimentos a entrada, a saída e os
critérios para a validação do produto ou
componente selecionado foi
documentado?
58 - O projeto foi avaliado durante sua
maturação no contexto do ambiente de
validação para identificar as questões de
validação.
59 - Foram gerados relatórios de
validação?
60 - Foram gerados resultados de
validação?
61 - Foi utilizada uma matriz de
referência cruzada da validação?
62 - Foram gerados registros de
procedimento de "como executar"?
63 - Foram geradas demonstrações
operacionais dos produtos?
64 - Os resultados obtidos foram
comparados com os esperados?
65 - Baseando-se nos critérios de
validação estabelecidos, foram
identificados os produtos e componentes
que não tiveram a performance desejada
no seu ambiente de operação, ou
identificados problemas nos métodos,
critérios e ou ambiente?
66 - Os dados da validação sobre os
defeitos foram analisados?
67 - Os resultados das analises foram
registrados e a casos a serem tratados
241
foram analisados?
68 - Os resultados da validação foram
utilizados para comparar as medições
feitas e performance obtida com o uso
pretendido ou necessidades
operacionais?
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
