uso de modelos i* para enriquecer requisitos em métodos …palavras-chave: requisitos Ágeis,...
TRANSCRIPT
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
MESTRADO EM SISTEMAS E COMPUTAÇÃO
Uso de Modelos i* para Enriquecer Requisitos
em Métodos Ágeis
Aline de Oliveira Prata Jaqueira
Natal-RN
Março de 2013
Aline de Oliveira Prata Jaqueira
Uso de Modelos i* para Enriquecer Requisitos em
Métodos Ágeis
Dissertação de Mestrado apresentada ao
Programa de Pós-Graduação em Sistemas e
Computação do Departamento de Informática e
Matemática Aplicada da Universidade Federal do
Rio Grande do Norte como requisito parcial para
a obtenção do grau de Mestre em Sistemas e
Computação.
Linha de pesquisa:
Engenharia de Software
Orientadora
Profª. Drª. Márcia Jacyntha Nunes Rodrigues Lucena
PPgSC – Programa de Pós-Graduação em Sistemas e Computação
DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra
UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN
Março de 2013
Dissertação de Mestrado sob o título Uso de Modelos i* para Enriquecer Requisitos em
Métodos Ágeis apresentada por Aline de Oliveira Prata Jaqueira e aceita pelo
Programa de Pós-Graduação em Sistemas e Computação do Departamento de
Informática e Matemática Aplicada da Universidade Federal do Rio Grande do
Norte, sendo aprovada por todos os membros da banca examinadora abaixo
especificada:
__________________________________________
Profª. Drª. Márcia Jacyntha Nunes Rodrigues Lucena
Presidente
DIMAp – Departamento de Informática e Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do Norte
__________________________________________
Prof. Dr. Eduardo Henrique da Silva Aranha
Examinador Interno ao Programa
DIMAp – Departamento de Informática e Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do Norte
__________________________________________
Profª. Drª. Fernanda Maria Ribeiro Alencar
Examinadora Externa à Instituição
Departamento de Eletrônica e Sistemas
UFPE –Universidade Federal de Pernambuco
Natal-RN, 01 de março de 2013.
A meu pai (in memoriam)
Agradecimentos
A Deus. Pelas bênçãos em minha vida.
A meu marido, meu amor. Pelo apoio e incentivo sempre. Pela compreensão nos nossos momentos abdicados em função das minhas obrigações.
À minha querida família que, em sua simplicidade, mesmo sem entender muito bem o que eu estava fazendo, apoiava, torcia e se orgulha de ter alguém “estudado” entre eles.
À minha orientadora, Professora Márcia. Pela confiança em mim depositada, pelos conhecimentos compartilhados e observações fundamentais para melhoria deste trabalho. Pelo seu lado humano e acessível que me encantou desde a primeira entrevista e permitiu que eu realizasse este trabalho de forma tranquila.
Aos professores membros da banca avaliadora, Eduardo Aranha e Fernanda Alencar. Pela disponibilidade em avaliar meu trabalho e pelas contribuições.
À professora Roberta Souza. Pelos ensinamentos enquanto fui sua tutora e pela fundamental ajuda na publicação do artigo do FEES 2012.
A todos os professores com os quais tive aulas. Pelos ensinamentos, compartilhamentos e trocas.
Ao bolsista Bernardo Gurgel, pelas ajudas e disponibilização do material da empresa em que atua.
A todos que participaram da avaliação da minha proposta, no estudo de caso. Pela disponibilidade e participação.
Aos colegas do mestrado, principalmente àqueles com os quais realizei trabalhos em grupo, pela troca e colaboração.
A todos que direta ou indiretamente me acompanharam nessa jornada, torcendo, me ajudando, me ouvindo, me incentivando.
“Ninguém ignora tudo. Ninguém sabe tudo.
Todos nós sabemos alguma coisa. Todos nós ignoramos alguma coisa.
Por isso aprendemos sempre.” Paulo Freire
Uso de Modelos i* para Enriquecer Requisitos em Métodos Ágeis
Autora: Aline de Oliveira Prata Jaqueira.
Orientadora: Profª. Drª. Márcia Jacyntha Nunes Rodrigues Lucena.
RESUMO
A atividade de engenharia de requisitos é vista nos métodos ágeis como atividade burocrática tornando o processo menos ágil. No entanto, a falta de documentação no ambiente de desenvolvimento ágil é apontada como um dos principais desafios da metodologia. Assim, observa-se a existência de um contrassenso entre o que a metodologia ágil defende e o resultado que ocorre no ambiente real. Por exemplo, nos métodos ágeis as histórias de usuário são a forma mais usual para descrever requisitos. No entanto, essa maneira de descrever requisitos ainda não é suficiente, pois as histórias de usuário constituem um artefato muito restrito para representar e detalhar os requisitos. As atividades de verificar questões como o contexto do software e dependências entre as histórias também são limitadas com o uso somente desse artefato. No contexto de engenharia de requisitos existem as abordagens orientadas a metas que trazem vantagens para a documentação de requisitos, entre elas, completude dos requisitos, análise de alternativas e suporte à racionalização de requisitos. Dentre essas abordagens destaca-se a técnica de modelagem i* que fornece uma visão gráfica dos atores envolvidos no sistema e suas dependências. Esta dissertação propõe um recurso complementar para diminuir essa carência de documentação existente nos métodos ágeis. Assim, o objetivo deste trabalho é fornecer uma visão gráfica dos requisitos do software e seus relacionamentos através de modelos i*, enriquecendo assim os requisitos nos métodos ágeis. Para isso propõe-se um conjunto de heurísticas para realizar o mapeamento dos requisitos representados como histórias de usuário em modelos i*. Esses modelos poderão ser utilizados como uma forma de documentação dos requisitos no ambiente ágil, pois através do mapeamento para os modelos i*, os requisitos serão visualizados de maneira mais abrangente e com seus devidos relacionamentos de acordo com o ambiente de negócio que vão atender.
Palavras-chave: Requisitos Ágeis, Histórias de Usuário, Modelo i*.
ABSTRACT
The activity of requirements engineering is seen in agile methods as bureaucratic
activity making the process less agile. However, the lack of documentation in agile
development environment is identified as one of the main challenges of the
methodology. Thus, it is observed that there is a contradiction between what agile
methodology claims and the result, which occurs in the real environment. For
example, in agile methods the user stories are widely used to describe requirements.
However, this way of describing requirements is still not enough, because the user
stories is an artifact too narrow to represent and detail the requirements. The
activities of verifying issues like software context and dependencies between stories
are also limited with the use of only this artifact. In the context of requirements
engineering there are goal oriented approaches that bring benefits to the
requirements documentation, including, completeness of requirements, analysis of
alternatives and support to the rationalization of requirements. Among these
approaches, it excels the i * modeling technique that provides a graphical view of the
actors involved in the system and their dependencies. This work is in the context of
proposing an additional resource that aims to reduce this lack of existing
documentation in agile methods. Therefore, the objective of this work is to provide a
graphical view of the software requirements and their relationships through i *
models, thus enriching the requirements in agile methods. In order to do so, we
propose a set of heuristics to perform the mapping of the requirements presented as
user stories in i * models. These models can be used as a form of documentation in
agile environment, because by mapping to i * models, the requirements will be
viewed more broadly and with their proper relationships according to the business
environment that they will meet.
Keywords: Agile Requirements, User Stories, i * Model.
Lista de figuras
Figura 1: Exemplo de Histórias de Usuário ................................................................................ 21
Figura 2: Exemplo de Notação do Modelo SD ............................................................................ 29
Figura 3: Exemplo de Notação do Modelo SR ............................................................................ 31
Figura 4: Exemplo de Notação da Associação IS_A ................................................................... 32
Figura 5: Visão Geral do Mapeamento das Histórias de Usuário para Modelos I* ................. 35
Figura 6: Exemplo de Mapeamento para o Modelo SD ............................................................. 37
Figura 7: Exemplos de Cartões de Histórias ............................................................................... 38
Figura 8: Exemplo SD ................................................................................................................... 38
Figura 9: Exemplo de Mapeamento para o Modelo SR .............................................................. 39
Figura 10: Exemplos de Cartões de Histórias ............................................................................. 40
Figura 11: Exemplo SR .................................................................................................................. 40
Figura 12: Modelo SD do Exemplo de Aplicação ....................................................................... 41
Figura 13: Modelo SR do Exemplo de Aplicação........................................................................ 42
Lista de tabelas
Tabela 1: Desafios para requisitos em métodos ágeis ................................................................ 23
Tabela 2: Desafios para histórias de usuário ............................................................................... 26
Tabela 3: Desafios das Histórias de Usuário e Auxílio na Técnica i* ........................................ 34
Tabela 4: Correspondência no Mapeamento de Elementos das Histórias de Usuário e da
Técnica i* ........................................................................................................................................ 36
Tabela 5: Histórias de Usuário do Sistema de Login .................................................................. 41
Tabela 6: Questões de Pesquisa do Estudo de Caso ................................................................... 45
Tabela 7: Respostas dos Participantes para o Questionamento 1 e 2. ....................................... 48
Tabela 8: Respostas dos Participantes para o Questionamento 2 .............................................. 49
Tabela 9: Respostas dos Participantes para os Questionamentos 5,6 e 7 .................................. 51
Tabela 10: Respostas dos Participantes para os Questionamentos 3,4 e 5 ................................ 51
Tabela 11: Respostas dos Participantes para o Questionamento 8/6 ........................................ 54
Tabela 12: Respostas dos Participantes para o Questionamento 9/7 ........................................ 55
Tabela 13: Respostas dos Participantes para os Questionamentos 11 e 8 ................................. 57
Tabela 14: Comparação Entre os Trabalhos Relacionados ......................................................... 64
Sumário
1 Introdução ...................................................................................................................... 12
1.1 Motivação ................................................................................................................. 13
1.2 Trabalho Proposto .................................................................................................... 14
1.3 Objetivos ................................................................................................................... 15
1.4 Metodologia .............................................................................................................. 15
1.5 Organização do trabalho ......................................................................................... 16
2 Fundamentação Teórica ................................................................................................ 17
2.1 Metodologias Ágeis ................................................................................................. 17
2.2 Engenharia de Requisitos ........................................................................................ 18
2.3 Engenharia de Requisitos nos Métodos Ágeis....................................................... 19
2.3.1 Histórias de Usuários ...................................................................................... 20
2.4 Desafios dos Requisitos nos Métodos Ágeis .......................................................... 22
2.4.1Desafios das Histórias de Usuário .................................................................. 24
2.5 Engenharia de Requisitos Orientada a Objetivos .................................................. 26
2.5.1 Técnica de Modelagem i* ............................................................................... 27
2.5.1.1 Modelos i* SD e SR ....................................................................................... 29
3 Uso de Modelos i* para Enriquecer Requisitos em Métodos Ágeis ....................... 33
3.1 Visão Geral da Proposta .......................................................................................... 33
3.2 Construção dos Modelos i*...................................................................................... 35
3.3 Exemplo de Uso ....................................................................................................... 40
3.4 Discussão .................................................................................................................. 42
4 Estudo de Caso............................................................................................................... 44
4.1 Objetivo ..................................................................................................................... 44
4.2 Planejamento do Estudo de Caso ........................................................................... 44
4.2.1 Participantes .................................................................................................... 44
4.2.2 Artefatos de Entrada ....................................................................................... 45
4.2.3 Questões de Pesquisa ...................................................................................... 45
4.2.4 Preparação do Ambiente e Treinamento para o Estudo de Caso ................ 45
4.3 Execução do Estudo de Caso ................................................................................... 46
4.4 Análise dos Dados.................................................................................................... 47
4.4.1 Discussão.......................................................................................................... 58
4.5 Ameaças à Validade ................................................................................................. 58
4.5.1 Validade Interna .............................................................................................. 59
4.5.2 Validade Externa ............................................................................................. 59
5 Trabalhos Relacionados ............................................................................................... 60
5.1 “Integrando Scrum e a Modelagem de Requisitos Orientada a Objetivos por
meio do SCRUM i*” .......................................................................................................... 60
5.2 “Adopting Agile Methods: can Goal-Oriented Social Modeling Help?” ............ 61
5.3 “The New User Story Backlog is a Map” ............................................................... 62
5.4 Tabela Comparativa dos Trabalhos Relacionados ................................................ 63
6 Considerações Finais .................................................................................................... 66
6.1 Contribuições ............................................................................................................ 67
6.2 Trabalhos Futuros .................................................................................................... 67
Referências ........................................................................................................................ 70
Apêndice A – Escopo do Sistema Utilizado no Estudo de Caso ................................ 76
Apêndice B – Histórias de Usuário Utilizadas no Estudo de Caso ............................ 77
Apêndice C – Modelos SD e SR Utilizado com o Grupo de Equipe de
Desenvolvimento no Estudo de Caso ......................................................................... 78
Apêndice D – Questionário I Aplicado ao Grupo de Engenheiros de Requisitos no
Estudo de Caso ............................................................................................................... 79
Apêndice E – Questionário II Aplicado ao Grupo de Equipe de Desenvolvimento
no Estudo de Caso ......................................................................................................... 82
Apêndice F – Revisão Sistemática ..................................................................................... 85
12
1 Introdução
A dependência da sociedade contemporânea por computadores é uma
realidade. Grande parte de nossas atividades é mediada por algum software. A
rápida transformação do ambiente de negócios é um desafio para o desenvolvimento
de software, pois tem como propriedade uma constante evolução. A exigência por
programas cada vez mais especializados e avançados implica na demanda por
maneiras mais apropriadas de desenvolvê-los (Bassi, 2008).
Nesse contexto, os métodos ágeis estão inseridos em ambientes de
desenvolvimento de software dinâmicos onde os requisitos estão em constante
modificação e são construídos a partir do feedback das partes interessadas
(stakeholders) no decorrer do desenvolvimento. Esses métodos vêm ganhando muito
interesse entre os profissionais e pesquisadores (Cao e Ramesh, 2008), pois utilizam
processos mais simplificados com atividades menos burocráticas associadas ao
desenvolvimento (Fowler, 2011).
Nos métodos tradicionais as atividades de engenharia de requisitos estão
voltadas para elicitar, organizar, documentar e gerenciar os requisitos do software a
ser desenvolvido. Por exemplo, no processo de engenharia de requisitos proposto
por Sommerville (2007) existem atividades a serem realizadas antes da
implementação como estudo de viabilidade, elicitação e análise, especificação e
validação dos requisitos. Como resultado final desse processo um documento de
requisitos é gerado.
Na Engenharia de Requisitos Orientada a Objetivos ou GORE do inglês (Goal-
Oriented Requirements Engineering) (Lamsweerde, 2001) os requisitos são elicitados a
partir das metas organizacionais dos envolvidos no processo. As metas dos
stakeholders são utilizadas para elicitar, elaborar, estruturar, especificar, analisar,
negociar, documentar e modificar os requisitos (Lamsweerde, 2001). A técnica de
modelagem i* (Yu, 1995) é uma das mais relevantes abordagens GORE largamente
reconhecida e usada na engenharia de requisitos nos últimos anos. Essa técnica
fornece uma visão gráfica dos atores envolvidos no sistema com suas dependências.
Nos métodos ágeis os requisitos são desenvolvidos de forma incremental, de
acordo com as prioridades do cliente. Além disso, a elicitação é realizada com
clientes que fazem parte da equipe de desenvolvimento. Para isso, os clientes
13
utilizam cartões para escrever histórias1 do que o sistema precisa fazer (user stories) e
priorizam as mesmas de acordo com o valor do seu negócio. Esses cartões são os
artefatos de saída da atividade de elicitação dos requisitos nos métodos ágeis.
Mesmo a documentação de requisitos sendo vista como atividade burocrática
em métodos ágeis (Fowler, 2011), a falta de documentação é apontada como um de
seus principais desafios (Jaqueira et al., 2012).
Esta dissertação se insere no contexto de propor um recurso complementar que visa diminuir a carência de documentação dos projetos de desenvolvimento ágil de software. As histórias de usuário são mapeadas para os modelos i*, que são usados como um artefato complementar para a atividade de requisitos. Através dos modelos gerados, busca-se dar suporte aos stakeholders fornecendo uma representação visual e
abrangente das histórias de usuário e dos seus relacionamentos. Além disso, a carga semântica da técnica i* é aplicada às histórias de usuário, o que contribui também para enriquecer os requisitos nos métodos ágeis.
1.1 Motivação
Para melhor entender como os requisitos são tratados nos métodos ágeis e os
desafios associados a esse tema, foi realizado um trabalho de revisão sistemática
(Apêndice F) acerca das principais fontes de discussão sobre o assunto (Jaqueira et
al., 2012). Os trabalhos selecionados para a revisão sistemática partiam de estudos
empíricos baseados na experiência da utilização ou migração para métodos ágeis.
Dos nove artigos selecionados para o trabalho, cinco deles destacam a falta de
documentação nos métodos ágeis como um desafio (Cao e Ramesh, 2008), (Gallardo-
Valencia e Sim, 2009), (Savolainen; Kuusela e Vilavaara, 2010), (Espinoza e
Garbajosa, 2011), (Bjarnason; Wnuk e Regnell, 2011).
O desafio da documentação mínima nos métodos ágeis mostra-se acentuado
quando ocorre uma falha na comunicação do projeto, devido, por exemplo, à
rotatividade de pessoal, mudanças rápidas nos requisitos, indisponibilidade do
cliente (Cao e Ramesh, 2008); (Gallardo-Valencia e Sim, 2009). A tarefa de distinguir
os requisitos de usuário dos requisitos de sistema torna-se mais trabalhosa sem
suporte da documentação (Savolainen; Kuusela e Vilavaara, 2010). Segundo
Espinoza e Garbajosa (2011), a rastreabilidade de requisitos, quando utilizados em
métodos ágeis, é deficiente devido à ausência de uma documentação adequada. Para
1 Utilizou-se a palavra história, pois de acordo com o Dicionário Contemporâneo da Língua
Portuguesa Caldas Aulete (http://aulete.uol.com.br/estória) o termo estória é classificado como
brasileirismo, sendo que a palavra foi proposta, mas deve ser usada a forma história.
14
Bjarnason; Wnuk e Regnell (2011), manter um documento de requisitos atualizado é
uma atividade complexa nos métodos ágeis.
Observa-se então, de acordo com a revisão sistemática (Jaqueira et al., 2012), a
existência de um contrassenso entre o que a metodologia ágil defende, ou seja, a
documentação mínima e a necessidade de mais documentação no ambiente real. As
equipes manifestam carência por algum tipo de documentação no desenvolvimento
ágil de modo a amenizar os desafios enfrentados pela falta da mesma.
1.2 Trabalho Proposto
Este trabalho propõe o uso de modelos i* para enriquecer requisitos em métodos ágeis
visando diminuir a carência de documentação nos projetos de desenvolvimento ágil
de software. Os conceitos das histórias de usuários serão empregados juntamente
com os conceitos da técnica i* (Yu, 1995). Portanto, esse recurso complementar
poderá ser usado pelos desenvolvedores do ambiente ágil para melhorar a
visualização e acompanhamento dos requisitos.
Na técnica i* busca-se saber o que o ator quer, como ele consegue o que quer e de
quem depende para conseguir o que quer. Inclui dois modelos básicos, o modelo de
dependência estratégica (SD – Strategic Dependency) que descreve as relações de
dependência entre os atores e o modelo de raciocínio estratégico (SR – Strategic
Rationale) que demonstra como os atores atingem suas metas.
O foco nos stakeholders e seus relacionamentos para descrição de requisitos é uma
característica da técnica i*, onde os atores dependem uns dos outros para atingir suas
metas. Os métodos ágeis também se concentram em fatores humanos e apostam na
entrega de valor para o cliente (Bassi, 2008). Reconhecem as pessoas como os
principais impulsionadores do sucesso do projeto, o que produz uma nova
combinação de valores e princípios que definem a metodologia (Highsmith e
Cockburn, 2001). A preocupação comum com os stakeholders justifica a escolha da
técnica i* para representar os requisitos ágeis, ou seja, as histórias de usuário.
Assim, as histórias de usuário serão mapeadas para modelos i* gerando uma
visão gráfica e abrangente dos requisitos do software e seus relacionamentos. Esse
mapeamento poderá ser utilizado como uma forma de documentação dos requisitos
no ambiente ágil. Ao utilizar os modelos da técnica i* a partir das histórias de
usuário, a característica de agilidade dos projetos poderá ser mantida pelo fato de a
visualização através dos modelos ser mais simples e rápida. Modelos ajudam a
organizar e apresentar grandes quantidades de informações e dão contexto aos
detalhes. Proporcionam agrupamentos visuais que permitem analisar rapidamente
grandes quantidades de informações a curto prazo (Beatty e Chen, 2012) .
15
Como contribuição deste trabalho um conjunto de heurísticas é proposto para
realização do mapeamento das histórias de usuário para a técnica i* e, através desse
mapeamento, se propõe amenizar a carência de documentação nos projetos de
desenvolvimento ágil. Uma vez que os modelos i* são representações gráficas dos
requisitos, ter-se-á uma maneira abrangente e visual de enxergar as histórias de
usuário, amenizando assim a carência de documentação nos projetos de
desenvolvimento ágil de software, melhorando a visualização do contexto do
sistema, facilitando o acesso aos requisitos, contribuindo para a tomada de decisão
no ambiente de desenvolvimento.
1.3 Objetivos
O objetivo principal deste trabalho é fornecer um recurso complementar para o
ambiente de desenvolvimento ágil, o uso de modelos i* para enriquecer requisitos em
métodos ágeis. Além disso, este trabalho apresenta os seguintes objetivos específicos:
estudo sistemático sobre desafios dos requisitos nos métodos ágeis;
estudo e entendimento das estruturas usadas nos cartões de história;
estudo e entendimento das estruturas usadas nos modelos i*;
desenvolvimento de heurísticas para o mapeamento entre as histórias de
usuário e modelos i*;
avaliação da proposta através de um estudo de caso.
1.4 Metodologia
Conforme a seção 1.1, a partir da revisão sistemática foi possível visualizar os
principais desafios dos requisitos nos métodos ágeis para, posteriormente, direcionar
qual deles seria o foco desta dissertação. Escolhido o desafio de carência de
documentação de requisitos nos métodos ágeis, foram estudadas as técnicas
disponíveis que poderiam ser usadas. Assim chegou-se na proposta do uso de modelos
i* para enriquecer requisitos em métodos ágeis.
Para avaliar a proposta desta dissertação, aplicamos o método de pesquisa
estudo de caso, pois o mesmo foi conduzido em um ambiente do mundo real, sendo
puramente observacional, possuindo realismo e estudando os efeitos de uma
modificação, por exemplo, em estudos pré e pós-evento.
Quanto aos objetivos, o estudo de caso é exploratório e descritivo. Sendo
exploratório busca descobrir o que está acontecendo, busca novos conhecimentos e
busca gerar ideias e hipóteses para novas pesquisas. Adequado quando o assunto
escolhido é pouco conhecido e se pretende ampliar os conhecimentos. Sendo
descritivo preocupa-se em observar, registrar, correlacionar e descrever fatos ou
16
fenômenos de uma determinada realidade sem manipulá-los. Quanto à abordagem é
qualitativo, indicado aos estudos de uma unidade social, em que se procura o
universo do objeto de estudo.
A partir da avaliação através de um estudo de caso é possível testar as hipóteses
desta dissertação: (i) verificar como o uso de modelos i* para enriquecer requisitos em
métodos ágeis contribui na melhoria dos projetos de desenvolvimento ágil de software
e (ii) avaliar a viabilidade de seu uso como forma de documentação. O capítulo 4
desta dissertação apresenta o estudo de caso detalhadamente.
1.5 Organização do trabalho
Além desta introdução, esta Dissertação de Mestrado compreende mais cinco
capítulos que estão organizados como segue. O capítulo 2 apresenta a
fundamentação teórica a respeito dos conceitos básicos dos assuntos abordados neste
trabalho: métodos ágeis, engenharia de requisitos, engenharia de requisitos nos
métodos ágeis, histórias de usuários, os desafios dos requisitos nos métodos ágeis,
engenharia de requisitos orientada a metas e a técnica i*. O capítulo 3 descreve o
trabalho proposto por esta dissertação e apresenta o exemplo usado para demonstrar
a proposta, além disso, discute os resultados iniciais obtidos. O capítulo 4 apresenta
o estudo de caso que avalia a proposta deste trabalho. O capítulo 5 apresenta os
trabalhos relacionados. Finalmente, o capítulo 6 apresenta as considerações finais
deste trabalho, bem como as contribuições e trabalhos futuros.
17
2 Fundamentação Teórica
2.1 Metodologias Ágeis
Em meados da década de 90 surgiram métodos leves de desenvolvimento de
software, que não utilizavam as formalidades das metodologias tradicionais. Esses
métodos se concentravam em fatores humanos, apostavam na entrega de valor para
o cliente e em processos menos burocráticos (Bassi, 2008). A filosofia dessas
metodologias partia do princípio de que, nos projetos de software, era muito difícil
ter todos os requisitos completamente elicitados e estáveis antes da implementação
do projeto começar. Tornou-se necessário ser flexível e adaptável para responder às
mudanças sem grandes custos ou atrasos (McCauley, 2001) e para atender às
organizações com seus complexos sistemas adaptativos (Highsmith e Cockburn,
2001).
Assim, a partir dos resultados positivos de emprego das metodologias leves, em
2001, seus principais idealizadores se reuniram e publicaram um manifesto com
peculiaridades da metodologia, dando à mesma o nome de Métodos Ágeis. A ideia
era permitir que a metodologia pudesse ser usada por todos e fosse uma alternativa
aos modelos tradicionais de desenvolvimento. O resultado dessa reunião foi a
publicação do manifesto ágil com as quatro premissas que o representa (Manifesto,
2001):
os indivíduos e as interações mais que processos e ferramentas;
o software operante mais que documentação abrangente;
colaboração do cliente mais que negociações contratuais;
responder às mudanças mais que seguir um planejamento.
As metodologias ágeis tiram o foco do processo e o coloca no produto. Para
atender a essa exigência, algumas etapas da metodologia tradicional foram alteradas
ou até extintas e algumas atividades modificadas (Bassi, 2008), pois a principal
estratégia dos métodos ágeis é reduzir o custo de mudança ao longo do projeto
combinando trabalho em equipe com enfoque na flexibilidade. O que é novo nos
métodos ágeis é o reconhecimento das pessoas como os principais atores do sucesso
do projeto, o que produz uma nova combinação de valores e princípios que definem
a metodologia (Highsmith e Cockburn, 2001).
Segundo Abrahamsson et al. (2003), metodologias ágeis são caracterizadas pelos
seguintes atributos: incrementais, cooperativas, simples e adaptativas. Incremental
refere-se a versões de pequeno porte do software, com ciclos de desenvolvimento
rápido. Cooperativa refere-se à interação do cliente e equipe de desenvolvimento.
18
Simples implica que é fácil de aprender e de modificar. Adaptativa refere-se à
capacidade de flexibilidade para responder às mudanças.
Metodologias ágeis incentivam a mudança. A proximidade da equipe e intensa
interação entre seus membros são características essenciais. As iterações são curtas,
de duas a seis semanas. A equipe faz constante balanço das decisões e ajusta novas
informações, combinando os curtos ciclos com o planejamento de recursos e
priorização dinâmica onde o cliente pode repriorizar e acrescentar para o próximo
ciclo, descartando o originalmente planejado (Highsmith e Cockburn, 2001).
De acordo com McCauley (2001), os principais defensores dos métodos ágeis não
são teóricos, mas pessoas da indústria que usam a metodologia e conseguem
entregar com sucesso software de alta qualidade, mantendo os clientes satisfeitos.
Highsmith e Cockburn (2001) afirmam que projetos que utilizam efetivamente
metodologia ágil alcançam maior velocidade, boa flexibilidade e redução de custos.
As interações entre indivíduos facilitam o compartilhamento de informações e
permitem alterar o processo rapidamente quando o mesmo precisa mudar. Quando
os desenvolvedores conversam eles podem resolver as dificuldades, ajustar as
prioridades e examinar caminhos alternativos.
Cada vez mais os métodos ágeis têm despertado o interesse da comunidade de
Engenharia de Software como uma alternativa para o processo de desenvolvimento
de sistemas de maneira mais rápida, eficiente e que atenda as reais necessidades dos
clientes. Com base nesses valores e princípios, surgiram várias abordagens, algumas
com focos diferentes, mas sempre preservando a característica de agilidade. Como
exemplo de metodologias ágeis podemos citar eXtreme Programming (XP) (Beck,
2004), Scrum (Schwaber, 1997), Feature Driven Development (FDD) (Palmer e Felsing
2002), Adaptive Software Development (ASD) (Highsmith, 2000) entre outras. Não é
intenção detalhar nesta dissertação as abordagens das metodologias ágeis existentes.
Para maiores detalhamentos e esclarecimentos as referências citadas podem ser
consultadas.
2.2 Engenharia de Requisitos
Requisitos são descrições das necessidades dos clientes que serão implementadas
no sistema a partir de suas funcionalidades para ajudar a resolver algum problema.
O gerenciamento dos requisitos é de extrema importância e faz parte das melhores
práticas de Engenharia de Software (Engholm, 2010). 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). É definida como um processo de comunicação onde
19
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. Além disso, requisitos com erros, mal-
entendidos ou necessidades omitidas são mais caros para reparar mais tarde no
projeto (Nuseibeh e Easterbrook, 2000). De acordo com Chaos Report (Standish
Group, 1994), modificações nos negócios e requisitos mal compreendidos estão entre
as principais causas de fracasso nos projetos de software. A natureza abstrata e
invisível do software e a variedade de problemas que admitem suas soluções têm
contribuído para que a engenharia de requisitos receba a cada dia mais atenção
(Nuseibeh e Easterbrook, 2000). A forma como os requisitos são gerenciados
desempenha um papel importante para assegurar que eles possam ser lidos,
analisados, escritos e validados de forma correta.
O escopo desta dissertação se insere no estudo dos requisitos nos métodos ágeis,
ou seja, as histórias de usuário, e no contexto GORE. Ambos são detalhados nas
seções 2.3 e 2.5 apresentadas a seguir.
2.3 Engenharia de Requisitos nos Métodos Ágeis
A tarefa de lidar com os requisitos está presente em todo trabalho de
desenvolvimento de software independente da metodologia utilizada. No entanto,
cada metodologia apresenta suas características e particularidades. Há exigências
para que o software evolua tão rapidamente que, às vezes, os requisitos se tornam
obsoletos antes mesmo do término do projeto. Os métodos ágeis procuram lidar com
esses desafios e, dessa forma, ganharam muito interesse entre os profissionais e
pesquisadores (Cao e Ramesh, 2008). Os defensores das metodologias ágeis
argumentam que os requisitos mudam tão rapidamente que um documento de
requisitos fica desatualizado tão logo seja redigido, por isso o esforço é desperdiçado.
De acordo com Paetsch; Eberlein e Maurer (2003), engenharia de requisitos e
desenvolvimento ágil são vistos, muitas vezes, como atividades incompatíveis, pois
engenharia de requisitos é um processo tradicional da engenharia de software e
conta com a documentação para gerenciar o projeto e compartilhar conhecimentos,
enquanto os métodos ágeis se concentram na colaboração face a face entre os
stakeholders para lidar com os mesmos objetivos.
As metodologias ágeis empregam suas principais práticas para fabricar software
com mais flexibilidade e atender rapidamente às mudanças. O desenvolvimento ágil
é menos centrado em documentos e mais orientado ao código. Os métodos ágeis
foram desenvolvidos para se adaptarem e serem utilizados frente a modificações
20
frequentes (Fowler, 2011). Os requisitos são desenvolvidos de forma incremental, de
acordo com as prioridades do cliente. Além disso, a elicitação de requisitos é
realizada com clientes que fazem parte da equipe de desenvolvimento. Assim, os
clientes podem dizer o que querem e corrigir suas escolhas ao verem o software em
desenvolvimento, permitindo que os requisitos mais significativos sejam
implementados de maneira adequada e o software corresponda ao valor real do
negócio (Ambler, 2002).
O desenvolvimento ágil ocorre num ambiente onde coletar e desenvolver uma
especificação de requisitos completa parece ser inadequado, já que as mudanças
ocorrem durante todo o desenvolvimento até que o cliente não tenha mais requisitos
a solicitar (Cao e Ramesh, 2008). Por isso as metodologias ágeis não se preocupam
com a apuração detalhada e completa dos requisitos para dar início ao
desenvolvimento.
As metodologias ágeis procuram enfrentar os desafios em contextos dinâmicos
de desenvolvimento de software defendendo a implementação do código sem
análise formal de requisitos, baseando-se no constante feedback dos stakeholders onde
os requisitos surgem ao longo do processo de desenvolvimento. A intensa
comunicação entre os stakeholders é de fundamental importância. Ao invés de
produzir uma especificação completa que descreve precisamente o sistema, os
processos de engenharia de requisitos nos métodos ágeis são mais dinâmicos,
adaptativos e não são centralizados em uma fase antes do desenvolvimento (Cao e
Ramesh, 2008). A elicitação dos requisitos ocorre através do uso de abstrações em
forma de histórias de usuário, que serão detalhadas na seção a seguir.
2.3.1 Histórias de Usuários
Para elicitar os requisitos do software as equipes de desenvolvimento ágil
utilizam abstrações em forma de histórias de usuário que são o foco central da
atividade de desenvolvimento. Segundo Cohn (2004), uma história de usuário
descreve a funcionalidade que tem valor para o cliente do software e é usada para
planejamento do projeto, funcionando como um lembrete para a equipe já que
conversas posteriores sobre a história são essenciais para transmitir os detalhes das
mesmas.
As histórias de usuário são usadas para estabelecer um entendimento comum
dos requisitos do software utilizando uma abordagem flexível, de baixa sobrecarga e
centrada no usuário (O’hEocha e Conboy, 2010). São amplamente utilizadas pelo
desenvolvimento ágil e são, portanto, consideradas neste trabalho como um artefato
ágil.
21
As histórias de usuário são escritas em linguagem natural pelo próprio cliente.
Mike Cohn (2006) sugere um formato para a escrita das histórias que vem sendo
amplamente utilizado: “como <papel>, eu quero <ação> para <meta>”. Às vezes
pequenas variações dos termos desse formato são encontradas, mas a estrutura não
muda (Sharp; Robinson e Petre, 2009). Portanto, para aplicação das histórias de
usuário nesta dissertação, parte-se do princípio que as mesmas utilizam o formato
proposto por Cohn (2006). A figura 1 apresenta um exemplo de histórias de usuário
nesse formato.
Figura 1: Exemplo de Histórias de Usuário
Fonte: Adaptado de IBM (2012)
Segundo Jeffries (2001), as histórias de usuário tem três aspectos críticos que o
autor define como os “3Cs”. O primeiro C se refere ao cartão onde as histórias são
escritas. O texto é apenas suficiente para identificar a necessidade e para lembrar aos
stakeholders o que é a história. O cartão é um símbolo que representa o requisito e
usado no planejamento. Notas podem ser escritas sobre ele, refletindo a prioridade e
a estimativa. O cartão não contém toda a informação que constitui o requisito. A
exigência em si é comunicada de cliente para desenvolvedores através da conversa,
que seria o segundo “C” que é um intercâmbio de pensamentos, opiniões e
sentimentos. Essa conversa tem lugar ao longo do desenvolvimento, principalmente
quando a história é estimada e, novamente, na reunião de planejamento da iteração
quando a história está prevista para implementação. O terceiro “C” desempenha
papel chave na história de usuário, pois é a confirmação de que foi implementado o
que realmente era necessário. A confirmação é realizada de forma diferenciada em
cada metodologia ágil, mas ela sempre existe, pois é o que torna possível a
abordagem simples do cartão e da conversa.
22
O conjunto de cartões de história forma o artefato de saída da atividade de
elicitação de requisitos no desenvolvimento ágil. A história é escrita no cartão, é
priorizada pelo cliente, estimada pelo desenvolvedor, atribuída a uma iteração,
implementada por um desenvolvedor e, finalmente, aceita como feita. Segundo
(Sharp et al., 2006), apesar da simplicidade, os cartões de história fornecem uma
informação partilhada dentro da equipe e desempenham vários outros papéis dentro
do desenvolvimento. Por exemplo, como gerenciadores do progresso ou como um
meio de controlar o trabalho da equipe (Sharp e Robinson, 2004).
Depois de preenchidos com as histórias, os cartões são exibidos em uma parede
ou uma área vertical como armários, por exemplo, em um lugar público do ambiente
de desenvolvimento, configurando um espaço de trabalho informativo. A notação
utilizada na parede onde são fixados é simples e se baseia no princípio de
organizador direto, separados por colunas do que está “a ser feito”, o que está
“sendo feito” e o que “já foi feito” (Sharp, Robinson e Petre, 2009).
Para Sharp; Robinson e Petre (2009) os cartões de histórias de usuário e a parede
constituem os dois principais artefatos físicos no desenvolvimento ágil que,
individualmente ou em combinação, sustentam as atividades da equipe. As funções
principais desses artefatos é permitir uma compreensão compartilhada dos requisitos
e facilitar o gerenciamento no processo de desenvolvimento.
2.4 Desafios dos Requisitos nos Métodos Ágeis
A revisão sistemática realizada por Jaqueira et al. (2012) levantou os principais
trabalhos acadêmicos, conferências, workshops que apontaram e discutiram os
desafios dos requisitos nos métodos ágeis . Os resultados obtidos pela maioria dos
artigos selecionados partiram de estudos empíricos baseados na experiência da
utilização ou migração para métodos ágeis, o que contribui para o respaldo do
trabalho, já que seus resultados foram de acordo com a prática.
Ao analisar os trabalhos selecionados nessa revisão sistemática destacam-se os
desafios mais citados relacionados a requisitos em métodos ágeis: (i) a
disponibilidade do cliente para fornecer feedback constante, (ii) a gestão da mudança
dos requisitos e da arquitetura do software, (iii) bem como da rastreabilidade já que
as mudanças são frequentes, (iv) limitação do cliente que às vezes não possui
autonomia ou capacidade para fornecer feedback apropriado do projeto como um
todo, (v) requisitos não funcionais negligenciados, (vi) consenso na negociação ou
priorização dos requisitos, principalmente quando há mais de um cliente, (vii)
documentação que é mínima e sua falta pode causar diversos problemas, (viii)
equipe de desenvolvimento multifuncional, onde o profissional tem vários perfis, (ix)
23
custo e estimativa do projeto, já que o mesmo tem seu escopo flexível e sofre
alterações a todo momento.
A tabela 1 apresenta o resumo dos principais desafios dos requisitos nos
métodos ágeis levantados na revisão sistemática, bem como o número de vezes em
que foram evidenciados nos artigos analisados. Cada desafio foi associado a uma
fase da engenharia de requisitos, de modo a considerar os desafios em cada fase
específica.
Tabela 1: Desafios para requisitos em métodos ágeis
Atividades da ER
Desafios Referência do Desafio Nº de vezes que aparece nos artigos
Eli
cita
ção
Val
idaç
ão
Disponibilidade do Cliente
(Cao; Ramesh, 2008); (Hoda; Noble; Marshall, 2010); (Bjarnason; Wnuk; Regnell, 2011)
03
Limitação do cliente on site
(Cao; Ramesh, 2008) ;(Hoda; Noble; Marshall, 2010); (Bjarnason; Wnuk; Regnell, 2011)
03
Equipe multifuncional (Cao; Ramesh, 2008); (Savolainen; Kuusela;
Vilavaara, 2010); (Bjarnason; Wnuk; Regnell, 2011)
03
Negligência de requisitos não funcionais
(Cao; Ramesh, 2008) 01
Ger
enci
amen
to
Gestão da mudança dos requisitos e da
arquitetura do software
(Cao; Ramesh, 2008); (Vlaanderen et al., 2009);
(Mordinyi; Kühn; Schatten, 2010); (Savolainen; Kuusela; Vilavaara, 2010); (Sen; Hemachandran,
2010) (Bjarnason; Wnuk; Regnell, 2011)
06
Documentação
(Cao; Ramesh, 2008); (Gallardo-Valencia; Sim, 2009); (Savolainen; Kuusela; Vilavaara, 2010); (Espinoza; Garbajosa, 2011; (Bjarnason; Wnuk;
Regnell, 2011)
05
Rastreabilidade (Espinoza; Garbajosa, 2011) 01
Via
bil
idad
e
Consenso na negociação (Cao; Ramesh, 2008); (Sen; Hemachandran, 2010) 02
Custo e estimativa (Cao; Ramesh, 2008) 01
Fonte: Jaqueira et al. 2012
A partir dos resultados apresentados na tabela 1 foi possível identificar os
principais desafios da engenharia de requisitos ágil e a quantidade de vezes que os
mesmos foram evidenciados por diversos autores em pesquisas empíricas. De posse
da evidência dos desafios, a proposta para tratamento dos mesmos será de relevante
contribuição para os pesquisadores e praticantes das metodologias ágeis.
A proposta deste trabalho contribui para o desafio da falta de documentação,
que foi destacada por cinco artigos, conforme tabela 1. O objetivo é fornecer um
recurso complementar, o uso de modelos i* para enriquecer requisitos em métodos ágeis,
que poderá funcionar como uma forma de documentação no ambiente de
24
desenvolvimento ágil fornecendo uma visão gráfica e abrangente das histórias de
usuário.
2.4.1Desafios das Histórias de Usuário
Como o foco deste trabalho diz respeito ao mapeamento das histórias de usuário,
esta seção destaca alguns trabalhos sobre as principais limitações desse artefato no
desenvolvimento ágil.
Ao analisar em detalhes as atividades de uma equipe ágil, Sharp et al. (2006)
concluiu que as histórias de usuário e a parede onde são fixadas constituem artefatos
muito restritos para processar questões como o rastreamento do progresso do
software e que faltam informações detalhadas sobre o aplicativo em
desenvolvimento. Assim, os autores investigaram a partir da perspectiva de notação
e da perspectiva social, qual a função desses artefatos físicos no desenvolvimento ágil
(Sharp, Robinson e Petre, 2009). Podemos destacar as seguintes conclusões desse
trabalho:
(i) A parede é, principalmente, um mecanismo de controle do progresso do
desenvolvimento e oferece pouco em termos de expressar tantos requisitos
ou a aplicação em desenvolvimento. É um dispositivo de estruturação,
proporcionando uma visão geral de progresso dentro de uma iteração. A
visualização da parede é restrita à visão do processo do domínio, pois a
aplicação como um todo não pode ser visualizada.
(ii) A notação utilizada para os cartões é passível de erro. Descrições em
linguagem natural podem ser utilizadas de forma adequada ou não. Da
mesma forma, a parede não tem garantias, o princípio de organizar seu
layout pode ser respeitado ou não.
(iii) Dependências entre as histórias são geralmente “escondidas” ao visualizar
o cartão isolado. A parede apresenta os cartões quanto à iteração dos
mesmos. As dependências não expressas, a referência implícita entre
processo e aplicação somados à abstração dos cartões de história
contribuem para sobrecarregar a equipe exigindo rigorosas operações
mentais.
(iv) Os cartões são provisórios devido à fragilidade de sua natureza física e à
sua flexibilidade. São acessíveis, facilmente mutáveis e descartáveis. A
alteração, substituição ou remoção de qualquer dado do cartão é simples.
A parede também pode ser vista como provisória devido à facilidade com
que os cartões podem ser movidos, removidos, adicionados, os rótulos
alterados ou apagados.
(v) A história de usuário é escrita pelo cliente e lida pelo programador no
pressuposto de que ambos estão conscientes do domínio e que seus desejos
25
se encaixam nesse domínio. Assim, enquanto a história é discutida e
esclarecida em um nível de abstração mais baixo, o contexto social requer
uma consciência de um nível mais alto de abstração. Esse nível superior
não é, nem pode ser contido no cartão ou notação da parede, mas deve
contar com um entendimento mais amplo, no âmbito da equipe.
(vi) A escrita e a leitura de um cartão de história assume uma relação especial
entre cliente e desenvolvedor: fornecer e apoiar uma compreensão mais
ampla da aplicação sem recorrer a um documento de especificação
detalhado. A compreensão da notação é relativamente simples e concisa,
mas interpretar os detalhes e as implicações requer mais trabalho (e
possivelmente difíceis operações mentais), pois esses detalhes não são
expressos nos cartões e nem na parede, mas são incorporados em
discussões com o cliente ou outros colegas.
(vii) Antes de cada iteração, clientes e desenvolvedores realizam a atividade de
planejamento da iteração, que resulta em um acordo sobre quais histórias
farão parte da iteração. Tipicamente essa atividade é realizada
manuseando os cartões sobre uma mesa, arranjando e reorganizando os
mesmos para refletir as preocupações, prioridades, capacidades e
aspirações da equipe para mediar a discussão até que se chegue em um
acordo. No entanto, existem vários problemas com esse sistema físico,
incluindo o fato de que os cartões podem ser perdidos ou destruídos, a
dificuldade de serem pesquisados e não poderem ser facilmente
compartilhados com membros de uma equipe distribuída.
Os autores Beatty e Chen (2012) destacam como desafio o fato de contar com a
participação do cliente comunicando os requisitos através das histórias, das
conversas e dos testes de aceitação. De acordo com esses autores, o desafio é que as
pessoas tem memória curta, e para sistemas complexos em que muitas decisões e
escolhas são feitas ao longo da vida do projeto, sem documentação nenhuma essas
decisões se tornam arriscadas de forma significativa. E do lado da equipe, segundo
os autores, torna-se muito difícil controlar o sistema unicamente com histórias de
usuários.
Já os autores Gomez; Rueda e Alarcón (2010) dão enfoque ao desafio da questão
da dependência entre as histórias de usuário. Se a ordem de implementação não leva
em conta essas dependências, um grande número de refatoração será necessário
aumentando o custo total do projeto desnecessariamente pois, segundo Carlshamre
et al. (2001), apenas um quinto dos requisitos podem ser considerados sem
dependências. Portanto, as dependências naturais entre as histórias de usuários
devem ser aceitas como inevitáveis. A existência de dependências entre as histórias
de usuário torna necessária a implementação de umas antes de outras (Carlshamre et
26
al., 2001), (Greer e Ruhe, 2004) (Denne e Cleland-Huang, 2004) (Logue e McDaid,
2008).
As dependências entre as histórias de usuários dificulta o planejamento (Cohn,
2004) (Logue e McDaid, 2008). Não considerá-las aumenta as chances de não cumprir
com os planos de entrega (Babinet e Ramanathan, 2008). Portanto, a sequência de
implementação das histórias de usuário de acordo com as relações de dependência
entre elas deve ser considerada (Ton, 2007). Identificar de antemão as dependências
aumenta a capacidade de lidar efetivamente com as mudanças. Deste modo,
mecanismos sistemáticos são necessários para ajudar a identificar as dependências
entre histórias de usuários (Gomez; Rueda e Alarcón, 2010).
A tabela 2 apresenta o resumo dos desafios citados para as histórias de usuário.
Tabela 2: Desafios para histórias de usuário
Desafios Referência Total
Dependências entre as histórias
(Carlshamre et al., 2001); (Denne e Cleland-Huang, 2004); (Cohn, 2004); (Greer e Ruhe, 2004); (Sharp et al.,
2006); (Ton, 2007); (Logue e McDaid, 2008); (Babinet e Ramanathan, 2008); (Gomez; Rueda e Alarcón, 2010).
09
Ter informações e entendimento do sistema como um todo
(Sharp et al., 2006); (Beatty e Chen, 2012)
02
Dependência de conversas com o cliente
(Sharp et al., 2006); (Beatty e Chen, 2012) 02
Notação passível de erros (Sharp et al., 2006) 01
Vulnerabilidade dos cartões (Sharp et al., 2006) 01
Rastreamento das histórias (Sharp et al., 2006) 01
2.5 Engenharia de Requisitos Orientada a Objetivos
Na engenharia de requisitos orientada a objetivos, uma meta é um objetivo a ser
alcançado pelo sistema. As metas têm sido reconhecidas como sendo componentes
essenciais no processo de engenharia de requisitos. Assim, a Engenharia de
Requisitos Orientada a Objetivos (Goal-Oriented Requirements Engineering) ou GORE
(Lamsweerde, 2001) visa identificar as necessidades que o software deve atender por
meio de mapeamento dos objetivos dos envolvidos no processo. Ao considerar os
objetivos dos stakeholders, os engenheiros de requisitos podem se aprofundar na
compreensão do problema, analisar melhor e até avaliar modelos alternativos de
requisitos (Lamsweerde, 2003). Os objetivos fornecem um contexto mais rico para a
27
compreensão e interpretação de requisitos, porque se referem a um nível superior ao
negócio ou domínio de aplicação (Yu et al., 2011).
Na engenharia de requisitos orientada a objetivos, a análise é feita a partir da
descoberta de qual é o problema e de quem é responsável por resolver o problema.
Assim, sabe-se por que é necessário desenvolver o sistema, quais as necessidades o
mesmo vai atender e quem é responsável por satisfazer tais necessidades
(Lamsweerde, 2009).
De acordo com (Lamsweerde, 2001) as vantagens em usar abordagens GORE são:
(i) modelos de objetos e requisitos podem ser derivados sistematicamente a partir de
metas; (ii) as metas fornecem uma justificativa para os requisitos; (iii) as metas
fornecem um gráfico da rastreabilidade vertical para preocupações estratégicas de
alto nível permitindo detalhar as mesmas em um nível mais baixo para melhor
entendimento; (iv) a partir da abstração de alto nível que as metas fornecem, os
tomadores de decisão podem ter melhor orientação; (v) o refinamento da meta
fornece uma estrutura mais compreensível para o documento de requisitos; (vi) o
refinamento de metas alternativas e suas atribuições permitem avaliar propostas de
sistemas alternativos.
Existem várias técnicas que utilizam os objetivos dos stakeholders como abstração
na Engenharia de Requisitos, tais como KAOS (Dardenne; Lamsweerde e Fickas,
1993), i* (Yu , 1995), NFR Framework (Chung et al., 2000) e V-Graph (Yu e
Mylopoulos, 2004). Esta dissertação usa a técnica de modelagem i* como suporte
para os requisitos em métodos ágeis. A mesma será apresentada na próxima seção.
2.5.1 Técnica de Modelagem i*
De acordo com Eric Yu (2009), a cada dia os software se tornam mais complexos
e densamente interligados com o ambiente social humano. Para que um sistema seja
bem sucedido ele precisa funcionar dentro do contexto do seu ambiente. A
necessidade de modelar e caracterizar o ambiente refletindo as características sociais
desses sistemas complexos é iminente. Dentre os métodos e técnicas que os
profissionais de sistemas de software podem usar para lidar com essas questões tem-
se a modelagem social. Nesse contexto, a técnica i* tem sido bastante explorada por
comunidades de pesquisas na área de engenharia de requisitos pois torna a
compreensão social parte integrante do processo de desenvolvimento e análise do
sistema (Yu, 2009).
A técnica i*, proposta por Eric Yu (1995), é uma abordagem GORE centrada nos
stakeholders e seus relacionamentos, onde existem os atores que dependem uns dos
outros para atingir suas metas. Lê-se i estrela ou i star, acrônimo de intencionalidade
28
distribuída, pois o foco está nas propriedades intencionais dos atores e seus
relacionamentos.
De acordo com Silva Júnior (2011), i* tem grande aceitação internacional pela
academia, na área de engenharia de requisitos, por sua ampla capacidade semântica
de representar relações de dependências sociais e intencionais dos atores no contexto
organizacional, além de permitir mapear os requisitos funcionais e não funcionais de
um software. Além da engenharia de requisitos, vem sendo utilizada em várias áreas
de pesquisa como na área de reengenharia de processos de negócio, de modelagem
de software e desenvolvimento de sistemas orientados a agentes (Carvalho, 2003).
A técnica i* trouxe para a área de engenharia de requisitos, e mais
especificamente a de projetos de desenvolvimento e manutenção de software, a
inovação de considerar os relacionamentos de dependência entre atores
organizacionais e do software permitindo a visualização das características
encontradas na fase inicial da engenharia de requisitos (Santander, 2002) visando
entender o contexto do ambiente que o software deverá contemplar.
A modelagem organizacional propiciada por i* é uma técnica de modelagem
conceitual para a descrição de processos que envolvam vários participantes e permite
a compreensão do ambiente, o que é considerado relevante pela engenharia de
requisitos (Alencar, 1999). Os objetivos da modelagem organizacional, segundo
Alencar (1999) são: (i) fornecer um objeto que seja uma representação compartilhável
e reusável de informação e conhecimento; (ii) definir os objetivos de maneira precisa
e (iii) suportar a visualização do modelo de forma e compreensão fáceis. Ao
considerar as intenções das relações de dependências entre atores sociais, i* difere de
outras técnicas focadas nos aspectos dos processos que muitas vezes abstraem os
aspectos humanos do software.
A compreensão social do processo de software inserida nas atividades dos
analistas é a base para construção do sistema. A técnica i* modela o relacionamento
de dependência entre atores, por meio de metas, tarefas e recursos. Atores não
existem isolados. Eles existem em ambientes compartilhados com outros atores, e
interagem uns com os outros. Para tanto, são definidos os relacionamentos de
dependência entre eles. Os atores são vistos como sendo intencionais, ou seja, tem
objetivos, crenças, habilidades e compromissos. Assim, a análise centra-se em como
os objetivos de vários atores são alcançados de acordo com as relações entre atores
humanos e do sistema, e que reconfigurações desses relacionamentos pode ajudar os
agentes promover os seus interesses estratégicos.
29
2.5.1.1 Modelos i* SD e SR
A técnica de modelagem i* consiste de dois modelos básicos, o modelo de
dependência estratégica (Modelo SD – Strategic Dependency) que descreve as relações
de dependência entre os atores e o modelo de raciocínio estratégico (Modelo SR –
Strategic Rationale) que demonstra como os atores atingem suas metas.
A unidade central é o ator estratégico e intencional. Um ator é estratégico
quando, além de preocupado em cumprir suas metas, está interessado nos resultados
dos seus relacionamentos com outros atores. O ator intencional executa atividades e
produz entidades. Seus aspectos intencionais podem ser metas, crenças, habilidades
e compromissos.
O modelo SD é usado para expressar a rede de relações intencionais e
estratégicas entre os atores. É representado por um conjunto de nós e ligações, onde
cada nó representa um ator e cada ligação entre dois atores indica que um ator
depende do outro para atingir um objetivo. Auxilia na identificação dos stakeholders
do sistema, na análise de oportunidades e vulnerabilidades e também no
reconhecimento de padrões de relacionamentos. Os conceitos de atores, metas,
metas-soft, tarefas, recursos e dependências são utilizados pelo modelo SD. A figura
2 ilustra um exemplo de notação do modelo SD.
Figura 2: Exemplo de Notação do Modelo SD Fonte: Silva, 2008
O ator que depende de outro ator é chamado depender e o ator que satisfaz essa
dependência é chamado dependee. O objeto da dependência é chamado dependum.
Existem quatro tipos de dependências: dependência de metas, dependência de meta-
soft, dependência de tarefas e a dependência de recurso.
Os atores são representados por círculos e interagem através das dependências
representadas pelas ligações entre eles. O ator1 é o depender pois depende do ator2
que é o dependee. A letra “D” nas relações de dependência entre os atores indica qual
ator é o depender e qual é o dependee. Para onde o meio círculo da letra “D” direcionar
30
aí está o dependee. Estão representados também na figura 3 os quatro tipos de
dependums possíveis, ou seja, meta, meta-soft, tarefa e recurso.
Os atores podem representar papéis exercidos por pessoas, funções ou cargos
ocupados, organizações ou subdivisões da organização e sistemas. As metas
representam os interesses estratégicos dos atores, ou seja, suas intenções,
necessidades ou objetivos desejados para cumprir o seu papel dentro do ambiente
em que está inserido. As metas-soft também representam os interesses estratégicos
dos atores, só que com natureza subjetiva, isto é, descrevem desejos dos atores
relacionados aos atributos de qualidade (requisitos não funcionais). As tarefas
representam a forma de executar alguma atividade, isto é, indicam como realizar
alguma ação para atender a uma meta ou meta-soft. Os recursos representam dados
ou informações que podem ser fornecidas ou recebidas por um ator.
Na dependência de metas um ator tem uma meta a cumprir, mas depende de
outros atores para a satisfação dessa meta. Não é especificado pelo depender como o
dependee irá executar a meta. O dependum é expresso como uma declaração de
responsabilidade. A diferença da dependência de metas para a de metas-soft é que o
dependum é uma meta-soft. Em uma dependência de tarefa a dependência é para
realizar uma atividade. O dependum é uma tarefa com especificação de como deve ser
executada, mas não o porquê. O ator dependee assume o compromisso de executar a
atividade da forma como foi especificado. Quando um ator, para cumprir suas
responsabilidades, depende de informações fornecidas por outros atores, ocorre a
dependência de recursos. Essa dependência representa a troca de informações entre
os atores. O depender depende de um recurso fornecido por um ator dependee que se
responsabiliza em prover esse recurso.
O modelo SR é usado para expressar e representar as razões por trás das
dependências e possui vários tipos de nós e ligações. Os atores do modelo SD são
expandidos para mostrar suas intenções específicas.
O modelo SR possui os mesmos quatro tipos de nós principais: as metas, metas-
soft, tarefas e recursos, mas adiciona três tipos de ligações: análise meio-fim,
decomposição e contribuições. Nele, as relações são analisadas no contexto de um
único ator. Cada ator tem limites intencionais próprios e todos os elementos dentro
desse limite são desejados por esse ator. Para alcançar esses elementos, muitas vezes
um ator depende das intenções dos outros atores, representados por links de
dependência através das fronteiras do ator ou satisfaz certos elementos
representados por uma ligação de dependência no sentido oposto.
As ligações meio-fim representam uma relação entre um fim e um meio para
alcançá-lo. Os "meios" são expressos na forma de uma tarefa, dado que a noção de
31
tarefa incorpora como fazer alguma coisa, o fim é expresso como uma meta. Na
notação gráfica, a ponta da seta aponta do meio para o fim.
Ao realizar a análise meio-fim podemos identificar várias tarefas que seriam
alternativas para execução de uma meta. Estas tarefas são exclusivas, então ao final
da análise, deve-se optar por uma dessas, ou seja, as outras não serão executadas. O
fim pode ser uma meta, tarefa ou recurso e o meio geralmente é uma tarefa. Quando
o fim é uma meta e o meio é uma tarefa, essa tarefa especifica o "como atingir a meta"
através de suas decomposições em componentes. Quando o fim é um recurso e o
meio é a tarefa, essa tarefa especifica o "como produzir o recurso" através de suas
decomposições em componentes. A ligação entre meta-soft e tarefa é um caso
especial chamado contribuição. A tarefa é o meio para satisfazer as restrições de
qualidade da meta-soft. Essa satisfação pode ser negativa ou positiva.
Um elemento de tarefa está ligado aos seus componentes por ligações de
decomposição. A tarefa pode ser decomposta em quatro tipos de elementos: em uma
sub-meta, em uma sub-tarefa, em um recurso e em uma meta-soft e pode ser
decomposta em um para muitos desses elementos. Esses elementos podem também
ser parte de links de dependência no modelo de dependência estratégica quando o
raciocínio vai além da fronteira de um ator. Uma decomposição da tarefa em metas
indica o objetivo que aquela tarefa quer atingir. Quando uma tarefa é decomposta em
uma sub-tarefa, a sub-tarefa define uma ação a ser realizada. Uma decomposição em
um recurso implica em uma entidade (física ou informacional) que será usada para a
tarefa. Uma meta-soft serve como uma meta de qualidade para a tarefa e guia a
seleção entre alternativas em outras decomposições da tarefa.
A figura 3 apresenta um exemplo de modelo SR. O limite do ator2 é representado
pelo círculo pontilhado. A meta principal do ator2 é refinada por uma análise meio-
fim nas Tarefa1 e Tarefa2. Essas tarefas são as alternativas para realização da meta. A
Tarefa1 configura uma decomposição em duas sub-tarefas. A subtarefa1 tem
contribuição negativa sobre a meta-soft enquanto a tarefa2 tem contribuição positiva.
A análise das contribuições ajuda ao ator decidir qual tarefa deve ser executada.
Figura 3: Exemplo de Notação do Modelo SR Fonte: Silva, 2008
32
Nos modelos i* existe também um link de associação entre atores denominado
associação IS_A. Essa associação representa uma generalização de um ator para
outro. A figura 4 mostra um exemplo da notação IS_A utilizada na associação onde o
Ator 1 é uma generalização do Ator 2.
Figura 4: Exemplo de Notação da Associação IS_A
Esta dissertação utiliza os conceitos e notações da técnica i* de acordo com o i*
Wiki (2012) que representa uma versão simplificada da técnica. Também é
importante relatar que somente alguns elementos da técnica i* são utilizados neste
trabalho de acordo com a necessidade da proposta apresentada.
Portanto, para construir o modelo SD, os elementos utilizados neste trabalho são
o ator, as metas, além da associação IS_A. Para o modelo SR são utilizados os
elementos tarefas, recursos e também a ligação de decomposição.
33
3 Uso de Modelos i* para Enriquecer Requisitos em Métodos Ágeis
Esta dissertação propõe o uso de modelos i* para enriquecer requisitos em métodos
ágeis. Este capítulo apresenta a visão geral da proposta, o processo com as atividades
envolvidas na sua construção bem como as heurísticas para realizar o mapeamento
das histórias de usuário para os modelos i*.
3.1 Visão Geral da Proposta
A proposta deste trabalho surgiu para proporcionar aos stakeholders uma visão
gráfica abrangente das relações entre as histórias de usuário, uma vez que Sharp et al.
(2006) concluiu que as mesmas são artefatos muito restritos para proverem
entendimento do sistema como um todo e suas relações de dependências são
omitidas. Beatty e Chen (2012) afirmam que controlar o sistema somente com as
histórias de usuário é um desafio tanto para os clientes quanto para a equipe.
Segundo os autores, tomar decisões baseando-se somente nas histórias, sem
nenhuma documentação, se torna arriscado principalmente para sistemas
complexos.
É esperado que, a partir dos modelos i* gerados, os mesmos possam ser
utilizados como uma forma de documentação no ambiente de desenvolvimento ágil,
contribuindo assim para o desafio de falta de documentação que foi levantado na
revisão sistemática realizada por Jaqueira et al. (2012).
De acordo com Beatty e Chen (2012), mesmo em um ambiente ágil é necessário
desenvolver algum modelo antes de qualquer implementação para garantir uma
compreensão compartilhada pela equipe de desenvolvimento, de modo que fique
sincronizada com os objetivos do negócio, valor e contexto do projeto. Para os
autores, modelos visuais auxiliam nesse entendimento e no entendimento de como
os usuários precisarão usar o sistema. Além disso, são eficazes para os stakeholders
entenderem a solução proposta e também para mantê-los interessados e envolvidos.
Até mesmo para deixar claro o que a solução não vai entregar.
Uma abordagem baseada em modelos visuais pode fornecer ligações mais
diretas e rastreáveis para o desenvolvimento do sistema, promovendo uma análise
com maior impacto na concepção e implementação do software. Funciona também
para facilitar a comunicação, compreensão, a detecção de problemas ou explorar
cenários hipotéticos e potenciais soluções.
34
Dessa forma, este trabalho propõe mapear as histórias de usuário para os
modelos i*. Tanto a técnica i* quanto as metodologias ágeis se preocupam e ressaltam
os stakeholders e seus relacionamentos. Essa preocupação comum justifica a escolha
da técnica i* para representar os requisitos ágeis, ou seja, as histórias de usuário.
Além disso, a técnica i* foi escolhida pelo fato de (i) permitir considerar os objetivos
dos stakeholders, admitindo um aprofundamento na compreensão do problema,
analisando melhor e avaliando modelos alternativos de requisitos (Lamsweerde,
2003); (ii) tornar a compreensão social parte integrante do processo de
desenvolvimento e análise do sistema, considerada relevante para engenharia de
requisitos (Alencar, 1999); além de, (iii) permitir modelar os relacionamentos de
dependências entre os atores (wiki i*, 2012). A tabela 3 apresenta alguns desafios das
histórias de usuário e como a técnica i* pode auxiliar nesses desafios.
Tabela 3: Desafios das Histórias de Usuário e Auxílio na Técnica i*
Desafio das Histórias de Usuário Solução com a Técnica i*
O contexto social das histórias requer uma consciência de um nível mais alto de abstração. Esse nível superior não é, nem pode ser contido no cartão ou notação da parede (Sharp et al., 2006).
Torna a compreensão social parte integrante do processo de desenvolvimento e análise do sistema, considerada relevante para engenharia de requisitos (Alencar, 1999).
Necessidade de visualizar o contexto do software como um todo em vez de focar em uma história individual (Patton , 2008).
Ao considerar os objetivos dos stakeholders, os engenheiros de requisitos podem se aprofundar na compreensão do problema, analisar melhor e até avaliar modelos alternativos de requisitos (Lamsweerde, 2003).
Dependências entre as histórias são geralmente “escondidas” ao visualizar o cartão isolado (Sharp et al., 2006); (Gomez; Rueda e Alarcón, 2010) .
A técnica i* modela o relacionamento de dependência entre atores (wiki i*, 2012).
A figura 5 apresenta uma visão geral das atividades envolvidas para realizar o
mapeamento das histórias de usuário para os modelos i*. Está representada
utilizando BPMN, 2012 (Business Process Model and Notation), notação gráfica que
permite representar e comunicar fluxos de processos.
35
Figura 5: Visão Geral do Mapeamento das Histórias de Usuário para Modelos I*
A primeira etapa é mapear o modelo SD de acordo com a prioridade das
histórias de usuário a partir dos papéis e metas das histórias. No segundo momento,
a partir das ações das histórias de usuário, mapeia-se e gera-se o modelo SR. A seção
a seguir apresenta a construção do mapeamento de forma detalhada.
3.2 Construção dos Modelos i*
Para realizar o mapeamento das histórias de usuário para os modelos i*, de
acordo com a proposta deste trabalho, considera-se o formato de histórias de usuário
proposto por Cohn (2006): como <papel> eu quero <ação> para <meta>. A escolha
do formato de Cohn (2006) justifica-se pelo fato de o mesmo ser amplamente
utilizado no ambiente ágil (Cockburn, 2007).
Segundo Leffingwell e Behrens (2009), nas histórias de usuário o papel
representa quem realiza a ação ou alguém que está recebendo o valor da atividade,
ou seja, a funcionalidade. Pode até mesmo ser um outro sistema, se é esse que está a
iniciar a atividade. A ação é a atividade propriamente dita a ser executada pelo
sistema. E a meta representa o valor para o negócio.
36
Nos modelos i*, de acordo com Wiki i*, os atores são entidades ativas que
realizam ações para alcançar as metas. Podem representar papéis exercidos por
pessoas, funções ou cargos ocupados, organizações ou sistemas. As metas
representam os interesses estratégicos dos atores, ou seja, suas intenções,
necessidades ou objetivos desejados para cumprir o seu papel dentro do ambiente
em que está inserido. As tarefas representam o que o ator quer realizar de maneira
particular, a forma de executar alguma atividade, isto é, indicam como realizar
alguma ação para atender a uma meta ou a uma macro tarefa.
É possível notar as similaridades entre elementos nas histórias de usuário com
elementos do i*. Por exemplo, o papel nas histórias de usuário e o ator na técnica i*
são entidades que realizam ações. Enquanto que as ações nas histórias de usuário e
as tarefas da técnica i* representam a atividade a ser executada. Já as metas nas
histórias de usuário representam o valor para o negócio, ou seja, o objetivo final de
quem representa o papel e na técnica i* os interesses dos atores para atingir seus
objetivos.
Assim, o ponto de partida para realizar o mapeamento é o papel da história que
é mapeado como ator nos modelos da técnica i*. Existindo várias histórias para
determinado papel, o mesmo será representado como ator somente uma vez no
modelo i*. Por se tratar de uma atividade de desenvolvimento de um sistema, o ator
Sistema sempre irá existir já que é o mesmo que atenderá, através de suas
funcionalidades, às necessidades dos demais atores envolvidos com o software.
As metas das histórias de usuário são mapeadas como metas nos modelos i*. E as
ações das histórias de usuário são mapeadas como tarefas do Ator Sistema, pois as
mesmas serão operacionalizadas pelo sistema. A tabela 4 apresenta a
correspondência entre os elementos das histórias de usuário e da técnica i* no
mapeamento.
Tabela 4: Correspondência no Mapeamento de Elementos das Histórias de Usuário e da Técnica i*
História de Usuário Modelo i*
Elemento Elemento Notação
Papel Ator
Ação Tarefa
Meta Meta
Visando simplificar o entendimento para realizar o mapeamento a partir das
correspondências mostradas na tabela 4 entre os elementos das histórias de usuário e
37
os elementos dos modelos i*, foram estabelecidas heurísticas como recurso para se
chegar à solução do mapeamento proposto neste trabalho. Vale ressaltar que as
heurísticas estabelecidas devem ser executadas na ordem em que foram expressas
neste trabalho para que o mapeamento ocorra de maneira mais correta e objetiva.
As seguintes heurísticas foram propostas para realizar o mapeamento das
histórias de usuário para o modelo SD:
SD-H1: Criar o Ator Sistema;
SD-H2: Criar um Ator no modelo i* para cada diferente papel das histórias de usuário;
SD-H3: Criar uma meta no modelo i* para cada meta das histórias de usuário. Se houver metas repetidas as mesmas serão definidas uma única vez no modelo;
SD-H4: Se houver metas repetidas para atores diferentes, criar um Ator genérico;
SD-H4.1: Criar um relacionamento IS_A do Ator genérico para os demais atores específicos que compartilham a mesma meta;
SD-H5: Relacionar as dependências de cada ator com suas metas.
A figura 6 apresenta um exemplo do mapeamento para o modelo SD.
Figura 6: Exemplo de Mapeamento para o Modelo SD
No exemplo da figura 6, é mapeado o modelo SD para três atores (que
representam papéis nas histórias) e estabelecidas suas relações de dependência. Foi
38
utilizada a ligação IS_A de um Ator Generalizado que compartilha a Meta
Generalizada com o Ator 1 e com o Ator 3. A Meta Generalizada depende do Ator
Sistema para ser alcançada. O Ator 1, Ator e Ator 3 dependem do Ator Sistema para
atingirem suas metas.
Considerando os cartões de histórias de usuário da figura 7, é apresentado um
exemplo na figura 8 de como é realizado o mapeamento para o modelo SD.
Figura 7: Exemplos de Cartões de Histórias
Figura 8: Exemplo SD
No exemplo de mapeamento do modelo SD apresentado na figura 8 os Atores
Usuário e Administrador dependem do Ator Sistema para alcançarem suas metas.
Ator Sistema é padrão!
39
Para representar o modelo SR as ações das histórias são mapeadas como tarefas
do Ator Sistema, pois as mesmas serão operacionalizadas pelo sistema.
As heurísticas para realizar o mapeamento das histórias de usuário para o modelo SR são:
SR-H1: Criar uma Tarefa dentro do Ator Sistema para cada ação das histórias de usuário;
SR-H2: Se houver ações diferentes para a mesma meta, criar uma tarefa genérica;
SR-H2.1: Decompor a tarefa genérica em sub-tarefas que representem as ações associadas à mesma meta;
SR-H3: Relacionar as dependências de cada meta com as tarefas correspondentes de acordo com as histórias de usuário.
SR-H4: Se houver Tarefas que dependem do próprio Ator a que estão relacionadas, gerar um recurso com o nome da tarefa;
SR-H5: Relacionar o recurso criado dependendo do Ator.
A figura 9 apresenta um exemplo do mapeamento para o modelo SR.
Figura 9: Exemplo de Mapeamento para o Modelo SR
No exemplo da figura 9, é mostrado o modelo SR para o Ator Sistema. As ações
de cada papel das histórias de usuário são mapeadas como tarefas no Ator Sistema e
é representada a relação de dependência entre as metas de cada papel com suas
tarefas. A meta do Ator 3 é a mesma para duas ações, dessa forma foi criada uma
40
tarefa genérica e dela foram decompostas as duas sub-tarefas representando as duas
ações. A meta foi associada à tarefa genérica.
Considerando as histórias de usuário da figura 10, é apresentado um exemplo na
figura 11 de como o modelo SR foi gerado a partir das histórias de usuário.
Figura 10: Exemplos de Cartões de Histórias
Figura 11: Exemplo SR
3.3 Exemplo de Uso
Para demonstrar uma aplicação desta proposta utilizou-se como exemplo um
sistema de login simples, considerando a perspectiva de um usuário e de um
administrador. A tabela 5 apresenta as histórias de usuário do sistema de login.
De acordo com as heurísticas propostas, o modelo SD para esse exemplo será
mapeado primeiramente criando o Ator Sistema. Posteriormente, cria-se os atores
41
para os papéis das histórias de usuário, que, nesse caso, são ator Usuário e ator
Administrador. As metas das histórias de usuário são criadas como metas no modelo
SD e ligadas como dependums saindo dos atores a que estão associadas e chegando no
Ator Sistema. A figura 12 apresenta o mapeamento desse exemplo.
Tabela 5: Histórias de Usuário do Sistema de Login Fonte: IBM, 2012
Papel Ação Meta
01 Usuário Ter nome de usuário Acessar conteúdo seguro
02 Usuário Ter senha Acessar conteúdo seguro
03 Usuário Escolher nome de usuário Personalizar a conta
04 Usuário Alterar senha padrão Personalizar senha
05 Administrador Atribuir senha ao usuário Registro ser automatizado
06 Administrador Enviar email de registro Confirmar ativação da conta no
07 Administrador Solicitar login ao usuário Garantir segurança do
conteúdo
08 Usuário Cadastrar lembrete de senha Lembrar a senha
09 Administrador Solicitar a informação do lembrete
de senha Confirmar usuário
Figura 12: Modelo SD do Exemplo de Aplicação
Para gerar o modelo SR, cada ação das histórias de usuário foi gerada como
tarefa dentro do Ator Sistema, pois o mesmo é que irá operacionalizá-la, realizando a
tarefa de maneira particular para atender às metas dos atores. Como existem, nesse
exemplo, ações diferentes para a mesma meta, foi criada uma tarefa genérica no
modelo SR que foi decomposta nas ações em forma de sub-tarefas. As tarefas que
42
dependem do próprio ator geraram um recurso que depende do ator com o próprio
nome da tarefa. A figura 13 mostra o resultado do mapeamento.
Figura 13: Modelo SR do Exemplo de Aplicação
3.4 Discussão
Após a aplicação da proposta desta dissertação no exemplo do Sistema de Login,
algumas observações merecem atenção. A partir do mapeamento das histórias de
usuário para os modelos SD e SR da técnica i*, foi possível organizar e representar
todas as histórias em um modelo que fornecesse uma visualização geral das histórias
e seus relacionamentos. Além disso, todas as histórias de um mesmo ator foram
apresentadas no mesmo modelo, permitindo encontrá-las com maior facilidade.
Dessa maneira, é possível entender o contexto do sistema, seus principais atores e
suas metas.
A visualização através dos modelos tornou mais fácil a identificação de
dependências entre as histórias de usuário e a identificação de tarefas do Sistema
para atender a cada ator específico envolvido com o software.
De acordo com Horkoff (2009) percebemos, ao visualizarmos os modelos, que
possíveis erros e/ou negligências poderiam ser reconhecidos mais facilmente. Tudo
isso facilitou o processo de análise e discussão a respeito do sistema a ser
desenvolvido.
Assim, através desse exemplo demonstrativo é possível perceber que o uso de
modelos i* enriquece os requisitos nos métodos ágeis ao proporcionar uma melhor
visualização (mais abrangente e geral) das histórias de usuário; ao permitir visualizar
as dependências entre as histórias, contribuindo para uma melhor compreensão do
43
contexto do sistema a ser desenvolvido; ao proporcionar a visualização das tarefas
do sistema associadas às metas de cada ator; ao permitir reconhecer possíveis erros
ou negligências nos requisitos através da visualização fornecida.
Portanto, a proposta pode funcionar como uma forma de documentação dos
requisitos no ambiente de desenvolvimento ágil, pois a partir da mesma um artefato
visual será fornecido complementando as histórias de usuário permitindo, a partir de
sua visualização, a análise, comunicação, discussão e melhor entendimento do
sistema.
44
4 Estudo de Caso
Visando avaliar a proposta desta dissertação foi realizado um estudo de caso
com 13 participantes analisando questões qualitativas. Os artefatos utilizados foram
algumas histórias de usuário de um projeto de sistemas da Empresa Júnior 4Soft
(http://www.4softjr.com.br/).
A Seção 4.1 apresenta o objetivo da realização do estudo de caso em maiores
detalhes; na Seção 4.2 encontra-se o planejamento para a realização do estudo de
caso; a Seção 4.3 apresenta a execução do estudo de caso; na Seção 4.4 a análise dos
dados obtidos através da aplicação do estudo de caso é apresentada e, por fim, a
Seção 4.5 apresenta as ameaças à validade do estudo de caso.
4.1 Objetivo
O objetivo da realização desse estudo de caso é verificar se o uso de modelos i*
contribui para enriquecer requisitos nos métodos ágeis através das impressões de
uso dos participantes. Espera-se, então, que após a utilização da proposta através do
estudo de caso, os participantes possam relatar sua experiência de uso e os
resultados obtidos por eles possam ser coletados e analisados, a fim de avaliar a
proposta desta dissertação.
4.2 Planejamento do Estudo de Caso
Para a realização desse estudo de caso foi realizado um planejamento definindo
de forma clara e objetiva as atividades realizadas, os artefatos e informações
essenciais à sua realização.
O planejamento do estudo de caso consistiu na seleção dos participantes (Seção
4.2.1), na definição dos artefatos de entrada (Seção 4.2.2), na formulação das questões
de pesquisa relativas ao estudo (Seção 4.2.3) e, por fim, na preparação do ambiente e
treinamento para sua realização (Seção 4.2.4).
4.2.1 Participantes
Participaram do estudo de caso 13 voluntários, todos com experiência em
desenvolvimento ágil de software. Os participantes foram divididos em dois grupos,
procurando estabelecer grupos equivalentes de acordo com a atividade profissional
declarada por cada um antes da execução do estudo de caso. Dessa forma, 06
participantes atuaram como engenheiros de requisitos e 07 participantes atuaram
como equipe de desenvolvimento.
45
4.2.2 Artefatos de Entrada
Para aplicar a proposta desta dissertação visando avaliar os resultados das
impressões de uso dos participantes foram utilizados como artefatos de entrada um
pequeno texto explicativo do escopo do software (Apêndice A) e algumas histórias
de usuário (Apêndice B) do sistema gerenciador de projetos que está em
desenvolvimento pela Empresa Júnior 4Soft.
A escolha desses artefatos se deve ao fato da Empresa Júnior 4Soft utilizar
metodologia ágil no ambiente de desenvolvimento, empregando o padrão de
histórias de usuário proposto por Mike Cohn (2006) nos requisitos do sistema, o
mesmo utilizado nesta proposta. As histórias de usuário utilizadas como artefato
representam a elicitação de requisitos inicial para o sistema e foram disponibilizadas
pelo engenheiro de requisitos da empresa.
As heurísticas para realizar o mapeamento das histórias de usuário para os
modelos i* também foram utilizadas como artefato no estudo de caso.
4.2.3 Questões de Pesquisa
A fim de avaliar os resultados encontrados pelos participantes a partir do uso da
proposta desta dissertação, foram elaboradas 06 questões de pesquisa, apresentadas
na tabela 6, que serão respondidas através da execução do estudo de caso.
Tabela 6: Questões de Pesquisa do Estudo de Caso
Questão 1 Qual a avaliação dos usuários acerca do aprendizado e entendimento da proposta?
Questão 2 Qual a avaliação dos usuários acerca do desempenho no uso da proposta?
Questão 3 Qual a avaliação dos usuários quanto às melhorias propiciadas pelo uso da proposta?
Questão 4 A proposta pode funcionar como uma forma de documentação dos requisitos do sistema?
Questão 5 Qual a avaliação dos usuários quanto à utilidade da proposta?
Questão 6 Os usuários utilizariam a proposta no seu ambiente de trabalho?
4.2.4 Preparação do Ambiente e Treinamento para o Estudo de Caso
O estudo de caso foi aplicado separadamente com cada grupo de participantes,
de acordo com o perfil de cada um “equipe” ou “engenheiro de requisitos”.
46
Para o grupo de engenheiros de requisitos, antes de iniciar a execução do estudo
de caso foi necessário preparar o ambiente. Assim, foi solicitado que cada um
instalasse em sua máquina a ferramenta OME (Organization Modelling Environment)
(OME, 2012) que oferece uma interface gráfica para modelagens orientadas a
objetivos. Antes da execução do estudo de caso realizou-se um treinamento para
expor alguns conhecimentos básicos para realização do estudo, bem como para
explicar a proposta e a ferramenta utilizada. Foram apresentados o formato de
histórias de usuário utilizado, os elementos e notações da técnica i*, as heurísticas de
mapeamento e um exemplo de aplicação da proposta. Além disso, a ferramenta OME
também foi apresentada.
Para os participantes que atuaram como equipe de desenvolvimento, foram
apresentados o formato de histórias de usuário utilizado, os elementos e notações da
técnica i* e um exemplo de aplicação da proposta.
O objetivo do treinamento foi apresentar a proposta e a ferramenta e tirar
eventuais dúvidas com relação às mesmas, antes da sua utilização. Teve duração de
uma (1) hora, com cada um dos grupos individualmente, imediatamente antes da
execução do estudo de caso.
Depois dessas atividades deu-se início à execução do estudo de caso. A Seção 4.3
apresenta detalhes da execução. A Seção 4.4 apresenta a análise dos dados coletados
no estudo de caso.
4.3 Execução do Estudo de Caso
Após a preparação do ambiente e o treinamento dos participantes foi executado
o estudo de caso sob a supervisão da autora deste trabalho. A execução com o grupo
de engenheiros de requisitos ocorreu no laboratório da Superintendência de
Informática (Sinfo) da Universidade Federal do Rio Grande do Norte, que foi
reservado para esse fim. Os participantes utilizaram suas próprias máquinas, com a
ferramenta OME instalada e os artefatos de entrada, ou seja, as heurísticas de
mapeamento, o texto contendo o escopo do sistema mais as histórias de usuário. A
execução do estudo de caso com esse grupo foi realizada no dia 30 de janeiro de 2013
e durou três (03) horas aproximadamente.
As heurísticas de mapeamento, o texto com o escopo do sistema e as histórias de
usuário foram impressos e entregues aos participantes e foi solicitado aos mesmos
que construíssem os modelos SD e SR utilizando a ferramenta OME.
Após essas atividades foram coletados os dados resultantes da execução do
estudo de caso. Os dados foram obtidos de duas maneiras. Primeiramente foram
salvos e armazenados pela supervisora os modelos construídos por cada participante
durante a execução do estudo de caso visando posterior análise dos mesmos. Os
47
outros dados foram obtidos a partir do Questionário I, apresentado no Apêndice D
deste trabalho, que foi respondido por cada participante ao final de sua execução do
estudo de caso. Esse questionário, contendo 12 questões, procurou verificar as
impressões de uso da proposta por cada participante a partir da utilização da
mesma.
A execução com o grupo que atuou como equipe de desenvolvimento ocorreu na
sala de reuniões do Centro de Ciências Exatas e da Terra (CCET) da Universidade
Federal do Rio Grande do Norte, que foi reservada para esse fim. Esse grupo foi
dividido em duas categorias. A categoria dos conhecedores, composta por 03
participantes que faziam parte da equipe da 4Soft e portanto, já conheciam melhor o
domínio do sistema utilizado no estudo de caso. E a categoria dos neutros, composta
por 04 participantes que não conheciam o domínio sistema.
A execução do estudo de caso com a categoria de participantes conhecedores e
com a categoria de participantes neutros foi realizada nos dias 05 e 06 de fevereiro de
2013, respectivamente, com duração de aproximadamente duas (02) horas.
Após o treinamento onde foram explicados o formato das histórias de usuário
utilizado, a notação da técnica i* e a proposta deste trabalho, foi entregue aos
participantes o texto com o escopo do sistema, as histórias de usuário e os modelos
SD e SR mapeados pelo engenheiro de requisitos da 4Soft. Foi solicitada aos
participantes a observação dos artefatos em detalhes para que posteriormente
respondessem o Questionário II, contendo 09 questões, apresentado no Apêndice E
deste trabalho, utilizado como coleta de dados com o grupo que atuou como equipe
de desenvolvimento buscando verificar as impressões do mesmo.
4.4 Análise dos Dados
Ao final da execução do estudo de caso foram coletados os dados para serem
analisados a partir dos questionários respondidos por cada participante. Os
resultados são apresentados a seguir, respondendo às questões de pesquisa que
foram levantadas por esse estudo de caso.
Questão 1: Qual a avaliação dos usuários acerca do aprendizado e entendimento da proposta?
Para avaliar o aprendizado e entendimento da proposta deste trabalho foram
analisadas as respostas dos participantes para dois questionamentos contidos nos
Questionários I e II respondidos pelo grupo de engenheiros de requisitos e pelo
grupo de equipe de desenvolvimento respectivamente:
Questionamento 1: Como você julga seu aprendizado da proposta?
Questionamento 2: Como você julga seu entendimento da proposta (técnica i*
aplicada às histórias de usuário)
48
As respostas dos participantes foram dadas a essas perguntas através de métricas
no formato nominal com as seguintes opções que indicam o nível de aprendizado e
entendimento alcançados: ruim, razoável, bom e ótimo. Para o grupo de engenheiros
de requisitos foi perguntado o porquê da métrica selecionada, a fim de analisar a
justificativa sobre o aprendizado, uma vez que esse grupo iria realizar o
mapeamento da proposta na prática. A tabela 7 apresenta as respostas aos dois
questionamentos para ambos os grupos.
Tabela 7: Respostas dos Participantes para o Questionamento 1 e 2.
Engenheiro de
Requisitos Equipe de
Desenvolvimento
Aprendizado Entendimento
Ruim - -
Razoável - 1
Bom 2 4
Ótimo 4 2
Conforme tabela 7, ao analisar as respostas obtidas do grupo de engenheiros de
requisitos para o Questionamento 1, observa-se que 02 participantes consideraram o
aprendizado da proposta bom e 04 participantes consideraram o aprendizado ótimo.
Como respostas à justificativa da métrica escolhida como bom aprendizado: (i) um
participante afirmou que absorveu os conceitos e entendeu bem a proposta, mas
precisa praticar mais para aprimorar; o (ii) outro participante afirmou que mesmo
sendo novidade para ele, teve poucas dúvidas e conseguiu aprender. Os
participantes que julgaram o aprendizado como ótimo também se justificaram. Os
comentários foram que (iii) o conteúdo da proposta foi de fácil compreensão e foi
objetivo facilitando sua aplicação em metodologias ágeis; (iv) o emprego de conceitos
relacionados às metodologias ágeis facilitou o aprendizado; (v) a proposta foi
apresentada de forma clara e (vi) a proposta foi bem compreendida em relação aos
requisitos de software.
Ainda de acordo com a tabela 7, para as respostas obtidas para o
Questionamento 2 do grupo que atuou como equipe de desenvolvimento, observa-
se que 01 participante julgou o entendimento da proposta como razoável, 04
participantes julgaram o entendimento da proposta como bom e 02 participantes
julgaram o entendimento como ótimo. Para esse grupo não foi solicitada a
justificativa, pois o mesmo não iria realizar o mapeamento na prática, iria somente
visualizar o mapeamento pronto.
De acordo com as avaliações feitas pelos participantes do estudo de caso a
respeito dos dois questionamentos abordando pontos relativos ao aprendizado e ao
49
entendimento da proposta desta dissertação, é possível afirmar que a mesma foi bem
aprendida pelos engenheiros de requisitos e bem entendida pela equipe de
desenvolvimento. Dessa forma, pode-se concluir que, a partir do bom aprendizado e
do bom entendimento dos participantes, a proposta deste trabalho pôde ser bem
utilizada e bem avaliada por eles. Fato que, consequentemente, contribui para o
respaldo das repostas dos mesmos.
Questão 2: Qual a avaliação dos usuários acerca do desempenho no uso da proposta?
O desempenho foi avaliado somente para o grupo de engenheiros de requisitos,
pois os participantes desse grupo utilizariam a proposta na prática realizando o
mapeamento.
Assim, para avaliar o desempenho dos participantes no uso da proposta desta
dissertação foram analisadas as respostas dos participantes do grupo de engenheiros
de requisitos para o questionamento 2 contido no Questionário I como segue:
Questionamento 2: Como você julga seu desempenho na utilização da proposta
avaliada?
O formato nominal com as opções que indicam o nível de desempenho alcançado
como ruim, razoável, bom e ótimo foi utilizado para coletar as respostas dos
participantes à pergunta do Questionamento 2. Também foi perguntado o porquê da
métrica selecionada, a fim de analisar a justificativa sobre o desempenho desse grupo
que realizou o mapeamento da proposta na prática. A tabela 8 apresenta as repostas
dos participantes.
Tabela 8: Respostas dos Participantes para o Questionamento 2
Engenheiro de
Requisitos
Desempenho
Ruim 1
Razoável -
Bom 5
Ótimo -
Conforme a tabela 8, ao analisar as respostas obtidas do grupo de engenheiros de
requisitos para o Questionamento 2, observa-se que 01 participante considerou seu
desempenho ruim. Segundo ele, (i) foi fácil visualizar os requisitos e os
relacionamentos utilizando a proposta, mas ponderou não ter escolhido a melhor
forma de iniciar a modelagem.
Os demais participantes julgaram o desempenho como bom e também
justificaram suas avaliações: (ii) um participante ressaltou que seguindo as
50
heurísticas definidas o mapeamento é feito de forma rápida e sem dificuldades; (iii) o
fato de a proposta lidar com conceitos do desenvolvimento ágil, as histórias de
usuário, ajudou no seu desempenho de acordo com outro participante; (iv) colocar
em prática a proposta apresentada foi fácil, pois a assimilação do conteúdo foi boa e
a ferramenta OME também ajudou; (v) a prática foi fácil apesar de algumas dúvidas;
(vi) a facilidade de aplicar os conceitos da proposta foi destacada por outro
participante no sentido de contribuir para seu desempenho.
A respeito do questionamento sobre o desempenho na utilização da proposta
desta dissertação, de acordo com as avaliações feitas pelos participantes do grupo de
engenheiros de requisitos é possível concluir que o desempenho foi bom.
Avaliar o desempenho se torna importante como uma oportunidade de
indicador de melhoria da proposta. O desempenho avaliado no estudo de caso foi a
respeito da habilidade técnica de cada participante, ou seja, o saber-fazer na execução
da proposta. Considerando que foi o primeiro contato dos participantes com a
proposta, realizado em um breve período, e o julgamento da maioria foi um bom
desempenho, pode-se afirmar que a eficiência dos participantes no uso da proposta
demonstra que a mesma oferece heurísticas claras e cumpre seus objetivos,
oferecendo resultados claros e confiáveis.
Acredita-se que o participante que julgou seu desempenho ruim por não ter
escolhido a melhor maneira de iniciar a modelagem, tenha se esquecido de utilizar as
heurísticas.
Questão 3: Qual a avaliação dos usuários quanto à melhorias propiciadas pelo uso da
proposta?
Para avaliar as melhorias propiciadas pela proposta deste trabalho foram
analisadas as respostas dos participantes para três questionamentos contidos no
Questionário I (questões 5, 6 e 7) e no Questionário II (questões 3, 4 e 5) respondidos
pelo grupo de engenheiros de requisitos e pelo grupo de equipe de desenvolvimento
respectivamente:
Questionamento 5/3: Você considera que o mapeamento das histórias de usuário
para modelos i* propicia melhora na visualização do contexto do sistema a ser
desenvolvido?
Questionamento 6/4: O mapeamento das histórias de usuário para modelos i* torna
mais fácil o uso e acesso à informação dos requisitos?
Questionamento 7/5: Você considera que o uso dos modelos i* para visualizar
requisitos pode contribuir para o processo de tomada de decisão quanto aos requisitos
na equipe de desenvolvimento?
As respostas dos participantes foram dadas a essas perguntas através de métricas
no formato nominal com as opções “sim” e “não” indicando a concordância ou
51
discordância a respeito do questionamento. Foi perguntado o porquê da resposta, a
fim de analisar a justificativa de maneira mais detalhada. A tabela 9 e a tabela 10
apresentam as respostas dos participantes.
Tabela 9: Respostas dos Participantes para os Questionamentos 5,6 e 7
Engenheiros de Requisitos
5. Melhora a visualização do
contexto
6. Facilita o acesso aos requisitos
7. Contribui na tomada de decisão
Sim 6 5 5
Não - 1 1
Tabela 10: Respostas dos Participantes para os Questionamentos 3,4 e 5
Equipe de Desenvolvimento
3. Melhora a visualização do
contexto
4. Facilita o acesso aos requisitos
5. Contribui na tomada de decisão
Sim 7 7 6
Não - - 1
De acordo com as tabelas 9 e 10, ao analisar as respostas obtidas dos
participantes para o Questionamento 5/3, pode-se observar que todos os
participantes do grupo de engenheiros de requisitos e todos os participantes do
grupo de equipe de desenvolvimento concordaram que a proposta deste trabalho
propiciou melhora na visualização do contexto do sistema a ser desenvolvido.
Segundo os participantes do grupo de engenheiros de requisitos, a proposta
deste trabalho melhora a visualização do contexto do sistema a ser desenvolvido
porque: (i) o modelo i* abstrai as regras de negócio permitindo a simplificação para
atender o contexto ágil, facilitando o entendimento do domínio; (ii) torna mais fácil
analisar as histórias de usuário dentro de módulos do sistema ou considerando o
sistema como um todo, podendo visualizar as partes do sistema e suas dependências
com uma rápida visão do modelo; (iii) facilitou a capacidade de compreensão dos
requisitos do sistema; (iv) o detalhamento dos modelos i* é enxuto e propício para
metodologias ágeis; (v) o modelo visual da técnica i* torna possível a visão macro e
geral dos atores, metas e tarefas do sistema, o que facilita o entendimento do mesmo;
(vi) o mapeamento das histórias de usuário para modelos i* é de entendimento
simples e não gera confusão de ideias.
Para os participantes do grupo que atuou como equipe de desenvolvimento, a
melhora da visualização do contexto do sistema se dá porque (i) os modelos i*
52
facilitam a visualização de dependências e atores com suas atividades dentro do
sistema; (ii) após o mapeamento das histórias de usuário para os modelos i* tem-se
uma visualização rápida das tarefas a serem desempenhadas pelo sistema, (iii)
visualizar as ligações entre os atores como um todo em um modelo visual ajuda
analisar a relação e entendimento rápido do sistema; (iv) o modelo visual propicia
uma perspectiva melhor do sistema a ser desenvolvido, (v) facilita a visão geral do
sistema e também a visualização das dependências entre histórias de usuário, (vi) é
importante visualizar as relações de dependências existentes entre as metas que
devem ser atendidas e os usuários do sistema, também a partir dos modelos i* a
visualização do sistema como um todo é mais fácil; (vii) a proposta é interessante
porque mostra o funcionamento geral do sistema em um modelo de fácil
entendimento.
De acordo com as avaliações feitas pelos participantes de ambos os grupos,
pode-se concluir que a proposta deste trabalho melhora a visualização do contexto
do sistema a ser desenvolvido no ambiente de desenvolvimento ágil, uma vez que os
mesmos concordaram em unanimidade com essa afirmação. Essa visualização é
considerada importante para um melhor entendimento dos requisitos.
Pode-se afirmar que ao contribuir para a visualização do contexto geral do
sistema, os modelos i* estão enriquecendo as histórias de usuário, uma vez que,
segundo Sharp, Robinson e Petre (2009) somente as histórias de usuário não
cumprem esse papel.
Com relação à facilidade de uso dos requisitos e acesso às suas informações,
referente ao Questionamento 6, somente um participante do grupo de engenheiros
de requisitos discordou alegando que (i) existem requisitos que demandam bastante
informação que não é representada na proposta. Os demais participantes
concordaram e deram as seguintes justificativas: (ii) torna mais fácil pois a
representação gráfica e geral dos requisitos, proporciona abstração dos requisitos;
(iii) os modelos i* mostram claramente o que o desenvolvedor deve fazer; (iv) porque
o analista passará a possuir uma visão ampla do sistema; (v) pode-se visualizar todas
as histórias decompostas e como se comportam ou se relacionam com o sistema; (vi)
fica bem claro o objetivo, os atores envolvidos e os detalhes esperados de cada
requisito.
Os participantes do grupo equipe de desenvolvimento também justificaram suas
respostas para o Questionamento 4: (i) funciona como um apoio interessante no
entendimento geral dos requisitos; (ii) a disposição dos elementos do sistema em um
modelo visual torna mais fácil a visualização e o acesso aos requisitos; (iii) facilita o
acesso aos requisitos na forma de tabela por exemplo, mas para as metas de cada
história o acesso aos requisitos é limitado visto que estão descritos muito
brevemente; (iv) torna mais fácil a busca por informação dentro do modelo do que
53
em um monte de texto; (v) consegue-se visualizar imediatamente os requisitos e de
quem os mesmos dependem; (vi) as metas e tarefas relacionadas a um determinado
ator podem ser visualizadas mais rapidamente; (vii) o modelo visual facilita o acesso
aos requisitos.
A partir das avaliações feitas pelos participantes de ambos os grupos, pode-se
concluir que o mapeamento das histórias de usuário para modelos i* torna mais fácil
o uso e acesso à informação dos requisitos. Portanto, pode-se afirmar que o modelo
visual gerado pela proposta cumpre seu papel ao fornecer maior facilidade e rapidez
no uso e acesso aos requisitos do software.
O Questionamento 7/5 refere-se à contribuição da proposta para a tomada de
decisão quanto aos requisitos no ambiente de desenvolvimento. No grupo de
engenheiros de requisitos, somente um participante discordou. Segundo ele, (i) a
falta de informações sobre as regras de negócio torna a análise de impacto e o
modelo organizacional mais fraca, pois o objetivo geral é mais difícil ser percebido e
a ausência de fluxos de processo dificulta a identificação de conflitos e melhorias. Os
demais concordaram e se justificaram: (ii) podem-se notar as relações entre os atores,
metas em comum e tarefas que podem atender uma mesma meta. Com isso é
possível tomar decisões ao observar o fluxo na modelagem, levando em consideração
a complexidade, vantagens e desvantagens de cada decisão; (iii) devido à clareza
conforme o modelo é mapeado; (iv) os modelos visuais são fundamentais para a
tomada de decisão; (v) ficam claros os relacionamentos e as dependências; (vi) um
dos participantes concordou, mas não se justificou.
Também no grupo de equipe de desenvolvimento somente um participante
discordou, para ele (i) a tomada de decisão e avaliação do projeto está mais
relacionada às histórias dos usuários. Os demais participantes concordaram, (ii) por
facilitar a visualização de dependências e possíveis repetições de atividades ou
divergência de metas; (iii) é possível mais facilmente perceber ambiguidades e
tarefas menos lucrativas; (iv) é mais fácil identificar alternativas nos requisitos; (v) a
partir dos modelos podem-se visualizar possíveis ganhos ou perdas de acordo com a
tomada de decisão, facilitando a discussão dentro da equipe; (vi) muitas vezes as
tarefas são mal atribuídas entre a equipe e a partir dos modelos é mais fácil
modularizar e verificar a divisão das atividades na equipe; (vii) a partir do
mapeamento dos requisitos do sistema para os modelos i*, é possível considerar o
sistema em um nível de abstração mais elevado facilitando a tomada de decisão.
De acordo com as avaliações feitas pelos participantes de ambos os grupos, a
maioria concorda que o uso de modelos i* pode contribuir na tomada de decisão
quanto aos requisitos na equipe de desenvolvimento. Pode-se afirmar então que a
proposta deste trabalho está enriquecendo os requisitos ágeis ao proporcionar, a
54
partir da visualização mais ampla dos requisitos do sistema, maior facilidade, análise
e discussão na tomada de decisão no ambiente de desenvolvimento.
Questão 4: A proposta pode funcionar como uma forma de documentação dos requisitos do sistema?
Visando avaliar se a proposta deste trabalho pode funcionar como forma de documentação de requisitos do sistema, as respostas dos participantes para o questionamento contido no Questionário I (questão 8) e no Questionário II (questão 6) foram analisadas.
Questionamento 8/6: Você considera que o uso dos modelos i* pode funcionar como uma forma de documentação dos requisitos do sistema?
As respostas dos participantes foram dadas a essas perguntas através de métricas
no formato nominal com as opções “sim” e “não” indicando a concordância ou
discordância a respeito do questionamento. Foi perguntado o porquê da resposta, a
fim de analisar a justificativa de maneira mais aprofundada. A tabela 11 apresenta as
respostas dos participantes.
Tabela 11: Respostas dos Participantes para o Questionamento 8/6
Engenheiro de
Requisitos Equipe de
Desenvolvimento
Sim 6 6
Não - 1
Conforme tabela 11, ao analisar as respostas obtidas do grupo de engenheiros de
requisitos para o Questionamento 8, observa-se que todos os participantes
concordaram que a proposta deste trabalho pode funcionar como documentação de
requisitos no ambiente de desenvolvimento ágil. Para o grupo que atuou como
equipe de desenvolvimento, apenas um participante discordou.
Os participantes do grupo de engenheiros de requisitos se justificaram: (i) ao
gerar melhor entendimento do que deve ser construído a partir de um modelo
visual, a proposta se torna bem vinda como forma de documentação; (ii) é um
artefato visual de representação dos requisitos do sistema; (iii) pela objetividade e
clareza nas informações dos requisitos detalhados; (iv) da mesma forma que as
histórias de usuário podem ser uma forma de documentação de requisitos, quando
mapeadas para os modelos i* funcionam também, inclusive com mais informações já
que podemos traçar dependências e outras relações no modelo; (v) os modelos i*
contribuem complementando mas não sendo a única forma de documentação; (vi)
poderia ser usado mas não unicamente.
Um dos participantes do grupo de equipe de desenvolvimento discordou se
justificando (i) os modelos funcionariam como um documento para auxílio no
55
entendimento do sistema, mas não para requisitos unicamente. Os demais
concordaram que as histórias de usuário mapeadas como modelos i* podem
funcionar como forma de documentação dos requisitos do sistema. Suas justificativas
foram: (ii) a proposta contribui para uma visualização do sistema em um nível mais
alto, mas o uso somente dos modelos não é suficiente; (iii) os modelos proveem
agilidade de acordo com o ambiente de desenvolvimento onde os requisitos estão em
constante mudança; (iv) pelo melhor entendimento proporcionado pelos modelos
visuais; (v) pois apresenta as tarefas e metas de cada ator e fica bem visualizado; (vi)
é uma forma mais simples de visualizar as histórias de usuários; (vii)
complementado as histórias de usuário funcionaria de forma eficiente.
Conclui-se que o uso da proposta deste trabalho como forma de documentação
no ambiente de desenvolvimento ágil é aceitável pela maioria dos participantes, de
acordo com as avaliações feitas para ambos os grupos. Pode-se afirmar então que o
uso da proposta como forma de documentação no ambiente de desenvolvimento
contribui para o desafio de falta de documentação no ambiente ágil, levantado por
Jaqueira et al. (2012).
Questão 5: Qual a avaliação dos usuários quanto à utilidade da proposta?
Com o objetivo de avaliar a utilidade da proposta deste trabalho foram analisadas
as respostas dos participantes para o questionamento contido no Questionário I
(questão 9) e no Questionário II (questão 7).
Questionamento 9/7: Você considera que é útil aplicar os modelos i* para visualizar
requisitos no ambiente de desenvolvimento?
As respostas dos participantes foram dadas à pergunta através de métricas no
formato nominal com as opções “sim” e “não” indicando a concordância ou
discordância a respeito do questionamento. Foi perguntado o porquê da resposta, a
fim de analisar a justificativa de maneira mais aprofundada. A tabela 12 apresenta as
respostas dos participantes.
Tabela 12: Respostas dos Participantes para o Questionamento 9/7
Engenheiro de
Requisitos Equipe de
Desenvolvimento
Sim 6 6
Não - -
Em Branco - 1
Conforme tabela 12, ao analisar as respostas obtidas do grupo de engenheiros de
requisitos para o Questionamento 9, observa-se que todos os participantes
concordaram que é útil aplicar a proposta deste trabalho para visualizar requisitos
ágeis no ambiente de desenvolvimento. Para o grupo que atuou como equipe de
56
desenvolvimento, seis participantes concordaram e um participante não respondeu
alegando ainda não ter conhecimento suficiente para responder.
No grupo de engenheiros de requisitos as justificativas foram: (i) por sua
abordagem simplificada, o que é útil no ambiente de desenvolvimento ágil; (ii) a
agilidade está na correta compreensão dos objetivos e os modelos i* agilizam o
entendimento inicial do problema e seus objetivos; (iii) através da visualização das
dependências nos modelos a equipe pode traçar prioridades de modo mais seguro e
com uma visão mais técnica das histórias de usuário; (iv) por facilitar o trabalho a
partir da visualização dos modelos; (v) com a utilização dos modelos i* a equipe
poderá ter uma visão mais interativa e de fácil acesso aos requisitos do sistema; (vi)
por gerar melhor entendimento pelos envolvidos no projeto.
Os participantes do grupo de equipe de desenvolvimento que também
concordaram se justificaram: (ii) os modelos são rápidos e diretos de serem checados;
(iii) facilidade de encontrar os requisitos no modelo; (iv) os modelos tornam mais
fácil a percepção do problema, alternativas e conflitos; (v) apresentar as histórias de
usuário de maneira simplificada e visual, torna-se um processo adequado para o
ambiente ágil, pois facilita a visualização; (vi) os modelos podem auxiliar o
desenvolvedor no entendimento mais amplo do sistema; (vii) é uma forma de a
equipe se contextualizar e ter uma noção geral do sistema.
A partir das avaliações feitas pelos participantes de ambos os grupos, a respeito
da utilidade de aplicação da proposta para visualizar requisitos no ambiente de
desenvolvimento, a maioria concorda e se justifica ressaltando a utilidade da mesma.
Assim, pode-se afirmar que a proposta é relevante no sentido de ser considerada útil
para o ambiente de desenvolvimento ágil.
Questão 6: Os usuários utilizariam a proposta no seu ambiente de trabalho?
Para avaliar se os participantes fariam uso da proposta desta dissertação no seu
ambiente de trabalho, as respostas para os questionamentos contido no Questionário
I (questão 11) e no Questionário II (questão 8) foram analisadas.
Questionamento 11: Você utilizaria a proposta no seu ambiente de
desenvolvimento?
Questionamento 8: Você gostaria que a proposta fosse utilizada no seu ambiente de
desenvolvimento?
As respostas dos participantes foram dadas à pergunta através de métricas no
formato nominal com as opções “sim” e “não” indicando a concordância ou
discordância a respeito dos questionamentos. Foi perguntado o porquê da resposta, a
fim de analisar a justificativa de maneira mais aprofundada. A tabela 13 apresenta as
respostas dos participantes.
57
Tabela 13: Respostas dos Participantes para os Questionamentos 11 e 8
Engenheiro de
Requisitos Equipe de
Desenvolvimento
Sim 4 6
Não 2 1
Conforme tabela 13, ao analisar as respostas obtidas do grupo de engenheiros de
requisitos para o Questionamento 11, observa-se que 04 participantes usariam a
proposta no ambiente profissional e 02 participantes não usariam. De acordo com os
participantes que não fariam uso da proposta nos seus ambientes profissionais, um
deles não utilizaria (i) pela forma de trabalho da equipe, tarefas que devem ser
realizadas o mais rápido possível nem sempre permitindo utilizar modelos extras;
(ii) outro participante não utilizaria pois acredita que a modelagem tornaria seu
processo mais demorado, contrariando os princípios ágeis. Os 04 participantes que
utilizariam a proposta afirmaram que (iii) a proposta seria bastante útil para
contextualizar melhor sua equipe sobre o projeto em desenvolvimento; (iv) os
modelos facilitariam a melhor compreensão dos requisitos tanto pelo cliente quanto
pela equipe de desenvolvimento; (v) devido à facilidade para capturar as
necessidades e o entendimento inicial por parte do desenvolvimento, mas utilizaria
associado a outras técnicas; (vi) pela visão ampla do sistema a partir dos modelos
gerados.
Para o grupo que atuou como equipe de desenvolvimento, 06 participantes
gostariam que a proposta deste trabalho fosse utilizada no seu ambiente profissional
e 01 participante não gostaria. O participante que não gostaria se justificou
comentando que (i) a visualização dos modelos pode ser confusa com maior
quantidade de histórias e achou custoso fazer os modelos com muitas alterações ao
longo do desenvolvimento. Para os demais participantes que gostariam que a
proposta fosse utilizada no seu ambiente, as justificativas foram: (ii) o uso dos
modelos visuais auxiliaria na atribuição de tarefas aos desenvolvedores,
contribuindo para a divisão balanceada das tarefas entre a equipe, pois visualizando
os modelos tem-se melhor noção da quantidade de tarefas; (iii) é importante o tipo
de visualização que os modelos proporcionam às histórias de usuário. O
entendimento das relações de dependência entre as metas completam e contribuem
para o entendimento mais amplo do sistema a ser desenvolvido; (iv) pelo baixo custo
de implementação se comparada a outras propostas. Modificar os requisitos dentro
dessa abordagem pode ser mais fácil; (v) a proposta é prática e útil; (vi) é útil para
esclarecimento de dúvidas relacionadas aos relacionamentos entre atores, e
consequentemente entre histórias de usuário; (vi) um participante concordou mas
não justificou.
58
De acordo com as avaliações feitas pelos participantes de ambos os grupos, a
respeito da possibilidade de uso em seus ambientes profissionais, a maioria faria uso
da proposta. Pode-se afirmar que a proposta mostrou-se interessante e adequada
para enriquecer os requisitos no ambiente de desenvolvimento ágil.
Nota-se também que os participantes que atuaram como equipe de
desenvolvimento demonstraram maior aceitação da proposta deste trabalho, o que
pode ratificar a queixa sobre a falta de documentação no ambiente ágil levantada na
revisão sistemática (Jaqueira et al., 2012) e a restrição das histórias de usuário para o
trabalho do desenvolvedor (Sharp et al., 2006); (Beatty e Chen, 2012).
4.4.1 Discussão
No final dos questionários foi reservado um espaço para comentários
espontâneos dos participantes que quisessem fazê-lo. No grupo de engenheiros de
requisitos os comentários foram: (i) preocupação com a quantidade de ligações nos
modelos e compreensão dos mesmos para sistemas maiores; dúvida em como seriam
os modelos para sistema em módulos; (ii) preocupação com a visualização para
muito relacionamentos; sugestão de usar a proposta com outras técnicas; (iii)
observação com cuidado em repetições nos modelos; (iv) um participante comentou
que achou a proposta interessante e que pretende pesquisar mais sobre o assunto.
Os participantes do grupo que atuou como equipe de desenvolvimento
comentaram que (i) a proposta é interessante e poderia utilizar outros elementos da
técnica i*; (ii) os modelos podem ficar confusos para grandes projetos; (iii) gostaria de
representar mais relacionamentos de dependência; (iv) a proposta auxiliaria no
entendimento dos requisitos no meu ambiente profissional; (v) como seria o
comportamento da proposta diante das mudanças frequentes de requisitos ágeis?.
A partir dos comentários espontâneos dos participantes, conclui-se que mesmo a
maioria aprovando a proposta, nas respostas ao questionário algumas preocupações
ainda existem. A preocupação mais refletida foi quanto à proposta aplicada em um
sistema maior, sobre a possível confusão na visualização. Esse feedback está
diretamente associado à uma das ameaças à validade externa relatada na seção a
seguir. E é uma oportunidade de averiguação em trabalhos futuros como processo de
melhoria da proposta desta dissertação.
4.5 Ameaças à Validade
A partir dos conceitos definidos por Travassos et al. (2002), esta seção destaca as
principais ameaças à validade dos resultados obtidos pelo estudo de caso
apresentado. São apresentadas as ameaças à validade interna (Seção 4.5.1) e as
ameaças à validade externa (Seção 4.5.2).
59
4.5.1 Validade Interna
A validade interna define se o relacionamento observado entre o tratamento do
estudo e o resultado encontrado a partir do mesmo é causal, e não é influenciado por
outro fator que não é controlado ou mesmo que não foi medido.
A primeira das ameaças à validade interna desse estudo está relacionada ao nível
de conhecimento de Requisitos Ágeis, de História de Usuário e da Técnica i*
apresentado pelos participantes, pois o nível de conhecimento de cada um poderia
ser diferente. Para minimizar essa ameaça, foi realizado, antes da execução do estudo
de caso, um treinamento com todos os participantes para apresentar os principais
conceitos aplicados na execução do estudo, visando diminuir as diferenças existentes
entre os níveis de conhecimento de cada participante. Os grupos foram definidos de
acordo com a atuação profissional de cada participante, também a fim de amenizar
essa ameaça.
A segunda ameaça à validade interna do estudo de caso está associada com a
disponibilidade e entusiasmo dos participantes. Para minimizar essa ameaça, o
estudo de caso foi agendado de acordo com a disponibilidade dos participantes na
data e horário mais convenientes para eles e foi destacada a importância de
contribuição pela participação nas pesquisas.
4.5.2 Validade Externa
A validade externa está relacionada às condições que limitam a generalização
dos resultados alcançados pelo estudo de caso. Assim, duas ameaças à validade
externa desse estudo foram identificadas.
A primeira ameaça à validade externa desse estudo está relacionada à
quantidade de cenários utilizados para a realização do mesmo. Foi utilizado apenas
um cenário para avaliar a proposta, as histórias de usuário do sistema gerenciador de
projetos da Empresa Júnior 4Soft. É importante que, futuramente, novos estudos
envolvendo novos cenários sejam realizados para verificar os resultados obtidos a
partir do uso da proposta.
A segunda ameaça à validade externa está relacionada ao cenário utilizado. Foi
utilizado um cenário relativamente pequeno, com 17 histórias de usuário. Portanto, é
importante realizar novos estudos futuramente envolvendo cenários de médio e
grande porte a fim de conferir os resultados obtidos a partir do uso da proposta em
dimensões maiores.
60
5 Trabalhos Relacionados
Como trabalhos relacionados, citamos três trabalhos sendo que dois envolvem os
temas metodologia ágil e i*, e um trabalho trata do mapeamento de histórias de
usuário para fornecer uma visualização mais abrangente das mesmas. Dessa forma,
as seções a seguir (Seção 5.1, Seção 5.2 e Seção 5.3) apresentam uma visão geral
desses trabalhos. Ao final de cada seção é apresentada uma discussão dos aspectos
que diferenciam cada trabalho da proposta desta dissertação, fazendo uma
comparação desses trabalhos com a nossa abordagem.
Na Seção 5.4 é apresentada uma tabela comparativa entre os trabalhos
apresentados e a proposta desta dissertação, visando destacar os pontos comuns,
divergências e limitações entre cada um.
5.1 “Integrando Scrum e a Modelagem de Requisitos Orientada
a Objetivos por meio do SCRUM i*”
Scheidegger (2011) propõe a linguagem de modelagem Scrum i*, que integra
Scrum com GORE utilizando a técnica i*. A linguagem é utilizada na fase de
preparação para ação ou visão do projeto. Visa auxiliar o entendimento do contexto
do software a ser desenvolvido, considerando os seus relacionamentos e busca suprir
a carência observada no Scrum do entendimento das relações de dependência entre
atores.
No Scrum i*, a técnica i* foi simplificada para ser integrada ao Scrum, visando
manter a característica de agilidade (Scheidegger, 2011). Dessa forma, utilizou-se no
trabalho apenas parte do modelo SD. A representação gráfica é similar, mas a relação
de dependência considera apenas a dependência por objetivo, tendo esse uma
conotação mais abrangente englobando as tarefas, os recursos e as meta-soft. Assim,
por definição, no Scrum i* há um único tipo de relação de dependência que
representa todos os tipos de dependência da técnica i* (objetivos, tarefas, recursos e
objetivos soft), para simplificação do modelo.
Os atores são entidades que se relacionam por meio de dependência com o ator
software e são representados por círculos, com o nome que identifica o ator, escrito
internamente. A representação gráfica das dependências no Scrum i* é uma elipse. É
utilizada uma legenda para definir que tipo de dependência está representado, ou
seja, se é para satisfação de um objetivo, realização de uma tarefa, produção ou
consumo de um recurso ou mesmo de satisfação de um requisito não funcional (soft-
goal). A simplificação da notação visa permitir também que os modelos sejam
facilmente desenhados até mesmo sem uso de ferramenta gráfica.
61
Foi aplicado um estudo de caso cujo objetivo foi avaliar a viabilidade, benefícios
e desafios para adoção de Scrum i* em um ambiente real. Realizaram-se também
duas pesquisas qualitativas para avaliar a adoção do Scrum nas indústrias e para
avaliar a adoção do Scrum i*.
O diferencial da proposta desta dissertação é que a mesma está diretamente
relacionada com os requisitos do software, sendo os atores dos modelos os donos das
histórias de usuário, ou seja, dos requisitos. No trabalho proposto por Scheidegger
(2011) são utilizados atores organizacionais nos modelos, ou seja, são pessoas que
interagem na organização e interagem com o sistema, mas não necessariamente estão
ligados aos requisitos.
A proposta de Scheidegger (2011) tem motivação na carência de representação
das dependências entre atores observada no Scrum pela autora. Enquanto que na
nossa proposta a motivação está na carência de documentação observada nos
ambientes de desenvolvimento ágil. Portanto, independente da metodologia
utilizada, qualquer equipe de desenvolvimento ágil que utilize cartões de histórias
no formato proposto por Conh (2006) poderá aplicá-la.
Outro diferencial é que na nossa proposta usamos outros elementos de
dependência dos modelos i* (metas, tarefas, recursos e meta-soft) para representar os
relacionamentos entre os atores e utilizamos também os links de decomposição e de
associação IS_A.
5.2 “Adopting Agile Methods: can Goal-Oriented Social
Modeling Help?”
Esfahani; Cabot e Yu (2010) utilizam o Scrum para ilustrar a utilização de
abordagem GORE na descrição de aspectos sociais dos métodos ágeis visando
identificar fatores que contribuem para o sucesso ou fracasso da adoção de um
método ágil por uma equipe, fornecendo orientação durante a introdução do método
em uma organização.
A proposta é complementar o processo do Scrum com uma nova perspectiva que
visa descrever e analisar os aspectos sociais e humanos do processo através da
técnica i* para a visualização e análise das relações entre atores sociais, mostrando
como eles dependem uns dos outros para alcançar os objetivos da equipe e dos
indivíduos.
A justificativa é que através da representação explícita das relações sociais
envolvendo pessoas, habilidades, dependências e tarefas a adoção do Scrum pode ser
avaliada de acordo com as chances de sucesso verificadas nos aspectos sociais do
processo, permitindo ajustes para os membros da equipe atual e a identificando as
vulnerabilidades que são específicas para a organização.
62
Nesse contexto a técnica de modelagem i* é usada para modelar a perspectiva
social abordando os envolvidos no processo Scrum. A representação sistemática das
interdependências sociais pode ajudar os membros da organização a ter uma melhor
compreensão do processo, esclarecendo as suas responsabilidades e expectativas. É
possível também detectar como o mau desempenho de um ator, pode afetar o
cumprimento das metas do processo e da funcionalidade de outros atores.
Finalmente, dependências atribuídas a uma função também implica que o papel
deve ter certas habilidades para realizar com sucesso a relação de dependência.
Segundo os autores, a abordagem permite uma representação explícita de todos
os fatores sociais que podem ser analisados e incorporados ao processo de tomada de
decisão de uma organização quando na seleção de um processo de software para um
determinado projeto.
A proposta visa representar os aspectos sociais relacionados aos processos do
software e as relações sociais existentes entre os envolvidos no processo. No exemplo
utilizando Scrum, as relações para apresentar o modelo SD envolvem como atores
membros da equipe de desenvolvimento, o scrum master e o cliente. Para apresentar
o SR as habilidades de cada ator são mostradas como softgoal, representando
habilidades desejáveis para ele.
O diferencial da nossa proposta em relação a esse trabalho é que nosso foco são
as relações sociais baseadas nos requisitos do software. Os atores são os “donos dos
requisitos”, ou seja, pessoas que estão relacionadas diretamente com os mesmos.
5.3 “The New User Story Backlog is a Map”
Patton (2008) propõe uma maneira de organizar e priorizar as histórias de
usuário, criando um mapa de histórias. Para isso utiliza os cartões de histórias
definindo os mesmos como sendo atividade do usuário e tarefas de usuário. As
atividades do usuário são histórias mais genéricas, e para que essas atividades sejam
entregues existem tarefas de usuário a serem implementadas. Um exemplo: gerenciar
email é uma atividade de usuário. Enviar mensagem, excluir mensagens, ler
mensagens são tarefas de usuário necessárias para atingir o objetivo da atividade
gerenciar email.
A partir dessa definição, os cartões de atividades são organizados
horizontalmente de acordo com a ordem que os usuários os utilizam e, abaixo de
cada cartão de atividade, são organizados os cartões de tarefas também de acordo
com a ordem em que são executados pelos usuários. Constrói-se assim um mapa
priorizado pela ordem de execução dos cartões pelos usuários. A implementação dos
cartões de tarefas sempre ocorre da esquerda para direita. São definidos também os
63
cartões de atividades chamados “espinha dorsal”, que são as atividades essenciais
que precisam ser implementadas para o sistema funcionar.
O objetivo da proposta de Patton (2008) foi facilitar a exploração de novas
soluções e a compreensão do contexto mais amplo de interação da história,
permitindo a visualização do software como um todo, em vez de focar em uma
história individual. Essa necessidade surgiu de sua experiência de trabalho em uma
equipe ágil. Para ele, a partir do mapa de história seria possível ter algo mais
completo para fixar em uma parede ou colocar em uma mesa e ter uma discussão
com mais propriedade.
A navegação no mapa do começo ao fim com os stakeholders facilita o
entendimento e facilita também contar uma história sobre os usuários do sistema e o
que eles estão fazendo. Falando através do mapa facilitaria encontrar algo perdido
eventualmente, podendo anotar os pontos críticos e as oportunidades (Patton, 2008).
De acordo com a proposta de Patton (2008) o entendimento do sistema acontece
pela organização dos cartões e não necessariamente pelo contexto social que eles
desempenham. É uma maneira de organizar e priorizar as histórias na ordem em que
são utilizadas no ambiente do usuário, mas não apresenta o contexto social das
mesmas e também não mostra as relações de dependências. Essa proposta não usa
conceitos da orientação a metas e usa cartões e parede, limitando seu uso quando as
histórias não são escritas em cartões.
5.4 Tabela Comparativa dos Trabalhos Relacionados
Com o objetivo de melhor visualizar a comparação entre os trabalhos relacionados e a proposta desta dissertação, a tabela 14 é apresentada onde as principais características de cada trabalho relacionado são mostradas, bem como as
similaridades e diferenças entre cada um.
Quatro critérios de comparação foram estabelecidos para montar a tabela 13:
1) Artefatos Utilizados: indica quais artefatos são utilizados pelo trabalho
para proceder a análise dos dados;
2) Utiliza abordagem GORE: indica se o trabalho utiliza os conceitos da
engenharia de requisitos orientada a objetivos em sua aplicação;
3) Dados Analisados: Indica qual(is) o(s) dado(s) é(são) analisado(s) no
trabalho em questão;
4) Documentação Gerada: Indica qual a documentação gerada como dados
de saída que mostram os resultados encontrados pela aplicação do
trabalho;
5) Automação: indica o grau de automação que o trabalho possui,
informando se é automatizado, semiautomatizado (possui ferramenta para
aplicação do processo) ou manual.
64
Tabela 14: Comparação Entre os Trabalhos Relacionados
Critérios Artefatos Utilizados
Utiliza GORE
Dados Analisados
Documentação Gerada
Automação Trabalho
Uso de modelos i* para enriquecer requisitos ágeis
Histórias de Usuário no formato de Mike Cohn
(2006)
Sim Requisitos Ágeis Modelo SD e
SR Semi
automatizada
Scrum i* Atores
Organizacionais
Sim Dependência entre atores
organizacionais
Modelo SD com legenda
Semi automatizada
ou Manual
Adopting Agile Methods: can Goal-Oriented
Social Modeling help?
Atores doProcesso do
Scrum Sim
Relacionamento entre os atores
do Scrum Modelo SD
Semi automatizada
The new user story backlog is a
map
Cartões de Histórias de
Usuário Não Requisitos Ágeis
Nenhuma, a proposta gera organização
dos cartões na parede.
Manual
Analisando a tabela 14, podemos destacar alguns pontos. O primeiro deles diz
respeito ao critério de artefatos utilizados por cada trabalho para sua aplicação.
Somente a proposta desta dissertação e o trabalho de Patton (2008) utilizam os
requisitos ágeis, na forma de histórias de usuários, como artefatos de entrada. O
trabalho de Scheidegger (2011) utiliza os atores organizacionais como artefato e o
trabalho de Esfahani, Cabot e Yu (2010) utiliza os atores envolvidos no processo do
Scrum como artefatos.
Sobre o critério de usar GORE, apenas o trabalho de Patton (2008) não utiliza
essa abordagem. Os demais utilizam a engenharia de requisitos orientada a objetivos
para aplicarem suas propostas.
Outro ponto a ser mencionado é o critério de dados analisados pelos trabalhos. A
proposta desta dissertação e de Patton (2008) analisa o relacionamento entre os
requisitos ágeis, na forma de histórias de usuário. A proposta de Scheidegger (2011),
Scrum i*, analisa o relacionamento entre os atores organizacionais. O relacionamento
entre os atores envolvidos no processo Scrum são analisados no trabalho de
Esfahani, Cabot e Yu (2010).
A respeito da documentação gerada por cada trabalho, dois deles geram os
modelos SD para análise: o trabalho de Scheidegger (2011) e o trabalho de Esfahani,
Cabot e Yu (2010). É interessante comentar que a proposta desta dissertação permite
gerar tanto o modelo SD quanto o modelo SR para análise das histórias de usuário,
permitindo assim, uma análise no nível mais alto através do modelo SD e em um
65
nível mais específico de acordo com cada ator, através do modelo SR. Já a proposta
de Patton (2008) não gera documentação, pois seu uso está associado à organização
física dos cartões de histórias de usuário de maneira diferenciada na parede onde são
fixados.
Por fim, a respeito do critério sobre o nível de automação de cada trabalho, dois
são semiautomatizados, a proposta desta dissertação e o trabalho de Esfahani, Cabot
e Yu (2010), ou seja, ambos oferecem ferramentas que dão suporte em parte ao
processo por eles proposto. O trabalho de Scheidegger (2011), pode ser
semiautomatizado ou manual e o trabalho de Patton (2008) é somente manual, pois
corresponde à organização física dos cartões de histórias de usuário na parede onde
são fixados.
Perante os pontos aqui destacados, é possível verificar que cada um dos
trabalhos possui suas próprias características, que os diferem um dos outros. Assim,
é possível perceber o que cada um tem em comum, bem como as diferenças e
limitações existentes entre eles.
66
6 Considerações Finais
Por utilizarem processos mais simplificados no desenvolvimento de software, os
métodos ágeis ganharam muito interesse e vêm sendo bastante utilizados. Neles, a
elicitação de requisitos é realizada com clientes que fazem parte da equipe de
desenvolvimento, de forma incremental, de acordo com as prioridades do cliente.
De acordo com a revisão sistemática intitulada Os Desafios dos Requisitos nos
Métodos Ágeis realizada por Jaqueira et al.(2012), um dos principais desafios
apontados é a falta de documentação de requisitos no ambiente de desenvolvimento.
Observou-se que mesmo a documentação mínima sendo uma das premissas dos
métodos ágeis, nos ambientes reais de desenvolvimento as equipes ainda sentem
falta de alguma forma de documentar os requisitos.
Deste modo, esta dissertação propõe o uso de modelos i* para enriquecer requisitos
em métodos ágeis, como uma forma de documentação visual para amenizar essa
carência externada por equipes de desenvolvimento ágil. A proposta consiste no
mapeamento das histórias de usuário para os modelos da técnica i*, fornecendo
assim uma visualização abrangente das histórias de usuário, no que tange os atores
envolvidos, seus relacionamentos no contexto do sistema, bem como suas relações de
dependências entre si e entre o sistema.
Assim, a proposta deste trabalho é apresentada de maneira detalhada no
Capítulo 3, mostrando o processo de mapeamento das histórias de usuário para os
modelos i*, as heurísticas utilizadas no passo a passo para realizar o mapeamento,
bem como um exemplo de sua aplicação para demonstrar seu uso e a tornar mais
clara e melhor entendida.
Foi realizado um estudo de caso para avaliar a proposta e testar as hipóteses
desta dissertação: (i) verificar como o uso de modelos i* para enriquecer requisitos em
métodos ágeis contribui na melhoria dos projetos de desenvolvimento ágil de software
e (ii) avaliar a viabilidade de seu uso como forma de documentação.
De acordo com o estudo de caso, o desempenho dos participantes no uso da
proposta foi bom. Para a maioria, seu uso melhora a visualização do contexto do
sistema a ser desenvolvido, facilita o acesso aos requisitos e contribui na tomada de
decisão. Sobre seu funcionamento como uma forma de documentação no ambiente
ágil, a maioria dos participantes também concordou, afirmando a utilidade da
mesma e demonstrando interesse em utilizá-la no seu ambiente de trabalho. Dessa
forma, as soluções propiciadas pela técnica i* de modelar os relacionamentos de
dependência e tornar a compreensão social parte integrante do processo de
desenvolvimento, permitindo melhor compreensão e análise do problema
67
mostraram-se adequadas e úteis ao ambiente de desenvolvimento ágil. O capítulo 4
desta dissertação apresenta o estudo de caso e seus resultados detalhadamente.
A Seção 6.1 apresenta as principais contribuições desta dissertação e a Seção 6.2
apresenta as propostas de trabalhos futuros, a fim de dar continuidade a essa
pesquisa.
6.1 Contribuições
A contribuição mais importante deste trabalho é a elaboração de uma proposta
para amenizar a carência de documentação no ambiente de desenvolvimento ágil
através de modelos visuais. Também podemos apresentar as seguintes contribuições
desta proposta:
forma de documentação no ambiente ágil;
melhoria no entendimento do contexto do sistema a ser desenvolvido;
o uso e o acesso mais fácil à informação dos requisitos a partir da visualização
do modelo visual;
melhoria do processo de tomada de decisão de acordo com a análise dos
requisitos, levando ao entendimento dos objetivos do sistema e ao raciocínio
do por quê de um requisito uma vez que estão descritos em modelos i*;
suporte ferramental, possibilitando a automatização de algumas de suas
etapas (construção dos modelos SD e SR).
Além das contribuições já citadas, diretamente relacionadas à proposta deste
trabalho, também destacamos as seguintes contribuições importantes desta
dissertação:
a revisão sistemática realizada para destacar os desafios dos requisitos ágeis;
a definição do planejamento do Estudo de Caso;
a realização do Estudo de Caso que avaliou a proposta desta dissertação.
6.2 Trabalhos Futuros
Com o objetivo de dar continuidade à pesquisa desenvolvida por esta
dissertação, destacamos os seguintes trabalhos futuros:
o desenvolvimento de diretrizes e/ou uma ferramenta para realizar a
transformação das histórias de usuário para o formato de Mike Cohn (2006)
utilizado neste trabalho, de modo a poder utilizar esta proposta para histórias
de usuário fornecidas em outros formatos;
o desenvolvimento de uma ferramenta própria para a proposta deste trabalho
de modo que o mapeamento das histórias de usuário para os modelos i* se
torne totalmente automatizado;
68
o desenvolvimento de diretrizes para realizar o mapeamento “de volta”, dos
modelos i* para as histórias de usuário;
o tratamento da escalabilidade para o ator Sistema;
a verificação da possibilidade de representar as tarefas nos demais atores do
modelo;
a verificação da possibilidade de representar o relacionamento entre os demais
atores no modelo;
a execução de outros estudos de caso que comparem a proposta desta
dissertação a outros trabalhos relacionados para verificar com precisão as
diferenças e similaridades, bem como identificar possíveis melhorias a serem
feitas na proposta deste trabalho;
a definição de um processo de engenharia de requisitos para métodos ágeis
envolvendo modelos i*.
69
70
Referências
[Abrahamsson et al., 2003] Abrahamsson, P., Warsta, J., Siponen, M.T., Ronkainen, J.,
Newdirections on agile methods: a comparative analysis, in: Proceedings of the 25th
International Conference on Software Engineering (ICSE’03), IEEE Press, 2003.
[Alencar, 1999] Alencar, Fernanda Maria Ribeiro de. Mapeando a Modelagem
Organizacional em Especificações Precisas. 1999. 302 fls. Tese (Doutorado em Ciência
da Computação). Universidade Federal de Pernambuco, Recife, Centro de
Informática, Programa de Pós-Graduação em Ciência da Computação. 1999.
Disponível em: <http://istar.rwth-aachen.de/tiki-index.php?page=i%2A-
related+Phd+Dissertations&structure=i%2A+Wiki+Home>. Acesso em 20/06/2012.
[Ambler, 2002] Ambler, S. W. Apresentação. In Astels, D., Miller, G. e Novak, M.
Extreme Programming: Guia Prático. Tradução: Kátia Roque. Rio de Janeiro:
Campus, 2002.
[Babinet e Ramanathan, 2008] Babinet, E., Ramanathan, R.: Dependency management
in a large agile environment. In: AGILE Conference, pp. 401–406 (2008).
[Bassi, 2008] Bassi, D. Experiências com desenvolvimento ágil, Dissertação de
Mestrado, Universidade de São Paulo, 2008.
[Beatty e Chen, 2012] Beatty, J. e Chen, A. Visual Models for Software Requirements.
Washington, Microsoft Press: 2012.
[Beck, 2004] Beck, K. Programação extrema explicada: acolha as mudanças,
Tradução: Adriana P.S. Machado e Natália N. P. Lopes, Porto Alegre: Bookman,
2004.
[Bjarnason; Wnuk e Regnell, 2011] Bjarnason, E., Wnuk, K. and Regnell, B. (2011) A
Case Study on Benefits and Side-Effects of Agile Practices in Large-Scale
Requirements Engineering. In Proceedings of the 1st Workshop on Agile
Requirements Engineering.
[BPMN, 2012] Disponível em http://www.bpmn.org/ Acesso em 28/11/2012.
[Cao e Ramesh, 2008] Cao, L. and Ramesh, B., Requirements Engineering Practices:
An Empirical Study, IEEE Software, Volume: 25, Issue: 1. page(s): 60-67 (2008).
[Carlshamre et al., 2001] P. Carlshamre, K. Sandahl, M. Lindvall, B. Regnell, and J. N. och
Dag. An industrial survey of requirements interdependencies in software product release
planning. In Proc. of the IEEE Int. Req. Eng. Conf. (RE), pages 84–93,2001.
[Carvalho, 2003] Carvalho, Francisco dos Santos. Modelagem Organizacional e Gestão do
Conhecimento: O Caso da Universidade Estadual do Sudoeste da Bahia. 2003. 147 fls.
Dissertação (Mestrado em Ciência da Computação). Universidade Federal de Pernambuco,
71
Centro de Informática, Programa de Pós-Graduação em Ciência da Computação, Recife,
2003.
[Chung et al., 2000] Chung, L., Nixon, B. A., Yu, E., and Mylopoulos, J., Non-
Functional Requirements in Software Engineering, 1st ed. Springer, October 2000.
[Cockburn, 2007] Cockburn, A. (2007). Agile Software Development: The
Cooperative Game. Boston, Pearson.
[Cohn, 2004] Cohn, M.: User Stories Applied: For Agile Software Development (The
Addison-Wesley Signature Series), March. Addison-Wesley Professional, Reading
(2004).
[Cohn, 2006] Cohn, M. Agile Estimating and Planning. Prentice Hall, 2006.
[Dardenne; Lamsweerde e Fickas, 1993] Dardenne, A., Lamsweerde, A. van and
Fickas, S., "Goal-directed requirements acquisition," Science of Computer
Programming, vol. 20, no. 1-2, pp. 3-50, April 1993.
[Denne e Cleland-Huang, 2004] Denne, M., Cleland-Huang, J.: The incremental
funding method: Data-driven software development. IEEE Software 21(3), 39–47
(2004).
[Engholm, 2010] Engholm Júnior, H., Engenharia de Software na Prática, São Paulo:
Novatec, 2010.
[Espinoza e Garbajosa, 2011] Espinoza, A. and Garbajosa, J. (2011) “Study to Support
Agile Methods More Effectively through Traceability,” Computer Science
Innovations in Systems and Software Engi-neering, Vol. 7, No. 1, 2011, pp. 53-69.
[Fowler, 2011] Fowler, M. The new methodology. Disponível em:
<http://www.martinfowler.com/articles/newMethodology.html>. Acesso em
03/12/2011.
[Gallardo-Valencia e Sim, 2009] Gallardo-Valencia, R.E. and Sim, S.E. (2009)
Continuous and Collaborative Validation:A Field Study of Requirements Knowledge
in Agile. In: proceedings of the Second International Workshop on Managing
Requirements Knowledge. IEEE Computer.
[Gomez; Rueda e Alarcón, 2010] Gomez, A., Rueda, G., & Alarcón, P. P. (2010). A
Systematic and Lightweight Method to Identify Dependencies between User Stories.
In A. Sillitti, A. Martin, X. Wang, & E. Whitworth (Eds.), Agile Processes in Software
Engineering and Extreme Programming (Vol. 48, pp. 190-195): Springer Berlin
Heidelberg.
[Greer e Ruhe, 2004] Greer, D., Ruhe, G.: Software release planning: an evolutionary
and iterative approach. Information and Software Technology 46, 243–253 (2004).
72
[Highsmith, 2000] Highsmith, J. A., Adaptive Software Development: A
Collaborative Approach to Managing Complex Systems. New York, NY: Dorset
House Publishing, 2000.
[Highsmith e Cockburn, 2001] Highsmith, J. and Cockburn, A., "Agile Software
Development: The Business of Innovation," Computer, vol. 34, pp. 120-122, 2001.
[Hoda; Noble e Marshall, 2010] Hoda, R., Noble, J. and Marshall, S. (2010) Agile
Undercover: When Customers Don’t Collaborate In: XP2010, Trondheim.
[Horkoff, 2009] Horkoff, J., Yu, E.: A Qualitative, Interactive Evaluation Procedure
for Goal- and Agent-Oriented Models. In: CAiSE Forum. CEUR Workshop
Proceedings (2009)
[IBM, 2012] Data sets : Example of User Stories Disponível em <http://www-
958.ibm.com/software/analytics/manyeyes/datasets/example-of-user-
stories/versions/1> Acesso em 05/12/2012.
[i* Wiki, 2012] i* Wiki Home, Disponível em <http://istar.rwth-aachen.de/tiki-
index.php> Acesso em 10/08/2012.
[Jaqueira et al., 2012] Jaqueira A., Andreotti, E., Lucena, M., Aranha, E. Desafios de
Requisitos em Métodos Ágeis: Uma Revisão Sistemática 3rd Brazilian Workshop on
Agile Methods, São Paulo, 2012.
[Jeffries, 2001] Jeffries, R., 2001. Essential XP: Card, Conversation, Confirmation.
Disponível em:
<http://www.xprogramming.com/xpmag/expCardConversationConfirmation >
Acesso em 26/10/2012.
[Lamsweerde, 2001] Lamsweerde, A.van, "Goal-oriented requirements engineering:
A guided tour," in RE '01: Proceedings of the 5th IEEE International Symposium on
Requirements Engineering. Washington, DC, USA: IEEE Computer Society, 2001.
[Lamsweerde, 2003] Lamsweerde, A. van, From system goals to software
architecture. In 3rd Interl School on Formal Methods for the Design of Computer,
Communication and Soft Systems, 2003.
[Lamsweerde, 2009] Lamsweerde, A. van, Requirements Engineering: From System
Goals to UML Models to Software Specifications. Wiley, March 2009.
[Leffingwell e Behrens, 2009] Leffingwell, D. e Behrens, P. A User Story Primer,
LLC, 2009. Disponível em <http://trailridgeconsulting.com/files/user-story-
primer.pdf> Acesso 03/10/2012.
[Logue e McDaid, 2008] Logue, K., McDaid, K.: Handling uncertainty in agile
requirement prioritization and scheduling using statistical simulation. In: Agile 2008,
pp. 73–82. IEEE CS, Los Alamitos (2008).
73
[Manifesto, 2001] Manifesto for Agile Software Development, 2001. Disponível em
<http://www.agilemanifesto.org/> Acesso em 04/08/2012.
[McCauley, 2001] McCauley, R. "Agile Development Methods Poised to Upset Status
Quo," SIGCSE Bulletin, vol. 33, pp. 14 - 15, 2001.
[Mordinyi; Kühn e Schatten, 2010] Mordinyi, R., Kühn, E. and Schatten, A. (2010)
Structuring Complexity Issues for Efficient Realization of Agile Business
Requirements in Distributed Environments. in: Proc. Agile Processes in Software
Engineering and Extreme Programming, Springer Berlin Heidelberg, 48. ISBN: 978-3-
642-13054-0; S. 202 - 207.
[Nuseibeh e Easterbrook, 2000] Nuseibeh, B. and Easterbrook, S. Requirements
Engineering: A Roadmap , Proceedings of International Conference on Software
Engineering (ICSE-2000), 4-11 June 2000, Lime-rick, Ireland, ACM Press.
[OME, 2012] Organization Modelling Environment. Disponível em
<http://www.cs.toronto.edu/km/ome/>. Acesso em 03/11/2012.
[O’hEocha e Conboy, 2010] O’hEocha, C., & Conboy, K. (2010). The role of the user
story agile practice in innovation. In P. Abrahamsson & N. Oza (Eds.), Lean
enterprise software and systems (pp. 20-30). New York: Springer.
[Paetsch; Eberlein e Maurer, 2003] Paetsch, F., Eberlein, A. and Maurer, F.
Requirements Engineering and Agile Software Development, Proc.12th IEEE Int’l
Workshops Enabling Technologies: Infrastructure for Collaborative Enterprises
(WETICE 03), IEEE CS Press, 2003, pp. 308–313.
[Palmer e Felsing, 2002] Palmer, S. R., & Felsing, J. M. (2002). A practical guide to
Feature-Driven Development. Upper Saddle River, NJ: Prentice Hall PTR.
[Patton, 2008] Patton, J. (2008). "The new user story backlog is a map." Disponível em
<http://www.agileproductdesign.com/blog/the_new_backlog.html> Acesso em
03/10/2012.
[Savolainen; Kuusela e Vilavaara, 2010] Savolainen, J., Kuusela, J., and Vilavaara, A.
(2010) Transition to Agile Development - Rediscovery of Important Requirements
Engineering Practices. Paper presented at the 18th IEEE international requirements
engineering conference (RE), 2010. IEEE Computer Society (PP. 89-294)
[Santander, 2002] Santander, Victor Francisco Araya. Integrando Modelagem
Organizacional com Modelagem Funcional. 2002. 221fls. Tese (Doutorado em Ciência
da Computação). Universidade Federal de Pernambuco, Centro de Informática,
Programa de Pós-Graduação em Ciência da Computação, Recife, 2002. Disponível
em:<http://istar.rwth-aachen.de/tiki-ndex.php?page=i%2A-
related+Phd+Dissertations&structure=i%2A+Wiki+Home>. Acesso em 08/08/2012.
74
[Scheidegger, 2011] Scheidegger, M.E.S., Integrando Scrum e a Modelagem de
Requisitos Orientada a Objetivospor meio do SCRUM i*. Dissertação de Mestrado.
UFPE – CIN (2011).
[Schwaber, 1997] Schwaber, K. Scrum Development Process, in OOPSLA Business
Object Design and Im-plementation Workshop, J. Sutherland, D. Patel, C. Casanave,
J. Miller, and G. Hollowell, Eds. London: Springer, 1997.
[Sen e Hemachandran, 2010] Sen, A.M. and Hemachandran, K. (2010) Elicitation of
Goals in Requirements Engineering using Agile Methods. In: REFS 2010. 19-23 July
2010. Seoul Korea.
[Sharp e Robinson, 2004] Sharp, H., and Robinson, H. 2004. “An Ethnographic Study
of XP Practice,” Empirical Software Engineering (9:4), pp. 353-375.
[Sharp et al., 2006] Sharp, H., Robinson, H. Segal, J. and Furniss, D. (2006) ‘The Role
of Story Cards and the Wall in XP teams: a distributed cognition perspective’,
Proceedings of Agile 2006, IEEE Computer Society Press, pp65-75.
[Sharp; Robinson e Petre, 2009] Sharp, H., Robinson, H., Petre, M., The role of
physical artefacts in agile software development: two complementary perspectives,
Interacting with Computers 21 (2009) 108–116.
[Silva, 2008] Silva, M. J. U-TROPOS: uma proposta de processo unificado para apoiar
o desenvolvimento de software orientado a agentes. Dissertação de Mestrado.
Universidade Federal de Pernambuco, CIn. Ciência da Computação, 2008.
[Silva Junior, 2011] Silva Junior, Josias Paes da. AGILE: uma abordagem para geração
automática de linguagens i*. 2011. 131 fls. Dissertação (Mestrado em Ciência da
Computação). Universidade Federal de Pernambuco, Centro de Informática,
Programa de Pós-Graduação em Ciência da Computação, Recife, 2011. Disponível
em
<http://portal.cin.ufpe.br/ler/Our%20Publications/Dissertations/JosiasPaes2011.p
df>. Acesso em 10/09/2012.
[Sommerville, 2007] Sommerville, I. Engenharia de Software, 8ª edição, Tradução:
Selma Shin Shimizu Mel-nikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa;
São Paulo: Pearson Addison-Wesley, 2007.
[Standish Group, 1994] Standish Group. The CHAOS report, 1994 Disponível em:<
http://www.standishgroup.com/sample_research/chaos_1994_2.php> Acesso em
03/05/2012.
[Teles, 2004] Teles, V. M. Extreme Programming: Aprenda como Encantar seus
Usuários Desenvolvendo Software com Agilidade e Alta Qualidade. São Paulo:
Novatec, 2004.
75
[Ton, 2007] Ton, H.: A strategy for balancing business value and story size. In:
Proceedings of the AGILE 2007, Washington, DC, USA, pp. 279–284. IEEE Computer
Society Press, Los Alamitos (2007).
[Travassos, 2002] Travassos, G. H.; Gurov, D.; Amaral, E. A. G. (2002). Introdução à
Engenharia de Software Experimental. Relatório Técnico. Rio de Janeiro.
[Vlaanderen et al., 2009] Vlaanderen, K., Jansen, S., Brinkkemper, S., Jaspers, E. (2009)
The Agile Requirements Refinery: Applying SCRUM Principles to Software Product
Management. In: 3rd International Workshop on Software Product Management.
[Yu, 1995] Yu, E. “Modelling Strategic Relationships for Process Reengineering”. PhD
thesis.University of Toronto, Department of Computer Science. 1995.
[Yu, 2009] Yu, E., Social Modeling and i*, in LNCS. 2009, Springer Berlin /
Heidelberg. p. 99-121.
[Yu e Mylopoulos, 2004] Yu, Y., Julio, and J. Mylopoulos, "From goals to aspects:
Discovering aspects from requirements goal models," in RE '04: Proceedings of the
Requirements Engineering Conference, 12th IEEE International (RE'04). Washington,
DC, USA: IEEE Computer Society, 2004, pp. 38-47.
76
Apêndice A – Escopo do Sistema Utilizado no Estudo de Caso
Sistema para Gerência de Projetos
Visão do Produto
O sistema consiste basicamente em um sistema web capaz de fornecer um ambiente
para organizar, gerenciar tarefas e projetos de uma empresa e promover uma maior
interação entre seus membros. O serviço, inicialmente, está voltado para o contexto
de empresas juniores.
O cadastro de uma empresa nesse sistema só é possível via convite e o uso do serviço
é pago mensalmente. Através desse sistema, uma conta empresa poderá convidar
seus membros para que eles possam utilizar o software. Projetos poderão ser criados
e administrados dentro do sistema.
77
Apêndice B – Histórias de Usuário Utilizadas no Estudo de Caso
Fonte: Empresa Júnior 4Soft
Histórias de Usuário
Papel Ação Meta
01 Administrador Logar no sistema Usar o sistema
02 Administrador Convidar empresa Empresa se cadastrar
03 Empresa Logar no sistema Usar o sistema
04 Empresa Convidar funcionários
Funcionários se cadastrarem
05 Empresa Atualizar meus dados
Ter dados atualizados
06 Empresa Confirmar meu cadastro
Acessar o sistema
07 Funcionário Logar no sistema Usar o sistema
08 Funcionário Confirmar meu cadastro
Acessar o sistema
09 Funcionário Atualizar meus dados
Ter dados atualizados
10 Funcionário Criar um projeto Gerenciar o projeto
11 Funcionário Editar tarefas do projeto
Gerenciar tarefas do projeto
12 Funcionário Gerar relatórios Leitura e análise do relatório
13 Funcionário Submeter relatórios Anexar relatórios aos projetos
14 Funcionário Líder
Vincular e desvincular funcionários ao projeto
Adicionar ou excluir funcionários do projeto
15 Funcionário Líder
Alterar liderança do projeto
Outro funcionário possa ser líder do projeto
16 Convidado Me cadastrar Usar o sistema
17 Convidado Cadastrar minha empresa
Gerenciar minha empresa
78
Apêndice C – Modelos SD e SR Utilizado com o Grupo de Equipe de Desenvolvimento no Estudo de Caso
79
Apêndice D – Questionário I Aplicado ao Grupo de Engenheiros de Requisitos no Estudo de Caso
Parte 1 - Dados Pessoais
Escolaridade:________________________Formação/Curso:_________________________
Experiência com requisitos de software:
( ) Nenhuma ( ) Menos de 1 ano ( ) 1 a 3 anos ( ) Mais de 3 anos
Experiência com requisitos ágeis:
( ) Nenhuma ( ) Menos de 1 ano ( ) 1 a 3 anos ( ) Mais de 3 anos
Parte 2 - Aprendizado Nesta parte do questionário queremos saber sua opinião quanto ao seu entendimento na utilização da
proposta avaliada.
1. Como você julga seu aprendizado da proposta?
( ) Ruim ( ) Razoável ( ) Bom ( ) Ótimo
Por quê?
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Parte 3 – Desempenho Nesta parte do questionário queremos saber sua opinião quanto ao seu desempenho na utilização da proposta avaliada
2. Como você julga seu desempenho na utilização da proposta avaliada?
( ) Ruim ( ) Razoável ( ) Bom ( ) Ótimo
Por quê?
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
3. Em quais passos você teve maior dificuldade?
80
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
4. E em quais passos você teve maior facilidade?
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
_________________________________________________________________________
Parte 4 – Relevância Nesta parte do questionário queremos saber sua opinião quanto à relevância da proposta avaliada
5. Você considera que o mapeamento das histórias de usuário para os modelos i* propicia
melhora na visualização do contexto do sistema a ser desenvolvido?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
6. O mapeamento das histórias de usuário para modelos i* torna mais fácil o uso e acesso à
informação dos requisitos?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
7. Você considera que o uso dos modelos i* para visualizar requisitos pode contribuir para o
processo de tomada de decisão quanto aos requisitos na equipe de desenvolvimento?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
8. Você considera que o uso dos modelos i* pode funcionar como uma forma de
documentação dos requisitos do sistema?
( ) Sim ( ) Não
Por quê?
81
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
9. Você considera que é útil aplicar os modelos i* para visualizar requisitos no ambiente de
desenvolvimento?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
10. Analisando os modelos i* você notou alguma informação diferenciada nos requisitos que
não tenha sido notada nas histórias de usuário?
( ) Sim ( ) Não
Se sim, qual informação?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Parte 5 - Uso da proposta Nesta parte do questionário queremos saber sua opinião quanto ao uso da proposta
11. Você utilizaria a proposta no seu ambiente de desenvolvimento?
( ) Sim ( ) Não
Por quê?
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Parte 6 – Comentários
12. Caso tenha algum comentário em relação à proposta, sinta-se a vontade para fazê-lo.
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
82
Apêndice E – Questionário II Aplicado ao Grupo de Equipe de Desenvolvimento no Estudo de Caso
Parte 1 - Dados Pessoais
Escolaridade:________________________Formação/Curso:_________________________
Experiência com desenvolvimento de software:
( ) Nenhuma ( ) Menos de 1 ano ( ) 1 a 3 anos ( ) Mais de 3 anos
Experiência com metodologia ágil:
( ) Nenhuma ( ) Menos de 1 ano ( ) 1 a 3 anos ( ) Mais de 3 anos
Parte 2 – Entendimento Nesta parte do questionário queremos saber sua opinião quanto ao seu entendimento na utilização da
proposta avaliada.
1. O escopo do sistema e os requisitos apresentados foram bem entendidos?
( ) Sim ( ) Não ( ) Razoavelmente
2. Como você julga seu entendimento da proposta (técnica i* aplicada às histórias de
usuário)?
( ) Ruim ( ) Razoável ( ) Bom ( ) Ótimo
Parte 3 – Relevância Nesta parte do questionário queremos saber sua opinião quanto à relevância da proposta avaliada
3. Você considera que o mapeamento das histórias de usuário para os modelos i* propicia
melhora na visualização do contexto do sistema a ser desenvolvido?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
______________________________________________________________________
4. O mapeamento das histórias de usuário para modelos i* torna mais fácil o uso e acesso à
informação dos requisitos?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
83
5. Você considera que o uso dos modelos i* para visualizar requisitos pode contribuir para o
processo de tomada de decisão ou negociação na equipe de desenvolvimento?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
6. Você considera que o uso dos modelos i* pode funcionar como uma forma de
documentação dos requisitos do sistema?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
7. Você considera que é útil aplicar os modelos i* para visualizar requisitos no ambiente de
desenvolvimento?
( ) Sim ( ) Não
Por quê?
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Parte 4 - Uso da proposta Nesta parte do questionário queremos saber sua opinião quanto ao uso da proposta
8. Você gostaria que a proposta fosse utilizada no seu ambiente de desenvolvimento?
( ) Sim ( ) Não
Por quê?
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
84
Parte 5 – Comentários
9. Caso tenha algum comentário em relação à proposta, sinta-se a vontade para fazê-lo.
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
85
Apêndice F – Revisão Sistemática
Desafios de Requisitos em Métodos Ágeis: Uma Revisão
Sistemática
Aline Jaqueira1, Elisa Andreotti
2, Márcia Lucena
1, Eduardo Aranha
1
1 Departamento de Informática e Matemática Aplicada
UFRN Natal –RN
2 Centro de Pós-Graduação e Extensão
FUCAPI Manaus - AM
[email protected], [email protected],
{marciaj,eduardoaranha}@dimap.ufrn.br
Abstract. Agile methods are inserted in dynamic software development
environments where requirements are constantly changing and are built from the
feedback of stakeholders during the development. Although many changes occur in
requirements, little emphasis is given in requirement specification in agile methods.
In this context, this paper presents a systematic review of requirements in agile
methods in order to present a survey about who is discussing requirements in agile
methods, what are the main challenges and what are the proposals to solve them.
Resumo: Métodos ágeis estão inseridos em ambientes de desenvolvimento de
software dinâmicos onde os requisitos estão em constante modificação e são
construídos a partir do feedback dos stakeholders no decorrer do desenvolvimento.
Apesar de ocorrer muitas alterações nos requisitos pouca ênfase é dada à atividade
de especificação de requisitos no contexto de métodos ágeis. Neste contexto, este
trabalho apresenta uma revisão sistemática sobre requisitos em métodos ágeis a fim
de apresentar um levantamento de quem está discutindo o assunto sobre requisitos
em métodos ágeis, quais os principais desafios apontados e as propostas para
solucioná-los.
1. Introdução
Os métodos ágeis têm ganhado cada vez mais espaço no desenvolvimento de software e
interesse entre profissionais e pesquisadores [Cao; Ramesh 2008]. A rápida transformação do
ambiente de negócios é um desafio ao desenvolvimento de software, devido às exigências
para o software evoluírem tão rapidamente que, em alguns casos, os requisitos se tornam
obsoletos antes mesmo do término do projeto. Assim, os métodos ágeis surgiram com o
objetivo de minimizar os principais desafios no contexto atual de desenvolvimento.
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]. Pode ser 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].
86
Apesar da importância da engenharia de requisitos no sucesso do desenvolvimento do
software e na minimização dos riscos de projeto, essa atividade é vista nos métodos ágeis
como atividade burocrática que torna o processo menos ágil, pois nos métodos ágeis é dada
uma maior ênfase na codificação. A principal justificativa ocorre devido ao fato de que os
requisitos mudam tão rapidamente que um documento de requisitos fica desatualizado tão
logo seja redigido, desperdiçando todo esforço empreendido na documentação. Nesse
contexto, a engenharia de requisitos e os métodos ágeis podem ser considerados atividades
incompatíveis segundo alguns autores como [Paetsch; Eberlein; Maurer 2003]. Portanto, para
melhor entender como os requisitos são tratados nos métodos ágeis este trabalho busca fazer
uma revisão sistemática dos principais trabalhos acadêmicos, conferências, workshops que
discutem o assunto apresentando os principais desafios encontrados e as propostas existentes
para solucioná-los.
Este trabalho está organizado da seguinte forma: a seção 2 apresenta os trabalhos
relacionados. A seção 3 descreve a metodologia utilizada para a busca de trabalhos e para a
extração de resultados, bem como as questões de pesquisa. A seção 4 apresenta a análise dos
resultados encontrados em resposta às questões. A seção 5 apresenta uma discussão sobre os
resultados. Por fim, a seção 6 apresenta as conclusões deste trabalho.
2. Trabalhos Relacionados
Inicialmente, a fim de encontrar revisões sistemáticas relacionadas com métodos ágeis, foi
realizada uma busca na literatura através do site para pesquisa livre de ciência da computação
Free Search (http://dblp.isearch-it-solutions.net/dblp/). Foi encontrado um trabalho de 2008
[Dyba and Dingsøyr 2008] que avalia, sintetiza e apresenta os resultados empíricos do
desenvolvimento ágil de software. No Google Acadêmico foi encontrada uma revisão
sistemática de 2009 [Hossain, Babar and Paik 2009] cujo objetivo é apresentar os desafios no
uso do Scrum para desenvolvimento global de software bem como as estratégias para lidar
com eles. Também foi encontrado um estudo empírico de [Cao; Ramesh, L. and Ramesh, B.
2008] que apresenta práticas de requisitos ágeis utilizadas no contexto de projetos reais
mostrando seus benefícios e desafios.
O presente estudo apresenta uma perspectiva acadêmica sobre o assunto, destacando
os principais desafios de requisitos em métodos ágeis e as principais propostas da literatura
que tentam tratar esses desafios. Assim, este trabalho mostra-se relevante para os
pesquisadores e profissionais da área no sentido de apoiá-los nas pesquisas e na adoção das
metodologias ágeis.
3. Método de Pesquisa
De acordo com [Kitchenham; Charters 2007], a revisão sistemática é uma forma de estudo
secundário que usa uma metodologia bem definida para identificar, analisar e interpretar as
evidências disponíveis relacionadas a uma questão de pesquisa específica de forma imparcial.
Para a elaboração deste trabalho foi adotado o guia de [Kitchenham; Charters 2007]
considerado uma referência na área de engenharia de software experimental. A pesquisa foi
realizada na literatura publicada em conferências e jornais da área de Ciências da Computação
que citaram o assunto ‘requisitos e métodos ágeis’. O período anual delimitado foi de 2008 a
2012 de modo a destacar os resultados mais recentes.
3.1 Questões de pesquisa
Para realizar o levantamento a que se propõe este trabalho, foram elaboradas as seguintes
questões de pesquisa:
87
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?
A questão Q3 procura por propostas que tratam os desafios endereçados pela questão
Q2. As propostas são divididas de acordo com as questões Q3.1 e Q3.2 com o objetivo de
fazer um levantamento tanto de propostas provenientes de métodos ágeis como também
propostas de adaptações de métodos tradicionais que tratam os desafios de requisitos em
métodos ágeis.
3.2 Processo de Busca
As buscas foram realizadas sobre o título e o resumo dos 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. A
string utilizada na busca automática foi (“Requirements Engineering” AND “Agile methods”)
OR (“Agile requirements”).
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). Essas buscas
foram feitas em paralelo com as buscas automáticas. Os resultados das buscas automáticas e
manuais foram unidos e as duplicatas removidas. A lista final de estudos potencialmente
relevantes foi a entrada para a atividade de seleção do estudo.
3.3 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 usados foram: (i) o artigo menciona explicitamente requisitos em métodos ágeis; (ii)
o artigo menciona problemas com requisitos em métodos ágeis; (iii) o artigo menciona
contribuições (extensões ou adaptações em metodologias) para tratar requisitos em métodos
ágeis; (iv) o estudo usado no artigo é empírico com métodos ágeis. O critério de exclusão
adotado foi: (i) estudos incompletos como resumos ou apresentação de slides.
3.4 Seleção do Estudo
O procedimento adotado para seleção desta pesquisa foi dividido em duas etapas. Na primeira
etapa, Aline Jaqueira (AJ) e Elisa Andreotti (EA) analisaram o conjunto de estudos obtidos
através das buscas automáticas e manuais considerando os critérios de inclusão e exclusão,
além de observar os títulos, resumos e palavras-chave. Havendo alguma dúvida ou conflito foi
realizada a leitura plena do artigo e discutida sua relevância pelas pesquisadoras para gerar
um consenso. Ao final um conjunto de artigos para a revisão foi selecionado.
Na segunda etapa foram obtidos os artigos completos do conjunto de estudos
potencialmente relevantes da primeira etapa. Esse conjunto de artigos foi dividido de modo
que cada parte fosse avaliada por uma pesquisadora. Nove artigos foram selecionados e
analisados na íntegra: [Cao; Ramesh 2008], [Gallardo-Valencia; Sim 2009], [Vlaanderen et
al. 2009], [Hoda; Noble; Marshall 2010], [Savolainen; Kuusela; Vilavaara 2010], [Sen;
88
Hemachandran 2010], [Mordinyi; Kühn; Schatten 2010], [Bjarnason; Wnuk; Regnell 2011],
[Espinoza; Garbajosa 2011].
4. Análise dos Resultados
Esta seção apresenta a síntese dos resultados deste trabalho de acordo com as questões de
pesquisa organizada em ordem cronológica crescente.
4.1 Questão de pesquisa 1
Q1 – Quais as conferências e workshops publicam sobre métodos ágeis e que podem trazer
discussões sobre requisitos ágeis?
A International Requirements Engineering Conference é o principal fórum
internacional para pesquisadores, educadores, profissionais e estudantes apresentarem e
discutirem as mais recentes inovações, tendências e experiências no campo da Engenharia de
Requisitos. A Agile Conference foi criada por uma equipe de especialistas e profissionais
qualificados envolvidos com métodos ágeis para apresentar propostas no contexto de práticas
ágeis. Esse fórum é dedicado a descobrir maneiras melhores de desenvolver software
inspiradas nos valores e princípios do manifesto ágil. A International Conference XP reúne
trabalhos relacionados aos métodos ágeis, além de apresentar abordagens para requisitos
ágeis.
O primeiro workshop de engenharia de requisitos ágeis, Agile Requirements Engineering
Workshop (AREW), aconteceu em 2011, em Lancaster, Inglaterra dentro da conferência
ECOOP (European Conference on Object-Oriented Programming). O objetivo do workshop
foi fazer um balanço para descobrir as necessidades da engenharia de requisitos ágil e se suas
práticas fornecem o que a metodologia necessita. A tabela 1 mostra uma síntese dos principais
eventos que tratam de requisitos em métodos ágeis.
Tabela 1: Síntese dos eventos de requisitos em métodos ágeis
Evento Periodicidade WebSite do Evento
Workshop on Agile Requirements
Engineering (AREW) Ocorreu em 2011 www.comp.lancs.ac.uk/~gacitur1/AREW11/
International Requirements
Engineering Conference Anual www.requirements-engineering.org/
Agile Development Conference Anual www.agiledevelopmentconference.org
XP / Agile Universe Anual http://www.informatik.uni-
trier.de/~ley/db/conf/xpu/index.html
4.2 Questão de Pesquisa 2
Q2 – Existem desafios apontados para requisitos em métodos ágeis? Quais?
Ao analisar os trabalhos levantados nesta revisão sistemática podemos destacar os
desafios mais citados relacionados a requisitos em métodos ágeis: (i) a disponibilidade do
cliente para fornecer feedback constante, (ii) a gestão da mudança dos requisitos e da
arquitetura do software, (iii) bem como da rastreabilidade já que as mudanças são frequentes,
(iv) limitação do cliente que as vezes não possui autonomia ou capacidade para fornecer
feedback apropriado do projeto como um todo, (v) requisitos não funcionais negligenciados,
(vi) consenso na negociação ou priorização dos requisitos, principalmente quando há mais de
89
um cliente, (vii) documentação que é mínima e sua falta pode causar diversos problemas,
(viii) equipe de desenvolvimento multifuncional, onde o profissional tem vários perfis, (ix)
custo e estimativa do projeto, já que o mesmo tem seu escopo flexível e sofre alterações a
todo momento.
Os principais desafios apontados foram encontrados nos artigos selecionados em que
os estudos são empíricos baseados na experiência da utilização ou migração para métodos
ágeis. Isso contribui para que a avaliação deste trabalho tenha um maior respaldo, já que os
estudos apontam os principais desafios dos métodos ágeis de acordo com a prática.
Em [Cao; Ramesh 2008] os desafios de requisitos em métodos ágeis foram
apresentados utilizando o método Grounded Theory [Strauss; Corbin 1990]. Aplicando um
estudo de caso, foram avaliadas qualitativamente as respostas coletadas em 16 empresas
caracterizadas como desenvolvedoras ágeis dos Estados Unidos. Assim, as principais práticas
ágeis utilizadas nessas empresas foram apresentadas com seus respectivos desafios:
(i) Comunicação face a face no lugar da especificação escrita: como desafio essa prática
apresenta uma dependência de interação entre clientes e desenvolvedores e,
consequentemente, da disponibilidade e aptidão do cliente. Quando isso não é
possível, há riscos de requisitos desenvolvidos de forma inadequada ou incorreta. A
eficácia da comunicação entre o cliente e a equipe depende de vários fatores,
incluindo disponibilidade do cliente, consenso entre os grupos de clientes e confiança
especialmente durante o início do projeto. A dificuldade de ter o cliente disponível
todo o tempo também foi relatada. Outro desafio é a negociação para consenso dos
requisitos quando o projeto tem mais de um cliente envolvido.
(ii) Engenharia de requisitos iterativa: para essa prática, o principal desafio é o custo e a
estimativa de cronograma já que o escopo do projeto está sujeito a constantes
mudanças. Dessa forma, obter apoio da gestão para tais projetos pode ser difícil. Outro
desafio é a documentação mínima, pois quando uma falha de comunicação ocorre
devido, por exemplo, à rotatividade de pessoal, mudanças rápidas nos requisitos ou
indisponibilidade do cliente, a falta de documentação pode causar uma variedade de
problemas. Finalmente, um outro desafio é a negligência na descrição dos requisitos
não-funcionais, que podem ser mal definidos ou ignorados, pois o cliente muitas vezes
está preocupado com funcionalidades essenciais.
(iii) Priorização de requisitos: ao utilizar o valor do negócio como o único critério para
priorização de requisitos corre-se o risco de negligenciar requisitos não funcionais,
como, por exemplo, não atender requisitos de segurança e eficiência. Além disso,
alguns participantes observaram que a redefinição de prioridades contínua, quando
não praticada com cautela, leva à instabilidade do software.
(iv) Gestão da mudança de requisitos através de um planejamento constante: algumas
arquiteturas de desenvolvimento que a equipe escolhe durante os ciclos iniciais podem
tornar-se inadequadas após alteração dos requisitos. O redesenho da arquitetura
contribui significativamente para o custo do projeto.
(v) Prototipagem: muitas empresas reconhecem que os riscos de implantação de
protótipos em modo de produção podem causar problemas com aspectos de qualidade,
tais como escalabilidade, segurança e robustez, ou seja, mais uma vez os requisitos
não funcionais podem ser comprometidos. Além disso, a implantação rápida de
protótipos nos estágios iniciais cria expectativas irreais aos clientes, que rejeitam
ciclos mais longos de desenvolvimento, e que muitas vezes são necessários para
desenvolver software mais robusto.
(vi) Desenvolvimento dirigido a testes (TDD): os desenvolvedores criam testes como parte
de um requisito antes de escrever novo código especificando o comportamento do
90
código. Um grande desafio para a adoção TDD é que requer equipe multifuncional e
os desenvolvedores não estão acostumados a escrever os testes antes da codificação, e
a prática exige muita disciplina, compreensão completa dos requisitos e colaboração
entre cliente e desenvolvedor.
(vii) Reuniões de revisão e testes de aceitação: a validação dos requisitos não aborda
aspectos da verificação formal porque não há modelagem formal de requisitos
detalhados. Quanto aos testes de aceitação para verificação dos requisitos, as empresas
relatam a dificuldade do cliente escrever esses testes, ou seja, os clientes têm
limitações e assim muitas dessas empresas tem um profissional destinado a ajudá-los a
criar os testes.
Um outro trabalho [Gallardo-Valencia; Sim 2009] apresenta um estudo no campo de
validação de requisitos utilizando práticas ágeis, provendo a validação contínua a todos os
stakeholders. A análise do trabalho aborda também o desafio da falta de documentação em
projetos ágeis, uma vez que as atividades estão centradas em torno da unidade básica da
história do usuário, que pode ser em uma notificação por escrito, casos de testes e conversas.
As validações ágeis de requisitos, no estudo de campo realizado, foram feitas antes de
começar as interações, durante as reuniões de planejamento, abrangendo o projeto como um
todo, valorizando as práticas ágeis na validação de requisitos.
A pesquisa desenvolvida por [Hoda; Noble; Marshall 2010] utiliza Grounded Theory
[Strauss; Corbin 1990] e apresenta um estudo sobre equipes de desenvolvimento ágil. Nesse
trabalho é enfatizado como a falta de envolvimento do cliente causa problemas na coleta e
especificação de requisitos contribuindo para a perda de produtividade. São apresentadas as
causas e conseqüências da falta de envolvimento do cliente em projetos ágeis. Foram
entrevistados 30 profissionais de 16 empresas ágeis de desenvolvimento de software da Nova
Zelândia e Índia. A maioria dos participantes afirmou que a falta de envolvimento dos clientes
é vista como "a parte mais difícil do desenvolvimento ágil" e "o maior problema", pois o
cliente comprometido e envolvido é vital para que o método alcance seu objetivo de ser ágil.
Algumas causas levantadas do não envolvimento do cliente são destacadas [Hoda; Noble;
Marshall 2010]: (i) ceticismo dos clientes, (ii) distância, (iii) falta de tempo do cliente, (iv)
clientes de grandes empresas, (v) cliente ineficiente. E como consequências dessa falta de
interesse temos: dificuldade na elicitação e esclarecimento dos requisitos, dificuldades na
priorização dos requisitos e confiança do feedback, perda de produtividade e prejuízo na
empresa.
Em [Savolainen; Kuusela; Vilavaara 2010] são apresentadas as lições aprendidas na
transição de dois projetos ágeis e os desafios enfrentados como: o tamanho variado dos
requisitos de usuário, o papel dos requisitos no sistema e os requisitos de arquitetura.
Também é ressaltado que um dos principais desafios na utilização de métodos ágeis, quando
ocorre um elevado número de equipes ágeis, está em dividir o trabalho entre as equipes,
alcançar as propriedades de todo o software, e garantir as características simultâneas. Os
autores destacam também que, ao ignorar o processo de descrições e especificações dos
requisitos detalhados, preenchendo apenas o backlog (lista simples de todos os tipos de
requisitos), torna-se mais trabalhoso, por exemplo, distinguir o que é requisito de sistema ou
de usuário. Destacam ainda que é importante preservar as práticas chaves dos métodos ágeis,
e da mesma maneira, é preciso investir na educação de engenheiros de requisitos quanto à
importância da elicitação e análise de requisitos em projetos ágeis, removendo práticas
desnecessárias e adicionando novas práticas, que auxiliem no sucesso do projeto.
No trabalho de [Bjarnason; Wnuk; Regnell 2011] um estudo de caso com nove
profissionais de uma grande empresa de desenvolvimento de software é apresentado,
destacando os seguintes desafios da engenharia de requisitos ágil: (i) fluxo contínuo de
91
escopo: o sistema não está completo até o final do ciclo de vida, com o risco de não serem
descobertas questões de nível de sistema até o final do projeto, (ii) equipes multifuncionais de
desenvolvimento, (iii) dificuldade de ter o cliente disponível, (iv) dificuldade em manter o
documento de requisitos atualizado, (v) garantir a competência suficiente do cliente e
desenvolvedores, incluindo inovadoras ideias na interação entre eles, (vi) equilíbrio entre a
agilidade e a estabilidade tanto a nível de projeto como para a equipe de desenvolvimento.
O trabalho de [Espinoza; Garbajosa 2011] aborda a deficiência da rastreabilidade de
requisitos quando utilizados em métodos ágeis, devido à ausência de uma documentação
adequada. De acordo com os autores, a diferença entre o desenvolvimento de software no
modelo ágil e tradicional não se encontra apenas na forma como os processos são realizados,
mas também nos artefatos produzidos como saídas de cada processo. Apesar disso, a
rastreabilidade deve ser considerada em metodologias ágeis como ponto chave para se
desenvolver sistemas de qualidade no intervalo de tempo determinado.
4.3 Questão de Pesquisa 3
Q3 – O que está sendo proposto para tratar os desafios de requisitos em métodos ágeis?
O trabalho de [Mordinyi; Kühn; Schatten 2010] está relacionado com uma proposta
para tratar os desafios relativos às questões de projeto e arquitetura no desenvolvimento ágil.
É proposto um framework de arquitetura chamado Architecture Framework for Agile
Business Requirements (AFA) que distingui os modelos computacional, organizacional, de
coordenação, de distribuição e de comunicação oferecendo flexibilidade sobre as alterações
no projeto e arquitetura de acordo com as mudanças nos requisitos. Ao distinguir os modelos,
os engenheiros têm mais facilidade para identificar apenas os componentes que são afetados
quando surgem novos requisitos. Com isso, os efeitos da implementação desses novos
requisitos em outros modelos podem ser minimizados. Uma vantagem dessa estrutura é que
um engenheiro com conhecimento limitado opera com conceitos simples em cada categoria.
Já no trabalho de [Sen; Hemachandran 2010] são identificadas questões que levam os
stakeholders às mudanças de ideias e alterações na fase de análise de requisitos. Ou seja, o
trabalho apresenta uma proposta para tratar com gestão de mudança de requisitos. Durante a
negociação deve-se chegar a um acordo através de uma linguagem compreendida por todos os
envolvidos. Para resolver os problemas de volatilidade dos requisitos, devido à dependência
da intuição dos stakeholders ou alguns desacordos, foi proposta a técnica Agile Technique for
Agent Based Goal Elicitation (ATABGE), com base nos mecanismos e princípios da
abordagem ágil. A técnica ATABGE assume que o analista trabalha a partir de diagramas
existentes ou documentos disponíveis na forma de objetivos da empresa, missão e visão da
empresa e política corporativa. Centra-se na identificação inicial e abstração dos objetivos
dos stakeholders que podem ser as fontes disponíveis de metas, independentemente do âmbito
de sua base de conhecimento. Essa abordagem também ajuda na elaboração de metas para
representar o sistema desejado. Essa técnica foi aplicada para elicitação de metas da Assam
University Examination Branch envolvendo cinco stakeholders.
O meta-modelo Traceability metamodel for Methodology definition (TmM), proposto
por [Espinoza; Garbajosa 2011] trata a rastreabilidade dos requisitos em métodos ágeis como
tipos de links, papéis e regras de vinculação, que são definidos pela propriedade do usuário,
fornecendo apoio ao processo de desenvolvimento e permitindo a definição de um projeto
específico que admite aos métodos ágeis utilizar a rastreabilidade, sendo possível alcançar um
maior grau de automação em relação ao seu uso.
Q3.1 – Existem adaptações e/ou extensões das metodologias ágeis para tratar
requisitos? Quais?
92
O trabalho apresentado em [Vlaanderen et al. 2009] enfatiza a inserção de um método
de gerenciamento de produtos de software para a aplicação dos princípios do framework
Scrum [Schwaber 1997]. No trabalho é apresentado um refinamento de requisitos ágeis
baseado no Software Product Management (SPM) a fim de melhorar a capacidade de lidar
com grandes escalas de requisitos em um ambiente ágil, dando suporte aos gerentes. Assim
este trabalho está relacionado com o desafio de gerenciamento de requisitos. Podemos
destacar os seguintes pontos desse trabalho:
(i) Como lições aprendidas, destaca-se a importância dos sprints alternados, ou seja, com
o uso de SPM metade do desenvolvimento do sprint é finalizado garantindo que o
Product Backlog estará pronto para ser usado quando as equipes de desenvolvimento
iniciarem um novo sprint.
(ii) Requisitos considerados grandes precisam ser detalhados e estruturados, dividindo-os
por temas, conceitos e tipo. O refinamento desses requisitos na estrutura da
abordagem ágil, efetivou o gerenciamento de grandes conjuntos de requisitos em
granularidade diferente.
(iii) É necessário administrar o Backlog com disciplina, para desempenhar com controle o
SPM e manter o processo de um sprint com qualidade de tempo gasto.
(iv) A comunicação entre a equipe durante o processo de especificação de requisitos é
essencial para promover a reutilização e integração dos requisitos, uma vez que,
discutir os requisitos antes de serem implementados, auxilia na correção de erros e
ambiguidades.
Para tratar com desafios relacionados com problemas com clientes foram usadas as
seguintes estratégias de acordo com [Hoda; Noble; Marshall 2010]:
(i) Prioridade alterada: os requisitos que estavam aguardando maior esclarecimento ou
priorização pelos clientes, na falta dos mesmos, tiveram a prioridade rebaixada ou sua
implementação foi adiada até a resposta do cliente.
(ii) Avaliação de risco: para medir o nível de envolvimento do cliente no projeto, alguns
participantes utilizaram um questionário de avaliação de risco. Tal iniciativa permitiu
à equipe descobrir se o nível indicado de envolvimento do cliente é um risco potencial
para o projeto. Notou-se que a falta de financiamento e indisponibilidade são as
principais causas. A partir da avaliação foi possível negociar melhor com o cliente
para convencê-lo da importância do seu envolvimento no projeto.
(iii) Proprietários de histórias: a prática dos proprietários de histórias foi uma adaptação da
prática Scrum de alocar um proprietário ao produto [Schwaber 1997]. Proprietários de
histórias foram responsáveis por histórias particulares, em vez de todas as histórias no
backlog do produto, e somente as histórias com um proprietário entravam na
priorização. Assim, não era preciso ter somente uma pessoa da organização do cliente
para estar continuamente disponível. Isso permitiu à equipe planejar as histórias de
acordo com a disponibilidade do proprietário.
(iv) Cliente Proxy: algumas equipes destacaram um membro do desenvolvimento para
estar na coordenação junto aos clientes e assegurar deles requisitos e feedback. Essa
prática foi empregada principalmente onde os clientes estavam fisicamente distantes.
(v) Uso de demos: apesar da relutância ou incapacidade para participar de reuniões, quase
todos os clientes foram interessados o suficiente para assistir a demonstrações
(demos), que muitas vezes eram o único meio de colaboração regular que as equipes
ágeis recebiam dos clientes, usando essa oportunidade para discutir características e
receber feedback.
(vi) E-colaboração: colaboração eletrônica foi um popular meio de comunicação regular
com os clientes usando conferência por vídeo/voz, telefone, email e chat. Foi
93
importante porque várias equipes tinham clientes fisicamente distantes e foi
convenientemente barato.
(vii) Ágil disfarçado: para os clientes com ceticismo e oposição ao desenvolvimento ágil,
algumas equipes escolheram seguir práticas ágeis internamente. Fazendo assim um
esforço para evitar consequências da falta de envolvimento do cliente e perda de
negócios.
Q3.2 – Existem adaptações e/ou extensões das metodologias tradicionais para serem
usadas em métodos ágeis? Quais?
De acordo com os filtros utilizados neste trabalho, não foram encontradas adaptações
ou extensões de metodologias tradicionais para tratar desafios dos requisitos nos métodos
ágeis.
5. Discussão
A tabela 2 apresenta o resumo das respostas para as questões de pesquisa 2 e 3 identificando
os principais desafios levantados neste trabalho, o número de vezes em que foram
evidenciados nos artigos analisados e as propostas de tratamento para eles, quando
encontradas no estudo, bem como suas devidas referências. Cada desafio foi associado a uma
fase da engenharia de requisitos de modo a considerar os desafios em cada fase específica.
Tabela 2. Desafios e Propostas para requisitos em métodos ágeis
Ativ
ida
des d
a
ER
Desa
fios
Referên
cia d
o
Desa
fio
Nú
mero
de
vezes q
ue
ap
arece n
os
artig
os
Pro
posta
de
Tra
tam
ento
Referên
cia d
a
Pro
posta
Eli
cita
ção/
Val
idaç
ão
Disponibilidade do Cliente
[Cao; Ramesh 2008]; [Hoda; Noble;
Marshall 2010]; [Bjarnason; Wnuk; Regnell 2011]
03
-
Limitação do cliente on
site
[Cao; Ramesh 2008] ;[Hoda; Noble; Marshall 2010]; [Bjarnason; Wnuk;
Regnell 2011] 03
-
Equipe multifuncional [Cao; Ramesh 2008]; [Savolainen;
Kuusela; Vilavaara 2010]; [Bjarnason;
Wnuk; Regnell 2011]
03 -
Negligência de requisitos não funcionais
[Cao; Ramesh 2008] 01 -
Ger
enci
amen
to
Gestão da mudança dos requisitos e da arquitetura
do software
[Cao; Ramesh 2008]; [Vlaanderen et al. 2009] ; [Mordinyi; Kühn; [Sen;
Hemachandran 2010];
Schatten 2010]; [Savolainen; Kuusela; Vilavaara 2010]; [Bjarnason; Wnuk;
Regnell 2011]
06
SPM
[Vlaanderen et al. 2009]
AFA
[Mordinyi;
Kühn; Schatten
2010]
ATABGE
[Sen; Hemachandr
an 2010]
Documentação
[Cao; Ramesh 2008]; [Gallardo-Valencia; Sim 2009]; [Savolainen;
Kuusela; Vilavaara 2010] ; [Espinoza; Garbajosa 2011] ;[Bjarnason; Wnuk;
Regnell 2011]
05
-
Rastreabilidade [Espinoza; Garbajosa 2011] 01 TmM [Espinoza; Garbajosa
94
2011] V
iabil
idad
e
Consenso na negociação
[Cao; Ramesh 2008]; [Sen; Hemachandran 2010]
02 -
Custo e estimativa [Cao; Ramesh 2008] 01 -
Durante a execução deste estudo notou-se que existe maior quantidade de trabalhos
destacando os benefícios dos métodos ágeis, o que pode ser um indicativo da carência de
trabalhos explorando os desafios existentes para as metodologias ágeis assim como as
soluções para os mesmos. A partir dos resultados apresentados é possível identificar os
principais desafios da engenharia de requisitos ágil e algumas soluções propostas. Vale
destacar que a maioria dos resultados é fruto de dados empíricos o que destaca a relevância do
presente estudo.
Para os nove principais desafios apontados, somente dois têm pelo menos uma
proposta de tratamento, sendo que foram levantadas três propostas diferentes para tratar o
desafio de gerenciamento da mudança dos requisitos e arquitetura do software. Os
questionamentos que surgem então: (i) a gestão da mudança dos requisitos nas metodologias
ágeis tem maior urgência de serem tratadas? Por quê? (ii) Por que os demais desafios
mencionados em mais de um trabalho não tem propostas de tratamento?
Sobre a técnica Agile Technique for Agent Based Goal Elicitation (ATABGE) [Sen;
Hemachandran 2010], que tem base nos mecanismos e princípios da abordagem ágil, os
resultados foram demonstrados com dados obtidos no processo e na aplicação da técnica. No
entanto não foi relatado se a mesma atendeu ou não as necessidades da engenharia de
requisitos efetivamente.
No Software Product Management (SPM) proposto por [Vlaanderen et al. 2009] o
estudo de caso mostrou que, para garantir a SPM ágil e eficaz, vários fatores devem ser
levados em conta tais como: tamanho da tarefa, estrutura e o atraso. A principal contribuição
do trabalho é a descrição de um processo SPM baseado em princípios ágeis, expondo os
diagramas de execução do processo tanto do desenvolvimento de software quanto do SPM,
permitindo a reutilização do método descrito nas empresas, que possuem nível comparável de
desenvolvimento.
6. Conclusões
Este trabalho apresentou uma revisão sistemática com o objetivo de pesquisar quais são os
desafios da engenharia de requisitos nos métodos ágeis, as soluções propostas e as principais
fontes de discussão sobre o assunto. O intervalo delimitado foi de 2008 a 2012, e um dos
critérios de inclusão foram estudos empíricos de modo a obter respostas de trabalhos práticos
aplicados no mercado de trabalho. Nove artigos relevantes foram selecionados como estudo
primário gerando os resultados apresentados no trabalho. No entanto, apesar dos métodos
ágeis estão sendo cada vez mais utilizados e que a engenharia de requisitos é uma das
atividades mais desafiadoras e propensas a erros em um processo de desenvolvimento de
software, foi observado que existem poucas pesquisas nesta área.
Com este estudo tem-se uma visão geral atualizada do assunto requisitos e métodos
ágeis. É possível visualizar suas principais fontes de discussão, observar os principais
desafios, as propostas de tratamento existentes, bem como as lacunas para propostas de
tratamento em alguns desafios, conforme apresentado na tabela 2. Como trabalhos futuros
pretende-se realizar uma busca manual exclusiva na International Conference XP que reúne
95
trabalhos relacionados aos métodos ágeis, mas que, por motivo de falta de espaço, não foi
contemplada neste trabalho. Também pretende-se averiguar se as propostas encontradas estão
atendendo as lacunas da engenharia de requisitos ágil e propor soluções para os desafios.
Referências
Bjarnason, E., Wnuk, K. and Regnell, B. (2011) A Case Study on Benefits and Side-Effects
of Agile Practices in Large-Scale Requirements Engineering. In Proceedings of the 1st
Workshop on Agile Requirements Engineering
Cao, L. and Ramesh, B. (2008) "Agile Requirements Engineering Practices: AnEmpirical
Study." IEEE Software. 60-67.
Dybå, T. and Dingsøyr, T. (2008) “Empirical Studies of Agile Software Development: A
Systematic Review,” IST (50:9-10), pp. 833-859.
Engholm Júnior, H.(2010) Engenharia de Software na Prática, São Paulo: Novatec.
Espinoza, A. and Garbajosa, J. (2011) “Study to Support Agile Methods More Effectively
through Traceability,” Computer Science Innovations in Systems and Software Engi-
neering, Vol. 7, No. 1, 2011, pp. 53-69.
Gallardo-Valencia, R.E. and Sim, S.E. (2009) Continuous and Collaborative Validation: A
Field Study of Requirements Knowledge in Agile. In: proceedings of the Second
International Workshop on Managing Requirements Knowledge. IEEE Computer.
Hoda, R., Noble, J. and Marshall, S. (2010) Agile Undercover: When Customers Don’t
Collaborate In: XP2010, Trondheim.
Hossain, E., Babar, M. A. and Paik, H. (2009) Using Scrum in Global Software Development:
A Systematic Literatur Review. In: Proc. of the 4th International Conference on Global
Software Engineering. IEEE Press, Los Alamitos.
Kitchenham, B. and Charters, S. (2007), Guidelines for performing systematic literature
reviews in software engineering, Technical Report EBSE-2007-01, School of Computer
Science and Mathematics, Keele University.
Mordinyi, R., Kühn, E. and Schatten, A. (2010) Structuring Complexity Issues for Efficient
Realization of Agile Business Requirements in Distributed Environments.
in: Proc. Agile Processes in Software Engineering and Extreme Programming, Springer
Berlin Heidelberg, 48. ISBN: 978-3-642-13054-0; S. 202 - 207.
Paetsch, F., Eberlein, A. and Maurer, F. (2003) Requirements Engineering and Agile
Software Development, In: 12th IEEE International WETICE 03, IEEE CS Press. pp. 308–
313.
Savolainen, J., Kuusela, J., and Vilavaara, A. (2010) Transition to Agile Development -
Rediscovery of Important Requirements Engineering Practices. Paper presented at the 18th
IEEE international requirements engineering conference (RE), 2010. IEEE Computer
Society (PP. 89-294)
Schwaber, K. (1997) Scrum Development Process, in OOPSLA Business Object Design and
Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G.
Hollowell, Eds. London: Springer.
Sen, A.M. and Hemachandran, K. (2010) Elicitation of Goals in Requirements Engineering
using Agile Methods. In: REFS 2010. 19-23 July 2010. Seoul Korea.
Sommerville, I. (2007) Engenharia de Software, 8ª edição, Tradução: Selma Shin Shimizu
Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa; São Paulo: Pearson Addison-
Wesley.
Strauss A. and Corbin J. (1990) Basics of Qualitative Research: Techniques and Procedures
for Developing Grounded Theory, Sage Publications, 1990.
96
Vlaanderen, K., Jansen, S., Brinkkemper, S., Jaspers, E. (2009) The Agile Requirements
Refinery: Applying SCRUM Principles to Software Product Management. In: 3rd
International Workshop on Software Product Management.