Escolar Documentos
Profissional Documentos
Cultura Documentos
por
DANIELA DE CASTRO PEREIRA ALVES
Dissertação de Mestrado
RECIFE-PE 2015
UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO
CIn - CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
RECIFE-PE 2015
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
______________________________________________________
Profa. Carla Taciana Lima Lourenço Silva Schuenemann
Centro de Informática/UFPE
______________________________________________________
Profa. Fernanda Maria Ribeiro de Alencar
______________________________________________________
Prof. Alexandre Marcos Lins de Vasconcelos
___________________________________________________
Ao meu orientador Alexandre Marcos Lins de Vasconcelos por todo seu apoio,
incentivo e paciência.
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
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
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.
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.
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
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.
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
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
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).
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).
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).
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:
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:
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.
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.
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
(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
Questões de Pesquisa
Estratégia de Busca
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.
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
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
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.
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.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.
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.
SCIENCE_DIRECT
26%
IEEE
4%
Muito
Alta
12%
Média
38%
Alta
50%
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.
49
15,5 15,5 16
13,5 13,5
11
CQ1 CQ2 CQ3 CQ4 CQ5 CQ6 CQ7 CQ8 CQ9 CQ10
20
15
10
0
CQ5 CQ6 CQ7 CQ8
Qtd que atenderam o critério
9 12 8 1
(Nota 1,0)
Qtd que atenderam parcialmete
9 3 6 2
o critério (Nota 0,5)
Qtd que não atenderam o
6 9 10 21
Critério (Nota 0,0)
4
3 3 3
1 1 1 1
XP
43%
SCRUM
53%
12
3
2 2
1 1
2 2 2 2 2
1 1 1 1 1 1 1
2
1 1 1 1
QUESTIONÁRIOS
GRUPO FOCAL
BRAINSTORM
WORKSHOP
MEETINGS
TOTAL
JAD
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
10 9
7
3 2 2 2 3 3 2
1 1 1 1 1 1 1 1
MAPAS MENTAIS
USER STORIES
STORY CARD
SCENARIOS
PROTOTIPO
PERSONAS
DIAG. ATIV
USE CASE
DOC REQ.
FEATURE
INVEST
TOTAL
WALL
XSBD
TASK
GPM
AUC
ACC
XXM
ALC
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
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.
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.
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.
“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
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.
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].
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.
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
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.
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.
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
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.
RICO, D.F.; SAYANI, H.H.; SONE, S. The Business value of agile software
methods. J.Ross Publishing, Ind., Fort Lauderdale (2009).
THOMSON, C.; HOLCOMBE, W. Applying XP Ideas Formally: The Story Card and
Extreme X-Machines. 1st South-East European Workshop on Formal Methods, 2003.
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.
RECIFE-PE
DEZEMBRO DE 2013
88
EQUIPE
1. Objetivo
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?
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
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”.
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.
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).
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:
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
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.
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.
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.
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
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.
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
DESCRIÇÃO GERAL:
PARTICIPAÇÃO DO CLIENTE:
TRABALHOS FUTUROS:
EVIDÊNCIAS DE CONTEXTO
Dados de Publicação Dados de Contexto
Referência (título, ano, Tipo do Método Coleta de Análise Tamanho Metodologia
etc.) estudo de dados dos dados da ágil
pesquisa amostra
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.
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., 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.
LIKERT, R. A Technique for the Measurement of Attitudes. Archives of Psychology 140: pp. 1-
55, 1932.
100
AMOSTRA
Tipo de Método de
ID Método Ágil Tipo de Sujeito
Estudo Pesquisa EMPRESAS PESSOAS