uma estratÉgia baseada em aquisiÇÃo do...

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




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




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


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


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


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;


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.


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


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.


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.


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


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>”


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).


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).


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.


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


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.


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


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



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


(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.


Figura 4 - Mapeamento dos riscos no planejamento da XP no DDS.


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.


Figura 5 - Mapeamento dos riscos no design da XP no DDS.


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.


Figura 6 - Mapeamento dos riscos na codificação da XP no DDS.


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.



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


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


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


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


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/


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.


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


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 - -


Consulta Funcionário - No sistema - -


Altera Funcionário - No 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 - - - -


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


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.




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/


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).


Figura 10 - Mural de cartões de estórias.


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.


Figura 11 - Novo cartão de estória.



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.



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.


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


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


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


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


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.


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


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”


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


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”


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-


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.


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.


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.


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


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


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


Quem O quê/ Qual

Para quem

Onde Quando Quanto


Cadastra Funcionário - No sistema - -


Consulta Funcionário - No sistema - -


Altera Funcionário - No 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 - - - -



- No sistema - -

Figura C.1 - Mapa conceitual da primeira estória do estudo de caso.



C.2 Segundo Requisito do Estudo de Caso


“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


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.


C.3 Terceiro Requisito do Estudo de Caso


“Como almoxarife recebo requisição de peças.“

Estruturação (Quadro C.3) e modelagem (Figura C.3) do conhecimento da terceira


P

Proto-AG Proto-PAC

SNsuj VS


Quem O quê/ Qual

Para quem Onde Quando Quanto

1 Almoxarife Acessa Sistema - - - -

2 Comprador Acessa Sistema - - - -


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.


C.4 Quarto Requisito do Estudo de Caso


P

Proto-AG Proto-PAC

SNsuj VS



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 - - - -


“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


Quadro C.4 – Tabela de protopapéis da quarta estória do estudo de caso.

P

Proto-AG Proto-PAC

SNsuj

VS


Quem O quê/ Qual


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 - -


Figura C.4 - Mapa conceitual da quarta estória do estudo de caso.


C.5 Quinto Requisito do Estudo de Caso


“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



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.


C.6 Sexto Requisito do Estudo de Caso


“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



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

- - - -


Estruturação (Quadro C.6) e modelagem (Figura C.6) do conhecimento da sexta


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.


C.7 Sétimo Requisito do Estudo de Caso


P

Proto-AG Proto-PAC

SNsuj VS



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

- - -


“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


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.


P

Proto-AG Proto-PAC

SNsuj VS



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

- -


C.8 Oitavo Requisito do Estudo de Caso


“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


Quadro C.8 – Tabela de protopapéis da oitava estória do estudo de caso.

P

Proto-AG Proto-PAC

SNsuj

VS


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 - - - -


Figura C.8 - Mapa conceitual da oitava estória do estudo de caso.


C.9 Nono Requisito do Estudo de Caso


“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



Quadro C.9 – Tabela de protopapéis da nona estória do estudo de caso.

P

Proto-AG Proto-PAC

SNsuj

VS


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 - -


Figura C.9 - Mapa conceitual da nona estória do estudo de caso.


C.10 Décimo Requisito do Estudo de Caso


“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.”


Estruturação (Quadro C.10) e modelagem (Figura C.10) do conhecimento da décima


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.


P

Proto-AG Proto-PAC

SNsuj VS



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 - -


C.11 Décimo Primeiro Requisito do Estudo de Caso


“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.


P

Proto-AG Proto-PAC

SNsuj VS


Quem O quê/ Qual


1 Almoxarife Envia Relatório Comprador No e-mail - -


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


Quem O quê?/ Qual? Para quem Onde Quando Quanto



- 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 -


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


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.




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: [email protected].

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.




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)



105

Anexo A

PARECER CONSUBSTANCIADO DO CEP

Anexo A - Parecer Consubstanciado do CEP 106

uma estratÉgia baseada em aquisiÇÃo do...

Documents