Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribuídas...

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


2/165


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


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


5/165


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


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


9/165


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)


11/165


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


13/165


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


15/165


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.3 Suporte Engenharia de Requisitos no Desenvolvimento Distribudo

de Software 21

xv


17/165

xvi SUMRIO


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


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


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


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.2 Detalhamento dos Casos de Uso 101


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.3 Preparao: Inspeo Assncrona 106


6.4.4 Reunio de Inspeo 107


20/165

SUMRIO xix


6.4.5 Correo da Inspeo 109

6.4.5.1 Passos para Execuo 1096.4.6 Validao 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


21/165


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


23/165


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


25/165


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


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.


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]


29/165


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


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.


31/165


As concluses, limitaes identificadas e as sugestes de trabalhos futuros ficaram no Ca-

ptulo 7.


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


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


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


35/165


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


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.


37/165


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.


38/165


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,


39/165


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]


40/165


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.


41/165


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:


42/165


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.


43/165


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;


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


45/165


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


46/165


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


47/165


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


48/165


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


49/165


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


50/165


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-


51/165


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


52/165


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


53/165


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


54/165


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


55/165


colocar uma ferramenta colaborativa para a edio dos artefatos que a Engenharia de Requisitos

funcionar em ambiente

Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribuídas...

Documents

Transcript of Medeiros L. M. Proposta de Processo de Requisitos para Equipes de Desenvolvimento Distribuídas...