engenharia de requisitos em projetos Ágeis: um … biblioteca revisado...ágeis como estratégia...
TRANSCRIPT
ENGENHARIA DE REQUISITOS EM PROJETOS ÁGEIS:
UM MAPEAMENTO SISTEMÁTICO BASEADO
EM EVIDÊNCIAS DA INDÚSTRIA.
por
DANIELA DE CASTRO PEREIRA ALVES
Dissertação de Mestrado
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CIN - CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
[email protected] www.cin.ufpe.br/~posgraduacao
RECIFE-PE 2015
UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO
CIn - CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
DANIELA DE CASTRO PERERIA ALVES
ENGENHARIA DE REQUISITOS EM PROJETOS ÁGEIS: UM MAPEAMENTO
SISTEMÁTICO BASEADO EM EVIDÊNCIAS DA INDÚSTRIA.
Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Ciência da Computação, área de concentração em Engenharia de Software, do Programa de Pós-graduação interinstitucional DINTER/MINTER em Ciências da Computação do Centro de Informática da Universidade Federal de Pernambuco com a Universidade do Vale do São Francisco UNIVASF e Associadas.
ORIENTADOR: Alexandre Marcos Lins de Vasconcelos
RECIFE-PE 2015
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
A474e Alves, Daniela de Castro Pereira Engenharia de requisitos em projetos ágeis: um mapeamento
sistemático baseado em evidências da indústria / Daniela de Castro Pereira Alves. – 2015.
104 f.: il., fig., tab. Orientador: Alexandre Marcos Lins de Vasconcelos. Dissertação (Mestrado) – Universidade Federal de Pernambuco.
CIn, Ciência da Computação, Recife, 2015. Inclui referências e apêndices.
1. Engenharia de software. 2. Metodologias ágeis. 3. Mapeamento
sistêmico I. Vasconcelos, Alexandre Marcos Lins de (orientador). II. Título. 005.1 CDD (23. ed.) UFPE- MEI 2016-018
Dissertação de Mestrado apresentada por
Daniela de Castro Pereira Alves à Pós-Graduação em Ciência da
Computação do Centro de Informática da Universidade Federal de
Pernambuco, sob o título “ENGENHARIA DE REQUISITOS EM
PROJETOS ÁGEIS: UM MAPEAMENTO SISTEMÁTICO BASEADO EM
EVIDÊNCIAS DA INDÚSTRIA” orientada pelo Prof. Alexandre Marcos
Lins de Vasconcelos e aprovada pela Banca Examinadora formada pelos
professores:
______________________________________________________
Profa. Carla Taciana Lima Lourenço Silva Schuenemann
Centro de Informática/UFPE
______________________________________________________
Profa. Fernanda Maria Ribeiro de Alencar
Departamento de Eletrônica e Sistemas/ UFPE
______________________________________________________
Prof. Alexandre Marcos Lins de Vasconcelos
Centro de Informática / UFPE
Visto e permitida a impressão.
Recife, 19 de agosto de 2015.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
Dedico este trabalho à minha família, por toda ajuda, compreensão e colaboração.
AGRADECIMENTOS Agradeço primeiramente a Deus. A minha família por todo apoio que me foi dedicado. Ao meu namorado Renato por toda sua paciência, cumplicidade e companheirismo. Ao meu orientador Alexandre Marcos Lins de Vasconcelos por todo seu apoio, incentivo e paciência. Aos amigos da pós-graduação: Juliana Dantas e Eduardo Wanderley por todas as contribuições na realização desta pesquisa. Aos amigos do trabalho: Fred Leonardo, Danielle Braga, Luana Talita, Ivan Dornelas e Zuleika Tenório pelo apoio incondicional, que foram essências para que eu conseguisse concluir esse meu objetivo.
Resumo
Nos últimos anos, percebe-se um interesse crescente na utilização de metodologias
ágeis como estratégia para minimizar os problemas no desenvolvimento de software.
Apesar disso, pouco ainda se sabe sobre como a engenharia de requisitos está sendo
conduzida em conjunto com essas metodologias. Neste contexto, o objetivo desta
pesquisa é investigar como a engenharia de requisitos e as metodologias ágeis vêm
sendo utilizadas conjuntamente na prática em projetos de desenvolvimento de
software aplicados na indústria. Para isso, foi realizado um mapeamento sistemático
da literatura que encontrou 24 estudos primários relevantes, cujos dados foram
extraídos e sintetizados. Esse mapeamento identificou as técnicas e processos de
engenharia de requisitos que estão sendo mais utilizados no contexto de
desenvolvimento ágil e quais os principais problemas e limitações encontradas. Após
a execução do mapeamento, verificou-se que a falta de envolvimento do usuário
associada às características das atuais técnicas utilizadas para especificar requisitos
e suas constantes mudanças são os principais desafios a serem superados.
Palavras-Chaves: Engenharia de Requisitos. Metodologias Ágeis. Mapeamento
Sistemático. Pesquisa Qualitativa.
Abstract
In recent years, we can see a growing interest in using agile methodologies as a
strategy to minimize the problems in software development. Nevertheless, little is
known as requirements engineering is being conducted in conjunction with these
methodologies. In this context, the objective of this research is to investigate how the
requirements engineering and agile methodologies have been used jointly in practice
in software development projects applied in the industry. For this, it was conducted a
systematic literature mapping that found 24 relevant primary studies, whose data were
extracted and synthesized. This mapping identified the most used techniques and
process of requirements engineering and what are the main problems and limitations
encountered in the context of agile development. After the execution of the mapping, it
was found that lack of user involvement associated with the characteristics of current
techniques used to specify requirements and their constant changes are the main
challenges to overcome.
Keywords: Requirements Engineering. Agile Methodologies. Systematic Mapping.
Qualitative Research.
Lista de Figuras
Figura 1: Ciclo de desenvolvimento da pesquisa ....................................................... 37
Figura 2: Processo de síntese temática ..................................................................... 43
Figura 3: Resultado da busca automática e manual ................................................... 46
Figura 4: Distribuição dos estudos por classificação de qualidade ............................. 48
Figura 5 : Pontuação por Critério de Qualidade ......................................................... 49
Figura 6: Quantidade por nota baixa .......................................................................... 50
Figura 7: Estudos selecionados por etapa ................................................................. 51
Figura 8: Distribuição temporal dos estudos primários ............................................... 52
Figura 9: Distribuição dos estudos por metodologia ................................................... 52
Figura 10: Distribuição dos estudos por método de pesquisa .................................... 53
Figura 11: Distribuição dos estudos por países .......................................................... 53
Figura 12: Técnicas utilizadas para elicitar requisitos ................................................. 54
Figura 13: Técnicas utilizadas para especificar requisitos .......................................... 55
Figura 14: Mapa temático dos desafios encontrados ................................................. 58
Figura 15: Relacionamento sugestões/práticas por desafios/problemas .................... 73
Lista de Quadros
Quadro 1: Quadro metodológico ................................................................................ 36
Quadro 2: Distribuição da pontuação por faixa de qualidade ..................................... 42
Lista de Tabelas
Tabela 1: Artigos X técnicas utilizadas para elicitar requisitos .................................... 55
Tabela 2: Artigos X técnicas utilizadas para especificar requisitos ............................. 56
Tabela 3: Detalhamento dos desafios e limitações encontrados ................................ 59
Tabela 4: Top 10 dos desafios e limitações ............................................................... 60
Tabela 5: Relação com trabalhos relacionados .......................................................... 78
Lista de Abreviaturas / Acrônimos
AS - Artigos Selecionados
CE – Critérios de Exclusão
CI – Critério de Inclusão
CIn – Centro de Informática
CQ – Critério de Qualidade
ER – Engenharia de Requisitos
ESBE – Engenharia de Software Baseada em Evidências
JAD - Joint Application Design
QPE – Questão de Pesquisa Específica
MSL – Mapeamento Sistemático da Literatura
RSL – Revisão Sistemática da Literatura
RNF – Requisitos não Funcionais
TDD – Test Driven Development
UFPE – Universidade Federal de Pernambuco
XP – Extreme Programming
SUMÁRIO
1. INTRODUÇÃO ......................................................................................................................... 13 1.1. DEFINIÇÃO DO PROBLEMA ..................................................................................................... 14 1.2. MOTIVAÇÃO .......................................................................................................................... 14 1.3. QUESTÃO DE PESQUISA .......................................................................................................... 14 1.4. OBJETIVO GERAL .................................................................................................................... 15 1.5. OBJETIVOS ESPECÍFICOS ......................................................................................................... 15 1.6. CONTRIBUIÇÕES E RESULTADOS ............................................................................................. 15 1.7. ESTRUTURA DO TRABALHO..................................................................................................... 15 2. REVISÃO DA LITERATURA ....................................................................................................... 17 2.1. METODOLOGIAS ÁGEIS ........................................................................................................... 17 2.2. ENGENHARIA DE SOFTWARE BASEADA EM EVIDÊNCIAS (ESBE) ................................................ 19 2.3. ENGENHARIA DE REQUISITOS ................................................................................................. 21 2.3.1. TÉCNICAS DE ENGENHARIA DE REQUISITOS ....................................................................... 23 2.4. TRABALHOS RELACIONADOS................................................................................................... 29 2.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO.................................................................................... 35 3. METODOLOGIA DA PESQUISA ................................................................................................. 36 3.1. CLASSIFICAÇÃO DA PESQUISA ................................................................................................. 36 3.2. CICLO DA PESQUISA ................................................................................................................ 37 3.3. PROCEDIMENTO DE COLETA DE DADOS .................................................................................. 38 3.3.1. PROTOCOLO DO MAPEAMENTO SISTEMÁTICO .................................................................. 38 3.4. LIMITAÇÕES E AMEAÇAS À VALIDADE ..................................................................................... 43 3.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO.................................................................................... 44 4. RESULTADOS .......................................................................................................................... 45 4.1. RESULTADOS DOS PROCEDIMENTOS DE BUSCA E SELEÇÃO ...................................................... 45 4.1.1. EQUIPE ENVOLVIDA .......................................................................................................... 45 4.1.2. EXECUÇÃO ........................................................................................................................ 45 4.1.3. VISÃO GERAL DOS ESTUDOS.............................................................................................. 51 4.1.4. MAPEAMENTO DAS EVIDÊNCIAS ....................................................................................... 53 4.2. CONSIDERAÇÕES FINAIS ......................................................................................................... 76 5. CONCLUSÕES.......................................................................................................................... 77 5.1. RELAÇÃO DESTA PESQUISA COM OS TRABALHOS RELACIONADOS ........................................... 78 5.2. IMPLICAÇÕES PARA A PESQUISA E PRÁTICA ............................................................................ 79 5.3. TRABALHOS FUTUROS ............................................................................................................ 79 5.4. CONSIDERAÇÕES FINAIS ......................................................................................................... 79 6. REFERÊNCIAS.......................................................................................................................... 81 APÊNDICE A – PROTOCOLO DO MAPEAMENTO SISTEMÁTICO ........................................................ 86 APÊNDICE B – ESTUDOS PRIMÁRIOS SELECIONADOS .................................................................... 100 APÊNDICE C – AVALIAÇÃO DA QUALIDADE DOS ESTUDOS ............................................................ 102 APÊNDICE D – EVIDÊNCIAS DE CONTEXTO DOS ESTUDOS SELECIONADOS ..................................... 103 APÊNDICE E – DESAFIOS E LIMITAÇÕES POR ESTUDOS SELECIONADOS ......................................... 104
13
1. INTRODUÇÃO
Devido ao aumento da competitividade, as empresas são cada vez mais
impulsionadas a desenvolver e/ou aprimorar seus produtos, consequentemente,
aumentando a demanda de desenvolvimento de software. Por outro lado, também é
crescente o interesse de pesquisadores e profissionais das áreas que lidam com o
desenvolvimento destes softwares (MORISIO et al., 2002; DAHLSTEDT, 2003).
Estudos mostram que a engenharia de requisitos é um fator crítico para o
sucesso dos projetos de software. Segundo o Standish Group (2014) os maiores
prejuízos em projetos de software ocorrem devido a requisitos incompletos (13,1%),
falta de envolvimento com os usuários (12,4%), falta de recursos (10,6%),
expectativas não realistas (9,9%), falta de suporte executivo da gerência (9,3%) e
mudanças nos requisitos e especificações (8,7%).
Sommerville (2007) e Kujala (2002) relatam que o mau entendimento dos
requisitos é um dos principais fatores de insucesso, retrabalho, atrasos e custos
adicionais durante todo o desenvolvimento de software.
As metodologias ágeis foram criadas com intuito de minimizar os problemas
causados pelas metodologias tradicionais. Elas possuem processos flexíveis e
adaptativos e que aceitam as mudanças de requisitos como parte inseparável do seu
processo de desenvolvimento, visando à melhoria na qualidade de software e o
aumento da satisfação do cliente. Entregas frequentes e feedback contínuo do cliente
são princípios das metodologias ágeis para minimizar os riscos causados pelas
constantes mudanças nos requisitos (COCKBURN, 2004; BECK, 1999; SCHWABER,
1995; PALMER e FELSING, 2002).
Dyba e Dingsoyr (2008) relatam que Scrum e XP são as metodologias ágeis
mais utilizadas ultimamente, porém evidências sobre como essas metodologias estão
sendo utilizadas na prática ainda são escassas. Existem relatos de que estas
metodologias diminuem as taxas de insucesso dos projetos de software, porém,
Ferreira e Cohen (2008) afirmam que são poucas as pesquisas empíricas sobre essa
efetividade, a maioria das pesquisas é de natureza exploratória.
Paetsh (2003) entende que a engenharia de requisitos (ER) e os métodos
ágeis podem ser considerados incompatíveis. Além disso, evidências de pesquisas
realizadas em projetos que adotam metodologias ágeis apontam problemas de
backlogs muito instáveis, dificuldades dos engenheiros de software em se adaptarem
14
às mudanças constantes de requisitos, e ainda em aplicar práticas ágeis como User
Stories e Test Driven Development (TDD) (KAMEI, 2012).
Nesse contexto, foi realizado um mapeamento sistemático da literatura,
objetivando investigar como a engenharia de requisitos tem sido conduzida em
projetos que adotam metodologias ágeis para desenvolvimento de Software. Esse
mapeamento identificou as técnicas e os processos de engenharia de requisitos que
estão sendo utilizados e quais são os problemas e limitações encontradas.
1.1. Definição do Problema
Apesar da vasta utilização de metodologias ágeis para desenvolvimento de
software, de acordo com o que podemos ver na sessão de Introdução, alguns autores
afirmam que pouco ainda se sabe como essas metodologias estão sendo conduzidas
na prática e em conjunto com a engenharia de requisitos. Além disso, pesquisas
apontam que as questões ligadas aos requisitos são as principais causas dos
prejuízos ocorridos durante o desenvolvimento de software.
1.2. Motivação
A motivação deste estudo é responder como a engenharia de requisitos tem
sido conduzida em projetos que adotam metodologias ágeis para desenvolvimento de
software aplicado na indústria. Espera-se que essa pesquisa mostrem as técnicas e
os processos da engenharia de requisitos mais utilizados, bem como os problemas e
limitações encontradas.
1.3. Questão de Pesquisa
Para atingir o objetivo desse estudo foi elaborada a seguinte questão de
pesquisa:
QP: Como a engenharia de requisitos tem sido conduzida em projetos
que adotam metodologias ágeis para desenvolvimento de software?
As seguintes questões de pesquisa específicas (QPE) foram definidas para
orientar a extração, análise e síntese dos resultados:
QPE1: Quais as técnicas/processos de engenharia de requisitos estão
sendo utilizados com objetivo de levantar requisitos em projetos que adotam
metodologias ágeis?
15
QPE2: Quais as técnicas/processos de engenharia de requisitos estão
sendo utilizados com objetivo de especificar requisitos em projetos que
adotam metodologias ágeis?
QPE3: O que atualmente se sabe sobre os desafios e limitações das
técnicas de engenharia de requisitos adotadas em projetos ágeis?
QPE4: Quais boas práticas/sugestões podem minimizar os efeitos desses
desafios e limitações encontrados?
QPE5: Quais as implicações, para a indústria de software e para a
comunidade acadêmica, dos atuais estudos que envolvem a engenharia de
requisitos em Projetos ágeis?
1.4. Objetivo geral
O objetivo geral desta pesquisa é reunir de forma sistemática, o conhecimento
sobre a engenharia de requisitos aplicada no desenvolvimento ágil de software.
1.5. Objetivos Específicos
Os objetivos específicos que contribuirão para atingir o objetivo geral são:
a) Identificar os estudos empíricos da literatura;
b) Identificar evidências que apontem técnicas, processos, desafios e
limitações;
c) Analisar e classificar as evidências encontradas.
1.6. Contribuições e Resultados
A seguir são apresentadas as contribuições e os resultados esperados desse
trabalho:
Mostrar como está sendo conduzida a engenharia de requisitos em projetos
que utilizam metodologias ágeis.
A partir dos resultados e possíveis lacunas deste trabalho, permitir que
sejam realizadas novas pesquisas.
1.7. Estrutura do Trabalho
Este trabalho está estruturado da seguinte maneira:
16
Capítulo 1 – Introdução: apresenta toda parte introdutória como base
para o desenvolvimento do restante do trabalho;
Capítulo 2 – Revisão da literatura: apresenta o referencial teórico dos
principais assuntos e os trabalhos relacionados com esta pesquisa;
Capítulo 3 – Metodologia da Pesquisa: apresenta os procedimentos
metodológicos utilizados nesta pesquisa;
Capítulo 4 – Resultados: apresenta os resultados obtidos no mapeamento
sistemático da literatura;
Capítulo 5 – Considerações finais: apresenta as limitações e ameaças à
validade da pesquisa, assim como suas implicações, recomendações para
trabalhos futuros e conclusões finais do trabalho;
Apêndices: apresentam os procedimentos, resultados e formulários
relevantes para a pesquisa.
17
2. REVISÃO DA LITERATURA
Este capítulo apresenta uma descrição das principais teorias utilizadas para a
condução desta pesquisa, ela é resultante de uma revisão bibliográfica não
sistemática. Nas próximas seções serão abordadas a engenharia de requisitos, as
metodologias ágeis, a engenharia de software baseadas em evidências e os trabalhos
relacionados.
2.1. Metodologias Ágeis
As metodologias ágeis são abordagens contemporâneas para criação de
software baseando-se na colaboração com o cliente, no trabalho em equipe, no
desenvolvimento iterativo e incremental (RICO; SAYANI; SONE, 2009), com
processos flexíveis e adaptativos e que aceitam as mudanças como parte inseparável
do seu processo de desenvolvimento, visando à melhoria na qualidade de software e
ao aumento da satisfação do cliente (HIGHSMITH, 2000).
Elas nasceram da insatisfação com as metodologias tradicionais e da
necessidade de desenvolver softwares cada vez mais adaptativos às inovações
tecnológicas e ao mercado competitivo (SOMMERVILLE, 2007). A definição oficial de
Desenvolvimento Ágil de Software surgiu através de um manifesto denominado de
Aliança Ágil, ele foi publicado 2001 por um grupo de 17 especialistas em
desenvolvimento de software que se reuniram durante dois dias para propor melhores
maneiras de desenvolvimento de softwares (AGILE MANIFESTO, 2001).
O produto desse encontro foi a identificação de 12 princípios e valores que as
metodologias ágeis deveriam seguir.
Valores
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Princípios
Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e
contínua de software de valor.
18
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos
ágeis se adequam a mudanças, para que o cliente possa tirar vantagens
competitivas.
Entregar software funcionando com frequência, na escala de semanas até
meses, com preferência aos períodos mais curtos.
Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente
e suporte necessário, e confiar que farão seu trabalho.
O Método mais eficiente e eficaz de transmitir informações para, e por dentro
de um time de desenvolvimento, é através de uma conversa cara a cara.
Software funcional é a medida primária de progresso.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente,
passos constantes.
Contínua atenção a excelência técnica e bom design aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou
ser feito.
As melhores arquiteturas, requisitos e designs emergem de times auto-
organizáveis.
Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
ajustam e otimizam seu comportamento de acordo.
As metodologias ágeis tem o objetivo de eliminar a dependência em realizar
um extenso planejamento inicial e documentação de todos os requisitos do sistema
(FERREIRA E COHEN, 2008), com propostas que dão ênfase a flexibilidade,
comunicação informal e código funcionando (CAPILUPPI et al., 2007).
Os talentos e habilidades inerentes aos indivíduos devem ser enfatizados,
moldando o processo, as pessoas e equipes específicas (COCKBURN e
HIGHSMITH, 2001). Deve-se utilizar o desenvolvimento iterativo e incremental,
valorizando a colaboração e comunicação entre cliente e toda a equipe, sendo
adaptativa e com capacidade de responder às mudanças.
19
2.2. Engenharia de Software Baseada em Evidências (ESBE)
Para Monteiro (2010), a essência do paradigma baseado em evidência é
coletar e analisar sistematicamente todos os dados disponíveis sobre determinado
fenômeno para obter uma perspectiva mais completa e mais ampla do que se pode
captar através de um estudo individual.
O paradigma baseado em evidência ganhou forças inicialmente na medicina
(Evidence-based Medicine – EBM), que objetiva integrar as melhores evidências de
pesquisas com experiências clinicas e avaliação de pacientes. Segundo Mafra et al.
(2006), Kitchenham foi o primeiro a estabelecer um paralelo entre medicina e
engenharia de software no que diz respeito à abordagem baseada em evidências.
A ESBE busca prover meios pelos quais melhores evidências provenientes da
pesquisa possam ser integradas com experiência prática e valores humanos no
processo de tomada de decisão considerando o desenvolvimento e a manutenção do
software. Ainda de acordo Kitchenham et a. (2004), a ESBE é relevante para a
engenharia de software, pois fornece os insumos necessários que podem ajudar os
engenheiros de software na busca das melhores práticas, usando as tecnologias
apropriadas e por consequência evitando as tecnologias inadequadas.
Alguns trabalhos sugerem que profissionais e pesquisadores da engenharia de
software devem considerar o suporte do uso da engenharia de software baseada em
evidências para melhorar suas decisões sobre quais tecnologias adotar (DYBA et al.,
2008, KITCHENHAM et al., 2004; KITCHENHAM et al., 2007; OATES e CAPPER,
2009; TRAVASSOS, 2007). À medida que uma área de pesquisa amadurece, existe
uma tendência de aumento acentuado no número de relatórios e resultados
divulgados, tornando-se importante uma síntese para fornecimento da visão geral na
área (PETERSEN et al.,2007).
A ESBE reúne e avalia evidências existentes em uma tecnologia através de
cinco etapas de uma metodologia (DYBA et al., 2005):
1. Transformar o problema ou necessidade de informação em uma questão de
pesquisa;
2. Pesquisar na literatura por melhores evidências disponíveis para responder
às perguntas;
3. Avaliar criticamente as evidências, quanto a sua validade, impacto e
aplicabilidade;
20
4. Integrar as evidências avaliadas com experiências práticas, valores e
circunstâncias para tomar decisões;
5. Avaliar o desempenho das etapas de 1 a 4 e buscar formas de melhorá-las.
Um dos métodos da engenharia de software baseada em evidências é o
mapeamento sistemático da literatura (MSL), também conhecido como Estudo de
Escopo. Ele é classificado como estudo secundário, pois dependem dos estudos
primários para revelar evidências e construir conhecimento (PETERSEN et al.,2007).
Eles têm o objetivo de identificar todas as pesquisas relacionadas a um tema
específico, respondendo a questões mais amplas relacionadas à evolução da
investigação. As questões de pesquisa típicas deste método são de natureza
exploratória.
Da mesma forma que um estudo de mapeamento sistemático, outro estudo
secundário existente é a revisão sistemática da literatura (RSL), conhecida como um
dos principais métodos da engenharia de software baseada em evidências e que tem
recebido muita atenção na engenharia de software (KITCHENHAM et al., 2004; DA
SILVA, et al., 2010).
Arksey e O'Malley (2005) afirmam que o arcabouço metodológico de um estudo de
mapeamento sistemático é apoiado na mesma visão de uma revisão sistemática, no
sentido de ser conduzido de maneira auditável, rigorosa e transparente. Contudo,
entre os dois métodos existem algumas diferenças importantes que podemos
observar a seguir.
Uma diferença é em relação à abrangência do estudo. O mapeamento
sistemático tem como objetivo encontrar e classificar estudos primários sobre
um tópico ou área de estudo e possuem questões de pesquisa amplas, de
natureza exploratória e descritiva, já a revisão sistemática foca em questões de
pesquisa bem definidas e normalmente de natureza causal (KITCHENHAM,
2007; PETERSEN et al., 2007).
Kitchenham et al. (2007) recomenda considerar nas revisões sistemáticas as
questões de pesquisa a partir da estrutura PICOC (Population, Intervention,
Context, Outcomes, e Comparison) que traduzida para o português seria:
População, Intervenção, Contexto, Resultados e Comparação. Do outro lado,
Petersen et al. (2007) afirma que deveria ser considerado, no máximo, a
21
população e a intervenção, do contrário poderia introduzir limitações
desnecessárias para um estudo de mapeamento.
Outra diferença é que em um mapeamento sistemático a extração de dados é
mais abrangente e a síntese tem foco maior na classificação e categorização
dos resultados (BAILEY et al., 2007), já em uma revisão sistemática a extração
é mais aprofundada e a síntese foca mais em identificar as melhores práticas e
sua efetividade (PETERSEN et al., 2007).
Kitchenham et al. (2007) definiram uma revisão sistemática da literatura como
um meio de identificar, avaliar e interpretar todas as evidências disponíveis relevantes
para uma questão específica de pesquisa, área temática, ou fenômeno de interesse.
E mapeamento sistemático da literatura, como uma ampla revisão dos estudos
primários em um tema específico que visa identificar as evidências disponíveis sobre
o tema.
Considerando-se, então, a questão central desta pesquisa e os conceitos sobre
métodos de pesquisas apresentados, este trabalho é caracterizado como um
mapeamento sistemático.
2.3. Engenharia de Requisitos
Requisito é uma descrição sobre o que deverá ser implementado no software,
devendo conter descrições sobre o funcionamento da aplicação e quais as restrições
para operacionalização da mesma. Os requisitos são o ponto de partida para a
definição de um sistema e por isso são decisivos no sucesso do desenvolvimento de
um software (KOTONYA e SOMMERVILLE, 1998).
Em IEEE (1984) engenharia de requisitos é defina como o processo de
aquisição, refinamento e verificação das necessidades do cliente para um sistema de
software, objetivando-se ter uma especificação completa e correta dos requisitos de
software. Segundo Thayer (1997), a engenharia de requisitos fornece o mecanismo
apropriado para entender aquilo que o cliente deseja, analisando as necessidades,
avaliando a viabilidade, negociando soluções, especificando-as sem ambiguidade e
gerenciando suas mudanças.
O objetivo principal da engenharia de requisitos é descobrir as reais
necessidades dos stakeholders, que são as pessoas ou organizações que serão
22
afetadas pelo sistema e tem influência, direta ou indireta, sobre os requisitos do
sistema. Para isso, é preciso entender o problema e seu contexto, elicitar os
requisitos necessários pra o sistema, analisá-los, documentá-los e validá-los
(KOTONYA e SOMMERVILLE, 1998).
Durante as fases de desenvolvimento de projetos de software, a fase de
engenharia de requisitos é uma das mais complexas do processo de desenvolvimento
do software (COCKBURN, 2002). Atender aos prazos, custos e o escopo planejados
inicialmente junto com o cliente é muito importante para a satisfação do cliente.
A engenharia de requisitos com seu enfoque sistemático destina-se a elicitar,
organizar e documentar os requisitos de um software com base em um processo que
estabeleça e mantenha um acordo entre os stakeholders (ENGHOLM, 2010). Ela é
definida como um processo de comunicação onde será especificado o que o software
deve fazer, suas funções, suas propriedades essenciais e desejáveis, e também suas
restrições (SOMMERVILLE, 2007).
A especificação dos requisitos precisa ser legível e rastreável de forma a
gerenciar a evolução do sistema no tempo. O gerenciamento dos requisitos é de
extrema importância e faz parte das melhores práticas de engenharia de software
(ENGHOLM, 2010).
Nuseibeh et al.(2000) mencionam que requisitos com erros, mal entendidos ou
necessidades omitidas são mais caros para reparar mais tarde no projeto. Kotonya et
al. (1998) relata que os problemas relacionados com a ER são provenientes de
divergência, incompletude ou inconsistência dos requisitos.
Apesar da importância da engenharia de requisitos no sucesso do
desenvolvimento do software e na minimização dos riscos de projeto, essa prática é
vista nos métodos ágeis como burocrática que torna o processo menos ágil. Pelo fato
da engenharia de requisitos tradicional contar com a documentação para gerenciar o
projeto e compartilhar conhecimentos e os métodos ágeis se concentram na
colaboração face to face entre os stakeholders para lidar com os mesmos objetivos, a
engenharia de requisitos e desenvolvimento ágil são vistos, muitas vezes, como
atividades incompatíveis (PAETSCH; EBERLEIN; MAURER, 2003).
Por fim, Cao e Ramesh (2008) relatam que é esse natureza desafiadora das
metodologias ágeis que fazem com que os profissionais e pesquisadores tenham
tanto interesse por esse tema.
23
2.3.1. Técnicas de Engenharia de Requisitos
Nesta seção, apresentamos brevemente as técnicas de elicitação e
especificação de requisitos que estão em consonância com os resultados deste
mapeamento sistemático da literatura.
Questionários
De acordo com Lauesen (2002) O uso de Questionários é muito utilizado
quando os analistas identificam a necessidade de coletar as mesmas informações de
muitos usuários e ao mesmo tempo. Quando aplicado, cada usuário responde o
questionário individualmente e posteriormente os requisitos são identificados através
de análise de respostas fornecidas.
O importante em um questionário é que as questões sejam claras e de fácil
entendimento, procurando usar sempre o vocabulário comum dos usuários e que as
questões reflitam o que os analistas estão procurando. Esse é um dos métodos de
coleta de requisitos que tem um dos menores custos de aplicação, além de atingir um
grande número de pessoas.
Joint Application Development (JAD)
É uma técnica organizada e estruturada para a elicitação de requisitos
(MAIDEN et al., 1996). Ela visa reunir autoridades representativas e gerenciais em um
workshop organizado para promover decisões (BELGAMO et al., 2000). Ela Promove
a cooperação, o entendimento e o trabalho em grupo entre os usuários e
desenvolvedores, facilitando a criação de uma visão compartilhada do produto.
O objetivo desta técnica é aumentar o comprometimento e participação do
usuário e obter subsídios para elaborar o documento de especificação de requisitos
com o consenso de todos. De acordo com Linn (2008) O sucesso desta técnica
depende do líder da sessão JAD, dos desenvolvedores, usuários finais e as partes
interessadas do produto e do envolvimento grupo.
Esta técnica deve ser utilizada nos casos onde existe a necessidade de
consenso entre diversos usuários, pois possibilita a todos os envolvidos ter uma visão
global do sistema, ajudando a consolidar interesses de diversos usuários quanto ao
sistema a ser desenvolvido.
24
Grupo Focal
Grupos focais são debates ou entrevistas com um pequeno grupo selecionado
de indivíduos, que discute um tópico específico, pré-definido e limitado, sob a
orientação de um facilitador ou moderador (BLACKBURN, 2000; GIBBS, 1997).
É uma técnica informal, onde um grupo de usuários de diferentes origens e
com diferentes habilidades discutem questões de forma livre. Os grupos focais
ajudam a identificar as necessidades dos usuários e as coisas que são importantes
para eles.
Brainstorming
É uma técnica usada para gerar novas ideias e encontrar a solução para uma
questão específica, além de promover o pensamento criativo. Brainstorming pode ser
usado para obter recursos para a aplicação, definir o projeto ou problema para
trabalhar e para diagnosticar problemas em um curto espaço de tempo.
Essa técnica contém duas fases, a primeira é a de geração, onde as ideais são
coletadas, na segunda fase, a de avaliação, as ideais coletadas são discutidas. Seu
objetivo é uma apresentação do problema/necessidade a um grupo específico,
objetivando assim buscar soluções.
Workshop
Trata-se de uma técnica de elicitação em grupo usada em uma reunião
estruturada. Devem fazer parte do grupo uma equipe de analistas e os stakeholders
que melhor representam a organização e o contexto em que o sistema será usado.
O importante nessa técnica é a postura da pessoa que vai conduzir a reunião,
pois ela deve ser neutra e boa observadora, evitando influenciar nas tomadas de
decisão tanto por parte dos analistas quanto das pessoas envolvidas.
User Stories
User Stories são descrições simples de funcionalidade dos sistemas que
contém apenas informação suficiente para que os desenvolvedores possam produzir
uma estimativa razoável do esforço para implementá-lo (AGILE MODELING, 2015).
O objetivo desta técnica é aumentar o comprometimento e participação dos
usuários e obter subsídios para elaborar o documento de especificação de requisitos
25
para o sistema com o consenso de todos.
Protótipos
Um protótipo representa o produto real tanto no sentido funcional quanto no
sentido gráfico (SOMERVILLE, 2007). Trata-se de uma versão inicial do sistema,
baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde
cedo falhas que através da comunicação verbal não são tão facilmente identificáveis.
Eles permitem que os usuários e as partes interessadas possam trabalhar com
a versão inicial do produto objetivando entender o sistema e discutir requisitos
adicionais e/ou requisitos não atendidos.
Os protótipos são normalmente de dois tipos:
Protótipos descartáveis: neste tipo de utilização, o protótipo não é
reutilizável e, portanto, é descartado sempre que o processo de
elicitação de requisitos é finalizado.
Protótipos evolutivos: nesse tipo de utilização, os protótipos são
reutilizados. Eles são evoluídos ou melhorado de acordo com o
feedback.
Features
São declarações de alto nível, uma vez que não possuem detalhes necessários
para a implementação, derivadas das necessidades dos stakeholders. Para cada
feature identificada temos um ou mais requisitos de software, esse requisito de
software é que ira tratar em maiores detalhes como a feature será atendida.
Story Card
Story Card é uma técnica de captura de requisitos de sistemas, esta técnica
surgiu com a metodologia XP, porém podemos utilizar esta técnica com qualquer
metodologia de desenvolvimento de sistemas ágeis.
Eles têm o objetivo de capturar os requisitos, e se concentram em “quem, o
quê e porquê de um recurso, e não como”. Story Card deve ser escrito a partir de uma
perspectiva do usuário e deve ser utilizada linguagem no negócio, para que seja
compreendido por todos.
26
XXM (eXtreme X-Machine)
De acordo com Thomson et al. (2004) XXM são utilizados para mostrar um
modelo de alto nível da totalidade sistema.
Ele é utilizado por desenvolvedores como um método de nível superior para
conceber sistemas. Uma extrema X-Machine nos permite modelar as estruturas de
controle de uma história e, finalmente, de todo o sistema. Cada modelo consiste de
um conjunto de estados que correspondem às telas no sistema final e funções que
ligam essas telas. (THOMSON e HOLCOMBE, 2003)
Ele possibilita a visualização de informações suficientes para que sejam
realizados os teste que podem garantir que a implementação do programa está em
conformidade diretamente ao XXM e, portanto, o modelo de cartão de história
(THOMSON e HOLCOMBE, 2007).
XSBD(eXtreme Scenario-Based Design)
De acordo Lee (2010), XSBD proporciona benefícios fundamentais da
abordagem de design baseada em cenários (SBD) de usabilidade. XSBD foi
concebida para uso em projetos em que uma grande parte da qualidade global do
sistema é determinada pelo sistema de usabilidade.
O objetivo principal do processo XSBD é que o engenheiro de usabilidade
possa desenvolver eficientemente um sistema de software que atenda a usabilidade
do projeto e metas de desenvolvimento. Ele baseia-se em uma série de práticas de
SBD, que são ajustadas para trabalhar em uma estrutura ágil incremental. Esta
estrutura ágil é baseada em práticas e processos de XP e Scrum.
Há cinco papéis principais no processo XSBD: o engenheiro de usabilidade, o
desenvolvedor, o representante do usuário final, o representante do cliente e o
gerente de projeto. O engenheiro de usabilidade e o representante do usuário final
estão principalmente preocupados com o design da interface do usuário. O
desenvolvedor e o representante do cliente estão preocupados com o
desenvolvimento do sistema. O gerente de projeto é cobrado com a manutenção e
acompanhamento do cronograma do projeto.
Diagrama de Atividades:
É um diagrama definido pela Linguagem de Modelagem Unificada (UML), que
representa os fluxos conduzidos por processamentos. É essencialmente um gráfico
27
de fluxo, mostrando o fluxo de controle de uma atividade para outra. Eles são
utilizados normalmente para modelagem de processos de negócio, para modelar a
lógica detalhada de uma regra de negócio.
Ele fornece uma visualização do comportamento de um sistema descrevendo a
sequência de ações em um processo. Os diagramas de atividades são semelhantes a
fluxogramas porque mostram o fluxo entre as ações em uma atividade, no entanto, os
diagramas de atividades também podem mostrar fluxos paralelos ou simultâneos e
fluxos alternativos.
AUC (Agile Use Case) , ALC (Agile Loose Case) e ACC (Agile Choose Case)
São três artefatos ágeis proposto por Farid et al. (2012) para modelar
requisitos. A proposta é que Requisitos Funcionais sejam modelados através Agile
Use Case (AUC), requisitos não funcionais sejam modelados através de Agile Loose
Case (ALC) e soluções potenciais propostas (operacionalizações) para os ALCs
sejam modeladas como Agile Choose Case (ACC).
INVEST (Independent, Negotiable, Valuable, Estimatable, Small and Testable)
Segundo Wake (2003) e Guide Alliance (2015), uma história bem escrita
obedece às características do acrônimo INVEST, se a história não cumprir algum
destes critérios, a equipe pode considerar sua reformulação ou até mesmo a
reescrita.
A seguir esta o detalhamento do acrônimo:
Independente (I): a história do usuário deve ser autossuficiente, de uma
forma que não há nenhuma dependência inerente em outra história de
usuário.
Negociável (N): enquanto fizer parte da iteração, ela pode sempre ser
alterada e reescrita.
Valioso (V): uma história usuário deve fornecer um valor para o usuário
final.
Estimável (E): a equipe deve sempre ser capaz de estimar o tamanho de
uma história de usuário.
Pequeno (S): não deve ser tão grande.
28
Testável (T): a história de usuário ou a descrição relacionada deve
fornecer as informações necessárias para tornar possível o
desenvolvimento teste.
GPM (Goal Preference Model)
GPM é uma prática que tem como objetivo auxiliar na priorização de metas.
Nesse processo, os stakeholders atribuem um valor inteiro para cada meta descrita
em um a lista, denominada de lista inicial de metas. Esse valor representa o grau
preferencia de prioridade de cada meta. Cada meta é analisada individualmente e
além da atribuição do valor, os stakeholders devem descrever as razões para tal
pontuação (SEM et al., 2010; SEM e HEMACHANDRAN, 2010).
A Prioridade da meta é calculada através do somatório dos valores atribuídos
pelos stakeholders para cada meta e, em seguida, é realizada uma ordenação
ascendente.
Use Case
Um caso de uso especifica uma sequência de interação entre um sistema e um
ator externo incluindo variantes e extensões que o sistema pode executar. Um
conjunto de casos de uso devem descrever as possíveis interações que serão
apresentadas nos requisitos do sistema, cada caso de uso representa uma visão
orientada ao usuário de um ou mais requisitos funcionais do sistema.
Os casos de uso são uma técnica baseada em cenário de UML que identificar
os agentes uma interação, e que descrevem a interação em si. Um conjunto de casos
de uso deve descrever todas as possíveis interações com o sistema.
Wall
A maior razão para a utilização da parede para exibição dos cartões é a
agilidade que ela proporciona à equipe. A parede de cartões melhora a comunicação
da equipe, o compartilhamento de informações, a remoção de impedimento e a
tomada de decisões.
A ideia básica da parede de cartões é de ter o fluxo de trabalho visível na
própria parede. O objetivo principal é dar a todos os membros da equipe de uma visão
compartilhada do trabalho atualmente em execução. A parede de cartões ajuda na
auditoria e reajustes de planejamento.
29
Documento de Requisitos
O documento de requisitos de software é a declaração oficial do que é
exigido dos desenvolvedores do sistema. Ela deve incluir uma definição das
necessidades dos utilizadores e uma especificação dos requisitos do sistema. Ele
deve descrever o que o sistema deve fazer, mas não como ele deve fazê-lo.
Task (Tarefas)
São unidades menores das histórias de usuário. Durante a o sprint planning, os
itens do backlog que serão desenvolvidos na Sprint são escolhidos. Em seguida
esses itens são quebrados em unidades menores, o que é denominado de Tasks. A
história não está completa até que todas as suas tarefas estiverem concluídas.
Scenarios
É uma forma de levar as pessoas a imaginarem o comportamento de um
sistema. Através de exemplos práticos descritivos do comportamento de um sistema,
os seus usuários podem comentar acerca do seu comportamento e da interação que
esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a
qualquer tipo de sistema. Scenarios são exemplos reais de como um sistema pode
ser usado, o que geralmente proporciona uma melhor compreensão dos stakeholders.
Personas
Persona é uma técnica de usabilidade, que consiste na criação de perfis e
personificação de grupo de usuários, ou seja, representa uma caracterização de um
personagem que, embora seja fictício, expõem às características importantes da
população de usuários para a qual se destina o produto o projeto (ADLIN, 2006).
2.4. Trabalhos Relacionados
Nesta seção são apresentados os trabalhos relacionados com esta pesquisa,
que foram encontrados durante a revisão da literatura tradicional realizada de forma
ad hoc.
30
2.4.1. Desafios de Requisitos em Método Ágeis: Uma Revisão
Sistemática (Jaqueira et al. 2012).
Jaqueira (2012) realizou uma revisão sistemática para investigar os desafios
dos requisitos nos métodos ágeis. Esta pesquisa levantou os principais trabalhos
acadêmicos, conferências e workshops que apontaram e discutiram os desafios dos
requisitos nos métodos ágeis no período de 2008 a 2012. A seguir será descrito de
forma resumida o procedimento de coleta dos dados utilizado.
Questões de Pesquisa
Este estudo teve como objetivo responder as seguintes questões de pesquisa:
Q1 – Quais as conferências e workshops publicam sobre métodos ágeis e
que podem trazer discussões sobre requisitos ágeis?
Q2 – Existem desafios apontados para requisitos em métodos ágeis? Quais?
Q3 – O que está sendo proposto para tratar os desafios de requisitos em
métodos ágeis?
Q3.1 – Existem adaptações e/ou extensões das práticas ágeis para tratar os
desafios de requisitos? Quais?
Q3.2 – Existem adaptações e/ou extensões de práticas de métodos
tradicionais que são usadas em métodos ágeis? Quais?
Estratégia de Busca
As buscas foram realizadas em artigos publicados entre 2008 e 2012
combinando buscas automáticas e manuais. As buscas automáticas foram realizadas
em ACM Digital Library, IEEEXplore Digital Library, Science Direct, ISI Web of
Science e Scopus. E as buscas manuais foram realizadas para as conferências Agile
Conference, Agile Brazil, International Requirements Engineering Conference (RE),
Empirical Software Engineering and Measurement (ESEM) e Evaluation and
Assessment in Software Engineering (EASE) e no Workshop on Requirements
Engineering (WER).
A string de utilizada na busca automática foi:
(“Requirements Engineering” AND “Agile methods”) OR (“Agile requirements”).
31
Após a execução das buscas manuais e automáticas, os resultados foram
agrupados, as duplicações removidas e assim formou-se a lista de estudos
potencialmente relevantes que seguiram para a próxima etapa estudo.
Seleção dos Estudos
O procedimento adotado para seleção desta pesquisa foi dividido em duas
etapas. Na primeira etapa, foram realizadas as leituras dos títulos, resumos e
palavras-chave e em seguida foram aplicados os critérios de inclusão e exclusão. A
inclusão foi dada pela relevância dos trabalhos em relação às questões investigadas.
Os critérios de inclusão utilizados foram:
O artigo menciona explicitamente requisitos em métodos ágeis;
O artigo menciona problemas com requisitos em métodos ágeis;
O artigo menciona contribuições (extensões ou adaptações em metodologias)
para tratar requisitos em métodos ágeis;
O estudo usado no artigo é empírico com métodos ágeis.
O critério de exclusão adotado foi:
Estudos incompletos como resumos ou apresentação de slides.
Quando ocorreu dúvida ou conflito foi realizada a leitura plena do artigo e
discutida sua relevância entre os pesquisadores até chegar a um consenso. Ao final,
um conjunto de artigos foi selecionado para a segunda etapa, a de leitura integral.
Após a leitura os dados foram analisados objetivando responder as questões de
pesquisa deste estudo.
Jaqueira (2012) apresenta uma revisão sistemática sobre requisitos em
métodos ágeis, mas tem um propósito diferente do deste pesquisa, apresentando
apenas um ponto de convergência que é quanto aos desafios da ER em projetos
ágeis. Além disso, a revisão possui algumas limitações, como a não realização da
avaliação de qualidade e a ausência do detalhamento do método de extração dos
dados. A revisão selecionou apenas 9 artigos e não apresenta uma síntese dos
resultados.
32
Os resultados de jaqueira que estão em consonância com esta pesquisa serão
descritos e comparados na sessão 5.1 deste trabalho.
2.4.2. Benefícios e Limitações das Metodologias Ágeis no
Desenvolvimento de Software (Kamei 2012).
Kamei (2012) realizou uma revisão sistemática da literatura para identificar o
que atualmente se sabe sobre os benefícios e limitações das metodologias ágeis de
desenvolvimento de software através de estudos empíricos apresentados na
literatura. A seguir será descrito de forma resumida o procedimento de coleta dos
dados utilizado.
Questões de Pesquisa
Com o objetivo de identificar resultados de pesquisas, práticas e aplicações
com o uso das Metodologias Ágeis, esta revisão possui as seguintes questões de
pesquisa:
Q1: O que atualmente se sabe sobre os benefícios e limitações das
metodologias ágeis de desenvolvimento de software?
Q2: Quais são as forças das evidências que suportam os resultados
encontrados?
Q3: Quais são as implicações desses estudos para a indústria de software e a
comunidade de pesquisa?
Para conduzir as buscas pelos estudos, foram utilizadas fontes de busca
automática e manual. A busca automática foi realizada a partir da definição de uma
String de busca, derivada da questão principal da pesquisa. A seguir é a apresentada
a String de busca:
("agile" or "agility" or "scrum" or "extreme programming" or "xp" or "dynamic
system development" or "dsdm" or "crystal clear" or "crystal orange" or "crystal red" or
"crystal blue" or "feature driven development" or "fdd" or "lean software development"
or "adaptive software development" or "asd" or "test driven development" or "tdd") and
("software development" or "software engineering" or "information system
development" or "information system engineering" or "software production")
33
As buscas automáticas foram realizadas em ACM Digital Library, El
Compendex, IEEE Xplore, ISI Web of Science, ScienceDirect – Elsevier, Scopus,
SpringerLink e Wiley Inter Science Journal Finder. As buscas manuais foram
realizadas em Agile Development Conference, XP Conference, ACM Transactions on
Software Engineering and Methodology, Empirical Software Engineering, IEEE
Software, IEEE Transactions on Software Engineering e Journal of the ACM.
Seleção dos Estudos
Todos os estudos retornados do processo de busca foram avaliados com base
em critérios de inclusão e exclusão. Para que um estudo fosse incluído, o mesmo
deveria atender os seguintes critérios de inclusão:
Apenas estudos primários;
Estudos que apresentam dados empíricos;
Estudos acadêmicos e da indústria serão incluídos;
Apenas estudos que apresentaram dados empíricos sobre desenvolvimento
ágil de software;
Estudos de pesquisa qualitativa e quantitativa;
Os estudos que apresentam dados em formato científico;
Apenas estudos escritos em Inglês;
Estudos publicados entre 2006 e 2010;
Os artigos completos, publicados em uma revista ou conferência.
E para que fosse excluído, bastava se enquadrar em apenas um dos critérios
de exclusão descritos a seguir:
Estudos cujo foco não era desenvolvimento ágil de software;
Estudos que não apresentaram dados empíricos;
Estudos que incidiu sobre técnicas ou práticas individuais, tais como
programação em pares, testes unitários ou refactoring;
Estudos com apenas lições aprendidas;
Os trabalhos meramente com base na opinião de especialistas;
Editoriais, prefácios, resumos de artigos, entrevistas, notícias, comentários,
correspondência, debates, comentários, cartas e resumos de tutoriais,
workshops , painéis e sessões de pôsteres do leitor;
34
Estudos acadêmicos que se concentram em ensinar métodos ágeis;
Estudos que não respondem a nossa primeira questão de pesquisa;
Estudo duplicado, sem nenhuma informação extra.
Os critérios foram aplicados em dois estágios: o primeiro com base na leitura
do Título e Abstract. E no segundo, com base na leitura da Introdução, Conclusão e
Metodologia, e em casos onde não ficou claro o entendimento sobre o estudo, a
leitura completa foi efetuada sobre o mesmo.
Avaliação de qualidade
Todos os estudos incluídos na etapa anterior foram avaliados quanto a sua
qualidade metodológica com base em 10 critérios:
1) Existe uma descrição clara dos objetivos da pesquisa?
2) Existe uma descrição adequada do contexto em que a pesquisa foi realizada?
3) O desenho de pesquisa foi adequado para atender os objetivos da pesquisa?
4) A estratégia de seleção foi adequada aos objetivos da pesquisa?
5) Havia um grupo de controle com o qual comparar tratamentos?
6) Os dados foram coletados de uma forma que abordou a questão de pesquisa?
7) A análise dos dados foi suficientemente rigorosa?
8) A relação entre pesquisador e participantes foi considerada de uma forma
adequada?
9) Existe uma declaração clara dos resultados?
10) É o estudo de valor para a investigação ou a prática?
Extração e Análise dos dados
Durante a extração, foram utilizados os procedimentos de codificação aberta
para identificar os conceitos para responder a Q1. Em seguida, o procedimento de
codificação axial foi utilizado para reagrupar os dados, e entender como as categorias
e subcategorias se relacionam. Para a análise dos dados, foi utilizado o método da
Teoria Fundamentada em Dados.
A busca inicial resultou na identificação de 9845 estudos potencialmente
relevantes, ao decorrer da revisão sistemática, 9720 artigos foram excluídos, restando
35
assim 125 estudos primários que foram incluídos na revisão. Com base na análise
dos estudos incluídos, benefícios e limitações foram identificados e categorizados.
Kamei (2012) realizou uma revisão sistemática sobre metodologias ágeis de
desenvolvimento, apesar de não ter o propósito de investigar sobre requisitos,
apresenta algumas limitações relacionadas à execução da ER em projetos ágeis. Os
resultados estão em consonância com esta pesquisa serão descritos e comparados
na sessão 5.1 deste trabalho.
2.5. Considerações finais do capítulo
Este capítulo apresentou os conceitos e fundamentos teóricos usados como
base para esta pesquisa. Este referencial envolveu os conceitos sobre requisitos,
engenharia de requisitos e algumas técnicas de elicitação e especificação de
requisitos. Além disso, também foram abordados os conceitos de metodologias ágeis,
seus valores e princípios, engenharia de software baseada em evidências,
demostrando os conceitos e a diferença entre revisões e mapeamento sistemático da
literatura e por fim foram descritos os trabalhos relacionados com esta pesquisa.
36
3. METODOLOGIA DA PESQUISA
Este capítulo descreve os métodos de pesquisa que foram utilizados neste
trabalho, objetivando tornar os resultados mais confiáveis, auditáveis e possíveis de
serem reproduzidos por outros pesquisadores.
3.1. Classificação da Pesquisa
Marconi e Lakatos (2008) relatam que um quadro metodológico bem
selecionado, confere mais rigor científico a uma pesquisa. Este trabalho é classificado
conforme quadro metodológico apresentado a seguir e detalhado posteriormente.
Quadro 1: Quadro metodológico
Método de abordagem Indutivo
Natureza dos dados Qualitativa
Quanto ao escopo Mapeamento Sistemático da Literatura
Método de procedimento Análise e Síntese Temática
Variáveis independentes
(X)
Engenharia de Requisitos
Metodologias Ágeis
Variáveis dependentes (Y) Técnicas/processos de levantamento e especificação
de requisitos.
Possíveis desafios e limitações.
Fonte: Elaboração Própria
Esta pesquisa optou por um método de abordagem indutiva, que segundo Marconi e
Lakatos (2003) é um processo mental por intermédio do qual, partindo de dados
particulares, suficientemente constatados, infere-se uma verdade geral ou universal,
não contida nas partes examinadas.
A indução realiza-se em três etapas:
Observação dos fenômenos, com a finalidade de descobrir as causas de
sua manifestação;
Descoberta da relação, por intermédio da comparação, com a finalidade de
descobrir a relação constante existente entre eles;
Generalização da relação entre os fenômenos e fatos semelhantes.
A natureza geral dos dados é qualitativa, mesmo considerando que alguns
resultados desta pesquisa sejam quantitativos. Para Marconi e Lakatos(2008), o
37
paradigma qualitativo preocupa-se em analisar e interpretar aspectos mais profundos,
descrevendo a complexidade do comportamento humano, fornecendo análises mais
detalhadas sobre as investigações, hábitos, atitudes, tendências de comportamento
etc.
O escopo da pesquisa envolveu um mapeamento sistemático da literatura, a
partir de artigos científicos primários e empíricos, para identificar, analisar, interpretar
e reportar todas as pesquisas relevantes disponíveis para responder uma questão de
pesquisa específica (KITCHENHAM ET AL., 2007).
Os métodos de procedimentos definidos para esta pesquisa é o de Análise e
Síntese Temática, para identificar os temas ou questões recorrentes em vários
estudos, com o objetivo de interpretar e explicar esses temas e fenômenos, para tirar
conclusões em resultados de revisões sistemáticas (CRUZES e DYBA, 2011).
Segundo Marconi e Lakatos (2008), as variáveis de um trabalho podem ser
consideradas independentes ou dependentes. As independentes determinam a
condição ou causa para um resultado, afetando ou determinando as variáveis
dependentes. Neste conceito, as variáveis independentes são engenharia de
requisitos e metodologias ágeis. As variáveis dependentes são técnicas/processos de
levantamento e especificação de requisitos e os desafios e limitações da engenharia
de requisitos em projetos de desenvolvimento ágil.
3.2. Ciclo da Pesquisa
Este tópico apresenta o ciclo desta pesquisa, com suas principais etapas e
descrições, conforme mostrado na Figura 1.
Figura 1: Ciclo de desenvolvimento da pesquisa
Fonte: Elaboração Própria
(1) Revisão da Literatura: foi realiza uma revisão da literatura tradicional de modo
adhoc em artigos e livros objetivando buscar conceitos da engenharia de requisitos
em ambientes ágeis de desenvolvimento de software. Nesta etapa foram
38
identificadas lacunas na teoria atual e surgiu a necessidade execução de um
mapeamento sistemático sobre o problema de pesquisa.
(2) Planejamento da pesquisa: nesta etapa iniciou o delineamento das questões de
pesquisa, o planejamento e a elaboração do protocolo do mapeamento sistemático
da literatura como instrumento de coleta de dados.
(3) Coleta de dados: realizaram-se as fases do protocolo do mapeamento sistemático
da literatura.
(4) Análise dos dados: de posse dos dados coletados, iniciou-se a análise e
interpretação dos dados com o objetivo de responder as questões de pesquisa.
(5) Consolidação dos dados: essa última etapa os dados foram consolidados, as
contribuições, limitações e trabalhos futuros foram apresentadas finalizando com a
elaboração de um relatório final.
3.3. Procedimento de Coleta de dados
De acordo com Arksey e O'Malley (2005) o arcabouço metodológico de um
estudo de mapeamento sistemático é apoiado na mesma visão de uma revisão
sistemática, no sentido de ser conduzido de maneira auditável, rigorosa e
transparente. Os procedimentos metodológicos utilizados para planejar e executar
esse mapeamento foram baseados nas diretrizes de Kitchenham et al., (2004, 2007),
Dybâ et al., (2007) e Travassos(2007).
3.3.1. Protocolo do Mapeamento Sistemático
Este item apresenta uma versão resumida do protocolo utilizado na condução
do mapeamento sistemático. Este protocolo descreve o processo e os métodos que
serão aplicados na pesquisa sistemática (DYBA et al., 2008). Ele é, portanto, o
artefato chave da pesquisa, e precisa ser pré-definido para reduzir a possibilidade de
viés por parte do pesquisador e para tornar o processo passível de replicação
externa. A versão completa pode ser visualizada no APÊNDICE A.
39
Questões de Pesquisa
Este estudo visa responder como a engenharia de requisitos tem sido
conduzida em projetos que adotam metodologias ágeis para desenvolvimento de
software?
Para facilitar a extração, análise e síntese dos resultados, as seguintes
questões de pesquisa específicas (QPE) foram elaboradas:
QPE1: Quais as técnicas\processos de engenharia de requisitos estão sendo
utilizadas em projetos que adotam metodologias ágeis com objetivo de levantar
requisitos?
QPE2: Quais as técnicas\processos de engenharia de requisitos estão sendo
utilizadas em projetos que adotam metodologias ágeis com objetivo de
especificar requisitos?
QPE3: O que atualmente se sabe sobre os desafios e limitações das técnicas
de engenharia de requisitos adotadas em projetos ágeis?
QPE4: Quais boas práticas/sugestões podem minimizar os efeitos desses
desafios e limitações encontrados?
QPE5: Quais as implicações, para a indústria de software e para a comunidade
acadêmica, dos atuais estudos que envolvem a engenharia de requisitos em
Projetos ágeis?
Estratégia de Busca
Foram utilizadas fontes de busca automáticas e manuais na execução da
estratégia de seleção dos estudos. A busca automática foi realizada a partir da
definição de uma string de busca, derivada das de palavras-chave das questões de
pesquisa mais seus sinônimos ou palavras derivadas, concatenados por meio dos
operadores booleanos “OR” e “AND”.
As palavras-chave extraídas da questão de pesquisa principal foram:
Requisitos, Metodologias Ágeis e Software. Objetivando retornar um maior número de
artigos, os termos utilizados para a construção da string foram os mais abrangentes
possíveis, motivo pelo qual não foi utilizada a técnica PICO. A seguir é apresentada a
string derivada:
((“requirements” OR “use case” OR “use cases” OR “user stories”) AND
(“agile” OR “agility”) AND (“scrum” OR “extreme programming” OR “xp” OR
40
“dynamic system development” OR “dsdm” OR “crystal methodologies” OR “crystal
clear” OR “crystal orange” OR “crystal red” OR “crystal blue” OR “feature driven
development” OR “fdd” OR “lean software development” OR “adaptive software
development” OR “test driven development” OR “tdd”) AND (“software” OR
“information system development” OR “information system engineering” ) )
Fontes de Busca
Para a seleção dos estudos foram utilizadas fontes de busca automática e
manual. As fontes automáticas utilizadas foram: IEEEXplore Library, ACM Library,
ScienceDirect, SpringerLink e Scopus e as buscas manuais foram a International
Requirements Engineering e a Agile Development.
Critérios de Inclusão (CI) e Exclusão (CE)
Para a escolha dos estudos primários, foram aplicados os critérios de inclusão
(CI) e de exclusão (CE) descritos a seguir:
CI1. Estudos que tratem sobre requisitos em projetos de Software que utilizam
metodologias ágeis;
CI2. Estudos aplicados na indústria;
CI3. Pesquisas qualitativas ou quantitativas;
CI4. Estudos primários.
CE1. Escrito em um idioma que não seja o Inglês;
CE2. Estudos duplicados ou repetidos;
CE3. Estudos que não tratem de elicitação, especificação e modelagem de
requisitos de software;
CE 4. Estudos incompletos, rascunhos, slides ou resumos;
CE5. Estudos terciários e meta-análises;
CE6. Estudos acadêmicos que tratem do ensino de métodos ágeis;
CE7. Estudos que não abordem pelo menos uma metodologia ágil;
CE8. Artigos que não estão disponíveis gratuitamente para download nos
ambientes institucionais do CIn/UFPE ou do IFPB;
CE9. Estudos teóricos que não apresentam nenhum tipo de validação.
41
Seleção dos Estudos
A seleção dos Estudos foi realizada em 4 (quatro) fases. Na primeira fase, a
busca automática foi realizada a partir da ferramenta Reviewer1, que executou a string
em todos os engenhos simultaneamente. O resultado da busca foi exportado para
uma planilha Excel, a partir de onde foram realizadas as etapas seguintes. Em
seguida foi realizada a busca manual onde alguns estudos relevantes foram
acrescentados, formando assim a base de dados inicial deste estudo.
Na segunda fase, os títulos e resumos foram lidos e os critérios de inclusão e
exclusão foram aplicados. Em caso de dúvida sobre a relevância do estudo, o mesmo
era incluído para ser analisado nas etapas seguintes.
Na terceira fase, os critérios foram aplicados com base na leitura da introdução
e conclusão dos estudos resultantes da segunda fase. Quando necessário, a leitura
completa do estudo foi efetuada.
Com objetivo de diminuir o viés da pesquisa, os estudos analisados na
segunda e na terceira fase foram divididos entre duas duplas de pesquisadores. Uma
vez identificado algum conflito dentro de uma dupla, o mesmo foi discutido com os
membros da outra dupla procurando resolver o impasse.
Na quarta fase, os estudos resultantes da terceira fase foram lidos por
completo para aplicação da avaliação de qualidade. Os artigos foram avaliados por
dois pesquisadores, as respostas dos questionários foram tabuladas de tal forma que
foi possível que os membros pudessem comparar e discutir as respostas e entrar em
um consenso. Os artigos com somatório classificado nas faixas Média, Alta e Muito
Alta foram encaminhados para extração, os demais foram descartados nesta etapa.
Avaliação da Qualidade
Após seleção dos estudos relevantes, foi realizada uma avaliação de qualidade
baseada na aplicação dos seguintes critérios de qualidade (CQ):
CQ1: É um artigo de pesquisa?
CQ2: Existe uma descrição clara dos objetivos da pesquisa?
CQ3: Existe uma descrição adequada do contexto em que o estudo foi
realizado?
1 Reviewer (https://github.com/bfsc/reviewer)
42
CQ4: O desenho de pesquisa foi adequado para atender os objetivos da
pesquisa?
CQ5: A estratégia de seleção da amostragem foi adequada aos objetivos da
pesquisa?
CQ6: Os dados foram coletados de maneira adequada a responder as
questões de pesquisa?
CQ7: A análise dos dados foi suficientemente rigorosa?
CQ8: A relação entre os pesquisadores e os participantes foi considerada de
forma adequada?
CQ9: Há uma descrição clara dos resultados?
CQ10: O estudo possui valor para a academia ou para a indústria?
Cada critério recebeu uma pontuação que foi definida a partir da escala de três
pontos de Likert. Quando não existia nada no artigo que atenda ao critério avaliado,
deveria ser aplicada a nota 0. Quando o artigo não deixa claro se atende ou não ao
critério, deve ser aplicada a nota (0,5). E quando o artigo atende ao critério avaliado
deve ser aplicada a nota 1.
A partir do somatório das notas de todos os critérios, os artigos foram
classificados em 4 faixas de qualidade de acordo coma pontuação obtida, conforme
podemos verificar no quadro 2. Os artigos com somatório classificado nas faixas
Média, Alta e Muito Alta foram encaminhados para extração, os demais foram
descartados nesta etapa.
Quadro 2: Distribuição da pontuação por faixa de qualidade
Baixa Média Alta Muito Alta
0 ≤ N ≤ 2,5 3 ≤ N ≤ 5,5 6 ≤ N ≤ 8,5 9 ≤ N ≤ 10 Fonte: Elaboração própria
A classificação das faixas de qualidade e a definição da faixa que seria
excluída foram analisadas e definidas pelos pesquisadores que participaram deste
mapeamento sistemático.
Extração e Análise dos dados
Os estudos que passaram na fase de qualidade passaram para a fase de
extração estruturada dos dados de publicação (referência), contexto (tipo de estudo,
métodos de pesquisa, análise dos dados, tamanho da amostra, método ágil) e
43
evidências (trechos de texto) objetivando responder as questões de pesquisa,
conforme sugerido por Cruzes e Dyba (2011). Também, houve uma extração de
dados por amostragem desenvolvida por outro pesquisador para comparação,
visando reforçar a validade dos resultados desta fase.
Síntese dos dados
Conforme orientações de Cruzes e Dyba (2011), este estudo realizou uma
síntese e análise temática dos dados. O processo resumido consistiu em fazer uma
leitura inicial dos estudos identificando os seguimentos de texto específico. Devido a
grande quantidade de seguimentos identificados, foi realizada uma compilação que
agrupou esses seguimentos de texto específico em códigos de texto específico
conforme orientação na figura 2.
Em seguida, estes códigos de texto foram classificados em temas e depois
classificados novamente em temas de ordem superior conforme podemos verificar na
Figura 2.
Figura 2: Processo de síntese temática
Fonte: Cruzes e Dyba (2011).
3.4. Limitações e Ameaças à Validade
Uma limitação comum dos mapeamentos sistemáticos é encontrar todos os
artigos relevantes existentes. Para minimizar esse problema, foram utilizadas
múltiplas fontes de dados, sendo elas automáticas e manuais. Dentre as automáticas,
estão os quatro principais engenhos de busca automática da área de engenharia de
software citados por Kitchenham el al., (2007) e Dyba e Dingsøyr, (2008).
44
Para evitar viés na seleção dos estudos, foram realizadas reuniões e/ou testes
pilotos antes de iniciar as etapas da pesquisa e estas foram conduzidas por mais de
um pesquisador. Quando houve divergências de opiniões entre os pesquisadores,
estas foram confrontadas e resolvidas com a participação de terceiro pesquisador e
do professor orientador.
Este estudo não considerou artigos publicados em 2014, pois o mapeamento já
estava em curso. Aproximadamente 6% de artigos selecionados não puderam ser
analisados tendo em vista que não estavam disponíveis para download gratuitamente
na rede do CIN\UFPE e não tivemos êxito nas tentativas de obter os artigos
diretamente com os autores. Sendo assim, é possível que algum artigo relevante
tenha deixado de ser incluído para ser analisado.
3.5. Considerações finais do capítulo
Com o intuito de tornar os resultados mais confiáveis, auditáveis e
reprodutíveis, este capítulo apresentou a metodologia utilizada nesta pesquisa. Foram
descritos a classificação da pesquisa, o ciclo da pesquisa e os procedimentos de
coleta de dados. Foi realizado também o detalhamento do protocolo de coleta de
dados, onde então descritos as questões de pesquisa, as estratégias e de fontes e de
busca, o processo utilizado para a seleção dos estudos finais, a avaliação de
qualidade que foi aplicada e os detalhes da extração, análise e síntese dos dados.
45
4. RESULTADOS
Este capítulo apresenta os resultados obtidos no mapeamento sistemático da
literatura, onde são apresentados e analisados com o objetivo de responder as
questões de pesquisa deste trabalho.
4.1. Resultados dos Procedimentos de Busca e seleção
Nesta subseção são apresentados os procedimentos executados para
obtenção dos resultados desta revisão.
4.1.1. Equipe Envolvida
Para a condução desta pesquisa, foram envolvidos 4 pesquisadores, sendo
três estudantes de pós-graduação (um doutorando e dois mestrandos) em Ciências
da Computação e um professor orientador que auxiliou durante todo o processo.
Segundo Dyba e Dingsoyr (2008), deve-se ter cuidado com o viés introduzido
pelos pesquisadores na seleção dos estudos. Para reduzir essa possibilidade de viés,
todas as etapas da revisão foram conduzidas envolvendo no mínimo uma dupla de
pesquisadores.
4.1.2. Execução
O mapeamento sistemático foi conduzido seguindo o protocolo apresentado
resumidamente no capítulo 3 e disponível por completo no APÊNDICE A. Os
resultados de cada etapa da condução são descritos nas próximas subseções.
4.1.2.1. Etapa 1: Busca Automática e Manual
Após as definições da string de busca, das fontes de pesquisa e dos demais
critérios definidos no protocolo, a string busca foi executada simultaneamente e de
forma automática em todos os engenhos através da ferramenta Reviewer.
Os estudos retornados pela ferramenta e suas referências foram armazenados
em planilha compartilhada do Microsoft Excel™. Além disso, cada estudo recebeu um
identificador único para facilitar a comunicação entre os pesquisadores.
A partir das buscas primárias, foram retornados 2852 estudos, dos quais 2501
são provenientes da busca automática nos engenhos eletrônicos e 351 identificados
46
pela busca manual. Conforme podemos observar na figura 03, dos 2501 artigos da
busca automática, 41%(1174) são da ACM Digital Library, 26%(748) do
ScienceDirect, 9%(259) da SpringerLink, 8%(219) no Scopus e 4%(101) do IEEE
Xplore.
Figura 3: Resultado da busca automática e manual
Fonte: Elaboração própria
Ainda de acordo com a figura 3, dos 351 estudos provenientes na busca
manual, 6%(173) foram originados da Agile Development Conference(AGILE),
6%(171) da International Requirements Engineering Conference(REC) e 0,2%(7)
através da técnica de snowballing, que segundo Wohlin (2014), refere-se à utilização
da lista de referências ou das citações de um artigo para identificar artigos adicionais.
4.1.2.2. Etapa 2: Seleção dos estudos pelo Título e Abstract
Os estudos foram divididos igualmente entre dois pares de pesquisadores, que
efetuaram a leitura do Título e Abstract. Apenas os estudos considerados fora da área
de pesquisa foram excluídos, em caso de dúvida sobre a relevância do estudo, o
mesmo era incluído para ser analisado nas etapas seguintes. Assim, do total de
estudos identificados, restaram 312 estudos potencialmente relevantes.
Na próxima seção são apresentados os resultados da segunda etapa da
seleção dos estudos, com base na leitura da introdução e conclusão dos estudos.
ACM 41%
IEEE 4%
SCIENCE_DIRECT 26%
SCOPUS 8%
SPRINGER_LINK 9%
AGILE 6%
REC 6%
SNOWBALLING 0%
47
4.1.2.3. Etapa 3: Seleção dos Estudos pela Introdução e
Conclusão
Os 312 estudos potencialmente relevantes foram divididos novamente entre
duas duplas para serem aplicados os critérios de inclusão e exclusão descritos na
seção 3.3.1 deste trabalho. Esses critérios foram aplicados de forma independente,
quando não foi possível aplicar os critérios baseando-se na leitura da introdução e da
conclusão, a leitura integral foi realizada.
Para cada desacordo identificado entre as duplas, os mesmos discutiram para
tentar chegar a um consenso. Assim, do total de estudos identificados, restaram 81
estudos potencialmente relevantes.
4.1.2.4. Etapa 4: Avaliação de Qualidade
Objetivando nivelar os conceitos dos pesquisadores, no início desta etapa foi
realizada uma reunião sobre os critérios de qualidade e como eles deveriam ser
aplicados. Os 81 estudos relevantes originados da etapa anterior foram distribuídos
entre dois pesquisadores para que fosse realizada a leitura completa de cada estudo
e aplicada à avaliação de qualidade, ambos de forma independente.
Após a leitura completa dos artigos, os pesquisadores se reuniram e
verificaram que 50 artigos deveriam ter sido excluídos em etapas anteriores, restando
assim 31 artigos para a realização da avaliação de qualidade. Após a aplicação da
avaliação, os dados dos dois pesquisadores foram tabulados e comparados. Os
conflitos foram discutidos em reunião e após consenso ficou decidido que 22% (7)
artigos deveriam ser excluídos devido a baixa qualidade. Assim, restaram 24 artigos
que foram classificados pela seguinte faixa de qualidade: média, alta e muito alta.
Conforme podemos observar na figura 4, 38%(9) estudos foram classificados
com qualidade Média, 50% (12) com qualidade Alta e 12% (3) com qualidade Muito
alta. Essa pontuação foi obtida através do somatório da aplicação dos critérios de
qualidade.
48
Figura 4: Distribuição dos estudos por classificação de qualidade
Fonte: Elaboração própria
A Figura 5 apresenta o total da pontuação obtida nos seguintes critérios da
avaliação de qualidade:
CQ1 - É um artigo de pesquisa?
CQ2 - Existe uma descrição clara dos objetivos da pesquisa?
CQ3 - Existe uma descrição adequada do contexto em que o estudo foi
realizado?
CQ4 - O desenho de pesquisa foi adequado para atender os objetivos da
pesquisa?
CQ5 - A estratégia de seleção da amostragem foi adequada aos objetivos da
pesquisa?
CQ6 - Os dados foram coletados de maneira adequada a responder as
questões de pesquisa?
CQ7 - A análise dos dados foi suficientemente rigorosa?
CQ8 - A relação entre os pesquisadores e os participantes foi considerada de
forma adequada?
CQ9 - Há uma descrição clara dos resultados?
CQ10 - O estudo possui valor para a academia ou para a indústria?
Ainda de acordo com figura 5, é possível perceber que os critérios Q5, Q6 ,Q7
e Q8 tiveram as menores pontuações no somatório da avaliação da qualidade.
Muito Alta 12%
Alta 50%
Média 38%
49
Figura 5 : Pontuação por Critério de Qualidade
Fonte: Elaboração própria
Analisando melhor esses critérios que obtiveram as menores avaliações de
qualidade, podemos verificar na figura 6 o total de notas 0,0 (não existe nada no
artigo que atenda ao critério avaliado), 0,5 (o artigo não deixa claro se atende ou não
ao critério) e 1,0 (o artigo atende ao critério avaliado) recebidas por cada critério.
Conforme figura 6, que o critério de qualidade 5 (Q5), que objetiva verificar se a
estratégia de seleção da amostra foi adequada aos objetivos da pesquisa, obteve
25% (6) estudos com nota igual a 0 (zero), ou seja, eles não relataram como foi
realizada a estratégia de seleção da amostragem, dificultando assim o entendimento
se tamanho da amostra foi suficiente ou como as pessoas e os casos foram
selecionados.
No critério de qualidade 6 (Q6), que analisa se a coleta dos dados foi feita de
forma adequada para responder as questões de pesquisa, mostrou que 37,5% (9) dos
estudos não relataram como foi feita a coleta dos dados. Não deixando claro,
portanto, como os dados foram coletados e se foram utilizados critérios de qualidade
para coleta-los.
O critério de qualidade 7 (Q7) obteve 41,6% (10) de estudos que não
atenderam ao critério, eles não descreveram como foi realizada a análise dos dados.
Por fim, o critério (Q8), que está relacionado à reflexividade do pesquisador,
apresentou 87,5% (21) estudos que não relataram sobre os potenciais vieses da
pesquisa, suas ameaças à validade ou as limitações da pesquisa.
20
15,5
22
15,5
13,5 13,5
11
2
16
23
CQ1 CQ2 CQ3 CQ4 CQ5 CQ6 CQ7 CQ8 CQ9 CQ10
50
Figura 6: Quantidade por nota baixa
Fonte: Elaboração própria
4.1.1.1. Etapa 5: Extração dos dados
A partir dos estudos resultantes da etapa anterior, foi realizada a extração dos
dados de publicação, contexto e evidências, conforme orientação de Cruzes e Dyba
(2011). Não foi necessário excluir nenhum artigo nessa etapa, portanto os 24 estudos
relevantes foram a base para realização da síntese e análise temática dos dados. Os
estudos relevantes e os dados extraídos estão detalhados nos APÊNDICES B e C.
4.1.1.2. Resumo da Execução da Estratégia de Busca
A partir das buscas automáticas e manuais foram encontrados 2852 estudos. A
Figura 7 apresenta a quantidade de estudos resultantes por etapa. 2540 estudos
foram excluídos na fase de seleção por título e resumo, restando então 312 estudos
potencialmente relevantes.
Na fase de seleção por introdução e conclusão foram aplicados os critérios de
inclusão e exclusão e, após leitura e consenso, foram excluídos 231 estudos,
restando 81.
Os estudos restantes da fase anterior foram lidos por completo e feita avaliação
de qualidade. Nesta etapa, 50 estudos foram excluídos após leitura total porque foi
constatado que eles deveriam ter sido excluídos em etapas anteriores. E 7 estudos
foram excluídos devido à baixa qualidade, restando assim 24 estudos para a extração
dos dados, onde nenhum estudo foi excluído.
CQ5 CQ6 CQ7 CQ8
Qtd que atenderam o critério(Nota 1,0)
9 12 8 1
Qtd que atenderam parcialmeteo critério (Nota 0,5)
9 3 6 2
Qtd que não atenderam oCritério (Nota 0,0)
6 9 10 21
0
5
10
15
20
25
51
Dos 24 artigos selecionados, 20 foram provenientes da busca automática, 3
provenientes do uso da técnica snowballing e 1 oriundo da busca manual realizado
nas conferências.
Figura 7: Estudos selecionados por etapa
Fonte: Elaboração própria
4.1.3. Visão geral dos estudos
Após a realização da fase de extração nos 24 estudos, verificou-se que a maior
parte dos estudos foram publicados nos últimos anos, conforme ilustrado na figura 8,
reforçando assim a relevância deste assunto.
52
Figura 8: Distribuição temporal dos estudos primários
Fonte: Elaboração própria
Em relação à metodologia ágil utilizada, verificamos que, conforme figura 9,
96% dos estudos utilizaram Scrum ou XP, essas evidências estão em consonância
com os achados das pesquisas em Dyba e Dingsoyr (2008) e Kamei (2012).
Figura 9: Distribuição dos estudos por metodologia
Fonte: Elaboração própria
Foram identificados 6 métodos de pesquisa nos estudos primários conforme
mostra a figura 10. Estudo de Caso foi o método de pesquisa mais utilizado tendo
sido relatado em 12 estudos, sendo que em 3 destes foi utilizado em conjunto com
outros métodos. Etnografia, Experimento, Grounded Theory e Pesquisa Ação também
foram reportados.
1 1 1
3
1
3 3
7
4
2004 2006 2007 2008 2009 2010 2011 2012 2013
SCRUM 53%
XP 43%
FDD 4%
53
Figura 10: Distribuição dos estudos por método de pesquisa
Fonte: Elaboração própria
Em relação aos países envolvidos, os Estados Unidos destacou-se com 7
artigos. Os outros 17 artigos estão distibuidos entre 12 outros países conforme
podemos observar na figura 11. Destacamos que nenhum artigo desta revisão foi do
Brasil, o que pode ser justificado pela aplicação do critério de exclusão - CE1, onde
foram excluídos todos os artigos escritos em idiomas que não seja o inglês.
Figura 11: Distribuição dos estudos por países
Fonte: Elaboração própria
4.1.4. Mapeamento das evidências
Nesta seção são apresentados os resultados da revisão organizados de acordo
com as questões de pesquisa.
12
1 2
1
3 2
6
2
1 1 1 1 1
2 2
1 1
2 2
7
54
QP1: Quais técnicas\processos de engenharia de requisitos estão sendo
utilizados com objetivo de levantar requisitos em projetos que adotam
metodologias ágeis?
O levantamento realizado resultou em um total de 6 estratégias para elicitar
requisitos em projetos que adotam alguma metodologia ágil, conforme podem ser
observadas na Figura 12. A realização de encontros com o cliente (Meetings) é
técnica mais utilizada. Além destas, foram citadas JAD, Grupo Focal, Brainstorm,
Questionários e Workshop como técnicas utilizadas para levantamento de requisitos.
Figura 12: Técnicas utilizadas para elicitar requisitos
Fonte: Elaboração própria
Conforme apresentado na Tabela 1, dos 24 Artigos Selecionados (AS), apenas
10 artigos [AS04, AS05, AS07, AS08, AS12, AS13, AS16, AS20, AS23 e AS24]
mencionaram sobre a técnica utilizada para levantar requisitos. Os artigos [AS05 e
AS20] destacaram-se por apresentar a utilização de técnicas diferentes. O [AS05]
relatou a utilização de Meetings, Questionários e Workshops. E o artigo [AS20]
descreveu a utilização de Meetings, JAD e Grupo Focal.
9
1 1
2
1 1
55
Tabela 1: Artigos X técnicas utilizadas para elicitar requisitos
ME
ET
ING
S
JA
D
GR
UP
O F
OC
AL
BR
AIN
ST
OR
M
QU
ES
TIO
NÁ
RIO
S
WO
RK
SH
OP
TOTA
L
AS04 X 1
AS05 X X X 4
AS07 X 1
AS08 X 1
AS12 X X 2
AS13 X 1
AS16 X 1
AS20 X X X 3
AS23 X 1
AS24 X 1
Total 9 1 1 2 1 1 Fonte: Elaboração própria
QP2: Quais técnicas/processos de engenharia de requisitos estão sendo
utilizados com objetivo de especificar requisitos em projetos que adotam
metodologias ágeis?
A tabela 2 apresenta o resultado do levantamento realizado sobre as técnicas
utilizadas para especificar requisitos nos projetos que adotam metodologias ágeis.
Segundo o levantamento, um total de 19 técnicas estão sendo utilizadas para
especificar requisitos. Conforme podemos verificar na Figura 13, as técnicas mais
utilizadas nos estudos foram User Stories, Protótipos, Features e Story Card cada um
com respectivamente 19,10, 9 e 7 ocorrências.
Figura 13: Técnicas utilizadas para especificar requisitos
Fonte: Elaboração própria
3
19
10
1
9 7
2 2 1 2 3 3 2 1 1 1 1 1 1
56
Apesar de 8 técnicas terem sido reportadas em apenas um artigo, as mesmas
foram contabilizadas por este estudo tendo em vista que apresentaram evidências
que foram validades empiricamente em projetos da indústria. Essas técnicas são:
XXM(eXtreme X-Machine), XSBD(eXtreme Scenario-Based Design), Diagrama de
Atividades, AUC(Agile Use Case), ALC(Agile Loose Case), ACC(Agile Choose Case),
INVEST (Independent, Negotiable, Valuable, Estimatable, Small and Testable) e
GPM(Goal Preference Model).
Conforme apresentado na Tabela 2, os 23 artigos selecionados mencionaram
sobre técnicas utilizadas para especificar requisitos. Os artigos [AS04, AS10 e AS15]
destacaram-se por apresentar a utilização de 5 técnicas cada um.
Tabela 2: Artigos X técnicas utilizadas para especificar requisitos
US
E C
AS
E
US
ER
ST
OR
IES
PR
OT
OT
IPO
XX
M
FE
AT
UR
E
ST
OR
Y C
AR
D
WA
LL
XS
BD
DIA
G.
AT
IV
DO
C R
EQ
.
TA
SK
SC
EN
AR
IOS
PE
RS
ON
AS
AU
C
AL
C
AC
C
MA
PA
S M
EN
TA
IS
INV
ES
T
GP
M
TO
TA
L
AS01 X X X 3
AS02 X X 2
AS03 X X X 3
AS04 X X X X X 5
AS05 X X X X 4
AS06 X X 2
AS08 X X X 3
AS09 X 1
AS10 X X X X X 5
AS11 X X X 3
AS12 X X X 3
AS13 X 1
AS14 X 1
AS15 X X X X X 5
AS16 X X X X 4
AS17 X X X X 4
AS18 X X X 3
AS19 X X X 3
AS20 X X X X 4
AS21 X X 2
AS22 X X X X 4
AS23 X X X 3
AS24 X X 2
Total 3 19 10 1 9 7 2 2 1 2 3 3 2 1 1 1 1 1 1
Fonte: Elaboração própria
57
QP3: O que atualmente se sabe sobre os desafios e limitações das técnicas de
engenharia de requisitos adotadas em projetos ágeis?
Conforme descrito na sessão 3.3.1 desta pesquisa, essa etapa seguiu as
recomendações de Cruzes e Dyba (2011). Inicialmente foram identificados códigos
(textos) de dados, em seguida foram realizados refinamentos sucessivos de revisão,
eliminando possíveis duplicações e analisando similaridades entre esses códigos
objetivando agrupa-los em uma classificação de nível mais alto, que foi denominada
de Temas.
Por fim realizamos novamente análise de similaridade, agora no nível de
Temas, objetivando também agrupa-los em uma classificação de nível mais alto, que
foi denominada de Categorias, esse nível também é conhecidos como tema de ordem
superior.
Na primeira etapa, foram identificados 115 códigos de texto, 15 temas e 7
categorias, após as análises e refinamentos, esses números reduziram e chegou-se a
um total de 49 códigos de texto, 13 temas e 5 categorias que podem ser visualizados
no mapa temático descrito na figura 14.
Cada código de texto recebeu um identificador (ID) para facilitar sua
identificação e as quantidades de ocorrências nos artigos estão descritas entre
parênteses logo após a descrição do código. Objetivando tornar mais claro o
entendimento, a partir desta sessão passaremos a chamar esses códigos de texto de
Desafios/Limitações encontradas.
58
Figura 14: Mapa temático dos desafios encontrados
Fonte: Elaboração própria
59
Analisando o total de ocorrências de desafios e limitações por Temas, é
possível constatar na tabela 3 os temas Mudança e Cliente foram os que
apresentaram as maiores ocorrências de desafios e limitações. Podemos verificar na
coluna QTD, que o tema Mudança obteve 30 ocorrências de desafios e limitações, o
que corresponde a 24,2% conforme coluna ‘%’ e o tema Cliente obtiveram 19
ocorrências, o que corresponde a 15,32%.
Tabela 3: Detalhamento dos desafios e limitações encontrados
Fonte: Elaboração própria
Conforme tabela 3, receberam destaque os desafios e limitações “Pouca
Disponibilidade do Cliente” com 6 ocorrências no tema Cliente e “Controle insuficiente
60
de mudanças nos requisitos”, com 10 ocorrências no tema Mudanças. Isso sinaliza
que o valor ágil “Equipes se adaptam rapidamente às mudanças” e “Interação
contínua com o cliente” não é a realidade das empresas investigadas nos estudos.
Analisando os desafios e limitações isoladamente, independente de seus
temas, podemos destacar também na tabela 4: “Documentação Insuficiente p\
Implementação, Manutenção ou Treinamento”, com 9 ocorrências, “Dificuldade em
estimar custo, prazo e produtividade” e “Interação inadequada entre cliente e equipe
desenvolvimento”, com 6 ocorrências, “Expectativas do Cliente não são atendidas”,
“US - Nível de detalhe não apropriado, requerendo esforço considerável”, “Falta de
clareza entre o problema e solução proposta”, “Arquitetura não escaláveis decorrentes
de constantes mudanças” e “Constante repriorização dos requisitos”, ambos com 5
ocorrências.
Para o detalhamento desta pesquisa, foram selecionados os 10 desafios e
limitações que obtiveram o maior número de ocorrências independente de seu tema
ou categoria, conforme tabela 4. Esse corte foi analisado e definido pela autora desta
pesquisa.
Tabela 4: Top 10 dos desafios e limitações
DESAFIOS/LIMITAÇÕES CATEGORIA TEMA QTD
Controle ineficiente de mudança nos requisitos
Gestão Mudança 10
Documentação insuficiente para implementação, manutenção ou treinamento
Documentação Documentação 9
Pouca disponibilidade do cliente Cliente Cliente 6
Dificuldade em estimar custo, prazo e produtividade
Gestão Mudança 6
Interação inadequada entre cliente e equipe desenvolvimento
Cliente Cliente 6
Expectativas do cliente não são atendidas
Cliente Cliente 5
US Nível de detalhe não apropriado, requerendo esforço considerável
Técnica US 5
Arquitetura não escaláveis decorrentes de constantes mudanças
Gestão Mudança 5
A falta de clareza entre a necessidade do cliente e a solução
Gestão Qualidade 5
Constante repriorização dos requisitos Gestão Mudança 5
Fonte: Elaboração própria
61
A seguir serão detalhamento dos 10 Desafios e Limitações que obtivem as maiores
ocorrências, conforme tabela 04.
Controle Ineficiente de Mudança nos Requisitos
Muitos estudos desta pesquisa relataram que existem desafios e limitações em
fazer mudanças nos requisitos de software, principalmente quando elas não têm
nenhum controle. As mudanças são sempre esperadas no desenvolvimento ágil, e por
isso o gerenciamento do esforço pode ser um desafio [AS12]. O estudo [AS11] relata
que as necessidades de alteração que surgem no desenvolvimento de alta
velocidade, não acontecem apenas porque os usuários são imprecisos ou
desconhecimento, mas também porque o mercado e a tecnologia estão sempre em
evolução.
Um dos desafios relatados por [AS24] foi à forma com que os clientes tratam
metodologias ágeis, onde o foco é colher os benefícios dos projetos ágeis, sem
compreender totalmente as suas próprias responsabilidades de colaboração e
envolvimento. Um entrevistado citou que os clientes querem fazer mudanças em
todos os instantes, não compreendendo a disciplina contrabalanceamento e o
envolvimento do cliente. Outro desafio das práticas de ER ágeis é como de alcançar
um bom equilíbrio entre agilidade e estabilidade, ou seja, alcançar um grau de
compromisso em relação à flexibilidade para mudanças de última hora [AS02].
Entrevistados do estudo [AS02] relataram que a falta uma definição de clara de
requisitos no início do desenvolvimento resultou em significativas mudanças durante o
desenvolvimento, o que ocasionou um retrabalho posterior e frustração dentro da
equipe de desenvolvimento. Por fim, o estudo [AS06] relatou que o ingresso contínuo
de mudanças de requisitos após a definição do escopo pode causar overscoping.
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“The quality manager (Sg) mentioned the continuous inflow of
requirement changes after setting the scope as causing
overscoping.” – [AS06]
62
“Changing requirements arise in high-speed development not
only because users are imprecise or unknowing, but also
because the marketplace and technology are evolving.” –
[AS11]
“I mostly work [with] Indian companies with client in US...they
see is client can make changes all the time and they think
wow that sounds great!...They don’t understand the counter-
balancing discipline...customer involvement.” – [AS24]
“This had resulted in significant requirements changes during
the development with subsequent rework and frustration within
the development team”. – [AS02]
“Our results also uncover some challenges with agile RE
practices such as ..., striking a good balance between agility
and stability both at project level (degree of commitment in
relation to flexibility for late changes) and ...” – [AS02]
Documentação Insuficiente para implementação, manutenção ou treinamento
Alguns estudos relatam que um dos desafios das metodologias ágeis é a falta
de documentação de requisitos. O estudo [AS03] relata que movimento ágil começou
a fortalecer a relação entre desenvolvedores e clientes através de práticas como o
cliente no local, no entanto, este estilo de relacionamento não é aplicável a todos os
projetos e pode levar a uma má documentação e consequentemente causar
problemas durante a manutenção do software.
Atividades muito grandes requerem uma atenção especial em relação à
documentação de requisitos, de acordo com o estudo [AS12], a aparente
descontração e falta de documentação pode ser preocupante e por isso, deve ser
posto em prática um novo plano de acompanhamento, que de preferência deve contar
com a ajuda de algumas ferramentas. O estudo [AS07] cita que falta de
documentação pode trazer riscos para a mudança do código existente.
De acordo com [AS17], os Cartões de História e a Parede são um sistema de
notação incompleto, eles fornecem estruturas para transmitir informações, no entanto,
63
existem vários problemas com este sistema físico. Dentre eles estão que os cartões
podem ser perdidos ou destruídos, são difíceis de ser pesquisados e compartilhados
com os membros da equipe distribuída.
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“However this style of relationship is not applicable to all
projects and may lead to poor documentation that can cause
problems during maintenance.” – [AS03]
"…lack of documentation can create risks for changing
existing code…" – [AS07]
“The apparent casualness and lack of documentation can be
worrisome, especially on a very large activity, so a new
tracking plan has to be put into place, preferably with the help
of some tools.” – [AS12]
"Story cards and the Wall are an incomplete notational
system; …However, there are several issues with this physical
system, including the fact that cards may be lost or destroyed,
they cannot easily be searched, they cannot easily be shared
with distributed team members and so on.” – [AS17]
Pouca disponibilidade do cliente
Uma pesquisa realizada em 16 organizações de desenvolvimento de software
revelou algumas práticas ágeis, seus benefícios e desafios. Esse estudo mostrou que
quase todas as organizações pesquisadas enfrentam problemas em relação à
incapacidade de ter acesso ao cliente e que é difícil ter o cliente no local de
desenvolvimento. Por esse motivo, a maior parte das empresas utilizou o gerente de
produto como o representante do cliente [AS04].
De acordo com [AS20], ocorreu uma melhora significativa em relação ao
resultado do papel do cliente, porém a prática do ritmo sustentável esta sendo
64
sacrificada. Ainda neste estudo, foi relatado que o processo de iteração XP foi
seguido, exceto o que se refere à participação do cliente, que não estava sempre no
local. Porém ocorreu um esforço para que ele passasse pelo menos 50% de seu
tempo no mesmo local em que estavam os desenvolvedores.
O estudo [AS03] relata que movimento ágil começou a fortalecer a relação entre
desenvolvedores e clientes através de práticas como o cliente no local, no entanto,
este estilo de relacionamento não é aplicável a todos os projetos.
O estudo [AS17] relatou que apesar de métodos ágeis mencionarem a
participação do usuário, a forma como ocorre essa participação não está definida, ou
pode esta sendo projetada em forma irrealista. O que de acordo com o estudo pode
trazer possíveis consequências para a Usabilidade.
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“Many organizations reported that achieving onsite customer
representation is difficult. In most of the projects we studied,
product managers acted as surrogate customers.” – [AS04]
“End users, however, are not necessarily part of these
negotiations, and although agile methods often mention user
participation, their manner is not defined, or projected in
unrealistic form (e.g. the on-site customer of XP) – with
possible consequences for Usability.” – [AS17]
“So although there has been a significant improvement as the
result of the on-site customer role, the practice of sustainable
pace has been sacrificed…The XP iteration process was
followed, except that the customer was not always on-site with
developers, but she attempted to spend 50% of her time at the
same location as the developers.” – [AS20]
“The agile movement has begun to strengthen the relationship
between developers and customers through practices such as
65
the on site customer in Extreme Programming [1]. However
this style of relationship is not applicable to all projects…” –
[AS03]
Dificuldade em estimar custo, prazo e produtividade
O estudo [AS04] registrou que nenhuma das organizações pesquisadas seguia
uma fase normal de engenharia de requisitos. Elas realizavam a estimativa inicial
baseava-se nas histórias de usuários conhecidas, porém muitas destas são
descartadas e muitas outras adicionadas durante o desenvolvimento, assim, as
estimativas originais eram ajustadas durante todo o processo de desenvolvimento.
Devido a esse fato, o escopo do projeto está sempre sujeito a mudanças, fazendo
com seja difícil criar estimativas precisas de custo e cronograma para o todo projeto.
O estudo [AS12] destacou que, em projetos grandes, as alterações nos sprints
podem causar problemas para estimar o cronograma geral. Também foi relatado nos
estudos [AS06, AS02] a dificuldades em estimar custos e escopo.
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“Addressed RE Challenges: Weak effort estimates” – [AS02]
“On a very large project, changes to the sprints can cause
issues for estimating the overall schedule.” – [AS12]
“However, agile RE practices also pose challenges [57], e.g.
communication between teams [36,53], difficulty in cost
estimation[57]. On the other hand, agile RE practices were
found to include challenges in (1) correctly estimating and
scheduling for the full project scope (which continuously
changes)” - [AS06]
“Because none of the organizations follow a formal RE phase,
the initial estimation of project size typically is based on the
66
known user stories. Many of these might be discarded, and
many more get added during development. So, the original
estimates must be adjusted (sometimes quite dramatically)
during development, as happened with HuCap.” – [AS04]
“Because the project scope is subject to constant change,
creating accurate cost and schedule estimates for the entire
project is difficult. Obtaining management support for such
projects could be challenging.” – [AS04]
Interação inadequada entre cliente e equipe desenvolvimento
A eficácia de comunicação entre o cliente e a equipe depende de vários fatores,
incluindo disponibilidade do cliente e confiança entre o cliente e os desenvolvedores,
especialmente durante o estágio inicial do projeto. Muitas vezes os clientes têm
dificuldade de entender ou confiar o processo de engenharia de requisitos ágeis, o
que é desafiador para o estabelecimento de confiança entre eles e os
desenvolvedores [AS04].
O estudo [AS07] relata que o risco da iteração inadequada entre o cliente e os
desenvolvedores aumenta quando o cliente não confiar no processo ou se a interação
passa por alguns representantes dos clientes. Este estudo também relata que é
necessário um enorme esforço de ambas as partes e nem todos os clientes estão
dispostos ou capazes de participar em tal processo.
Alguns estudos analisados apontaram que proximidade física é um item
necessário para essa prática se sustentar [AS17]. O estudo [AS24] também destacou
que a distância pode trazer prejuízos, promovendo mal-entendidos e causando a falta
de envolvimento do cliente devido a problemas de comunicação.
O estudo [AS24] revelou também que a falta de envolvimento do cliente foi um
dos maiores desafios que enfrentam e isso provocou problemas no levantamento e
detalhamento dos requisitos e perda de produtividade. A maioria dos participantes
não recebeu o nível de envolvimento do cliente que métodos ágeis exigem. Falta de
envolvimento do cliente foi visto como a parte mais difícil da utilização de
metodologias ágeis, sendo assim o maior problema da utilização desta metodologia.
67
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“Customers sometimes find it difficult to understand or trust
the agile RE process. Many participants reported that
establishing trust between the customer and developer, which
is essential for agile RE, can be challenging...The
effectiveness of communication between the customer and
team depends on several factors, including customer
availability, consensus among customer groups, and trust
between the customer and the developers, especially during
the project’s early stages.” – [AS04]
“Agile mitigates this because of frequent user interaction. At
the same time this risk is exacerbated if the customer does not
trust the process, or if the interaction goes through a few
selected customer representatives.” – [AS07]
“This indicates that the development process required a huge
effort from both parties, and not all customers are willing or
able to participate in such a process...Problematic is also the
physical proximity we believe is required to sustain such a
process.” – [AS07]
Our study revealed that Lack of Customer Involvement was
one of the biggest challenges they faced...We discovered that
lack of customer involvement was causing problems in
gathering and clarifying requirements, loss of productivity, and
business loss...The effect of distance was apparent on a NZ
team whose local customer was actively involved while their
distanced customer was unwilling to participate...Distance
between the team and their customers promoted
misunderstandings (P11) and caused lack of customer
68
involvement due to problems of communicating and
coordinating over distances [P8-P12, P17, P29). – [AS24]
Expectativas do Cliente não são atendidas
Nos estudos [AS02, AS06] foi possível identificar que as expectativas dos
clientes nem sempre são cumpridas, além disso, [AS06] relatou que umas das
causas disso ocorrer é o overscoping. O estudo [AS16] destaca que uma das
consequências da insatisfação do cliente é a não utilização dos aplicativos
desenvolvidos.
O estudo [AS18] exemplifica o desapontamento do cliente após o primeiro sprint
do projeto, onde muitas das características não funcionavam como pretendidas, e
algumas, embora computacionalmente corretas, não puderam ser utilizadas para o
fim a que se destinavam.
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“Addressed RE Challenges: Customer expectations not met” –
[AS02]
“Customer expectations are not always met (E4). Overscoping
was mentioned by a few interviewees as resulting in
sometimes failing to meet customer expectations.” – [AS06]
“Customer dissatisfaction which leads to unused applications.”
– [AS16]
“At the end of the first sprint, the PO was disappointed that
many of the features did not function as intended, and some,
although computationally correct, could not be used for their
intended purpose.” – [AS18]
69
US Nível de detalhe não apropriado, requerendo esforço considerável
O estudo [AS21] relatou que as histórias de usuário tendem a ter dois problemas
básicos, o primeiro é que a sua aplicação requer esforço significativo e o segundo é
que suas descrições são imprecisas. O estudo [AS20] menciona que a dificuldade
talvez seja ter as habilidades técnicas necessárias para escrever histórias de
usuários. Um dos pesquisados neste estudo relatou que achou o processo de
escrever histórias de usuário frustrante e detalhado.
Os estudos [AS12 e AS21] citam que, devido a sua complexidade, a definição
história de usuário pode ser um desafio. Elas podem necessitar de um esforço
significativo, sobrepondo-se a vários sprints, o que é indesejável nas metodologias
ágeis de desenvolvimento de software.
O estudo [AS18] citou que a falta de experiência em escreveu histórias podem
levar a implementações incompletas, onde muitas das características podem não
funcionar conforme as expectativas do cliente. O programador ao ser questionado
pela ausência da funcionalidade explicou que a história de usuário não disse que essa
funcionalidade deveria ser feita, então ela não foi feita.
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“User stories as we have encountered tend to have two basic
problems. Their implementation takes significant effort and
their descriptions are imprecise...User story definition can be
challenging – story complexity impacts completion time and
may overlap multiple sprints, which is undesirable.” – [AS12]
The difficulty maybe the technical skills required to write
usable user stories for developers as suggested by Beck &
Fowler [3]” – [AS20]
“Lacking experience, the PO and SM wrote stories were short,
vague and ambiguous, ...At the end of the first sprint, the PO
was disappointed that many of the features did not function as
intended, and some, although computationally correct, could
70
not be used for their intended purpose. A frustrated
programmer said, “The story didn’t say I should do that, so I
didn’t do it.” – [AS18]
Arquitetura não escaláveis decorrentes de constantes mudanças
Uma tendência das práticas ágeis é omitir os requisitos de qualidade e
problemas de arquitetura, isto pode ocasionar problemas graves e onerosos ao longo
do tempo [AS06]. O estudo [AS04] relata que a arquitetura definida pela equipe de
desenvolvimento durante os ciclos iniciais pode-se tornar inadequada com as
constantes mudanças ocorridas nos requisitos durante o desenvolvimento do projeto.
Rever essa arquitetura pode aumentar significativamente os custos do projeto,
ocasionalmente, a única alternativa é jogar fora o código e reescrever módulos
inteiros. Este estudo ainda relata que utilizar o valor do negócio como a único ou
principal critério para a priorização requisitos pode causar grandes problemas, por
exemplo, em uma arquitetura que não era escalável ou até mesmo não atender a
requisitos não funcionais como segurança.
Grandes mudanças estruturais demandam bastante tempo para sua
implementação e consequentemente não podem ser abordados dentro de um sprint
regular. Outras partes do software muitas vezes são dependentes dessa mudança,
mas não pode ser atualizado antes da alteração ser implementada e testada. Isso é
um problema, pois quebra o ritmo da integração contínua. – [AS21]
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“On the other hand, agile RE practices were found to include
challenges in... (2) a tendency to omit quality requirements
and architectural issues (with the risk of serious and costly
problems over time)” – [AS06]
“…the architecture the development team chose during the
early cycles became inadequate as requirements changed.
Redesign of the architecture added significantly to project
71
cost...Occasionally, the only alternative is to throw away the
code and rewrite entire modules... Using business value (often
focused on time-to-market) as the only or primary criterion for
requirements prioritization might cause major problems. For
example... in an architecture that wasn’t scalable.” – [AS04]
“Architecture evolution has been more problematic... Large
structural changes take rather long time to implement and
cannot be addressed within a regular sprint. Other parts of
software often are dependent on this change but cannot be
updated before the change has been implemented and tested.
This breaks the rhythm of continuous integration.” – [AS21]
A falta de clareza entre a necessidade do cliente e a solução
O estudo [AS01] relata que as relações entre problema e solução não são
transparentes. As partes interessadas muitas vezes não têm um entendimento claro
do que o sistema desejado deve fazer ou como o sistema desejado deve executar.
Assim, as partes interessadas frequentemente mudam de ideia sobre as
funcionalidades [AS23].
Transcrições dos estudos
A seguir, seguem algumas transcrições extraídas durante a análise dos estudos:
“Relationship of problem to solution space: Nontransparent
relations between the problem and solution spaces” – [AS01]
“Stakeholders often lack a clear understanding of what the
desired system should do or how the desired system should
perform. So the stakeholder frequently change their mind
regarding the functionality that the system exhibit.” – [AS23]
Constante repriorização dos requisitos:
72
O estudo [AS04] relata que a repriorização contínua, quando não praticado com
cautela, leva a instabilidade. O estudo [AS06] mencionou que as práticas de ER ágeis
incluem alguns desafios, dentre eles esta a redefinição de prioridades constante dos
requisitos com instabilidade posterior e desperdício. Foi mencionado também que a
falta de prioridade unificada dificultada a gestão de projetos a lidar eficazmente com o
overscoping. Um dos entrevistados do estudo [AS20] relatou sua insatisfação em
relação à necessidade de realiza a priorização de requisitos.
“Furthermore, some participants observed that continuous
reprioritization, when not practiced with caution, leads to
instability.” – [AS04]
“… agile RE practices were found to include challenges in…
and (3) constant reprioritization of the requirements (with
subsequent instability and waste). In addition, Rc mentioned
that the lack of unified priority hindered the project
management from effectively addressing the overscoping.” –
[AS06]
“During the interview the customer demonstrated her strength
of feeling regarding prioritisation: I hate it, I hate that word
prioritise [and later in the interview]" – [AS20]
QP4: Quais as boas práticas e/ou sugestões que podem minimizar os efeitos
dos desafios e limitações encontrados?
Durante a leitura e extração dos artigos selecionados neste mapeamento, foi
possível identificar algumas sugestões e práticas que auxiliam na minimização dos
efeitos de alguns dos problemas/desafios detectados nesta pesquisa. Esse
relacionamento pode ser visualizado na figura 15.
73
Figura 15: Relacionamento sugestões/práticas por desafios/problemas
Fonte: Elaboração própria
A seguir detalharemos as sugestões/práticas por desafios/problemas conforme
figura 15:
Controle ineficiente de mudança nos requisitos:
De acordo com [AS04] organizações que praticam gerenciamento de mudança
de requisitos durante as iterações de desenvolvimento tem uma baixa necessidade de
grandes mudanças para os recursos entregues. Além disso, este mesmo estudo
relata que a realização de validações iniciais e constantes dos requisitos minimiza a
necessidade de maiores alterações. Por fim, tem-se que a comunicação frequente
entre o desenvolvedor e o cliente durante o desenvolvimento elimina a necessidade
de mudanças após o desenvolvimento.
Documentação insuficiente para implementação, manutenção ou treinamento:
Segundo [AS02] equipes de desenvolvimento multifuncionais são experientes
em colmatar as lacunas de comunicação. Além disso, é relatado que a utilização
dessa prática aborda o desafio de manter o SRS atualizado. Documentar requisitos
74
detalhados como critérios de teste de aceitação também foi mencionado como uma
prática que enfrentar o desafio de manter os SRS atualizados.
Em vez de incorrer a sobrecarga envolvida na criação de documentos de
requisitos formais, vários organizações usam para se comunicar com seus clientes a
prototipagem para validar e refinar requisitos [AS04].
O estudo [AS10] relata que manter repositório do produto/processo pode
facilitar a partilha de conhecimentos, além disso, sugere que ocorra a
complementação da comunicação informal com a documentação pertinente e que
seja utilizado um processo de colaboração estruturada centrada em um portal on-line
para compartilhar informações.
Pouca disponibilidade do cliente:
De acordo com [AS24] equipes ágeis estão utilizado um representante do
cliente, onde um representante do cliente interage frequentemente com a equipe, e
em seguida, passa o feedback do cliente para a equipe e vice-versa. Além disso, é
sugerida a utilização de colaboração eletrônica (e-colaboração) para realização da
comunicação regular com clientes, através de web-conferência, chats,
videoconferência, entre outros.
Dificuldade em estimar custo, prazo e produtividade:
De acordo com [AS05] Planning Poker é uma maneira eficiente de fazer a
estimativa de alto nível.
Interação inadequada entre cliente e equipe desenvolvimento:
Realizar engenharia de requisitos iterativa cria-se um relacionamento mais
satisfatório com o cliente. Além disso, foi percebido que a utilização de reuniões
validação permitem a identificação mais rápidas de problemas no processo de
desenvolvimento e também possibilita a verificação se o projeto está no alvo, o que
aumenta a confiança do cliente e confiança na equipe.
75
Expectativas do cliente não são atendidas:
Foi relatado por [AS04] que acomodar mudanças de requisitos durante o
desenvolvimento é uma forma de ajustar o sistema para melhor satisfazer as
necessidades dos clientes. Na inclusão ou eliminação de recursos, mudando as
características já implementadas, os clientes podem fornecer feedback e solicitar
mudanças importantes se suas expectativas não sejam atendidas.
Relatou-se também que Reuniões de validação têm sido benéfica em averiguar
se o projeto está no alvo, e em aumentar a confiança do cliente.
Utilizar equipes de desenvolvimento multifuncionais aumenta a clareza da
cobertura da exigência e grau em que são satisfeitas as expectativas dos clientes, isto
resulta em requisitos de qualidade mais elevada e subsequente maior qualidade de
software, bem como, menos resíduos devido a retrabalho desde questões são já
resolvido ao discutir requisitos [AS02].
Definição de requisitos com histórias de usuários foi mencionado como uma
forma de facilitar a comunicação entre funções comerciais e de engenharia, e
expressando o ponto de vista dos usuários, aumenta a probabilidade de capturar e
satisfazer as expectativas dos clientes [AS02].
A falta de clareza entre a necessidade do cliente e a solução:
A técnica de história do usuário aumenta a qualidade dos requisitos,
assegurando que o contexto do usuário é capturado, as necessidades reais são mais
claramente comunicadas [AS02]. Na engenharia de requisitos iterativa os requisitos
são mais claros e compreensíveis, isso se deve ao fato do acesso imediato aos
clientes e ao seu envolvimento no projeto [AS04].
A participação dos desenvolvedores durante as atividades levantamento de
requisitos conduz naturalmente para a atividade de clarificação e evolução dos
requisitos [AS08]. Utilizar documentos de requisitos simplificados, incluindo os
objetivos do projeto priorizados e declaração de visão ajuda a equipe a ter uma
compreensão do sistema, para quem ele é direcionado e quais aspectos dele são
mais importantes [AS10].
76
QP5: Quais as implicações, para a indústria e para a academia, dos estudos que
envolvem a engenharia de requisitos em projetos que adotam metodologias
ágeis?
Os resultados levantam algumas questões que a academia deve investigar
para melhorar as atuais práticas de engenharia de requisitos quando aplicadas em
projetos que adotam metodologias ágeis, estimulando mais pesquisadores nessa
área. Outra questão que merece atenção da comunidade acadêmica é a baixa
qualidade dos artigos selecionados. O total inicialmente a ser utilizado para a extração
de dados era de 31 artigos. Entretanto durante a etapa de análise da qualidade, 23%
dos artigos (7) foram excluídos, devido à baixa avaliação. Dos 24 artigos restantes,
apenas 6 artigos foram considerados de qualidade muito alta.
Interessante registrar que a grande maioria (20) dos artigos selecionados foi
resultante de pesquisas realizadas na academia, mas com validações empíricas
realizadas em projetos reais da indústria.
Com base nos resultados apresentados, percebe-se que mesmo com a adoção
das metodologias ágeis, as empresas ainda apresentam diversos problemas
principalmente relacionados com gestão de requisitos. De um total de 128
ocorrências, 60 estão relacionadas a problemas de gestão de requisitos: Escopo,
Mudança, Qualidade e Pessoas.
4.2. Considerações Finais
Este capítulo descreveu os resultados desta pesquisa, que foram obtidos
através da aplicação dos métodos de coletas já mencionados. O mapeamento
sistemático foi conduzido objetivando investigar como a engenharia de requisitos e as
metodologias ágeis vêm sendo utilizadas conjuntamente na prática em projetos de
desenvolvimento de software aplicados na indústria.
Nos 24 estudos primários relevantes, receberam destaques as técnicas
Meetings, User Stories, Protótipos, Features e Story Card. Em relação aos problemas
e limitações encontradas, foram identificamos 49 desafios e limitações classificados
em 13 temas e 5 categorias. Receberam destaque os desafios e limitações “Pouca
Disponibilidade do Cliente” com 6 ocorrências na categoria Cliente e “Controle
insuficiente de mudanças nos requisitos”, com 10 ocorrências na categoria Mudanças.
77
5. CONCLUSÕES
Os 24 artigos analisados investigaram um total de 68 empresas, envolvendo
270 pessoas no total. Analisando esses artigos constatamos que a técnica de
Meetings é a mais utilizada para levantar requisitos, ela foi relatada em 37,5% dos
estudos analisados. User Stories foi citada em 79,2% dos artigos analisados como
técnica para especificar requisitos. Além desta, receberam destaque também
Protótipos e Feature, com respectivamente 41,6% e 37,5% de presença nos artigos
desta pesquisa.
A categoria de Gestão de Requisitos foi a que apresentou a maior quantidade
de problemas, ela teve 48,39%(60) dos problemas identificados nesta pesquisa. Isso
pode ser justificado pela baixa utilização de práticas como Burn Down Chart, Plano de
Projeto, Descrição das Metas e Objetivos gerais das aplicações. O uso dessas
práticas só foi relatado em 2, 4 e 5 artigos, respectivamente.
Analisando ao nível de Temas, os estudos reportaram que a maioria dos
problemas foram detectados nos temas Mudança e Cliente, com respectivamente
24,2% e 15,32% dos problemas identificados. Receberam destaque os desafios e
limitações “Controle insuficiente de mudanças nos requisitos”, com 10 ocorrências e
“Pouca Disponibilidade do Cliente” com 6 ocorrências. Isso sinalizou que o valor ágil
“Equipes se adaptam rapidamente às mudanças” e “Interação contínua com o cliente”
não era a realidade das empresas investigadas nos estudos.
Analisando os desafios e limitações isoladamente, independente de suas
categorias, podemos destacar também: “Documentação Insuficiente p\
Implementação, Manutenção ou Treinamento”, com 9 ocorrências, “Dificuldade em
estimar custo, prazo e produtividade” e “Interação inadequada entre cliente e equipe
desenvolvimento”, com 6 ocorrências, “Expectativas do Cliente não são atendidas”,
“US - Nível de detalhe não apropriado, requerendo esforço considerável”, “Falta de
clareza entre o problema e solução proposta”, “Arquitetura não escaláveis decorrentes
de constantes mudanças” e “Constante repriorização dos requisitos”, ambos com 5
ocorrências.
Em 50% (12) dos artigos foi relatado a utilização Testes de Aceitação, talvez
por isso, foram reportados poucos problemas relacionados com Validação de
Requisitos, apenas 5 ocorrências foram contabilizadas nesse Tema.
78
5.1. Relação desta pesquisa com os trabalhos relacionados
Comparando os resultados obtidos neste estudo com trabalhos relacionados
observou-se que três desafios não foram relatados nos artigos deste mapeamento.
Jaqueira (2012) relatou desafios relacionados com a rastreabilidade e a equipe
multifuncionais e Kamei (2012) relatou problemas com a ausência de um contrato
formal com o cliente.
De acordo com a tabela 5, podemos verificar que Interação inadequada entre
cliente e equipe desenvolvimento, Documentação insuficiente, Controle Ineficiente de
Mudança nos Requisito, Dificuldade em estimar custo, prazo e produtividades foram
identificados com limitações nos três estudos, sendo assim um ponto de convergência
com os trabalhos relacionados.
Tabela 5: Relação com trabalhos relacionados
Problemas/Limitações Estudo
de Jaqueira
Estudo de
Kamei
Este Estudo
Expectativas do cliente não são atendidas - X X
Interação inadequada entre cliente e equipe desenvolvimento
X X X
Pouca disponibilidade do cliente X - X
Documentação insuficiente para implementação, manutenção ou treinamentos
X X X
Dificuldades na transferência de conhecimento - X X Cartões de História e a parede fornecem informações incompletas sobre o sistema
- X X
US - Nível de detalhes não apropriado, inadequadas para desenvolvedores e testadores, requerendo esforço considerável
- X X
Controle ineficiente de mudança nos requisitos X X X
Dificuldade em estimar custo, prazo e produtividade
X X X
Constante repriorização dos requisitos
X X
Conflitos quando requisitos são provenientes de várias fontes
X - X
Deficiência no levantamento de RNF X - X
Rastreabilidade X - -
Equipe de desenvolvimento multifuncional X - -
Dificuldade de trabalhar com contrato de escopo aberto
- X -
Fonte: Elaboração Própria
79
5.2. Implicações para a Pesquisa e Prática
Este trabalho tem implicações tanto para pesquisa quanto para a prática. Para
a pesquisa, os resultados mostram que poucos estudos estão analisando como a
engenharia de requisitos vem sido conduzida na prática em conjunto com as
metodologias ágeis. Sendo assim, podemos considerar que existe uma clara
necessidade de mais estudos nesta área.
A maioria dos estudos selecionados neste mapeamento sistemático
apresentaram resultados da aplicação de estudos de caso. Isso mostra que existem
oportunidades para pesquisas com aplicação de outros métodos científicos, como o
survey, a pesquisa-ação e os experimentos.
Para os praticantes, os resultados podem ajudar a entender melhor as técnicas
e processos de engenharia de requisitos que estão sendo mais utilizados e quais os
problemas e limitações encontradas.
5.3. Trabalhos Futuros
A partir da condução deste trabalho, são propostos direcionamentos para
novas pesquisas, que são descritas a seguir:
Atualizar os dados do mapeamento sistemático com a inclusão dos anos
seguintes a que a pesquisa foi limitada.
Realizar survey com analistas e desenvolvedores que atuam em
empresas que adotam metodologias ágeis.
Confrontar dados do mapeamento com o survey para verificar os pontos
de convergência e de divergência.
5.4. Considerações Finais
A utilização da ferramenta Reviewer para a busca automática agilizou a
seleção inicial feita a partir do título e do resumo, tendo em vista que não foi
necessário fazer o download dos artigos, pois no resultado gerado pela ferramenta já
constavam essas informações.
O planejamento inicial previa a participação de 4 alunos de graduação para
atuar na primeira etapa de leitura do título e resumo. Entretanto esta prática não se
mostrou efetiva, o índice de divergência era muito alto em relação à avaliação do
outro membro da dupla, desta forma, a participação dos mesmos foi cancelada.
80
A realização de reuniões e/ou testes piloto antes de iniciar as etapas do
mapeamento foi importante para permitir um conhecimento unificado e padronizado,
evitando assim possíveis desacordos.
Diante do exposto, consideramos que o mapeamento atingiu os objetivos
esperados, tendo apontado a necessidade de ações da academia e da indústria para
minimizar os problemas que atualmente comprometem a ER nos projetos ágeis.
81
6. REFERÊNCIAS
ADLIN, T. The Persona Lifecycle: Keeping People in Mind Throughout Product Design. The Morgan Kaufmann Series in Interactive Technologies. Elsevier Science & Technology, 2006. AGILE ALLIANCE. INVEST. Disponível em: <http://guide.agilealliance.org/guide/invest.html/>. Acesso em: 05 novembro 2015.
AGILE MANIFESTO. Manifesto for Agile Software Development, 17 February 2001. Disponível em: <http://www.agilemanifesto.org/>. Acesso em: 01 junho 2015.
AGILE MODELING. UML 2 Activity Diagrams: An Agile Introduction. Disponível em: <http://agilemodeling.com/artifacts/activityDiagram.htm#sthash.d8uPdAVa.dpuf/>. Acesso em: 05 novembro 2015.
ARKSEY, H.; O'MALLEY, L. Scoping studies: towards a methodological framework. International Journal of Social Research Methodology, v. 8, n. 1, p. 19-32. doi: 10.1080/1364557032000119616, 2005. BAILEY, J. et al. Evidence relating to Object-Oriented software design: A survey. First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007), p. 482-484. Ieee. doi: 10.1109/ESEM.2007.58, 2007. BECK, K. Extreme Programming Explained: Embrace Change. [S.l.]: Addison-Wesley, 1999.
BELGAMO, A.; MARTINS, L. Estudo Comparativo sobre as Técnicas de Elicitação de Requisitos do Software. In: XX Congresso Brasileiro da Sociedade Brasileira de Computação (SBC), Curitiba – Paraná, 2000.
BLACKBURN, R. Breaking down the barriers: Using focus groups to research small and medium-sized enterprises, International Small Business Journal, v. 19(1), p. 44-63, 2000.
CAO, L.; RAMESH, B. Requirements Engineering Practices: An Empirical Study, IEEE Software, v. 25, n. 1, p. 60-67, 2008.
CAPILUPPI, A. et al. An empirical study of evolution patterns for an agile system, that combines qualitative and quantitative approaches in Proceedings of ICSE 2007, ACM, p. 511-518, 2007.
COCKBURN, A. Crystal Clear: A Human-Powered Methodology for Small Teams. [S.l.]: Addison-Wesley Professional. ISBN 0-201-69947-8, 2004.
COCKBURN, A. Agile software development. 1. Ed. Boston: Addison-Wesley, 2002.
82
CRUZES, D.S.; DYBA, T. Recommended Steps for Thematic Synthesis in Software Engineering. International Symposium on Empirical Software Engineering and Measurement, 2011.
DA SILVA. et al. An Extended Systematic Literature Review about Challenges and Solutions in Distributed Software Development Project Management. 5th IEEE International Conference on Global Software Engineering, 2010.
DAHLSTEDT, A. Study of Current Practices in Market-Driven Requirements Engineering. 3rd Conference for the Promotion of Research in IT at New Universities and University Colleges in Sweden, 2003.
DYBA, T.; DINGSOYR, T. Empirical studies of agile software development: A systematic review. Information and Software Technology, doi:10.1016/j.infsof.2008.01.006, USA, 2008.
DYBA, T.; KAMPENES, V.; SJOBERG, D. A Systematic Review of Statistical Power in Software Engineering Experiments, Journal of Information and Software Technology, v. 1, n. 11, 2005.
ENGHOLM, H. Engenharia de Software na Prática, São Paulo: Novatec, 2010.
FARID, W.M., MITROPOULOS, F.J.: Novel lightweight engineering artifacts for modeling non-functional requirements in agile processes. In: 2012 Proceedings of IEEE Southeastcon, p. 1–7. IEEE (2012) 17. Farid, W.M., Mitropoul.
KITCHENHAM, B. et al. Evidence-based Software Engineering. Proceedings of the 26th International Conference on Software Engineering (ICSE’04). IEEE Computer Society, Washington DC, USA, p.273 –281, 2004.
FERREIRA,C.; COHEN,J. AgileSystems Development and Stakeholder Satisfaction: A South African Empirical Study. ITSAUCSIT, p. 48-55, 2008.
GIBBS, A. Focus Groups, Social research Update, v.19, p.1-7, 1997.
HIGHSMITH, J. A. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York, NY: Dorset House Publishing, 2000.
HIGHSMITH, J.; COCKBURN, A., Agile Software Development: The Business of Innovation, Computer, v. 34, p. 120-122, 2001.
IEEE. IEEE Guide to Software Requirements Specification. The Institute of Electrical and Electronics Engineers, New York, EUA, 1984.
83
JAQUEIRA, A. et al. Desafios de requisitos em Métodos Ágeis: Uma Revisão Sistemática. Workshop Brasileiro de Métodos Ágeis, 2012.
KAMEI, F. K. Benefícios e limitações das metodologias ágeis no desenvolvimento de software. 2012. 296f. Dissertação (mestrado em ciências da computação) - Centro de Informática- CIn, Universidade Federal de Pernambuco - UFPE, Recife, 2012.
KITCHENHAM, B. et al. Evidence-based Software Engineering. Proceedings of the 26th International Conference on Software Engineering (ICSE’04). IEEE Computer Society, Washington DC, USA, p.273 –281, 2004.
KITCHENHAM, B.A; CHARTERS, S. Guidelines for performing Systematic Literature Reviews in Software Engineering. v. 2.3, EBSE-2007-01, Keele, UK, 2007.
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: processes and techniques. Chichester, England: John Wiley, 1998.
KUJALA, S. User Studies: A practical Approach to User Involvement for
Gathering User Needs and Requirements. PhD Thesis. Helsinki University of Technology, Department of Computer Science and Engineering, Espoo, Finland, 2002.
LAUESEN, S. Software Requirements Styles and Techniques. Elicitation. England: A Personal Education Limited, 2002.
LEE J.C. Integrating scenario-based usability engineering and agile software development. Dissertação de doutorado - Faculty of the Virginia Polytechnic Institute and State University,2010.
LINN GUSTAFSON. Requirements Engineering Verification validation, University West, Course slides, Feb-2008.
MAFRA, S. et al. Aplicando uma Metodologia Baseada em Evidência na Definição de Novas Tecnologias de Software. In: Anais do XX Simpósio Brasileiro de Engenharia de Software, Florianópolis, SC, Brasil, p. 239-254, 2006.
MAIDEN, N.; RUGG, G. Selecting Methods for Requirement Acquisition. IEEE, Software Engineering Journal, 11(3):183-19247, 1996.
MARCONI, M.; LAKATOS, E. M. Fundamentos de metodologia científica. 5. ed. - São Paulo : Atlas, 2003.
84
MARCONI, M. A.; LAKATOS, E. M. Metodologia Científica. 6. ed. São Paulo: Atlas, 2008.
MONTEIRO, C. V. F. Impacto do uso de ferramentas de software nas fases iniciais do processo de inovação. Dissertação de Mestrado. Universidade Federal de Pernambuco, Recife, PE, Brasil, 2010.
MORISIO, M. et al. COTS-based software development: Processes and open issues. The Journal of Systems and Software, v. 61, n. 3, p. 189–199, 2002.
NUSEIBEH, B.; EASTERBROOK, S. Requirements Engineering: ARoadmap. International Conference on Software Engineering. Proceedings of the Conference on the Future of Software Engineering. ACM Press, p. 35-46. Limerick, Ireland , 2000.
OATES, J. B.; CAPPER G. Using systematic reviews and evidence-based software engineering with masters students. International Conference on Evaluation & Assessment in Software Engineering, EASE, 2009.
PAETSH, F.; EBERLEIN, A.; MAURER, F. Requirements Engineering and Agile Software De-velopment, In: 12th IEEE International WETICE 03, IEEE CS Press, 2003.
PALMER, S.; FELSING, J. A Practical Guide to Feature Driven Development, Prentice Hall, 2002.
PETERSEN, K. et al. Systematic Mapping Studies in Software Engineering. p. 1-10, 2007.
RICO, D.F.; SAYANI, H.H.; SONE, S. The Business value of agile software methods. J.Ross Publishing, Ind., Fort Lauderdale (2009).
SCHWABER, K. SCRUM Development Process. OOPSLA'95 Workshop on Business Object Design and Implementation. Austin, Texas, USA: Springer-Verlag, 1995.
SEM A.M. et al. Elicitation of Requirements in Goal Oriented Requirement Engineering. Assam University Journal of Science & Technology - Physical Sciences and Technology v. 5, n. II, p. 64-72, 2010. SEM A.M.; HEMACHANDRAN, K.; Elicitation of Goals in Requirements Engineering using Agile Methods. 34th Annual IEEE Computer Software and Applications Conference Workshops, 2010.
SOMMERVILLE, I. Software Engineering. Addison Wesley; 7ª ed, 2007.
85
THAYER, R.H.; M. DORFMAN. Software Requirements Engineering, 2d ed., IEEE Computer Society Press, 1995 1997.
THOMSON, C.; HOLCOMBE, W.; MICHAELIDES, G. A Pilot Study of Comparative Customer Comprehension between Extreme X-Machine and UML Models. University of Sheffield Department of Computer Science, 2004
THOMSON, C.; HOLCOMBE, W. Applying XP Ideas Formally: The Story Card and Extreme X-Machines. 1st South-East European Workshop on Formal Methods, 2003.
THOMSON, C.; HOLCOMBE, W. A Design Change Metric Derived From Extreme XMachines. Department of Computer Science, University of Sheffield, 2007
TRAVASSOS, G.; BIOLCHINI, J. Revisões Sistemáticas Aplicadas a Engenharia de Software. In: XXI SBES - Brazilian Symposium on Software Engineering, João Pessoa, PB, Brasil, 2007. WAKE, B. INVEST in Good Stories, and SMART Tasks, 2003. Disponível em: <http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/>. Acesso em : 01 novembro 2015.
WOHLIN, C. Guidelines for Snowballing in Systematic Literature Studies and a Replication in Software Engineering . International Conference on Evaluation and Assessment in Software Engineering, EASE 2014, p. 321-330, 2014.
86
APÊNDICE A – Protocolo do Mapeamento Sistemático
Este apêndice contém o protocolo do Mapeamento Sistemático conduzido neste
trabalho. Ele foi desenvolvido por três pessoas: uma aluna do mestrado, Daniela de
Castro Pereira Alves, uma aluna de doutorado, Juliana Dantas Medeiros e pelo
professor orientador Alexandre Marcos Lins de Vasconcelos.
87
UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO
CIn - CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
PROTOCOLO DO MAPEAMENTO SISTEMÁTICO DA LITERATURA
ENGENHARIA DE REQUISITOS EM PROJETOS ÁGEIS: UM MAPEAMENTO
SISTEMÁTICO BASEADO EM EVIDÊNCIAS DA INDÚSTRIA.
Daniela de Castro Pereira Alves
Juliana Dantas Medeiros
Alexandre Marcos Lins de Vasconcelos
RECIFE-PE
DEZEMBRO DE 2013
88
EQUIPE
Nome Afiliação Papel
Alexandre Marcos Lins de
Vasconcelos
CIn – Universidade Federal de
Pernambuco
Co-autor e Revisor
Daniela de Castro Pereira
Alves
CIn – Universidade Federal de
Pernambuco
Autor
Juliana Dantas Medeiros CIn – Universidade Federal de
Pernambuco
Autor
1. Objetivo
O objetivo geral desta pesquisa é realizar um mapeamento sistemático da literatura para
investigar como a engenharia de requisitos vem sendo conduzida em projetos que adotam
metodologias ágeis para desenvolver softwares.
2. Questões de Pesquisa
Para alcançar os objetivos, este estudo buscou responder a seguinte questão de pesquisa:
RQ: Como a Engenharia de Requisitos tem sido conduzida em projetos que adotam
metodologias ágeis para desenvolvimento de Software?
As seguintes questões de pesquisa específicas(QPE) foram definidas para orientar a extração,
análise e síntese dos resultados:
QPE1: Quais técnicas\processos de engenharia de requisitos estão sendo utilizadas em
projetos que adotam metodologias ágeis com objetivo de levantar requisitos?
QPE2: Quais técnicas\processos de engenharia de requisitos estão sendo utilizadas em
projetos que adotam metodologias ágeis com objetivo de especificar requisitos?
QPE3: O que atualmente se sabe sobre os desafios e limitações das técnicas de
Engenharia de Requisitos adotadas em projetos ágeis?
QPE4: Quais as implicações, para a indústria de software e para a comunidade
acadêmica, dos atuais estudos que envolvem a engenharia de requisitos em Projetos
ágeis?
89
3. Estratégias de Busca
Segundo Kitchenham et al. (2007), uma estratégia deve ser usada para a pesquisa dos
estudos primários, com a definição das palavras chaves, bibliotecas digitais, jornais e
conferências. A estratégia usada nessa pesquisa é apresentada nas próximas subseções.
4. Termos de Busca
Os termos de busca foram identificados a partir da estrutura das questões de pesquisa. Em
seguida foram traduzidos para o inglês, pois é a língua utilizada na maioria das bibliotecas
digitais. Os termos utilizados foram os mais abrangentes possíveis, para evitar perdas de
estudos relevantes, de modo que a busca retornasse a maioria dos estudos sobre as
Metodologias Ágeis Scrum e XP, e somente após a leitura dos mesmos identificar as técnicas e
processos de engenharia de requisitos que estão sendo mais utilizados e quais os principais
problemas e limitações encontradas, conforme recomendam Dyba e Dingsoyr (2008). Os
termos de busca, seus sinônimos ou palavras relacionadas são apresentados no Quadro I.
Termos de busca Sinônimos ou Palavras Relacionadas
Software Software, information system development,
information system engineering.
Metodologias Ágeis Agile, agility, scrum, extreme programming,
xp, dynamic system development, dsdm,
crystal methodologies, crystal clear, crystal
orange, crystal red, crystal blue, feature driven
development, fdd, lean software development,
adaptive software development, test driven
development.
Requisitos Requirements, use case, user stories
Quadro I – Termos de busca, seus sinônimos ou palavras relacionadas.
Fonte: Eleborada pelo autor
90
5. String de Busca
Na visão de Kitchenham et al. (2007) as strings de busca devem ser derivadas das questões de
pesquisa e seus termos de busca. Dessa forma, a string de busca foi gerada a partir da
combinação dos termos de busca, seus sinônimos ou palavras relacionadas, concatenando-os
por meio dos operadores booleanos “OR” e “AND”.
A string pode ser visualizada no Quadro II a seguir.
String de Busca
(("requirements" OR "use case" OR "use cases" OR "user stories") AND ("agile" OR "agility")
AND ("scrum" OR "extreme programming" OR "xp" OR "dynamic system development" OR
"dsdm" OR "crystal methodologies" OR "crystal clear" OR "crystal orange" OR "crystal red"
OR "crystal blue" OR "feature driven development" OR "fdd" OR "lean software
development" OR "adaptive software development" OR "test driven development" OR
"tdd") AND ("software" OR "information system development" OR "information system
engineering" ) )
Quadro II – String de busca da RSL.
Fonte: Elaborada pelo autor.
6. Fontes de Busca
Kitchenham et al. (2007) também orienta que as buscas dos estudos primários podem ser
realizadas em bibliotecas digitais, alertando que isso pode não ser suficiente. Dessa forma,
outras fontes deveriam ser consultadas como: Pesquisadores da área, revistas e manuais de
conferências e periódicos.
Assim, visando uma busca abrangente para garantir uma maior cobertura possível da
literatura sobre o tema, foram escolhidas as fontes de busca automática e manual com acesso
institucional permitido para Universidade Federal de Pernambuco via portal de periódicos da
CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior).
Essas fontes são as principais bases de dados eletrônicas de relevância na área de
investigação, citadas por Kitchenham et al. (2007) e Dyba e Dingsøyr (2008). As fontes de
busca automática desta pesquisa são listadas a seguir:
91
IEEE Xplore (http://www.ieeexplore.ieee.org)
Compendex (www.engineeringvillage2.org)
Scopus (http://www.scopus.com)
ACM Digital Library (http://dl.acm.org/)
SpringerLink (http://springerlink.com)
Science Direct (http://www.sciencedirect.com/)
Para complementar a seleção dos artigos, também serão selecionados artigos de maneira
manual em conferências específicas das áreas, referente aos últimos 5 anos:
International Requirements Engineering Conference (www.requirements-
engineering.org/);
Agile Development Conference (www.agiledevelopmentconference.org);
7. Critérios de seleção dos estudos
Os estudos desta revisão foram selecionados de acordo com os critérios de inclusão e
exclusão, descritos nas seções a seguir.
8. Critérios de Inclusão
IC1. Estudos que tratem sobre requisitos em projetos de Software que utilizam
metodologias ágeis;
IC2. Estudos aplicados na indústria;
IC3. Pesquisas qualitativas ou quantitativas;
IC4. Estudos primários..
9. Critérios de Exclusão
EC1. Escrito em um idioma que não seja o Inglês;
EC2. Estudos duplicados ou repetidos;
EC3. Estudos que não tratem de elicitação, especificação e modelagem de requisitos de
software;
EC4. Estudos incompletos, rascunhos, slides ou resumos;
EC5. Estudos terciários e meta-análises;
92
EC6. Estudos acadêmicos que tratem do ensino de métodos ágeis;
EC7. Estudos que não abordem pelo menos uma metodologia ágil;
EC8. Artigos que não estão disponíveis gratuitamente para download nos ambientes
institucionais do CIn/UFPE ou do IFPB;
EC9. Estudos teóricos que não apresentam nenhum tipo de validação.
10. Processo de Seleção dos Estudos
De acordo com Kitchenham et al. (2007) o processo de seleção dos estudos possui múltiplas
fases, sendo sua condução realizada por dois ou mais pesquisadores. Esta pesquisa será
realizada em quatro fases, sempre conduzida por no mínimo dois de pesquisadores para
identificar potenciais estudos primários, conforme Figura I.
Figura I – Fases Processo de seleção dos estudos
Fonte: Cruzes e Dyba (2011).
Fase 1: A busca automática foi realizada a partir da ferramenta Reviewer que executou a
string em todos os engenhos simultaneamente. O resultado foi exportado para uma planilha
Excel compartilhada, a partir de onde foram realizadas as etapas seguintes. Em seguida foi
realizada a busca manual e alguns estudos relevantes foram acrescentados, formando assim a
base de dados inicial deste estudo.
1ª Fase
•Execução da busca manual;
•Execução da busca automática;
•Criar lista dos estudos resultantes das buscas manuais e automáticas.
2ª Fase
•Leitura do título e resumo;
•Aplicação dos critérios de inclusão e exclusão.
3ª Fase
•Leitura da Introdução e conclusão;
•Aplicação dos critérios de inclusão e exclusão.
4ª Fase
•Leitura completa dos estudos;
•Realização da avaliação da qualidade;
•Extração e síntese dos dados.
93
Fase 2: Cada estudo selecionado na etapa anterior foi analisado por um par de pesquisadores.
Os títulos e resumos foram lidos e os critérios de inclusão e exclusão foram aplicados. Se após
a análise da dupla ainda existir dúvida sobre a relevância do estudo, o mesmo era incluído
para ser analisado nas etapas seguintes. Uma lista consolidada com os estudos relevantes foi
compartilhada por todos os pesquisadores.
Fase 3: Cada estudo selecionado na etapa anterior foi analisado por um par de pesquisadores.
Os critérios foram aplicados com base na leitura da introdução e conclusão dos estudos
resultantes da segunda fase. Quando necessário, a leitura completa do estudo foi efetuada,
em caso de desacordo sobre a inclusão ou exclusão de um estudo, foi feita uma reunião de
consenso e se o conflito persistisse considerava-se a opinião de um terceiro pesquisador.
Fase 4: Os estudos resultantes da terceira fase foram lidos por completo para aplicação da
avaliação de qualidade contida no Formulário A seção 11. Os artigos foram avaliados por dois
pesquisadores e as respostas dos formulários foram tabuladas de tal forma que foi possível
que os membros pudessem comparar e discutir as respostas e entrar em um consenso. Os
estudos com somatório classificado nas faixas Média, Alta e Muito Alta foram encaminhados
para extração, os demais foram descartados nesta etapa. A extração de dados foi realizada
por dois pesquisadores e documentada no Formulário B seção 12.
11. Avaliação da Qualidade dos estudos
Os estudos foram analisados baseados na aplicação dos critérios de qualidade definidos
conforme sugestão de Kitchenham et al. (2007), Dyba e Dingsøyr (2008) e Kamei (2012),
apresentados no Formulário A nesta seção. Os artigos deverão ser lidos por pelo menos dois
pesquisadores que deverão aplicar o questionário para cada artigo, sendo necessária a leitura
completa desses artigos.
Para avaliar os artigos, foi utilizada a escala de três pontos de Likert(1932) que é um
instrumento que permite aos pesquisadores atribuírem respostas gradativas sobre suas
opiniões a respeito dos itens. As respostas do questionário deverão ser tabuladas de tal forma
que seja possível avaliar o grau de concordância\discordância das respostas entre os
pesquisadores.
94
Os itens de likert para avaliar os critérios são:
Não Atende (0): deve ser concedido no caso em que não existe nada no trabalho que
atenda ao critério avaliado.
Neutro (0.5): deve ser concedido no caso em que o trabalho não deixa claro se atende
parcialmente ou não ao critério avaliado;
Atende (1): deve ser concedido no caso em que o trabalho apresente no texto
atendimento ao critério avaliado.
A partir do somatório das notas de todos os critérios, os artigos foram classificados em 4
faixas de qualidade de acordo coma pontuação obtida, conforme podemos verificar na tabela
I.
Baixa Média Alta Muito Alta
0 ≤ N ≤ 2,5 3 ≤ N ≤ 5,5 6 ≤ N ≤ 8,5 9 ≤ N ≤ 10 Tabela I – Classificação de Qualidade.
Fonte: Elaborada pelo autor.
Formulário A
Este formulário foi utilizado para registrar os dados relativos à avaliação da qualidade
dos estudos dos estudos incluídos na pesquisa.
Avaliação de Qualidade ID:
Item Critério Avaliação
1
É um artigo de pesquisa?
Considere o seguinte:
(o artigo é resultado de uma pesquisa, ou é meramente uma
consolidação de lições aprendidas baseadas na opinião de um
especialista)
2
Existe uma descrição clara dos objetivos da pesquisa?
Considere o seguinte:
- Existe uma razão por que o estudo foi realizado?
- É possível identificar a questão de pesquisa?
95
3
Existe uma descrição adequada do contexto em que o estudo foi
realizado?
Considere o seguinte:
-A natureza da organização.
-As habilidades e a experiência do pessoal de software.
4
Desenho de Pesquisa:
O desenho de pesquisa foi adequado para atender os objetivos da
pesquisa?
Considere o seguinte:
- Foi justificado o método de pesquisa utilizado ?
5
Amostragem:
A estratégia de seleção da amostragem foi adequada aos objetivos da
pesquisa?
Considere o seguinte:
- O tamanho da amostra foi suficiente?
- Foi explanado como as pessoas e os casos foram selecionados?
- A amostra foi representativa?
6
Coleta de Dados:
Os dados foram coletados de maneira adequada a responder as
questões de pesquisa?
Considere o seguinte:
- As unidade de análise foram definidas?
- Está claro como os dados foram coletados?
- Foram utilizados critérios de qualidade para coletar os dados?
7
Análise de Dados:
A análise dos dados foi suficientemente rigorosa?
Considere o seguinte:
- O processo de análise dos dados foi descrito?
- Os dados coletados são suficientes para justificar os resultados?
- Foi utilizado algum critério de qualidade para analisar os dados?
8 Reflexividade:
96
A relação entre os pesquisadores e os participantes foi considerada de
forma adequada?
Considere o seguinte:
- Possíveis vieses foram considerados?
9
Resultados:
Há uma descrição clara dos resultados?
Considere o seguinte:
- Existem resultados explícitos?
- Há uma adequada discussão das evidências dos resultados?
- Limitações, ameaças a validade são apresentadas?
- Os resultados são relacionados com a questão de pesquisa?
10
Valor da Pesquisa:
O estudo possui valor para a academia ou para a indústria?
Considere o seguinte:
- É apresentada uma discussão a respeito da contribuição para prática
ou para literatura?
- Foram identificadas novas áreas de pesquisa?
- Foi discutido se os resultados podem ser aplicados em outras
populações? ou considerações de onde a pesquisa pode ser utilizada?
Somatório da Avaliação
Formulário A – Avaliação da qualidade
Fonte: elaborado pelo autor baseado em Dyba e Dingsøyr (2008).
12. Extração dos dados
Cruzes e Dyba (2011) afirmam que a extração dos dados é uma parte fundamental em
revisões sistemáticas, em que texto e dados dos estudos primários relevantes são obtidos de
forma explícita e consistente de acordo com uma estratégia definida. Assim, este estudo
adotou o processo de extração dos dados recomendo por Cruzes e Dyba (2011). O processo
consistiu em extrair os dados dos estudos primários relevantes de forma estruturada.
97
As informações relevantes foram registradas no Formulário B e os estudos que não
apresentaram informações relevantes para responder as questões de pesquisa foram
excluídos.
FORMULÁRIO DE EXTRAÇÃO DE DADOS ID: TÍTULO: ÁREA FIM:
DESCRIÇÃO GERAL:
PARTICIPAÇÃO DO CLIENTE:
CARACTERÍSTICAS EQUIPE DESENVOLVIMENTO:
TRABALHOS FUTUROS:
DADOS DE RESULTADOS E EVIDÊNCIAS QP1 - Quais técnicas\processos de engenharia de requisitos estão sendo utilizadas em
projetos que adotam metodologias ágeis com objetivo de LEVANTAR requisitos?
QP2 - Quais técnicas\processos de engenharia de requisitos estão sendo utilizadas em
projetos que adotam metodologias ágeis com objetivo de ESPECIFICAR requisitos?
QP3 - O que atualmente se sabe sobre os DESAFIOS e LIMITAÇÕES das técnicas de
Engenharia de Requisitos adotadas em projetos ágeis?
EVIDÊNCIAS DE CONTEXTO Dados de Publicação Dados de Contexto Referência (título, ano,
etc.) Tipo do estudo
Método de
pesquisa
Coleta de dados
Análise dos dados
Tamanho da
amostra
Metodologia ágil
Formulário B – Coleta de Dados
Fonte: elaborado pelo autor baseado em Dyba e Dingsøyr (2008).
98
13. Síntese e Análise dos dados
A síntese e análise dos dados foram construídas quase que paralelamente baseadas em uma
abordagem qualitativa, para resumir as evidências extraídas dos estudos primários incluídos
nesta pesquisa (KITCHENHAM et al., 2007). Assim, este estudo conduziu uma síntese e análise
temática dos dados, conforme processo recomendado por Cruzes e Dyba (2011), que poder
ser visualizado na Figura II.
Figura II – Processo de síntese temática
Fonte: Cruzes e Dyba (2011).
O processo resumido consistiu em fazer uma leitura inicial dos estudos, depois foram
extraídos os dados e evidências, identificando os códigos (textos) de dados, esses códigos
foram traduzidos em temas, em seguida identificados os temas de ordem superior para
criação do modelo que explicasse o fenômeno ou questões de pesquisa, conforme sugere
Cruzes e Dyba (2011). Para facilitar o processo de análise e síntese das evidências foi utilizada
a ferramenta Microsoft Excel. A partir da coleta dos dados, foram realizadas as comparações e
análises.
14. Referências
CRUZES, D.S; DYBA, T. Recommended Steps for Thematic Synthesis in Software Engineering.
ESEM, 2011.
99
DYBA, T.; DINGSøYR, T. EmpiricalStudiesofAgile Software Development: A
SystematicSeview. Information and Software Technology, Butterworth-Heinemann Newton,
MA, USA, v. 50, n. 9, p. 833-859, August 2008.
Dyba, T., Kampenes, V., Sjoberg, D. (2005) “A Systematic Review of Statistical Power in Software
Engineering Experiments”, Journal of Information and Software Technology, v. 1, n. 11.
KAMEI, F., K. Benefícios e limitações das metodologias ágeis no desenvolvimento de
software. 2012. 296f. Dissertação - Centro de Informática- CIn, Universidade Federal de
Pernambuco - UFPE, Recife, 2012.
KITCHENHAM, B.; CHARTERS, S. Guidelines for performing Systematic Literature Reviews in
Software Engineering. Keele University and Durham University Joint Report, Tech. Rep. EBSE
2007-001, 2007.
LIKERT, R. A Technique for the Measurement of Attitudes. Archives of Psychology 140: pp. 1-
55, 1932.
100
APÊNDICE B – Estudos Primários Selecionados
ID ANO FONTE REFERÊNCIA
01 2012 IEEE
Rudorfer, A.; Stenzel, T.; Herold, G.: A Business Case
for Feature-Oriented Requirements Engineering
02 2011 ACM
Bjarnason,E., Wnuk,K., Regnell, B.: A case study on
benefits and side-effects of agile practices in large-scale
requirements engineering
03 2008 ACM
Thomson. C, Holcome,M., Cowling, T., Simons, T.,
Michaelides, G.: A pilot study of comparative customer
comprehension between extreme x-machine and uml
models
04 2008 SCOPUS
Cao, L.A., Ramesh,B.B : Agile requirements
engineering practices: An empirical study
05 2007 ACM
Bang, T.J.: An agile approach to requirement
specification
06 2012 SCIENCE_DIRECT
Bjarnason,E., Wnuk, K., Regnell,B.: Are you biting off
more than you can chew? A case study on causes and
effects of overscoping in large-scale software
engineering
07 2012 IEEE
Haugset,B., Stalhane,T.: Automated Acceptance
Testing as an Agile Requirements Engineering Practice
08 2012 ACM
Abdullah, B.N.N., Honiden, S., Sharp, H., Nuseibeh,
B., Notkin, D.: Communication patterns of agile
requirements engineering
09 2013 SCOPUS
Batool, A., Motla, Y.H., Hamid, B., Asghar, S., Riaz,
M., Mukhtar, M., Ahmed, M.: Comparative study of
traditional requirement engineering and Agile
requirement engineering
10 2011 ACM
Lee,J.C, Judge,T.K, McCrickard, D.S.: Evaluating
eXtreme scenario-based design in a distributed agile
team
11 2006 IEEE
Baskerville, R., Ramesh, B., Levine, L., Pries-Heje, J.:
High-Speed Software Development Practices: What
Works, What Doesn't
12 2012 IEEE
Gregorio, D.D.: How the Business Analyst supports and
encourages collaboration on agile projects
13 2013 IEEE
Lorber, A.A., Mish, K.D.: How We Successfully
Adapted Agile for a Research-Heavy Engineering
Software Team
14 2011 IEEE
Mahmud, I., Veneziano, V.: Mind-mapping: An
effective technique to facilitate requirements
engineering in agile software development
15 2012 SCOPUS
Farid, W.M., Mitropoulos, F.J.: Novel lightweight
engineering artifacts for modeling non-functional
requirements in agile processes
16 2013 ACM
Abdallah, A., Hassan, R., Azim, M.A.: Quantified
extreme scenario based design approach
17 2008 ACM
Obendorf,H., Finck, M.: Scenario-based usability
engineering techniques in agile development processes
101
18 2012 IEEE
Read, A., Briggs, R.O.: The Many Lives of an Agile
Story: Design Processes, Design Products, and
Understandings in a Large-Scale Agile Development
Project
19 2009 SCIENCE_DIRECT
Sharp,H., Robinson,H., Petre, M.: The role of physical
artefacts in agile software development: Two
complementary perspectives
20 2004 IEEE
Martin, A., Biddle, R., Noble, J.: The XP customer role
in practice: three studies
21 2010 REC
Savolainen,J., Kuusela,J., Vilavaara, A.: Transition to
Agile Development - Rediscovery of Important
Requirements Engineering Practices
22
2013 Snowballing
Batool, A., Hafeez, Y., Asghar, S., Abbas, M.A.,
Hassan, M.S.: A Scrum Framework for Requirement
Engineering Practices
23 2010 Snowballing Sem A.M., Hemachandran, K.: Elicitation of Goals in
Requirements Engineering using Agile Methods
24 2010 Snowballing Hoda, R., Noble,J., Marshall, S.: Agile Undercover:
When Customers Don’t Collaborate
102
APÊNDICE C – Avaliação da Qualidade dos Estudos
AVALIAÇÃO DE QUALIDADE
ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 SOMA AVALIAÇÃO
01 0 0,5 1 0 0 0 0 0 0,5 1 3,0 Média
02 1 1 1 1 0,5 1 1 0 1 1 8,5 Alta
03 1 1 1 1 0,5 1 1 0,5 1 1 9,0 Muito Alta
04 1 0,5 1 1 1 1 1 0,5 1 1 9,0 Muito Alta
05 1 0,5 1 0 0,5 0,5 0 0 0,5 1 5,0 Média
06 1 1 1 1 0,5 1 1 1 1 1 9,5 Muito Alta
07 1 1 1 0,5 0,5 0 0 0 1 1 6,0 Alta
08 1 1 1 1 0,5 1 1 0 0,5 1 8,0 Alta
09 1 0,5 0,5 0,5 0,5 0 0 0 0,5 0 3,5 Média
10 1 0,5 1 0 0 0 0 0 0,5 1 4,0 Média
11 1 0,5 1 1 1 1 1 0 0,5 1 8,0 Alta
12 1 0,5 1 0 0 0 0 0 0,5 1 4,0 Média
13 0 0,5 1 0 0 0 0 0 0,5 1 3,0 Média
14 1 1 1 1 1 0,5 1 0 1 1 8,5 Alta
15 1 0,5 1 1 1 1 0,5 0 1 1 8,0 Alta
16 1 0,5 1 1 1 1 0,5 0 0,5 1 7,5 Alta
17 0 0,5 1 0 0 0 0 0 0,5 1 3,0 Média
18 1 0,5 1 1 1 1 0,5 0 0,5 1 7,5 Alta
19 1 0,5 0,5 1 1 1 0,5 0 0,5 1 7,0 Alta
20 1 0,5 1,0 1 1 1 1 0 0,5 1 8,0 Alta
21 0 0,5 1 0 0 0 0 0 0,5 1 3,0 Média
22 1 0,5 0,5 1 0,5 0 0,5 0 0,5 1 5,5 Média
23 1,0 0,5 0,5 0,5 0,5 0,5 0,0 0,0 0,5 1,0 5,0 Média
24 1 1 1 1 1 1 0,5 0,0 1 1 8,5 Alta
103
APÊNDICE D – Evidências de Contexto dos Estudos
Selecionados
ID Tipo de Estudo
Método Ágil Método de
Pesquisa Tipo de Sujeito
AMOSTRA
EMPRESAS PESSOAS
01 Empírico SCRUM - Profissional 1
02 Empírico SCRUM Estudo de Caso Profissional 1 9
03 Empírico - Experimento Profissional 3 9
04 Empírico SCRUM, XP
Grounded Theory, Estudo de Caso
Profissional 16 59
05 Empírico XP - Profissional 1 5
06 Empírico SCRUM, XP Estudo de Caso Profissional 1 9
07 Empírico - Estudo de Caso Profissional 1 4
08 Empírico XP Etnografia Profissional 1 7
09 Empírico SCRUM, XP Estudo de Caso Profissional 1 12
10 Empírico SCRUM, XP Pesquisa Ação Profissional 1
11 Empírico -
Grounded Theory, Estudo de Caso
Profissional 10 35
12 Empírico SCRUM - Profissional 1
13 Empírico SCRUM - Profissional 1 22
14 Empírico SCRUM Experimento Profissional 1 38
15 Empírico SCRUM, XP Estudo de Caso Profissional 1
16 Empírico SCRUM, XP Estudo de Caso Profissional 1 6
17 Empírico XP - Profissional 1
18 Empírico SCRUM Pesquisa Ação Profissional 1
19 Empírico XP Etnografia Profissional 1
20 Empírico XP Estudo de Caso Profissional 3 20
21 Empírico SCRUM - Profissional 2
22 Empírico SCRUM, FDD Estudo de Caso,
Survey Profissional 1
23 Empírico - Estudo de Caso Profissional 1 5
24 Empírico SCRUM, XP Grounded Theory Profissional 16 30
104
APÊNDICE E – Desafios e Limitações por Estudos
Selecionados