7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
1/165
Universidade Federal de Pernambuco
Centro de Informtica
Ps-graduao em Cincia da Computao
Proposta de Processo de Documentao e
Validao dos Requisitos para Equipes de
Desenvolvimento Distribudo de Software
Leonardo Melo de Medeiros
DISSERTAO DE MESTRADO
Recife
29 de agosto de 2007
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
2/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
3/165
Universidade Federal de Pernambuco
Centro de Informtica
Leonardo Melo de Medeiros
Proposta de Processo de Documentao e Validao dos
Requisitos para Equipes de Desenvolvimento Distribudo deSoftware
Trabalho apresentado ao Programa de Ps-graduao em
Cincia da Computao do Centro de Informtica da Uni-
versidade Federal de Pernambuco como requisito parcial
para obteno do grau de Mestre em Cincia da Computa-
o.
Orientador: Alex Sandro Gomes
Co-orientador: Alexandre Vasconcelos
Recife
29 de agosto de 2007
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
4/165
Medeiros, Leonardo Melo deProposta de Processo de Documentao e
Validao dos Requisitos para Equipes deDesenvolvimento Distribudo de Software /Leonardo Melo de Medeiros. Recife: O autor ,2007.
xxiii , 138 folhas: il., fig., tab., quadros, grf.
Dissertao (mestrado) Universidade Federalde Pernambuco. CIN. Cincia da Computao,2007.
Inclui bibliografia, glossrio e apndices.
1. Documentao de Software. 2.Desenvolvimento Distribudo de Software. 3.Engenharia de Requisi tos. 4. Processo deEngenharia de Requisitos. I.Ttulo.
005.3 CDD (22.ed.) MEI2007-064
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
5/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
6/165
Dedico este trabalho minha av Lanuza Ubirajara de
Medeiros, que faleceu durante esse perodo e tanto fez por
seus filhos e netos. Dedico tambm a todos os meus tios e
avs que ficaram em guas Belas nesse natal e que no
pude v-los.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
7/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
8/165
Agradecimentos
A Deus que apesar de nossas desavenas nunca me fez sair do caminho me amparando nos
momentos mais difceis.
A minha famlia, por ter me dado apoiado durante toda minha formao, sou eternamente
grato pelo esforo que meus pais fizeram para que eu pudesse conquistar meus objetivos.Ao meu orientador, Professor Alex Sandro Gomes, pelos ensinamentos fornecidos para que
eu pudesse me tornar um pesquisador. Me apoiando na concluso deste trabalho.
Ao meu co-orientador, Professor Alexandre Vasconcelos, pelo apoio dado na rea de Enge-
nharia de Software.
Aos professores Jaelson Castro e Jones Albuquerque que atravs da participao em suas
disciplinas me auxiliaram na proposio deste trabalho.
Aos avaliadores Maria de Ftima Vieira e Carina Alves que se despuseram a avaliar este
trabalho.
Aos amigos Gustavo Cabral, Magno Maciel e Rafael Fonseca que me auxiliaram durante
as disciplinas do mestrado.
A Fbio Caparica, Almir Moura aos amigos de Petrolina e todos os integrantes do projeto
Amadeus que pelas discusses ocorridas durante esse trabalho incentivaram e motivaram a
realizao deste estudo de caso.
A todos professores e funcionrios do Centro de Informtica, pelo conhecimento e apoio
demonstrados durante o mestrado.
Enfim, a todos os que, direta ou indiretamente, contriburam para a realizao deste traba-
lho.
vii
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
9/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
10/165
How many roads must a man walk down
Before you call him a man?
Yes, n how many seas must a white dove sail
Before she sleeps in the sand?Yes, n how many times must the cannon balls fly
Before theyre forever banned?
The answer, my friend, is blowin in the wind,
The answer is blowin in the wind.
BOB DYLAN (Blowin in the Wind)
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
11/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
12/165
Resumo
A pesquisa em desenvolvimento distribudo de software est num momento relevante e opor-
tuno. Devido a necessidade industrial em distribuir o desenvolvimento do software em diver-
sas localidades, formando equipes distribudas de desenvolvimento. Essa forma distribuda de
desenvolvimento trs preocupaes nos aspectos culturais, operacionais e tcnicos do desen-volvimento de software quando realizado por equipes distribudas. Dentro desse contexto, as
atividades de documentao e validao de requisitos so necessrias para assegurar que estes
estejam completos e corretos. Contudo, a distncia entre os participantes impacta na produ-
tividade desse processo dificultando a obteno da congruncia e consenso nos requisitos por
parte das equipes distribudas.
Estudos indicam que o processo de validao de requisitos por parte dos stakeholders neces-
sita estar bem estruturado para ocorrer de forma efetiva em ambientes distribudos de desenvol-
vimento, pois as revises consomem bastante tempo mesmo quando realizadas presencialmente
atravs de comunicao face a face.
Nesta pesquisa realizamos um estudo de caso com uma abordagem exploratria num pro-
jeto de desenvolvimento de software. O caso analisado ocorreu dentro das atividades do pro-
jeto Agentes Micromundo e Anlise do Desenvolvimento no Uso de Instrumentos Multimdia
(AMADeUs-MM) que um projeto de pesquisa desenvolvido por vrias instituies. Devido
distribuio geogrfica de seus integrantes, esse projeto serviu como estudo de caso para iden-
tificar qual a estrutura das prticas relacionados validao e documentao dos requisitos de
uma equipe de desenvolvimento distribudo de software.
A partir da anlise do estudo de caso, propomos um processo de Engenharia de Requisitosadequado s necessidades existentes no desenvolvimento distribudo de software dentro do
grupo estudado.
Palavras-chave: Desenvolvimento Distribudo de Software, Engenharia de Requisitos, Pro-
cesso de Engenharia de Requisitos
xi
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
13/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
14/165
Abstract
The distributed development software subject is timely and relevant. Almost all of todays large
software development projects need to pay serious attention to cultural, operational and techni-
cal aspects when dealing with distributed development teams. In this context the requirements
documentation and validation activities are necessary to ensure that requirements are consis-tent. Therefore, the distance of the participants impacts on the productivity of this process,
dificulting the consense of distributed teams regarding the requirements.
Studies indicate thate requirements validation performed by distributed teams is a challen-
ging activity. This happens because the local revisions realized in person takes a lot of time
when realized by colocated teams.
In this research we conducted a case study with an exploratory approach in a software
development project. This case occurred in the activities of the Agentes Micromundo e Anlise
do Desenvolvimento no uso de Instrumentos Multimdia (AMADeUs-MM), a research project
developed by many institutions. Because of the geographical distribution of participants, this
project was used as a case study to identify the practices of the software distributed team,
related with the requirements documentation and validation activities.
According to the analysis of this case study, we propose a requirements engineering process
adjusted to existing necessities in the distributed software development on the observed group.
Keywords: Distributed Software Development, Requirements Engineering, Requirements
Engineering Process
xiii
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
15/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
16/165
Sumrio
1 Introduo 1
1.1 Motivao 2
1.2 Problema da Pesquisa 4
1.2.1 Contribuio 4
1.3 Organizao da Dissertao 5
2 Engenharia de Requisitos no Desenvolvimento Distribudo 7
2.1 Desenvolvimento Distribudo de Software 7
2.1.1 Desafios do Desenvolvimento Distribudo de software 7
2.1.1.1 Comunicao 8
2.1.1.2 Integrao 9
2.1.1.3 Coordenao 92.2 Engenharia de Requisitos 10
2.3 Processo de Engenharia de Requisitos Baseado em DDS 11
2.3.1 Elicitao de Requisitos 12
2.3.2 Documentao de Requisitos 13
2.3.3 Validao de Requisitos 13
2.3.3.1 Inspeo de Requisitos 14
2.3.4 Prototipagem Durante a Engenharia de Requisitos 16
2.4 Trabalhos Relacionados 182.4.1 Processo de Requisitos alinhado com o CMM 18
2.4.1.1 Etapas do Processo 18
2.4.1.2 Concluses 20
2.4.2 MuNDDoSS - Um Modelo de Referncia para o Desenvolvimento Dis-
tribudo de Software 20
2.4.2.1 Concluses 21
2.4.3 Suporte Engenharia de Requisitos no Desenvolvimento Distribudo
de Software 21
xv
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
17/165
xvi SUMRIO
2.4.3.1 Concluses 23
2.4.4 Efetividade das Tcnicas de Elicitao dos Requisitos na Engenharia
de Requisitos Distribuda 232.4.4.1 Concluses 24
2.4.5 Impacto dos Stakeholders Geograficamente Distribudos na Gerncia
de Requisitos em organizaes Multi-Site 25
2.4.5.1 Concluses 29
3 Metodologia de Pesquisa 31
3.1 Introduco 31
3.2 Objetivos 32
3.2.1 Geral 32
3.2.2 Especficos 32
3.3 Procedimentos 32
3.4 Entrevista Semi-Estruturada Exploratria (1) 33
3.4.0.1 Perfil dos participantes 33
3.4.0.2 Entrevista com gerentes de projeto de software oriundos de
pesquisa 33
3.5 Estudo de Caso - Etapa 1 (2) 34
3.5.0.3 Unidade de Anlise do Estudo de Caso 35
3.6 Anlise dos Resultados - Elaborao (3) 35
3.6.1 Anlise Qualitativa Assistida por Computador 35
3.6.2 Coleta de dados 36
3.6.2.1 Arquivamento de correios-eletrnicos 36
3.6.2.2 Logs de Ferramenta de Instant Messaging 36
3.6.2.3 Atas de Reunio Presencial 36
3.6.2.4 Gravao em udio das Reunies de Validao dos Requisitos 37
3.6.3 Instrumento de Anlise dos Dados 373.7 Proposta de um processo (4) 38
3.7.1 Seleo de Ferramentas que Dem Suporte ao Processo Proposto 38
4 Anlise da Entrevista Semi-Estruturada 39
4.1 Entrevista Semi-Estruturada 39
4.1.1 Participantes da Entrevista Semi-Estruturada 39
4.1.1.1 Projeto 1 40
4.1.1.2 Projeto 2 41
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
18/165
SUMRIO xvii
4.1.1.3 Projeto 3 42
4.2 Anlise das Entrevistas 43
4.2.1 Processo de Desenvolvimento de Software 44
4.2.2 Processo de Engenharia de Requisitos 44
4.2.2.1 Elicitao dos Requisitos 45
4.2.2.2 Documentao dos Requisitos 46
4.2.2.3 Validao dos Requisitos 48
4.3 Requisitos Extrados da Entrevista Semi-estruturada com os Gerentes de Pro-
jeto (F2) 48
5 Estudo de Caso 515.1 Descrio do Estudo de Caso 51
5.2 Ambiente de Desenvolvimento 53
5.3 Participantes do Estudo de Caso 53
5.4 Categorizao dos Dados 54
5.5 Prticas de Comunicao do Projeto 54
5.5.1 Skype 55
5.5.2 Microsoft Messenger 56
5.5.3 Correio-Eletrnico 575.5.4 Lista de Correio-Eletrnico 58
5.6 Ferramentas Colaborativas de Edio Observadas no Estudo de Caso 59
5.6.1 Groove Virtual Office 59
5.6.2 Writely 62
5.7 Fases Observadas da Engenharia de Requisitos no Estudo de Caso 62
5.7.1 Elicitao de Requisitos 63
5.7.1.1 Prottipo em Papel 63
5.7.2 Negociao dos Requisitos 645.7.3 Artefatos de Entrada para a Documentao e Validao dos Requisitos 64
5.7.3.1 Observao 1: Sem o uso de Storyboard como Artefato de
Entrada 65
5.7.3.2 Observao 2: Com o uso de Storyboard como artefato de
entrada 67
5.7.4 Documentao de Requisitos 69
5.7.4.1 Seleo da Ferramenta de Edio dos Artefatos 69
5.7.4.2 Apresentao do Storyboard 70
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
19/165
xviii SUMRIO
5.7.4.3 Acompanhamento da Documentao 71
5.7.5 Validao dos Requisitos 72
5.7.5.1 Planejamento da Inspeo 72
5.7.5.2 Distribuir Documento 74
5.7.5.3 Preparar para Inspeo - Inspeo Assncrona 75
5.7.5.4 Reunio de Inspeo - Audio-Conferncia 78
5.7.5.5 Correes da Reviso 83
5.7.5.6 Revisar o documento 84
5.8 Requisitos Relacionados Ao Estudo de Caso 85
6 Processo Proposto 896.1 Descrio do Processo 90
6.2 Iterao: Elicitao de Requisitos 90
6.2.1 Obteno dos Requisitos Iniciais do Sistema 91
6.2.2 Elicitao em Grupo 92
6.2.3 Documentao dos Requisitos Iniciais do Sistema 94
6.2.4 Desenvolvimento do Storyboard 94
6.2.5 Reviso da Elicitao 95
6.2.5.1 Passos para Execuo 966.2.6 Retrabalho Reviso de Elicitao 97
6.2.6.1 Passos para Execuo 98
6.3 Iterao: Documentao de Requisitos 98
6.3.1 Apresentar Storyboard 99
6.3.1.1 Passos para Execuo 100
6.3.2 Detalhamento dos Casos de Uso 101
6.3.2.1 Passos para Execuo 102
6.3.3 Acompanhamento da Documentao 1026.3.3.1 Alternativas 103
6.4 Iterao: Validao dos Requisitos 104
6.4.1 Planejamento de Inspeo 104
6.4.2 Distribuio do Documento 105
6.4.2.1 Passos para Execuo 106
6.4.3 Preparao: Inspeo Assncrona 106
6.4.3.1 Passos para Execuo 107
6.4.4 Reunio de Inspeo 107
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
20/165
SUMRIO xix
6.4.4.1 Passos para Execuo 108
6.4.5 Correo da Inspeo 109
6.4.5.1 Passos para Execuo 1096.4.6 Validao 110
6.4.6.1 Passos para Execuo 110
6.5 Papis e Responsabilidades 111
6.5.1 Engenheiro de Requisitos 111
6.5.2 Designer de Interface 112
6.5.3 Engenheiro de Software 112
6.5.4 Gerente de Projeto 113
6.5.5 Stakeholder 1136.5.6 Coordenador de Revises 114
6.5.7 Revisor Tcnico 115
6.6 Artefatos do Processo 115
6.6.1 Base formal de conhecimento do problema 116
6.6.1.1 Consideraes 116
6.6.2 Prottipo em Papel 116
6.6.3 Registro de Reviso 117
6.6.3.1 Passos para Execuo 1176.6.3.2 Formato do Artefato 118
6.6.4 Requisitos Iniciais 118
6.6.5 Requisitos do Sistema 118
6.6.5.1 Consideraes 119
6.6.6 Documento de Especificao dos Requisitos 119
6.6.6.1 Descrio dos Atores do Sistema 120
6.6.6.2 Descrio de Casos de Uso 121
6.6.6.3 Storyboard 121
7 Concluso 123
7.1 Trabalhos Futuros 124
A Entrevista Semi-Estruturada 125
A.1 Entrevista com Gerentes de Projeto 125
B Planilha de Coleta de Mtricas 127
C Glossrio 129
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
21/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
22/165
Lista de Figuras
1.1 Principais razes envolvidas no DDS [Pri03] 3
1.2 Demada por software x profissionais disponveis [DZ02] 4
2.1 Nveis de interao contextual [MH01] 9
2.2 Fases da Engenharia de Requisitos Baseado em [KS98] 11
2.3 Processo de Inspeo dos Requisitos Baseado em [KS98] 14
2.4 Processo para Engenharia de Requisitos Distribuda [Lop03] 18
2.5 Efetividade das Tcnicas de Elicitao dos Requisitos em DDS [Llo01] 24
2.6 Distribuio geogrfica do grupo de stakeholders [DZ02] 26
2.7 Fluxo de informao no projeto [DZ02] 27
2.8 Modelo de impacto dos desafios e atividades afetadas da Engenharia de Requi-
sitos devido a problemas com o DGS adaptado de Damian [DZ02] 29
3.1 Desenho da Pesquisa 32
5.1 Arquitetura do AMADeUs-MM [Sou05] 52
5.2 rvore de Categoria do NVivo [QSR07] 55
5.3 Prottipo em papel desenvolvido durante a elicitao em grupo 63
5.4 Storyboarddesenvolvido pelo designerde interface 64
5.5 Processo de Elicitao dos Requisitos sem Uso do Storyboard 65
5.6 Processo de Elicitao dos Requisitos com uso do storyboard 67
5.7 Permisses do Artefato: colaboradores e visualizadores [Goo] 755.8 Publicar Documento [Goo] 76
5.9 Inserir comentrio no artefato [Goo] 77
5.10 Comparar diferentes verses do artefato [Goo] 85
6.1 Estrutura Analtica do Processo de Desenvolvimento 91
6.2 Iterao: Elicitao dos Requisitos 92
6.3 Iterao: Documentao dos Requisitos 99
6.4 Iterao: Validao dos Requisitos 104
xxi
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
23/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
24/165
Lista de Tabelas
4.1 Projetos Pesquisados 40
4.2 Legenda dos Entrevistados 44
5.1 Participantes Estudo de Caso 54
5.2 Mtricas do DER do mdulo desenvolvido na UD1 de 12-01-2006 a 02-02-2006 665.3 Mtricas do DER do mdulo desenvolvido na UD1 de 13-02-2006 a 24-02-2006 68
xxiii
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
25/165
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
26/165
CAPTULO 1
Introduo
H uma dcada o nmero de empresas engajadas no desenvolvimento distribudo de software
era pequeno, mas esse cenrio foi modificado. No ano de 2000, 203 das 500 maiores empresas
americanas listadas pela US Fortune j utilizavam o offshore outsourcing [CA01], enviando
parte da pesquisa e desenvolvimento para outros pases.Existem alguns fatores que impulsionaram o desenvolvimento distribudo entre grandes
empresas de software, dentre eles: necessidade de utilizar recurso capacitado onde quer que
ele esteja; vantagens de estar prximo de diferentes mercados, conhecendo consumidores e
condies locais; formao rpida de organizaes virtuais e equipes virtuais para explorar
as oportunidades do mercado; necessidade de diminuir o tempo de entrega do produto para o
mercado, conseguido atravs de fusos horrios diferentes uma produo de 24 horas por dia
[Pri03].
No processo de desenvolvimento de software, a engenharia de requisitos, uma das fa-ses mais importantes, pois nesta etapa onde so definidas as funcionalidades e o escopo do
software a ser desenvolvido [Zow02]. Segundo um relatrio do CHAOS [Int01], publicado
pelo Standish Group [TSG05], os maiores problemas no desenvolvimento de software so re-
lacionados com requisitos. Tendo em vista que as especificaes dos requisitos serviro como
base para contratos e desenvolvimento do software em questo, ela deve ser clara e no amb-
gua [ABD+04]. Entretanto, cliente, analista e desenvolvedores freqentemente no possuem o
mesmo nvel tcnico de conhecimento e tendem a descrever e entender os requisitos de formas
diferentes [Byr94].
A Engenharia de Requisitos, a disciplina da engenharia de software que mais faz uso de
comunicao entre os envolvidos do projeto [NE00]. No Desenvolvimento Distribudo de Soft-
ware (DDS), as dificuldades encontradas de comunicao, coordenao e cultura aumentam os
problemas inerentes da Engenharia de Requisitos (ER) [DZO01]. Sendo assim, os problemas
causados por ambigidade e falta de entendimento nos requisitos so intensificados [Lop03].
Segundo o SWEBOK, o desenvolvimento de prottipos muito utilizado para a validao
dos requisitos do software em geral [ABD+04]. Visando melhorar o entendimento dos requi-
sitos por parte das Unidades Distribudas de Desenvolvimento (UDS) e diminuir a duplicidade
1
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
27/165
2 CAPTULO 1 INTRODUO
dos requisitos gerados por eles, ser proposto um processo de Engenharia de Requisitos que
melhore a documentao e validao dos requisitos no DDS.
1.1 Motivao
Nas ltimas dcadas a globalizao dos negcios impactou tambm a indstria de tecnologia
da informao. As foras econmicas transformaram mercados nacionais em mercados globais
[HM01]. Essas transformaes no alteraram apenas o marketing da distribuio, mas tambm
as formas como os produtos so: criados, construdos, testados e liberados para os clientes
finais [ODJ94].O DDS por si s uma prtica de engenharia de software [HM01], analisando que na ltima
dcada a indstria de TI cresceu bastante rumo a globalizao, diversas empresas tm divi-
dido parte do desenvolvimento de software, criando unidades distribudas de desenvolvimento
[HM01]. Surgindo a uma grande demanda por servios de outsourcing e conseqentemente
um reaprendizado de como as atividades de Engenharia de Software (ES) so realizadas nesse
contexto.
Essa forma distribuda de desenvolvimento impacta profundamente em todo o processo de
desenvolvimento das organizaes, afetando diretamente os meios de comunicaes, coorde-nao e integrao das atividades no ambiente [CA01] [HM01].
Segundo Nuseibeh [NE00] um dos principais problemas existentes na ER de ordem social.
Pois estes no podem apenas serem repassados para mtodos tcnicos disponveis, alm disso
a relativa imaturidade nos campos da ER em DDS sugere abordagens bastante eclticas na
execuo dos processo de ER em DDS, na busca de tratar os problemas relativos a: distncia,
comunicao e coordenao [Zow02].
Diversos fatores tm contribudo para que as empresas distribuam seu processo de desen-
volvimento, dentre eles [Pri03] (Figura 1.1):1. A necessidade de aumentar os recursos quando a disponibilidade de mo de obra estiver
escassa.
2. Vantagens de negcio, relativo ao mercado local, incluindo conhecimento dos clientes e
das condies locais, alm de melhorar as condies locais atravs de investimentos.
3. A rpida formao de corporaes virtuais e times virtuais visando explorar as oportuni-
dades de mercado.
4. Presses relativas ao time-to-market, com o uso de diferente fuso-horrio , permitindo
inclusive o desenvolvimento 24x7 [Car98] follow-the-sun.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
28/165
1.1 MOTIVAO 3
Figura 1.1 Principais razes envolvidas no DDS [Pri03]
O mercado americano, responsvel por grande parte da demanda em software, teve esgo-
tadas suas cotas de vistos de trabalho temporrio para rea de tecnologia antes do trmino do
ano fiscal, gerando uma maior escassez por profissionais qualificados [Car98], logo sentiu a
necessidade de dividir parte do desenvolvimento com outras localidades. Em termos grficos
(Figura 1.2) percebe-se com bastante clareza que nos ltimos anos houve um acrscimo da
necessidade por profissionais capacitados. Sendo assim, buscando reduzir custos ao evitar o
deslocamento de funcionrios no momento de sua contratao. Muitas delas distriburam o
seu desenvolvimento criando unidades de desenvolvimento especializadas, reduzindo custos,quantidade de profissionais com a mesma especialidade e aumentando o nvel de experincia
dos mesmos com a execuo de atividades semelhantes [Lop03].
Em um estudo de caso foram identificados campos de estudo relevantes da ER em DDS
[DZO01]. Neste artigo, os autores informam que foram consumidos 18 meses na fase de nego-
ciao dos requisitos no estudo de caso pesquisado. Um dos fatores fundamentais dessa demora
foi a comunicao pobre entre os stakeholders mais relevantes.
0Indivduos ou organizaes que so os responsveis pelo sucesso do sistema. [NE00]
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
29/165
4 CAPTULO 1 INTRODUO
Figura 1.2 Demada por software x profissionais disponveis [DZ02]
1.2 Problema da Pesquisa
A questo que se formula nessa pesquisa, diante do quadro a motivao saber qual a estrutura
das prticas de uma equipe de desenvolvimento distribudo de software quanto aos processos
relacionados com a validao e documentao dos requisitos. A partir da resoluo desta per-gunta, pretende-se: "Propor um processo de documentao e validao dos requisitos para
ambientes de desenvolvimento distribudo de software a partir das prticas encontradas num
estudo de caso".
O caso analisado ocorreu dentro das atividades do projeto Agentes Micromundo e Anlise
do Desenvolvimento no uso de Instrumentos Multimdia (AMADeUs-MM) [Sou05]. Este pro-
jeto possui um total de 16 integrantes em duas UDS divididos em duas cidades com 800 km de
distncia. Devido s divergncias de horrios entre os integrantes, podemos classificar o ambi-
ente de desenvolvimento do estudo de caso como de Distncia Nacional e nveis de dispersoTemporal e Geogrfica conforme o modelo de referncia de Prikladnicki [PAE04]. Por conta
destas caractersticas esse projeto serviu como estudo de caso para a elaborao do processo de
Engenharia de Requisitos proposto neste trabalho.
1.2.1 Contribuio
O objetivo principal desta pesquisa a definio de um processo de Engenharia de Requisitos
para ambientes de desenvolvimento distribudo de software. Deseja-se que esse processo de
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
30/165
1.3 ORGANIZAO DA DISSERTAO 5
Engenharia de Requisitos, seja mais adequado possvel para a documentao e validao dos
requisitos em ambientes distribudos de desenvolvimento.
Para atingir nosso objetivo principal por intermdio de um estudo de caso [Yin05] chegamosa algumas contribuies intermedirias como :
Anlise do uso de prottipos de baixa fidelidade, como artefato de entrada para a docu-
mentao e validao dos requisitos em ambientes distribudos de desenvolvimento.
Os impactos existentes ao se tentar realizar a elicitao dos requisitos de forma distri-
buda.
Testamos o uso de ferramentas colaborativas no intuito de diminuir o impacto das distn-
cias geogrficas e temporais.
Anlise do uso de ferramentas de Voz Sobre IP (VoIP) para realizar as atividades de
validao dos requisitos dos requisitos em ambientes de DDS.
1.3 Organizao da Dissertao
Este documento est estruturado em 7 captulos. O presente captulo apresenta a motivao
desse trabalho, nosso problema de pesquisa visando elaborar um processo de engenharia derequisitos para desenvolvimento distribudo de software e por fim sua contribuio.
No Captulo 2 introduzimos a necessidade do uso de processo de engenharia de requisi-
tos no desenvolvimento de software, bem como a problemtica existente para a conduo do
mesmo em ambientes DDS. Nesse mesmo captulo selecionamos e descrevemos trabalhos re-
lacionados que contriburam para a concepo desse trabalho.
No Captulo 3, definida a metodologia de pesquisa realizada para a realizao desse traba-
lho. Nessa metodologia esto previstas a realizao de uma entrevista semi-estruturada [Fli04]
com gerentes de projeto que possuem alguma caracterstica de desenvolvimento distribudo deacordo com o modelo de referncia de Prikladnicki [Pri03]. Posteriormente foi realizada uma
observao participante [Fli04] em um estudo de caso [Yin05].
No Captulo 4, so apresentadas a anlise das entrevistas realizadas e no Captulo 5, so
apresentados os resultados da observao participante realizada no estudo de caso.
Como resultado dessa pesquisa foram gerados requisitos (Seo 4.3 e Seo 5.8) que da-
ro suporte a proposio do processo no Captulo 6. O processo de Engenharia de Requisitos
proposto neste trabalho e as ferramentas utilizadas para a sua execuo esto descritos no Ca-
ptulo 6.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
31/165
6 CAPTULO 1 INTRODUO
As concluses, limitaes identificadas e as sugestes de trabalhos futuros ficaram no Ca-
ptulo 7.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
32/165
CAPTULO 2
Engenharia de Requisitos no Desenvolvimento
Distribudo
Neste captulo iremos abordar a Engenharia de Requisitos, descrevendo os principais conceitos
existentes na rea e uma viso geral de processos de Engenharia de Requisitos. Logo aps, se-
ro explanados: conceitos e motivaes do desenvolvimento distribudo de software. Ao final
teremos uma descrio dos trabalhos relacionados de Engenharia de Requisitos no desenvolvi-
mento distribudo de software.
2.1 Desenvolvimento Distribudo de Software
H mais de uma dcada, visando diminuir custos e buscando recursos mais qualificados, muitas
organizaes comearam a experimentar o desenvolvimento distribudo de software [HM01].A partir da demanda da indstria o assunto passou a ser abordado em congressos internacionais
[ICoGSE06], alm do surgimento de grupos de pesquisa bastante expressivos na rea [MUN06]
[TSL06].
O DDS caracteriza-se pela distncia fsica e/ou temporal entre alguns stakeholders (cliente,
usurio e desenvolvedores, por exemplo) envolvidos no processo de desenvolvimento [Pri03].
No Brasil esse tema tende a ser mais explorado, devido a grande quantidade de empresas que
esto implantando unidades de desenvolvimento distribudo no pas.
2.1.1 Desafios do Desenvolvimento Distribudo de software
Nesta seo esto expostos os desafios encontrados na literatura no que se refere ao desenvol-
vimento de software quando realizado por equipes distribudas de desenvolvimento.
Baseado em um modelo estatstico, Herbsleb [HMFG01], demonstrou que o DDS leva
muito mais tempo de ser concludo do que o Desenvolvimento Centralizado de Software (DCS).
Segundo o autor problemas de comunicao e coordenao, so os principais responsveis por
esse atraso.
7
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
33/165
8 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
2.1.1.1 Comunicao
Com o crescimento do desenvolvimento distribudo de software os engenheiros, gerentes e exe-
cutivos tm se confrontado com profissionais de diferentes nveis: tcnicos, sociais e culturais
[HM01]. A resoluo dessas diferenas j bastante complicada localmente onde existe a
comunicao face a face, pois as diferenas de vocabulrio, termos tcnicos e formas de abor-
dagem social, dificultam a comunicao. Num ambiente distribudo de desenvolvimento esse
problema torna-se ainda maior, pois os meios de comunicao como: correio-eletrnico, chats
e ligaes telefnicas, no so to ricos quanto comunicao face a face [HM01] [DZ02]
Figura 2.1.
Na fase inicial do desenvolvimento de software, muita comunicao requerida, para o in-
cio das definies do projeto [PSV94]. Nesse contexto existem duas formas complementares
de comunicao, primeiramente, a formal, que a comunicao oficial que deve ser passada
com bastante clareza. Principalmente em tarefas cruciais como atualizao de status de projeto,
reorganizao, determinao de papis, etc. Uma comunicao confusa ou mal especificada,
poder levar a equipe a perder tempo e gerar problemas de coordenao no projeto [HM01].
Em segundo plano, a comunicao informal um excelente canal para reportagem de tarefas,
percepo de como andam as atividades perante o grupo. As "conversas de corredor", aju-dam as pessoas a terem percepo do andamento do projeto, facilitando o trabalho em grupo
e auxilia na resoluo de problemas tcnicos, melhorando a eficincia dos desenvolvedores
[DZ02]. A partir do momento que a comunicao for mais presente entre os membros, e as
ferramentas colaborativas possam prover comunicao informal sncrona haver um aumento
na percepo do grupo virtual. Comeando ento a construir importantes relaes de confiana
na comunicao remota [DZ02].
Contudo a escolha do meio de comunicao para a realizao de determinadas tarefas exigebastante cuidado. Por exemplo, um gerente de DDS deve, regularmente, transmitir a viso
de equipe para todos os grupos, de forma a contextualizar o time a respeito do andamento do
projeto. Esse meio de comunicao dever prover nveis altos de motivao e emoo [CA01].
Existem casos em que a comunicao sncrona pode ser menos apropriada do que a as-
sncrona. Como por exemplo numa ligao telefnica (sncrono) pode ocorrer problemas do
tipo "Eu j te disse isso", enquanto que num correio eletrnico (assncrono) o escrito histrico
servir como documentao do que fora relatado [CA01].
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
34/165
2.1 DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE 9
Figura 2.1 Nveis de interao contextual [MH01]
2.1.1.2 Integrao
Para integrar as equipes necessrio possuir um repositrio de artefatos do projeto contendo:
Documento de Especificao dos Requisitos (DER), bugs encontrados, processos e termos uti-
lizados. Esse repositrio deve ser mantido e compartilhado com rigor, pois diminui a distncia
entre as UDS, auxilia no entendimento dos requisitos, e aumenta a percepo do andamento do
projeto [DZ02].
Existem diversos estudos relacionados a ferramentas colaborativas de edio assncrona
[AG98] [Bri06] para a ER. Estas ferramentas tornam-se um repositrio para requisitos, permi-
tindo ainda o compartilhamento do DER com os demais stakeholders. Isso diminui a distncia
entra as UDS [DZ02].
2.1.1.3 Coordenao
No contexto de DDS necessrio que o processo de desenvolvimento do software seja nico,
bem definido e conhecido pelas equipes distribudas. A coordenao de um projeto sendo
executado com processos distintos pode ser mais complicada para o gerente de projeto [EF99].
Quando as equipes distribuem os processos em diversas localidades, a falta de sincronizao
pode se tornar crtica. Pois um nico processo bem definido e treinado fornece um conjunto
comum de expectativas aos elementos envolvidos, impondo rigor e disciplina equipe [CA01].
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
35/165
10 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
Para haver alinhamento no processo necessrio que haja rotina na comunicao pois a
falta dela poder gerar surpresas advindas de diferentes locais, resultando num desalinhamento
da equipe e ,conseqentemente, em retrabalho. Quando as equipes esto distribudas, o nvelde sincronizao torna-se particularmente crtico. Por exemplo, no caso em que um time est
desenvolvendo testes unitrios diferentemente do que est sendo desenvolvido. A sincronizao
nesse processo requer marcos bem definidos e critrios de entrada e sada bastante claros para
toda a equipe [RP95]. Herbleb [HM01] defende que os avanos das ferramentas colaborativas
agregada a multimdia venham melhorar o desenvolvimento distribudo de software.
Estudos indicam que uma especificao de requisitos mal redigida impacta diretamente nas
atividades a serem desenvolvidas de forma distribuda [HM01]. Apesar dos desenvolvedores
resistirem elaborao de documentao, ela se faz necessria para aumentar a congrunciada equipe. Portanto no desenvolvimento distribudo, a documentao dos artefatos, bem como
a sua atualizao e reviso por diferentes responsveis pelo software (Gerentes de Projeto,
Analista de Sistemas, Engenheiro de Usabilidade e Clientes) faz-se necessria.
2.2 Engenharia de Requisitos
Os requisitos definem quais sero os servios que o sistema dever prover alm de um conjuntode restries existentes na operao do sistema [KS98]. Para Nuseibeh [NE00] a Engenharia de
Requisitos o processo de descobrir o propsito do software, identificando os stakeholders com
suas respectivas necessidades e documentando a anlise realizada para uma implementao
subseqente.
O contexto em que a ER est centrada na atividade de entendimento do comportamento
humano [NE00], visando buscar solues para os problemas das pessoas. Assim, a ER usa
mecanismos de sensibilidade para entender como as pessoas percebem o mundo e como suas
aes interagem com a sociologia do ambiente [NE00].Geralmente os requisitos so escritos em linguagem natural, ento uma comunicao clara
extremamente importante para a especificao dos requisitos, pois evitam a ambigidade e
aumentam o entendimento dos mesmos [NE00]. Logo so necessrios um conjunto de tcnicas
empregadas para levantar, detalhar, documentar e validar os requisitos de um produto. O uso do
termo "Engenharia"implica que tcnicas sistemticas e repetidas devem ser aplicadas para cer-
tificar que os requisitos de um sistema estejam completos, consistentes e relevantes [Som04]. O
emprego correto da Engenharia de Requisitos um passo fundamental para o desenvolvimento
de um bom produto, onde a satisfao do usurio deve ser o principal objetivo a ser atingido
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
36/165
2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS 11
[Did03].
2.3 Processo de Engenharia de Requisitos Baseado em DDS
Uma completa compreenso dos requisitos de software fundamental para um desenvolvi-
mento de software bem sucedido. No importa quo bem projetado ou quo bem codificado
seja um programa, se ele for mal analisado e especificado dificilmente atender s expectativas
do usurio [Byr94].
Neste trabalho, detalharemos o processo1 de Engenharia de Requisitos, proposto por Ko-
tonya e Sommervile em [KS98], o qual descreve as atividades de: elicitao, anlise, docu-mentao e validao como sendo as etapas do processo de engenharia de requisitos, conforme
apresentado na Figura 2.2.
Figura 2.2 Fases da Engenharia de Requisitos Baseado em [KS98]
Sabemos que difcil definir um plano seqencial de atividades que descrevam adequada-
mente o processo de Engenharia de Requisitos [Zow02]. Para Carmel [CA01] fundamentalque o processo de desenvolvimento entre as equipes distribudas, seja um processo nico, pois
a falta de sincronizao das atividades pode se tornar crtica. Um processo define um conjunto
de atividades que devem ser conhecidas por todos os membros da equipe, impondo rigor na
equipe.
Por ser realizado em ambientes DDS importante identificar as diferenas entre os meios
de comunicao utilizado na execuo das atividades referentes ER. Por exemplo: O correio
eletrnico apesar de facilitar a comunicao entre os stakeholders, dificulta no gerenciamento
1Um processo um conjunto de atividades que transformam entradas em sadas.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
37/165
12 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
das discusses e essa forma assncrona de tomada de deciso pode demandar bastante tempo
para atingir o consenso [Zow02].
Para Zowghi [Zow02], os problemas existentes no DDS fazem com que seja necessrio
criar um processo especfico para a ER em DDS. Herbsleb, por sua vez, sugere uma soluo
de processo concorrente de desenvolvimento de software nesse contexto, porm segundo ele a
aplicao e implantao dos princpios de engenharia concorrente em ambientes de desenvol-
vimento distribudo se tornam difceis, com requisitos instveis ou volteis [HM01]. Herbsleb
defende tambm que boas ferramentas colaborativas podem auxiliar na estabilidade dos requi-
sitos havendo uma diminuio do tempo e espao entre as equipes distribudas [HM01].
O resultado principal de todo esse processo de engenharia de requisitos a produo de umDER, que o principal artefato produzido pela Engenharia de Requisitos. Ele deve descrever
de forma clara e precisa cada um dos requisitos do software juntamente com suas interfaces ex-
ternas. Um DER, em geral, serve como base para acordos formais entre clientes e fornecedores,
com relao ao que o software dever prover [HP00].
2.3.1 Elicitao de Requisitos
A elicitao dos requisitos consiste em saber a origem dos requisitos e como o analista de
sistemas poder colet-los. Elicitao de requisitos uma das atividades mais importantes na
ER, sendo o primeiro passo na captura dos requisitos.
Durante a coleta necessrio que sejam elaboradas as perguntas corretas, buscando en-
contrar os problemas a serem solucionados [NE00]. Num primeiro momento, construdo o
entendimento do problema que o software pretende resolver. Para a captura, descobrimento e
aquisio dos requisitos fundamental a existncia e interao entre stakeholders, equipe de
desenvolvimento e clientes [ABD+04].
sabido que o conhecimento adquirido durante a elicitao dos requisitos tende a ser mais
profundo que o conhecimento contido no DER [Lop03]. Portanto, no surgimento de dvidas
relativas ao DER ocorre num grande volume de comunicao informal entre os integrantes.
Atravs das tcnicas de elicitao em grupo obtm-se um maior entendimento e acordo dos
requisitos elicitados. Nessas tcnicas esto inclusas: brainstorming, grupo-focal assim como
workshops [NE00]. A partir dessas constataes a documentao dos requisitos por uma equipe
distribuda a qual no participou das sesses de elicitao torna-se um desafio.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
38/165
2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS 13
2.3.2 Documentao de Requisitos
O documento de requisitos de software - s vezes chamado de DER ou especificao de re-quisitos de software - a declarao oficial do que exigido dos desenvolvedores do sistema.
Ele deve incluir os requisitos para o cliente e/ou usurio e uma descrio detalhada dos requi-
sitos do sistema. Em alguns casos, eles so integrados em uma nica descrio [Som04]. Para
clientes, desenvolvedores e demais envolvidos no desenvolvimento do software um DER bem
especificado deve prover os seguintes benefcios [Byr94]:
1. Estabelecer a concordncia no que o software se prope a fazer perante clientes e demais
envolvidos no desenvolvimento do software.
2. Reduzir o esforo de desenvolvimento;
3. Subsdios para estimar custo e prazo;
4. Uma verso comum para todos os envolvidos no projeto, visando validao e verificao;
5. Facilidade de transferncia de desenvolvimento;
6. Servir de base para futuras melhorias.
7. Prover o suporte necessrio para a validao dos requisitos entre os stakeholders do sis-
tema.
2.3.3 Validao de Requisitos
A validao dos requisitos, consiste em checar se o documento de requisitos est consistente,
completo e claro [KS98]. Ela a ultima fase do processo de ER, isso significa dizer que quando
os requisitos esto "validados"eles contemplam a descrio do sistema que ser implementado
[KS98].
uma atividade complexa por dois motivos: o primeiro reside na dificuldade de identificar
todos os requisitos juntamente ao cliente; e o segundo de razo social, por conta da difi-
culdade de atingir o consenso entre os diferentes responsveis pelo software, principalmente
quando estes possuem objetivos conflitantes [NE00]. Os conflitos ainda pendentes entre osstakeholders devem ser resolvidos atravs da realizao de reunies de validao para que haja
uma estabilidade nos requisitos validados [NE00].
O principal motivo da realizao da validao dos requisitos garantir que o analista do sis-
tema compreendeu corretamente os requisitos ao assegurar que o mesmo esteja claro, completo
e consistente [ABD+04]. Essa fase importante por envolver vrios integrantes do projeto com
diferentes vises (engenheiro de requisitos, stakeholders, gerente de projeto) na busca por er-
ros no documento de requisitos mitigando o esforo gasto em retrabalho nas etapas posteriores
do projeto. Esse esforo se justifica pelo fato de que em geral uma mudana nos requisitos,
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
39/165
14 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
impacta em modificao na implementao do sistema [Som04].
Durante a elicitao dos requisitos o foco da anlise nas necessidades dos stakeholders.
Seria ideal que o documento de requisitos apenas inclusse requisitos aceitos pelos mesmos.
Entretanto, inevitavelmente, alguns stakeholders descobrem problemas nos requisitos durante
a validao necessitando voltar as atividades de elicitao dos requisitos [KS98].
2.3.3.1 Inspeo de Requisitos
A inspeo dos requisitos a tcnica mais utilizada para realizar a validao dos requisitos
[KS98]. Existe diversos trabalho que comprovam a efetividade da tcnica [GG93] [Wel93] ,
que vem sendo refinada ao longo dos anos com o uso de sistemas colaborativos [MDTR93][GHB03] para a sua realizao. Ela envolve a seleo de alguns integrantes do projeto que fi-
cam responsveis por ler, analisar os requisitos na busca por problemas, discuti-los e concordar
com as aes a serem tomadas. Apesar de ser um meio onde h muita alocao de recursos
(engenheiros de software, arquitetos, engenheiro de requisitos, gerente de projeto e etc), a reali-
zao de inspeo dos requisitos do software logo no incio do desenvolvimento, considerada
uma boa prtica [Wit00]. Com o uso desta tcnica, possvel remover os defeitos logo nas fases
iniciais do processo de desenvolvimento [Wit00], reduzindo os custos gastos com retrabalho.
A inspeo dos requisitos proposta neste trabalho tem o objetivo de:
1. assegurar o padro de qualidade dos artefatos;
2. evitar a ambigidade dos requisitos;
3. evitar o baixo nvel de detalhamento dos mesmos.
Kotonya e Sommerville, basearam-se em Tom Gilb [GG93] para propor o seu processo de
inspeo. A Figura 2.3 demonstra esse processo.
Figura 2.3 Processo de Inspeo dos Requisitos Baseado em [KS98]
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
40/165
2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS 15
As atividades do processo de inspeo so as seguintes:
Planejar inspeo : Seleciona-se o time de inspeo, definindo data, horrio e local para areunio.
Distribuir documentos : Os documentos de requisitos e qualquer outro artefato relevante so
distribudos para a equipe de inspeo.
Preparar para a inspeo : Cada inspetor l o documento visando identificar conflitos, omis-
ses, inconsistncias, no seguimento dos padres do artefato e outro problemas.
Reunio de inspeo : Os comentrios individuais e os problemas so discutidos e as aes
so tomadas para resolver os problemas encontrados.
Correes da inspeo : O coordenador de revises ir assegurar que todas as aes foram
efetuadas.
Revisar o documento : O documento revisado refletindo as aes acordadas. Nesse mo-
mento o artefato poder ser considerado validado. Caso contrrio ser necessrio a reali-
zao de outra inspeo.
Ao aplicar o modelo de processo de inspeo proposto por Kotonya e Sommerville (Fi-
gura 2.3) dentro do ambiente de DDS, a literatura aponta para a necessidade de usar um
conjunto de ferramentas colaborativas para executar esse processo nesse ambiente [BV05],
[Zow02], [CA01]. Atravs dessas ferramentas ser possvel, por exemplo, facilitar a distribui-o dos documentos com o uso de um editor de texto colaborativo [Goo] e viabilizar reunies
de inspeo por intermdio dos meios de comunicao sncronos.
A seleo dos inspetores deve ser bastante criteriosa. ideal que o documento de requisitos
possa ser revisto por uma equipe multidisciplinar, vindo de integrantes com diferentes habili-
dades [KS98]. Um dos problemas a serem enfrentados pelos inspetores o de entendimento
dos requisitos, possivelmente a partir do uso dos storyboards 2 poderemos melhorar essa ativi-
dade. Contudo o conhecimento adquirido pelo autor durante a documentao muito maior do
que a documentao por ele elaborada. Na falta desse conhecimento poder haver impacto nacompreenso dos mesmos. Visando preencher essa lacuna prudente que entre os inspetores
devam estar inclusos os participantes da fase de elicitao dos requisitos. Estes, devem saber
o que precisa ser documentado, caso isso no seja possvel que ao menos um especialista do
domnio esteja engajado nesse processo.
2Prottipo de interface de mdia-fidelidade que contm uma srie de desenhos ou imagens que representamcomo a interface utilizada para desempenhar determinada tarefa.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
41/165
16 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
2.3.4 Prototipagem Durante a Engenharia de Requisitos
A prototipagem pode ser usada como uma tcnica de anlise e reduo de riscos. Um riscosignificativo no desenvolvimento de software so os erros e as omisses dos requisitos. Ge-
ralmente os prottipos so utilizados para verificar a interpretao do analista de sistemas,
assim como para elicitar novos requisitos. Possibilitando ao stakeholderfornecer feedback e
sugestes de melhorias para a resoluo dos problemas encontrados no prottipo [ABD+04].
Combinada com outras tcnicas como por exemplo, podemos ter uma instncia de um prottipo
o qual pode ser utilizado para provocar discusses em grupos de elicitao [NE00].
Os desentendimentos entre usurios e desenvolvedores so expostos nos prottipos, identificando-
se assim, defeitos e confuses nos requisitos elicitados e documentados. Atravs do seu desen-
volvimento ser possvel auxiliar clientes e desenvolvedores no entendimento dos requisitos do
sistema, sendo utilizada como artefato de entrada para o DER auxiliando no nvel de detalhe
da especificao dos requisitos e conseqentemente reduzindo o risco de retrabalho [Som04].
O principal propsito dos prottipos desenvolvidos para as etapas de elicitao e valida-
o dos requisitos ser demonstrar as funcionalidades do software, devendo ser desvinculado
do acabamento do mesmo. Por essa razo existem recomendaes para que sejam utilizados
prottipos de baixa fidelidade [ABD+04].
Segundo o padro IEEE-830 [Byr94], os prottipos so teis pelas seguintes razes:
Os usurios podem ter uma viso mais amigvel visualizando um prottipo do que lendo
um DER. Isso prov um rpido feedback.
Os prottipos antecipam aspectos do comportamento do sistema. Isso produz no apenas
respostas, mas tambm novos questionamentos, bastante importantes durante a fase de
elicitao dos requisitos.
Um DER baseado em prottipos tende a possuir menos mudanas durante o desenvolvi-
mento, diminuindo o tempo gasto na Engenharia de Requisitos. Auxiliando na validao
do DER.
Segundo Kotonya [KS98] os prottipos so apenas utilizados para demonstrar os requisi-
tos funcionais do sistema. Logo no podem ser utilizados para requisitos no funcionais do
software como: usabilidade, performance, eficincia, segurana e demais requisitos no funci-
onais.
Tcnicas como prototipagem, especificao e o uso de cenrios auxiliam na transcrio
do problema no mundo real. Porm, isso no garante que os aspectos das necessidades dos
stakeholders estejam cobertos [NE00], os prottipos podem ser:
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
42/165
2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS 17
Evolucionrios fornecer um sistema funcional aos usurios finais. Normalmente esse pro-
cesso se inicia com os requisitos do usurios que so bem compreendidos e com os que
tm maior prioridade [Som04].
Descartveis sua principal funo validar ou elicitar novos requisitos do sistema. Sendo
preciso comear com aqueles que no so bem compreendidos, porque preciso saber
mais sobre eles. Os prottipos descartveis tm uma durao muito curta, sendo pos-
svel modific-los muito rapidamente durante o desenvolvimento, mas a facilidade de
manuteno a longo prazo no exigida [Som04].
Os prottipos descartveis no precisam ser prottipos executveis de software para que
sejam teis no processo de ER. Os modelos com base em papel, da interface com o usurio de
sistema, se mostram bastante efetivos no entendimento dos requisitos [Som04].
Apesar do desenvolvimento de prottipos aumentar o custo gasto nas fases iniciais do sis-
tema, eles podem evitar o uso de recursos no desenvolvimento de requisitos errados, logo essecusto justificado [NE00] [Som04]. Durante o desenvolvimento distribudo onde a fase de
elicitao realizada em uma localidade e o detalhamento dos requisitos desenvolvida em
outra o uso de prottipos com o intuito de evitar o desenvolvimento errneo dos requisitos
essencial.
Segundo Kotonya [KS98] se um prottipo foi desenvolvido para a elicitao dos requisitos,
faz sentido que ele seja refinado e usado no processo de validao dos requisitos. Porm a
criao de prottipos apenas para a validao dos requisitos no compensador, pois perde-se
todos os benefcios que o uso dos prottipos traria nas etapas inicias do processo de ER. Oformato do prottipo deve facilitar a discusso do grupo e as intervenes do stakeholder, para
que as tcnicas de brainstorming possam fluir com mais naturalidade. A fase de elicitao
se dar por concluda quando for realizado o refinamento exaustivo do prottipo por todos os
stakeholders, atingindo a estabilidade necessria para finalizar a fase de elicitao. A proposta
desse trabalho realizar a documentao e validao dos requisitos em ambientes distribudos
de desenvolvimento. Para isso consideramos essencial o uso dos prottipos desenvolvidos
durante a elicitao dos requisitos como artefato de entrada para a documentao e validao
dos requisitos em ambientes DDS.
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
43/165
18 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
2.4 Trabalhos Relacionados
2.4.1 Processo de Requisitos alinhado com o CMM
Lopes [Lop03] prope um processo de engenharia de requisitos alinhado com o Capability
Maturity Model (CMM) visando reduzir as dificuldades causadas pela distribuio da equipe
durante a fase de requisitos. Sua pesquisa consiste em testar etapas de entendimento e adapta-
o do DER entre as equipes distribudas.
O CMM tem o intuito de auxiliar as organizaes de software a atingirem a maturidade de
seus processos de uma maneira evolucionria, podendo passar de processos caticos a proces-
sos maduros e disciplinados.No processo proposto, existe a distribuio da equipe de especificao e equipe de desen-
volvimento. A equipe de especificao realiza reunies presenciais com o usurio e a equipe
de desenvolvimento implementa o software baseado no DER definidos pela equipe de especi-
ficao. Esse processo tem um total de cinco etapas como mostrado na Figura 2.4 e descrito
abaixo.
Figura 2.4 Processo para Engenharia de Requisitos Distribuda [Lop03]
2.4.1.1 Etapas do Processo
Como podemos ver na Figura 2.4 o processo proposto por Lopes [Lop03], consiste nas seguin-
tes etapas:
A) Envio do DER para a equipe de desenvolvimento;
B) Anlise do DER pela equipe de desenvolvimento;
C) Envio do DER para aprovao da equipe de especificao;
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
44/165
2.4 TRABALHOS RELACIONADOS 19
D) Validao do DER pela equipe de especificao;
E) Verso final do DER definida.
Envio do DER para a equipe de desenvolvimento: Enquanto realiza as etapas de elicitao,
anlise, negociao e especificao junto aos stakeholders, a equipe de especificao cria
uma verso inicial do DER e envia para a equipe de desenvolvimento, no intuito de haver
familiarizao com o artefato.
Anlise do DER pela equipe de desenvolvimento: A anlise do DER pela equipe de desen-
volvimento deixa a equipe de desenvolvimento engajada na especificao desde o incio
da idealizao do software, permitindo um melhor entendimento dos motivos que gera-
ram o requisito.
Entretanto, com o surgimento de novas demandas, so realizados muitos contatos entre
a equipe de especificao e os stakeholders, tornando o acompanhamento da evoluo
dos requisitos por parte da equipe de desenvolvimento mais complexo. J que o conheci-
mento obtido durante o processo de criao do documento tende a ser mais profundo do
que as informaes contidas no prprio documento.
Ao receber o DER da equipe de especificao, necessrio que a equipe de desenvolvi-
mento busque o entendimento da especificao e seu contexto. Durante esta etapa so
feitas adaptaes no DER para reduzir eventuais fontes de problema. A atividade de re-
escrita permite que o conhecimento adquirido no seja perdido. Porm dvidas podemsurgir e precisam ser esclarecidas com a equipe de especificao, causando um grande
volume de comunicao entre as equipes.
A comunicao entre as equipes visa obter: esclarecimentos e consenso quanto especi-
ficao em construo. Por vezes os esclarecimentos solicitados equipe de especifica-
o podem demandar novos contatos com usurios e clientes aumentando a qualidade de
especificao.
Envio do DER para aprovao da equipe de especificao: Uma vez que o DER foi adap-
tado ou reescrito, o novo documento precisa ser aprovado. Ao trmino dessa etapa deanlise do DER por parte da equipe de desenvolvimento, o documento enviado para
verificao pela equipe de especificao.
Validao do DER pela equipe de especificao: A equipe de especificao deve assegurar
que aps as mudanas o DER ainda represente as necessidades e caractersticas solicita-
das pelos stakeholders. Com as diversas interaes realizadas durante a segunda etapa,
permite que a equipe de especificao acompanhe o processo de adaptao do DER, re-
duzindo o esforo necessrio para a validao.
Verso final do DER definida: Aps aprovao pela equipe de especificao, a verso final
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
45/165
20 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
do DER definida com aprovada. Esta verso ento utilizada pela equipe de desenvol-
vimento como base para a modelagem, codificao e testes do software.
O modelo de qualidade de software CMM recomenda, em uma de suas reas chave, queos requisitos sejam acordados por todos os stakeholders. Para que este acordo seja obtido
indispensvel a completa compreenso dos requisitos pelas partes envolvidas. Em ambientes
de DDS isso envolve, muitas vezes, sobrepor barreiras de linguagem e cultura.
2.4.1.2 Concluses
Uma das grandes contribuies desse trabalho uma grande interao existente entre diferentes
equipes (desenvolvimento e especificao). No nosso trabalho buscamos aumentar a interao
entre as UDS na fase de documentao, isso permitiu que o artefato fosse revisado durante essa
fase, e conseqentemente diminuir o esforo gasto durante a fase de validao.
O autor reconhece que alm da distribuio entre as equipes de especificao e desenvol-
vimento, pode haver distribuio entre a equipe de especificao e os stakeholders, afetando
ainda mais as etapas da Engenharia de Requisitos que envolvem estes grupos, como destacado
por [DZ02].
2.4.2 MuNDDoSS - Um Modelo de Referncia para o Desenvolvimento Distribudo de
Software
Prikladnicki [Pri03], prope um modelo de referncia para a rea de DDS, contemplando as
dimenses tcnicas e no-tcnicas alm dos fatores envolvidos em cada um delas. O autor tirou
tais concluses baseado em dois estudos de caso realizados em um centro no Brasil, atravs de
uma empresa global de desenvolvimento de software.
Nesse trabalho, atravs do confronto entre a teoria e as descobertas empricas o autor pde
apresentar oito lies apreendidas, que foram as bases de sustentao para o modelo de refe-
rncia proposto. Dentre essas oito, o autor identifica como sendo "A Engenharia de Requisitos o maior desafio no ponto de vista do processo de desenvolvimento de software"[Pri03]. Os
entrevistados dessa pesquisa mencionaram que pelo fato de o projeto ser distribudo, os re-
quisitos devem ser passados com o maior nvel de detalhe possvel, sem margem para falsas
interpretaes.
A Engenharia de Requisitos aplicada nesse contexto distribudo de desenvolvimento con-
siderada um grande desafio, na exata medida em que devem ser encontradas as melhores formas
de: identificar, analisar, negociar, e documentar os requisitos. Atravs de ferramentas de apoio
alm de tcnicas que permitam uma maior proximidade das equipes distribudas, juntamente
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
46/165
2.4 TRABALHOS RELACIONADOS 21
com clientes e usurios, sendo os dois ltimos responsveis por identificar os requisitos do
projeto em um nvel mais alto.
Praticamente todas as entrevistas realizadas com os gerentes de projetos e lderes tcnicos
apontaram para dificuldades nas atividades que envolvem a Engenharia de Requisitos. Em
um dos projetos a instabilidade dos requisitos foi o maior problema, principalmente devido
distncia entre as equipes, o que dificultava o entendimento dos requisitos e a convergncia
de idias. Em todos os projetos, os requisitos foram identificados como um grande desafio,
envolvendo atividades desde a realizao de reunies at a formalizao (documentao) dos
requisitos que eram definidos, a rastreabilidade e controle dos mesmos.
2.4.2.1 Concluses
O autor conclui que existem problemas constantes na execuo da Engenharia de Requisitos
em ambientes de DDS. Eles foram encontrados desde a necessidade de identificar os requisitos
do projeto, passando pela anlise, especificao, validao e gerncia.
Buscamos, ento, neste trabalho atacar a sistematizao da validao dos requisitos. Con-
tudo antes de validar os requisitos de forma distribuda, devemos document-lo de forma con-
sistente para que ele possa ser validado.
2.4.3 Suporte Engenharia de Requisitos no Desenvolvimento Distribudo de Software
Brito [Bri06], props um processo de Engenharia de Requisitos distribuda e desenvolveu uma
ferramenta open-source de ambiente de desenvolvimento de software (ADS) chamada de CO-
operative and DIstributed Process Support Environment(CODIPSE) a qual fornece suporte as
equipes distribudas na execuo desse processo. Na ferramenta esto inclusos: um modelo de
rastreamento originado desse processo o qual vincula diferentes tipos de informao, proveni-
entes das ferramentas de groupware fazendo um gerenciamento de requisitos em que auxilia
na compreenso do rationale3. Registrando informaes relacionadas entre si, possibilitandoresponder a seguinte pergunta: quais informaes originaram determinada informao?
Esse processo foi definido com base em dois outros processos existentes: o primeiro des-
creve um processo para web baseado no Rational Unified Process (RUP) [Did03] e o segundo
descreve um processo de Engenharia de Requisitos para desenvolvimento distribudo [Lop03].
3Termo usado para identificar as motivaes, razes e/ou justificativas para um determinado requisito existir.Os artefatos armazenados so: reunies, correios-eletrnicos, resultados de pesquisas, entre tantos outros quepossam contribuir para a sua definio. Ao longo do tempo, esse rastreamento auxiliar na construo de umhistrico do projeto [Bri06].
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
47/165
22 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
Apesar do trabalho de Lopes [Lop03] tambm apresentar um processo para Engenharia de
Requisitos Distribuda, ele no faz uso de tecnologias colaborativas, mesmo considerando a
importncia de sua utilizao.
Nessa proposta, os participantes esto totalmente distribudos e usam um ambiente ade-
quado para trabalhar colaborativamente. importante ressaltar que embora exista uma distin-
o clara entre as etapas da ER, algumas delas comumente ocorrem em paralelo [KS98].
Viso geral do processo de Engenharia de Requisitos proposto, ele considera a interao
com trs bases de conhecimento: (1) formais contendo informaes sobre: o processo em exe-
cuo, clientes e usurios; (2) informais contendo dicas sobre a execuo do processo e infor-
maes sobre cultura, idioma e histrico de interaes com os clientes; (3) informaes sobre
o negcio, agrupando dados sobre o projeto atual tais como: documentos e artefatos gerados.Juntas essas bases auxiliam no fornecimento de informaes contextuais para os participantes.
A proposta CODIPSE visa construir um ambiente de desenvolvimento de software cen-
trado em processo ou Process-Centered Software Engineering Environment (PSEE) utilizando
tecnologias de colaborao para auxiliar na definio e execuo de processos de software em
equipes distribudas.
Devido ao escopo ser muito abrangente a autora decidiu tratar apenas a disciplina de re-
quisitos, pois ela encontrou na literatura poucas propostas que dem o suporte Engenharia de
Requisitos de forma colaborativa dentro do desenvolvimento open source. Ela salienta aindaque os ambientes colaborativos de open source atuais do o suporte ao desenvolvimento de
software distribudo mas apenas tratam da colaborao durante a edio de modelos de anlise
do projeto e nas atividades de codificao [GMH00].
A autora estendeu o eGroupware [GRO06] devido facilidade de integrao e desenvolvi-
mento de novas aplicaes na sua plataforma, o qual utiliza uma soluo baseada em templates
(onde possvel construir a interface grfica apenas descrevendo os campos e listagens). Re-
aproveitando um conjunto de aplicativos que favorece e estimula a cooperao entre equipes,
tais como: calendrio compartilhado, base de conhecimento, fruns e wiki.A aplicao CODIPSE possui trs mdulos principais:
Gerenciamento de Requisitos: agrupando funcionalidades para manuteno de projeto como
viso/escopo, casos de uso, requisitos funcionais e no funcionais, glossrio e atores;
Manuteno do Rationale: agrupa funcionalidade para criar links para as demais ferramentas
de colaborao do ambiente. Os links podem ser criados em nvel de projeto, casos de
uso ou requisitos, permitindo a completa manuteno do histrico do projeto;
Exportao: esse mdulo responsvel pela gerao intermediria (em Extensible Markup
Language (XML)) dos dados presentes em um determinado projeto. A partir dessa verso
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
48/165
2.4 TRABALHOS RELACIONADOS 23
possvel exportar as informaes para qualquer formato atravs de transformao The
Extensible Stylesheet Language Family (XSL) .
2.4.3.1 Concluses
Esse trabalho est muito relacionado nas etapas iniciais da ER, inclusive o rastreamento pro-
posto pelo mesmo abrange essas etapas iniciais. Nosso trabalho na ER de forma distribuda
inicia na etapa de documentao dos requisitos e validao dos mesmos.
Consideramos tambm que o uso das tecnologias colaborativas, essencial para a Enge-
nharia de Requisitos realizada em ambientes distribudos de desenvolvimento. Um ambiente
web, permite que todos os envolvidos no projeto possam ter um nico repositrio de artefatose acess-los atravs de um navegador web.
2.4.4 Efetividade das Tcnicas de Elicitao dos Requisitos na Engenharia de
Requisitos Distribuda
Lloyd [Llo01], realzou um estudo emprico de como as ferramentas de colaborativas podem
ser utilizadas para elicitao dos requisitos de um sistema no desenvolvimento de software
em equipes distribudas de desenvolvimento. Os participantes dessa pesquisa foram grupos
distintos de estudantes de cincias da computao no total seis grupos de sete a nove membrossendo separando os clientes dos engenheiros. O DER foi produzido pelos engenheiros atravs
de interao remota com os clientes.
Todos os grupos ficaram distribudos e tinham como suporte ferramentas colaborativas que
permitiram a colaborao sncrona e assncrona. Clientes e engenheiros nunca tiveram contato
face a face, com o objetivo de realizar qualquer tipo de discusso ou negociao a respeito
do projeto. A inteno foi observar a efetividade das tcnicas de elicitao no processo de
refinamento dos requisitos no ambiente distribudo de desenvolvimento. Ao trmino das itera-
es foram analisadas a qualidade dos artefatos produzidos. A Engenharia de Requisitos foiauxiliada com o uso de um conjunto de ferramentas colaborativas, a saber:
Centra Symposium : possibilitou as reunies virtuais em tempo real;
MOOsburg : facilitou o compartilhamento de arquivos, conversas informais, correios-eletrnicos
para realizao de discusso assncrona.
Cada grupo de Engenharia de Requisitos conduziu uma srie de quatro reunies virtuais
planejadas e agendadas com um grupo de clientes. As reunies de elicitao tinham no mximo
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
49/165
24 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
90 minutos de durao sendo realizadas por audio-conferncia atravs do Centra Symposium.
Os engenheiros de requisitos no utilizaram nenhuma tcnica de elicitao de requisitos em
particular. Eles foram treinados numa variedade de tcnicas (Figura 2.5) e durante a elicitaotiveram a liberdade de escolha da melhor tcnica para a situao.
Neste estudo emprico o autor observou e examinou os artefatos armazenados nos espa-
os colaborativos criados no MOOSburg. Alm de arquivar e analisar toda a comunicao de
correios-eletrnicos entre clientes e engenheiros de software. Mais detalhes sobre essa anlise
sero encontrados na dissertao de mestrado [Llo01].
Os participantes estavam habilitados a usar o MOOsburg de qualquer computador atravs de
um navegador web, sendo necessrio instalar um plugin apropriado. O MOOsburg possibilitou
a comunicao sncrona e assncrona entre clientes e engenheiros de requisitos. J o CentraSymposium que possibilitava audio-conferncia atravs de Voz Sobre IP (VoIP), ficou restrito
ao campus da universidade. Os grupos obtiveram informaes dos requisitos adequados atravs
de sesses virtuais planejadas, obtendo mais sucesso na escrita do DER.
Figura 2.5 Efetividade das Tcnicas de Elicitao dos Requisitos em DDS [Llo01]
Nesse grfico da Figura 2.5 apesar dos diversos nveis de experincia dos participantes
foram identificadas as tcnicas de elicitao de requisitos mais efetivas quando utilizadas no
contexto de DDS. Porm a avaliao dos prottipos executveis gerados para elicitao deveser desconsiderado, pois o autor informa que os engenheiros de requisitos no tiveram o de-
vido treinamento no uso do mtodo. Todavia a prototipagem de baixa fidelidade chamada de
storyboard, foi estudada e utilizada durante o experimento.
2.4.4.1 Concluses
Neste estudo emprico de Engenharia de Requisitos em ambientes distribudos de desenvol-
vimento, as atividades foram auxiliadas pelo uso de ferramentas de groupware com suporte
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
50/165
2.4 TRABALHOS RELACIONADOS 25
colaborao. Seis estudantes de Engenharia de Requisitos seguiram um processo bsico de
elicitao, refinamento e especificao de um sistema.
O autor conclui que a Engenharia de Requisitos em ambientes distribudo de desenvolvi-
mento, mais efetiva quando os stakeholders participam ativamente das atividades sncronas
do processo de engenharia de requisitos. Ficando a cargo da audio-conferncia como o meca-
nismo mais rico de colaborao sncrona utilizado na pesquisa. Atravs da observao, o autor
acredita que os grupos sentem-se atrados a usarem correio eletrnico e ferramentas de instant
messaging, diminuindo as barreiras sociais causadas pela distncia.
Nesse trabalho o autor testou um conjunto de ferramentas usando tcnicas de elicitao
de requisitos, porm no sistematizou num processo de Engenharia de Requisitos para esses
ambientes. O prprio autor reconhece que os meios mais adequados para realizar a elicitaoso os meios sncronos e que o mecanismo de comunicao mais adequado o contato face a
face. Consideramos que se conseguirmos elicitar os requisitos juntamente com o stakeholderde
maneira presencial, teremos um mecanismo mais rico em contexto (Figura 2.1) e diminuiremos
o esforo gasto nessa atividade.
De acordo com as tcnicas listadas para a elicitao dos requisitos (Figura 2.5) seleciona-
mos3das5maisefetivas(Brainstorming, Storyboarding, Casos de Uso). Apesar de considerar-
mos o gerenciamento de requisitos extremamente importante para a Engenharia de Requisitos
[KS98], a anlise deste processo foge do escopo desse trabalho.
2.4.5 Impacto dos Stakeholders Geograficamente Distribudos na Gerncia de
Requisitos em organizaes Multi-Site
Damian e Zowghi [DZ02] investigam os problemas da ER quando os stakeholders esto distri-
budos geograficamente numa organizao multi-site. Elee buscaram examinar a ER na prtica,
entendendo o impacto da distncia em projetos onde os stakeholders definem os requisitos do
software separados geograficamente.Algumas organizaes s vezes no podem se dar o luxo de realizar reunies de requisitos
face a face. Como resultado, a distncia impactou na forma como os stakeholders opinam,
questionam e decidem os requisitos. Ento, atravs de evidncias empricas, foi construdo um
modelo de comunicao remota e gerncia do conhecimento. Mesmo com o uso desse mo-
delo foram encontrados diversos problemas: diversidade cultural, diferenas de horrio. Esses
problemas impactaram negativamente nas etapas subseqentes dos requisitos: negociao e
validao.
Essa pesquisa foi motivada pela seguinte pergunta: Qual o impacto da distncia geogr-
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
51/165
26 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
fica dos stakeholders nas atividades de Engenharia de Requisitos no ambiente distribudo de
desenvolvimento?.
A metodologia de pesquisa utilizada foi a grounded theory [Fli04] aplicada num estudo decaso [Yin05]. O autor levou sete meses em sites de desenvolvimento localizados em Sydney-
AU, coletando: dados, mtodos, inspeo de artefatos, observao das reunies de requisitos e
entrevista semi-estruturada com vinte e quatro stakeholders (gerente de produto, engenheiro de
produto, gerente de suporte ao cliente e engenheiro de software).
A organizao estudada foi uma corporao de Desenvolvimento Global de Software (DGS)
entre 4 continentes. A estratgia do produto fica de responsabilidade de uma equipe deBusiness
Management(BM) localizada em 4 pontos nos Estados Unidos (vide Figura 2.6). A equipe de
desenvolvimento est divida em trs na Austrlia e uma na Nova Zelndia. Os clientes estoagrupados em 5 seguimentos ao redor do mundo .
Figura 2.6 Distribuio geogrfica do grupo de stakeholders [DZ02]
Reunies de udio conferncia so utilizadas para a comunicao sncrona, o que permite
conectar o BM com as demais localidades na tomada de deciso (vide Figura 2.7). Os requisitos
ficavam armazenados num banco de dados no BM sendo fruto de informaes geradas por:usurios finais, clientes e funcionrios. Todos os sites provinham informaes que no futuro
poderiam se tornar requisitos do sistema.
Depois de centralizadas as informaes o BM prepara um documento inicial com os requi-
sitos em alto nvel Marketing Requirements Specification (MRS) a serem priorizados e negoci-
ados com a equipe de desenvolvimento. Depois do entendimento comum, a seleo realizada
e os requisitos passam a ser especificados pela equipe de desenvolvimento gerando o DER.
Depois de pronto o DER enviado para o BM para aprovao.
Nesse contexto, achou-se diversos campos para investigao das dificuldades em conseguir
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
52/165
2.4 TRABALHOS RELACIONADOS 27
Figura 2.7 Fluxo de informao no projeto [DZ02]
uma colaborao efetiva dos stakeholders geograficamente distribudos. Durante a negocia-
o dos requisitos, foram utilizadas um conjunto de ferramentas sncronas e assncronas de
comunicao visando diminuir essa distncia.
Canais de udio e vdeo foram usados na comunicao com entre desenvolvedores remotos
e clientes para a captura de requisitos. O Microsoft Powerpoint [Mic06b] foi usado na cons-
truo de diagramas de contexto, juntamente com o NetMeeting para o compartilhamento das
apresentaes do Microsoft Powerpoint [Mic06b] a distncia. Isso permitiu criar documentoseletrnicos colaborativamente melhorando as atividades colaborativas distribudas atravs do
acesso em tempo real por sites remotos. A percepo dos participantes em Sydney aumentou
com a captura de vdeo e as conferncias de audio.
Junto a essas ferramenta colaborativas genricas, uma ferramenta especfica de requisitos
foi usadada RequisitePro [RAT05] da Rational. Os requisitos capturados so cadastrados no
RequisitePro [RAT05] sendo refinados pela equipe de desenvolvimento e ento um DER
gerado . Tanto o time de desenvolvimento, quanto os demais membros do projeto podem
acessar as verses atuais dos DER, isso inibe a ocorrncia de artefatos desatualizados sendoutilizados pelos demais integrantes.
Apesar de todas as funcionalidades das ferramentas colaborativas existentes no estudo de
caso, o correio eletrnico ainda a ferramenta assncrona predominante. Principalmente de-
vido a diferena de tempo entre as unidades distribudas. Isso traz vantagens e desvantagens
na gerncia dos requisitos, o correio eletrnico para a resoluo de ambigidades existentes no
documentos de requisitos, foi um mecanismo muito pobre. Alm de ser um meio de baixo con-
texto para a comunicao, vrias vezes a equipe de especificao explicava os requisitos atravs
de correio eletrnico porm posteriormente o problema ressurgia, seja por conta que um outro
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
53/165
28 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
stakeholder vinha com a mesma dvida, ou o e-mail foi respondido h muito tempo e caiu no
esquecimento. Como vantagem, fica o fato de ser um mecanismo mais formal de comunicao
pois por ser considerado um documento ele fornece mais segurana na informao.
Durante a realizao do estudo de caso o autor revelou que a distncia impactou diretamente
nas atividades relacionadas a negociao dos requisitos do sistema, sendo eles:
Comunicao inadequada : A distncia introduz barreiras para a comunicao informal e
face a face. Deixando a comunicao dependente de ferramentas colaborativas sncronas
e assncronas.
Gesto de conhecimento : A quantidade de requisitos vinda de mltiplas fontes dos sites re-
motos, no ficou bem compartilhada entre os desenvolvedores.
Diversidade cultural : Diferenas entre as lnguas e culturas afetaram a colaborao global.A linguagem do cliente impactou diretamente na atividade de elicitao de requisitos,
essas barreiras afetaram a transferncia de conhecimento a respeito dos requisitos para
os desenvolvedores.
Diferena de tempo : A larga distribuio dos stakeholders introduz diferenas de fuso hor-
rio ficando difcil de ser resolvida. Assim canais de comunicao assncrona so mais
predominantes. Reunies sncronas requerem o compromisso de algum site para ser re-
solvido.
Em um estudo anterior desse mesmo estudo de caso [DZO01] os autores visualizaram di-versos problemas na rea de ER em DDS Figura 2.8:
Negociao : DER levou cerca de 6 meses de negociao at ser aprovado. O autor considera
que devido a esse atraso a validao dos requisitos no foi realizada a contento.
Reviso : esse processo consumiu bastante tempo do cliente. Desta forma foram realizadas
revises no formais, geralmente mal gerenciadas e ineficientes.
Validao : no houve uma validao formal dos requisitos por parte do cliente. Eventuais
comunicaes entre os clientes eram realizadas e melhorias nos requisitos foram propos-
tas durante a evoluo do artefato. Os autores sentiram a necessidade de uma melhorcoordenao dessa atividade.
Prototipagem : O processo de prototipagem foi bastante em cascata, perdendo os benefcios
que uma abordagem baseada em prototipagem poderia trazer, como a construo dos re-
quisitos de forma iterativa e auxiliando nas fases de elicitao e validao dos requisitos.
Damian, Zowgui e Offen [DZO01] defendem que esses problemas esto diretamente re-
lacionados com o impacto dos problemas de comunicao e coordenao existentes no DDS.
Porm como resultados parciais do estudo os autores concluem que a distncia impacta na
colaborao entre grupos distribudos de desenvolvimento. Desta forma os autores sentem
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
54/165
2.4 TRABALHOS RELACIONADOS 29
Figura 2.8 Modelo de impacto dos desafios e atividades afetadas da Engenharia de Requisitos devidoa problemas com o DGS adaptado de Damian [DZ02]
a necessidade de uma pesquisa em um processo de engenharia de requisitos especfico para
desenvolvimento distribudo de software. Pois eles acreditam que um nmero bastante signifi-
cativos de organizaes que utilizam desenvolvimento distribudo de software venham a ter os
mesmos problemas descritos.
2.4.5.1 Concluses
Damian, Zowgui e Offen reconhecem que a negociao de requisitos desse estudo de caso foi
bastante demorada levando cerca de 6 meses e que caberia como um estudo futuro estudar os
fenmenos da validao dos requisitos nesse ambiente.
A centralizao e priorizao dos requisitos realizadas nesse estudo pelo BM foi importante
para a negociao atravs comunicao face a face do que deveria ser especificado. Melhorando
na coordenao das atividades atravs da priorizao dos requisitos entre as unidades distribu-das. Em nosso trabalho essa centralizao das informaes essencial para a tomada de decises
do que ser desenvolvido. Foi a partir dessas concluses que resolvemos criar uma Unidade
Principal de Desenvolvimento (UPD), que ficou responsvel por elicitar os requisitos iniciais
do sistema, delegando para as UDS em realizar o detalhamento dos mesmos.
Encontramos tambm nesse trabalho o uso de ferramentas colaborativas na Engenharia de
Requisitos distribuda. Os documentos foram criados de maneira colaborativa e em paralelo
entre as unidades distribudas, sendo registrados no RequisitePro o documento de requisitos era
organizado por essa ferramenta e mantido por controle de verso [RAT05]. Contudo, no s
7/31/2019 Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribudas Visando Melhor
55/165
30 CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
colocar uma ferramenta colaborativa para a edio dos artefatos que a Engenharia de Requisitos
funcionar em ambiente
Top Related