INSTITUTO DE COMPUTAÇÃO
Stallin Estefferson Ferreira da Silva
Uso de requisitos não-funcionais na estimativa de
esforço de software: revisão sistemática e resultados
experimentais
CAMPINAS
2017
Uso de requisitos não-funcionais na estimativa de esforço de
software: revisão sistemática e resultados experimentais
Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Ciência da Computação.
Orientador: Prof. Dr. Mario Lúcio Côrtes
Este exemplar corresponde à versão final da Dissertação defendida por Stallin Estefferson Ferreira da Silva e orientada pelo Prof. Dr. Mario Lúcio Côrtes.
CAMPINAS
2017
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca do Instituto de Matemática, Estatística e Computação Científica Ana Regina Machado - CRB 8/5467
Silva, Stallin Estefferson Ferreira da,
Si38u SilUso de requisitos não-funcionais na estimativa de esforço de software : revisão sistemática e resultados experimentais / Stallin Estefferson Ferreira da Silva. – Campinas, SP : [s.n.], 2017.
SilOrientador: Mario Lúcio Côrtes.
SilDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de Computação.
Sil1. Software - Desenvolvimento - Estimativa. 2. Engenharia de software. 3. Engenharia de requisitos. I. Côrtes, Mario Lúcio,1950-. II. Universidade Estadual de Campinas. Instituto de Computação. III. Título.
Informações para Biblioteca Digital
Título em outro idioma: Use of non-functional requirements in software effort estimation :
systematic review and experimental results
Palavras-chave em inglês:
Software development - Estimates Software engineering
Requirements engineering
Área de concentração: Ciência da Computação Titulação: Mestre em Ciência da Computação Banca examinadora:
Mario Lúcio Côrtes [Orientador] Ariadne Maria Brito Rizzoni Carvalho Ricardo Ribeiro Gudwin
Data de defesa: 26-04-2017
Programa de Pós-Graduação: Ciência da Computação
INSTITUTO DE COMPUTAÇÃO
Stallin Estefferson Ferreira da Silva
Uso de requisitos não-funcionais na estimativa de esforço de
software: revisão sistemática e resultados experimentais
Banca Examinadora:
• Prof. Dr. Mario Lúcio Côrtes
Presidente - Instituto de Computação/Unicamp
• Profa. Dra. Ariadne Maria Brito Rizzoni Carvalho Membro interno - Instituto de Computação/Unicamp
• Prof. Dr. Ricardo Ribeiro Gudwin
Membro externo - Faculdade de Engenharia Elétrica e de Computação/Unicamp
A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.
Sem lenga lenga, vamos diretamente ao que importa:
Primeiramente agradeço enormemente o apoio de meus pais. A minha mãe Wal pelo amor incondicional e garra demonstradas diariamente. Ao meu pai Sebastião pelo incen-tivo de sempre fazer o melhor. Ah! Também agradeço a irmã Luma por cada aprendizado nesta vida de irmãos que passamos muito bem juntos.
A sensacional namorada e companheira Tiffany, por ser a responsável em ouvir todos os meus problemas diariamente e propor as melhores soluções aos desafios encontrados nesta jornada. E claro, pela paciência e apoio, afinal foram quantos finais de semana comigo trabalhando neste mestrado né linda?
Ao meu orientador Dr. Mario pela confiança, paciência e aprendizado em todas reu-niões semanais. O engajamento e parceria do senhor durante todo o trabalho deveria ser exemplo a todos.
Aos meus sócios Juliano e Gabriel, que acompanharam durante todos estes anos meus esforços em cumprir o mestrado ao mesmo tempo que assumia novas responsabilidades em nossa empresa. Obrigada pela confiança hoje e sempre.
Aos meus amigos da Unicamp, onde desde 2009 cultivo grandes amizades. Muitos deles, direta ou indiretamente fazem parte deste trabalho.
Na verdade, os agradecimentos poderiam se prolongar por muitos e muitos parágrafos, afinal todos nós somos reflexos de muitas pessoas que passaram em nossa vida, da tia da escola primária, passando pela inspetora do colégio e dos amigos da rua.
Em gerenciamento de projetos computacionais, uma etapa bastante complicada e impor-tante é a estimativa de esforço a partir dos requisitos do projeto de software. Diversos métodos de estimativa de esforço foram propostos nas últimas décadas, todos com o ob-jetivo de prever o esforço e custo do projeto com baixas taxas de erro.
No entanto, muitos dos métodos algorítmicos de estimativa de esforço propostos ig-noram os requisitos não-funcionais na modelagem de suas variáveis de entrada, outros métodos somente os utilizam parcialmente.
O objetivo deste trabalho é entender o uso dos requisitos não-funcionais nos métodos de estimativa de esforço e a correlação da utilização deles ou não com a precisão do método. Uma revisão sistemática foi conduzida para verificar quais requisitos não-funcionais são usados, como eles são usados e quais seus efeitos sobre o erro da estimativa.
A revisão sistemática mostrou que apenas 33% dos 39 métodos algorítmicos usam requisitos não-funcionais, por sua vez, a correlação entre a precisão da estimativa com o uso deles foi inconclusiva. Para compreender tal correção, um experimento foi realizado em datasets disponíveis publicamente na literatura. Este experimento mostrou que o uso de requisitos não-funcionais resulta em uma redução de aproximadamente 30% no erro da estimativa do software, com garantia estatística.
Software cost estimation is a critical step in software project management, and its main driver are requirements. Some algorithmic methods use as inputs only functional require-ments and others take also into account non-functional requirerequire-ments.
The goal of this study is to understand the correlation of using non-functional require-ments on the accuracy of software cost estimation algorithmic methods. A systematic literature review was conducted to learn which non-functional requirements are used, how they are used, and their effects on estimation accuracy.
The systematic review shows that only 33% of 39 algorithmic methods use non-functional requirements. However, the investigation on its correlation with estimation accuracy was not conclusive from published results. In order to address this issue, an ex-periment was conducted on publicly available datasets. This exex-periment shows that the use of non-functional requirements results in a reduction of about 30% in the estimation error, with statistically significant confidence.
2.1 Ilustração do fluxo de estimativa de esforço de um software . . . 18
2.2 Entradas e saídas do método algorítmico SEER-SEM (adaptado de [50]). . 19
2.3 Ilustração do fluxo realizado no método Delphi (adaptado de [1]). . . 21
2.4 Classificação de requisitos não funcionais, segundo Sommerville 2004. . . . 23
2.5 ISO/IEC 25010 - Características de qualidade . . . 24
3.1 Número de ocorrências de publicações versus repetições . . . 50
3.2 Processo de filtragem das publicações identificadas . . . 51
3.3 Resumo dos resultados da revisão sistemática . . . 52
4.1 Gráfico cumulativo Kolmogorov - Pr(same): probabilidade das duas distri-buições serem a mesma . . . 61
2.1 Valores para “a” e “b” de acordo com o tipo do projeto de software. . . 20
3.1 Design de nossa Revisão Sistemática versus guia de Kitchenham e Charters 35 3.2 Aspectos da revisão sistemática para criação das questões de pesquisa (PI-COC). . . 37
3.3 Protocolo da revisão sistemática realizada. . . 38
3.4 Trabalhos analisados inicialmente na revisão sistemática (“fontes de refe-rência”). . . 40
3.5 Amostra dos métodos identificados na análise das “fontes de referência”. . . 41
3.6 Frequência de palavras no título das publicações de referência. . . 42
3.7 Revistas científicas mais importantes em estimativa de esforço de software. 44 3.8 Amostra de dados da execução final do string de busca nos bancos de publicações. . . 46
3.9 Amostra das “publicações de referência” encontrados na execução em cada banco. . . 47
3.10 Métodos algorítmicos que não usam RNFs como entrada . . . 53
4.1 Amostra dos dados do Promise COCOMO81 . . . 57
4.2 Amostra de planilha gerada para cálculo da estimativa e do erro utilizando RNFs. . . 60
4.3 Experimento - Intermediate COCOMO com Promise COCOMO81 . . . 61
C.1 Métodos identificados na análise das “fontes de referência- Parte 1 . . . 80
C.2 Métodos identificados na análise das “fontes de referência- Parte 2 . . . 81
C.3 Execução primária da string de busca nos bancos de publicações - Parte 1. 82 C.4 Execução primária da string de busca nos bancos de publicações - Parte 2 . 83 C.5 Execução final da string de busca nos bancos de publicações - Parte 1 . . . 84
C.6 Execução final da string de busca nos bancos de publicações - Parte 2 . . . 85
C.7 “Publicações de referência” versus resultados da busca nos bancos . . . 88
C.8 Palavras utilizadas na blacklist durante a filtragem das publicações obtidas 89 C.9 Métodos para os quais não foram encontrados os PDFs - Parte 1 . . . 90
1 Introdução 12
1.1 Motivação . . . 12
1.2 Objetivos . . . 13
1.3 Organização da dissertação . . . 13
2 Conceitos Básicos e Trabalhos Relacionados 15 2.1 Estimativa de custo e esforço . . . 15
2.1.1 Estimativa de tamanho de projeto . . . 16
2.1.2 Métodos de estimativa de esforço . . . 16
2.2 Requisitos e sua relação com estimativa de esforço . . . 22
2.2.1 Requisitos funcionais e não-funcionais . . . 22
2.2.2 Os requisitos não-funcionais na estimativa de esforço . . . 25
2.3 Métodos experimentais em Engenharia de Software . . . 26
2.3.1 Métodos experimentais . . . 26
2.3.2 Revisão sistemática . . . 28
2.4 Outros trabalhos relacionados . . . 32
2.5 Considerações finais . . . 33
3 Revisão Sistemática 34 3.1 Design . . . 34
3.2 Planejamento . . . 35
3.2.1 Identificação da necessidade de uma revisão sistemática . . . 36
3.2.2 Método PICOC . . . 36
3.2.3 Protocolo da revisão sistemática . . . 37
3.3 Execução do trabalho experimental . . . 39
3.3.1 Identificação das publicações . . . 39
3.3.2 Extração . . . 48
3.4 Análise . . . 51
3.5 Publicação . . . 54
3.6 Considerações finais . . . 54
4 Experimento complementar 55 4.1 Planejamento e seleção de alternativas . . . 55
4.1.1 Metodologia experimental . . . 55
4.1.2 Seleção da fonte de dados . . . 56
4.1.3 Seleção do método de estimativa . . . 57
4.1.4 Metodologia de análise dos resultados . . . 58
4.2 Execução . . . 59
Referências Bibliográficas 65
A Unidades de medida de tamanho de software 75
A.1 Linhas de código-fonte - source lines of code . . . . 75
A.2 Equação de Halstead . . . 76
A.3 Pontos de função e suas derivações . . . 76
A.3.1 Pontos de função - function points . . . . 76
A.3.2 Pontos por objeto - object points . . . . 77
A.3.3 Pontos de caso de uso - use case points . . . . 77
A.3.4 Story points . . . . 77
B Intermediate COCOMO 78 C Revisão Sistemática 79 C.1 Identificação das publicações . . . 79
C.2 Execução nos Bancos de Publicação . . . 81
C.3 Validação dos resultados da revisão sistemática . . . 87
Introdução
O planejamento do projeto é uma das mais importantes atividades em projetos de soft-ware [80]. Um planejamento inadequado provavelmente implicará em falhas no projeto e em resultados insatisfatórios. Caso o custo e o esforço em projetos de software sejam determinados de maneira pessimista (ou seja, adicionando uma porcentagem razoável ao valor estimado), algumas oportunidades de realização de projetos convenientes para a empresa podem ser perdidas; enquanto que estimativas otimistas podem levar a prejuízos do empresário [80].
Dessa maneira, a estimativa de esforço ou custo de um projeto é um passo importante e essencial no planejamento de um projeto, pois afeta significativamente a competitivi-dade da empresa. Além disso, estimativas mais precisas ajudarão no controle de custos da empresa durante o projeto, irão gerar uma satisfação maior ao cliente (pois o software será entregue dentro do prazo, sem redução de seu escopo) e auxiliarão no dimensiona-mento mais adequado da equipe (melhorando também a satisfação dos colaboradores da empresa).
No entanto, estimar o esforço de um projeto computacional não é simples como apa-renta ser. Diferentes fatores conhecidos e desconhecidos influenciam o processo de esti-mativa, como por exemplo, a imprecisão e contínua mudança dos requisitos do sistema, a experiência do time de desenvolvimento e a linguagem de programação utilizada [18].
Nas últimas décadas, diversos pesquisadores propuseram métodos e abordagens dife-rentes para estimar o esforço, objetivando atingir baixas taxas de erro na estimativa. Nos últimos anos, pesquisas foram realizados com o objetivo de classificar e entender a vasta literatura de métodos de estimativa de esforço, como são os casos dos trabalhos [18], [35], [73], [80] e [91].
1.1
Motivação
Existem inúmeros métodos de estimativa de esforço disponíveis na literatura [73]. Os métodos de estimativa de esforço algorítmicos (ou também chamados de métodos para-métricos), são responsáveis por gerar uma estimativa de esforço através de uma ou mais equações matemáticas modeladas sob as variáveis de entrada para o método [18]. Tais va-riáveis de entrada e equações mudam de um método para o outro; no entanto é importante
que as entradas sejam suficientes para representar todo o projeto computacional.
A precisão da estimativa de esforço influencia diretamente no sucesso do projeto [19], por isso é desejável que todos os requisitos do sistema e fatores externos sejam cobertos pelo método de estimativa idealizado. Os requisitos não-funcionais são os responsáveis por garantir como as funções do software desejadas pelo cliente serão desenvolvidas. No entanto, muitos métodos de estimativa de esforço tendem a ignorar os impactos dos di-ferentes requisitos não-funcionais ou de qualidade [125]. Por sua vez, outros métodos incluem os requisitos não-funcionais parcialmente, requerendo análise subjetiva de espe-cialistas na área [38].
Dessa forma, é desejável entender o atual cenário de uso dos requisitos não-funcionais como entrada nos métodos algorítmicos de estimativa de esforço. Assim, a partir do es-tado da arte encontrado, será possível delinear novas direções para a área de estimativa de esforço. Tal estudo também é importante para compreender a importância da relação direta entre a precisão do método e a boa utilização de requisitos não-funcionais como entrada, ressaltando assim o impacto dos requisitos não-funcionais para a estimativa re-alizada. Apesar da importância dos requisitos não-funcionais na estimativa de esforço de software ser amplamente aceita, não foi encontrada uma pesquisa na literatura estudando especificamente esta questão.
1.2
Objetivos
O objetivo desta dissertação de mestrado é entender o atual uso e a importância dos requisitos não-funcionais para a estimativa de esforço de um projeto computacional. Dessa forma, podemos separá-lo em dois objetivos distintos, conforme segue:
• OBJ-1 Entender como os métodos algorítmicos de estimativa de esforço existentes tratam os requisitos não-funcionais;
• OBJ-2 Entender a relação do uso de requisitos não-funcionais com a precisão dos métodos algorítmicos de esforço.
O objetivo OBJ-1 será alcançado realizando uma revisão sistemática da literatura de métodos algorítmicos de estimativa de esforço. Dessa maneira, será possível classificar a literatura atual quanto ao uso ou não de requisitos não-funcionais, além de quais requisitos não-funcionais são mais levados em consideração nos métodos de estimativa atuais.
Para ser cumprido o objetivo OBJ-2, por sua vez, serão analisados também os resul-tados da revisão sistemática. Além disso, será realizado um estudo experimental visando complementar a afirmação de que os requisitos não-funcionais afetam a estimativa de esforço de software. Dessa forma, será possível entender a relação do uso de requisitos não-funcionais com a precisão do método (OBJ-2).
1.3
Organização da dissertação
Esta dissertação de mestrado está estruturada conforme segue. O Capítulo 2 apresenta os conceitos básicos disponíveis na literatura, importantes para a realização dos trabalhos
experimentais. Os Trabalhos relacionados são apresentados na Seção 2.4 no final do Capítulo 2. O Capítulo 3 apresenta todo o Planejamento e detalhes da Execução da Revisão sistemática realizada. O Capítulo 4 mostra todos os detalhes do Experimento complementar executado. As Conclusões deste trabalho são apresentadas no Capítulo 5. Por fim, os Apêndices apresentam detalhes adicionais sobre a realização da revisão sistemática e do trabalho experimental.
Conceitos Básicos e Trabalhos
Relacionados
Esta seção apresenta a fundamentação teórica encontrada na literatura sobre o tema proposto, servindo assim como embasamento para as outras seções desta dissertação. A Seção 2.1 aborda o conceito de esforço, unidade de medida e classificação de métodos de estimativa de esforço. Já a Seção 2.2 trabalha sob a relação e importância dos requisitos não-funcionais na estimativa de esforço, descrevendo melhor as taxonomias de requisitos não-funcionais existentes. Por sua vez, a Seção 2.3 explica sucintamente os principais métodos de pesquisa existentes em Engenharia de Software, incluindo o quase-experimento e também mais a fundo quais são os principais passos para realização de uma revisão sistemática robusta. Por fim, a Seção 2.4 apresenta os trabalhos publicados com temas relacionados a esta dissertação.
2.1
Estimativa de custo e esforço
O esforço é a medida de quantas unidades de trabalho serão gastas para completar uma determinada tarefa ou atividade, tal como desenvolver um projeto computacional. As unidades podem ser por exemplo, pessoas x dia ou pessoas x hora. O custo refere-se a quanto será gasto, em termos de recursos financeiros, para produzir determinado software [125]. Muitos métodos de estimativa geram o esforço, o qual pode ser convertido em duração do projeto e custo via nivelamento de recursos. Em projetos de software, o custo referente a recursos humanos costuma ser a parte dominante do custo, e está associado ao esforço total do projeto e a distribuição de custo unitário da mão de obra. Apesar de esforço e custo estarem muito relacionados, eles não estão necessariamente relacionados por uma simples função de transformação [91]. Neste trabalho iremos nos ater e analisar o esforço gerado pelo método de estimativa estudado, e não ao custo de desenvolvimento total do projeto.
Diferentes atributos devem ser considerados para estimar o esforço de um software. Um dos mais importantes atributos de entrada é o tamanho do projeto. A estimativa de esforço do software depende da precisão com que foi estimado o tamanho do software. Normalmente, é complicado estimar o esforço de um projeto computacional. Além disso,
os requisitos de um sistema mudam continuamente, o que pode gerar mudanças nas es-timativas [80]. Uma boa estimativa de esforço possibilita organizar melhor atividades do projeto, como planejamento e alocação de equipe, além de evitar prejuízos da empresa [18]. As próximas subseções resumem as técnicas mais utilizadas para estimar o tamanho de um projeto e a classificação dos métodos de estimativa de esforço existentes.
2.1.1
Estimativa de tamanho de projeto
Existe um grande número de pesquisas já realizadas com o objetivo de identificar unidades de medida, as quais podem prover uma boa maneira de se lidar com o tamanho do software estimado [62]. Unidades de medida quantitativas são importantes em todos os campos da ciência; em particular, em Ciência da Computação as unidades de medida de tamanho de software são uma forma de conduzir estimativas quantificáveis. As unidades de medida de tamanho de software utilizadas corretamente podem fazer com que o processo de estimativa de esforço seja muito mais fácil e confiável [18]. Além disso, pesquisadores apontam que as unidades de medida de tamanho de software podem também ser utilizadas para mensurar produtividade e qualidade do software, durante ou após o processo de desenvolvimento do software [99].
Uma unidade de medida de tamanho de software pode ser baseada em três caracterís-ticas do software: tamanho, complexidade e funcionalidade [125]. Um número grande de unidades de medida de tamanho de software foram propostas até então; as mais utiliza-das e conheciutiliza-das na literatura são: linhas de código fonte (ou SLOC), pontos de função, equação de Halstead, pontos por feature, pontos por objeto, pontos por caso de uso e story points. Essas unidades de medida de tamanho são descritas com mais detalhe no Apêndice A.
2.1.2
Métodos de estimativa de esforço
Diferentes métodos de estimativa de esforço foram propostos nos últimos 30 anos; alguns deles sobreviveram devido a sua eficácia (baixa taxa de erro), e outros são limitados a um escopo específico [18]. Estes métodos podem ser classificados de muitas maneiras diferentes, baseado em sua abordagem, categoria e técnica empregada. A estimativa de esforço de um método de estimativa é obtida através da análise dos requisitos do sistema. Leung et al. [91] propuseram dividir os métodos existentes de estimativa de esforço em dois: algorítmicos e não-algorítmicos. Magne Jorgensen e Barry Boehm, dois ícones na área de estimativa de software, defendem a combinação de métodos algorítmicos e não-algorítmicos - em especial o COCOMO-II [37] e o discernimento de especialista (expert judgment) - com o objetivo de obter melhores estimativas do esforço real do projeto de software [72].
[31] [135]
Uma das principais maneiras de avaliar a eficácia de um método de estimativa de software é calculando sua precisão ou erro. Há diversas maneiras de calcular o erro como, por exemplo: Symmetric measures [104], Weighted Mean of Quartiles of relative errors (WMQ) [93] e Mean Variation from Estimate (MVFE) [58]. No entanto, a maneira
mais comum de medir a precisão é o MRE (do inglês, Magnitude Relative Error ou em português, Erro Relativo em Magnitude), definido pela Equação 2.1. Na equação o valor do esforço “realizado” é aquele que realmente aconteceu durante o projeto e o estimado é o resultado calculado pelo método de estimativa [80].
M RE = krealizado − estimadok realizado
!
(2.1)
Uma vantagem de medir o erro usando a abordagem MRE é o fato de ele capturar tanto variações positivas quanto negativas, transformando tais estimativas (a mais ou a menos) em números comparáveis. Por sua vez, MMRE (do inglês, Mean Magnitude Relative Error ou em português, Média do Erro Relativo em Magnitude) é a média obtida a partir de estimativas de MRE em vários projetos [80].
2.1.2.1 Métodos algorítmicos
Os métodos algorítmicos, também conhecidos por métodos paramétricos, geram estima-tivas de esforço através de um modelo matemático usando as variáveis de entrada consi-deradas mais importantes para o esforço [18]. Estes métodos geram a estimativa baseada principalmente no tamanho do software e em outros fatores conhecidos derivados dos requisitos do projeto [18].
Vale observar que o tamanho do software também é uma estimativa e, portanto, pode ter incertezas [125]. Além do tamanho, o esforço de um projeto computacional é uma função dos seguintes fatores: detalhes do produto (complexidade, funcionalidade, etc), fatores técnicos (linguagem de programação, ferramentas, etc), fatores de produtividade (experiência, tamanho da equipe, etc) e fatores de projeto (prazo, orçamento, cronograma, etc).
Quantificar os fatores mencionados é muito complicado e alguns deles acabam sendo ignorados na estimativa de esforço do projeto [80]. Estudos sugerem que os métodos algorítmicos sejam periodicamente recalibrados baseado em uma análise estatística de dados históricos [18].
A Figura 2.1 foi elaborada durante esta dissertação para ilustrar o processo completo de estimativa de esforço de software, derivando inclusive o custo estimado do software. Na Figura, inicialmente temos apenas os requisitos do cliente; a partir dos requisitos são geradas modelagens que representam tais requisitos e com estas modelagens é possível estimar o tamanho do software. Seguindo o fluxograma da Figura, obtendo o tamanho do software, outros requisitos do sistema e variáveis do ambiente do desenvolvimento (como arquitetura selecionada) derivamos o esforço. Com o esforço então é possível, a partir da equipe disponível para desenvolver o projeto e a negociação com o cliente, finalmente obter a estimativa do custo do software (em unidades monetárias).
Figura 2.1: Ilustração do fluxo de estimativa de esforço de um software
Alguns dos métodos algorítmicos mais populares são o SEER-SEM [50], COCOMO [38], COCOMO-II [37], Putnam [121] e o Boeing Model [51]. Nesta Seção descrevemos com mais detalhes o SEER-SEM e o COCOMO (e suas variações), conforme segue.
O SEER-SEM (ou SEER for Software) está esquematizado na Figura 2.2 [50], ilus-trando como se comporta um típico método algorítmico e resumindo as categorias de atributos aceitos como entrada e os gerados como saída do método SEER-SEM. As equa-ções de modelagem desse método são privadas, no entanto a abrangência deste método é grande, cobrindo projetos em diversos estágios desde a especificação inicial, passando pelo design, desenvolvimento, entrega e manutenção. Na Figura 2.2 a variável de entrada tamanho, é derivada também dos requisitos do sistema (conforme visto na Figura 2.1).
Figura 2.2: Entradas e saídas do método algorítmico SEER-SEM (adaptado de [50]).
2.1.2.2 COCOMO e o Intermediate COCOMO
O Constructive Cost Model (COCOMO) tem diversos versões do método de estimativa, como: básica, intermediate, detalhada [38] e a versão 2 [37]. O Intermediate COCOMO, por exemplo, calcula o esforço do desenvolvimento do software em função do tamanho do software e de um conjunto de drivers de custo que incluem análise subjetiva do projeto, hardware, equipe e atributos do projeto. O Intermediate COCOMO é uma extensão do Basic COCOMO.
Existem 4 conjuntos de drivers de custo no método Intermediate COCOMO: atributos de produto, de hardware, equipe e projeto. Cada atributo tem os seguintes sub-atributos referentes à aplicação (no parênteses apresenta-se o nome do sub-atributo em inglês):
• Atributos de produto: confiabilidade do software (required software reliability), ta-manho do banco de dados (size of application database) e complexidade do produto (complexity of the product).
• Atributos de hardware: restrições de desempenho (run-time performance cons-traints), restrições de memória (memory conscons-traints), volatilidade do ambiente da máquina virtual (volatility of the virtual machine environment) e tempo de resposta esperado (required turnaround time).
• Atributos de equipe: capacidade do analista (analyst capability), capacidade dos engenheiros de software (software engineering capability), experiência nas aplicações (applications experience), aplicação em máquina virtual (virtual machine experience) e experiência na linguagem de programação (programming language experience).
• Atributos de projeto: uso de ferramentas de software (use of software tools), apli-cação de métodos de engenharia de software (application of software engineering
methods), restrições do cronograma de desenvolvimento (required development sche-dule).
Cada um dos 15 atributos recebe uma nota que varia em 6 intensidades de importância ou valor de “muito baixo” até “muito alto”. Estes atributos são transformados em um número de acordo com a definição do método, por exemplo para o sub-atributo “tamanho do banco de dados” que seja grande, o valor atribuído a ele no método será 1.08 (a tabela completa mostrando todas as transformações possíveis está no Apêndice B.1). Por fim, o produto de todos estes números gera o EAF (fator de ajuste de esforço). Os valores típicos do EAF variam de 0.9 até 1.4.
Desta forma, a fórmula do Intermediate COCOMO (Equação 2.2) é
E = a ∗ (KSLOCb) ∗ EAF (2.2)
onde E é o esforço em pessoas x mês para aquele projeto, KSLOC é a estimativa de tamanho de projeto em milhares de linhas de código e EAF é o fator de ajuste calculado anteriormente. Finalmente o coeficiente “a” e o expoente “b” são apresentados pela Tabela 2.1, os quais variam de acordo com o tipo do projeto de software (primeira coluna). Usando a terminologia do COCOMO os tipos de projeto: orgânico - são projetos relativamente pequenos e simples nos quais times pequenos com boa experiência na aplicação trabalham cumprindo requisitos pouco rígidos; semi-destacado (semi detached) - intermediários (em tamanho e complexidade) são projetos de software nos quais os times com diferentes níveis de experiência devem cumprir requisitos rígidos ou não; incorporado (embedded) - um projeto de software que deve ser desenvolvido sob requisitos rígidos (não podem ser violados), por exemplo um software de controle de tráfego aéreo.
Tabela 2.1: Valores para “a” e “b” de acordo com o tipo do projeto de software. Tipo do projeto de software a b
Orgânico 3.2 1.05
Semi destacado (semi detached) 3.0 1.12 Incorporado (embedded) 2.8 1.2
2.1.2.3 Métodos não-algorítmicos
Os métodos não-algorítmicos são baseados na comparação analítica e inferência. Para usar métodos não-algorítmicos, alguma informação sobre projetos passados é necessária. O processo de estimativa destes métodos é realizado analisando os conjuntos de dados de projetos passados [80]. As abordagens de métodos não-algorítmicos mais utilizadas atualmente são por analogia ou discernimento de especialista (expert judgment).
Um exemplo da abordagem discernimento de especialista é a técnica Delphi, ilustrada na Figura 2.3 [1]. Nessa Figura o processo começa com uma questão que é respondida por especialistas de maneira a ser reformulada. Após isso, esta pergunta será avaliada pelos especialistas iterativamente até chegar a uma síntese da resposta à questão. Note que a experiência dos especialistas é a chave para obtenção da resposta à questão; no nosso caso a questão é a estimativa de esforço do software [44].
Figura 2.3: Ilustração do fluxo realizado no método Delphi (adaptado de [1]).
Os métodos de estimativa que utilizam aprendizado de máquina também são consi-derados não-algorítmicos [18]. Atualmente houve uma explosão na literatura de novos métodos que utilizam a técnica de aprendizado de máquina. Esta abordagem explora as informações estatísticas do conjunto de dados, relacionando-os com as entradas do pro-jeto a ser estimado, podendo inclusive aumentar a precisão dos resultados [80]. Muitos destes métodos utilizam redes neurais e lógica fuzzy para obter a estimativa de esforço do software [18]. Regressões lineares também são bastante utilizadas para se obter o valor da estimativa de esforço [35].
2.2
Requisitos e sua relação com estimativa de
es-forço
De acordo com Sommerville, os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restrições sobre sua operação ou implementação [132]. Em Engenharia de Software é comum fazer uma distinção entre requisitos de uma funciona-lidade do software (requisitos funcionais) e requisitos não-funcionais [61].
Existem diversos estudos que relatam a relação entre os requisitos não-funcionais e a estimativa de esforço. A próxima Seção 2.2.1 define o conceito de requisito funcional e não-funcional; já a Seção 2.2.2 discute os estudos existentes sobre a relação dos requisitos não-funcionais na estimativa de esforço, acentuando a importância do tema na área de Gerenciamento de Projetos de software.
2.2.1
Requisitos funcionais e não-funcionais
Há uma certa convergência nas definições encontradas na literatura sobre o termo requisito funcional [54]. Seguem alguns exemplos:
• IEEE 610: “uma função que um sistema (...) deve ser capaz de realizar” [60];
• Robertson 1999: “o que produto deve fazer” [124];
• Sommerville 2004: “o que o sistema deveria fazer” [132];
• Anton 1997: “descrevem os aspectos comportamentais do sistema” [28];
• Davis 1993: “aqueles requisitos que especificam entradas de um sistema e as re-lações de comportamento entre elas; também chamados de requisitos funcionais ou operacionais” [46].
Já o termo requisito não-funcional (RNF), apesar de ser utilizado há mais de duas décadas, ainda não tem uma definição consensual e mesmo uma forma consagrada de documentá-lo no projeto. Glinz et al. [54] reuniu diversas definições sobre requisito não-funcional (apresentadas no próximo parágrafo) e concluiu que as diferenças não são somente na terminologia utilizada, mas há também diferença nos conceitos utilizados para defini-lo. Os próprios termos utilizados nas definições encontradas no trabalho de Glinz et al. [54] (como propriedade, característica, atributo, qualidade, constante e desempenho) carecem de um consenso do que estes termos denotam no contexto da definição.
Muitas organizações internacionais ainda não convergiram para um definição oficial de requisito não-funcional. Por exemplo, no relatório técnico IEEE 830-1998 [61], apesar de ser dada a lista de requisitos não-funcionais (por exemplo: interfaces externas, desem-penho, atributos como portabilidade, segurança, etc), o termo em questão não é definido explicitamente. Wiegers [138] no seu livro de 2003 define requisito não-funcional como sendo “a descrição de uma propriedade ou característica que um sistema deve exibir ou uma constante que ele deve respeitar, diferente de um comportamento do sistema obser-vável”. Outros autores preferem listar os requisitos não-funcionais, como é o caso de Davis
et al. [46] que trata o termo como “os atributos globais requeridos pelo sistema, incluindo portabilidade, confiabilidade, eficiência, testabilidade, compreensibilidade e modificabili-dade”.
Existem diversas taxonomias de requisitos não-funcionais na literatura como, por exemplo:
• IEEE 1990: 610 - Standard Glossary of Software Engineering Terminology;
• Davis 1993: Software Requirements: Objects, Functions and States;
• IEEE 1998: 830 - Recommended Practice for Software Requirements Specificati-ons;
• Wiegers 2003: Software Requirements, 2nd edition;
• Sommerville 2004: Software Engineering Seventh Edition;
• Pressman 2007: Software Engineering: A Practitioner’s Approach;
• ISO/IEC 2010: 25010 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models.
Na taxonomia criada por Sommerville, em seu livro intitulado Software Engineering: A Practitioner’s Approach [132], os requisitos não-funcionais são divididos em requisitos de produto, requisitos de processo e requisitos externos como ilustrado na Figura 2.4. Os requisitos não-funcionais de produto especificam o comportamento do produto (como por exemplo: eficiência, confiabilidade e portabilidade); já os requisitos de processo são decor-rentes de políticas e procedimentos da corporação (como padrões e infraestrutura); por fim os requisitos externos são derivados de outros fatores do sistema e do desenvolvimento (como interoperabilidade, legislação e ética). Na Figura 2.4 os requisitos não-funcionais são listados, evidenciando a amplitude da taxonomia proposta por Sommerville.
Já a proposta da IEEE no padrão 830 de 1998 [61] define as categorias de funcio-nalidade, interfaces externas, desempenho, atributos (portabilidade, segurança e etc), e constantes de design. Os requisitos de projeto, tais como schedule, custo ou requisitos de desenvolvimento são explicitamente excluídos. Os requisitos não-funcionais específicos definidos no padrão são requisitos de: desempenho, interface, operacionais, recursos, ve-rificação, aceitação, documentação, segurança, portabilidade, qualidade, confiabilidade e manutentabilidade.
Por fim, o modelo de requisito não funcional definido pela ISO/IEC 25010 é dividido em 8 características de qualidade, conforme apresentado na Figura 2.5. Nessa Figura, a “functional suitability” representa o grau que um produto ou sistema deve cumprir sobre condições específicas e pode ser considerado um requisito funcional. Por outro lado, as outras sete características podem ser usadas para categorizar requisitos não-funcionais encontrados em projetos de software. Estas características de qualidade podem ser mapeadas em requisitos não funcionais [135].
A taxonomia definida pela ISO/IEC 25010 foi escolhida para ser usada neste trabalho para mapear os requisitos não-funcionais estudados nos métodos de estimativa de software, pois é recente e faz parte de uma norma muito utilizada.
Há ainda diversas outras abordagens para classificar os requisitos não-funcionais, as quais podem ser encontradas em [54] e [42]; outros esquemas inclusive são limitados a domínios específicos, como é o caso do [52] que criou uma taxonomia de requisitos não-funcionais para sistemas orientados a serviço.
Uma outra parte importante dentro da engenharia de requisitos não-funcionais é a verificação da completude dos requisitos não-funcionais no software já desenvolvido. Co-brindo esta temática existe o NFR Framework [109] [110], o qual desprende o conceito de funcionalidade de outros atributos de qualidade e conceitos para produtividade, custo e tempo, através de uma abstração de alto nível. Em vez de focar na expressão de re-quisitos em termos de funções detalhadas, constantes e atributos, o NFR Framework concebe a distinção dos requisitos não-funcionais usando o conceito de goal (seu requi-sito não-funcional) e softgoal (objetivo que ainda não tem um critério definido se ele foi cumprido ou não). Existem outras abordagens com o objetivo de modelar os requisitos não-funcionais e verificar se são cumpridos, algumas inclusive para domínios específicos, como em [130] - onde o objetivo é quantificar os requisitos - e em [75], no qual é trabalhada a melhoria do conceito de softgoal tornando a análise mais expressiva.
2.2.2
Os requisitos não-funcionais na estimativa de esforço
O sucesso de um projeto de software depende de muitos fatores, inclusive da precisão da estimativa de esforço [19]. Conforme exposto anteriormente, inúmeros trabalhos foram desenvolvidos nesta área nos últimos anos. Além da unidade de medida e do método escolhido, existem outros fatores que afetam a estimativa, como: fatores do ambiente, fatores técnicos e constantes de operação [99]. Alguns estudos foram realizados com o objetivo de identificar um conjunto de requisitos não-funcionais que afetam a relação entre esforço e tamanho do projeto [19]. Muitos métodos de estimativa de esforço tendem a ignorar os impactos dos diferentes requisitos não-funcionais [125]. Já outros métodos incluem os requisitos não-funcionais parcialmente, requerendo análise subjetiva de experts na área [38]. Um aumento do erro gerado pelos métodos de estimativa de esforço pode ser introduzido se ocorrer uma avaliação errônea dos requisitos não-funcionais na análise subjetiva dos especialistas [19].
No trabalho realizado por Angelis et al. [27] foram gerados métodos de estimativa de esforço a partir da conversão de valores categóricos em numéricos usando regressão esta-tística. Com isso, foi determinado que há diferentes fatores e características de ambiente - como o tipo do desenvolvimento, tipo da linguagem de programação e plataforma de desenvolvimento - que afetam a relação entre o esforço e o tamanho do projeto determi-nado [27]. Todo este trabalho foi realizado usando a base de dados do ISBSG (do inglês, International Software Benchmarking Standards Group [7]).
O trabalho realizado por Nassif et al. [111] em 2012 analisou a importância dos requi-sitos não-funcionais em um conjunto pré-determinado de projetos (o conjunto Desharnais, com 8 projetos de software). A análise teve o objetivo de estudar a influência de cada
um dos requisitos não-funcionais (ou de qualidade) no resultado da estimativa de esforço gerada usando modelos de regressão e de redes neurais. As taxas de erro geradas levaram a concluir que o atributo “Linguagem de Programação” é o mais significante ao calcular o esforço de software. Além disso, se todos os requisitos não-funcionais fossem eliminados da entrada, o valor do erro resultado seria o dobro.
A entrada de muitos métodos de estimativa de esforço são valores de categorias tais como: muito baixo, baixo, normal e alto. Estes valores apresentam um certo problema para serem determinados devido a sua subjetividade [125]. Idris et al. [59] tentaram resolver este problema usando analogia fuzzy. Esse estudo se mostrou mais preciso que outras abordagens de avaliação, por exemplo, o COCOMO-II [37] [19].
Para que seja possível compreender a relação dos requisitos não-funcionais na esti-mativa de esforço com a precisão do método, a próxima Seção apresenta os principais métodos experimentais utilizados em Engenharia de Software, além de descrever a fundo como deve ser concebida uma revisão sistemática.
2.3
Métodos experimentais em Engenharia de
Soft-ware
Esta Seção descreve os métodos experimentais (empíricos) que serão utilizados nesta dis-sertação, o quase-experimento e a revisão sistemática. A apresentação de outros métodos experimentais tem o objetivo de melhor contextualizar a escolha desses dois métodos experimentais.
Existem diversos métodos disponíveis para pesquisa em Engenharia de Software, para enumerar os principais: experimento controlado [119], estudo de caso [127], survey [83], etnografia [84], análise de arquivo/artefato [105], action research [90], simulação [78], benchmark [131] e revisão sistemática [81].
Há dois tipos de paradigmas de pesquisa que tem duas diferentes abordagens para estudos empíricos, a pesquisa exploratória e a explanatória. A pesquisa exploratória é concebida para estudar objetos em suas configurações normais e os resultados emergem observando-os. Isso implica que um design de pesquisa flexível é necessário para adaptar as mudanças observadas no fenômeno. Em geral, designs de pesquisa flexíveis como a pesquisa exploratória também são referenciados como pesquisa qualitativas.
Já a pesquisa explanatória é principalmente concebida para quantificar a relação ou comparar dois ou mais grupos com o objetivo de identificar a relação de causa e efeito entre eles (esta pesquisa é normalmente conduzida através de um experimento controlado). Este tipo de estudo necessita de um design rígido, fixando os fatores da pesquisa antes do estudo ser lançado. Designs de pesquisa rígidos como a pesquisa explanatória muitas vezes são também referenciados como pesquisa quantitativa.
2.3.1
Métodos experimentais
Dependendo da proposta de avaliação e dependendo das condições da investigação empí-rica, há três principais tipos de estratégias empíricas, conforme descritas resumidamente
a seguir: survey, estudo de caso e experimento.
Um survey é um processo para coletar informações de/ou sobre pessoas para descre-ver, comparar ou explicar aquele conhecimento, postura ou comportamento. Um survey é normalmente uma investigação realizada onde a questão de pesquisa, ferramenta ou téc-nica tem sido usada por pouco tempo. As principais formas de obter dados qualitativos ou quantitativos são através de entrevistas e questionários, os quais são feitos muitas vezes selecionando uma amostra representativa da população de estudo. Os resultados então são analisados com conclusões explanatórias.
Já o estudo de caso em engenharia de software é realizado para entender um fenô-meno contemporâneo pouco estudado ainda (especialmente quando os limites entre o fenômeno na teoria e prática não podem ainda ser bem especificados), dentro de um con-texto prático trabalhando normalmente com poucas fontes/instâncias experimentais. Os dados coletados são direcionados a uma proposta específica e então são analisados esta-tisticamente. Normalmente os estudos de caso tem como objetivo entender uma variável específica ou a relação entre diversas variáveis coletadas.
O experimento controlado em engenharia de software manipula um fator ou va-riável das configurações de estudo. Baseado em aleatorização, diferentes tratamentos são aplicados para ou por diferentes sujeitos, enquanto são mantidas outras variáveis cons-tantes e então são mensurados os efeitos da variável estudada. Experimentos controlados são principalmente realizados em ambiente de laboratório e proveem um alto nível de controle.
No entanto, nem sempre a aleatorização é desejável ou possível. Por exemplo, em engenharia de software, os custos de ensinar a profissionais como utilizar diferentes tec-nologias (condições do experimento) de forma que eles possam aplicá-las de uma forma adequada, pode ser bastante caro. Em outro caso por exemplo, quando o nível de conheci-mento dos participantes afeta na tecnologia implementada ou se diferentes departaconheci-mentos de uma companhia constituem grupos experimentais, a aleatorização não pode ser usada. Além disso, a aleatorização pode ser anti ética, por exemplo, se uma nova tecnologia é comparada com uma tecnologia antiga e há uma atribuição de estudantes para estas tecnologias, pois a experiência e conhecimento pode ser diferente entre os 2 grupos de estudantes. Nestes casos, o quase-experimento é mais adequado, conforme é descrito a seguir.
O quase-experimento é similar ao experimento controlado, no entanto as variáveis não podem ser randomizadas, mas sim emergem das características delas mesmas. Desta forma, ele é utilizado em experimentos controlados onde não é possível ou é anti ético atribuir aleatoriamente valores as variáveis estudadas. O quase-experimento é usado para estimar o impacto da causa de uma intervenção em sua população de estudo. Infelizmente os quase-experimentos não podem com segurança demonstrar uma relação causal entre o tratamento realizado e os resultados observados.
A próxima Seção descreve com detalhes o método experimental da revisão sistemática, o qual também será utilizado neste projeto de mestrado.
2.3.2
Revisão sistemática
Revisões sistemáticas são realizadas para identificar, analisar e interpretar toda evidência disponível e relatada para uma questão específica de pesquisa [81]. Seu objetivo é permi-tir uma análise completa e abrangente das evidências existentes, obtendo uma fotografia válida do cenário vigente [140]. Para ser válida ela deve ser conduzida de uma maneira científica e rigorosa [140]. Para alcançar este objetivo, Kitchenham e Charters [81] desen-volveu um guia para a construção de revisões sistemáticas em Engenharia de Software, adaptando os existentes na área médica.
Revisão sistemática é uma metodologia de pesquisa e não apenas uma revisão da literatura cuidadosa. Ao contrário do processo usual de revisão da literatura (que em geral é realizado antes de começar qualquer trabalho de pesquisa), uma revisão sistemática é desenvolvida, como o termo denota, de uma maneira formal e sistemática. Isso significa que o processo de pesquisa conduzido numa revisão sistemática deve seguir um sequência bem definida de passos da metodologia [34].
MacDonell et al. [96] afirmam que no contexto de Engenharia de Software, revisão sistemática é considerada um método de pesquisa robusto. Já no trabalho realizado por Kitchenham et al. [82], foi possível entender como atualmente as revisões sistemáticas estão sendo usadas na área de Engenharia de Software. Kitchenham et al. [82] concluiram que ainda são pouco utilizadas as revisões sistemáticas como metodologia experimental em Engenharia de Software. A área específica dentro de Engenharia de Software que mais utiliza revisões sistemáticas é a de estimativa de custo e esforço de projeto [82]. O trabalho realizado por Bereto et al. [39] também traz importantes lições para a aplicação de revisão sistemática na área de Engenharia de Software.
O guia criado por Kitchenham e Charters [81] e também relatado por Wohlin et al. [140] é estruturado em três principais passos e suas respectivas seções: Planejamento 2.3.2.1, Execução 2.3.2.2 e Publicação 2.3.2.2. A próxima Seção descreve as ações refe-rentes ao Planejamento.
2.3.2.1 Planejamento
No planejamento é necessário realizar três diferentes ações: identificação da necessidade de uma revisão sistemática, especificação da questão de pesquisa e desenvolvimento de um protocolo da revisão.
A identificação da necessidade de uma revisão sistemática se origina do desejo do pesquisador em entender o estado da arte daquele assunto na área pesquisada. Uma revisão sistemática pode ser vista como um método de pesquisa para criar uma revisão da literatura [140].
O processo de contratação de uma revisão sistemática para que terceiros a realizem também deve fazer parte do planejamento.
Especificar as questões de pesquisa é um passo muito importante no planejamento de uma revisão sistemática. Com elas bem definidas, a condução da revisão sistemática é facilitada, principalmente a identificação dos estudos, a extração dos dados e a análise [140].
Segundo [117], o processo denominado PICOC pode ser utilizado para levantar aspec-tos da revisão sistemática, a fim de especificar melhor as questões de pesquisa:
• População/Population: A população que tem interesse pelo conteúdo da revisão, podendo ser um grupo de pessoas, organizações ou empresas. Exemplo: gerentes de software;
• Intervenção/Intervention: A intervenção é a metodologia, ferramenta, tecnologia ou procedimento que é o objeto da revisão sistemática. Exemplo: verificação e validação de software;
• Comparação/Comparison: A comparação é a definição de como cada intervenção realizada será confrontada com outra, ou seja, como os dados extraídos das pu-blicações devem ser comparados. É de suma importância, mesmo em Engenharia de Software, controlar os casos de comparação. As tecnologias em Engenharia de Software normalmente requerem treinamento. Se você comparar pessoas usando uma tecnologia após treinamento, com outras pessoas usando outra tecnologia sem treinamento, o efeito da tecnologia se confundirá com o do treinamento.
• Resultados/Outcomes: Os resultados devem estar relacionados a fatores de impor-tância para a população de destino da pesquisa (de um ponto de vista prático), tal como melhoria da confiabilidade do método e redução dos custos de produção;
• Contexto/Context: O contexto no qual a comparação ocorre (por ex. academia ou indústria), os participantes que fazem parte do estudo (ex. profissionais, acadêmicos, consultores ou estudantes) e o volume das tarefas realizadas (ex. pequena escala ou grande escala);
O processo PICOC, assim como a metodologia de pesquisa da revisão sistemática, derivou-se da medicina. Apenas para esclarecer o processo e apresentar melhor cada as-pecto dele, segue exemplificação do PICOC em uma aplicação qualquer na área médica:
População - crianças de 8 a 12 anos; Intervenção - aplicação de uma injeção; Com-paração - aqueles que tiveram a injeção aplicada com os que não tiveram; Resultados
- quais os sintomas dos que tiveram a injeção aplicado (se sentiram melhor ou pior);
Contexto - crianças estudantes de escola pública.
Muitas vezes, deve-se tomar cuidado com a forma como o experimento será executado (experimental design), pois pode ser necessário restringir a revisão sistemática a estudos de um determinado tipo. Isso reforça o fato da revisão sistemática ser devidamente limitada por questões de pesquisa claras e objetivas, a fim de evitar obter em seu conjunto de dados estudos não previstos inicialmente [81].
O desenvolvimento do protocolo da revisão sistemática é considerado uma das partes mais importantes da fase de planejamento. O objetivo do protocolo é definir e documentar como a metodologia da revisão sistemática será utilizada [134]. O protocolo deve descre-ver o contexto da pesquisa, as questões específicas da pesquisa, a estratégia planejada para encontrar os estudos, o critério para selecionar as publicações, o tratamento da qua-lidade das publicações, o planejamento de extração de dados, o plano de síntese de dados,
estratégia de publicação e um cronograma (plano de ação) para a revisão sistemática [81]. Em geral, estas partes definem todo o processo de revisão sistemática e, geralmente, é impossível prever todos os elementos e obstáculos que irão surgir durante o seu desenvol-vimento [134]. Kitchenham e Charters [81] em seu guia sugerem que alguns pontos do protocolo devem ser definidos somente durante o desenvolvimento da revisão sistemática, em particular: os termos de pesquisa, processo de seleção de estudos e extração de dados. Apesar de não ser necessário, recomenda-se revisar o protocolo durante a realização da revisão sistemática. Os avaliadores devem levar em conta diferentes aspectos (proposta da pesquisa, qualidade desejada, tempo, questões financeiras, etc) [81]. Há diversos métodos para revisão do protocolo da revisão sistemática, como por exemplo: revisão pelo próprio autor, revisão em par, revisão por supervisor, revisão por especialistas externos ou teste de execução de protocolo [134]. A próxima Seção descreve como deve ser realizada a Execução da revisão sistemática.
2.3.2.2 Execução
O relatório técnico publicado em [81] é uma das principais referências para revisão sis-temática em Engenharia de Software, inclusive foi utilizado como base no capítulo sobre revisão sistemática nas novas edições de Experimentation in software engineering: an introduction [139].
A execução da revisão sistemática, desta vez segundo Wohlin et al. [140], deve ser realizada da seguinte maneira:
• Identificação de pesquisas: A principal atividade neste passo envolve especificar strings de busca e aplicá-las em bancos de dados. De qualquer maneira, isso também inclui uma busca manual em revistas científicas e conferências, bem como procurar em outros lugares por pesquisas na área. Nesta etapa é importante evitar falsos positivos - pesquisas que são retornadas e que não são referentes ao assunto estudado - além disso é importante retirar trabalhos duplicados;
• Seleção de estudos primários: Nesta fase, os estudos são avaliados de acordo com alguns critérios. Para alguns trabalhos, somente a leitura da introdução e resumo pode ser suficiente para avaliá-lo segundo os critérios pré definidos. Em outros tra-balhos, pode ser necessário ler a metodologia e a conclusão para melhor entendê-lo. Os critérios devem ser definidos previamente, no entanto eles podem ser ajustados durante o desenvolvimento da seleção;
• Avaliação da qualidade do estudo: Avaliar a qualidade dos estudos originais é impor-tante, especialmente quando eles relatam resultados contraditórios. A qualidade dos estudos originais pode ser usada para analisar a causa da contradição dos resultados ou para pesar a importância dos estudos individualmente;
• Extração de dados: Os dados dos estudos são extraídos após a avaliação e conse-quente determinação da lista de estudos originais. A extração de dados é realizada para coletar as informações necessárias dos estudos de origem. A extração de da-dos é estruturada baseada nas questões de pesquisa. Os dada-dos são um conjunto
de valores numéricos representando, por exemplo: número de assuntos, caracterís-ticas do objeto, efeitos do tratamento, intervalos de confiança e etc. Quanto menos homogêneo forem os estudos, mais qualitativas devem ser as descrições realizadas;
• Síntese dos dados: Nesta etapa é realizada a síntese dos dados onde métodos esta-tísticos são aplicados nos dados de maneira a analisar os resultados dos diferentes estudos independentemente. Existem diversos métodos de síntese de dados, con-forme abaixo:
– Síntese temática: é um método que tem como objetivo identificar, analisar
e reportar padrões e temas em estudos primários. No mínimo, ele organiza e apresenta os dados bem detalhadamente e interpreta os vários aspectos do tópico sobre estudo.
– Síntese narrativa: conta uma “história” que se origina de uma evidência
primá-ria. Tais evidências e interpretações são estruturadas, usando por exemplo ta-bulação dos dados, agrupamentos e clusterizações em uma ferramenta. Síntese narrativa pode ser aplicada para estudos com dados qualitativos e quantitativos (além da combinação de ambos).
– Análise comparativa: tem como objetivo analisar conexões causais complexas.
Usa lógica booleana para explicar relações de causa e efeito em estudos pri-mários. A análise resultante lista necessidades e condições para cada estudo primário e direciona uma conclusão para presença ou não de variáveis indepen-dentes em cada um dos estudos.
– Meta estudo: foi originalmente definido para estudos de caso, mas pode ser
aplicado em outros tipos de experimentos também. Ele agrega resultado apli-cando um survey para questões especificas dos estudos primários. Os dados obtidos no survey são quantitativos e sua agregação é realizada utilizando mé-todos estatísticos.
– Meta etnografia: traduz estudos de um no outro e sintetiza estas traduções em
conceitos que vão além dos estudos individuais. Interpretações e explicações dos estudos primários são tratados como dados para a meta etnografia.
– Meta análise: baseada em métodos estatísticos para resumir dados
quantitati-vos em diversos casos. O estudo realizado por [25] descreve melhor as opções de meta análise e é uma das técnicas mais robustas de síntese analítica.
– Análise de escopo: tem como objetivo obter uma visão da literatura naquele
campo, mais do que sintetizar os estudos encontrados. A análise de escopo também é utilizada em mapeamentos sistemáticos.
Por fim, assim como em outros tipos de estudo empírico, a publicação da pesquisa deve ser realizada para que a mesma seja avaliada. No guia de Wohlin et al. [140], são sugeridos os seguintes caminhos possíveis de disseminação do estudo: revistas cien-tíficas do tema, lançamentos para especialistas, folhetos resumidos, posteres, websites e comunicação direta com a sociedade afetada pela pesquisa.
Se a questão de pesquisa para a revisão sistemática ainda está ampla (não direcionada), ou o campo de estudo é menos explorado, um estudo de mapeamento pode ser realizado em vez de uma revisão sistemática [140]. Um estudo de mapeamento, muitas vezes citado como “estudo de escopo”, procura algo mais amplo (no sentido de buscar em largura sobre o tema), com o objetivo de obter uma visão do estado da arte ou estado da prática daquele tópico [140].
A Tabela 3.1 do próximo Capítulo apresenta resumidamente na segunda coluna todos os passos que o guia sugere (que foram descritos acima) e como cada passo foi realizado neste trabalho.
2.4
Outros trabalhos relacionados
Esta Seção apresenta outros trabalhos relacionados ao tema desta dissertação de mestrado. Um artigo muito interessante, que ilustra bem o método de revisão sistemática e como deve ser trabalhado, é A Systematic Review of Software Development Cost Estimation Studies [73], no qual são estudados diversos métodos de estimativa de custo, com o objetivo de entender a literatura atual para direcionar novas pesquisas na área.
Kitchenham et al. realizaram um estudo bastante expressivo chamado Systematic literature reviews in Software Engineering - A systematic literature review [82], no qual foi realizada uma revisão sistemática sobre os estudos publicados que utilizaram revisão sistemática como metodologia de pesquisa em Engenharia de Software.
São exemplos interessantes de publicações que utilizaram a revisão sistemática como método de pesquisa em Engenharia de Software os trabalhos: [74], [73], [82], [55], [108], [98].
Existem trabalhos como o do Yang e Boehm [142], que concluem que o tamanho do projeto e o tamanho da equipe de desenvolvimento também afetam a relação entre a entrada do método algorítmico (tamanho do projeto) com a sua saída (esforço ou custo). Neste estudo, o ciclo de vida de desenvolvimento do projeto também foi apontado como importante para a estimativa de esforço ou custo [142].
O trabalho de 2014, realizado por Nassif et al. [112] analisa a importância dos requi-sitos de qualidade na estimativa de esforço de software em modelos baseados no dataset Desharnais (que contém 80 projetos e 20 atributos de uma empresa canadense). Os re-sultados mostram que a “Linguagem de Programação” é o fator mais estatisticamente significativo quando se calcula a estimativa de esforço. Além disso, se todos os requisitos de qualidade são eliminados na estimativa, o erro do software (MMRE) dobra.
Já o trabalho de Maxwell et al. [101] permitiu o entendimento de quais características do software afetam mais a produtividade e a estimativa de esforço [19]. Os requisitos não-funcionais de eficiência e interface do usuário (requisito de usabilidade) são as carac-terísticas do sistema que mais afetam a produtividade [101].
Os estudos realizados por Liebchen et al. [92] demonstram que a produtividade do software é afetada pelos seguintes fatores: grau de inovação tecnológica, complexidade do time e experiência do gerente de projetos. Também sugeriram que a produtividade varia de acordo com o setor da indústria no qual o software foi projetado [92].
O trabalho realizado por Magazinovic et al. [97] destacou o impacto na estimativa de esforço por mudanças nos requisitos, ambiguidades, indisponibilidade de padrões e problemas de coordenação entre o projeto de software e o seu desenvolvimento.
Um estudo feito a partir da base de dados do ISBSG, por Lokan et al. [94], determinou que a produtividade de construção de um software também é afetada pela: linguagem de programação, conhecimento da equipe de desenvolvimento, tipo da organização e o tipo da aplicação.
2.5
Considerações finais
Este Capítulo apresentou detalhes dos conceitos básicos e trabalhos existentes na litera-tura que serão utilizados no decorrer deste trabalho de pesquisa. O próximo Capítulo apresenta a revisão sistemática realizada a fim de cumprir os objetivos deste trabalho.
Revisão Sistemática
Este capítulo apresenta a revisão sistemática realizada, com o objetivo de identificar, analisar e interpretar evidência disponível na literatura sobre a utilização de requisitos não-funcionais em métodos algorítmicos de estimativa de esforço. Desta forma, será possí-vel construir uma revisão da literatura sobre métodos de estimativa de esforço e entender a forma como os métodos tratam os requisitos não-funcionais. A próxima Seção 3.1 apre-senta o Design com todos os passos da revisão sistemática, a Seção 3.2 detalha os passos do Planejamento, a Seção 3.3 descreve a Execução da revisão e a Seção 3.4 mostra a Análise completa dos resultados.
3.1
Design
O design desta revisão sistemática foi baseado no relatório técnico [81] criado por Kitche-nham e Charters, sobre o qual pequenas adaptações foram realizadas. A segunda coluna da Tabela 3.1 mostra os passos realizados nesta revisão sistemática, já a terceira coluna descreve quais são os passos previstos no relatório técnico e a última coluna descreve ob-servações pertinentes a cada passo (principalmente explicando as adaptações realizadas). A principal adaptação realizada no guia apresentado em [81] está descrita na linha 6 da Tabela 3.1. Note que o passo Fontes e métodos de referência (Seção 3.3.1.1) não existe no relatório técnico. Esse passo inserido na revisão sistemática foi importante pois com base nas “fontes de referência” obtidas foi possível criar um string de busca mais preciso e abrangente (conforme evidenciará a Seção 3.3.2.2). Os passos de 1 a 3 na Tabela 3.1 correspondem a fase de Planejamento da revisão e estão detalhados na próxima Seção 3.2. Os passos de 4 a 10 compreendem a fase de Execução e estão descritos na Seção 3.3.
Tabela 3.1: Design de nossa Revisão Sistemática versus guia de Kitchenham e Charters # Nossos passos Passos do guia Observações
1 3.2.1 Identificação da necessi-dade de uma revisão sistemá-tica
Identificação da necessidade por uma revisão sis-temática
Não há
2 Não há Contratação de
uma revisão sis-temática
Não aplicável, pois a re-visão sistemática foi ideali-zada pelos próprios autores. 3 3.2.2 Método PICOC e 3.2.3
Protocolo da revisão sistemá-tica
Determinar as questões de pesquisa
Não há
4 3.2.3 Protocolo da revisão sis-temática
Criação do pro-tocolo
Não há
5 3.2.3 Protocolo da revisão sis-temática
Avaliar o proto-colo
Não há
6 3.3.1.1 Fontes e métodos de re-ferência
Não há Para gerar e validar o string de busca foi realizada uma busca por métodos relevan-tes em estimativa de esforço 7 3.3.1 Identificação das
publica-ções, 3.3.1.2 String de busca e 3.3.1.3 Bancos de Publicações Identificação de pesquisas Não há 8 3.3.1.4 Execução da busca e 3.3.2 Extração Seleção de estu-dos primários Não há 9 3.3.2.2 Validação Avaliação da qualidade do estudo Não há.
10 3.3.2.3 Extração das informa-ções
Extração de da-dos
Não há
11 3.4 Análise Síntese dos da-dos
Não há
12 3.5 Publicação Publicação dos resultados
Não há
3.2
Planejamento
As próximas subseções descrevem os três passos realizados durante o Planejamento da revisão sistemática. A Seção 3.2.1 mostra a identificação de que há a necessidade de uma revisão sistemática neste trabalho, a Seção 3.2.2 descreve todo o processo do PICOC que servirá de base para criação das questões da pesquisa e do protocolo; por fim, a Seção 3.2.3 descreve o protocolo da revisão sistemática gerado.
3.2.1
Identificação da necessidade de uma revisão sistemática
O objetivo deste trabalho é entender o uso de requisitos não-funcionais como entrada nos métodos de estimativa de esforço (OBJ-1), conforme descrito na Seção 1.2. Das metodologias de pesquisa disponíveis para Engenharia de Software listadas na Seção 2.3, a revisão sistemática é conhecida como sendo um bom mecanismo para entender o estado da arte de um determinado tema na literatura.
Apesar do trabalho bastante abrangente e importante na área ter sido feito por Jor-gensen e Shepperd [73] em 2005, não foi encontrada nenhuma revisão sistemática focada em analisar o impacto de RNF em estimativa de esforço. Executando uma busca ainda mais aberta no Google Scholar, deixando de lado RNF, com o seguinte query de busca “allintitle: (systematic AND review AND requirement AND software)” somente 3 publicações foram retornadas, e nenhuma delas está focada em métodos algorítmicos de esforço.
Desta forma, podemos concluir que há uma clara necessidade de conduzir uma revisão sistemática neste tema a fim de cumprir o OBJ-1. Assim, é esperado produzir resultados que nos ajudarão a entender como os requisitos não-funcionais são tratados atualmente pelos métodos de estimativa de estimativa de esforço.
3.2.2
Método PICOC
A Tabela 3.2 mostra a aplicação do método do PICOC a esta pesquisa, conforme deta-lhado na Seção 2.3.2. A Tabela 3.2 é dividida em duas colunas, a primeira mostra os aspectos que devem ser levados em consideração na aplicação do método e a segunda coluna define o significado daquele determinado aspecto para esta pesquisa. Por exemplo, na primeira coluna da Tabela, o aspecto “População” descreve que o foco desta pesquisa será apresentar os resultados a empresas e grupos de pesquisas interessados na melhoria dos métodos algorítmicos de estimativa de esforço.
Tabela 3.2: Aspectos da revisão sistemática para criação das questões de pesquisa (PI-COC).
Aspectos Descrição
População Organizações ou grupos de pesquisa interessados na me-lhoria dos métodos algorítmicos de estimativa de esforço de projetos computacionais.
Intervenção Métodos algorítmicos de estimativa de esforço. Os méto-dos não-algorítmicos não serão estudaméto-dos, pois suas va-riáveis de entrada não são definidas, dependendo muitas vezes da análise subjetiva dos especialistas envolvidos. Comparação Avaliação dos métodos de estimativa de esforço,
ressal-tando as diferenças quanto ao uso de requisitos não-funcionais como entrada.
Resultados Classificação dos métodos existentes quanto ao uso de requisitos não-funcionais e identificação dos melhores métodos de estimativa de esforço que utilizam requisitos não-funcionais como entrada.
Contexto A avaliação será realizada nas publicações selecionadas na literatura (basicamente em conferências, revistas ci-entíficas e relatórios técnicos).
3.2.3
Protocolo da revisão sistemática
Com os aspectos descritos pelo método PICOC na sub Seção anterior é possível criar uma versão do protocolo da revisão sistemática. A Tabela 3.3 descreve o protocolo de nossa revisão sistemática, após diversas rodadas de ajuste, incluindo as quatro questões de pesquisa.
