AVALIANDO O USO DE FERRAMENTAS DE MEDIÇÃO COMO FATOR DETERMINANTE PARA ADOÇÃO DE MÉTRICAS DE
MANUTENIBILIDADE DE SOFTWARE EM COMPANHIAS BRASILEIRAS DE SOFTWARE
por
Micael Soares de França Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2016
Universidade Federal de Pernambuco Centro de Informática
Pós-graduação em Ciência da Computação
Micael Soares de França
AVALIANDO O USO DE FERRAMENTAS DE MEDIÇÃO COMO FATOR DETERMINANTE PARA ADOÇÃO DE MÉTRICAS DE MANUTENIBILIDADE DE
SOFTWARE EM COMPANHIAS BRASILEIRAS DE SOFTWARE
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Sergio Castelo Branco Soares Co-Orientadora: Juliana de Albuquerque Gonçalves Saraiva
RECIFE 2016
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
F814a França, Micael Soares de.
Avaliando o uso de ferramentas de medição como fator determinante para adoção de métricas de manutenibilidade de software em companhias brasileiras de software / Micael Soares de França. – 2016.
84 f.: il., fig., tab.
Orientador: Sérgio Castelo Branco Soares.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2016.
Inclui referências e apêndices.
1. Engenharia de software. 2. Engenharia de software empírica. 3. Manutenção de software. I. Soares, Sérgio Castelo Branco. (orientador). II. Título.
Micael Soares de França
Avaliando o Uso de Ferramentas de Medição como Fator Determinante para Adoção de Métricas de Manutenibilidade de Software em Companhias
Brasileiras de Software
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação.
_________________________________ Prof. Dr. Sérgio Castelo Branco Soares Orientador do Trabalho de Dissertação
Aprovado em: 01/02/2016
BANCA EXAMINADORA
________________________________________________ Prof. Dr. Henrique Emanuel Mostaert Rebêlo
Centro de Informática / UFPE
________________________________________________ Profa. Dra. Sabrina dos Santos Marczak
Faculdade de Informática/PUC- RS
___________________________________________________________ Profa. Dra. Juliana de Albuquerque Gonçalves Saraiva (Co-Orientadora)
Agradecimentos
A Deus, por me permitir alcançar meus objetivos com força e determinação.
Ao meu pai Luiz Soares, e minha mãe Luzmar Soares, por todo apoio, dedicação e suporte concedidos durante todo o meu período ao longo da execução deste meu trabalho, e sem os quais eu não estaria aqui.
A minha amada Vanessa Claudino, por toda paciência que teve comigo durante meus momentos de estresse e pelo apoio e carinho que tem me dado.
Ao meu orientador Sérgio Soares, obrigado pela oportunidade, confiança e pelo empenho durante o mestrado. Obrigado a minha co-orientadora Juliana Saraiva, por todo suporte e ajuda, sempre se mostrando disponível para esclarecer e tirar dúvidas durante o desenvolvimento deste trabalho.
E ao meu amigo, Samuel Carlos, que me acompanhou durante todo esse trabalho sempre dando apoio e suporte.
Resumo
O desenvolvimento de software engloba uma série de atividades cuja complexidade é notória. Quando este desenvolvimento não é gerenciado adequadamente pode haver diminuição na qualidade do software, aumento nos custos e atrasos nas entregas. Neste contexto, a manuteni-bilidade de software é considerada um atributo de qualidade que possui uma importante função na análise de qualidade de software. Geralmente, diversas áreas distintas, tais como Desenvolvi-mento de Software, Gestão de Projetos e Pesquisa de Software adotam métricas que atuam como indicadores que resumem uma série de informações, ajudando a caracterizar e entender certas circunstancias envolvidas na produção de um sistema. Por outro lado, determinar características de manutenibilidade em um sistema pode apresentar significantes desafios para um engenheiro de manutenibilidade. Por conseguinte, visando auxiliar o uso destas métricas, diversas ferramentas estão disponíveis para facilitar a análise e coleta de métricas software aplicadas a diversos contextos no desenvolvimento de um projeto. No entanto, a variedade de ferramentas e falta de informações para avaliar melhor o uso de cada uma, pode dificultar em algum aspecto a seleção e aplicação de novas métricas ou ferramentas. Face a esta realidade, este trabalho tem como objetivo investigar a adoção e uso de ferramentas que auxiliem a coleta de métricas de manutenibilidade de software e como elas podem estar relacionadas a escolha de tais atributos utilizados sob contexto industrial. E adicionalmente, verificar a sua representatividade, quais são as mais comuns e em que contexto são utilizadas. Para levantar os dados necessários para a análise e avaliação dessas ferramentas utilizadas no cenário industrial foi escolhido o Survey, como método empírico. Os dados coletados mostraram-se significantes para entendimento do cenário industrial no contexto relacionado, ajudando na integralização do conhecimento sobre uso de ferramentas e métricas adotadas na indústria.
Palavras-chave: Engenharia de Software. Manutenção de Software. Manutenibilidade de Software. Métricas de Software. Ferramentas de Suporte. Ferramentas CASE. Survey.
Abstract
Software development includes a series of activities whose complexity is notorious. When the development is not properly managed there can be decrease in software quality, higher costs and schedule delays. In this context, software maintainability (SM) is considered a quality attribute that plays an important role in the software quality analysis. Usually, several different areas such as Software Development, Project Management and Research in Software adopt metrics that act as indicators that summarize lots of information, helping to characterize and understand certain circumstances involved in the system production. However, determining maintainability characteristics of a system can present significant challenges for maintainability engineer. Therefore seeking to support using metrics, several tools have been developed to facilitate the collection and analysis of software metrics applied in different contexts on a project. However, the variety of tools and lack of information to better evaluate the use of each one, can hinder in some way the selection and application of new metrics and tools. Considering this fact, this research aims to investigate the adoption and use of tools to assist the collection of SM metrics and how they may be related to the choice of such attributes used in industrial context. Besides, we also aim to verify its representativeness, which are the most common and in what context they have been used. To gather all necessary data for analysis and evaluation of these tools used in industrial scenario, we chose Survey as empirical method. The data collected proved to be significant for understanding the industrial scenario in the referred context, helping the integration of knowledge about using tools and metrics adopted in the industry.
Keywords: Software Engineering. Software Maintenance and Evolution. Software Metrics. Tools Support. Survey.
Lista de Figuras
2.1 Características do modelo de qualidade de software e subcategorias de
manuteni-bilidade. . . 17
2.2 Requisicao de Modificação . . . 18
3.1 Diagrama de atividades de um Survey . . . 26
4.1 Tabulação dos dados de questionário para cálculo do alfa de Cronbach . . . 37
4.2 Perfil das Empresas Entrevistadas . . . 39
4.3 Relação entre realização de Manutenção e Uso de Métricas . . . 40
4.4 Perfil das Empresas Respondentes . . . 40
4.5 Setor de Atuação das Empresas Respondentes . . . 41
4.6 Tipos de Software Desenvolvidos . . . 41
4.7 Metodologias Adotadas pelas Empresas . . . 42
4.8 Nuvem de Palavras das Entrevistas . . . 42
4.9 Utilização de Ferramentas . . . 44
4.10 Valores do coeficiente de correlação . . . 44
4.11 Motivos pelos quais não usam ferramentas . . . 46
4.12 Motivos pelos quais ferramentas nem sempre são utilizadas . . . 47
4.13 Circunstâncias onde ferramentas são utilizadas . . . 47
4.14 Frequência de Menção das Ferramentas . . . 48
4.15 Desvantagens/Dificuldades quanto a ferramentas usadas . . . 51
4.16 Vantagens/Benefícios quanto a ferramentas usadas . . . 52
C.1 Página Inicial do Questionário Online . . . 71
C.2 Questionário — Primeira Parte (Página 01) . . . 72
C.3 Questionário — Primeira Parte (Página 02) . . . 73
C.4 Questionário — Segunda Parte (Página 01) . . . 74
C.5 Questionário — Segunda Parte (Página 02) . . . 74
C.6 Questionário — Terceira Parte: Cenário de Utilização de Métricas de MS (Página 01) . . . 75
C.7 Questionário — Terceira Parte: Cenário de Utilização de Métricas de MS (Página 02) . . . 76
C.8 Questionário — Terceira Parte: Cenário de Utilização de Métricas de MS (Página 03) . . . 77
C.9 Questionário — Terceira Parte: Cenário de Utilização de Métricas de MS (Página 04) . . . 77
C.10 Questionário — Terceira Parte: Cenário de Utilização de Métricas de MS (Página 05) . . . 77 C.11 Questionário — Terceira Parte: Cenário de Não Utilização de Métricas de MS
(Página 01) . . . 78 C.12 Questionário — Terceira Parte: Cenário de Utilização de Métricas de MS (Página
06) . . . 79 C.13 Questionário — Terceira Parte: Cenário de Utilização de Métricas de MS (Página
07) . . . 80 C.14 Questionário - Página Final . . . 81
Lista de Tabelas
2.1 Lista de Métricas da ferramenta PIVot . . . 24 4.1 Tabulação dos dados de questionário . . . 38 4.2 Utilização de ferramentas, métricas e certificações distribuída por empresas . . 45 4.3 Lista de Ferramentas Usadas pelas Empresas . . . 49
Sumário
1 Introdução 12
1.1 Contexto e Motivação . . . 12
1.2 Objetivos . . . 13
1.3 Problema e Questões de Pesquisa . . . 14
1.4 Organização da Dissertação . . . 15
2 Fundamentação Teórica 16 2.1 Manutenibilidade de Software . . . 16
2.2 Métricas de Software . . . 19
2.3 Ferramentas de Suporte a Métricas de Software . . . 21
2.4 Trabalhos Relacionados . . . 22
3 Método de Pesquisa 25 3.1 Framework Metodológico . . . 25
3.1.1 Definição dos Objetivos da Pesquisa e Administração do Projeto . . . . 25
3.1.2 Elaboração do Instrumento de Pesquisa . . . 26
3.1.3 Avaliação do Instrumento de Pesquisa . . . 28
3.1.4 Documentação do instrumento de pesquisa . . . 29
3.1.5 Obtenção de dados válidos . . . 29
3.1.6 Análise dos dados . . . 30
3.2 Design da Pesquisa . . . 31
3.2.1 Entrevista . . . 32
3.2.2 Questionário Online . . . 33
3.2.3 Ameaças a Validade . . . 34
4 Resultados e Discussão 36 4.1 Validação das Respostas . . . 36
4.2 Análise dos Resultados . . . 37
4.2.1 Perfil das Empresas . . . 37
4.2.2 Análise Geral sobre os Dados . . . 42
4.2.3 Análise das Ferramentas . . . 43
4.3 Resumo - Questões de Pesquisa . . . 53
4.3.1 Q1 - Qual a importância para as empresas quanto ao uso de ferramentas CASE voltadas a métricas de software? . . . 53
4.3.2 Q2 - A existência de ferramentas de coletas de métricas é uma condição prévia para escolha de métricas de manutenção? . . . 54
11 4.3.3 Q3 - Quais ferramentas mais utilizadas para coletar esses tipos de métricas? 54 4.3.4 Q4 - Há ferramentas de medição em comum usadas nas empresas? O
uso dessas ferramentas está ligada a alguma característica em comum
entre essas empresas? (tipos de projetos, tamanho da empresa, etc)? . . 54
5 Considerações Finais 56 5.1 Conclusão . . . 56 5.2 Trabalhos Futuros . . . 57 Referências 59 Apêndice 64 A Protocolo de Entrevista 65 A.1 Informações Gerais do Protocolo . . . 65
A.1.1 Sobre a Entrevista . . . 65
A.1.2 Visão Geral do Protocolo . . . 66
A.2 Dados Sobre a Pesquisa . . . 67
A.3 Termos utilizados na entrevista/questionário . . . 67
A.4 Perguntas/Questionário: Informações Gerais . . . 67
A.4.1 Dados do Entrevistado . . . 67
A.4.2 Questões da Entrevista . . . 68
B Termo de Confidencialidade e Sigilo 69
C Questionário 70
D Carta Convite para Divulgação das Entrevistas 82
12 12 12
1
Introdução
Este capítulo apresenta uma introdução sobre o tema do trabalho, bem como relevância, motivação e objetivos, expondo cada um em seções a seguir. Primeiramente, o contexto e motivação em que se insere o projeto são apresentados na Seção 1.1. Em seguida o problema de pesquisa abordado é exposto na Seção 1.3. Por fim, os objetivos do projeto são descritos na Seção 1.2.
1.1
Contexto e Motivação
O desenvolvimento de software engloba uma série de atividades cuja complexidade é notória (RAGAB; AMMAR, 2010). Quando este desenvolvimento não é gerenciado adequada-mente pode haver diminuição na qualidade do software, aumento nos custos e atraso na entrega, muitas vezes acarretando o cancelamento do projeto. Se um design errado não é corrigido logo, o custo para a correção após a entrega do software pode ser de 5 a 100 vezes maior (RAGAB; AMMAR, 2010). Assim, visando garantir uma melhor qualidade no desenvolvimento e diminuir a complexidade em torno do mesmo é que diversas técnicas são empregadas tanto para estruturação do software quanto para o desenvolvimento do projeto como todo (ALBIN, 2003).
A manutenibilidade de software é considerada uma característica de qualidade de soft-ware que possui uma função importante na análise de qualidade (PRESSMAN, 2011). Quanto menor o esforço/custo no ciclo de manutenção de software, maior tende ser a qualidade do software (PRESSMAN, 2011). Portanto, novos métodos de desenvolvimento de software, téc-nicas e ferramentas, visam minimizar custos futuros no processo de manutenção (SULTAN; EN-NOUAARY; HAMOU-LHADJ, 2008).
Neste sentido, a manutenibilidade de software desempenha um importante papel no que se refere ao desenvolvimento de software. Várias métricas têm sido estudas, propostas e utilizadas como indicadores quantitativos e qualitativos na pesquisa em Engenharia de Software (ES) (MINGGUANG et al., 2009; ALSHAMMARI; FIDGE; CORNEY, 2010; BESZEDES et al., 2007; SARAIVA; SOARES; CASTOR, 2010). Geralmente, diversas áreas distintas,
1.2. OBJETIVOS 13 tais como Desenvolvimento de Software, Gestão de Projetos e Pesquisa de Software adotam métricas que atuam como indicadores que resumem uma série de informações que ajudam a caracterizar e entender certas circunstâncias envolvidas na produção de um software, modelagem dos requisitos ou do projeto, contribuindo assim com tomada de decisão relacionada a cada processo (PRESSMAN, 2011). Por outro lado, determinar características de manutenibilidade em um sistema pode apresentar significantes desafios para um engenheiro de software (VARCOE, 1994).
Por conseguinte, visando auxiliar a adoção destas métricas, diversas ferramentas estão disponíveis para facilitar a análise e coleta de métricas software aplicadas a diversos contextos no desenvolvimento de um projeto (LINCKE; LUNDBERG; LöWE, 2008). Muitas delas, por exemplo, auxiliam a análise do custo/esforço da manutenção de um software (BITMAN, 1999). No entanto, a grande variedade de ferramentas e falta de informações para avaliar um bom caminho para suas adoções, pode dificultar em algum aspecto o uso ou escolha de alguma nova métrica ou ferramenta (LINCKE; LUNDBERG; LöWE, 2008).
Face a esta realidade, este trabalho tem como objetivo investigar a adoção e uso de ferramentas que auxiliem a coleta de métricas de softwares e como elas podem estar relacionadas com a escolha das métricas utilizadas na indústria. E adicionalmente, também se verificou a representatividade destas ferramentas, quais são as mais comuns e em que contexto são utilizadas. Com isso, espera-se contribuir para um melhor entendimento quanto às ferramentas de medição adotadas na indústria e consequentemente ajudar a facilitar a escolha e adesão delas neste contexto.
1.2
Objetivos
O objetivo geral dessa pesquisa é identificar e sumarizar informações sobre as fer-ramentas mais utilizadas na indústria de software brasileira que dão suporte a utilização e coleta de métricas de software. Espera-se fornecer informações válidas a profissionais e pesquisadores da área, afim de prover um melhor entendimento no uso de métricas e ferramentas no contexto desse cenário.
Objetivos específicos:
1. Realizar levantamento de dados na indústria brasileira para coletar e listar infor-mações sobre quais ferramentas são utilizadas nas empresas;
2. Verificar a representatividade delas, quais são as mais comuns e em que contexto são utilizadas;
3. Avaliar o impacto dessas ferramentas nas escolhas das métricas adotadas, se a escolha ou uso das métricas está condicionada ao uso de uma ferramenta;
1.3. PROBLEMA E QUESTÕES DE PESQUISA 14 4. Identificar e analisar as características de uso das ferramentas na indústria, pontos
positivos ou negativos do seu uso.
1.3
Problema e Questões de Pesquisa
As ferramentas de suporte a métricas podem melhorar as atividades de desenvolvimento e manutenção como todo, motivo pelo qual muitos autores vem propondo ferramentas(YAZBEK, 2010; MULLER, 1996; PREMKUMAR; POTTER, 1995). Por outro lado, muitas empresas ainda não fazem uso dessas ferramentas, optando muitas vezes pela análise manual das métricas (YAZBEK, 2010). Muitos trabalhos identificados visam propor ou comparar ferramentas entre si, mas poucos procuram avaliar o contexto de uso e adoção das mesma nas empresas (RAGAB; AMMAR, 2010; YAZBEK, 2010; MULLER, 1996; PREMKUMAR; POTTER, 1995; SHARMA; KAULGUD, 2013). Se as empresas e profissionais da área realmente não estão dando a devida atenção a adoção dessas ferramentas, então alguns desses trabalhos desenvolvidos em torno das ferramentas podem estar sendo em vão, por outro lado talvez a informação sobre essas ferramentas podem não estar chegando até as empresas (YAZBEK, 2010). Com a falta de trabalhos que melhor avaliem e sumarizem informações sobre o contexto de uso e adesão dessas ferramentas torna-se difícil para as empresas realizarem avaliações mais precisas e confiáveis e também encontrar as ferramentas adequadas aos seus propósitos. Esse problema leva a diversos questionamentos, como por exemplo, se essas ferramentas de suporte a métricas realmente vem sendo utilizadas pelas empresas ou o por quê de nem sempre serem utilizadas.
Diante do contexto abordado, o problema de pesquisa é a falta de informações que ajudem a entender melhor o uso de ferramentas de suporte a métricas de manutenibilidade de software no contexto industrial, e que consequentemente ajudem na melhora da tomada de decisão a cerca do uso dessas ferramentas. Os resultados, bem como objetivos dessa pesquisa, podem ajudar a responder os seguintes questionamentos:
Q1 - Qual a importância para as empresas quanto ao uso de ferramentas CASE voltadas a métricas de software?
Q2 - A existência de ferramentas de coletas de métricas é uma condição prévia para escolha de métricas de manutenção?
Q3 - Quais ferramentas mais utilizadas para coletar esses tipos de métricas?
Q4 – Há ferramentas de medição em comum usadas nas empresas? O uso dessas ferramentas está ligada a alguma característica em comum entre essas empresas? (tipos de projetos, tamanho da empresa, etc)
1.4. ORGANIZAÇÃO DA DISSERTAÇÃO 15
1.4
Organização da Dissertação
Após a introdução exposta neste capítulo, o Capítulo 2 apresenta os conceitos e fun-damentos teóricos que nortearam este trabalho: Manutenibilidade de Software, Métricas de Software e Ferramentas de suporte a métricas de sofware, além de abordar alguns trabalhos relacionados. No Capítulo 3, a metodologia de pesquisa para desenvolvimento deste trabalho, todo o framework metodológico, design da pesquisa e ameaças à validade da pesquisa são apresentados. Em seguida, os resultados são discutidos no Capítulo 4, e por fim, no Capítulo 5, são apresentadas as conclusões e os trabalhos futuros.
16 16 16
2
Fundamentação Teórica
Este capítulo apresenta o estado da arte sobre o tema abordado. Compreendendo assim, diversos fundamentos e conceitos relacionados com o projeto e cujos conhecimento se fazem necessário para execução deste trabalho. Alguns dos conceitos abordados são: manutenibilidade de software, métricas de software bem como ferramentas de suporte a métricas. Cada um desses assuntos abordados nas seções subsequentes.
2.1
Manutenibilidade de Software
O conceito de manutenção de software refere-se ao processo geral de mudança em um sistema depois que ele é liberado para uso pelos usuários finais (PRESSMAN, 2011). Essas mudanças são implementadas por meio de modificação de componentes do sistema existente e quando necessário por meio de adição de novos recursos. Podendo assim ocorrer essas mudanças devido à necessidade de correções de defeito (erros de codificação, projetos, ou de requisitos); adaptação ambiental (quando algum aspecto relativo ao ambiente do sistema, seja software/hardware, sofre mudança e o sistema da aplicação deve ser modificado para se adaptar a essas mudanças de ambiente); ou quando há nova adição de funcionalidade por mudanças nos requisitos do sistema (SOMMERVILLE, 2011).
Segundo o conceito de modelo de qualidade de software SquaRE (Software product Quality Requeriments and Evaluation), temos manutenibilidade de software como uma de suas características mais relevantes (KOSCIANSKI; SOARES, 2007). Esse modelo é hierárquico, onde a qualidade é dividida de acordo com uma série de fatores de influência. O modelo SquaRE é uma evolução de uma série de normas norma ISO/IEC (International Organization for Standard-ization/Internation Electrotechnical Comission) 9126 e ISO/IEC 14598, criado com o intuito de facilitar a documentação com relação a essas normas (KOSCIANSKI; SOARES, 2007; ISO/IEC, 2011). Segundo esse modelo, a qualidade de software possui 8 características (funcionalidade, manutenibilidade, usabilidade, confiabilidade, eficiência, portabilidade, segurança e compat-ibilidade) que por sua vez são divididas em subcategorias (ISO/IEC, 2011). A característica de manutenibilidade está relacionada à facilidade de modificação de um produto de software
2.1. MANUTENIBILIDADE DE SOFTWARE 17 durante toda sua evolução, desde correções do produto como adaptações dos requisitos, como já citado anteriormente. Baseado nisso, a característica de manutenibilidade divide-se em 5 subcategorias: testabilidade, reusabilidade, modularidade, modificabilidade e analisabilidade. Essas subcategorias são descritas abaixo, e exibidas na Figura 2.1 juntamente com as demais características do modelo de qualidade de software.
Modificabilidade refere-se a implementação e alterações no código fonte de um software, podendo ser facilitada através de uma documentação bem estruturada, escolha de arquitetura adequada ao software, e clareza do código.
A analisabilidade está relacionada com a facilidade de se identificar erros ou defeitos que possam estar causando falhas em um software por exemplo.
A modularidade é uma característica que está relacionada a interação e nível de acoplamento entre os diversos componentes de um sistema, de forma que mudanças realizadas em um determinado componente tenham impacto minimo sobre outros componentes.
A reusabilidade refere-se a capacidade do software de permitir que determinadas partes do seu código-fonte ou seus componentes possam ser reutilizadas na construção de outros sistemas.
Testabilidade é a capacidade de o software seja validado após uma modificação.
Figura 2.1: Características do modelo de qualidade de software e subcategorias de manutenibilidade.
2.1. MANUTENIBILIDADE DE SOFTWARE 18 Complementarmente, a manutenção de software dependendo do propósito pelo qual se iniciou, seja por motivo de correção ou melhoria de um software, pode ainda ser dividida em 4 tipos: corretiva, preventiva, adaptativa ou perfectiva (ISO/IEC, 2006). Os tipos de manutenção variam de acordo com as atividades pretendidas, conforme definido e ilustrado na Figura 2.2.
Figura 2.2: Requisicao de Modificação
Fonte: (ISO/IEC, 2006)
Manutenção Adaptativa refere-se a modificação do produto de software, a fim de adequá-lo a mudanças ocorridas no ambiente onde esse produto é usado;
Manutenção Corretiva refere-se a modificações com o objetivo de corrigir proble-mas descobertos após o software já ter sido entregue/liberado;
Manutenção Perfectiva visa detectar e corrigir possíveis deficiências, após o produto ser entregue, antes que elas surjam como uma falha no software. Geralmente as mudanças desse tipo provem melhorias ao software sejam de performance ou outros atributos;
Manutenção Preventiva objetiva detectar e corrigir possíveis falhas antes que se tornem problemas operacionais, que impeçam o correto funcionamento do software. Assim, o desafio da manutenção de software se dá desde o início da liberação do sistema aos usuários, demandando continuamente atividades como correções de bugs, solicitações de adaptações e melhorias a serem planejadas, programadas e executadas. Com isto muitas vezes o custo de uma organização de software com manutenção tende a deter mais de 60% do orçamento (SOMMERVILLE, 2011). Por isso a importância da manutenção e motivo de tanto esforço empregado nessa atividade. Esforço esse que pode ser dificultado tanto pelas necessidades que surgem pela evolução do software propriamente dita, que ao longo dos anos pode trazer novas necessidades como correções de erros e solicitações de novos ajustes, como também pela mudança de profissionais da equipe responsável pelo desenvolvimento do trabalho original e
2.2. MÉTRICAS DE SOFTWARE 19 consequente dificuldade dos novos profissionais, ainda não habituados com o funcionamento do sistema, a continuar seu desenvolvimento.
Consequentemente, um software com boa capacidade de manutenibilidade apresenta modularidade eficaz, utiliza padrões de projeto que permitem facilmente entendê-lo e usa padrões e convenções de codificação bem definidos, levando a um código-fonte de fácil entendimento (PRESSMAN, 2011). Portanto, é importante uma solução de projeto bem estruturada e uma implementação bem executada, para ajudar nas futuras atividades de manutenção de software e de acesso às informações que contribuam na redução de esforços com manutenção.
2.2
Métricas de Software
Métricas de software podem vir para auxiliar em questões relativas à manutenibilidade de software. Métricas são formas de medir determinadas características de um software ligado a sua estrutura ou funcionamento com o objetivo de avaliar e revisar dados, obtidos por essas métricas (SOMMERVILLE, 2011). Complementarmente, elas geralmente são associadas a medição, modelos de qualidade e modelos de estimativa (ABRAN, 2010). Com elas é possível fazer uma análise sobre qualidade do produto de software. Diversas são as métricas existentes e suas aplicações, que podem auxiliar no planejamento de um projeto. Métricas para medir algum aspecto relativo a tamanho de um software pode ajudar a estimar prazo e custo. Exemplos são métricas que medem a quantidade de linhas de código (Lines of Code - LOC) (MARQUES, 2013). Adicionalmente, o IEEE (2002) define Engenharia de software como "A aplicação de uma abordagem sistemática, disciplinada e quantificável para desenvolvimento, operação e manutenção de software". Além dos outros motivos já citados, pela definição já pode-se notar o quão é importante o uso de medições e consequentemente das métricas de software na engenharia de software como um todo.
De acordo com PRESSMAN (2011) e SINGH; SINGH; SINGH (2011) as métricas de software são definidas em 3 tipos:
Métricas de Produto - são usadas para medir propriedades do software ajudando a melhorar a qualidade dos componentes existentes do software. Alguns exemplos dessas métricas são as métricas de tamanho, complexidade, pontos de função, entre outras;
Métricas de Processo - usadas na gestão, sendo utilizadas para medir certos atrib-utos e propriedades do processo usado para se obter o software a fim de fornecer um conjunto de indicadores de processo que leve ao aperfeiçoamento do mesmo. Exemplos dessas métricas são as métricas de custo e esforço que podem auxiliar a verificar se a execução do projeto está de acordo com o cronograma;
Métricas de Projeto - usadas de forma mais táticas, por um gerente ou equipe de software, podendo ser usadas ao longo de todo o desenvolvimento do projeto
2.2. MÉTRICAS DE SOFTWARE 20 para acompanhar risco em potenciais e ajudar a ajustar fluxo de trabalho ou tarefas, geralmente são utilizadas logo no inicio para fazer estimativas;
Adicionalmente, as métricas de software ainda podem ser classificadas de diversas formas, podendo estarem relacionadas a atributos internos e externos (SOMMERVILLE, 2011):
Medidas Diretas (quantitativas), que envolvem questões como custo, esforço, lin-has de código, velocidade de execução, tamanho da memória, número de erros e complexidade ciclomática;
Medidas Indiretas (qualitativas), que são relativas a características de funcionali-dade, qualifuncionali-dade, complexifuncionali-dade, eficiência, confiabilidade e manutenibilidade; Dinâmicas, que são coletadas quando as medições são feitas em um programa em
execução;
Estáticas, que são medições feitas de representações do sistema como o programa ou documentação.
Além do uso das métricas propriamente dito, às vezes é necessária uma melhor organiza-ção e planejamento para realizaorganiza-ção do trabalho de mediorganiza-ção de software. Assim como qualquer outra atividade relacionada ao desenvolvimento de software, a própria medição de software tem de ser planejada para eficiência na execução (KOSCIANSKI; SOARES, 2007). O método GQM (Goal-Question-Metric) é uma forma de organizar o planejamento de uma medição de software considerando em suas fases questões como coleta, validação e análise dos dados obtidos (KOSCIANSKI; SOARES, 2007).
Embora várias outras métricas no geral possam ser utilizadas tanto para o desenvolvi-mento de um novo software quanto para manutenção do software existente, há métricas que foram projetadas especificamente para tratar de atividades de manutenção (PRESSMAN, 2011). Nesse contexto, as métricas de manutenibilidade são importante para o gerenciamento dessas atividades, visando facilitar e prever o esforço necessário para modificar um software quando necessário durante seu desenvolvimento e evolução.
Como exemplos de métricas de manutenibilidade podemos citar: (i) métricas de tamanho, que são indicadores de características como o tamanho do software, em termos de linhas de código, quantidade de funções ou classes; (ii) complexidade estrutural, que avalia a construção de um software, quanto ao caminho e a complexidade do mesmo pra se executar uma tarefa, medindo, por exemplo, quantidade de laços necessário para executar uma instrução; (iii) métricas baseadas no fluxo de dados, que medem a complexidade com base na quantidade de informações processadas pelas sub-rotinas do software; (iv) métricas de acoplamento e coesão, que analisa o grau de dependência entre os componentes de um programa; entre várias outras (KOSCIANSKI; SOARES, 2007). Portanto, torna-se evidente a importância e utilidade do estudo relativo ao uso de métricas de manutenibilidade de software.
2.3. FERRAMENTAS DE SUPORTE A MÉTRICAS DE SOFTWARE 21
2.3
Ferramentas de Suporte a Métricas de Software
Quando se fala em ferramentas de suporte a métrica de software, está se falando direta-mente de ferramentas CASE (Computer Aid Software Engineering) são ferramentas/sistemas utilizados para auxiliar, com apoio automatizado, nas diversas atividades relacionadas a desen-volvimento/projeto de software, ou seja, na utilização de métodos da engenharia de software (MULLER, 1996). Ferramentas CASE no geral auxiliam na edição de diferentes tipos de documentos, compilação, depuração e gerenciamento de informação. Complementarmente, as ferramentas de suporte a métricas de software provêm todos os mecanismos e recursos cita-dos voltacita-dos para o gerenciamento de informação, analise e coleta no contexto de métricas de software. E diversas são as formas como ferramentas CASE podem ser classificadas, seja por uma perspectiva mais funcional (de acordo com a função específica daquela ferramenta), ou até mesmo com relação aos tipos de processos e atividades que elas provêm suporte.
Muitos autores defendem o uso dos mais variados tipos de ferramentas CASE como forma de melhorar as atividades de desenvolvimento de software como um todo (YAZBEK, 2010; MULLER, 1996; PREMKUMAR; POTTER, 1995). Melhorias significativa são possíveis para diversas atividades, especialmente para atividades de programação não importando muito o tipo ou tamanho do projeto (YAZBEK, 2010). Desde a introdução das primeiras ferramentas CASE por volta da década de 80 já se acreditava que o seu uso geraria economias nos custos de processo de desenvolvimento de software (INSIDER, 2015). Segundo SOMMERVILLE (2011), as melhorias advindas do uso dessas ferramentas são limitadas a três fatores: (1) requisitos e requerimentos mal definidos, o que pode levar a um extensivo retrabalho no desenvolvimento do software, e por ser um problema mais de negócio do que técnico, as ferramentas de suporte não poderiam ajudar muito a reduzir custos nesse sentido; (2) questões arquiteturais e de designpor mais que as ferramentas venham auxiliar nessas questões, essa é uma atividade mais predominante dependente da criatividade, não podendo ser inteiramente por uma inteligência artificial tecnológica; (3) ferramentas colaborativas voltadas a melhorar a necessidade por comunicação e colaboração entre times de engenheiros geralmente não atendem de forma eficiente ao suporte do processo criativo.
Por fim, limitações à parte, as vantagens e melhorias proporcionadas são evidentes. Apesar disso, métricas e ferramentas de suporte a métricas ainda não são usadas por muitas empresas (YAZBEK, 2010). Segundo YAZBEK (2010), um dos motivos é o pouco conhecimento sobre métricas de software, o que torna seu uso difícil por parte de alguns desenvolvedores, além do processo de medição ser considerado custoso pelos gestores. Outra razão seria o fato de que boas ferramentas de métricas ainda seriam caras, especialmente para pequenas e médias empresas.
2.4. TRABALHOS RELACIONADOS 22
2.4
Trabalhos Relacionados
Há muitos trabalhos relativos a métricas de software na literatura, no entanto, a grande maioria trata apenas de questões específicas, como uso de alguma métrica específica aplicada no desenvolvimento de um software e seus benefícios quanto à qualidade de software. Por exemplo, RAWAT; MITTAL; DUBEY (2012) avalia o impacto do uso de métricas de software quanto a qualidade de software e a importância delas neste contexto, analisando seus pontos fortes e fracos, e qual conjunto de métricas utilizadas pelas empresas pesquisadas, porém o trabalho foca apenas nesse aspecto do uso de métricas. Além disso, há ainda algumas outras pesquisas isoladas que fazem algum levantamento quanto ao uso de alguma métrica em empresas, por exemplo, SOINI (2011) que estuda o uso de métricas de produto em empresas da Finlândia, procurando identificar tais métricas através de entrevistas e questionários conduzidos e aplicados em 10 empresas. ARRUDA; FILHO (2014) procura, através de um survey, identificar métricas utilizadas em companhias de software brasileira, conseguindo coletar dados de mais de 20 empresas do parque tecnológico do Porto Digital na cidade de Recife. Esses e outros trabalhos na maioria são restritos não só em relação ao estudo das métricas em si, geralmente resumindo a um grupo pequeno de empresas, como até mesmo em relação a ferramentas de suporte a coleta e análise dessas métricas que geralmente não são analisadas e estudadas quanto ao possível impacto do uso delas.
Complementarmente, nos trabalhos de SARAIVA (2013) e SARAIVA; SOARES; CAS-TOR (2013) temos uma iniciativa de pesquisa em contextos mais abrangentes no estudo do uso de métricas de software. Poucos são os trabalhos que procuram avaliar e relacionar tanto cenário industrial quanto acadêmico no que diz respeito as métricas de software, que é um ponto interessante realizado nesses trabalhos. Na pesquisa de SARAIVA et al. (2015) foi sumarizado e organizado um conjunto de métricas de manutenibilidade de software no contexto de software orientados a objetos propondo assim um catálogo para elas considerando os cenários tanto industrial quanto acadêmico. Neste estudo os autores realizaram um mapeamento sistemático objetivando identificar e catalogar cada métrica de acordo com seu tipo e cenários (industrial e acadêmico) nas quais estão inseridas. Mais de 600 métricas foram identificadas, catalogadas, e categorizadas e ao final uma ferramenta para auxiliar na pesquisa de informações sobre es-sas métricas foi também proposta. Porém esse trabalho não tinha como foco avaliar o uso de ferramentas de suporte a métricas de software.
Outros estudos LINCKE; LUNDBERG; LöWE (2008); RAGAB; AMMAR (2010); BUDIMAC et al. (2012) tratam de ferramentas que dão suporte a métricas de software, no entanto, há ainda uma escassez de trabalhos voltados a ferramentas de suporte relativas a métricas de manutenibilidade de software e seu uso no cenário industrial. A maioria dos trabalhos relativos ao assunto em questão realizam avaliação de qualidade/eficiência comparando ferramenta de coleta de dados entre si ou propõem novas ferramentas (LINCKE; LUNDBERG; LöWE, 2008; BAKAR; BOUGHTON, 2012; FARIA JUNIOR, 2006; NANDA et al., 2013). Há muitos artigos
2.4. TRABALHOS RELACIONADOS 23 que abordam apenas uma única ferramenta, exibindo suas características ou propondo novas ferramentas como soluções (ULVILA; GAFFNEY; CHINNIS J.O., 1998; BORGES, 2006; VIEIRA, 2007) , mas apenas poucos artigos sumarizam as ferramentas de métricas ajudando a analisar as diferenças entre elas ou a entender seu uso no contexto do cenário da indústria de software.
Concomitantemente, no trabalho de BUDIMAC et al. (2012), um projeto foi desenvolvido em parceria entre ministério da ciência de dois diferentes países, visando basicamente criar um melhor software no contexto em que necessitavam. Esse estudo tinha como objetivo principal detectar as principais dificuldades numa aplicação de métricas de software a fim de lidar com elas e desenvolver uma ferramentas melhor no contexto analisado. Situações como essas podem indicar uma deficiência nas ferramentas ou pouco conhecimento sobre as ferramentas já existentes e que poderiam atender a determinadas necessidades, como já mencionado por YAZBEK (2010).
Um exemplo de estudo que procurou analisar ferramenta de suporte a métricas de software no contexto industrial foi a pesquisa de SHARMA; KAULGUD (2013). Neste estudo foi feita uma análise da adoção e efetividade do uso de novas métricas em uma determinada empresa a partir de um conjunto de métricas providas por uma ferramenta chamada Pivot (SHARMA; KAULGUD, 2012). Na Tabela 2.1 pode ser observada a lista de métricas disponíveis na ferramenta. Nessa pesquisa foram coletados dados, através de um survey aplicado em um empresa, acerca do impacto das métricas e ferramenta utilizada em nove projetos. O resultado da pesquisa foi positivo, indicando que os projetos foram bem impulsionados pelo uso do PIVot e suas métricas. A ferramenta ajudou a tomar medidas específicas para benefício do projeto. No entanto, como observado, apesar desse estudo ajudar a apontar que o uso de métricas e ferramentas de suporte e coleta de métricas possam trazer benefícios, ele é limitado a um conjunto pequeno de métricas providas por uma única ferramenta no contexto de apenas um empresa.
Por fim, como previamente mencionado, alguns poucos estudos foram encontrados na literatura visando sumarizar ou avaliar o impacto e uso das ferramentas de suporte a métricas. No trabalho RAGAB; AMMAR (2010) foi realizado um survey com objetivo identificar um conjunto de métricas que possuíssem impacto significativo com relação a atributos de qualidade de design. Esse trabalho também comparou as características e recursos de algumas ferramentas de suporte a métricas (SD Metrics, ES2 tool, SAAT tool, SARA tool), mas ainda de uma forma muito limitada, sem avaliar o impacto do uso dela nas empresas e apenas realizando um resumo geral. Este contexto reforça a motivação dessa pesquisa para adicionar mais conhecimento sobre ferramentas de métricas de manutenibilidade de software tanto no contexto da academia como na indústria. Os resultados deste trabalho irão ajudar desenvolvedores e companhias na adesão de ferramentas e métricas de forma mais eficiente a partir do conhecimento da aplicação dessas ferramentas nestes cenários.
2.4. TRABALHOS RELACIONADOS 24
Tabela 2.1: Lista de Métricas da ferramenta PIVot
Métrica Tipo de Análise
Code Churn Modificação
Top Code Contributors Modificação
Per Package Code Contributors Modificação Per Package Code Churn History Modificação
Code Quality Index - Project codebase Qualidade de código Code Quality Index - Modified codebase Qualidade de código
Top Code Quality Issues Qualidade de código
Top Code Quality Issue Categories Qualidade de código Rate of Increase of Code Quality Issues Qualidade de código Packages with Highest Code Quality Issues Qualidade de código Code Churn Causing High Code Quality Issues Qualidade de código Persistent Code Quality Issues - Modified codebase Qualidade de código QCTE - Quality of Component Testing Effectiveness Teste de Unidade
UnTested Components Teste de Unidade
Poorly Tested Components Teste de Unidade
UnTested Complex Components Teste de Unidade Poorly Tested Complex Components Teste de Unidade Development Efficiency - Project codebase Eficiência
Development Efficiency - Modified codebase Eficiência
Highly Connected Resources Equipe
Poorly Connected Resources Equipe
Disconnected Resources Equipe
Programmer Fragmentation Equipe
Development Efficiency - Project codebase Equipe
25 25 25
3
Método de Pesquisa
Para desenvolvimento do trabalho proposto, uma série de atividades tiveram de ser realizadas. Essas atividades compreendem questões que vão desde o estudo da teoria necessária para realização desta pesquisa bem como a aplicação dos conceitos envolvidos. Nesta seção, explicita-se os aspectos metodológicos que guiaram a pesquisa, a coleta de dados e ameaças a validade. A Seção 3.1 apresenta a metodologia adotada, definições e características. Já na Seção 3.2 é detalhado o passo a passo de toda a execução do Survey, protocolo da pesquisa, entrevistas e questionário. Por ultimo, na Seção 3.2.3 são abordado questões relativas a ameaça a validade, quais são e o que foi feito para mitigá-los.
3.1
Framework Metodológico
Dada a natureza dos objetivos desse trabalho, relativo ao levantamento de informação quanto ao uso de métricas de manutenibilidade de software na indústria, o Survey foi escol-hido como método empírico para realização deste estudo. Survey é um método de pesquisa compreensível para coleta de informação para descrever, comparar ou explicar conhecimento, atitudes e comportamento de uma população, tendo como objetivo produzir estatísticas sobre uma população pela coleta de dados de uma amostra dessa população, por exemplo, através de questões (SHULL; SINGER; SJOBERG, 2009).
Um Survey compreende resumidamente seguintes atividades: (i) definição dos objetivos da pesquisa e administração do projeto; (ii) elaboração do instrumento de pesquisa; (iii) validação do instrumento de pesquisa; (iv) documentação do instrumento de pesquisa; (v) execução e obtenção de dados válidos; (vi) análise dos dados; (KITCHENHAM; PFIEEGER, 2001). A Figura 3.1 exibe a relação e sequencia de execução de cada uma das atividades citadas. Cada uma dessas atividades será descrita nas próximas seções.
3.1.1
Definição dos Objetivos da Pesquisa e Administração do Projeto
Um dos primeiros pontos a se fazer ao definir a pesquisa, claramente é definir seus objetivos, algo fundamental em qualquer pesquisa independente do método usado. Cada objetivo
3.1. FRAMEWORK METODOLÓGICO 26
Figura 3.1: Diagrama de atividades de um Survey
Fonte: Elaborado pelo autor
consiste de resultados esperados da pesquisa ou em uma pergunta que a pesquisa se destina a responder. Por exemplo, avaliar a frequência de alguma característica em uma população, avaliar gravidade de alguma condição que ocorre na população ou ainda identificar fatores que influenciam uma nova característica ou condição.
Complementarmente, nesta etapa, é preciso verificar a aplicabilidade do método, ou seja, se o Survey é realmente o método adequando de acordo com suas características. Adicionalmente, é preciso definir o tipo de projeto: transversal, quando provê informação sobre a população em determinado momento; ou longitudinal, quando provê informações sobre mudanças sofridas pela população ao longo do tempo (FREITAS et al., 2000). E por fim, definir o tipo de administração, ou seja, de que forma será executado, podendo ser através de questionário auto-administrado onde o participante responde a um questionário sem supervisão, ou por meio de entrevista, presencial ou não (KITCHENHAM; PFIEEGER, 2001). Todas essas decisões são importantes pois influenciam no projeto das questões.
3.1.2
Elaboração do Instrumento de Pesquisa
Após decidida todas as questões levantadas na primeira etapa do Survey, é preciso elaborar o instrumento de pesquisa em si, seja visando um questionário ou entrevista. Para isso é importante, dentre outras coisas, fazer um pesquisa na literatura a fim de evitar duplicação (não intencional) de pesquisa, e aprender com outros estudos, uma vez que questionários já validados em outros estudos podem ser reusados, e que medidas para problemas já ocorridos em estudos similares como taxa de resposta insuficiente poderão ser tomadas para evitá-los(KITCHENHAM; PFIEEGER, 2001).
Ao se criar o questionário um série de considerações devem ser observadas. Quanto ao reuso de questionário criado por outros, é preciso observar se as questões estão alinhadas com os
3.1. FRAMEWORK METODOLÓGICO 27 objetivos do estudo, se o questionário está bem validado, e em caso de não usar o questionário na integra e sim adaptá-lo será necessário validá-lo (GROVES et al., 2009).
Adicionalmente, é preciso cuidado com os tipos de questões que irão compor o ques-tionário e como serão formuladas. As questões podem ser abertas, mais vulneráveis a má interpretação e com análise de respostas mais difícil; ou podem ser fechadas, mais difícil de garantir o entendimento comum das respostas e de definir as opções de respostas adequadas (KITCHENHAM; PFIEEGER, 2001). Ainda quanto ao tipo de resposta, segundo KITCHEN-HAM; PFIEEGER (2001) as questões podem ser:
numéricas, tipo mais simples;
nominais, são classes não ordenadas, por exemplo tipo de projeto, podendo ser ainda exaustivas, mutualmente exclusivas ou ainda permitir seleção múltipla;
binárias (Sim/Não), que podem levar a considerações como : viés do consentimento (tendência de se concordar com algo em caso de dúvida); confiança; imprecisão pois possuem apenas 2 níveis de medida; além de nem sempre ser fácil expressar conceitos através de uma única pergunta/resposta;
resposta em escala ordinal, devem ser exaustivas mas não muito extensas, geralmente entre 5 e 7 pontos. Pontos devem ser identificados com palavras ao invés de números. Além de possuir uma escala balanceada: pontos extremos devem ser opostos, e haver espaços uniformes entre as escalas (KITCHENHAM; PFIEEGER, 2001).
Quanto a formulação, é preciso tomar cuidado para que as questões sejam precisas, não-ambíguas e compreensíveis (COLLADO; LUCIO; SAMPIERI, 2013).Portanto, outro ponto, relativo a elaboração do questionário está relacionado ao formato do mesmo. Baseado nos trabalhos de KITCHENHAM; PFIEEGER (2001), GIL (2002), FREITAS et al. (2000) alguns pontos devem ser levados em considerações, como:
Deixar espaço para participantes fazerem comentários;
Prezar pela legibilidade (contrastes de cores, tipo e tamanho de fonte); Usar recursos de ênfase (negrito, sublinhado, etc) de forma consistente;
Não dispor de questões, instruções ou respostas associadas em páginas/telas sepa-radas;
Ter cuidado com a ordem das questões, levando em consideração grau de dificuldade e o fato de que uma pergunta não influêncie na resposta da pergunta que a sucede, por exemplo;
3.1. FRAMEWORK METODOLÓGICO 28
Incluir informações no questionário que ajudem a guiar o respondente e a entender o contexto da pesquisa como: proposito do estudo, relevância do estudo para os participantes, explicação da importância da participação de cada indivíduo, e como a confiabilidade será preservada;
O questionário não pode ser muito extenso, para não desmotivar. Não possuir perguntas demais ou que levem muito tempo para serem respondidas;
Tomar cuidado com relação ao viés do pesquisador, ou seja, quando o questionário induz ao resultado desejado. Pode se tomar cuidados como: procurar elaborar questões neutras, ter questões suficientes para cobrir o assunto adequadamente, ordenar questões com cuidado evitando influência entre respostas, projetar categorias de respostas exaustivas e mutualmente exclusivas e prover instruções claras.
3.1.3
Avaliação do Instrumento de Pesquisa
Após definidos, os objetivos da pesquisa, o tipo de projeto e como será administrado, com o instrumento de pesquisa já elaborado, é preciso então validá-lo. A avaliação de um questionário, também chamado de pré-teste, tem como objetivos: checar se as questões são compreensíveis, avaliar a provável taxa de resposta, avaliar a confiabilidade e validade do questionário, e garantir que as técnicas de analise de dados que se pretende usar sejam adequadas para as respostas esperadas (SHULL; SINGER; SJOBERG, 2009). Essa é uma etapa muito importante e que pode consumir bastante tempo e esforço.
Essa avaliação pode ocorrer através de grupos de foco ou através de um estudo piloto, ambas abordagens podem ser utilizadas a fim de garantir melhor validade e confiabilidade. Nos grupos de foco, ou grupos de discussão mediados, um determinado grupo responde o questionário procurando identificar possíveis problemas como perguntas/instruções ausentes, desnecessárias ou ambíguas(KITCHENHAM; PFIEEGER, 2001). Adicionalmente, o estudo piloto é uma simulação da Survey para uma amostra menor da população com o objetivo de identificar problemas no questionário em si, bem como na taxa de resposta (KITCHENHAM; PFIEEGER, 2001). O estudo piloto é uma forma usada para avaliar a confiabilidade do instrumento.
Complementarmente, há uma série de questões relativas a validade do questionários que devem ser consideras para verificar o quão bem o questionário mede o que ele se propõe a medir. Basicamente, existem quatro tipos de validade a serem consideradas (KITCHENHAM; PFIEEGER, 2001): Validade Aparente, é uma análise superficial e informal, geralmente feita por avaliadores inexperientes, por isso não é tão amplamente aceita e muitas vezes pode ser subjetiva e mal definida; Validade de Conteúdo, é uma avaliação subjetiva sobre a adequação do questionário conduzida por um grupo de revisores (grupo focal), conhecedores do assunto, especialistas no domínio e membros da população alvo; Validade de Critério, mede o quanto o questionário se destaca em relação a outro questionário usado como referência (já validado),
3.1. FRAMEWORK METODOLÓGICO 29 ou avalia a habilidade do questionário de prever eventos futuros, comportamentos, atitudes ou resultados; e Validade de Construto, considerada uma medida de validade mais difícil e rigorosa, é avaliado o nível de significância do questionário na prática, procura-se verificar se há correlação entre os conceitos relacionados (validade convergente) ou a falta de correlação entre conceitos distintos (Validade Divergente). É importante salientar que a maioria dos estudos em engenharia de software são omissos em relação à verificação da confiança e validade dos questionários utilizados (KITCHENHAM; PFIEEGER, 2001).
3.1.4
Documentação do instrumento de pesquisa
A documentação de todo o instrumento de pesquisa desde sua concepção, elaboração, e a execução é uma etapa importante (KITCHENHAM; PFIEEGER, 2001). O estudo pode se prolongar e detalhes importantes podem ser esquecidos. Por exemplo, em relação a um questionário auto-administrado, poderia se elaborar uma especificação do questionário contendo objetivo do estudo, justificativa sobre as perguntas adotadas ou adaptadas de outras fontes, descrição do processo de avaliação, ou ainda detalhes após a aplicação como quem eram os respondente e como o questionário foi administrado.
3.1.5
Obtenção de dados válidos
Com relação a aplicação do survey é preciso observar certas questões relativas aos dados que se pretende coletar para garantir que esses dados sejam válidos no contexto da pesquisa. Por exemplo, com relação a população, não é viável envolver toda a população na pesquisa, pois há um elevado custo (tempo, esforço, recursos) para fazê-lo (SHULL; SINGER; SJOBERG, 2009). Portanto, deve ser escolhida uma amostra dessa população e os resultados obtidos devem ser então generalizados para todo a população, logo é preciso definir uma amostra verdadeiramente representativa.
Neste contexto, a população-alvo é o grupo de indivíduos ao qual a pesquisa se aplica, ela define o contexto do estudo e depende do objetivo da pesquisa(GROVES et al., 2009). Adicionalmente, uma amostra válida é um subconjunto representativo da população-alvo, caso contrário, não é possível generalizar os resultados (SHULL; SINGER; SJOBERG, 2009). Con-sequentemente, é importante definir os critérios de inclusão e exclusão de membros de uma população. Portanto, o uso de um método de amostragem rigoroso é fundamental para garantir a relevância dos resultados do estudo (KITCHENHAM; PFIEEGER, 2001). Vários são os métodos de amostragem, dos quais podemos listar os seguintes:
Métodos probabilísticos - Todo membro da população tem uma probabilidade não nula de ser incluído na amostra. Eles podem ser de três tipos: amostra aleatória simples, onde todos os membros têm a mesma probabilidade de serem selecionados; amostra aleatória estratifica, onde são extraídas amostras randômicas de cada grupo
3.1. FRAMEWORK METODOLÓGICO 30 (estrato) da população; amostra aleatória sistemática, a cada n membros, um é selecionado (KITCHENHAM; PFIEEGER, 2001);
Baseado em Grupos (Cluster-Based) – Termo designado à Survey envolvendo indivíduos que pertencem à grupos definidos da população. Neste contexto, processos aleatórios se baseiam no grupo e não no indivíduo. Espera-se que as respostas de indivíduos de um mesmo grupo sejam parecidas. Complementarmente, a analise dos dados tende a ser mais complexa do que no caso das amostras aleatória simples (KITCHENHAM; PFIEEGER, 2001);
Não-probabilisticos: Nestes métodos, os indivíduos são selecionados por facil-idade de acesso ou por alguma razão que leve a acreditar na representativfacil-idade deste. Adicionalmente, elas podem ser de três tipos: amostragem por conveniên-cia, onde os indivíduos estão disponíveis e dispostos; amostragem bola de neve, onde os participantes recomendam outros indivíduos; e amostragem por quota, uma versão não-probabilística da amostragem aleatória estratificada (KITCHENHAM; PFIEEGER, 2001).
Por fim, além das questões a cerca da definição da população e amostra, também deve haver preocupação com relação ao tamanho dessa amostra. Uma amostra de tamanho inadequado pode levar à resultados estatisticamente irrelevantes (GROVES et al., 2009). Se a amostra não for grande o suficiente, não é possível chegar à uma conclusão razoável, nem torna possível a generalização dos resultados (GROVES et al., 2009).
3.1.6
Análise dos dados
Em uma pesquisa bem projetada, a identificação dos procedimentos de análise de dados é feita bem antes da realização da análise em si (FREITAS et al., 2000). Antes de realizar a análise, é necessário examinar a consistência e completude das respostas, rejeitando questionários incompletos ou ainda remover da análise questões com poucas respostas (GROVES et al., 2009). Adicionalmente, também pode-se fazer necessário tratar esse dados antes da análise, por exemplo, atribuindo aos dados apenas valores numéricos, ao invés de nominais, visando simplificar a analise e aplicação de métodos estatísticos(GROVES et al., 2009). Pode-se ainda particionar as repostas em subgrupos mais homogêneos, algo que também facilita a validação dos dados(KITCHENHAM; PFIEEGER, 2001).
Por fim, diante de todo o contexto relacionado ao Survey, pode-se perceber que apesar de ser um método de pesquisa muito difundido, ele não é um método simples, há muitas considerações a serem feitas para execução desse método. Criar e validar o estudo consome muito tempo e esforço, e se cada etapa não for bem feita, não é possível generalizar os resultados obtidos ou ainda pode levar ao comprometimento da relevância do estudo.
3.2. DESIGN DA PESQUISA 31
3.2
Design da Pesquisa
Tendo como base as características de um Survey já citadas na seção anterior, será estruturado o design da pesquisa. Primeiramente quanto aos objetivos da pesquisa citados anteriormente, é preciso definir tais objetivos, como já feito na Seção 1.2, para estruturar adequadamente o método de pesquisa atendendo assim aos objetivos que pretende-se alcançar. Complementarmente, definimos a pesquisa exploratória através de um survey do tipo transversal, uma vez que pretende-se estudar uma determinada amostra da população em um momento especifico.
Posteriormente, foi elaborado o questionário a ser aplicado para coletar as informações a cerca da população relativa a indústria de software, e para verificar que ferramentas de suporte e métricas de manutenibilidade de software as empresas atualmente estão mais usando. Foi necessário também uma pesquisa na literatura a fim de investigar quais métricas e ferramentas propostas pela academia/indústria e outros trabalhos relacionados. É importante ressaltar, que esse estudo foi conduzido em parceria com outro aluno de mestrado, Samuel Carlos — discente do Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE), sobre mesmo domínio e que utilizou o mesmo método de avaliação, e tinha como objetivo avaliar métricas de manutenibilidade e sua aplicabilidade durante processo de desenvolvimento de software e ciclo de evolução. Consequentemente, as etapas iniciais relativas a elaboração e posterior aplicação do instrumento de pesquisa foram feitas conjuntamente com outro pesquisador. Esse trabalho em conjunto entre pesquisas foi possível devido a ambas visarem o mesmo tipo de população e tratarem de assuntos correlacionados (Métricas de software e Ferramentas de suporte a métricas).
A execução e coleta dos dados ocorreu por meio de um survey, e envolveu funcionários das empresas participantes do estudo responsáveis pelas decisões de métricas a serem adotadas e ferramentas utilizadas para coleta. Basicamente, a aplicação do instrumento de pesquisa ocorreu em duas etapas: uma primeira etapa para levantar os dados, e realizar uma validação inicial do estudo através de uma entrevista, sobre as ferramentas de medições utilizadas, e demais características da empresa, e uma segunda etapa com aplicação de questionário online, após validação e analise dos resultados preliminares da primeira etapa.
Neste contexto, antes da aplicação do survey na amostra final da população, foi realizado um estudo piloto, com o intuído de melhor avaliar o instrumento proposto. Neste estudo piloto, a coleta de dados foi conduzida através de uma entrevista semiestruturada aplicada em empresas de desenvolvimento de software, inicialmente do Porto Digital um parque tecnológico reconhecido nacionalmente que possui mais de 220 companhias, com mais de 1,5 bilhões de reais em faturamento anual localizado na cidade de Recife (PORTODIGITAL, 2015). A entrevista foi aplicada também em outras empresas localizadas em João Pessoa. Essa cidade possui um grupo de empresas de software que tem trazido crescimento tecnológico para a região e levantado discussões sobre a criação de um novo parque tecnológico (JOÃO PESSOA, 2015). Esta entrevista ajudou a caracterizar e coletar informação dessa população relativa ao cenário
3.2. DESIGN DA PESQUISA 32 industrial e contribuiu para posterior elaboração do questionário que seria aplicado em empresas de desenvolvimento de software de outras localidades. Na seção 3.2.1, é abordado mais detalhes a cerca do protocolo dessa entrevista.
Complementarmente, após aplicação do estudo piloto, análise e validação dos seus dados, foi elaborado um questionário online. O questionário formulado é autoadministrado, ou seja, não é necessária supervisão para que os participantes respondam às perguntas, para assim garantir maior abrangência e facilidade na aplicação do mesmo. Adicionalmente, ele é composto de questões tanto abertas e fechadas que tem como objetivo desde caracterizar o ambiente da empresa em questão, como o tempo de atuação no mercado dessas empresa, tipos de software desenvolvidos por elas e tamanho dos projetos, bem como quais são as ferramentas de suporte a métricas de manutenibilidade de software mais utilizadas nos projetos de desenvolvimento de software pela empresa em cada contexto, dentre outras, como pode ser visto em mais detalhes na seção C.
Por fim, deve-se ressaltar que é de suma importância realização da validação do ques-tionário antes de enviá-lo para os participantes. Outro ponto é relativo a motivação das pessoas para responderem ao questionário. As pessoas se motivam mais quando acreditam que os resul-tados da pesquisa lhes será útil. Tendo em vista isso, foi deixado claro, aos participantes, qual é o propósito do estudo e a importância para o contexto do trabalho que elas exercem (SHULL; SINGER; SJOBERG, 2009).
3.2.1
Entrevista
Como já mencionado anteriormente, foi realizado um estudo piloto, através da execução de um entrevista semiestruturada. Essa entrevista foi aplicada com um número reduzido de empresas em relação a amostra final, pois o intuito era apenas realizar uma validação inicial do instrumento de pesquisa proposto. Alguns dos questionamentos levantados nessa entrevista foram a cerca do perfil da empresa, dos projetos desenvolvidos, participantes, métricas e ferramentas de suporte a coleta e analise de métricas. Essa primeira etapa auxiliou na validação inicial das perguntas realizadas, da coleta de dados e avaliação da metodologia como um todo.
As entrevistas foram conduzidas entre abril e junho de 2015, em 7 empresas no nordeste brasileiro, nas cidades de João Pessoa e Recife. É importante ressaltar que esta região vem crescendo bastante com relação ao setor de tecnologia da informação (TI)(ELETRONICA, 2015; BRASIL, 2015). Adicionalmente, como já citado, os profissionais entrevistados eram diretamente relacionados com o processo de coleta de métricas na empresa. Complementarmente, antes da realização de cada entrevista, uma breve apresentação (cerca de 10-15min) era realizada com o intuito de informar previamente de forma resumida sobre o contexto da pesquisa em questão, e a importância e benefícios para os participantes do estudo. Após essa apresentação, a entrevista era de fato iniciada. Cada entrevista teve duração média entre 35-40min, e foi gravada em áudio para posterior análise. No Apêndice A pode ser conferido todo o protocolo
3.2. DESIGN DA PESQUISA 33 das entrevistas, contento informações sobre a pesquisa realizada, o roteiro de apresentação e aplicação da entrevista, bem como das perguntas realizadas.
3.2.2
Questionário Online
Após análise dos dados coletados na primeira etapa composto pelo estudo piloto, foi elaborado e posteriormente aplicado um questionário online. Em um primeiro momento, esse questionário foi aplicado com as empresas participantes da entrevista da primeira etapa como forma validado, e posteriormente ele foi aplicado envolvendo um número maior de empresas. Esse questionário foi o instrumento de pesquisa principal utilizado no Survey executado, e objetivou a coleta mais detalha de dados que auxiliassem a analisar melhor o cenário de adoção de métricas de software na indústria. A partir desse questionário pode ser inferido as respostas para questões de pesquisa previamente levantadas.
O questionário foi aplicado entre os dias 31 de agosto e 14 de dezembro de 2015, tendo como população-alvo empresas de desenvolvimento de software brasileiras. As perguntas do questionário podem ser conferidas no Apêndice C, e a sua estrutura geral é composta da seguinte forma:
1. Descrição da pesquisa, seu contexto e objetivos;
2. Perfil da empresa, seção composto por questões que objetivavam identificar o perfil das empresas participantes;
3. Questões relativas a manutenção;
4. Questões relativas a métricas de software;
5. Questões relativas a ferramentas de suporte a métricas de software.
Após a estruturação do questionário foi necessário definir o tamanho da amostra que fosse considerada satisfatória para coleta e análise dos dados. Segundo GIL (2002) é possível calcular o tamanho mínimo satisfatório de uma amostra de uma determinada população finita, através da Equação 3.1. n= σ 2p.q.N e2.(N − 1) + σ2p.q) 3.1 onde, n = Tamanho da amostra. σ2 = Nível de confiança escolhido, baseado em números de desvio-padrão p = Porcentagem na qual o fenômeno se verifica q = Porcentagem complementar (100 – p) N = Tamanho da população e2= Erro máximo permitido
De acordo com a pesquisa da ABES (2015) sobre o mercado de software brasileiro, o número total de empresas desenvolvedoras e distribuidoras de sistemas e prestadoras de serviços de TI é 12.660. Este é o conjunto universo N. Foi determinado que a porcentagem na qual o fenômeno se verifica é de 2% (ARRUDA; FILHO, 2014). Neste caso o valor de q é o
3.2. DESIGN DA PESQUISA 34 complemento de p, sendo igual a 98% (100-2). O nível de confiança adotado foi de 95,5% (dois desvios-padrão), e um erro máximo de 5,0%. A partir desses dados, podemos aplicar a equação 3.1 para calcular a amostra, resultado na Equação 3.2.
n= 2 22.98.12660 52.(12660 − 1) + 222.98)= 32 3.2 Consequentemente, para essa determinada população, uma quantidade de amostras e consequentemente de respostas válidas necessárias para que os dados possam ser considerados suficientemente satisfatórios é de 32 respostas. Considerando esse contexto, foram enviados cerca de 1450 convites para empresas distintas, tendo um retorno de 68 respostas válidas, número acima dos 32 necessários para que nesse contexto a amostra possa ser considerada significante.
3.2.3
Ameaças a Validade
Como já citado na Seção 3.2.3, há um série de considerações que precisam ser feitas em relação as possíveis ameaças a validade do questionário para poder garantir que o questionário mede o que se propõe a medir. Uma das ameaças a validade está relacionada ao viés do pesquisador, além disso é preciso garantir a coerência das perguntas evitando ambiguidade e imprecisão das mesmas, bem como avaliar se o tipo das respostas (binária, ordinal, nominal), e no caso de questões fechadas, se são adequadas as perguntas elaboradas. Para tanto foram utilizadas duas estratégias. Primeiro, após a elaboração de um questionário, o mesmo foi submetido a especialistas da área de pesquisas de engenharia de software empírica e manutenibilidade de software para uma primeira validação. Após essa primeira validação e feitos eventuais ajustes que foram necessários, o questionário ajustado foi utilizado em um teste piloto com uma amostra menor da população (um pequeno grupo de empresas) como uma segunda forma de validação. Neste teste piloto a entrevista foi uma tarefa importante pois ajudou a identificar características da população e a elaborar as perguntas que seriam adicionadas no questionário. Além disso foi realizado um levantamento de pesquisas similares já realizadas, testadas e validadas para verificar e ajudar a validar o instrumento proposto.
Adicionalmente, outra ameaça esta relacionada a validade de conclusão, ou seja, a possíveis conclusões errôneas retiradas dos resultados. Foram adotadas estratégias para mitigar essa ameaça nas duas etapas da pesquisa, tanto pra análise das entrevista como do questionário online. Na análise da primeira etapa usamos o software proprietário Nvivo (NVIVO, 2015). Este software é uma plataforma para análise de dados não estruturados, que provê uma interface para melhor acesso a grande conjunto de dados. Além disso, foram observados os conceitos sugeridos por DYBA; KITCHENHAM; JORGENSEN (2004, 2005) para análise de dados através das teorias de engenharia de software baseada em evidência. Por fim, para a segunda etapa, além dos cuidados previamente mencionados, foram utilizados métodos estatísticos como Alfa de Cronbach e correlação de Spearmana, para ajudar a verificar a integridade e consistência das respostas, bem como averiguar possíveis correlações entre elas.
3.2. DESIGN DA PESQUISA 35 Quanto à validade externa, a principal ameaça está relacionada ao tamanho da amostra utilizada neste trabalho. No entanto, com auxílio de trabalhos semelhante a está pesquisa (GROVES et al., 2009; ARRUDA; FILHO, 2014), foi possível utilizar de métodos estatísticos, como na Equação 3.1, para poder prever a necessidade quanto ao tamanho da amostra e assim estabelecer esforço para alcançar a meta necessária.
Por fim, a ameaça à validade interna relacionada aos problemas que podem surgir com os participantes do estudo, em relação a entrevistas ou respostas irrelevante que possam levar a erros sistemáticos na pesquisa sem que o pesquisa possa tomar conhecimento. Para evitar qualquer problema advindo da falta de conhecimento ou experiência dos participantes três medidas foram tomada: elaboração de carta convites, elaboração de termo de confiabilidade, e inclusão de todas informações a cerca do estudo conduzido no questionário. Primeiro, com relação as cartas convites, elas permitiam explicar previamente o contexto da pesquisa tanto no caso da entrevista Apêndice D, como no questionário online Apêndice E, ajudando assim as empresas a se organizarem e alocarem as pessoas realmente relacionadas ao assunto. Adicionalmente, quanto ao termo de confiabilidade B, também presente tanto na entrevista quanto no questionário, permitia com que os participantes ficassem mais confortáveis a responder todas as perguntas. Por fim, o próprio questionário possuía informações sobre o contexto da pesquisa, e conceitos abordados (manutenção, métricas e ferramentas), informações que os participantes precisariam para responder as perguntas caso tivessem alguma dúvida.
