View
216
Download
0
Category
Preview:
Citation preview
UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE TECNOLOGIA
GLAUCIA SCHNOELLER DOS SANTOS
UMA ESTRATÉGIA BASEADA EM AQUISIÇÃO DO CONHECIMENTO
PARA O GERENCIAMENTO DE RISCOS NOS REQUISITOS EM UM
DESENVOLVIMENTO XP DISTRIBUÍDO
LIMEIRA - SP
2017
GLAUCIA SCHNOELLER DOS SANTOS
UMA ESTRATÉGIA BASEADA EM AQUISIÇÃO DO CONHECIMENTO
PARA O GERENCIAMENTO DE RISCOS NOS REQUISITOS EM UM
DESENVOLVIMENTO XP DISTRIBUÍDO
Dissertação apresentada à Faculdade de Tecnologia da Universidade Estadual de Campinas como parte dos requisitos exigidos para a obtenção do título de Mestra em Tecnologia, na Área de Sistemas de Informação e Comunicação.
Orientador: Prof. Dr. Ivan Luiz Marques Ricarte
ESTE EXEMPLAR CORRESPONDE À VERSÃO FINAL DA DISSERTAÇÃO DEFENDIDA PELA ALUNA GLAUCIA SCHNOELLER DOS SANTOS E ORIENTADA PELO PROF. DR. IVAN LUIZ MARQUES RICARTE
LIMEIRA - SP
2017
UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE TECNOLOGIA
DISSERTAÇÃO DE MESTRADO EM TECNOLOGIA
ÁREA DE CONCENTRAÇÃO: SISTEMAS DE INFORMAÇÃO E COMUNICAÇÃO
UMA ESTRATÉGIA BASEADA EM AQUISIÇÃO DO CONHECIMENTO
PARA O GERENCIAMENTO DE RISCOS NOS REQUISITOS EM UM
DESENVOLVIMENTO XP DISTRIBUÍDO
Aluna: Glaucia Schnoeller dos Santos
Orientador: Prof. Dr. Ivan Luiz Marques Ricarte
Banca Examinadora:
Prof. Dr. Ivan Luiz Marques Ricarte FT-UNICAMP
Prof. Dr. Paulo Sergio Martins Pedro FT-UNICAMP
Profa. Dra. Renata Pontin de Mattos Fortes ICMC-USP
A Ata da defesa com as respectivas assinaturas dos membros encontra-se no processo de vida acadêmica da aluna.
LIMEIRA - SP
2017
Dedico este trabalho aos meus queridos familiares e amigos.
AGRADECIMENTO
Ao meu orientador, Prof. Ivan Luiz Marques Ricarte, pela confiança
empregada em meu projeto, a oportunidade de pesquisa sob sua valiosa orientação
e a atenção dada no decorrer do desenvolvimento deste estudo.
À minha família, que me apoiou em todos os momentos. Ao meu querido pai,
Diogenes de Souza Santos, pelo incentivo pela educação e os exemplos
apresentados em sua trajetória e sua busca incansável pelo conhecimento. À minha
amada mãe, Roseli Schnoeller Santos, pela demonstração de valores, como a
paciência, o respeito ao próximo e humildade, que foram fundamentais para a minha
formação. Aos meus avós pelo encorajamento, em especial, à memória de minha
estimada avó Maria da Penha Schnoeller.
Aos participantes do estudo de caso desta pesquisa, que mesmo atarefados,
reservaram um tempo e se empenharam para o projeto de desenvolvimento do
sistema. À Samanta Branquinho de Lima, Virginia Trinca da Silva e William Toshio
Nakagawa, grata pela disponibilidade e confiança em meu projeto.
Aos meus queridos amigos Dildre Georgiana Vasques, Franciene Duarte
Gomes de Lima e Juan Fernando Galindo Jaramillo, os quais se tornaram grandes
amigos de vida. Grata pelos conhecimentos compartilhados, a prontidão e o
companheirismo. Aos colegas da FT, pelas parcerias realizadas.
A todos os professores e colaboradores da Faculdade de Tecnologia –
UNICAMP, pelo profissionalismo e dedicação que me auxiliaram na conclusão desta
pesquisa. Aos membros da comissão examinadora, Profa. Renata Pontin de Mattos
Fortes e Prof. Paulo Sergio Martins Pedro, pela participação e contribuições para a
dissertação.
"Não podemos prever o futuro, mas podemos criá-lo."
Peter Drucker
RESUMO
Esta dissertação apresenta uma estratégia baseada em aquisição do
conhecimento processual para gerenciar riscos de ausência de
informação e falta de compreensão dos requisitos de software, com a
finalidade de facilitar a comunicação das estórias do usuário em projetos
da Extreme Programming (XP) no desenvolvimento distribuído de
software (DDS). Para a avaliação dessa estratégia, um estudo de caso foi
conduzido, com a participação de especialistas da área de análise de
sistemas, para o desenvolvimento de um sistema comercial. Como
instrumento para a coleta de dados do estudo foram aplicados
questionários aos participantes, antes e após a intervenção, para
investigar quais as contribuições da estratégia para gerenciar esses
riscos. O resultado dessa aplicação mostra que, por meio de regras
semânticas, o processo gera um conhecimento estruturado e globalizado,
expondo clareza nos requisitos e possibilitando a identificação e extração
de informações ausentes.
Palavras-chave: Aquisição do conhecimento; Metodologias ágeis;
Engenharia de requisitos; Gestão de riscos.
ABSTRACT
This study presents a strategy based on acquisition of processual
knowledge to manage risks of lack of information and understanding of the
software requirements, to facilitate the communication of user stories in
projects of Extreme Programming (XP) in distributed software
development (DSD). For assessing this strategy, a case study was
conducted, which was attended by experts in systems analysis for the
development of a trading system. Before and after questionnaires
answered by the participants were used as a tool to collect data to
investigate which contributions were used in the strategy to manage these
risks. The results of this study show that through semantic rules, the
process generates a structured and globalized knowledge, exposing clarity
in the requirement, besides being able to identify and extract missing
information.
Keywords: Knowledge acquisition; Agile methodologies; Requirements
engineering; Risk management.
LISTA DE FIGURAS
Figura 1 - Cartão de estória. ...................................................................................... 26
Figura 2 - Fluxo do processo do modelo de gerenciamento de riscos. ..................... 27
Figura 3 - Mapeamento dos riscos na equipe XP distribuída. ................................... 33
Figura 4 - Mapeamento dos riscos no planejamento da XP no DDS. ....................... 35
Figura 5 - Mapeamento dos riscos no design da XP no DDS. .................................. 36
Figura 6 - Mapeamento dos riscos na codificação da XP no DDS. ........................... 37
Figura 7 - Mapeamento dos riscos nos testes da XP no DDS................................... 37
Figura 8 - Mapa conceitual causal. ............................................................................ 49
Figura 9 - Cartão de estória. ...................................................................................... 53
Figura 10 - Mural de cartões de estórias. .................................................................. 54
Figura 11 - Novo cartão de estória. ........................................................................... 55
Figura 12 - Mapeamento temático da análise dos resultados. .................................. 56
Figura 13 - Frequência de citações de temas do primeiro questionário. ................... 57
Figura 14 - Frequência de citações de temas do segundo questionário. .................. 61
Figura 15 - Mapas conceituais causais a) Entrega de produto b) Registro de pedido.
.................................................................................................................................. 64
Figura C.1 - Mapa conceitual da primeira estória do estudo de caso. ....................... 84
Figura C.2 - Mapa conceitual da segunda estória do estudo de caso. ...................... 85
Figura C.3 - Mapa conceitual da terceira estória do estudo de caso. ........................ 86
Figura C.4 - Mapa conceitual da quarta estória do estudo de caso. ......................... 88
Figura C.5 - Mapa conceitual da quinta estória do estudo de caso. .......................... 89
Figura C.6 - Mapa conceitual da sexta estória do estudo de caso. ........................... 90
Figura C.7 - Mapa conceitual da sétima estória do estudo de caso. ......................... 91
Figura C.8 - Mapa conceitual da oitava estória do estudo de caso. .......................... 93
Figura C.9 - Mapa conceitual da nona estória do estudo de caso. ............................ 95
Figura C.10 - Mapa conceitual da décima estória do estudo de caso. ...................... 96
Figura C.11 - Mapa conceitual da décima primeira estória do estudo de caso. ........ 97
Figura C.12 – Visão geral dos requisitos. .................................................................. 99
LISTA DE QUADROS
Quadro 1 - Resumo das práticas da metodologia XP. .............................................. 23
Quadro 2 - Comparação dos trabalhos relacionados ................................................ 41
Quadro 3 - Estória do usuário. .................................................................................. 47
Quadro 4 - Preparação do texto. ............................................................................... 47
Quadro 5 - Extração de proposições. ........................................................................ 47
Quadro 6 - Tabela de protopapéis. ............................................................................ 48
Quadro C.1 – Tabela de protopapéis da primeira estória do estudo de caso. .......... 84
Quadro C.2 – Tabela de protopapéis da segunda estória do estudo de caso. .......... 85
Quadro C.3 – Tabela de protopapéis da terceira estória do estudo de caso. ........... 86
Quadro C.4 – Tabela de protopapéis da quarta estória do estudo de caso. ............. 87
Quadro C.5 – Tabela de protopapéis da quinta estória do estudo de caso. .............. 89
Quadro C.6 – Tabela de protopapéis da sexta estória do estudo de caso. ............... 90
Quadro C.7 – Tabela de protopapéis da sétima estória do estudo de caso. ............. 91
Quadro C.8 – Tabela de protopapéis da oitava estória do estudo de caso. .............. 92
Quadro C.9 – Tabela de protopapéis da nona estória do estudo de caso. ............... 94
Quadro C.10 – Tabela de protopapéis da décima estória do estudo de caso. .......... 96
Quadro C.11 – Tabela de protopapéis da décima primeira estória do estudo de caso.
.................................................................................................................................. 97
Quadro C.12 – Tabela de protopapéis da junção dos requisitos. .............................. 98
LISTA DE ABREVIATURAS E SIGLAS
ACM Association for Computing Machinery
AG Agente
CEP Comitê de Ética em Pesquisa
Compl. Complemento
DDS Desenvolvimento Distribuído de Software
IEEE Institute of Electrical and Electronics Engineers
MARDI Managing Agile Requirements in a Distributed
Development Environment
P Proposição
PAC Paciente
PMBOK Project Management Body of Knowledge
PRISMA Preferred Reporting Items for Systematic reviews and
Meta-Analyses
S Sintagma
SNsuj Sintagma Nominal Sujeito
SV Sintagma Verbal
TCLE Termo de Consentimento Livre e Esclarecido
V Verbo
XP Extreme Programming
SUMÁRIO
CAPÍTULO 1 - INTRODUÇÃO .................................................................................. 16
1.1 CONTEXTO E MOTIVAÇÃO ........................................................................ 16
1.2 OBJETIVOS ............................................................................................. 17
1.3 ORGANIZAÇÃO DO TRABALHO ................................................................... 18
CAPÍTULO 2 - REVISÃO DE LITERATURA ............................................................ 20
2.1 EMBASAMENTO TEÓRICO ......................................................................... 20
2.1.1 Extreme Programming................................................................... 20
2.1.2 Jogo do planejamento ................................................................... 24
2.1.3 Estórias do usuário ........................................................................ 25
2.1.4 Desenvolvimento distribuído de software ...................................... 26
2.1.5 Gerenciamento de riscos ............................................................... 27
2.1.6 Engenharia do conhecimento ........................................................ 28
2.2 ESTADO DA ARTE: APLICAÇÃO DA XP NO DDS, RISCOS E ESTRATÉGIAS
NESSE CENÁRIO ............................................................................................ 30
2.2.1 Extreme Programming no desenvolvimento distribuído de software
............................................................................................................... 31
2.2.2 Revisão de riscos no desenvolvimento distribuído e ágil .............. 31
2.3 RISCOS E SOLUÇÕES DE GERENCIAMENTO NA ENGENHARIA DE REQUISITOS 38
2.4 ESTRATÉGIAS PARA RISCOS SEMÂNTICOS ................................................. 39
2.5 CONSIDERAÇÕES FINAIS .......................................................................... 41
CAPÍTULO 3 - METODOLOGIA DO ESTUDO DE CASO ....................................... 42
3.1 DESCRIÇÃO DOS PROCEDIMENTOS METODOLÓGICOS ................................ 42
3.2 COLETA E ANÁLISE DOS DADOS ................................................................ 43
3.3 AMEAÇAS À VALIDADE ............................................................................. 44
3.4 CONSIDERAÇÕES FINAIS .......................................................................... 45
CAPÍTULO 4 - ESTRATÉGIA PARA GERENCIAMENTO DE RISCOS NOS
REQUISITOS DA EQUIPE XP DISTRIBUÍDA .......................................................... 46
4.1 ESTRATÉGIA BASEADA EM AQUISIÇÃO DE CONHECIMENTO ......................... 46
4.2 CONSIDERAÇÕES FINAIS .......................................................................... 50
CAPÍTULO 5 - ESTUDO DE CASO: DESENVOLVIMENTO DISTRIBUÍDO DE UM
SISTEMA COMERCIAL ............................................................................................ 51
5.1 DESCRIÇÃO DO ESTUDO DE CASO ............................................................ 51
5.2 PROCESSO CONVENCIONAL DE ELICITAÇÃO DE REQUISITOS DA XP ............. 52
5.3 PROCESSO DE AQUISIÇÃO DO CONHECIMENTO .......................................... 54
5.4 ANÁLISE DOS RESULTADOS ...................................................................... 56
5.4.1 Processo convencional da XP ....................................................... 57
5.4.2 Processo de aquisição do conhecimento ...................................... 60
5.5 DISCUSSÃO A RESPEITO DOS RESULTADOS ............................................... 63
5.6 CONSIDERAÇÕES FINAIS .......................................................................... 65
CAPÍTULO 6 - CONCLUSÃO ................................................................................... 66
REFERÊNCIAS ......................................................................................................... 69
APÊNDICE A - PRIMEIRO QUESTIONÁRIO INDIVIDUAL PARA INTEGRANTES
DO ESTUDO DE CASO ............................................................................................ 76
APÊNDICE B - SEGUNDO QUESTIONÁRIO INDIVIDUAL PARA INTEGRANTES
DO ESTUDO DE CASO ............................................................................................ 81
APÊNDICE C - REQUISITOS DO ESTUDO DE CASO............................................ 83
C.1 PRIMEIRO REQUISITO DO ESTUDO DE CASO .............................................. 83
C.2 SEGUNDO REQUISITO DO ESTUDO DE CASO ............................................. 85
C.3 TERCEIRO REQUISITO DO ESTUDO DE CASO ............................................. 85
C.4 QUARTO REQUISITO DO ESTUDO DE CASO ............................................... 86
C.5 QUINTO REQUISITO DO ESTUDO DE CASO ................................................ 88
C.6 SEXTO REQUISITO DO ESTUDO DE CASO .................................................. 89
C.7 SÉTIMO REQUISITO DO ESTUDO DE CASO ................................................. 90
C.8 OITAVO REQUISITO DO ESTUDO DE CASO ................................................. 92
C.9 NONO REQUISITO DO ESTUDO DE CASO ................................................... 93
C.10 DÉCIMO REQUISITO DO ESTUDO DE CASO .............................................. 95
C.11 DÉCIMO PRIMEIRO REQUISITO DO ESTUDO DE CASO ............................... 97
C.12 VISÃO GERAL DOS REQUISITOS ............................................................. 98
APÊNDICE D - DIAGRAMA PRISMA .................................................................... 100
APÊNDICE E - TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO .......... 101
ANEXO A - PARECER CONSUBSTANCIADO DO CEP ....................................... 105
16
Capítulo 1
CAPÍTULO 1 - INTRODUÇÃO
Este capítulo introduz a fundamentação para o entendimento da proposta
desta dissertação, mediante a apresentação do contexto, motivação e os objetivos
do estudo. Conduz também a estrutura para a organização do trabalho.
1.1 Contexto e Motivação
Há um crescente interesse na aplicação de métodos ágeis em projetos de
desenvolvimento distribuído de software (DDS) (ALZOUBI; GILL; AL-ANI, 2016), que
estão associados a benefícios como: redução de custo e tempo no desenvolvimento,
facilidade de recrutamento de desenvolvedores qualificados e compartilhamento das
boas práticas (ÅGERFALK et al., 2008). Uma das metodologias aplicadas nesse
cenário é a Extreme Programming (XP), que foca em práticas para o
desenvolvimento de software para acompanhar mudanças frequentes e entregar um
software de qualidade (SADIQ; HASSAN, 2014).
Embora XP preconize a adoção de equipes pequenas, sua aplicação em
cenários co-locados em DDS pode trazer benefícios. Ganesh e Thangasamy (2011)
constataram flexibilidade e economia de custos no projeto, enquanto Hildenbrand et
al. (2008) e Abdullah e Abdelsatir (2013) aplicaram XP em projetos distribuídos de
larga escala. Entretanto, a aplicação de XP nesses cenários expõe o projeto a riscos
na engenharia de requisitos (SHRIVASTAVA; RATHOD, 2014), principalmente na
comunicação das estórias do usuário, como a ausência de informação e a falta de
Capítulo 1 - Introdução 17
compreensão dos requisitos, potencialmente agravados por problemas semânticos
(relacionados ao significado).
Neste trabalho, explora-se a aplicação de um processo para a aquisição do
conhecimento processual baseado em regras semânticas para mitigar riscos na
comunicação dos requisitos. Esse processo fornece uma simplificação para a
extração do conhecimento, além de facilitar a leitura, expor clareza nas informações
e permitir a aplicação em diversas áreas de conhecimento, uma vez que não exige
conhecimento prévio do negócio (VASQUES, 2016). Para avaliar as contribuições
dessa estratégia na mitigação de riscos relacionados à ausência de informação e à
falta de compreensão nos requisitos com a metodologia ágil XP em DDS, um estudo
de caso foi conduzido. A pergunta que direcionou esse estudo foi: Quais as
contribuições do processo de aquisição do conhecimento para o gerenciamento de
riscos de ausência de informação e falta de compreensão nos requisitos para a
equipe XP em DDS?
Esta pesquisa de mestrado gerou uma publicação na Revista Ibérica de
Sistemas e Tecnologias de Informação, intitulada: “Uma estratégia baseada em
aquisição de conhecimento para o gerenciamento de riscos nos requisitos em um
desenvolvimento XP distribuído”. E ainda, dentro desta temática, outro artigo foi
publicado, no VII Congresso Mundial de Estilos de Aprendizagem, com o título “Uso
de Métodos de Representação do Conhecimento e Estilos de Aprendizagem na
Elaboração de Estratégias de Ensino”.
1.2 Objetivos
O objetivo principal do estudo consistiu em avaliar as contribuições de uma
estratégia baseada em aquisição do conhecimento para mitigar riscos de ausência
de informação e falta de compreensão nos requisitos com a metodologia ágil XP em
um desenvolvimento distribuído de software.
No decorrer do desenvolvimento da pesquisa, foram abordados os seguintes
objetivos específicos:
1. Identificar riscos associados a requisitos no desenvolvimento distribuído XP.
Identificar limitações e riscos em XP;
Capítulo 1 - Introdução 18
Identificar riscos no ciclo de desenvolvimento de software com
metodologias ágeis no desenvolvimento distribuído;
Mapear riscos XP a riscos ágeis distribuídos.
2. Identificar estratégias para o gerenciamento de riscos associados a requisitos
no desenvolvimento distribuído XP.
Identificar estratégias para o gerenciamento de riscos nos requisitos com a
metodologia ágil em desenvolvimento distribuído de software;
Identificar estratégias para XP;
Identificar estratégias para o desenvolvimento distribuído XP,
considerando os riscos de ausência de informação e a falta de clareza nos
requisitos.
3. Avaliar a aplicabilidade de estratégias de aquisição do conhecimento para os
riscos de ausência de informação e a falta de clareza com a XP em um
desenvolvimento distribuído de software.
4. Selecionar uma estratégia de aquisição do conhecimento para o
gerenciamento de riscos de ausência de informação e a falta de clareza e
definir como integrá-la ao processo XP.
5. Avaliar a aplicabilidade da estratégia selecionada em um contexto distribuído
XP.
1.3 Organização do Trabalho
Este trabalho está organizado em seis capítulos. Neste primeiro capítulo, para
a compreensão do objetivo deste estudo, aborda-se a contextualização, a motivação
e o problema de pesquisa.
No Capítulo 2, o resultado da revisão da literatura conduzida como parte
deste estudo é apresentado. Para tanto, os fundamentos envolvidos nesta pesquisa
são introduzidos. São descritas as práticas da XP, os conceitos do desenvolvimento
distribuído de software, um modelo geral para o gerenciamento de riscos e uma
introdução em aquisição do conhecimento. O estado da arte da aplicação da XP no
DDS está categorizado em: XP no desenvolvimento distribuído, riscos no ciclo de
desenvolvimento e estratégias de gerenciamento na engenharia de requisitos.
Capítulo 1 - Introdução 19
Em seguida, no Capítulo 3 é descrita a metodologia adotada no estudo. São
declaradas as ferramentas de apoio utilizadas, bem como os métodos aplicados.
No Capítulo 4 é proposta a estratégia para o gerenciamento de riscos nos
requisitos, baseada em aquisição do conhecimento. Esse capítulo ainda traz a
exemplificação da sua aplicação por meio de uma estória de usuário.
O Capítulo 5 descreve o estudo de caso realizado neste trabalho. São
apresentados o cenário do desenvolvimento, os processos implantados e os
resultados interpretados por meio da técnica de análise temática, bem como uma
discussão dos achados.
Por fim, as conclusões e as propostas de trabalhos futuros são relatadas no
Capítulo 6.
20
Capítulo 2
CAPÍTULO 2 - REVISÃO DE LITERATURA
Neste capítulo são apresentados os conceitos básicos para o
desenvolvimento desta pesquisa. Esta seção aborda também uma apresentação do
estado da arte da aplicação da XP no DDS.
2.1 Embasamento Teórico
Os fundamentos desta pesquisa estão estruturados: em práticas da XP, com
foco na prática de jogo do planejamento; em uma exemplificação de estórias do
usuário; em uma breve descrição do modelo do desenvolvimento distribuído de
software, com seus benefícios e desafios; em uma apresentação de um modelo
geral para o gerenciamento de riscos, para a implantação no estudo; e é finalizado
com uma introdução em aquisição do conhecimento, apresentando os conceitos e
técnicas aplicadas.
2.1.1 Extreme Programming
A metodologia ágil consiste em uma abordagem iterativa, apoiando a
especificação, o desenvolvimento e a documentação do projeto. Sua criação foi
motivada na década de 1990, com a necessidade de atender a projetos de
desenvolvimento de software que sofrem com mudanças frequentes dos requisitos
(SOMMERVILLE, 2007).
Capítulo 2 - Revisão de Literatura 21
Os conceitos que estabelecem o desenvolvimento ágil são:
Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano. (“Manifesto Ágil”, 2016)
Com o objetivo de aplicar melhores práticas nos projetos de desenvolvimento
de software, além desses conceitos, doze princípios são valorizados em projetos
ágeis (“Manifesto Ágil”, 2016):
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Contínua atenção à excelência técnica e bom design aumenta a agilidade. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
XP é uma das metodologias que visam suprir as lacunas de projetos de
desenvolvimento de software que enfrentam requisitos incertos que estão em
constante alteração. É indicada para equipes pequenas, estimadas entre dois a dez
integrantes. A XP objetiva reduzir riscos no projeto, atendendo às mudanças
Capítulo 2 - Revisão de Literatura 22
frequentes nos negócios, melhorando a produtividade no decorrer do
desenvolvimento e ampliando a colaboração da equipe (formada em times). Em sua
fundamentação, define a etapa de codificação como uma atividade principal em um
projeto. Considera também na criação do escopo do projeto, tanto os objetivos do
negócio, como também os técnicos. Para guiar o desenvolvimento do software,
quatro valores são aplicados (BECK, 1999a), sendo:
Comunicação: a XP tem como objetivo manter um fluxo de comunicação constante
com a equipe empregando, para isso, algumas práticas que exigem essa
comunicação a curto prazo (como exemplo, a programação em pares, testes
e estimativas). Manter esse fluxo pode reduzir muitos problemas no projeto,
como desentendimentos;
Simplicidade: a equipe da XP deve concentrar-se somente naquilo que é
evidentemente necessário no momento, buscando evitar implementações que
poderiam se tornar desnecessárias no futuro;
Feedback: os resultados são validados a cada tarefa/etapa do projeto. O feedback é
aplicado em diferentes escalas de tempo, podendo ser em minutos/dias,
como as validações dos programadores sobre o estado do sistema, sobre a
qualidade das estórias do usuário e o acompanhamento do progresso das
tarefas que é dado à equipe. O feedback também pode ser em escala de
semana/meses, como o retorno dado ao cliente quando for implementado
uma nova funcionalidade;
Coragem: este valor é uma base para os anteriores. É importante para a aceitação
das mudanças frequentes no projeto, já que pode ocorrer a necessidade da
sua reconstrução.
Baseada nesses valores, a XP implanta algumas práticas e princípios que são
de senso comum em níveis extremos (BECK, 1999a), diferenciando-se das outras
metodologias e ampliando a colaboração entre os envolvidos no projeto (BECK,
1999a). O Quadro 1 apresenta um resumo dessas práticas de desenvolvimento da
XP.
Capítulo 2 - Revisão de Literatura 23
Quadro 1 - Resumo das práticas da metodologia XP.
Extreme Programming
Práticas
Jogo do Planejamento
Os clientes definem o escopo do projeto e estipulam o próximo release,
baseados nas prioridades do negócio e nas estimativas realizadas pelos
programadores.
Releases Curtos Um sistema simples é rapidamente desenvolvido, o qual será implantado
com novas funcionalidades a curto período.
Metáfora O sistema é definido por um conjunto de metáforas compartilhadas com
o cliente e a equipe, visando facilitar a comunicação entre a equipe.
Design Simples
O sistema deve ter uma abordagem simples, buscando eliminar
duplicidade no código e reduzir as classes e métodos ao menor número
possível.
Desenvolvimento
Orientado a Testes
Os testes devem ser definidos frequentemente e devem ser executados
com precisão para a continuação do desenvolvimento. Os clientes
contribuem escrevendo os testes.
Refatoração
Os programadores reestruturam o software, sem comprometer as
funcionalidades, buscando excluir duplicações, simplificar ou adicionar
flexibilidade.
Programação em Par O código é desenvolvido por dois programadores, compartilhando a
mesma máquina.
Código Coletivo Em qualquer momento, os membros da equipe podem ter acesso ao
código e realizar modificações.
Integração Contínua O sistema deve ser integrado com novas versões, diversas vezes ao dia,
assim que uma tarefa for finalizada.
Ritmo Sustentável O período estipulado de trabalho deve ser de 40 horas semanais para
um bom rendimento.
Cliente Presente O cliente deve fazer parte da equipe, contribuindo em período integral e
participando do desenvolvimento.
Código Padronizado Recomenda-se que os programadores desenvolvam o código
uniformizado para facilitar a comunicação por meio deste código.
Stand up meeting Reuniões de curta duração devem ser praticadas todos os dias para o
compartilhamento de informações sobre o projeto.
Capítulo 2 - Revisão de Literatura 24
Cinco princípios básicos são definidos pela XP. Esses princípios podem ser
entendidos como um vínculo de ligação entre os valores e as práticas (CARVALHO;
AZEVEDO, 2013):
(i) Rápido feedback: a equipe de desenvolvimento deve obter o feedback,
interpretá-lo e lançar o novo conhecimento o mais rápido possível;
(ii) Manter a simplicidade: resolução dos problemas atuais. O planejamento de
soluções para o futuro deve ser evitado;
(iii) Mudança incremental: uma abordagem incremental é apresentada, gerando
rapidamente um plano geral, o qual será evoluído com incrementos no
decorrer do projeto;
(iv) Aceitar as mudanças: em primeiro lugar, solucionar os problemas mais
complexos, baseando-se em um design simples;
(v) Qualidade: prover uma boa qualidade nas etapas do desenvolvimento do
software, satisfazendo todos os requisitos especificados pelo especialista
do negócio.
A aplicação da XP em projetos grandes e médios é afetada (QURESHI,
2012). A XP dispensa grande parte do processo tradicional, como a extensa
documentação e definição de requisitos (CAO et al., 2004). O tamanho da equipe é
limitado na XP para os projetos de maiores dimensões, que envolvem problemas
mais complexos (MUNOZ; ALEGRIA, 2012). Para reparar as limitações da dimensão
do projeto, foram desenvolvidas extensões (QURESHI, 2012), modificações
(PUTRA; YULIAWATI; MURSANTO, 2012), adaptações (MUNOZ; ALEGRIA, 2012)
e incremento de novas práticas (ELSHAMY; ELSSAMADISY, 2007) na metodologia
ágil XP.
2.1.2 Jogo do planejamento
A engenharia de requisitos se estrutura em um conjunto de atividades, como
a elicitação, a análise, a negociação e a validação dos requisitos, buscando obter,
validar e manter a documentação de requisitos de software (GANESH;
THANGASAMY, 2011). Na XP, essas etapas são executadas no processo do jogo
do planejamento. Esse processo de planejamento é visto como um jogo para facilitar
Capítulo 2 - Revisão de Literatura 25
o entendimento de sua aplicação (PRIOR; KEENAN, 2005), como apresentado por
Beck (1999a). Nesse cenário, o jogo é composto por (a) objetivos: busca maximizar
os valores dos requisitos do sistema; (b) peças: que representam as estórias do
usuário e; (c) jogadores: desenvolvedor e o cliente do negócio. Esse processo se
divide em fases contínuas, as quais formam um processo cíclico (BECK, 1999a):
Escopo: investiga quais as funções que o software deve ter, define o escopo do
projeto e desenvolve as estórias do usuário;
Estimativa: avaliação do tempo para a implementação de cada estória. Caso não
seja possível estimar, a estória pode ser fragmentada em partes menores;
Priorização: define um conjunto de estórias que devem ser implementadas e
priorizadas;
Mudanças: o plano do projeto é atualizado com novas mudanças de valores pelos
desenvolvedores e o especialista do negócio.
De acordo com Beck (1999b), as estórias são implementadas em releases
que podem durar alguns meses, divididos em iterações, que duram algumas
semanas. As iterações são distribuídas em tarefas que duram alguns dias. As
tarefas são então implementadas e testadas, em etapas que duram minutos ou dias.
2.1.3 Estórias do usuário
Em XP, os requisitos são expressos por meio de estórias informais (BOEHM;
TURNER, 2003), as quais devem capturar os elementos que são necessários para o
negócio. Para empregar qualidade nas estórias, elas devem possuir alguns atributos
como: independência das outras estórias; serem negociáveis entre a equipe; serem
valiosas para os usuários; serem estimadas pelos desenvolvedores e serem
pequenas para que possam ser usadas no planejamento e também testáveis
(COHN, 2004).
De acordo com Cohn (2004), fazer com que as estórias sejam desenvolvidas
pelo próprio usuário é a melhor maneira de garantir a sua eficiência. Para manter um
padrão para a criação das estórias, alguns formatos foram desenvolvidos, como
apresentado por Cohn (2008):
“Como <tipo de usuário>, eu quero <objetivo da estória> para que <razão>”
Capítulo 2 - Revisão de Literatura 26
Exemplo: “Como um vendedor, eu quero verificar se o produto solicitado está
disponível no estoque para que eu possa despachar o pedido”.
Para uma melhor manipulação das estórias, utiliza-se o registro em cartões. A
Figura 1, adaptada do exemplo de Beck (1999a), ilustra o modelo desses cartões.
Figura 1 - Cartão de estória.
Data: Tipo de atividade: Nova: Depurar: Melhoria:
Número da Estória: Prioridade: Usuário: Técnico:
Referência Prévia: Risco: Estimativa:
Descrição da Tarefa:
Notas:
Acompanhamento da Tarefa:
Data Concluído A fazer Comentário
Fonte: Adaptada de Beck (1999a).
2.1.4 Desenvolvimento distribuído de software
O desenvolvimento de software em um ambiente distribuído tem como
princípio os processos colaborativos. As partes interessadas são formadas por uma
empresa (cliente), a qual negocia o desenvolvimento de software total ou em partes
com outra empresa prestadora de serviços (fornecedor) (NIAZI; MAHMOOD, 2013).
A equipe contratada pode ser um grupo interno da mesma organização ou pertencer
a outras organizações (YADAV et al., 2007). Essa equipe pode estar no mesmo local
físico (BLOMKVIST; PERSSON; ÅBERG, 2015) ou distribuída geograficamente, em
diferentes municípios, estados ou até mesmo países (PRECHELT, 2013).
Esse tipo de desenvolvimento introduz benefícios, como o recrutamento de
uma equipe qualificada, a redução do tempo de desenvolvimento, a melhoria na
qualidade do produto e a proximidade com o mercado (ŠMITE; MOE; ÅGERFALK,
2010). Contudo, o desenvolvimento distribuído enfrenta alguns desafios
relacionados com as diferenças nas distâncias geográficas, nos fusos horários e na
cultura (diferentes línguas e contextos organizacionais) (JAIN; SUMAN, 2015).
Capítulo 2 - Revisão de Literatura 27
Há um crescente interesse nas investigações sobre a aplicabilidade das
abordagens ágeis com o desenvolvimento distribuído de software (ŠMITE; MOE;
ÅGERFALK, 2010). No entanto, a aplicação da metodologia ágil no ambiente
distribuído pode evidenciar riscos para a equipe do projeto e no ciclo de
desenvolvimento do software (SHRIVASTAVA; RATHOD, 2014).
2.1.5 Gerenciamento de riscos
O gerenciamento ou gestão de riscos tem como objetivo prever os riscos do
projeto que podem comprometer o cronograma ou afetar a qualidade do software
que está em desenvolvimento, além de elaborar providências para que esses riscos
possam ser evitados (HALL, 1998; OULD, 1999 apud SOMMERVILLE, 2007).
Com um modelo de gerenciamento de riscos, o processo para poder lidar com
os riscos no projeto se torna mais fácil e assegura que esses riscos não afetem o
orçamento ou o cronograma do projeto. Devido às incertezas que projetos de
software apresentam, o controle de riscos no projeto é fundamental. Esses riscos
procedem de requisitos mal definidos, problemas com estimativa de prazo e os
recursos necessários, das dependências de habilidades e das mudanças realizadas
nos requisitos (SOMMERVILLE, 2007).
Embora na literatura sejam apresentados vários modelos para o processo de
gestão dos riscos, existem alguns modelos que são muito influentes como o PMBOK
(Project Management Body of Knowledge) Guide (CUNHA; PEREIRA; PINTO,
2013). Os processos deste modelo (Figura 2) interagem com projetos de diversas
áreas do conhecimento.
Figura 2 - Fluxo do processo do modelo de gerenciamento de riscos.
Fonte: Adaptado de Cunha, Pereira e Pinto (2013).
Capítulo 2 - Revisão de Literatura 28
Esse modelo é composto por seis fases para o gerenciamento de riscos (PMI,
2008):
Planejamento de gestão de riscos: definição do modo de como conduzir, planejar
e realizar as atividades para o gerenciamento de riscos no projeto. Essa etapa
deve ser realizada com eficiência, pois está relacionada a outras atividades
no gerenciamento de riscos;
Identificação dos riscos: determinar os riscos que poderão interferir no projeto e
desenvolver a documentação de suas características. Para a identificação de
riscos, todos os integrantes do projeto devem contribuir;
Avaliação qualitativa dos riscos: priorizar os riscos para as próximas análises ou
ações, por meio da avaliação das suas probabilidades de ocorrência e
também do impacto no projeto;
Avaliação quantitativa dos riscos: analisar de maneira numérica a consequência
dos riscos apresentados no projeto;
Planejamento de resposta: desenvolver planos de ações para aumentar as
oportunidades e minimizar as ameaças nos objetivos do projeto;
Monitoração e controle: implantar os planos de ações aos riscos identificados e
acompanhar e monitorar os riscos. Identificar o surgimento de novos riscos no
projeto e avaliar a eficácia dos processos durante o seu ciclo de vida. Os
processos devem ser monitorados continuamente, identificando mudanças e
riscos desatualizados no projeto.
Os modelos de gerenciamento de riscos convencionais não contemplam
soluções para os riscos em metodologias ágeis com o desenvolvimento distribuído
de software.
2.1.6 Engenharia do conhecimento
A área de engenharia do conhecimento está relacionada com o
desenvolvimento de sistemas de informação, nos quais o conhecimento e o
raciocínio são fundamentais (SCHREIBER, 2000). Os métodos de engenharia do
conhecimento têm sido aplicados não apenas para o desenvolvimento de sistemas
baseados em conhecimento, mas também na gestão do próprio conhecimento.
Capítulo 2 - Revisão de Literatura 29
Outras áreas que se beneficiam da engenharia do conhecimento são a engenharia
de software (e engenharia de requisitos), a modelagem empresarial, a reengenharia
de processos de negócio e a integração de informação (SCHREIBER, 2000). Na
área da engenharia de requisitos, a engenharia do conhecimento tem se destacado
no que concerne à sua elicitação. A aplicação das tecnologias desenvolvidas nessa
área foi analisada como uma ferramenta útil no processo geral de aquisição do
conhecimento (TARAPANOFF, 2006).
Aquisição do conhecimento pode ser definida como um processo para a
extração ou elicitação, estruturação e também organização do conhecimento,
originário dos especialistas humanos (JAWADEKAR, 2011). O processo de
aquisição do conhecimento conta com a colaboração de especialistas do domínio do
conhecimento, que trabalham em conjunto com o engenheiro do conhecimento que,
por sua vez, codifica e explicita as regras utilizadas para a resolução de problemas
(DING, 2001). Assim, os atuantes principais no processo de engenharia do
conhecimento podem ser compreendidos como (TARAPANOFF, 2006):
a) especialista do conhecimento: pessoas possuidoras de alto grau de conhecimento sobre determinado domínio do conhecimento; b) engenheiro do conhecimento: o profissional responsável pela estruturação e construção de um sistema inteligente, extraindo conhecimento de alguma fonte, interpretando e representando o conhecimento adquirido em tipos e estruturas adequadas.
Algumas técnicas foram desenvolvidas para a extração do conhecimento que
não foi explicitado. Entre essas, se destacam as técnicas que se baseiam em mapas
cognitivos (representação gráfica do modelo mental extraído do especialista do
domínio sobre um determinado problema); em mapas conceituais que, à diferença
dos anteriores, estruturam o conhecimento em um modelo lógico; em modelos
causais, que estabelecem relações de causa-efeito para a geração de informações
existentes no negócio; na aquisição automatizada (ferramentas automatizadas para
a execução de etapas para a aquisição e representação do conhecimento), entre
outras (TARAPANOFF, 2006).
O conhecimento é composto por dois componentes: o conhecimento implícito
e o explícito. O conhecimento explícito tem como característica a facilidade para a
transmissão de conhecimento entre indivíduos, podendo ser expresso em diversas
maneiras (dados, palavras, sons, fórmulas, entre outras). Por outro lado, o
Capítulo 2 - Revisão de Literatura 30
conhecimento implícito é difícil de ser compartilhado, pois não é facilmente
explicável. Este tipo de conhecimento é originado pelas ações e experiências do
indivíduo, além de constituírem suas ideias, valores e emoções (TAKEUCHI;
NONAKA, 2009).
2.2 Estado da Arte: Aplicação da XP no DDS, Riscos e Estratégias
nesse Cenário
Foi realizada uma pesquisa bibliográfica segundo alguns princípios da revisão
sistemática da literatura, usando a abordagem PRISMA (Preferred Reporting Items
for Systematic reviews and Meta-Analyses), proporcionando a descrição do fluxo de
informações por meio de cada fase da revisão de literatura (MOHER et al., 2009).
Foram obtidos estudos publicados na literatura especializada relacionados com a
aplicação de metodologias ágeis no contexto do desenvolvimento distribuído de
software. O diagrama do processo aplicado neste trabalho para a seleção de
estudos é apresentado no Apêndice D.
Base de dados
Para encontrar os estudos foram realizadas pesquisas nas bases de dados:
IEEE Xplore, ACM Digital Library e Elsevier ScienceDirect. Essas bases foram
selecionadas por serem consideradas relevantes na área do estudo e forneceram
uma ampla abrangência de resultados.
Critérios para inclusão e exclusão de artigos
O primeiro critério de exclusão de artigos foi o ano de publicação. A busca
pelos artigos iniciou-se em 2015, portanto, os estudos publicados a partir do ano
2010 foram selecionados por serem considerados recentes (ou seja, 5 anos). Em
seguida, foi realizada a filtragem de artigos pela análise dos títulos e, finalmente,
pela análise dos resumos dos artigos, sendo excluídos os artigos que não estavam
relacionados com a metodologia ágil. Além disso, foram incluídos artigos
considerados relevantes para a revisão, mesmo que não estivessem contemplados
nos critérios anteriores.
Capítulo 2 - Revisão de Literatura 31
Seleção final
A análise dos artigos foi realizada com foco na identificação de riscos e
estratégias na implantação de práticas ágeis no desenvolvimento distribuído de
software. Foram aplicadas as etapas: (a) Identificação dos Riscos; (b) Identificação
dos desafios do desenvolvimento distribuído de software; (c) Classificação do
problema; (d) Identificação de estratégia e, finalmente (e) Mapeamento na XP.
Assim, foi possível analisar quais estudos continham informações válidas para a
revisão. Foram selecionados 30 estudos para a investigação.
2.2.1 Extreme Programming no desenvolvimento distribuído de software
Alguns estudos investigaram a XP no cenário distribuído e mostraram
vantagens dessa aplicação. Kircher et al. (2001) adaptaram XP para
desenvolvimento de projetos com a equipe distribuída geograficamente. Paasivaara
e Lassenius (2006) discutiram benefícios e desafios dessa adaptação com base em
casos reais. Hildenbrand et al. (2008) analisaram como XP pode ser empregada em
projetos distribuídos e gerenciados por grandes empresas, identificando práticas que
podem ser utilizadas nesse contexto. Abdullah e Abdelsatir (2013), nesse mesmo
contexto, argumentaram que houve um aumento de interação humana entre a
equipe que contribuiu para geração de novas ideias e uma eficaz implementação do
sistema.
Por outro lado, Shrivastava e Rathod (2014) evidenciam que a aplicação de
XP em DDS pode trazer riscos a equipe e ao ciclo de desenvolvimento da
metodologia ágil.
2.2.2 Revisão de riscos no desenvolvimento distribuído e ágil
Os trabalhos relacionados citados estão associados a riscos no contexto ágil
e distribuído, o que vem ao encontro desse estudo. Esses trabalhos contribuem para
identificar quais os riscos que podem comprometer o desenvolvimento do software.
No estudo realizado no contexto desta dissertação, foram identificados 30
riscos no DDS com a aplicação da metodologia ágil. Os riscos identificados foram
organizados e categorizados. A categorização dos riscos foi atribuída aos problemas
com a comunicação, coordenação, colaboração e presença dos envolvidos no
Capítulo 2 - Revisão de Literatura 32
projeto. Embora nem todos os estudos demonstrem explicitamente as práticas ágeis
da XP, foram incluídas inferências no mapeamento, buscando associar as práticas
com os desafios da implantação do desenvolvimento distribuído de software.
Equipe
Os riscos mais citados nos artigos estão relacionados com a comunicação e a
dificuldade da presença da equipe no projeto. Para Kamaruddin, Arshad e Mohamed
(2012), uma das razões da ausência da equipe em reuniões presenciais é o custo
das viagens. De acordo com Dorairaj, Noble e Malik (2012), este problema é uma
das causas do risco da falta de confiança da equipe. Os mesmos autores
investigaram as causas e as consequências desse risco, demonstrando que a falta
de confiança pode comprometer a participação dos integrantes do projeto, com
consequente deficiência no desempenho da equipe.
A comunicação da equipe está exposta a atrasos (ALZOUBI; GILL; AL-ANI,
2016). Kajko-Mattsson, Azizyan e Magarian (2010) relatam que uma das dificuldades
no projeto é encontrar recursos eficazes para a comunicação entre as equipes e
que, apesar da implantação de ferramentas, a comunicação entre os integrantes da
equipe é reduzida, considerando os valores ágeis. Além disso, Alzoubi, Gill e Al-Ani
(2016), que investigaram os desafios na comunicação, mencionam que a utilização
de ferramentas também pode prolongar o tempo da comunicação, gastando mais
tempo do que o necessário. A fraca comunicação entre as equipes pode interferir na
aplicação de metáforas com a equipe, dificultando o compartilhamento de
conhecimento (RAZZAK; AHMED, 2014), podendo fazer surgir desentendimentos e
dúvidas no andamento do projeto (GANESH; THANGASAMY, 2011).
Não foram observadas alterações na prática de ritmo sustentável que é
aplicada pela equipe. A Figura 3 ilustra o mapeamento dos riscos na equipe XP no
desenvolvimento distribuído de software.
Capítulo 2 - Revisão de Literatura 33
Figura 3 - Mapeamento dos riscos na equipe XP distribuída.
Fonte: Elaborado pela autora (2017).
Planejamento
A fase mais discutida nos artigos foi a análise do projeto. Essa fase aplica um
planejamento flexível (BLOMKVIST; PERSSON; ÅBERG, 2015) na prática do jogo
do planejamento. Essa prática se contrapõe ao desenvolvimento distribuído de
software, pois esse modelo de desenvolvimento implanta um planejamento rígido
nos projetos.
A falta de comunicação com o cliente pode ocasionar riscos como a ausência
na colaboração (KAJKO-MATTSSON; AZIZYAN; MAGARIAN, 2010) e o fraco
vínculo entre a equipe e o cliente (ALZOUBI; GILL; AL-ANI, 2016). Nesse sentido,
doze casos da literatura foram investigados no trabalho de Kajko-Mattsson, Azizyan
e Magarian (2010). Os autores apontam que os motivos da ausência do cliente não
são explícitos. Em consequência disso, a comunicação sobre os requisitos é
reduzida (QAHTANI; WILLS; GRAVELL, 2013), o que traz erros à documentação de
requisito do projeto, pois a documentação gerada da metodologia ágil torna-se
incompleta (GANESH; THANGASAMY, 2011).
A carência de detalhes nos requisitos ainda pode gerar outros riscos tais
como a ausência de informações nos requisitos, como descrito por Akbar, Haris e
Naeem (2008a), e a falta de clareza nos requisitos, citada por Mudumba e One-Ki
Capítulo 2 - Revisão de Literatura 34
(2010). A lacuna na comunicação ainda aponta obstáculos para a priorização
(DANEVA et al., 2013) e para o rastreamento de requisitos (AKBAR; HARIS;
NAEEM, 2008b). Para Qahtani, Wills e Gravell (2013) outra complicação é aquela
associada com a complexidade de coordenação quando há vários clientes incluídos
no projeto. Para reparar a lacuna de comunicação sobre os requisitos mais
informações são registradas na documentação. Essa ação foi identificada por Kajko-
Mattsson, Azizyan e Magarian (2010) como um problema, pois esse aumento na
documentação se opõe aos princípios ágeis.
Problemas com a gestão do projeto também foram identificados. Uma
pesquisa foi realizada por Estler et al. (2012), os quais analisaram dados de 66
projetos de desenvolvimento. Os autores analisaram o impacto da metodologia ágil
no desenvolvimento distribuído de software. Foram relatados alguns desafios na
gestão do projeto, no entanto, não foram classificados como problemas graves. O
mesmo estudo salienta a dificuldade de cumprir o cronograma do projeto,
identificado esse fato como um problema grave. Também Alzoubi, Gill e Al-Ani
(2016) apontam o comprometimento no acompanhamento de processos do projeto.
Apesar dos numerosos trabalhos na literatura que abordam os riscos na área
de engenharia de requisitos no desenvolvimento distribuído de software e na
metodologia ágil, poucos estudos relatam os riscos na engenharia de requisitos com
a metodologia ágil no desenvolvimento distribuído de software (SHRIVASTAVA;
RATHOD, 2014). O mapeamento realizado desta fase do projeto XP é demonstrado
na Figura 4.
Capítulo 2 - Revisão de Literatura 35
Figura 4 - Mapeamento dos riscos no planejamento da XP no DDS.
Fonte: Elaborado pela autora (2017).
Design
Poucas pesquisas investigam a fase do design da XP no DDS. Com a prática
de design simples, a equipe tem o entendimento claro do projeto, podendo contribuir
em todas as suas etapas. O desenvolvimento distribuído não aplica essa
transparência no projeto, razão pela qual essa aplicação é prejudicada.
Gerenciar e manter a uniformização do código remotamente é um desafio.
Como consequência, podem ocorrer conflitos na comunicação por meio do código,
tornando o processo instável e interferindo, por esse motivo, na sua qualidade. A
colaboração da equipe é essencial para desenvolver um código de qualidade e a
falta de colaboração pode comprometer o sistema. De acordo com Bavani (2011), a
pouca atenção ao código causa o risco de instabilidade no design. A Figura 5 ilustra
o mapeamento da fase do design da XP com as práticas implantadas e o risco
associado.
Capítulo 2 - Revisão de Literatura 36
Figura 5 - Mapeamento dos riscos no design da XP no DDS.
Fonte: Elaborado pela autora (2017).
Codificação
Apesar da literatura contribuir com investigações para a aplicação da
programação em pares no DDS, ainda há riscos (ESTÁCIO, 2012). A participação
presencial da equipe é de grande valor para o desenvolvimento do sistema. Por
meio da interação entre os envolvidos, um conjunto de informações é transmitido,
como a expressão facial, a manipulação de objetos, os gestos, entre outros. Essas
informações podem ser muito relevantes para a compreensão do desenvolvimento
do sistema. Quando os desenvolvedores estão distribuídos em diferentes distâncias
geográficas, podem ocorrer riscos devido à pouca interação e, consequentemente,
perda de informações importantes (SCHENK; PRECHELT; SALINGER, 2014).
Existe também a pouca disponibilidade dos desenvolvedores no projeto, relatada na
revisão sistemática de Alzoubi, Gill e Al-ani (2016).
Ferramentas de apoio implantadas no desenvolvimento de projetos
distribuídos pode reduzir a colaboração dos desenvolvedores para os releases
curtos, integração contínua e código coletivo. Esse tópico foi discutido por Kajko-
Mattsson, Azizyan e Magarian (2010), que citam o risco de diferentes infraestruturas
entre as equipes dos projetos. Nesse mesmo contexto, em uma análise do estudo
realizado por Schenk, Prechelt e Salinger (2014) foi observada a incompatibilidade
de configurações de rede como, por exemplo, a diferença de banda. A coordenação
do planejamento de lançamento de iterações também é afetada, como apresentado
por Szőke (2011). Com relação à refatoração do código, a qual é aplicada pelos
desenvolvedores na XP, não foi identificado nenhum risco que a envolvesse essa
prática. Os riscos identificados desta fase estão mapeados na Figura 6.
Capítulo 2 - Revisão de Literatura 37
Figura 6 - Mapeamento dos riscos na codificação da XP no DDS.
Fonte: Elaborado pela autora (2017).
Testes
Devido à dificuldade para as execuções de testes com a equipe localizada no
mesmo ambiente, o desenvolvimento orientado a testes é prejudicado (Figura 7). No
entanto, poucos estudos abordam os riscos nessa fase no desenvolvimento
distribuído de software com a XP. Para Collins et al. (2012) a dificuldade para a
execução dos testes estão relacionadas com a comunicação, a coordenação da
equipe, a disponibilidade de informações, a organização das equipes do projeto e a
ausência de reuniões presenciais da equipe, como também a falta de sincronismo
entre essas equipes (ALZOUBI; GILL; AL-ANI, 2016).
Figura 7 - Mapeamento dos riscos nos testes da XP no DDS.
Fonte: Elaborado pela autora (2017).
Capítulo 2 - Revisão de Literatura 38
2.3 Riscos e Soluções de Gerenciamento na Engenharia de
Requisitos
Para reparar as lacunas no rastreamento e priorização dos requisitos,
algumas ferramentas foram desenvolvidas. Akbar, Haris e Naeem (2008a), citados
na revisão de Shrivastava e Rathod (2014), apresentam um processo para auxiliar
no levantamento e rastreamento de requisitos na abordagem ágil e distribuída. Esse
processo também contribui para a comunicação do cliente com os desenvolvedores.
Já Prior e Keenan (2005), também citados por Shrivastava e Rathod (2014),
produziram um protótipo de uma ferramenta computacional para o gerenciamento de
requisitos no ambiente distribuído com a aplicação da metodologia ágil, denominada
MARDI (Managing Agile Requirements in a Distributed Development Environment),
com características de fácil manuseio e acessibilidade. Esse protótipo fornece um
módulo para o rastreamento de requisitos e tem como um diferencial o
gerenciamento de outros riscos associados à engenharia de requisitos. Na
priorização de requisitos o mesmo protótipo MARDI apresenta uma estratégia para o
gerenciamento desse risco. Para isso, a ferramenta fornece uma área para o usuário
visualizar os requisitos priorizados, registrados por nome e identificador, de modo a
permitir que o cliente e o desenvolvedor possam acompanhar o projeto.
Para ampliar a comunicação da equipe, ferramentas estratégias foram
desenvolvidas. Prior e Keenan (2005) implantaram ferramentas de comunicação,
como o messenger e fóruns no projeto, introduzindo um processo que combina a
prática de jogo do planejamento da metodologia XP. Foram obtidos bons resultados
na aplicação de ferramentas de comunicação integradas no processo, fornecendo
uma perspectiva que atendesse às necessidades do cliente. Assim, os autores se
motivaram a fim de implantar um módulo com uma ferramenta de comunicação
online no protótipo MARDI. No entanto, Ganesh e Thangasamy (2011) alertam que
as ferramentas de comunicação utilizadas no ambiente distribuído podem trazer
diversas desvantagens, tais como conflitos e desentendimentos sobre os requisitos.
Diante dessa questão, o modelo desenvolvido por Qahtani, Wills e Gravell (2013)
contribui para minimizar problemas relacionados com a comunicação sobre os
requisitos por meio de um modelo que implementa algumas atividades ágeis para a
equipe. No entanto, algumas exigências das práticas ágeis são implantadas neste
Capítulo 2 - Revisão de Literatura 39
modelo sem a utilização de ferramentas de comunicação, como as etapas realizadas
no local do cliente. Além de estratégias para gerenciar esse risco na comunicação,
Korkala e Maurer (2014) apresentam um processo para a identificação de
interferências na comunicação e apresentam soluções para repará-las. Esse
trabalho se baseia em um estudo de caso de um projeto de desenvolvimento de
software distribuído em um ambiente global. O processo proposto pode auxiliar as
equipes de desenvolvimento a identificar riscos na comunicação sobre os requisitos.
Uma documentação mínima pode contribuir para gerenciar riscos na
comunicação. O processo apresentado por Akbar, Haris e Naeem (2008a) gera uma
documentação estruturada atualizada, frequentemente, no decorrer das mudanças,
o que não é obtido nas metodologias ágeis. O processo adota a participação do
cliente em várias etapas. Como suporte a vários clientes, o modelo de Qahtani, Wills
e Gravell (2013) pode ser aplicado para este problema, já que tem o propósito de
trabalhar com vários clientes em um projeto, mesmo estando distribuídos
geograficamente.
Para reparar a ausência de informações nos requisitos, no estudo de Akbar,
Haris e Naeem (2008a), os desenvolvedores reuniram em uma lista as questões a
serem discutidas com o cliente para confirmar as informações, porém, a estratégia
não demonstra claramente como gerenciar esse risco, podendo comprometer a
qualidade do software. A identificação desse risco está relacionada com problemas
semânticos, tema associado à proposta deste estudo. No mesmo contexto, Damian
e Zowghi (2002) e Mudumba e One-Ki (2010) que relatam o risco de falta de clareza
nos requisitos, não apresentam estratégias para gerenciar esse risco. Diante disso, a
proposta deste estudo contribui para o seu gerenciamento. Como as estratégias
identificadas não contemplam todos os riscos neste contexto, tal como os problemas
semânticos dos requisitos, uma nova busca foi realizada, visando identificar
estratégias para tais riscos.
2.4 Estratégias para Riscos Semânticos
A semântica, de modo sintético, pode ser entendida como o estudo do
significado. É um ramo que compõe o estudo da linguagem. No estudo da
Capítulo 2 - Revisão de Literatura 40
semântica, o tipo linguagem que sobressai é a falada. Para realizar a comunicação,
é necessário o emissor (1º interlocutor, o que produz a mensagem) e o receptor (2º
interlocutor, o que recebe a mensagem) (MACEDO, 2013).
A comunicação dos requisitos entre o especialista do negócio e
desenvolvedores pode ser prejudicada pelas diferenças culturais entre os
envolvidos, com lacunas semânticas e consequente perda de informação.
Wanderley e Silveira (2012) propõem uma abordagem interativa para modelar os
requisitos em metodologias ágeis com modelos mentais do domínio, que são
transcritos para um modelo conceitual. Essa abordagem gera um vocabulário com
uma linguagem comum para ambas as partes. Já Wanderley et al. (2014) propõem
um framework para modelar estórias do usuário com uma linguagem visual
fundamentada em mapas mentais.
A escrita dos requisitos pode apontar problemas, como dependências ocultas,
inconsistências, ambiguidade e falta de padrão. Lucassen et al. (2015), com base
em um conjunto de estórias reais, apresentam 14 critérios para melhorar a qualidade
nas estórias do usuário. Um protótipo desenvolvido para analisar e expor erros nos
requisitos identificou baixa qualidade e pontos de melhorias, embora sem apontar
métodos para resolver os problemas identificados. Rodríguez e Caro (2012)
propõem um método para modelagem de processos do negócio, com ênfase na
qualidade dos dados, e Vicente (2012) apresenta a utilização da dinâmica de
sistemas para a modelagem semântica do negócio no processo de desenvolvimento
de software.
Algumas técnicas automatizadas de aquisição do conhecimento foram
propostas e utilizadas como, por exemplo, nos estudos de Cunha (1995) e Diederich,
Ruhmann e May (1987). No entanto, a automatização pode não ser suficiente para a
resolução de problemas de procedência semântica (KHOO; NA, 2007; WIELINGA,
2013; VASQUES, 2016).
Perda de informações e falta de compreensão dos requisitos são tipos de
riscos semânticos. O processo Verbka (VASQUES, 2016; VASQUES et al., 2016a,
2016b) visa reduzir problemas inerentes à utilização da linguagem natural, ao
sistematizar, com base em regras baseadas em semântica verbal, a aquisição de
conhecimento processual, representando-o em mapas conceituais causais. Verbka
fragmenta o texto em componentes linguísticos, que são reestruturados em
conceitos e suas relações, produzindo assim informações. Essas informações são
Capítulo 2 - Revisão de Literatura 41
então modeladas semanticamente em tabelas e mapas conceituais causais,
oferecendo uma visão geral do processo causal entre os conceitos. O processo pode
ser aplicado em diferentes idiomas, como mostrado nos estudos de Gomes et al.
(2016) e Vasques (2016).
2.5 Considerações Finais
A revisão da literatura apresenta um embasamento teórico, com ênfase na
aplicação da metodologia XP. Há poucos trabalhos na literatura sobre os riscos no
ciclo de desenvolvimento distribuído ágil XP e, assim, esta seção contribui com uma
investigação dos riscos e estratégias nesse cenário. É evidente que alguns riscos
são previsíveis com a aplicação da XP em um projeto distribuído, por vários fatores,
como relatado nesta seção. O estudo focou em riscos no ciclo do desenvolvimento
distribuído XP e, portanto, riscos associados a outras práticas não foram discutidos.
Observou-se a necessidade de investigações em estratégias para o
gerenciamento de riscos na área de engenharia de requisitos, destacando-se riscos
causados por problemas de ordem semântica. Por essa razão, esta seção contribuiu
com uma busca na literatura com os trabalhos relacionados. O Quadro 2 apresenta
um resumo comparativo desses estudos e o diferencial deste trabalho.
Quadro 2 - Comparação dos trabalhos relacionados.
Recursos propostos
Trabalhos relacionados
Wan
derl
ey e
Silv
eira
(201
2)
Wan
derl
ey e
t al.
(2014)
Lucassen e
t al.
(2015)
Vasqu
es e
t a
l.
(2016)
Rodrí
gu
ez e
Caro
(20
12)
Vic
en
te (
2012)
Modelagem do negócio Redução de riscos na comunicação da equipe ágil
Identificação de problemas semânticos Tratamento semântico do texto Extração de conhecimento tácito Permissão de Inferências
42
Capítulo 3
CAPÍTULO 3 - METODOLOGIA DO ESTUDO DE CASO
Nesta seção serão apresentados os procedimentos metodológicos aplicados
nesta dissertação.
3.1 Descrição dos Procedimentos Metodológicos
Para responder à questão de pesquisa: quais as contribuições do
processo de aquisição do conhecimento para o gerenciamento de riscos de
ausência de informação e falta de compreensão nos requisitos para a equipe
XP em DDS, adotou-se a abordagem qualitativa de estudo de caso. Para alcançar
os objetivos específicos do estudo foi realizada uma pesquisa bibliográfica, a qual é
definida por Severino (2007, p.122) como:
Aquela que se realiza a partir do registro disponível, decorrente de pesquisas anteriores, em documentos impressos, como livros, artigos, teses etc. Utiliza-se de dados ou de categorias teóricas já trabalhados por outros pesquisadores e devidamente registrados. Os textos tornam-se fontes dos temas a serem pesquisados. O pesquisador trabalha a partir das contribuições dos autores dos estudos analíticos constantes dos textos.
Foram levantadas informações sobre as limitações da aplicação da
metodologia XP e os riscos previsíveis no ciclo do desenvolvimento distribuído e ágil,
em destaque na engenharia de requisitos. Foram identificadas soluções para a fase
de engenharia de requisitos no ambiente de desenvolvimento distribuído com a
Capítulo 3 - Metodologia do Estudo de Caso 43
aplicação da metodologia ágil, buscando as estratégias e ferramentas já propostas
na literatura.
Para a avaliação da estratégia proposta foi aplicado um estudo de caso, que é
definido por Severino (2007, p.121) como uma “pesquisa que se concentra no
estudo de um caso particular, considerado representativo de um conjunto de casos
análogos, por ele significativamente representativo”. O estudo de caso contribuiu
para a avaliação de uma estratégia baseada em aquisição do conhecimento
apresentado para o gerenciamento de riscos de ausência de informação e falta de
clareza nos requisitos do desenvolvimento distribuído XP. Esse estudo foi aprovado
no Comitê de Ética em Pesquisa (CEP) da Universidade Estadual de Campinas1
(Anexo A). A população do estudo é composta por desenvolvedores de software,
com participantes selecionados por amostragem de conveniência por indicação de
profissionais da área de desenvolvimento de software. O critério para a inclusão na
pesquisa foi a experiência em outros projetos de desenvolvimento de software,
preferencialmente no tipo de projeto de software que se buscava para este estudo
(sistema comercial), por seu foco na interação com o cliente.
3.2 Coleta e Análise dos Dados
Para a coleta de dados, primeiramente foi apresentado o documento do
Termo de Consentimento Livre e Esclarecido (TCLE) aos participantes (Apêndice E).
Foram desenvolvidos dois roteiros de entrevistas, disponibilizados online por meio
da ferramenta de formulários Google. A primeira entrevista foi realizada antes da
aplicação do Verbka e teve como finalidade investigar questões relacionadas à
compreensão de requisitos, requisitos vagos e ausência de informações (Apêndice
A). A segunda entrevista, após a aplicação do Verbka, levantou as contribuições da
estratégia para o gerenciamento de riscos nos requisitos (Apêndice B).
As respostas às entrevistas foram analisadas pelo método da análise de
conteúdo (SILVA; FOSSÁ, 2015), associando rótulos (categorias ou temas) a
fragmentos das respostas para auxiliar na compreensão dos dados, de modo a
1 Número do CAAE: 55040316.9.0000.5404
Capítulo 3 - Metodologia do Estudo de Caso 44
identificar, analisar e expor os dados por meio de padrões, organizados e descritos
em detalhes (BRAUN; CLARKE, 2006). As etapas realizadas para o tratamento dos
dados foram:
Leitura geral dos questionários coletados;
Codificação para a construção de temas para a análise, utilizando o recorte
de unidades de registro (em frases);
Estabelecimento de categorias temáticas das unidades de registro;
Revisão de temas;
Definição de temas;
Agrupamento temático das unidades de registro;
E produção do relatório qualitativo.
Algumas ferramentas computacionais foram utilizadas para apoiar essa
análise. Durante a etapa de codificação, QDA Miner2 foi utilizada para a seleção de
unidades de registro, apoiando a análise e elaboração dos relatórios. Após essa
etapa, a ferramenta XMind3 foi aplicada para organizar o mapeamento dos temas e
subtemas. Como resultado dessa análise, foi extraída uma ampla descrição de
temas específicos dentro dos dados coletados.
3.3 Ameaças à Validade
Com o intuito de garantir a confiabilidade dos resultados obtidos neste estudo,
os fatores previsíveis de ameaças internas e externas foram analisados. A validade
interna investiga as relações causais dos componentes de estudo (BLEIJENBERGH;
KORZILIUS; VERSCHUREN, 2011). Para reduzir o risco de influenciar os
participantes, foram aplicadas questões abertas nos questionários. A validade
externa refere-se à capacidade de generalizar os resultados da pesquisa para outros
casos. Na metodologia de estudo de caso, o propósito é prover a generalização
2 http://provalisresearch.com/products/qualitative-data-analysis-software/freeware/
3 http://www.xmind.net/
Capítulo 3 - Metodologia do Estudo de Caso 45
analítica para resultados que são relevantes a casos com caraterísticas similares
(RUNESON; HÖST, 2009). Para Razzak e Ahmed (2014), a validade externa é
recomendável para as investigações de pesquisas quantitativas.
3.4 Considerações Finais
Os dados do estudo de caso foram apresentados nesta seção. Foram
descritos: a população do estudo, o tipo do estudo, o tipo de projeto, a questão de
pesquisa conduzida, a coleta dos dados, as técnicas e recursos utilizados, a
amostragem do estudo de caso e o tratamento dos dados. O próximo capítulo
apresenta a proposta deste trabalho.
46
Capítulo 4
CAPÍTULO 4 - ESTRATÉGIA PARA GERENCIAMENTO DE
RISCOS NOS REQUISITOS DA EQUIPE XP
DISTRIBUÍDA
A estratégia proposta nesta dissertação é apresentada neste capítulo, de
maneira conjunta com sua exemplificação em uma estória de usuário.
4.1 Estratégia Baseada em Aquisição de Conhecimento
Esta proposta parte da premissa de que a extração do conhecimento implícito
de requisitos pode contribuir para gerenciar os riscos de ausência de informação e
falta de clareza na especificação desses requisitos. Especificamente, propõe-se a
aplicar o processo Verbka para gerenciar riscos na comunicação das estórias do
usuário de equipes XP em DDS, com: (a) tratamento do conteúdo semântico das
estórias do usuário; (b) extração do conhecimento implícito; (c) estruturação do
conhecimento extraído e (d) modelagem semântica das estórias do usuário. A
aplicação do processo Verbka, ao modelar semanticamente o conhecimento nas
estórias do usuário, pode reduzir vieses na interpretação dos requisitos e, assim,
mitigar riscos semânticos, reduzindo o impacto da distância geográfica entre os
membros da equipe para a análise dos requisitos.
Considere como exemplo um requisito escrito por um especialista do negócio
(Quadro 3):
Capítulo 4 - Estratégia para Gerenciamento de Riscos nos Requisitos da Equipe XP Distribuída 47
Quadro 3 - Estória do usuário.
Como administrador cadastro, altero e excluo funcionário com número de matrícula, nome e
departamento, para controle de acesso.
O primeiro passo é preparar o texto, por meio de seu refinamento, ou seja,
transcrição para voz ativa de todos os verbos escritos em voz passiva e transcrição
de todos os verbos no tempo presente. Sujeitos indeterminados devem ser
explicitados, termos acessórios são eliminados e orações coordenadas são
desmembradas. Desse passo, resultam oito orações (Quadro 4).
Quadro 4 - Preparação do texto.
Administrador cadastra funcionário. Administrador consulta funcionário. Administrador altera
funcionário. Administrador exclui funcionário. Funcionário tem número de matrícula. Funcionário
tem nome. Funcionário tem departamento. Administrador controla acesso de funcionário.
A seleção dos verbos contribui para a extração dos sintagmas. As sentenças
foram fragmentadas em dois blocos, sintagma nominal sujeito (SNSuj) – composto
por substantivo e eventuais adjetivos – e sintagma verbal (SV) – composto por verbo
e complementos. Para identificar esses elementos, duas questões são direcionadas
ao verbo: Quem e O quê. Por exemplo, para a primeira oração, Administrador
cadastra funcionário, o verbo é Cadastrar. Para a pergunta quem cadastra?, a
resposta é administrador; para a pergunta cadastra o quê?, a resposta é funcionário.
Essa análise deve ser aplicada a todas as orações. No exemplo, o conhecimento
codificado em proposições é sintetizado no Quadro 5.
Quadro 5 - Extração de proposições.
P SNSuj SV
V Compl.
1 Administrador Cadastra Funcionário
2 Administrador Consulta Funcionário
3 Administrador Altera Funcionário
4 Administrador Exclui Funcionário
5 Funcionário Tem Número de matrícula
6 Funcionário Tem Nome
7 Funcionário Tem Departamento
8 Administrador Controla Acesso de funcionário
Capítulo 4 - Estratégia para Gerenciamento de Riscos nos Requisitos da Equipe XP Distribuída 48
A seguir, o sintagma verbal é complementado com base nas questões
aplicadas ao verbo: O quê, Para quem, Onde, Quando e Quanto. Assim, a cada
conceito é atribuída uma função semântica, com valores relativos às respostas
obtidas a essas questões. Questões sem respostas têm os campos em branco. A
aplicação dessa etapa permite identificar informações ausentes e possibilita a
inserção de inferências para relações implícitas. No exemplo, o administrador não
tinha sua função definida, o que levantou dúvidas como: Administrador do negócio?
Administrador de informação? Por meio das respostas, foi possível identificar e
explicitar essa informação, conforme apresentado no Quadro 6.
As questões Como e Por que são respondidas após a modelagem das
proposições, pois fornecem uma visão completa do requisito. Após esses passos, se
houver conceitos sinônimos na tabela, o termo mais representativo é selecionado.
Quadro 6 - Tabela de protopapéis.
P Proto-AG Proto-PAC
SV SNSuj
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem Onde Quando Quanto
1 Administrador do sistema
Cadastra Funcionário - No sistema - -
2 Administrador do sistema
Consulta Funcionário - No sistema - -
3 Administrador do sistema
Altera Funcionário - No sistema - -
4 Administrador do sistema
Exclui Funcionário - No sistema - -
5 Funcionário Tem Atributo número de matrícula
- No sistema - -
6 Funcionário Tem Atributo nome - No sistema - -
7 Funcionário Tem Atributo departamento
- No sistema - -
8 Funcionário Tem Atributo senha - No sistema - -
9 Funcionário Acessa Sistema - - - -
10 Administrador do sistema
Controla Acesso de funcionário
- No sistema - -
Com base nesse quadro, proposições podem ser modeladas com seus
conceitos e relações. Para isso, cada coluna é percorrida e os conceitos são
Capítulo 4 - Estratégia para Gerenciamento de Riscos nos Requisitos da Equipe XP Distribuída 49
atribuídos a caixas, relacionadas por setas correspondentes a verbos e extensões
verbais. As setas seguem a ordem das colunas, de maneira que complementos são
ligados ao conceito anterior. Esse processo é realizado para cada linha da tabela de
protopapéis. As inferências (de relações não explícitas) são destacadas com uma
seta tracejada.
O fluxo de energia entre os conceitos é diferenciado pelo tipo de associação,
o que permite uma visão complexa do requisito. Os tipos de associação são:
Associações por verbos de ação-processo (transitivos diretos e indiretos), que
representam relacionamentos em que um conceito afeta outro conceito e altera o
seu estado atual (como exemplo, “Administrador controla acesso de funcionário”);
Associações por verbos de ação (reflexivos, intransitivos e também alguns verbos
transitivos de percepção e psicológicos), que indicam conceitos que afetam a si
próprios (“Comprador recebe pedido”); e Associações por verbos de ligação que são
conceitos estáticos, nos quais não ocorre um fluxo de energia que perpassa entre os
conceitos relacionados (“Funcionário tem atributo nome”).
A Figura 8 mostra a modelagem semântica resultante da aplicação dessa
etapa ao exemplo, que foi validado por um especialista do negócio e usuários.
Figura 8 - Mapa conceitual causal.
Fonte: Elaborado pela autora (2017).
Capítulo 4 - Estratégia para Gerenciamento de Riscos nos Requisitos da Equipe XP Distribuída 50
4.2 Considerações Finais
Uma estratégia baseada em aquisição de conhecimento é proposta neste
capítulo, com o objetivo de gerenciar riscos na engenharia de requisitos decorrentes
de problemas semânticos na comunicação entre a equipe. Para exemplificar sua
aplicação, o processo Verbka foi utilizado em uma estória de usuário real. O
resultado dessa aplicação foi a modelagem semântica e a estruturação do
conhecimento extraído dos requisitos.
51
Capítulo 5
CAPÍTULO 5 - ESTUDO DE CASO: DESENVOLVIMENTO
DISTRIBUÍDO DE UM SISTEMA COMERCIAL
O estudo de caso realizado é descrito nesta seção com uma breve descrição
do cenário de desenvolvimento, além dos processos implantados no
desenvolvimento do sistema e a análise dos resultados obtidos na coleta dos dados.
Por fim, foi realizada uma discussão desses resultados.
5.1 Descrição do Estudo de Caso
O objetivo da equipe foi desenvolver um sistema comercial para gestão de
estoque de produtos, para substituir um sistema que não acompanhou a evolução
tecnológica do estoque, tornando-se obsoleto e não atendendo aos negócios da
empresa. O estudo de caso teve a duração de um mês. A equipe XP, distribuída em
diferentes localizações, foi composta por três especialistas em análise e
desenvolvimento de sistemas com experiência em projetos de desenvolvimento de
sistemas comerciais e com conhecimento da metodologia ágil XP. O tamanho de
amostra foi considerado adequado para esse tipo de estudo.
Para evidenciar as práticas da XP em DDS, todos os processos do
desenvolvimento foram realizados remotamente. Um curto treinamento sobre
ferramentas de apoio ao DDS foi oferecido aos participantes antes do início do
desenvolvimento. Entre essas ferramentas, Skype teve grande aceitação para a
programação em pares, pelo fácil acesso para os envolvidos e recursos como o
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 52
compartilhamento de tela entre os desenvolvedores e mensagens (Chats). Para o
gerenciamento do projeto foi utilizado o Mingle4, uma ferramenta virtual (gratuita
para até 5 integrantes) que fornece flexibilidade para adoção em projetos ágeis. Ela
fornece um conjunto de funções como: a criação e o controle de cartões de estórias,
acompanhamento de releases, tarefas e defeitos, além de notificações por meio de
alertas e priorização de requisitos. Possibilita, na construção e organização dos
cartões, a inserção de anexos, comentários e gráficos. A preferência de seu uso se
deu pelo fato de facilitar a colaboração de toda a equipe.
O sistema foi desenvolvido na linguagem de programação C#, de
conhecimento comum entre os desenvolvedores do projeto. A plataforma de
desenvolvimento utilizada foi o Visual Studio Community 2015, com o apoio dos
serviços da Visual Studio Team Services5. Essa ferramenta, gratuita até cinco
usuários, é baseada em nuvem e fornece um conjunto de recursos para equipes
ágeis. Assim, o código do sistema foi armazenado e compartilhado em repositório
privado com todos os envolvidos do projeto, com controle de versão distribuído,
gerenciamento de mudanças, plano de testes, integração contínua e chat.
Para a geração dos mapas conceituais, foi utilizada a ferramenta gratuita
CmapTool6. A aplicação das tabelas de protopapéis seguiu os princípios da
ferramenta 5W2H, com um checklist de cinco questões iniciadas (em inglês) com W
(what, why, when, where e who) e duas com H (how e how much).
5.2 Processo Convencional de Elicitação de Requisitos da XP
Nesta etapa do estudo, o processo convencional da XP foi aplicado para a
elicitação, análise e validação dos requisitos. Todas as definições e negociações das
estórias do usuário foram acompanhadas remotamente. Na primeira reunião com o
especialista do negócio, realizada por Skype, foram compartilhadas as
funcionalidades das ferramentas utilizadas no projeto. O escopo do projeto e
planejamento do lançamento da primeira iteração das estórias foram discutidos em
outras reuniões, com as estórias do usuário escritas pelo especialista do negócio em
4 https://www.thoughtworks.com/mingle/
5 https://www.visualstudio.com/pt-br/products/visual-studio-team-services-vs.aspx
6 http://cmap.ihmc.us/cmaptools/
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 53
cartões criados diretamente no software Mingle (Figura 9). Por problemas de
incompatibilidade de horários dos membros da equipe, esses cartões foram
discutidos por meio de troca de mensagens e muitas dúvidas surgiram durante o
processo de análise dos requisitos associados.
Foram realizadas quatro iterações para a priorização dos requisitos, pois
algumas estórias dependiam de funcionalidades ainda não implementadas. A
priorização foi atribuída no Mingle, com o recurso do mural de cartões, categorizados
em novos, em andamento, testes e finalizados. Pela mesma ferramenta, os
envolvidos no projeto puderam inserir comentários e realizar alterações, quando
necessário.
Figura 9 - Cartão de estória.
Fonte: Print screen da aplicação no Mingle.
Foram realizadas quatro iterações, no total de onze cartões de estória do
usuário (Figura 10).
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 54
Figura 10 - Mural de cartões de estórias.
Fonte: Print screen da aplicação no Mingle.
5.3 Processo de Aquisição do Conhecimento
Nesta etapa do desenvolvimento, além dos recursos e práticas utilizadas na
etapa anterior, foi implantado o processo Verbka nas estórias do usuário para apoiar
o gerenciamento dos riscos de falta de informação e compreensão dos requisitos.
Para isso, a autora desta dissertação gerenciou o projeto de desenvolvimento e
aplicou as regras semânticas nas estórias do usuário.
A tabela de protopapéis e o mapa conceitual causal, criados no processo,
puderam ser incluídos nos cartões de estórias no Mingle. Isso permitiu que a equipe
tivesse acesso ao conhecimento extraído, modelado e estruturado com a aplicação
do processo pelo especialista do negócio no mesmo cartão de estória. Esse modelo
de cartão é ilustrado na Figura 11, que apresenta o requisito de cadastro, alteração
e exclusão de funcionário, juntamente com a tabela e o mapa conceitual causal com
a junção de todos os objetos do sistema, fornecendo uma visão completa de suas
funcionalidades e permitindo o rastreamento e a identificação de dependências. A
extração de todas as estórias do usuário e a visão geral dos requisitos são
apresentadas no Apêndice C.
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 55
Figura 11 - Novo cartão de estória.
Fonte: Print screen da aplicação no Mingle.
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 56
5.4 Análise dos Resultados
Esta seção apresenta a análise temática dos resultados obtidos por meio dos
questionários, os quais foram aplicados durante o desenvolvimento do sistema.
Visando facilitar a análise das informações, os dados foram categorizados e
mapeados (Figura 12) tematicamente. A descrição e a interpretação desses temas
da primeira e segunda etapa do projeto serão abordadas nas próximas subseções.
Figura 12 - Mapeamento temático da análise dos resultados.
Fonte: Elaborado pela autora (2017).
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 57
5.4.1 Processo convencional da XP
Esta subseção tem por objetivo apresentar a posição dos participantes do
estudo de caso durante a primeira etapa do desenvolvimento do sistema, sobre a
qual foi aplicada o processo convencional da XP para a fase de elicitação, análise e
validação dos requisitos. Os dados foram categorizados em três temas: os
processos do negócio, a compreensão dos requisitos e o detalhamento dos
requisitos. O gráfico ilustrado na Figura 13 apresenta a média da frequência de
ocorrência desses temas no primeiro questionário individual.
Figura 13 - Frequência de citações de temas do primeiro questionário.
Fonte: Elaborado pela autora (2017).
Processos do negócio
A aplicação da linguagem natural na escrita das estórias do usuário introduziu
um formato informal e técnico dos processos exercidos no negócio. Apresentou
ainda uma falta de uniformização de conceitos utilizados nos requisitos. Isso
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 58
prejudicou a compreensão dos desenvolvedores em relação aos processos do
negócio, como mencionado em um dos questionários:
Na análise de requisitos houve uma dificuldade na compreensão das sentenças, pois as mesmas foram escritas de uma forma informal e o modo como elas foram expostas parecia que emissor e receptor conheciam todos os processos e particularidades da organização. Além disso, empregaram-se diferentes termos para designar a mesma coisa. (Apêndice A; Questão 1; Linha 1)
Outro risco proveniente desse problema foi a ambiguidade nos requisitos.
Algumas dúvidas levantadas pelos participantes apresentaram essa ocorrência: “No
lugar do termo ‘justamente’ não seria a palavra ‘juntamente’? Isso provoca diferentes
interpretações” (Apêndice A; Questão 3; Linha 10), “A data de entrega
corresponderia à data da realização do pedido? Há uma dupla interpretação”
(Apêndice A; Questão 3; Linha 34).
A ausência de informações sobre o negócio foi um dos principais riscos
identificados, como citado por um dos desenvolvedores: “A principal dificuldade
encontrada consistiu na falta de informações referentes à organização e seu
processo de trabalho” (Apêndice A; Questão 4; Linha 1). O tempo gasto e o esforço
dos desenvolvedores para o entendimento das estórias do usuário e dos processos
do negócio foram considerados maiores, pela necessidade de repetir diversas vezes
a leitura desses requisitos. Essa deficiência foi mencionada em um dos
questionários: “[...] foi necessário ler todas as histórias mais de uma vez para
entender a base dos processos realizados pelo cliente” (Apêndice A; Questão 1;
Linha 9). À vista disso, ficou evidente a necessidade da aplicação de estratégias
para a modelagem desses processos de negócio, com a finalidade de reduzir o
tempo gasto para a compreensão dos requisitos. Essa observação foi sugerida por
um dos participantes: “Se as histórias fossem descritas como a explicar ou
exemplificar os processos a um leigo, a análise dos requisitos poderia ser menos
demorada e o escopo poderia ser laborado e aprovado mais rapidamente” (Apêndice
A; Questão 4; Linha 4).
Com esse cenário, o projeto requeria uma comunicação frequente e eficiente
para a validação dos requisitos. No entanto, os envolvidos enfrentaram mais
desafios, pelo motivo da equipe e o especialista do negócio estarem distribuídos
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 59
geograficamente. Por essa razão, deparou-se com a falta de conhecimento dos
processos do negócio entre os desenvolvedores.
Compreensão dos requisitos
Uma das principais dificuldades dos desenvolvedores nas etapas de análise e
implantação das estórias do usuário foi a falta de compreensão dos requisitos. De
acordo com os participantes, as estórias escritas pelo usuário apresentaram
deficiências, como: “Todos os requisitos apresentaram alguma imprecisão”
(Apêndice A; Questão 2; Linha 1). Apesar das sugestões apresentadas à equipe
para a aplicação de um padrão para a criação dos cartões, sem o acompanhamento
presencial para a elaboração desses cartões, nem todos os critérios sugeridos foram
adotados. Assim, os participantes se depararam com inconsistências no padrão das
estórias do usuário, como a atribuição de duas estórias no mesmo cartão: “Colocou-
se dois requisitos diferentes em um só” (Apêndice A; Questão 3; Linha 29).
Foram identificados requisitos vagos, provenientes da falta de clareza, que
limitaram a implantação das estórias: “[...] não há informações suficientes para que
seja definido como requisito” (Apêndice A; Questão 1; Linha 18). Nesse contexto,
muitos questionamentos em relação à compreensão dos atores do sistema foram
manifestados: “Administrador do quê? [...]” (Apêndice A; Questão 3; Linha 2),
“Existem outros tipos de administradores?” (Apêndice A; Questão 3; Linha 3), “[...]
está faltando o tipo de usuário (para definir quais interfaces o usuário poderá
acessar) [...]” (Apêndice A; Questão 3; Linha 84).
Houve questões sobre responsabilidades de cada ator: “Quais são os tipos de
pedido que são de responsabilidade do almoxarife? E do departamento de
compras?” (Apêndice A; Questão 3; Linha 43), “Somente o almoxarife cadastra um
novo produto?” (Apêndice A; Questão 3; Linha 66), “Somente o departamento de
almoxarife pode cadastrar fornecedor?” (Apêndice A; Questão 3; Linha 58), “A que
tipo de informações o departamento de almoxarife deverá ter acesso? [...]”
(Apêndice A; Questão 3; Linha 11). Dificuldades foram associadas ao tipo de
relacionamento entre atores: “[...] produto pode ter mais de um fornecedor
vinculado? [...]” (Apêndice A; Questão 3; Linha 79).
Apesar da necessidade da independência, as estórias do usuário estavam
relacionadas e alguns desafios surgiram para explicitar essas dependências: “A
execução desta atividade depende de algum parâmetro, como por exemplo, a
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 60
solicitação de um novo pedido de compra?” (Apêndice A; Questão 3; Linha 54), “É
necessário algum aviso prévio, antes de receber definitivamente algum pedido?”
(Apêndice A; Questão 3; Linha 55). Nesse sentido, outras dificuldades foram
encontradas, como a ausência de relações do comportamento do requisito: “Os
requisitos estão sem comportamento. Ex. (entrada, saída e estado)” (Apêndice A;
Questão 1; Linha 13), “[...] não é possível definir qual é o comportamento do
requisito [...]” (Apêndice A; Questão 2; Linha 9).
A falta de compreensão dos requisitos e os seus relacionamentos implicam
em riscos de permissões de acesso para o controle de segurança do sistema. Foram
também encontradas dificuldades para rastreamento desses requisitos.
Detalhamento dos requisitos
A falta de informação nos requisitos, tal como funcionalidades que não foram
identificadas na implantação da história, teve grande impacto no desenvolvimento e
afetou a usabilidade do sistema. Por exemplo, na geração de relatórios pelo sistema:
“A geração desse relatório deve ser exibido em tela e/ou gerado em .pdf?” (Apêndice
A; Questão 3; Linha 72), “O sistema deve possibilitar a opção de ‘imprimir’ o
relatório?” (Apêndice A; Questão 3; Linha 73).
Algumas ausências de atributos do sistema foram identificadas. No controle
de acesso dos funcionários não foi esclarecida a atribuição de senhas para os
funcionários. Outra situação foi o cadastramento de novas peças, que não previa a
quantidade dos produtos: “[...] Requisito de cadastro de novas peças: deve possuir
um campo de quantidade atual? [...]” (Apêndice A; Questão 3; Linha 78). Por esse
motivo, algumas funcionalidades que requeriam essas informações foram afetadas,
demandando tempo para reparos.
5.4.2 Processo de aquisição do conhecimento
Com relação à segunda etapa do desenvolvimento do sistema, a qual foi
aplicada o processo de aquisição do conhecimento, buscou-se identificar como este
processo contribui para gerenciar os riscos expostos na primeira etapa do
desenvolvimento. A categorização dos dados recolhidos nesta etapa seguiu o
modelo dos temas anteriores, sendo: os processos do negócio, a compreensão dos
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 61
requisitos e o detalhamento dos requisitos. A frequência de ocorrência de cada tema
relatado no segundo questionário está ilustrada na Figura 14.
Figura 14 - Frequência de citações de temas do segundo questionário.
Fonte: Elaborado pela autora (2017).
Processos do negócio
O processo Verbka proporcionou uma modelagem e globalização do
conhecimento referente ao negócio: “A aplicação de um processo de aquisição de
conhecimento permitiu uma visão mais detalhada e ao mesmo tempo generalizada,
permitindo uma compreensão global dos requisitos e do sistema” (Apêndice B;
Questão 4; Linha 7). O processo contribuiu para o levantamento de requisitos,
fornecendo a construção de cenários: “[...] com o auxílio das tabelas a interpretação
dos requisitos fica mais dinâmica, facilitando o levantamento dos requisitos e com
isso a elaboração dos requisitos” (Apêndice B; Questão 2; Linha 1). Durante o
desenvolvimento do sistema, algumas falhas de compreensão nesta etapa foram
reduzidas: “[...] a ferramenta ajudou a diminuir algumas brechas do levantamento de
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 62
requisitos, deixando mais visível o que cada requisito deve gerar” (Apêndice B;
Questão 2; Linha 3). Nesse sentido, reduziu-se o tempo desta etapa para a
compreensão dos processos aplicados pelo negócio.
A uniformização do conhecimento forneceu uma melhor comunicação e
participação de todos os envolvidos no projeto e facilitou a adição ou modificações
de requisitos: “[...] com o auxílio da tabela de protopapéis, fica mais fácil a inserção
de novas informações, como, atributos, procedimentos, dados e comportamentos”
(Apêndice B; Questão 3; Linha 3).
Compreensão dos requisitos
A extração do conhecimento implícito oferece uma estratégia para
compreensão dos requisitos do sistema. O principal auxílio foi a redução de falta de
clareza: “A partir do momento que existe um gráfico e/ou uma tabela, a
compreensão dos requisitos fica mais clara” (Apêndice B; Questão 1; Linha 1).
Nesse contexto, ela permitiu a identificação dos atores do sistema e suas
responsabilidades, como observado: “[...] com a ferramenta a visualização dos
requisitos ficou mais clara, detalhando todos os atributos, revelando os responsáveis
pela operação e definindo o tipo do comportamento do requisito” (Apêndice B;
Questão 1; Linha 5). Além disso, auxiliou na compreensão das relações de
comportamento do requisito.
A geração do conhecimento estruturado e sistematizado das estórias do
usuário permitiu a redução de dúvidas durante a análise: “[...] ela permite antecipar
informações evitando dúvidas que podem surgir em fases posteriores” (Apêndice B;
Questão 1; Linha 8). Da mesma maneira, abrange a identificação de requisitos
dependentes: “Com a aplicação do processo de aquisição de conhecimento, fica
mais fácil analisar as dependências do requisito [...]” (Apêndice B; Questão 4; Linha
4). Fornece ainda o rastreamento desses requisitos: “[...] o mapa conceitual ajuda a
direcionar a função do requisito, revelando todo o caminho desse requisito”
(Apêndice B; Questão 2; Linha 5).
Detalhamento dos requisitos
A informação referente a atributos e funcionalidades do sistema foi
complementada: “[...] a visualização dos requisitos ficou mais clara, detalhando
todos os atributos [...]” (Apêndice B; Questão 1; Linha 5). Com isso, foram reduzidos
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 63
riscos relativos à ausência de informação, pois “[...] os requisitos ficam mais
detalhados [...]” (Apêndice B; Questão 3; Linha 1). No entanto, como mencionado
pelos desenvolvedores, o excesso de informação nas tabelas ou no mapa conceitual
causal pode comprometer a compreensão: “[...] o gráfico e/ou a tabela deve ser
clara. O excesso de informações no gráfico pode resultar em uma má compreensão
das informações” (Apêndice B; Questão 1; Linha 2). Ou seja, materiais extensos
devem ser resumidos para melhorar a eficiência do processo.
A uniformização dos conceitos reduziu o viés de interpretação e facilitou a
comunicação dos requisitos. Como observou um participante, quando questionado
se o processo contribuiu para o preenchimento de informações ausentes: “Sim, a
partir da utilização de ‘palavras-chaves’, as quais complementam uma informação”
(Apêndice B; Questão 3; Linha 5).
5.5 Discussão a Respeito dos Resultados
A linguagem natural fornecer rápidos feedbacks para a equipe, no entanto,
podem ocorrer várias falhas de comunicação devido ao caráter subjetivo da
compreensão linguística. Esse caráter subjetivo está vinculado à mensagem que
parte do emissor e nem sempre chega ao sujeito receptor do modo pensado pelo
receptor.
Na primeira etapa do desenvolvimento do estudo de caso, estórias de
usuários foram utilizadas na extração de requisitos no processo convencional da XP
por uma pequena equipe. Devido à qualidade na produção do texto em um cenário
de desenvolvimento distribuído, problemas semânticos foram agravados,
decorrentes dos problemas na comunição. Sem a estruturação do conhecimento,
notou-se uma ausência de detalhes semânticos que levou à falta de compreensão.
Esses riscos foram reduzidos na segunda etapa do desenvolvimento, quando foi
aplicado o processo Verbka. A equipe teve acesso à modelagem semântica das
estórias do usuário, com uma visão geral dos processos do negócio (como a
identificação, atuação e relacionamentos causais de cada ator no sistema), e isso
diminuiu o impacto de falta de compreensão decorrente do fato de a equipe estar
distribuída geograficamente. Como exemplo, a primeira imagem da Figura 15 refere-
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 64
se à modelagem do requisito de entrega do produto e traz um exemplo desse
resultado. Pelo requisito inicial do especialista do negócio: “Como almoxarife recebo
os produtos, cadastro fornecedor com código, nome, endereço, telefone e produtos”
foi suposto pela equipe que o responsável desse cadastro era o almoxarife. E com a
apresentação clara do requisito permitiu confirmar o ator dessa função, que é o
comprador, podendo restringir o acesso do almoxarife nesse cadastro. O processo
contribuiu ainda com uma maior clareza para as dependências entre os requisitos.
Com relação ao nível de granularidade do texto, as estórias curtas facilitaram
a extração do conhecimento; textos extensos tiveram de ser resumidos para
melhorar a eficiência do processo.
Figura 15 - Mapas conceituais causais a) Entrega de produto b) Registro de pedido.
Fonte: Elaborado pela autora (2017).
A uniformização do conhecimento pode evitar viés de interpretação, com
adoção de uma linguagem comum para as partes envolvidas. Dificuldades inerentes
à falta de informação foram controladas, pois a aplicação do processo gera uma
estrutura baseada em princípios da 5W2H. Inferências puderam explicitar o
conhecimento implícito presente nos requisitos ou detectar a ausência de
informação, como observado para os atributos nome e quantidade do produto
(associados por linha tracejada) na segunda imagem da Figura 15.
Capítulo 5 - Estudo de Caso: Desenvolvimento Distribuído de um Sistema Comercial 65
Embora a aplicação da estratégia proposta possa apoiar o gerenciamento de
riscos nos requisitos de uma equipe XP distribuída e ser adaptável a software que
enfreta mudanças frequentes, o estágio atual da sua implantação se depara com
algumas limitações. Uma primeira limitação está na aplicação do processo Verbka,
por ainda não ser automatizado, requer um tempo maior para a sua utilização,
considerando o tempo de extração do conhecimento (aplicação manual dos passos
e etapas), o aprendizado da equipe e a familiarização com o processo. Ainda,
limitando seu uso para equipes de caractéristicas mutáveis. Outra limitação se
sucede na extração e representação de conhecimento de textos extensos, como
citado pelos participantes. Essas limitações serão trabalhadas em estudos futuros.
Os resultados deste estudo (qualitativo) não podem ser generalizados, no
entanto, pode contribuir como uma base útil para outros estudos com pequenas
equipes de desenvolvimento distribuído de software que adotam a linguagem natural
como principal fonte de informação.
5.6 Considerações Finais
Neste capítulo, foi detalhado o estudo de caso, que consistiu em um
desenvolvimento distribuído de software do tipo comercial para o gerenciamento de
estoque, com uma equipe pequena XP. Foi descrito o cenário de desenvolvimento,
com os recursos e ferramentas utilizadas.
O estudo contou com duas etapas, a primeira com o processo convencional
da XP e a segunda com a aplicação da estratégia baseada em aquisição do
conhecimento. Essa aplicação foi validada pelos desenvolvedores, os quais
responderam dois questionários, sendo um na primeira etapa, buscando avaliar a
qualidade dos requisitos e o segundo na segunda etapa, avaliando a capacidade da
estratégia. Esses dados coletados foram analisados por meio da técnica da análise
temática e foram apresentados em uma ampla descrição. Uma breve discussão
sobre os resultados do estudo de caso foi conduzida nesta seção.
66
Capítulo 6
CAPÍTULO 6 - CONCLUSÃO
A flexibilidade da metodologia ágil é interessante em projetos de
desenvolvimento distribuído de software, o qual pode proporcionar uma redução de
custo na construção de software mediante a contratação de uma equipe qualificada.
No entanto, nesses projetos colaborativos, o meio de comunicação pode apresentar
viés de interpretação e acarretar na perda de informação relevante.
Essa aplicação foi analisada em um estudo de caso conduzido neste trabalho,
em que foi desenvolvido um sistema comercial real com a aplicação da metodologia
de software XP por uma equipe pequena de analistas e desenvolvedores de
sistemas, os quais estavam distribuídos geograficamente. O projeto foi composto por
duas etapas. Na primeira etapa foi aplicada e analisada a técnica de elicitação de
requisitos convencional da XP. Mediante aos resultados foi possível constatar que,
mesmo em um sistema simples, problemas semânticos como a ausência de
informação e falta de compreensão nos textos expõem riscos na engenharia de
requisitos, implicando em danos no sistema, como o desenvolvimento de algumas
tarefas que o sistema deveria desempenhar, além da falta de gerenciamento no
acesso do sistema.
Na segunda etapa do desenvolvimento, o processo Verbka foi aplicado nas
estórias do usuário e a extração do conhecimento foi apresentada por meio de uma
ferramenta virtual de gerenciamento de requisitos em um ambiente de
desenvolvimento ágil. Esse resultado foi avaliado pela equipe de desenvolvedores.
Além dessa validação, outro diferencial foi à validação dessa extração pelo
especialista do negócio, o qual pôde avaliar a estruturação do seu próprio
conhecimento. Contribuiu de maneira significativa para a comunicação de uma
Capítulo 6 - Conclusão 67
equipe pequena do projeto XP distribuída com o especialista do negócio e a
geração de novas ideias e propostas de soluções no decorrer do projeto de sistema
comercial.
Riscos na comunicação das estórias do usuário foram controlados com a
utilização da estratégia proposta neste estudo que, por meio de um processo
sistemático para extração de conhecimento, proporcionou a estruturação e facilitou a
comunicação global da informação presente nas estórias do usuário.
A principal contribuição desta pesquisa foi demonstrar como o processo de
extração de conhecimento Verbka pode ser utilizado para gerenciar riscos na
comunicação da equipe XP distribuída, reduzindo problemas inerentes ao uso da
linguagem natural em estórias do usuário. Há na literatura trabalhos que contribuem
com estratégias para ampliar o fluxo de comunicação que as metodologias ágeis
exigem entre as equipes que estão distribuídas geograficamente. Além disso, em
alguns estudos são propostas estratégias para o gerenciamento de riscos
semânticos, com modelagens dos processos do negócio, mediante o uso de mapas
mentais, modelos conceituais e modelagem semântica por meio de dinâmica de
sistemas. Existem também estudos focados na identificação de viés na comunicação
do texto, como a aplicação de algumas práticas para a elevação da qualidade da
escrita. Contudo, esses trabalhos não reparam as falhas decorrentes desses
problemas.
No entanto, a aplicabilidade dessa estratégia a projetos de outra natureza,
como equipes maiores ou outras metodologias de desenvolvimento (por exemplo, no
contexto dos diagramas da UML), deve ser alvo de trabalhos futuros. Além disso,
busca-se a aplicação das atividades de um estudo de maneira idenpendente, para
que não haja o envolvimento dos pesquisadores responsáveis. A estratégia pode
progredir para atender um maior número de projetos de desenvolvimento de
sistemas.
O aprimoramento da estratégia para o gerenciamento de riscos pode ser
concebido com a automatização (total ou parcial) do processo Verbka. Para tanto,
deve-se contar com o apoio de técnicas de processamento de linguagem natural e
de modelagem de conhecimento, incluindo o uso de ontologias. Essa automatização
é essencial para que a estratégia possa ser disseminada e integrada a outros
contextos, como em software de gerenciamento de requisitos. Outro benefício será a
redução do esforço humano para a extração do conhecimento, apoiando a atividade
Capítulo 6 - Conclusão 68
do coordenador da aplicação da estratégia nesse processo. Um estudo quantitativo
para uma melhor avaliação da capacidade dessa automatização pode ser realizado,
para a avaliação comparativa do tempo e qualidade implantada em um projeto de
desenvolvimento de sistema.
69
REFERÊNCIAS
ABDULLAH, E.; ABDELSATIR, E.-T. B. Extreme programming applied in a large-scale distributed system. In: International Conference on Computing, Electrical and Electronic Engineering, Anais...IEEE, ago. 2013. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6633979>. ÅGERFALK, P. J.; FITZGERALD, B.; HOLMSTRÖM OLSSON, H.; CONCHÚIR, E. Ó. Benefits of Global Software Development: The Known and Unknown. In: Making Globally Distributed Software Development a Success Story. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008. p. 1–9. AKBAR, R.; HARIS, M.; NAEEM, M. Requirement Gathering and Tracking Process for Distributed Agile based Development. In: WSEAS International Conference on Applied Informatics and Communications, Anais...World Scientific and Engineering Academy and Society (WSEAS), 2008a. Disponível em: <http://portal.acm.org/citation.cfm?id=1503829.1503900>. AKBAR, R.; HARIS, M.; NAEEM, M. Agile Framework for Globally Distributed Development Environment (The DAD Model). In: WSEAS International Conference on Applied Informatics and Communications, Anais...World Scientific and Engineering Academy and Society (WSEAS), 2008b. Disponível em: <http://dl.acm.org/citation.cfm?id=1503899>. ALZOUBI, Y. I.; GILL, A. Q.; AL-ANI, A. Empirical studies of geographically distributed agile development communication challenges: A systematic review. Information & Management, v. 53, n. 1, p. 22–37, jan. 2016. Disponível em: <http://dx.doi.org/10.1016/j.im.2015.08.003>. BAVANI, R. Distributed Agile: Steps to Improve Quality before Design. Agile Record, n. 8, out. 2011. BECK, K. Extreme programming explained: embrace change. Boston: Addison-Wesley, 1999a. BECK, K. Embracing change with extreme programming. Computer, v. 32, n. 10, p. 70–77, 1999b. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=796139>. BLEIJENBERGH, I.; KORZILIUS, H.; VERSCHUREN, P. Methodological criteria for the internal validity and utility of practice oriented research. Quality & Quantity, v. 45, n. 1, p. 145–156, 8 jan. 2011. Disponível em: <http://link.springer.com/10.1007/s11135-010-9361-5>. BLOMKVIST, J. K.; PERSSON, J.; ÅBERG, J. Communication through Boundary Objects in Distributed Agile Teams. In: ACM Conference on Human
Referências 70
Factors in Computing Systems, New York, New York, USA. Anais... New York, New York, USA: ACM Press, 2015. Disponível em: <http://dl.acm.org/citation.cfm?doid=2702123.2702366>. BOEHM, B. W.; TURNER, R. Balancing agility and discipline: a guide for the perplexed. 1. ed. Boston: Addison-Wesley, 2003. BRAUN, V.; CLARKE, V. Using thematic analysis in psychology. Qualitative Research in Psychology, v. 3, n. 2, p. 77–101, jan. 2006. Disponível em: <http://www.tandfonline.com/doi/abs/10.1191/1478088706qp063oa>. CAO, L.; MOHAN, K.; PENG XU; RAMESH, B. How extreme does extreme programming have to be? Adapting XP practices to large-scale projects. In: Hawaii International Conference on System Sciences, Anais...IEEE, jan. 2004. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1265237>. CARVALHO, F.; AZEVEDO, L. G. Service Agile Development Using XP. In: International Symposium on Service-Oriented System Engineering, Anais...IEEE, mar. 2013. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6525528>. COHN, M. User stories applied: for agile software development. [s.l.] Addison-Wesley, 2004. COHN, M. Advantages of the “As a user, I want” user story template, 2008. Disponível em: <http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template>. Acesso em: 4 nov. 2016. COLLINS, E.; MACEDO, G.; MAIA, N.; DIAS-NETO, A. An Industrial Experience on the Application of Distributed Testing in an Agile Software Development Environment. In: International Conference on Global Software Engineering, Anais...IEEE, ago. 2012. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6337365>. CUNHA, F. dos S. Um sistema especialista para previdência privada. 1995. 95f. Dissertação (Mestrado) - Universidade Federal de Santa Catarina, Florianópolis, 1995. CUNHA, R.; PEREIRA, C. S.; PINTO, J. Â. Agile software project: Proposal of a model to manage risks. In: Iberian Conference on Information Systems and Technologies, Anais...IEEE, jun. 2013. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6615716&isnumber=6615699>. DAMIAN, D. E.; ZOWGHI, D. The impact of stakeholders’ geographical distribution on managing requirements in a multi-site organization. In: IEEE Joint International Conference on Requirements Engineering, jul. 2001, Anais...IEEE, 2002. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1048545>. DANEVA, M.; VAN DER VEEN, E.; AMRIT, C.; GHAISAS, S.; SIKKEL, K.; KUMAR,
Referências 71
R.; AJMERI, N.; RAMTEERTHKAR, U.; WIERINGA, R. Agile requirements prioritization in large-scale outsourced system projects: An empirical study. Journal of Systems and Software, v. 86, n. 5, p. 1333–1353, maio 2013. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0164121212003536>. DING, L. A new paradigm of knowledge engineering by soft computing. [s.l.] World Scientific, 2001. DIEDERICH, J.; RUHMANN, I.; MAY, M. KRITON: a knowledge-acquisition tool for expert systems. International Journal of Man-Machine Studies, v. 26, n. 1, p. 29–40, jan. 1987. Disponível em: <http://linkinghub.elsevier.com/retrieve/pii/S0020737387800330>. DORAIRAJ, S.; NOBLE, J.; MALIK, P. Understanding Team Dynamics in Distributed Agile Software Development. In: Lecture Notes in Business Information Processing. [s.l: s.n.] 111 LNBIP p. 47–61. ELSHAMY, A.; ELSSAMADISY, A. Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects. In: Agile Processes in Software Engineering and Extreme Programming. Berlin, Heidelberg: Springer Berlin Heidelberg, 2007. p. 46–53. ESTÁCIO, B. J. da S. Development of a Set of Best Practices for Distributed Pair Programming. In: International Conference on Global Software Engineering Workshops, Anais...IEEE, ago. 2012. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6337315>. ESTLER, H.-C.; NORDIO, M.; FURIA, C. A.; MEYER, B.; SCHNEIDER, J. Agile vs. Structured Distributed Software Development: A Case Study. In: International Conference on Global Software Engineering, Anais...IEEE, ago. 2012. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6337393>. GANESH, N.; THANGASAMY, S. Issues identified in the software process due to barriers found during eliciting requirements on agile software projects: Insights from India. International Journal of Computer Applications, v. 16, n. 5, p. 7–12, 28 fev. 2011. Disponível em: <http://www.ijcaonline.org/volume16/number5/pxc3872713.pdf>. GOMES, F. D.; VASQUES, D. G.; JARAMILLO, J. F. G.; SANTOS, G. S. dos; ANUNCIAÇÃO, P. F.; BAIOCO, G. B.; ZAMBON, A. C. Uso de Métodos de Representação do Conhecimento e Estilos de Aprendizagem na Elaboração de Estratégias de Ensino. In: VII Congresso Mundial de Estilos de Aprendizagem, Bragança. Anais... Bragança: Instituto Politécnico de Bragança, 2016. HILDENBRAND, T.; GEISSER, M.; KUDE, T.; BRUCH, D.; ACKER, T. Agile Methodologies for Distributed Collaborative Development of Enterprise Applications. In: International Conference on Complex, Intelligent and Software Intensive Systems, Anais...IEEE, 2008. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4606732>.
Referências 72
JAIN, R.; SUMAN, U. A Systematic Literature Review on Global Software Development Life Cycle. ACM SIGSOFT Software Engineering Notes, v. 40, n. 2, p. 1–14, 3 abr. 2015. Disponível em: <http://dl.acm.org/citation.cfm?doid=2735399.2735408>. JAWADEKAR, W. S. Knowledge management: text & cases. [s.l.] Tata McGraw-Hill Education, 2011. KAJKO-MATTSSON, M.; AZIZYAN, G.; MAGARIAN, M. K. Classes of Distributed Agile Development Problems. In: Agile Conference, Anais...IEEE, ago. 2010. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5562806>. KAMARUDDIN, N. K.; ARSHAD, N. H.; MOHAMED, A. Chaos issues on communication in Agile Global Software Development. In: 2012 IEEE Business, Engineering & Industrial Applications Colloquium (BEIAC), Anais...IEEE, abr. 2012. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6226091>. KHOO, C. S. G.; NA, J.-C. Semantic relations in information science. Annual Review of Information Science and Technology, v. 40, n. 1, p. 157–228, 28 set. 2007. Disponível em: <http://doi.wiley.com/10.1002/aris.1440400112>. KIRCHER, M.; JAIN, P.; CORSARO, A.; LEVINE, D. Distributed extreme programming. Extreme Programming and Flexible Processes in Software Engineering, Italy, p. 66–71, 2001. KORKALA, M.; MAURER, F. Waste identification as the means for improving communication in globally distributed agile software development. Journal of Systems and Software, v. 95, p. 122–140, set. 2014. Disponível em: <http://dx.doi.org/10.1016/j.jss.2014.03.080>. LUCASSEN, G.; DALPIAZ, F.; VAN DER WERF, J. M. E. M.; BRINKKEMPER, S. Forging high-quality User Stories: Towards a discipline for Agile Requirements. In: 2015 IEEE 23rd International Requirements Engineering Conference (RE), Anais...IEEE, ago. 2015. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7320415>. MACEDO, W. O livro da semântica: estudo dos signos linguísticos. [s.l.] LEXIKON Editora, 2013. Manifesto Ágil. Disponível em: <http://agilemanifesto.org/>. Acesso em: 1 jan. 2016. MOHER, D.; LIBERATI, A.; TETZLAFF, J.; ALTMAN, D. G. Preferred reporting items for systematic reviews and meta-analyses: the PRISMA statement. PLoS medicine, v. 6, n. 7, p. e1000097, 21 jul. 2009. Disponível em: <http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2707599&tool=pmcentrez&rendertype=abstract>. Acesso em: 10 jun. 2011. MUDUMBA, V.; ONE-KI, L. A New Perspective on GDSD Risk Management: Agile
Referências 73
Risk Management. In: IEEE International Conference on Global Software Engineering, Anais...IEEE, ago. 2010. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5581512>. MUNOZ, L. F.; ALEGRIA, J. A. H. XA: An XP extension for supporting architecture practices. In: Colombian Computing Congress (CCC), Anais...IEEE, out. 2012. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6398012>. NIAZI, M.; MAHMOOD, S. Towards Identifying the Factors for Project Management Success in Global Software Development : Initial Results. In: International Conference on Software Engineering Advances ICSEA 2013, Anais...2013. PAASIVAARA, M.; LASSENIUS, C. Could Global Software Development Benefit from Agile Methods? In: 2006 IEEE International Conference on Global Software Engineering (ICGSE’06), Anais...IEEE, out. 2006. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4031749>. PMI. A guide to the project management body of knowledge: pmbok guide. [s.l.] Project Management Inst, 2008. PRECHELT, L. Agile offsharing: Using pair work to overcome nearshoring difficulties. In: International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE), Anais...IEEE, maio 2013. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6614755>. PRIOR, P.; KEENAN, F. Requirements Management in a Distributed Agile Environment. Proceedings of World Academy of Science, Engineering and Technology, v. 4, p. 204–207, fev. 2005. PUTRA, I. P. E. S.; YULIAWATI, A.; MURSANTO, P. Industrial Extreme Programming practice’s implementation in rational unified process on agile development theme. In: International Conference on Advanced Computer Science and Information Systems (ICACSIS), Anais...IEEE, 2012. QAHTANI, A. M.; WILLS, G. B.; GRAVELL, A. M. Customising Software Products in Distributed Software Development. In: International Conference on Information Society (i-Society), Anais...2013. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6636348&isnumber=6636320>. QURESHI, M. R. J. Agile software development methodology for medium and large projects. IET Software, v. 6, n. 4, p. 358–363, 2012. Disponível em: <http://digital-library.theiet.org/content/journals/10.1049/iet-sen.2011.0110>. RAZZAK, M. A.; AHMED, R. Knowledge Sharing in Distributed Agile Projects: Techniques, Strategies and Challenges. In: Federated Conference on Computer Science and Information Systems (FedCSIS), Warsaw, Poland. Anais... Warsaw, Poland: 29 set. 2014. Disponível em: <http://ieeexplore.ieee.org/articleDetails.jsp?arnumber=6933185>.
Referências 74
RODRÍGUEZ, A.; CARO, A. Obteniendo Casos de Uso centrados en la Calidad de los Datos desde Procesos de Negocio descritos con BPMN. Iberian Journal of Information Systems and Technologies, n. 10, 1 dez. 2012. Disponível em: <http://www.scielo.gpeari.mctes.pt/scielo.php?script=sci_abstract&pid=S1646-98952012000200006&lng=pt&nrm=iso&tlng=es>. RUNESON, P.; HÖST, M. Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, v. 14, n. 2, p. 131–164, 19 abr. 2009. Disponível em: <http://link.springer.com/10.1007/s10664-008-9102-8>. SADIQ, M.; HASSAN, T. An extended adaptive software development process model. In: International Conference on Issues and Challenges in Intelligent Computing Techniques (ICICT), 305, Anais...IEEE, fev. 2014. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6781341>. SCHENK, J.; PRECHELT, L.; SALINGER, S. Distributed-pair programming can work well and is not just distributed pair-programming. In: Companion Proceedings of the 36th International Conference on Software Engineering - ICSE Companion 2014, New York, New York, USA. Anais... New York, New York, USA: ACM Press, 2014. Disponível em: <http://dl.acm.org/citation.cfm?doid=2591062.2591188>. SCHREIBER, G. Knowledge engineering and management: the commonkads methodology. [s.l.] MIT Press, 2000. SEVERINO, A. J. Metodologia do trabalho científico. 23. ed. São Paulo: Cortez, 2007. SHRIVASTAVA, S. V.; RATHOD, U. Risks in Distributed Agile Development: A Review. Procedia - Social and Behavioral Sciences, v. 133, p. 417–424, maio 2014. Disponível em: <http://www.sciencedirect.com/science/article/pii/S1877042814031188>. SILVA, A. H.; FOSSÁ, M. I. T. Análise De Conteúdo: Exemplo De Aplicação Da Técnica Para Análise De Dados Qualitativos. Qualitas Revista Eletrônica, v. 16, n. 1, p. 1–14, 2015. Disponível em: <http://revista.uepb.edu.br/index.php/qualitas/article/view/2113>. ŠMITE, D.; MOE, N. B.; ÅGERFALK, P. J. (ed.). Agility across time and space. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010. SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson Addison Wesley, 2007. SZŐKE, Á. A Feature Partitioning Method for Distributed Agile Release Planning. In: SILLITTI, A.; HAZZAN, O.; BACHE, E.; ALBALADEJO, X. (Ed.). Agile Processes in Software Engineering and Extreme Programming. [s.l.] Springer, 2011. p. 27–42. TAKEUCHI, H.; NONAKA, I. Gestão do conhecimento. [s.l.] Bookman, 2009.
Referências 75
TARAPANOFF, K. Inteligência, informação e conhecimento em corporações. Brasília: Instituto Brasileiro de Informação em Ciência e Tecnologia, 2006. VASQUES, D. G. Verbka : processo para aquisição de conhecimento baseado em semântica verbal. 2016. 167f. Dissertação (Mestrado) - Universidade Estadual de Campinas, Limeira, 2016. Disponível em: <http://www.bibliotecadigital.unicamp.br/document/?code=000973205>. VASQUES, D. G.; GOMES, F. D.; JARAMILLO, J. F. G.; MARTINS, P. S. Verbka: An Approach To Building Causal Concept Maps Based On Verbal Semantics. In: 7th International Conference on Concept Mapping, Tallinn. Anais... Tallinn: 2016a. VASQUES, D. G.; ZAMBON, A. C.; BAIOCO, G. B.; MARTINS, P. S. An Approach to Knowledge Acquisition Based on Verbal Semantics. In: Hawaii International Conference on System Sciences (HICSS), Anais...IEEE, jan. 2016b. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7427700>. VICENTE, R. Modelamiento semántico con Dinámica de Sistemas en el proceso de desarrollo de software. Iberian Journal of Information Systems and Technologies, n. 10, 1 dez. 2012. Disponível em: <http://www.scielo.gpeari.mctes.pt/scielo.php?script=sci_abstract&pid=S1646-98952012000200003&lng=pt&nrm=iso&tlng=es>. WANDERLEY, F.; DA SILVEIRA, D. S. A Framework to Diminish the Gap between the Business Specialist and the Software Designer. In: 2012 Eighth International Conference on the Quality of Information and Communications Technology, Anais...IEEE, set. 2012. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6511809>. WANDERLEY, F.; SILVA, A.; ARAUJO, J.; SILVEIRA, D. S. SnapMind: A framework to support consistency and validation of model-based requirements in agile development. In: 2014 IEEE 4th International Model-Driven Requirements Engineering Workshop (MoDRE), Anais...IEEE, ago. 2014. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6890825>. WIELINGA, B. J. Reflections on 25+ years of knowledge acquisition. International Journal of Human-Computer Studies, v. 71, n. 2, p. 211–215, fev. 2013. Disponível em: <http://linkinghub.elsevier.com/retrieve/pii/S1071581912001590>.
YADAV, V.; ADYA, M.; NATH, D.; SRIDHAR, V. Investigating an “Agile-Rigid” Approach in Globally Distributed Requirements Analysis. In: Pacific-Asia Conference on Information Systems, Anais...2007. Disponível em: <http://www.pacis-net.org/file/2007/1196.pdf>.
76
Apêndice A
PRIMEIRO QUESTIONÁRIO INDIVIDUAL PARA
INTEGRANTES DO ESTUDO DE CASO
Este apêndice expõe as questões e as respostas obtidas do primeiro
questionário aplicado individualmente para a equipe de desenvolvedores do estudo
de caso.
Em relação aos requisitos, responda:
Questão 1: Você encontrou alguma dificuldade para a compreensão dos requisitos? Quais dificuldades? Em quais requisitos? (3 respostas) Na análise de requisitos houve uma dificuldade na compreensão das sentenças, 1
pois as mesmas foram escritas de uma forma informal e o modo como elas foram 2
expostas parecia que emissor e receptor conheciam todos os processos e 3
particularidades da organização. Além disso, empregaram-se diferentes termos para 4
designar a mesma coisa. 5
Os requisitos apresentados nas histórias podem servir como base para um escopo 6
do projeto a ser desenvolvido. Tal projeto ainda deve ser refinado junto ao cliente 7
antes de concluído. Não houve dificuldade em um requisito especifico, seria apenas 8
a falta de detalhes, pois foi necessário ler todas as histórias mais de uma vez para 9
entender a base dos processos realizados pelo cliente. 10
Sim, eu encontrei muita dificuldade para compreender e interpretar os requisitos. As 11
dificuldades encontradas foram: • Os requisitos não estão numerados; • Os 12
requisitos não estão definidos como funcionais e não funcionais; • Os requisitos 13
estão sem comportamento. Ex. (entrada, saída e estado) • Há muitas palavras que 14
não deixam claro o que dê fato o requisito gera; • No requisito 1, ao meu ver, falta de 15
informações, para que seja necessário fazer um cadastro de funcionário; • No 16
requisito 2, a palavra “justamente” dá vários sentidos a frase, por isso, é difícil a 17
definição do requisito; • No requisito 3, não há informações suficientes para que seja 18
Apêndice A – Primeiro Questionário Individual para Integrantes do Estudo de Caso 77
definido como requisito; • No requisito 6, não entendi o que o sistema irá fazer neste 19
caso. O sistema terá um cadastro das pesquisas feitas pelo comprador? Ou esse 20
requisito é um requisito não funcional?; • No requisito 7, há falta de informações, 21
para que seja necessário fazer um cadastro de fornecedor; • No requisito 10, não 22
está claro para quem será destinado o e-mail, se será para um responsável do 23
departamento ou para outros responsáveis da empresa. 24
Questão 2: Você identificou algum requisito vago? Qual? (3 respostas) Todos os requisitos apresentaram alguma imprecisão. 1
Alguns requisitos deram a impressão de falta de informação, por exemplo: O sobre o 2
administrador, ele apenas criará os demais logins ou poderá realizar algum outro 3
processo do sistema? O setor compras, apenas pesquisa as peças/produtos? Ele 4
deve ter acesso ao cadastro de fornecedores? Sobre os relatórios, seria apenas o 5
relatório de quantidade de baixas mensal ou seria necessário algum outro tipo de 6
relatório? 7
Há 3 requisitos vagos no levantamento de requisitos analisado, são os requisitos 2, 8
3 e 6. • No requisito 2, não é possível definir qual é o comportamento do requisito, 9
por existir múltiplas perspectivas, devido a palavra “justamente”; • No requisito 3, há 10
muita falta de informação, por isso é muito difícil construir qualquer função para este 11
requisito; • No requisito 6, há ausência do comportamento e da ação (cadastro, 12
consulta, etc.), dificultando o entendimento para a especificação da função do 13
requisito. 14
Questão 3: Faltou alguma informação nos requisitos no seu entender? Quais informações? (3 respostas) 1. Como administrador cadastro, altero e excluo funcionário com número de 1
matricula, nome e departamento, para controle de acesso. • Administrador do quê? 2
Do Sistema. • Existem outros tipos de administradores? • Controlar o acesso em que 3
sentindo: Controlar o acesso a determinadas funcionalidades (para isso deveria 4
haver maiores especificações sobre qual departamento pode acessar cada 5
funcionalidade) ou atuar somente como um administrador de sistema, a qual inclui a 6
funcionalidade de cadastrar, alterar e excluir funcionários. • Sendo responsável por 7
cadastrar funcionários, deveria incluir a opção de pesquisar o mesmo? 2. Como 8
almoxarife tenho acesso ao sistema justamente com o departamento de compras. • 9
No lugar do termo “justamente” não seria a palavra “juntamente”? Isso provoca 10
diferentes interpretações • A que tipo de informações o departamento de almoxarife 11
deverá ter acesso? Porque apesar de serem departamentos dependentes um do 12
outro, cada qual possuem suas próprias características e atividades distintas. • Esse 13
acesso tem que finalidade? Cadastrar ou alterar algum tipo de informação ou 14
somente visualizar as informações do departamento de compras. • O departamento 15
de compras também tem acesso ao almoxarife? (seguindo a mesma premissa). 3. 16
Apêndice A – Primeiro Questionário Individual para Integrantes do Estudo de Caso 78
Como almoxarife recebo requisição de peças. • Quais informações devem estar 17
contidas nessa requisição? • O Almoxarife só recebe requisição de peças ou há 18
requerimentos de outros itens? • Recebe de quem ou de que departamento essa 19
requisição? • Qual é o modo de recebimento dessa requisição? Via e-mail, 20
formulário próprio,...? • Existe algum critério para receber essa requisição? 4. Como 21
almoxarife devo dar baixa na peça, caso a peça solicitada conste no estoque. Devo 22
registrar pedido com nome do funcionário, departamento e data da entrega da peça 23
ao técnico. • Na frase “Como almoxarife devo dar baixa na peça, caso a peça 24
solicitada conste no estoque” ao invés de dar baixa na peça não seria dar baixar na 25
requisição? • Para que haja a “baixa da peça” é necessário considerar algum 26
parâmetro? Se sim, qual (is)? • Só é “dado baixa na ‘peça’” quando se já possui a 27
mesma no estoque ou existe outra ação que permite também “dar baixa na peça”? • 28
Colocou-se dois requisitos diferentes em um só. • O que consiste este ato de “dar 29
baixa na ‘peça’”? Qual tarefa o sistema deve realizar? • A realização de um pedido 30
não deve conter mais informações, como qual (is) peça(s) necessitam ser 31
adquiridas, a quantidade, o tipo (se houver algum tipo de variação), entre outras 32
informações? • Existe algum modelo de pedido que deve ser seguido? • Todas as 33
pessoas do almoxarife registram o pedido? • A data de entrega corresponderia à 34
data da realização do pedido? Há uma dupla interpretação. • É pedido do que? De 35
compra de um novo produto? 5. Caso não tenha a peça, solicito um pedido para o 36
departamento de compras para providenciar a compra em regime de urgência. • Mas 37
o departamento de almoxarife não tem acesso ao departamento de compras? • 38
Somente o almoxarife pode realizar um pedido de compra? • Só é solicitado um 39
pedido de compras se não houve peça em estoque? E se estiver acabando, esperar 40
acabar para realizar o pedido? • Todas as compras são realizadas em regime de 41
urgência? • Ao invés do termo “solicito” não seria, “encaminho”, afinal levando em 42
consideração o requisito anterior quem elabora o pedido é o almoxarife. • Quais são 43
os tipos de pedido que são de responsabilidade do almoxarife? E do departamento 44
de compras? 6. Como almoxarife envio um e-mail de advertência ao departamento 45
de compras para a requisição de novos produto quando entra na quantidade 46
mínima. • O sistema deve ter um modulo e-mail? Se sim para cadastrar um 47
funcionário deveria ser pedido o e-mail do mesmo. • O almoxarife realiza pedidos de 48
peças e também de produtos? • Somente quando acaba a peça que é feito um 49
pedido de compra ao departamento de compras? • O sistema deve emitir algum tipo 50
de alerta quando um “produto” está em quantidade mínima? • O departamento de 51
compras realiza uma compra depois do recebimento do pedido? Então qual é a 52
finalidade de se mandar um e-mail? 7. Como comprador pesquiso preços, prazo de 53
entrega e qualidade do produto. • A execução desta atividade depende de algum 54
parâmetro, como por exemplo, a solicitação de um novo pedido de compra? • É 55
necessário algum aviso prévio, antes de receber definitivamente algum pedido? 8. 56
Como almoxarife recebo os produtos, cadastro fornecedor com código, nome, 57
endereço, telefone e produtos. • Somente o departamento de almoxarife pode 58
cadastrar fornecedor? • Somente quando recebe-se o produto é que cadastra o 59
fornecedor? • Qual seria o código do fornecedor? Seria gerado pelo próprio sistema? 60
Apêndice A – Primeiro Questionário Individual para Integrantes do Estudo de Caso 79
9. Como almoxarife eu verifico se o produto recebido já está cadastrado. No caso de 61
existir, acrescento e atualizo a quantidade. Caso não tenha o produto cadastrado, 62
faço novo cadastro com o código, nome do produto, nome do fabricante, nome do 63
fornecedor, peso, localização dentro do estoque, prazo de garantia, limite de 64
quantidade mínima, data de recebimento do produto. • Atualiza-se somente a 65
quantidade ou coloca-se alguma outra informação? • Somente o almoxarife cadastra 66
um novo produto? • Que código é esse para cadastrar produto? Um código que deve 67
ser gerado pelo próprio sistema ou inserir um código já pré-existente na 68
organização? 10. Como almoxarife preciso gerar um relatório mensal de controle de 69
produtos, com os produtos solicitados no mês com o código, quantidade, data e 70
departamento responsável. • O que seria “Departamento Responsável”? Quem 71
solicitou o pedido? • A geração desse relatório deve ser exibido em tela e/ou gerado 72
em .pdf? • O sistema deve possibilitar a opção de “imprimir” o relatório? 11. Como 73
almoxarife devo enviar os relatórios gerados via e-mail. • O sistema deve ter um 74
modulo e-mail? Se sim para cadastrar um funcionário deveria ser pedido o e-mail do 75
mesmo. 76
Algumas dúvidas sobre os processos surgiram no momento de analisar os 77
requisitos: Requisito de cadastro de novas peças: deve possuir um campo de 78
quantidade atual? Um produto pode ter mais de um fornecedor vinculado? Se sim na 79
pergunta anterior, cada fornecedor possui uma garantia diferente? Cadastro de 80
fornecedor: um fornecedor pode fornecer apenas um tipo de peça/produto? Cadastro 81
de funcionários: os departamentos são fixos ou será necessário um cadastro de 82
departamentos? 83
Sim, há vários requisitos faltando informações: • No requisito 1, está faltando o tipo 84
de usuário (para definir quais interfaces o usuário poderá acessar) e a senha do 85
usuário (chave para controlar o acesso do usuário); • No requisito 3, está faltando o 86
procedimento ao receber a requisição de peças; • No requisito 4, faltam os dados 87
para a solicitação do pedido ao departamento de compras; • No requisito 7, na 88
minha visão, será necessário a inserção dos campos nome do responsável da venda 89
ou da entrega e cnpj ou cpf; • No requisito 9, ao meu ver, seria necessário colocar no 90
relatório o nome do produto também, para que a pessoa que for visualizar o 91
relatório, possa ver o produto e não o código do produto; • No requisito 10, falta o 92
destinatário do e-mail (departamentos ou responsáveis pelo departamento). 93
Questão 4: Quais outras dificuldades você identificou na primeira etapa do processo? (3 respostas) A principal dificuldade encontrada consistiu na falta de informações referentes à 1
organização e seu processo de trabalho. Além de não serem especificados, 2
precisamente, todos os elementos. 3
Há falta de conhecimento do processo a ser desenvolvido. Se as histórias fossem 4
descritas como a explicar ou exemplificar os processos a um leigo, a análise dos 5
Apêndice A - Primeiro Questionário Individual para Integrantes do Estudo de Caso 80
requisitos poderia ser menos demorada e o escopo poderia ser laborado e aprovado 6
mais rapidamente. 7
Analisando o levantamento de requisitos, vejo que há muitas falhas (clareza, 8
ausência de informações e dê técnicas (método VORD, Etnografia, etc.) de 9
levantamento de requisitos) na descrição dos requisitos para o sistema.10
81
Apêndice B
SEGUNDO QUESTIONÁRIO INDIVIDUAL PARA
INTEGRANTES DO ESTUDO DE CASO
Neste apêndice são apresentadas as questões e as respostas recolhidas do
segundo questionário, o qual foi aplicado de forma individual para a equipe do
estudo de caso.
Em relação aos requisitos, responda: Questão 1: A ferramenta contribui para a compreensão dos requisitos? Como? (3 respostas) Sim. A partir do momento que existe um gráfico e/ou uma tabela, a compreensão 1
dos requisitos fica mais clara. Porém o gráfico e/ou a tabela deve ser clara. O 2
excesso de informações no gráfico pode resultar em uma má compreensão das 3
informações 4
Sim, com a ferramenta a visualização dos requisitos ficou mais clara, detalhando 5
todos os atributos, revelando os responsáveis pela operação e definindo o tipo do 6
comportamento do requisito. 7
Sim, porque ela permite antecipar informações evitando dúvidas que podem surgir 8
em fases posteriores. 9
Questão 2: Com a aplicação da ferramenta, os requisitos vagos foram eliminados? Como? (3 respostas) Sim, com o auxílio das tabelas a interpretação dos requisitos fica mais dinâmica, 1
facilitando o levantamento dos requisitos e com isso a elaboração dos requisitos. 2
A meu ver, a ferramenta ajudou a diminuir algumas brechas do levantamento de 3
requisitos, deixando mais visível o que cada requisito deve gerar. A tabela de 4
Apêndice B - Segundo Questionário Individual para Integrantes do Estudo de Caso 82
protopapéis ajuda a mostrar para que serve o requisito e o mapa conceitual ajuda a 5
direcionar a função do requisito, revelando todo o caminho desse requisito. 6
Todos os requisitos que estavam imprecisos foram supridos. 7
Questão 3: A ferramenta preenche as informações ausentes nos requisitos? De que modo? (3 respostas) De certa forma, os requisitos ficam mais claros. Os requisitos ficam mais detalhados, 1
facilitando o desenho do projeto. 2
Sim, com o auxílio da tabela de protopapéis, fica mais fácil a inserção de novas 3
informações, como, atributos, procedimentos, dados e comportamentos. 4
Sim, a partir da utilização de “palavras-chaves”, as quais complementam uma 5
informação. 6
Questão 4: Comentários adicionais com relação ao processo de aquisição do conhecimento. (3 respostas) O processo pode ser utilizado em uma segunda fase do levantamento dos 1
requisitos, talvez como uma confirmação dos requisitos juntamente ao cliente, para 2
finalização e aprovação do projeto. 3
Com a aplicação do processo de aquisição de conhecimento, fica mais fácil analisar 4
as dependências do requisito, melhorando a compreensão do propósito de cada 5
requisito e diminuindo as lacunas deixadas pelo levantamento de requisitos. 6
A aplicação de um processo de aquisição de conhecimento permitiu uma visão mais 7
detalhada e ao mesmo tempo generalizada, permitindo uma compreensão global 8
dos requisitos e do sistema. 9
83
Apêndice C
REQUISITOS DO ESTUDO DE CASO
As estórias do usuário registradas no estudo de caso e o conhecimento
estruturado e modelado por meio do processo de aquisição do conhecimento
(Verbka) são apresentados neste apêndice. A visão geral dos requisitos também é
modelada e estruturada.
C.1 Primeiro Requisito do Estudo de Caso
Estória do usuário:
“Como administrador cadastro, altero e excluo funcionário com número de matrícula,
nome e departamento, para controle de acesso.”
Estruturação (Quadro C.1) e modelagem (Figura C.1) do conhecimento da primeira
estória do usuário:
Apêndice C - Requisitos do Estudo de Caso 84
Quadro C.1 – Tabela de protopapéis da primeira estória do estudo de caso.
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual
Para quem
Onde Quando Quanto
1 Administrador do sistema
Cadastra Funcionário - No sistema - -
2 Administrador do sistema
Consulta Funcionário - No sistema - -
3 Administrador do sistema
Altera Funcionário - No sistema - -
4 Administrador do sistema
Exclui Funcionário - No sistema - -
5 Funcionário Tem Atributo número de matrícula
- No sistema - -
6 Funcionário Tem Atributo nome - No sistema - -
7 Funcionário Tem Atributo departamento
- No sistema - -
8 Funcionário Tem Atributo senha - No sistema - -
9 Funcionário Acessa Sistema - - - -
10 Administrador do sistema
Controla Acesso de funcionário
- No sistema - -
Figura C.1 - Mapa conceitual da primeira estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
Apêndice C - Requisitos do Estudo de Caso 85
C.2 Segundo Requisito do Estudo de Caso
Estória do usuário:
“Como almoxarife tenho acesso ao sistema justamente com o departamento de
compras.”
Estruturação (Quadro C.2) e modelagem (Figura C.2) do conhecimento da segunda
estória do usuário:
Quadro C.2 – Tabela de protopapéis da segunda estória do estudo de caso.
Figura C.2 - Mapa conceitual da segunda estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
C.3 Terceiro Requisito do Estudo de Caso
Estória do usuário:
“Como almoxarife recebo requisição de peças.“
Estruturação (Quadro C.3) e modelagem (Figura C.3) do conhecimento da terceira
estória do usuário:
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual
Para quem Onde Quando Quanto
1 Almoxarife Acessa Sistema - - - -
2 Comprador Acessa Sistema - - - -
Apêndice C - Requisitos do Estudo de Caso 86
Quadro C.3 – Tabela de protopapéis da terceira estória do estudo de caso.
Figura C.3 - Mapa conceitual da terceira estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
C.4 Quarto Requisito do Estudo de Caso
Estória do usuário:
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem Onde Quando Quanto
1 Técnico Acessa Sistema - - - -
2 Técnico Consulta Produto - No
sistema - -
3 Técnico Envia Pedido do produto Para o
almoxarife No e-mail
- -
4 Almoxarife Recebe Pedido do produto - No e-mail
- -
5 Sistema Acessa E-mail - - - -
Apêndice C - Requisitos do Estudo de Caso 87
“Como almoxarife devo dar baixa na peça, caso a peça solicitada conste no estoque.
Devo registrar pedido com nome do funcionário, departamento e data da entrega da
peça ao técnico.”
Estruturação (Quadro C.4) e modelagem (Figura C.4) do conhecimento da quarta
estória do usuário:
Quadro C.4 – Tabela de protopapéis da quarta estória do estudo de caso.
P
Proto-AG Proto-PAC
SNsuj
VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual
Para quem Onde Quando Quanto
1 Almoxarife Consulta Produto - No sistema - -
2 Produto Consta - - No estoque - -
3 Almoxarife Entrega Produto Ao Técnico - - -
4 Almoxarife Atualiza Quantidade do produto
- No sistema - -
5 Almoxarife Registra Pedido do produto
- No sistema - -
6 Pedido Tem Atributo produto
- No sistema - -
7 Pedido Tem Atributo quantidade do produto
- No sistema - --
8 Pedido Tem Atributo nome do Técnico
- No sistema - -
9 Pedido Tem Atributo departamento do Técnico
- No sistema - -
10 Pedido Tem Atributo data de entrega do produto
- No sistema - -
Apêndice C - Requisitos do Estudo de Caso 88
Figura C.4 - Mapa conceitual da quarta estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
C.5 Quinto Requisito do Estudo de Caso
Estória do usuário:
“Caso não tenha a peça, solicito um pedido para o departamento de compras para
providenciar a compra em regime de urgência.”
Estruturação (Quadro C.5) e modelagem (Figura C.5) do conhecimento da quinta
estória do usuário:
Apêndice C - Requisitos do Estudo de Caso 89
Quadro C.5 – Tabela de protopapéis da quinta estória do estudo de caso.
Figura C.5 - Mapa conceitual da quinta estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
C.6 Sexto Requisito do Estudo de Caso
Estória do usuário:
“Como almoxarife envio um e-mail de advertência ao departamento de compras para
a requisição de novos produtos quando entra na quantidade mínima.”
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem Onde Quando Quanto
1 Produto Não consta - - No
estoque - -
2 Almoxarife Encaminha Pedido do produto
Para o Comprador
No e-mail
- -
3 Comprador Providencia A compra em regime de urgência
- - - -
Apêndice C - Requisitos do Estudo de Caso 90
Estruturação (Quadro C.6) e modelagem (Figura C.6) do conhecimento da sexta
estória do usuário:
Quadro C.6 – Tabela de protopapéis da sexta estória do estudo de caso.
Figura C.6 - Mapa conceitual da sexta estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
C.7 Sétimo Requisito do Estudo de Caso
Estória do usuário:
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem Onde Quando Quanto
1 Produto Entra - - Na
quantidade mínima
- -
2 Almoxarife Recebe Notificação - No sistema
Quando produto entra na quantidade
mínima
-
3 Almoxarife Envia E-mail de advertência
Para o Comprador
- - -
Apêndice C - Requisitos do Estudo de Caso 91
“Como comprador pesquiso preços, prazo de entrega e qualidade do produto”.
Estruturação (Quadro C.7) e modelagem (Figura C.7) do conhecimento da sétima
estória do usuário:
Quadro C.7 – Tabela de protopapéis da sétima estória do estudo de caso.
Figura C.7 - Mapa conceitual da sétima estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem Onde Quando Quanto
1 Comprador Recebe Pedido do almoxarife
- No e-mail - -
2 Comprador Cadastra Preço do produto - No sistema
- -
3 Comprador Cadastra Prazo de entrega do produto
- No sistema
- -
4 Comprador Cadastra Qualidade do produto
- No sistema
- -
5 Comprador Pesquisa Preço do produto - No sistema
- -
6 Comprador Pesquisa Prazo de entrega do produto
- No sistema
- --
7 Comprador Pesquisa Qualidade do produto
- No sistema
- -
Apêndice C - Requisitos do Estudo de Caso 92
C.8 Oitavo Requisito do Estudo de Caso
Estória do usuário:
“Como almoxarife recebo os produtos, cadastro fornecedor com código, nome,
endereço, telefone e produtos.”
Estruturação (Quadro C.8) e modelagem (Figura C.8) do conhecimento da oitava
estória do usuário:
Quadro C.8 – Tabela de protopapéis da oitava estória do estudo de caso.
P
Proto-AG Proto-PAC
SNsuj
VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem
Onde Quando Quanto
1 Comprador Efetua Compra do produto com fornecedor
- - - -
2 Comprador Consulta Fornecedor - No sistema - -
3 Comprador Cadastra Fornecedor - No sistema - -
4 Fornecedor Tem Atributo código - No sistema - -
5 Fornecedor Tem Atributo nome - No sistema - -
6 Fornecedor Tem Atributo endereço - No sistema -
7 Fornecedor Tem Atributo telefone - No sistema - -
8 Fornecedor Tem Atributo produtos - No sistema - -
9 Almoxarife Recebe Produto - - - -
10 Almoxarife Confere Produto - - - -
Apêndice C - Requisitos do Estudo de Caso 93
Figura C.8 - Mapa conceitual da oitava estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
C.9 Nono Requisito do Estudo de Caso
Estória do usuário:
“Como almoxarife eu verifico se o produto recebido já está cadastrado. No caso de
existir, acrescento e atualizo a quantidade. Caso não tenha o produto cadastrado,
faço novo cadastro com o código, nome do produto, nome do fabricante, nome do
fornecedor, peso, localização dentro do estoque, prazo de garantia, limite de
quantidade mínima, data de recebimento do produto.”
Estruturação (Quadro C.9) e modelagem (Figura C.9) do conhecimento da nona
estória do usuário:
Apêndice C - Requisitos do Estudo de Caso 94
Quadro C.9 – Tabela de protopapéis da nona estória do estudo de caso.
P
Proto-AG Proto-PAC
SNsuj
VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem
Onde Quando Quanto
1 Almoxarife Consulta Cadastro do Produto - No sistema - -
2 Produto Tem Cadastro - No sistema - -
3 Almoxarife Atualiza Atributo quantidade de produto
- No sistema - -
4 Produto Não tem Cadastro - No sistema - -
5 Almoxarife Cadastra Produto - No sistema - -
6 Produto Tem Atributo código - No sistema - -
7 Produto Tem Atributo nome - No sistema - -
8 Produto Tem Atributo nome do fabricante
- No sistema - -
9 Produto Tem Atributo nome fornecedor
- No sistema - -
10 Produto Tem Atributo peso - No sistema - -
11 Produto Tem Atributo localização no estoque
- No sistema - -
12 Produto Tem Atributo prazo de garantia
- No sistema - -
13 Produto Tem Atributo quantidade mínima
- No sistema - -
14 Produto Tem Atributo data de recebimento
- No sistema - -
15 Produto Tem Atributo quantidade - No sistema - -
Apêndice C - Requisitos do Estudo de Caso 95
Figura C.9 - Mapa conceitual da nona estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
C.10 Décimo Requisito do Estudo de Caso
Estória do usuário:
“Como almoxarife preciso gerar um relatório mensal de controle de produtos, com os
produtos solicitados no mês com o código, quantidade, data e departamento
responsável.”
Apêndice C - Requisitos do Estudo de Caso 96
Estruturação (Quadro C.10) e modelagem (Figura C.10) do conhecimento da décima
estória do usuário:
Quadro C.10 – Tabela de protopapéis da décima estória do estudo de caso.
Figura C.10 - Mapa conceitual da décima estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual Para quem Onde Quando Quanto
1 Almoxarife Consulta Produto solicitado - No sistema No mês -
2 Almoxarife Gera Relatório Comprador No sistema No mês -
3 Relatório Tem Atributo código do produto
- No sistema - -
4 Relatório Tem Atributo quantidade do produto
- No sistema - -
5 Relatório Tem Atributo data de solicitação do produto
- No sistema - -
6 Relatório Tem
Atributo departamento responsável de solicitação do produto
- No sistema - -
Apêndice C - Requisitos do Estudo de Caso 97
C.11 Décimo Primeiro Requisito do Estudo de Caso
Estória do usuário:
“Como almoxarife devo enviar os relatórios gerados via e-mail.”
Estruturação (Quadro C.11) e modelagem (Figura C.11) do conhecimento da décima
primeira estória do usuário:
Quadro C.11 – Tabela de protopapéis da décima primeira estória do estudo de caso.
Figura C.11 - Mapa conceitual da décima primeira estória do estudo de caso.
Fonte: Elaborado pela autora (2017).
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê/ Qual
Para quem Onde Quando Quanto
1 Almoxarife Envia Relatório Comprador No e-mail - -
Apêndice C - Requisitos do Estudo de Caso 98
C.12 Visão Geral dos Requisitos
Quadro C.12 – Tabela de protopapéis da junção dos requisitos.
P
Proto-AG Proto-PAC
SNsuj VS
V Compl. Compl. Compl. Compl. Compl.
Quem O quê?/ Qual? Para quem Onde Quando Quanto
1 Administrador do sistema
Controla Acesso de funcionário
- No sistema - -
2 Funcionário Pode ser Almoxarife - - - -
3 Funcionário Pode ser Comprador - - - -
4 Funcionário Pode ser Técnico - - - -
5 Técnico Consulta Produto - No sistema - -
6 Técnico Envia Pedido do produto
Para o almoxarife
No e-mail - -
7 Almoxarife Recebe Pedido do produto
- No e-mail - -
8 Almoxarife Consulta Cadastro do produto
- No sistema - -
9 Produto Consta - - No estoque - -
10 Almoxarife Entrega Produto Ao Técnico - - -
11 Almoxarife Atualiza Cadastro do produto
- No sistema - -
12 Almoxarife Registra Pedido do produto
- No sistema - -
13 Produto Não consta
- - No estoque - -
14 Produto Entra - - Na quantidade mínima do estoque
- -
15 Almoxarife Envia E-mail Para o Comprador
- - -
16 Comprador Efetua Compra do produto com fornecedor
- - - -
17 Comprador Pesquisa Compra do produto
- No sistema - -
18 Comprador Cadastra Compra do produto
- No sistema - -
19 Comprador Consulta Fornecedor do produto
- No sistema - -
20 Comprador Cadastra Fornecedor do produto
- No sistema - -
21 Almoxarife Recebe Produto - - - -
22 Almoxarife Consulta Cadastro do Produto
- No sistema - -
23 Produto Tem Cadastro - No sistema - -
24 Almoxarife Atualiza Cadastro do produto
- No sistema - -
25 Produto Não tem Cadastro - No sistema - -
26 Almoxarife Cadastra Produto - No sistema - -
27 Almoxarife Gera Relatório de pedido
Para o Comprador
No sistema -
Apêndice C - Requisitos do Estudo de Caso 99
Figura C.12 – Visão geral dos requisitos.
Fonte: Elaborado pela autora (2017)
100
Apêndice D
DIAGRAMA PRISMA
101
Apêndice E
TERMO DE CONSENTIMENTO LIVRE E
ESCLARECIDO
TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO
ESTRATÉGIA PARA O GERENCIAMENTO DE RISCOS NOS REQUISITOS EM UM AMBIENTE XP DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE
Glaucia Schnoeller dos Santos Número do CAAE: 55040316.9.0000.5404
Você está sendo convidado a participar como voluntário de uma pesquisa.
Este documento, chamado Termo de Consentimento Livre e Esclarecido, visa
assegurar seus direitos como participante e é elaborado em duas vias, uma que
deverá ficar com você e outra com o pesquisador.
Por favor, leia com atenção e calma, aproveitando para esclarecer suas
dúvidas. Se houver perguntas antes ou mesmo depois de assiná-lo, você poderá
esclarecê-las com o pesquisador. Se preferir, pode levar este Termo para casa e
consultar seus familiares ou outras pessoas antes de decidir participar. Não haverá
nenhum tipo de penalização ou prejuízo se você não aceitar participar ou retirar sua
autorização em qualquer momento.
Justificativa e objetivos:
A pesquisa tem como objetivo avaliar como o processo de aquisição de
conhecimento auxilia na mitigação de riscos de ausência de informação e de falta de
Rubrica do pesquisador:_____________ Rubrica do participante:______________
Versão: março-2016 Página 1 de 4
Apêndice E - Termo de Consentimento Livre e Esclarecido 102
clareza nos requisitos com a metodologia ágil XP em um ambiente de
desenvolvimento distribuído de software.
Procedimentos:
Participando do estudo você está sendo convidado a: Participar de um estudo
de caso, que consiste no desenvolvimento de um sistema, o qual será doado para
uma empresa. O desenvolvimento irá adotar as práticas da metodologia ágil Extreme
Programming (XP) e o desenvolvimento distribuído de software (DDS). O projeto de
desenvolvimento do sistema terá a duração de um mês e será realizado online. O
estudo de caso tem como objetivo apresentar aos desenvolvedores uma estratégia
para o gerenciamento de riscos nos requisitos em um ambiente distribuído e ágil.
Para a avaliação do processo, serão aplicados dois questionários aos voluntários, os
quais serão disponibilizados em um formulário online.
Desconfortos e riscos:
Não há riscos previsíveis. O desenvolvimento e a coleta de dados serão
realizados online, assim não irá trazer desconfortos para os voluntários, pois não irá
interferir em suas atividades de rotina.
Benefícios:
O estudo contribuíra aos voluntários com novos conhecimentos e a prática da
metodologia XP e o DDS, modelos de desenvolvimento que são muito utilizados no
mercado de desenvolvimento de sistemas, por apresentar agilidade e economia de
custos para projetos. Em consequência, o estudo auxiliará aos desenvolvedores a
gerenciar os riscos na engenharia de requisitos em um projeto distribuído e ágil.
Acompanhamento e assistência:
O estudo de caso será acompanhado pela pesquisadora do estudo, a qual
gerenciará o projeto de desenvolvimento de sistemas por acesso remoto.
Rubrica do pesquisador:_____________ Rubrica do participante:______________
Versão: março-2016 Página 2 de 4
Apêndice E - Termo de Consentimento Livre e Esclarecido 103
Sigilo e privacidade:
Você tem a garantia de que sua identidade será mantida em sigilo e nenhuma
informação será dada a outras pessoas que não façam parte da equipe de
pesquisadores. Na divulgação dos resultados desse estudo, seu nome não será
citado.
Ressarcimento e Indenização:
Em caso de dano decorrente da pesquisa, está garantida a assistência
integral e imediata, de forma gratuita, pelo tempo que for necessário. Você também
tem direito a indenização em caso de danos.
Contato:
Em caso de dúvidas sobre a pesquisa, você poderá entrar em contato com a
pesquisadora Glaucia Schnoeller dos Santos, por meio do endereço da Faculdade
de Tecnologia da Unicamp: R. Paschoal Marmo, 1888 - Jd. Nova Itália - CEP 13484-
332 - Limeira, SP - Departamento de Pós-Graduação.
Em caso de denúncias ou reclamações sobre sua participação e sobre questões
éticas do estudo, você poderá entrar em contato com a secretaria do Comitê de
Ética em Pesquisa (CEP) da UNICAMP das 08:30hs às 11:30hs e das 13:00hs as
17:00hs na Rua: Tessália Vieira de Camargo, 126; CEP 13083-887 Campinas – SP;
telefone (19) 3521-8936 ou (19) 3521-7187; e-mail: cep@fcm.unicamp.br.
O Comitê de Ética em Pesquisa (CEP).
O papel do CEP é avaliar e acompanhar os aspectos éticos de todas as
pesquisas envolvendo seres humanos. A Comissão Nacional de Ética em Pesquisa
(CONEP), tem por objetivo desenvolver a regulamentação sobre proteção dos seres
humanos envolvidos nas pesquisas. Desempenha um papel coordenador da rede de
Comitês de Ética em Pesquisa (CEPs) das instituições, além de assumir a função de
órgão consultor na área de ética em pesquisas.
Rubrica do pesquisador:_____________ Rubrica do participante:______________
Versão: março-2016 Página 3 de 4
Apêndice E - Termo de Consentimento Livre e Esclarecido 104
Consentimento livre e esclarecido:
Declaro que sou maior de 18 anos e que participarei por livre vontade do projeto
de pesquisa conduzido pela pesquisadora Glaucia Schnoeller dos Santos, vinculada
à instituição de ensino Faculdade de Tecnologia/UNICAMP. Após ter recebido
esclarecimentos sobre a natureza da pesquisa, seus objetivos, métodos, benefícios
previstos, potenciais riscos e o incômodo que esta possa acarretar, aceito participar
e declaro estar recebendo uma via original deste documento assinada pelo
pesquisador e por mim, tendo todas as folhas por nós rubricadas:
Nome do (a) participante:
___________________________________________________________________
Contato telefônico:
___________________________________________________________________
E-mail (opcional):
___________________________________________________________________
_____________________________________________ Data: ____/_____/______.
(Assinatura do participante ou nome e assinatura do seu RESPONSÁVEL LEGAL)
Responsabilidade do Pesquisador:
Asseguro ter cumprido as exigências da resolução 466/2012 CNS/MS e
complementares na elaboração do protocolo e na obtenção deste Termo de
Consentimento Livre e Esclarecido. Asseguro, também, ter explicado e fornecido
uma via deste documento ao participante. Informo que o estudo foi aprovado pelo
CEP perante o qual o projeto foi apresentado. Comprometo-me a utilizar o material e
os dados obtidos nesta pesquisa exclusivamente para as finalidades previstas neste
documento ou conforme o consentimento dado pelo participante.
_______________________________________________Data:____/_____/______.
(Assinatura do pesquisador)
Rubrica do pesquisador:_____________ Rubrica do participante:______________
Versão: março-2016 Página 4 de 4
105
Anexo A
PARECER CONSUBSTANCIADO DO CEP
Anexo A - Parecer Consubstanciado do CEP 106
Anexo A - Parecer Consubstanciado do CEP 107
Anexo A - Parecer Consubstanciado do CEP 108
Anexo A - Parecer Consubstanciado do CEP 109
Anexo A - Parecer Consubstanciado do CEP 110
Recommended