Uma Proposta de Boas Práticas do Processo de Comunicação … · 2015-09-29 · Dentre os...

��

�Uma Proposta de Boas Práticas do Processo de Comunicação para Projetos de Desenvolvimento Distribuído de Software��

�

� ��

�

��

�� !��

�

�

Universidade Federal de Pernambuco [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, DEZEMBRO/2008

��

��

� � !�� "# � �� $� �� "# � �

Ivaldir Honório de Farias Junior

“Uma Proposta de Boas Práticas do Processo de Comunicação para Projetos de Desenvolvimento

Distribuído de Software"

ORIENTADOR(A): Prof. Dr. Edson Costa de B. Carvalho Filho

RECIFE,DEZEMBRO/2008

Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.

Farias Junior, Ivaldir Honório de Uma proposta de boas práticas do processo de comunicação para projetos de desenvolvimento distribuído de software / Ivaldir Honório de Farias Junior. – Recife: O Autor, 2008. xv, 90 folhas: il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2008. Inclui bibliografia e apêndice.

1. Engenharia de software. 2. Gerenciamento de projetos. l. Título.

005.1 CDD (22. ed.) MEI2009- 107

Aos meus pais, meus irmaos e minha noiva, por sempre

acreditarem e me incentivarem no alcance dos meus obje-

tivos.

AGRADECIMENTOS

A Deus que sempre esteve ao meu lado e que apesar de tudo nunca me deixou desistire sempre me proporcionou as melhores alternativas para a conclusao deste trabalho.A minha famılia, por tudo o que eles me proporcionaram ate aqui e por tudo o querepresentam na minha vida. A todos os colaboradores do Softex Recife e em especiala Eduardo Paiva e Ermeson Carneiro. Ao meu Orientado Edson Carvalho e aminha Co-orientadora Carina Frota Alves, que aceitou o desafio de me ajudar nestacaminhada, agradeco tambem pela sua forma unica de conduzir seus orientandos, deconduzir o trabalho e pela paciencia de manter sempre o objetivo de forma a busca-lo damelhor maneira possıvel. Aos avaliadores Alex Sandro Gomes e Cristine Gusmaoque se dispuseram a avaliar esta dissertacao. Aos professores Katyusco de Farias doCEFET-PE e Tiago Alessandro da UFRPE pela confianca e apoio durante esses 2anos. A todos os entrevistados, pelo tempo dispensado e pela rica contribuicao. Aosmeus colegas de mestrado, pelas discussoes, trabalhos e, pela grande amizade. A todosos professores e funcionarios do Centro de Informatica pelo apoio durante o mestradoe que contribuıram para que eu adquirisse o conhecimento necessario e, acima de tudo,para me qualificar na busca de novos conhecimentos como um profissional competente eciente do meu compromisso.

vii

Aprender e a unica coisa de que a mente nunca se cansa, nunca tem

medo e nunca se arrepende.

—LEONARDO DA VINCE

RESUMO

Atualmente, podemos perceber que o numero de empresas que estao aderindo ao Desen-volvimento Distribuıdo de Software(DDS) e bem mais significativo quando comparado haalguns anos atras. As empresas visam ganhos de qualidade, produtividade e diminuicaode custos. Por tais motivos, o DDS vem despertando um grande interesse de pesquisa-dores nos ultimos anos. A distribuicao das equipes de desenvolvimento de software temcriado diversos desafios ao processo de desenvolvimento de software e a gestao dos seusprojetos. Dentre os desafios, o processo de comunicacao destaca-se, como sendo uma dasatividades de grande importancia entre os membros da equipe. Essa atividade vem so-frendo impactos adversos, dentre eles: distancia fısica, diferencas culturais, fuso-horario,limitacoes dos meios de comunicacao disponıveis e outros. Diversos trabalhos tem enfa-tizado que a falta de comunicacao compromete diretamente o sucesso de projetos, sejamcentralizados ou distribuıdos. Diante deste contexto, o presente estudo apresenta resul-tados obtidos a partir de uma pesquisa empırica. O metodo de pesquisa utilizado foi oparadigma qualitativo que envolveu entrevistas com analistas de projetos distintos e suagrande maioria com equipes distribuıdas de forma global. Inserido nesse contexto, estadissertacao propoe boas praticas para o processo de comunicacao no desenvolvimento dis-tribuıdo de software. Essa proposta visa contribuir, no sentido de preencher essa lacunaexistente na area de DDS, especificamente no que se refere ao processo de comunicacao.

Palavras-chave:Desenvolvimento Distribuıdo de Software, Processo de comunicacao, Boas praticas

xi

ABSTRACT

Nowadays a growing number of companies are following a distributed software develop-ment process. Companies that are adopting this methology envisage gains of productivi-ties, quality and cost reduction. For this reason, the distributed software developmentisgaining attention of many companies. However, this approach is giving rise to severalchallenges and problems. Among these problems, the communication among develop-ment team is considered one of the most difficult to deal with. The communication isconsidered difficult because of work time in different places around the world, culturaldifferences, limitations of the ways of communication among others reasons. Several rese-arch are emphasizing that weak communication among team members can result in poorresults even if a development is centralized. This work presents an empirical study of thecommunication process of distributed software teams. The study was carried out usinga qualitative research approach with different team members working in distributed pro-jects. As a result of this dissertation, we propose several good practices to better supportthe communication process of distributed software projects.

Keywords:Software Distributed Developing, Communication Process, Best Practices

xiii

SUMARIO

Capıtulo 1—Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Descricao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Contribuicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Organizacao da Dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . 3

Capıtulo 2—Modelos de Qualidade 5

2.1 ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1 Processos Fundamentais . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Processos de Apoio . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Processos Organizacionais . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Visao Geral do Gerenciamento de Comunicacao na ISO 12207 . . 8

2.2 SPICE - ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Visao Geral do Gerenciamento de Comunicacao na ISO 15504 . . 14

2.3 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 Nıveis de Maturidade . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.2 Areas de Conhecimento do CMMI . . . . . . . . . . . . . . . . . . 182.3.3 Visao Geral do Gerenciamento de Comunicacao no CMMI . . . . 19

2.4 MPS.BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.1 Nıveis de maturidade . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.2 Visao Geral do Gerenciamento de Comunicacao no MPS.BR . . . 23

2.5 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Capıtulo 3—Desenvolvimento Distribuıdo de Software (DDS) 27

3.1 Motivacoes para o DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 Caracterizacao do DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Desafios do DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Processo de Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5 Problemas Relacionados a Comunicacao em DDS . . . . . . . . . . . . . 353.6 Comparando Processo de Comunicacao Distribuıdo com Centralizado . . 393.7 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.7.1 Abordagem de Carmel . . . . . . . . . . . . . . . . . . . . . . . . 413.7.2 MuNDDoS - Prikladnicki e Audy . . . . . . . . . . . . . . . . . . 453.7.3 Abordagem de Medeiros . . . . . . . . . . . . . . . . . . . . . . . 46

xv

xvi SUMARIO

3.8 Comparativo entre os Trabalhos Relacionados . . . . . . . . . . . . . . . 473.9 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Capıtulo 4—Metodologia de Pesquisa 49

4.1 Paradigma Qualitativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.1.1 Comparacao entre Pesquisa Qualitativa e Quantitativa . . . . . . 51

4.2 Plano de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3 Instrumento de Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . 544.4 Selecao dos Participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.5 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.6 Analise de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.7 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Capıtulo 5—Resultados do Estudo Empırico 59

5.1 Caracterısticas dos Participantes . . . . . . . . . . . . . . . . . . . . . . . 595.2 Analise e Interpretacao dos Dados das Entrevistas . . . . . . . . . . . . 615.3 Categorias e fatores associados a comunicacao . . . . . . . . . . . . . . . 635.4 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Capıtulo 6—Proposta de Boas Praticas para Processo de Comunicacao em DDS 69

6.1 Descricao da Praticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.1.1 Abertura do Projeto Distribuıdo com Reuniao Presencial . . . . . 706.1.2 Criar Pontos Focais . . . . . . . . . . . . . . . . . . . . . . . . . . 706.1.3 Manter a Cordealidade . . . . . . . . . . . . . . . . . . . . . . . . 726.1.4 Documentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.1.5 Definicao de Vocabulario . . . . . . . . . . . . . . . . . . . . . . . 736.1.6 Criar Portal Institucional . . . . . . . . . . . . . . . . . . . . . . . 746.1.7 Definicao de um Plano de Comunicacao . . . . . . . . . . . . . . . 756.1.8 Curso de Ingles para Negocios . . . . . . . . . . . . . . . . . . . . 756.1.9 Adocao Video-Conferencia . . . . . . . . . . . . . . . . . . . . . . 766.1.10 Reunioes Periodicas . . . . . . . . . . . . . . . . . . . . . . . . . . 776.1.11 Criar e Alimentar a Base de Informacoes Culturais . . . . . . . . 78

6.2 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Capıtulo 7—Conclusao e Trabalhos Futuros 81

7.1 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827.2 Limitacoes do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Capıtulo 8—Apendice A 85

LISTA DE FIGURAS

2.1 Processo da ISO 12207 [13] . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Nıveis de Capacidade da ISO 15504 . . . . . . . . . . . . . . . . . . . . . 122.3 Melhoria do Processo Organizacional [13] . . . . . . . . . . . . . . . . . . 122.4 Melhoria da Capacidade Organizacional [13] . . . . . . . . . . . . . . . . 132.5 Estrutura da Organizacao dos Documentos do Modelo ISO 15504 [1] . . . 132.6 Nıveis de Maturidade do CMMI . . . . . . . . . . . . . . . . . . . . . . . 172.7 Componentes do MPS.BR . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8 Nıveis de Maturidade do MPS.BR . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Equipe centralizada e distribuıda . . . . . . . . . . . . . . . . . . . . . . 283.2 Principais razoes envolvidas no DDS (adaptado [40]) . . . . . . . . . . . 293.3 Demanda por software em relacao ao numero de microcomputadores e

profissionais disponıveis (adaptado de [28]) . . . . . . . . . . . . . . . . . 303.4 Componentes da Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . 333.5 Componentes da Comunicacao Representado pelo Contexto . . . . . . . . 343.6 Forcas centrıfugas e centrıpetas de equipes distribuıdas ou globais . . . . 413.7 Numero de canais de comunicacao em uma equipe [31] . . . . . . . . . . 433.8 Modelo de impacto dos desafios apresentados devido dispersao dos sta-

keholders (adaptado de [16]) . . . . . . . . . . . . . . . . . . . . . . . . . 453.9 Diagrama de influencia das categorias em DDS (adaptado de [40]) . . . . 463.10 Comparacao entre os trabalhos relacionados . . . . . . . . . . . . . . . . 48

4.1 Uma Perspectiva do Processo de Pesquisa Qualitativa . . . . . . . . . . 524.2 Plano da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3 Etapas da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4 Arvore de Analise no Software NVivo . . . . . . . . . . . . . . . . . . . . 58

5.1 Visao geral da Certificacao de Modelos de Qualidade . . . . . . . . . . . 605.2 Area de Atuacao dos Entrevistados . . . . . . . . . . . . . . . . . . . . . 615.3 Nıvel de Dispersao das Equipes . . . . . . . . . . . . . . . . . . . . . . . 615.4 Entrevistados com Certificacao PMP . . . . . . . . . . . . . . . . . . . . 625.5 Categorias com impacto na Comunicacao . . . . . . . . . . . . . . . . . . 635.6 Estrutura da Arvore no NVivo . . . . . . . . . . . . . . . . . . . . . . . . 64

xvii

LISTA DE TABELAS

2.1 Principais Modelos de Qualidade . . . . . . . . . . . . . . . . . . . . . . 62.2 Dimensoes de Processo do ISO 15504 . . . . . . . . . . . . . . . . . . . . 11

3.1 Principais Desafios do DDS [40] . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Comparacao entre pesquisa qualitativa e quantitativa. . . . . . . . . . . . 51

5.1 Caracterizacao Geral dos Entrevistados . . . . . . . . . . . . . . . . . . . 59

xix

LISTA DE ABREVIATURAS

DDS - Desenvolvimento Distribuıdo de Software

DCS - Desenvolvimento Centralizado de Software

DGS - Desenvolvimento Global de software

CMM - Capability Maturity Model

CMMI - Capability Maturity Model Integration

MPS.BR - Melhoria de processo de Software Brasileiro

PMI - Project Management Institute

RUP - Rational Unified Process

SEI - Software Engineering Institute Carnegie Mellon University

SECM - Systems Engineering Capability Model

SPICE - Software Process Improvement Capability dEtermination

xxi

CAPITULO 1

INTRODUCAO

Neste capıtulo serao apresentadas as principais motivacoes deste trabalho, buscando con-textualizar o objetivo principal do estudo e as suas contribuicoes.

1.1 MOTIVACAO

Nas ultimas decadas, a globalizacao trouxe e ainda tras algumas consequencias, dentreelas podemos destacar a acirrada competitividade nos mercados nacionais e internacio-nais, os clientes cada vez mais exigentes, com demandas mais sofisticadas e complexas, emeios de comunicacao e recursos tecnologicos em crescente evolucao.

Este cenario apresenta maiores exigencias em padroes de qualidade, necessidade deinovacao e excelencia em gestao de projetos, seja centralizados ou distribuıdos. ParaKerzner [29] a globalizacao e a tecnologia farao com que a boa pratica de gestao deprojetos se torne ainda mais importante do que ja e nos dias atuais.

E possıvel perceber que as empresas estao buscando implantar ou se certificar emalgum dos modelos de qualidade existente, como CMMI e MPS.BR para conseguir obterou aumentar a qualidade de seus processos. Portanto, o processo ao qual este trabalhoestara dando prioridade, sera o processo de comunicacao onde o mesmo permeia todo oprojeto e e foco desta dissertacao.

Os modelos de qualidade como CMMI [11], MPS.BR [45], ISO 12207 [13], ISO 15504[1] dentre outros, tratam o processo de comunicacao de forma abrangente, dando umaatencao nao satisfatoria para o Desenvolvimento Distribuıdo de Software (DDS).

Atualmente, podemos perceber que e cada vez mais significativo o numero de em-presas que estao aderindo ao DDS; distribuindo seus processos de desenvolvimento desoftware globalmente. Entretanto, mesmo que a empresa seja certificada em algum mo-delo de qualidade, onde determinado nıvel de maturidade estabelece um processo decomunicacao promovendo dados e informacoes para apresentar o andamento ou status doprojeto, ainda nao consegue apresentar um processo de comunicacao direcionado, ou seja,suficientemente adequado para o Desenvolvimento Distribuıdo de Software onde fatoresexternos como dispersao geografica, a dispersao temporal e as diferencas culturais entreoutros tem grande impacto.

Por tal motivo, o Desenvolvimento Distribuıdo tem despertado interesse em um maiorvolume de pesquisas na area de Engenharia de Software[31]. Os engenheiros de software,pesquisadores da area, tem reconhecido a grande influencia desta nova forma de trabalhoe estao em busca de modelos que venham a facilitar o desenvolvimento de software comequipes geograficamente separadas ou dispersas.

Segundo Carmel [6], as principais caracterısticas que diferenciam o DesenvolvimentoDistribuıdo de Software do desenvolvimento co-localizado ou centralizado sao: dispersaogeografica, dispersao temporal e as diferencas culturais.

1

2 INTRODUCAO

O DDS, por ser altamente dependente da comunicacao, sofre com o impacto da dis-persao das equipes. Com as equipes distribuıdas geograficamente, a comunicacao acabatornando-se menos frequente e mais importante. A dispersao temporal, principalmentedevido a diferenca de fuso-horario, afeta atividades como, por exemplo, a elicitacao, ne-gociacao de requisitos e mudancas de escopo, introduzindo dificuldades como o contatosıncrono entre as equipes. O DDS, por necessitar e depender de um bom relacionamentoentre os envolvidos, tambem e influenciado pelas diferencas culturais entre os membrosdas equipes.

Portanto, a falta de um processo de comunicacao bem definido ou minimamente pa-dronizado para o DDS, torna-se um aspecto crıtico para o sucesso de projetos. Nestecontexto, esta dissertacao enfoca o processo de comunicacao de projetos distribuıdos desoftware.

1.2 OBJETIVOS

A comunicacao e um fator extremamente determinante para o sucesso dos projetos, sejameles centralizados ou distribuıdo. A distribuicao das equipes envolvidas no processo dedesenvolvimento de software apresenta diversos desafios, tanto para a Engenharia deSoftware quanto para as empresas que adotam esta nova forma de estrategia de negocio,ou seja, o desenvolvimento distribuıdo de software onde as empresas podem distribuir seusprocessos de forma global, tendo como um dos principais benefıcios, estar mais proximodo cliente, incentivos fiscais e equipes interdisciplinares. As equipes distribuıdas acabamsendo diretamente afetadas pela distancia fısica e temporal. Desta forma, fica evidenteque equipes necessitam de uma maior comunicacao via tecnologias, sejam elas via email,videoconferencia, chat ou teleconferencia dentre outras, para suprir a falta de reunioesface a face. Portanto, ambiguidades e problemas de entendimento sao muito frequentescom as diferencas de idioma e cultura. Diante deste cenario, questoes como gestao doconhecimento e fuso horario exercem impacto nas atividades das equipes em ambientesde Desenvolvimento Distribuıdo de Software (DDS) [31].

Essa pesquisa tem como principal objetivo o suporte necessario para a selecao de umconjunto de boas praticas a serem incorporadas na execucao do processo de comunicacaopara o desenvolvimento distribuıdo de software

1.3 DESCRICAO DO PROBLEMA

No cenario atual, com a possibilidade de pessoas separadas geograficamente poderem coo-perar no desenvolvimento de um determinado software, tornou-se necessario um controle,mais rigoroso das atividades relacionadas a gestao do projeto e mais especificamente noprocesso de comunicacao dos projetos.

Varias pesquisas foram realizadas em busca de modelo de referencia para Desenvol-vimento Distribuıdo de Software (DDS), tendo como um dos objetivos principais, deter-minar como as dificuldades relacionadas a comunicacao em DDS podem ser controladaspermitindo que as empresas garantam o sucesso em seus projetos. Diante deste contexto,e percebido que a comunicacao torna-se uma area negligenciada pelos gerentes de pro-

1.4 CONTRIBUICAO 3

jetos no DDS, pois os mesmos tratam o Desenvolvimento Distribuıdo de Software comodesenvolvimento centralizado de software (DCS).

Dentre as dificuldades encontradas em comunicacao no DDS, podemos citar: dife-rencas culturais, idioma, mudanca de escopo, informalidade, ausencia de infra-estruturade comunicacao entre outros.

O objetivo principal desta pesquisa e a elaboracao de uma proposta de boas praticasno processo de comunicacao para ambientes de Desenvolvimento Distribuıdo de Software.Deseja-se que essas praticas de comunicacao, sejam as mais adequadas possıveis para osmembros de projetos DDS.

1.4 CONTRIBUICAO

Esta dissertacao contribui para melhorar o processo de comunicacao no DesenvolvimentoDistribuıdo de Software (DDS). Seu objetivo principal e propor boas praticas para facilitaro gerenciamento da comunicacao nesse tipo de projeto. As contribuicoes que se destacamsao:

� Descrever as principais caracterısticas de DDS;

� Identificar as praticas utilizadas e relatadas em ambientes de Desenvolvimento Dis-tribuıdo de Software, sendo, o foco principal, na atividade de comunicacao;

� Identificar as principais categorias relacionadas a comunicacao em ambientes dedesenvolvimento distribuıdo de software;

� Propor boas praticas no processo de comunicacao para projetos de desenvolvimentodistribuıdos de software.

1.5 ORGANIZACAO DA DISSERTACAO

Esta dissertacao esta organizada em 7 capıtulos. O presente capıtulo exibe uma in-troducao sobre o contexto de Comunicacao dentro do Desenvolvimento Distribuıdo deSoftware. Apresenta, ainda, o objetivo central deste trabalho, a motivacao e a descricaodo nosso problema de pesquisa visando propor boas praticas para o processo de comu-nicacao no desenvolvimento distribuıdo de software.

No Capıtulo 2 introduzimos conceitos sobre modelo de qualidade de software, bemcomo a necessidade existente para a conducao dos mesmos em ambientes de desenvolvi-mento distribuıdos de software.

No Capıtulo 3 e apresentada uma contextualizacao do Desenvolvimento Distribuıdo deSoftware (DDS), bem como suas caracterısticas, desafios do DDS e problemas relacionadosao processo de comunicacao.

No Capıtulo 4, e definida a metodologia de pesquisa utilizada para a conclusaodesse trabalho. Nessa metodologia estao previstas a realizacao de uma entrevista semi-estruturada [20] com gerentes de projeto que participem ou tenha experiencia em projetoscom caracterıstica de Desenvolvimento Distribuıdo de acordo com Prikladnicki [41].

4 INTRODUCAO

No Capıtulo 5, sao apresentados os resultados do estudo e a analise das entrevistasrealizadas. Como resultado dessas pesquisa foram geradas informacoes e categorias quedarao suporte a proposicao das boas praticas no Capıtulo 6. Estas informacoes estaolistadas no Capıtulo 6.

ja as conclusoes e limitacoes do presente trabalho, bem como e as sugestoes paratrabalhos futuros, ficaram no Capıtulo 7.

CAPITULO 2

MODELOS DE QUALIDADE

O desenvolvimento de software com qualidade e com uma alta produtividade, no prazoestabelecido, sem precisar de mais recursos do que aqueles planejados e alocados, tem setornado um desafio para Engenharia de Software [46].

Qualidade nao e mais um diferencial de mercado para a empresa conseguir vender elucrar mais e um pre-requisito que a mesma deve obter ou conquistar para tentar colocaro seu produto no Mercado Global. O conceito de qualidade e sua aplicabilidade vemsendo fortemente disseminado em diversos setores empresariais e industriais.

E importante a utilizacao de modelos de qualidade, como ISO 12207, ISO 15504,CMMI, MPS.BR entre outros, que permitam estabelecer e avaliar os requisitos de quali-dade atraves de um processo de avaliacao bem definido e estruturado.

Um aspecto interessante da qualidade, e que nao basta sua existencia dentro do pro-cesso de desenvolvimento, e essencial, ainda, o seu reconhecimento pelo cliente. Por talmotivo, e necessario que exista algum tipo de certificacao oficial, emitida com base emum padrao, como por exemplo, os certificados de qualidade CMMI, MPS.BR, e os daserie ISO 9001 [13].

Manter a qualidade de software vem sendo uma preocupacao crescente e com grandeevidencia nas empresas de fabricas de software, tal fator deve-se inclusive devido aoaumento da concorrencia, mas tambem pelas exigencias dos clientes e pela necessidadede controle interno.

Atualmente existe uma grande preocupacao para criar modelos que venham a me-lhorar a avaliacao de qualidade tanto de produto de software quanto de processo dedesenvolvimento de software. Algumas iniciativas estao sendo fomentadas por governose instituicoes de pesquisas. A Tabela 2.1 apresenta os principais modelos de qualidade.A seguir cada um desses modelos serao apresentados em detalhes.

2.1 ISO/IEC 12207

A Norma NBR ISO/IEC 12207 foi criada em 1995 e tem como meta fornecer um templateou estrutura comum para fornecedores, clientes, desenvolvedores, mantenedores, opera-dores, gerentes e tecnicos envolvidos com o desenvolvimento de software. Desta forma, aISO 12207 tem como objetivo utilizar uma linguagem comum a todos, estabelecida porprocessos bem definidos, proporcionando uma melhor definicao dos papeis envolvidos eum entendimento das atividades a serem executadas. Esses processos sao classificadosde tres formas: Fundamentais, de Apoio e Organizacional. Esses processos conduzemuma melhor qualidade do produto quanto do Software [12]. A Figura 2.1 apresenta osprocessos.

5

6 MODELOS DE QUALIDADE

Tabela 2.1 Principais Modelos de Qualidade

Modelos DescricaoISO 12207 Processo de Ciclo de Vida do Software. Norma para a quali-

dade do processo de desenvolvimento de software.SPICE - ISO 15504 Projeto da ISO/IEC para avaliacao de processo de desenvol-

vimento de software.CMMI Capability Maturity Model Integration. Modelo do SEI (Ins-

tituto de Engenharia de Software do Departamento de Defesados EUA) para avaliacao da qualidade do processo de desen-volvimento de software.

MPS.BR Projeto coordenado pelo Softex, com o apoio do Ministerio deCiencia e Tecnologia - MCT, alem da Financiadora de Estu-dos e Projetos - FINEP e do Banco Interamericano de Desen-volvimento - BID para Melhoria do Processo de Software noBrasil.

2.1.1 Processos Fundamentais

Estes processos definem: aquisicoes, fornecimento, operacao e manutencao do ciclo devida do software encontram-se divididos nas seguintes atividades:

� Aquisicao - Atividade do cliente. Inicia-se com a necessidade de adquirir umsoftware.

� Fornecimento - Atividade do fornecedor do software. Inicia-se com a preparacaode propostas, contratos, planos de projeto e etc.

� Operacao - Atividade de quem opera o software. Inicia-se com a operacionalizacaodo software e suporte aos usuarios em sua operacao.

� Manutencao - Atividade do profissional ou equipe responsavel em fazer a manu-tencao do software.

2.1.2 Processos de Apoio

Define a documentacao, gestao de configuracao, gestao da qualidade, verificacao, va-lidacao, revisao conjunta, auditoria e resolucao de problemas.

� Documentacao - Atividade que registra as informacoes que sao produzidas porum processo ou atividade. Essa atividade inclui planejar, projetar, desenvolver,produzir, editar e manter todos os documentos que sao de interesse dos gerentes,engenheiros e usuarios do sistema.

2.1 ISO/IEC 12207 7

Figura 2.1 Processo da ISO 12207 [13]

� Gerencia de Configuracao - Atividade que faz o controle dos artefatos de soft-ware. Esta atividade tem como objetivo o controle de software, bem como, iden-tificar e definir itens de software em um sistema, estabelecer linhas bases tambemchamadas de baseline, liberar, manipular, distribuir e modificar cada item e artefatoque compoe o software.

� Garantia da Qualidade - Atividade que fornece garantia que o processo e produtode software estao em conformidade com os requisitos especificados e sao aderentesao plano estabelecido.

� Verificacao - Atividade que determina se os produtos de software atendem em suacompletude aos requisitos.

� Validacao - Atividade que valida os produtos de software que foram produzidos.Determina se os requisitos e o produto atendem ao seu uso especıfico proposto.

� Revisao Conjunta - Atividade que avalia a adequacao dos produtos de uma fasede um projeto, se apropriado. Elas sao feitas nos nıveis de gerenciamento do projeto,bem como, nos nıveis tecnicos. Sua execucao e feito durante a vigencia do contrato.

� Auditoria - Atividade que determina a adequacao do produto aos requisitos, planose contratos, quando for apropriado.

� Resolucao de Problemas - Atividade responsavel por analisar e resolver os pro-blemas de qualquer tipo de natureza, descobertos durante a execucao do desenvol-vimento, operacao e manutencao ou outros processos.


2.1.3 Processos Organizacionais

Tem como objetivo melhorar os processos dentro da organizacao. Esse processos contematividades organizacionais que sao as seguintes:

� Gerencia- Atividade responsavel pelo gerenciamento dos processos. O gerente eresponsavel pelo gerenciamento do produto e projeto.

� Infra-Estrutura - Atividade que estabelece e mantem a infra-estrutura adequadapara qualquer outro processo. A Infra-estrutura inclui hardware, software, ferra-mentas, tecnicas, padroes de desenvolvimento, operacao e manutencao.

� Melhoria - Atividade basica e necessaria que as organizacoes devem executar paraavaliar, medir, controlar e melhorar um processo de ciclo de vida de software.

� Treinamento - Atividade para prover uma melhor qualificacao dos profissionaise mante-los atualizados. E necessario que esses treinamentos sejam planejados eimplantados com antecedencia para que o pessoal a ser treinado esteja disponıvelquando necessario.

2.1.4 Visao Geral do Gerenciamento de Comunicacao na ISO 12207

O gerenciamento de comunicacao e fundamental para o sucesso dos projetos, sejam elescentralizados ou distribuıdos. Portanto, a Norma NBR ISO/IEC 12207 - Processos do Ci-clo de Vida do Software foi criada com o objetivo de fornecer uma estrutura comum paraque o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e tecnicosenvolvidos com o desenvolvimento de software utilizem uma linguagem comum. O pro-cesso de comunicacao permeia todos os processos da norma ISO 12027 que vai do processoFundamental, Apoio ate o Organizacional. A ausencia de um processo de comunicacaoformal nas normas e nos modelos de qualidade insere mais um desafio para o desen-volvimento de software, pois cada pessoa pode interpreta-la de uma forma, seja corretaou incorreta. A norma ISSO 12207 nao apresenta nenhuma pratica para o gerencia-mento da comunicacao, mas apresenta alguns sub-processos que mostram a claramentea necessidade da comunicacao para que venham a ter o sucesso esperado. Em seguidaapresentamos alguns dos sub-processos referentes aos processos Fundamentais, Apoio eOrganizacionais que deixam claro a necessidade de obter uma comunicacao legıvel e ob-jetiva.

O gerenciamento de comunicacao e fundamental para o sucesso dos projetos, sejameles centralizados ou distribuıdos. Portanto, a Norma NBR ISO/IEC 12207 - Processosdo Ciclo de Vida do Software foi criada com o objetivo de fornecer uma estrutura co-mum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes etecnicos envolvidos com o desenvolvimento de software utilizem uma linguagem comum.O processo de comunicacao permeia todos os processos da norma ISO 12027 que vai doprocesso Fundamental, Apoio ate o Organizacional. A ausencia de um processo de co-municacao formal nas normas e nos modelos de qualidade insere mais um desafio parao desenvolvimento de software, pois cada pessoa pode interpreta-la de uma forma, seja

2.1 ISO/IEC 12207 9

correta ou incorreta. A norma ISSO 12207 nao apresenta nenhuma pratica para o geren-ciamento da comunicacao, mas apresenta alguns sub-processos que mostram a claramentea necessidade da comunicacao para que venham a ter o sucesso esperado. Em seguidaapresentamos alguns dos sub-processos referentes aos processos Fundamentais, Apoioe Organizacionais que deixam claro a necessidade de obter uma comunicacao legıvel eobjetiva. A seguir serao apresentados os processos, no qual necessitam largamente dacomunicacao:Elicitacao de Requisitos - O proposito da Elicitacao de Requisitos e obter, processare acompanhar as necessidades e os requisitos do cliente ao longo da vida do produto e/ouservico, de forma a estabelecer a linha basica (baseline) de requisitos que serve de basepara a definicao dos produtos de trabalho necessarios. A Elicitacao de Requisitos pode serexecutada pelo adquirente ou pelo desenvolvedor do sistema. A seguir sao apresentadosalguns dos resultados referente ao processo comunicacao na elicitacao de requisitos:

� uma comunicacao contınua com o cliente e estabelecida;

� requisitos acordados com o cliente sao definidos e colocados sob uma linha basica(baseline);

� um mecanismo e estabelecido para o monitoramento contınuo das necessidades docliente.

Analise dos Requisitos do Software - O proposito da Analise dos Requisitos doSoftware e estabelecer os requisitos dos elementos de software do sistema. A seguirsao apresentados alguns dos resultados referente ao processo comunicacao na analise deelicitacao do software:

� a priorizacao para implementacao dos requisitos do software e definida;

� os requisitos do software sao aprovados e atualizados, sempre que necessario;

� as mudancas nos requisitos do software sao avaliadas quanto aos impactos nos as-pectos tecnicos, de custo e de cronograma;

Os requisitos do software sao colocados sob uma linha basica (baseline) ecomunicados a todas as partes envolvidas. - O Processo de Fornecimento contemas atividades e as tarefas do fornecedor. Esse processo inicia-se tanto por uma decisao depreparar uma proposta para responder a um pedido de proposta de um adquirente quantopela assinatura e celebracao de um contrato com o adquirente para fornecer o sistema,produto de software ou servico de software, e encerra-se com a entrega do sistema, produtode software ou servico de software para o adquirente.

O proposito da Proposta do Fornecedor e estabelecer uma interface para respon-der a requisicoes e solicitacoes de propostas, preparar e submeter propostas e confirmaratribuicoes atraves do estabelecimento de um acordo/contrato pertinente. A seguir saoapresentados alguns dos resultados referente ao processo comunicacao na gerencia deconfiguracao:

� Uma interface de comunicacao e estabelecida e mantida de forma a responder asrequisicoes e solicitacoes de propostas do cliente;


2.2 SPICE - ISO/IEC 15504

Tendo em vista que o modelo ISO 9000 encontrava-se em desvantagem, quando compa-rado a outros modelos que teriam sido concebidos especialmente para software; o ISOresolveu iniciar uma nova investigacao sobre a necessidade de se criar um padrao inter-nacional [13]. A ISO, ao visualizar essa falha decidiu em 1991, fazer uma investigacaosobre a real necessidade de se criar esse modelo internacional. Em 1992, os resultadosda investigacao indicaram a necessidade da criacao de um padrao internacional e a pu-blicacao de um primeiro relatorio tecnico. Para dar inıcio a este trabalho foi criado em1993 o projeto Spice - Software Process Improvement Capability dEtermination que temcomo objetivo definir o processo de desenvolvimento de software[1]. esse projeto e umaevolucao da ISO 12207. Em 1998, o ISO/IEC TR 15504 (relatorio tecnico) foi publicadopela primeira vez [1]. Uma das novidades do projeto Spice foi a inovacao da organizacaoem duas dimensoes, a de processos, e a de capacidade de processos.

A dimensao de processos.

E formada por processos do ciclo de vida do software definido no modelo de referenciade processos o qual e derivado diretamente da norma ISO 15504. Os processos saoagrupados em nove categorias conforme Tabela 2.2.

.

A dimensao de capacidade.

A capacidade de um processo e definida numa escala de seis pontos: O nıvel 0 (incom-pleto) ate o topo da escala que e o nıvel 5 (otimizado). A escala representa a maximizacaoda capacidade de desempenho do processo, desde um desempenho nao satisfatorio paraatingir os objetivos, ate um desempenho satisfatorio que e capaz de alcancar os objetivose de realizar melhorias relevantes, sendo que esses objetivos sao derivados dos objetivosde negocio da empresa. A escala dos nıveis define um percurso claro para melhorar indi-vidualmente cada processo conforme Figura 2.2.

Objetivos e Documentacao.

Tem como objetivo principal a melhoria do processo e a determinacao da capacidadedos processos em uma organizacao.

De acordo com Cortes [13], se o objetivo da organizacao for a melhoria de processos, amesma tera que realizar a avaliacao gerando um perfil dos processos que serao usados paraelaborar um plano de acao de melhorias conforme a Figura 2.3 apresenta. A organizacaodeve definir:

� Todos os objetivos e contextos para a avaliacao;

� Escolher modelos e metodos para avaliacao;

� Definir os objetivos de melhoria.

2.2 SPICE - ISO/IEC 15504 11

Tabela 2.2 Dimensoes de Processo do ISO 15504

Modelos DescricaoAquisicao Processos executados pelo cliente, com o intuito de adquirir

um produto e/ou servico.Suprimento Processos executados pelo fornecedor, com o intuito de propor

ou fornecer um produto e/ou servico.Engenharia Processos que identificam e gerem os requisitos do cliente, es-

pecificam, implementam e/ou mantem o produto de softwaree a sua relacao com o sistema.

Operacao Processos executados com o intuito de assegurar o corretofuncionamento e utilizacao do produto e/ou servico.

Fornecer Suporte Processos que podem ser utilizados no ambito de qualqueroutro processo em diversos pontos do ciclo de vida de desen-volvimento de software.

Melhoria de Processo Processos que contem praticas que podem ser utilizadas porquem gere qualquer tipo de projeto ou processo dentro dociclo de vida de desenvolvimento de software.

Gerenciamento Processos executados com o intuito de definir, implementar,avaliar e melhorar os processos executados na unidade orga-nizacional.

Recurso e Infra-Estrutura Processos executados com o intuito de disponibilizar os recur-sos (humanos e de infra-estrutura) necessarios para a execucaode qualquer outro processo executado dentro da unidade or-ganizacional.

Reuso Processos executados para aproveitar de forma sistematica asoportunidades de reutilizacao dentro da organizacao.

Caso o objetivo seja avaliar um fornecedor em potencial, e necessario obter o seu perfilde capacidade. A organizacao deve definir de acordo com a Figura 2.4.

� Todos os objetivos e contextos para a avaliacao;

� Os modelos e metodos para avaliacao e os requisitos esperados.

A obtencao do perfil de capacidade do fornecedor permite ao contratante estimar orisco da contratacao. Essa informacao auxilia na tomada de decisao para contratar ounao o fornecedor.


Figura 2.2 Nıveis de Capacidade da ISO 15504

Figura 2.3 Melhoria do Processo Organizacional [13]

2.2 SPICE - ISO/IEC 15504 13

Figura 2.4 Melhoria da Capacidade Organizacional [13]

Figura 2.5 Estrutura da Organizacao dos Documentos do Modelo ISO 15504 [1]


Os documentos do projeto Spice foram organizados em nove partes. Dentre estas,duas sao normativas e as demais sao informativas. Logo em seguida, cada uma das par-tes sao detalhadas conforme a Figura 2.5 e a norma [1].

A Parte 1 (informativa) e uma introducao ao ISO/IEC TR 15504; descreve os requi-sitos contidos dentro do ISO 15504 e a sua aplicabilidade na execucao de uma avaliacao.

Ja a Parte 2 (normativa) define um modelo de referencia que descreve os processos eos seus nıveis de capacidade usado nas avaliacoes. Nesta parte tambem sao definidos re-quisitos para o estabelecimento de compatibilidade entre diferentes modelos de avaliacaoe o modelo de referencia.

Quanto a Parte 3 (normativa) esta define os requisitos para a execucao da avaliacaocom o objetivo de que os resultados sejam passıveis de repeticao, confiaveis e consistentes.

A Parte 4 (informativa) fornece orientacoes para a execucao de avaliacoes de processosde software e interpretacao de requisitos em contextos diferentes. Estas orientacoes saocaracteristicamente genericas demais para serem aplicadas a todas as organizacoes.

Na Parte 5 (informativa) forcene um exemplo de um modelo para avaliacoes de pro-cessos que e baseado e compatıvel com o modelo de referencia.

Esta Parte 6 (informativa) descreve os requisitos para a qualificacao dos avaliadoresque possa ser relevante para a execucao da avaliacao de processos. Esta parte apresentaos meios que podem ser usados para demonstrar a competencia, para validar a formacao,treino e experiencia dos avaliadores.

Acerca da Parte 7 (informativa), esta descreve orientacoes para fins de melhoria deprocessos. Descreve, tambem, como se definem as entradas para a execucao da avaliacaoe como se utilizam os resultados da mesma em busca da melhoria do processo.

Na Parte 8 (informativa), tem-se a definicao de orientacoes para fins de avaliacao dacapacidade, ou seja, descreve a forma como se definem as entradas para a execucao daavaliacao e como se utilizam os resultados da mesma quando utilizados com o objetivode determinacao da capacidade dos processos.

Por fim, a Parte 9 (informativa) que e um vocabulario consolidado com os termosespecıficos definidos no ambito do ISO/IEC TR 15504.

2.2.1 Visao Geral do Gerenciamento de Comunicacao na ISO 15504

A melhoria do processo de comunicacao tem demonstrado na pratica ser altamente re-levante e viavel, alem de eficaz e eficiente para a necessaria melhoria das organizacoesintensivas em software. Melhoria de processo e na verdade uma abordagem para a me-

2.2 SPICE - ISO/IEC 15504 15

lhoria das organizacoes, em direcao a objetivos de negocio, por meio da melhoria dacapacidade de seus processos mais importantes. Dentro deste contexto, o processo decomunicacao vem sendo evidenciado nos ultimos anos.

O gerenciamento do processo de comunicacao na norma ISO 15504 em comum comoutros modelos, nao e um processo explıcito, pois se faz necessario que venhamos ainterpreta-lo para instancia-lo dentro de um contexto, seja ele, em um desenvolvimentotradicional ou distribuıdo.

Um aspecto importante da melhoria de processo e a identificacao do equilıbrio dograu de formalizacao do processo como a complexidade da comunicacao em um projeto.Um excesso de formalizacao do processo pode causar ”burocracia”enquanto que umainsuficiencia de formalizacao pode causar ”anarquia”.

Uma forte tendencia atual e a ampliacao da abrangencia da melhoria de processo desoftware para a melhoria de processo de software e sistemas. O principal framework decapacidade de processo (ISO/IEC TR 15504) foi evoluıdo e sua respectiva nova versao(ISO/IEC 15504) define framework generico para modelos de qualquer disciplina.

A norma ISO 15504 apresenta praticas de comunicacao em seus respectivos nıveis decapacidade (de 0 a 5) que nao sao explıcitas na norma, mas que podemos interpreta-lase utiliza-las para estabelecer este processo. Vejamos, logo em seguida, os principais sub-processos referente a comunicacao em alguns nıveis de capacidade, e como os mesmospodem nos auxiliar na obtencao de uma comunicacao efetiva.

Nıvel 2 (Processo Gerenciado) - neste nıvel podemos perceber alguns subprocessosde comunicacao:

� Os recursos e a informacao necessaria para a execucao do processo sao identificadas,disponibilizadas, alocadas e utilizadas;

� As interfaces entre as partes envolvidas sao gerenciadas para garantir comunicacaoefetiva e atribuicao clara de responsabilidades;

� Atribuicao e comunicacao de responsabilidades e autoridades para executar o pro-cesso;

� Os recursos e informacoes necessarios para implementar o processo de acordo com osobjetivos identificados de execucao do processo sao identificados, disponibilizados;

� Gerenciamento as partes envolvidas para assegurar uma comunicacao efetiva e aclara atribuicao das responsabilidades;

� Registros de qualidade tais como registros pessoais, atas de reuniao.

Nıvel 3 (Processo Estabelecido) - podemos visualizar alguns subprocessos decomunicacao:

� Definicao de uma infra-estrutura para a comunicacao (ferramentas, metodos e etc);


� Prover repositorio de conhecimento para a compreensao e melhoria do processopadrao;

� Os papeis necessarios, responsabilidades e autorizacoes para execucao do processodefinido sao designados e comunicados;

� Os recursos e informacao necessarios para a execucao do processo definido sao dis-ponibilizados.

Nıvel 4 (Processo Previsıvel) - logo em seguida, podemos perceber alguns dosprincipais subprocessos de comunicacao:

� Coletar as medidas e em seguida analisadas e comunicadas as partes interessadaspara permitir a monitoracao;

� Institucionalizar informacoes para medicao.

Percebe-se que o PMBOK atraves do seu processo de gerenciamento da comunicacaopode ser muito util para auxiliar a norma na definicao clara do processo de comunicacaoatraves do seu planejamento e suas tecnicas. Logo, o PMBOK pode ser utilizado paraatender algumas praticas dentro de determinados nıveis de capacidade para deixar oprocesso de comunicacao mais explicito e efetivo.

O sucesso do processo de comunicacao, ou do planejamento da comunicacao melhorao uso de modelos/normas e documentos auxiliares para seu entendimento e sua corretaaplicacao dentro das organizacoes.

2.3 CMMI

O CMMI, modelo criado pelo SEI (Software Engineering Institute Carnegie Mellon Uni-versity) e com o objetivo de integrar os modelos ja existentes, como o CMM (CapabilityMaturity Model) e SECM (Systems Engineering Capability Model ), solucionando, assim,o uso dos multiplos CMMs. Alem disso, o CMMI tambem incorporou licoes aprendidasdurante varios anos de utilizacao dos modelos do SEI, eliminando desta forma, incon-sistencias, reduzindo inclusive redundancias e aumentando assim a clareza no uso dostermos comuns.

Segundo Becker [3], dois conceitos que permeiam a concepcao dos modelos do SEIsao: as ideias de capacidade e as de maturidade de processo.

A capacidade apresenta o intervalo de resultados que podem ser atingidos e, aindaos resultados esperados atraves da utilizacao de um processo, e desta forma prove ummeio de prognosticar os resultados caracterısticos dos projetos a serem desenvolvidos pelaorganizacao. A maturidade simboliza as condicoes para o crescimento da capacidade deuma organizacao e informa a consistencia e riqueza do processo com o qual ele e aplicadono contexto da organizacao [3]. A principal mudanca do CMMI em comparacao como SW-CMM, e a opcao de utilizacao de duas abordagens diferentes para a melhoria doprocesso. As abordagens sao:

2.3 CMMI 17

� Contınuo - Tem como objetivo a maturidade da organizacao atraves de um pro-cesso evolutivo para sua melhoria. Essa representacao ajuda as organizacoes quedesejam a melhoria de seus processos de desenvolvimento de software.

� Estagios - Tem como objetivo a melhoria de processo de forma sistemica e es-truturada, alem de apresentar um meio mais facil ou flexıvel para a implantacaodas melhorias. Essa abordagem permite que as organizacoes possam escolher asareas para a implantacao das melhorias, bem como implantar nıveis distintos paradiferentes processos.

.

2.3.1 Nıveis de Maturidade

O modelo CMMI esta dividido em cinco nıveis de maturidade conforme a Figura 2.6 esuas areas de processo.

Figura 2.6 Nıveis de Maturidade do CMMI

.

Detalhes sobre os Nıveis de Maturidade.

Os Nıveis de maturidade baseiam-se em um conjunto pre-definido de areas de processo,sao eles:

� Nıvel de maturidade 1: (Inicial) - Neste nıvel, os processos sao muito infor-mais e a organizacao, geralmente, nao dispoe de um ambiente estavel. Sucessonestas organizacoes depende do talento e competencia das pessoas na organizacao e


nao na utilizacao dos processos. Organizacoes com esta maturidade, normalmenteproduzem produtos e servicos que funcionam, entretanto, eles frequentemente ul-trapassam o prazo e orcamento de seus projetos.

� Nıvel de maturidade 2: (Gerenciado) - Uma organizacao obteve as metasespecıficas e genericas de areas de processo, ou seja, os projetos das organizacoesasseguram quais requisitos sao gerenciados e quais processos sao planejados, execu-tados, medidos, e controlados.

� Nıvel de maturidade 3: (Definido) - A organizacao obteve metas especıficas egenericas das areas de processo concedidas aos nıveis 2 e 3. Cabe saber acerca damaturidade, que os processos sao bem entendidos.

� Nıvel de maturidade 4: (Quantitativamente Gerenciado) - Aqui, uma orga-nizacao obteve todas as metas especıficas das areas de processo determinadas paraos nıveis de maturidade 2, 3 e 4, bem como, metas genericas dos nıveis de maturi-dade 2 e 3. Subprocessos sao selecionados que significativamente contribuam a todaparte de desempenho de processo. Estes subprocessos selecionados sao controladosusando tecnicas estatısticas e outras tecnicas quantitativas.

� Nıvel de maturidade 5: (Otimizado) - Neste, uma organizacao obtem todasas metas especıficas das areas de processo determinadas para os nıveis 2, 3, 4 e 5com metas genericas determinadas para os nıveis 2 e 3. Os Processos sao continua-mente melhorados e baseiam-se em entendimentos quantitativos de causas comunsde variacao inerente aos processos.

2.3.2 Areas de Conhecimento do CMMI

O objetivo do CMMI e fornecer um CMM que aborde o desenvolvimento do produto ouservico alem da manutencao, permitindo a inclusao de novas disciplinas ou areas de co-nhecimento do CMMI. Atualmente o CMMI descreve quatro areas de conhecimento queajudam na melhoria do processo: i)engenharia de sistemas, ii)engenharia de software,iii)produtos integrados, iv)desenvolvimento de processos e fornecimento de recursos [35],[10]. Essas disciplinas sao descritas logo em seguida.

Engenharia de Software: onde o objetivo principal e o desenvolvimento de soft-ware aplicando uma abordagem sistematica, disciplinada e quantificavel para o desenvol-vimento, operacao e manutencao do software [10], [35];

Engenharia de Sistemas: esta coberto o desenvolvimento de sistemas completo.O foco principal e transformar as necessidades, expectativas e restricoes do cliente emprodutos e assistencia dos mesmos durante seu ciclo de vida [10];

Desenvolvimento integrado de processo e produto: aborda de uma forma sis-tematica o relacionamento e interacao dos stakeholders mais representativos durante otempo de vida do produto. Os processos utilizados nesta disciplina estao integrados a

2.3 CMMI 19

outros processos da organizacao, portanto os projetos sao caracterizados por uma grandequantidade de equipes de diferentes areas de conhecimento e processo [10].

Fornecimento de Recursos: essa disciplina tem como foco aquisicao ou subcon-tratacao de servicos ou produtos para agilizar e facilitar o desenvolvimento do projeto,principalmente quando o esforco de trabalho e muito grande ou complexo.[10]).

As disciplinas de Engenharia de Software e Engenharia de Sistemas, segundo o CMMI,podem ser aplicadas individualmente ou em conjunto. Ja as disciplinas de Desenvolvi-mento integrado de processo e produto e Fornecimento de Recursos devem ser aplicadasmediante a aplicacao das anteriores.

2.3.3 Visao Geral do Gerenciamento de Comunicacao no CMMI

O gerenciamento de comunicacoes e uma area de conhecimento que atraves dos seusprocessos asseguram uma correta comunicacao entre as partes interessadas, ou seja, osstakeholders [24]. O modelo CMMI avalia a maturidade organizacional, alem das capa-cidades dos processos utilizados em cada organizacao [11].

O CMMI apresenta algumas praticas de comunicacao que nao sao explıcitas no mo-delo, mas que podemos interpreta-las e utiliza-las para estabelecer este processo. Sabemosque e-mails, relatorios nao garantem a efetiva comunicacao, por isso e importante queexista um processo formal e bem definido atraves das partes interessadas. Ademais, enecessario saber como e quando essa comunicacao pode ser estabelecida. Vejamos, logoem seguida, como o CMMI pode nos auxiliar a obter uma comunicacao efetiva.

Planejar o processo.

Aqui abordamos a abrangencia no planejamento das praticas especıficas desta area deprocesso. Em outras palavras, esta pratica generica do CMMI solicita fazer o ”planeja-mento do plano”. no planejamento inclui-se atribuicao de tempo, recursos e habilidadespara realizacao dos processos, junto a descricao de quais serao ou nao realizados emdeterminado projeto.

As comunicacoes em diversos momentos, tem a atribuicao de multitarefas, e as vezesuma unica mensagem pode desencadear diversas respostas e troca de mensagens. Casoesse fluxo de mensagens nao seja esperado pelo emissor ou gestor, esse ocorrido podegerar um grande transtorno para o projeto.

Identificar e envolver os stakeholders importantes.

Esta pratica e necessaria a selecao do stakeholders relevantes para o projeto a partirdos gerentes de projetos, gerentes funcionais do projeto, fornecedores, clientes dentreoutros que podem ser afetados (ou afetar) o projeto. Desta forma o CMMI consegueestabelecer atividades que necessitam de uma comunicacao correta como: estabelecerestimativas, resolver questoes sobre riscos no projeto, estabelecer planos de projeto entre


outras.Alem disso, uma vez selecionado os stakeholders mais relevantes, podemos delimitar

quem e responsavel por tal atividade e quem ira receber as devidas informacoes semgerar um broadcast de mensagens dentro do projeto. Para obter uma boa selecao dosstakeholders do projeto e necessario saber quais dos selecionados tem especializacoes paraexecutar tal atividade.

E importante salientar que um plano de envolvimento com stakeholders deve conter:justificativas para o envolvimentodo dos mesmos; papeis e responsabilidades em relacaoao projeto; relacionamento entre os stakeholders ; importancia e otimismo em relacao aosucesso do projeto; recursos necessarios para assegurar a interacao dos stakeholders (trei-namento,tempo, financas, materias).

Distribuicao das informacoes.

Este processo de distribuicao das informacoes engloba informacoes importantes li-gadas ao projeto; informacoes estas totalmente disponıveis para as partes interessadasno momento apropriado, ou seja, disponibilizadas de forma adequada a informacao cor-reta, as pessoas certas. Esse processo esta localizado na fase de execucao do projeto,onde a distribuicao dessas informacoes comeca a efetivar o que fora previsto no geren-ciamento de comunicacao. Entretanto, dado que o CMMI promove uma estrutura paragerenciamento de processos e melhores praticas para Engenharia de Software, o termocomunicacao aparece atraves do texto do modelo, mas nao ha nada explıcita a execucaodo processo de distribuicao de informacao. Os elementos do modelo que se relacionammais claramente com componente de comunicacao sao as praticas genericas, as quais naoiremos nos aprofundar nesta pesquisa.

Diante deste contexto, no modelo CMMI podemos encontrar alguns elementos doprocesso de distribuicao das informacoes ao longo de diversas praticas de variadas areasde processo, dentre as quais destacamos:

� Institucionalizar um processo gerenciado - envolve revisar as atividades, sta-tus e resultados do processo com os nıveis gerenciais mais elevados, buscando porfim, resolver dificuldades.

� Monitorar o plano frente ao projeto - esta pratica busca revisar o processoperiodicamente, sua performance e problemas do projeto para manter os stakehol-ders sempre informados, ou seja, comunicar frequentemente o status de atividadesatribuıdas e produtos de trabalho. Esta pratica do CMMI estabelece que tais re-visoes podem ser informais e nao devem ser explicitamente especificadas nos planosde projeto.

� Fornecer Resultados de Medicoes - esta pratica estabelece que os resultados dasatividades de medicoes e analises sao comunicados para os stakeholders importantesde forma adequada e no momento apropriado.

.O PMBOK atraves do seu processo de gerenciamento da comunicacao pode auxiliar na

2.4 MPS.BR 21

definicao do processo de comunicacao atraves do planejamento da comunicacao e suastecnicas apresentadas, as quais os modelos de qualidade nao apresentam especificamente.Logo, o PMBOK pode ser utilizado para atender algumas praticas de comunicacao soli-citadas pelo CMMI e outros modelos de qualidade. O exito do processo de comunicacao,ou do planejamento da comunicacao melhora o uso de modelos e documentos auxiliaresao processo como ferramenta de suporte para uma boa comunicacao.

2.4 MPS.BR

A Associacao para Promocao e Excelencia do Software Brasileiro, criou em dezembro de2003 o Modelo de Melhoria de Processo de Software Brasileiro (MPS.BR) com o objetivode aumentar a qualidade do processo de desenvolvimento de Software em organizacoesmicro, pequenas e medias empresas que nao possuem recursos financeiros suficiente paraa implantacao de modelos como CMMI [48]. O MPS.BR e um programa coordenado peloSoftex, com o apoio do Ministerio de Ciencia e Tecnologia - MCT, alem da Financiadorade Estudos e Projetos - FINEP e do Banco Interamericano de Desenvolvimento - BID[45].

Este modelo tem como base tecnica para sua composicao as normas NBR ISO/IEC12207 - Processo de Ciclo de Vida do Software, ISO/IEC 15504 - Avaliacao de Processo,e de forma complementar o modelo abrange conteudo de outros modelos de referencia deprocesso como o CMMI [10] com o qual esta em conformidade. O modelo tambem temdefinidas algumas regras para a implementacao e avaliacao com intuito de dar sustentacaoe uma maior garantia de que esta sendo executado conforme suas definicoes. A Figura2.7 apresenta os tres componentes do modelo MPS.

� MR-MPS (Modelo de Referencia para Melhoria de Processo de Software) - temcomo objetivo orientar a realizacao de avaliacoes, em conformidade com a normaISO/IEC 15504, em empresas e organizacoes que implementaram o MR-MPS.

� MA-MPS (Metodo de Avaliacao para Melhoria de Processo de Software) o Softexatraves de seus agentes e algumas instituicoes no Brasil tem larga experiencia nagestao e formacao de grupos de empresas para melhoria de processo de software,seja voltado a implementacao e certificacao ISO 9000, seja grupos de empresasvoltados a implementacao e avaliacao CMM e CMMI. Baseado nestas experienciasconcebeu-se para o Projeto MPS.BR um Modelo de Negocio (MN-MPS) que preveduas situacoes:

1. A implementacao do MR-MPS de forma personalizada para uma empresa(MNE - Modelo de Negocio Especıfico);

2. A implementacao do MR-MPS de forma cooperada em grupos de empre-sas (MNC - Modelo de Negocio Cooperado), com custo mais baixo, ficandoacessıvel as micro, pequenas e medias empresas, alem de dividir todo o custoproporcionalmente entre as empresas e por buscar outros meios de financia-mento.


� MN-MPS (Modelo de Negocio para Melhoria de Processo de Software) descreveregras para o negocio com o intuito de: implementacao do Modelo de ReferenciaMR-MPS pelas Instituicoes Implementadoras (II); avaliacao seguindo o Metodo deAvaliacao MA-MPS pelas Instituicoes Avaliadoras (IA); organizacao de grupos deempresas para implementacao do MR-MPS e avaliacao MA-MPS pelas InstituicoesOrganizadoras de Grupos de Empresas (IOGE); Certificacao de Consultores deAquisicao (CA) de software e servicos correlatos, de acordo com o Guia de Aquisicaodo MPS.BR; realizacao de treinamentos e provas no Modelo MPS.

Figura 2.7 Componentes do MPS.BR

O Modelo de Referencia MR-MPS define nıveis de maturidade (Ver Figura 2.8) quesao uma combinacao entre processos e sua capacidade.

Figura 2.8 Nıveis de Maturidade do MPS.BR

2.4 MPS.BR 23

2.4.1 Nıveis de maturidade

.

O modelo MPS.BR esta dividido em SETE nıveis de maturidade conforme a Figura2.8 e suas areas de processo.

Detalhes sobre os Nıveis de Maturidade.

� Nıvel de maturidade A: (Em Otimizacao) - e formado pelos processos dosnıveis de maturidade anteriores (G ao B), acrescido do processo Analise de Causasde Problemas e Resolucao.

� Nıvel de maturidade B: (Gerenciado Quantitativamente) - e formado pelosprocessos dos nıveis anteriores (G ao C), sendo que acrescidos dos processos deDesempenho do Processo Organizacional e Gerencia Quantitativa do Projeto.

� Nıvel de maturidade C: (Definido) - e formado pelos processos dos nıveisde anteriores (G ao D), acrescidos dos processos Analise de Decisao e Resolucao,Desenvolvimento para Reutilizacao e Gerencia de Riscos.

� Nıvel de maturidade D: (Largamente Definido) - e formado pelos proces-sos dos nıveis anteriores (G ao E), acrescidos dos processos Desenvolvimento deRequisitos, Integracao do Produto, Projeto e Construcao do Produto, Validacao eVerificacao.

� Nıvel de maturidade E: (Parcialmente Definido) - e formado pelos processosdos nıveis anteriores (G e F), acrescidos dos processos Avaliacao e Melhoria do Pro-cesso Organizacional, Definicao do Processo Organizacional, Gerencia de RecursosHumanos e Gerencia de Reutilizacao. O processo de Gerencia de Projetos sofre suaprimeira evolucao retratando seu novo proposito que e o gerenciamento com baseno processo definido para o projeto e planos integrados.

� Nıvel de maturidade F: (Gerenciado) - e formado pelos processos do nıvel ante-rior (G) acrescidos dos processos de Aquisicao, Gerencia de Configuracao, Garantiada Qualidade e Medicao.

� Nıvel de maturidade G: (Parcialmente Gerenciado) - e formado pelos pro-cessos Gerencia de Projetos e de Gerencia de Requisitos.

2.4.2 Visao Geral do Gerenciamento de Comunicacao no MPS.BR

O gerenciamento de comunicacoes no MPS.BR nao e muito diferente do modelo CMMI.Para estes dois modelos o PMBOK e um parceiro muito importante, pois estimula omelhoramento efetivo do processo de comunicacao. No MPS.BR o processo Gerencia de


Projetos estabelece a comunicacao tendo como benefıcio informacoes sobre o andamentodo projeto para a tomada de decisoes e acoes sobre ele.

A seguir iremos dar uma visao abrangente do gerenciamento de comunicacoes quepermeia por alguns nıveis como G, E e D do MPS.BR.

Os dados relevantes do projeto sao identificados e planejados quanto aforma de coleta, armazenamento e distribuicao

Para o MPS.BR os dados do projeto fornecem varias formas de documentacao queservem de entradas para a comunicacao como por exemplo: relatorios; dados informais;estudos e analises; atas de reunioes; licoes aprendidas; artefatos gerados; itens de acao eindicadores.

A comunicacao destes dados podem estar em qualquer formato, tais como: impressosou desenhados em diversos materiais; fotografias; meio eletronico entre outros formatos.Estes dados sao disponibilizados para todos os stakeholders relevantes do projeto paraque se tenha uma boa comunicacao sobre as informacoes importantes do projeto. O Planodo Projeto no MPS.BR e revisado com todos os interessados e o compromisso com elee obtido. Alcancar o compromisso, requer uma comunicacao entre todos os interessadosrelevantes internos e externos ao projeto. A reuniao de inıcio do projeto pode ser utilizadapara definir papeis e solucionar conflitos, alem de obter o comprometimento da equipeque esta envolvida no projeto. A comunicacao com os interessados neste modelo e tratadacomo fator fundamental para que o projeto possa efetivamente contar com os recursosplanejados, para atingir as metas definidas, ou seja, para atingir o sucesso no projeto.

A evolucao do projeto e acompanhado e monitorado com relacao ao que foi esta-belecido no Plano do Projeto com os resultados deste monitoramento sao efetivamentedocumentados.

O envolvimento das partes interessadas no projeto e gerenciado

Neste momento, devem ser identificados os mais importantes interessados no projeto,onde e como eles serao envolvidos Entretanto, podemos perceber que a comunicacao en-tre as partes interessadas, engloba varias questoes relativas a prazos, custos, recursos etambem requisitos, pois os mesmos impactam nas outras variaveis. Um plano de geren-ciamento das comunicacoes bem definido e institucionalizado, conforme apresentado noPMBOK [24], pode cobrir este resultado esperado. Quando falamos em resultado espe-rado, devemos lembrar que este e aderente ao nıvel G, no qual faz-se mensao a Gerenciade requisitos. Em relacao a comunicacao, esta e necessaria para o melhor entendimentodos requisitos estar junto as partes interessadas (os stakeholders) facilitando assim, oentendimento das necessidades que realmente o projeto devera atender.

Alem da comunicacao, e primordial verificar se os compromissos firmados pelas partesinteressadas estao sendo cumpridos (ou negociados), visando, assim, identificar aquelesque nao foram satisfeitos ou que possuem um grande risco de nao serem satisfeitos. Sa-bendo desta informacao, sera necessario alguns ajustes para que os compromissos sejamefetivamente cumpridos.

2.5 CONSIDERACOES FINAIS 25

O entendimento dos requisitos e obtido junto aos fornecedores de requisitos

A correta e efetiva comunicacao com os fornecedores de requisitos e extremamenteimportante para garantir um claro entendimento das necessidades do cliente e dos requi-sitos do projeto, conforme descrito anteriormente. Os fornecedores de requisitos devemser identificados a partir de alguns criterios predefinidos; o entendimento dos requisitosdeve ser obtido junto a estes fornecedores de requisitos; as comunicacoes devem ser regis-tradas em atas, e-mails, ferramentas de comunicacao, sendo necessaria uma comprovacaode que os interessados estao totalmente de acordo com o conteudo registrado.

O nıvel E tem como objetivo padronizar processos da organizacao, por meio da de-finicao dos mesmos, sendo instanciados a partir dos processos e melhores praticas jaexistentes na organizacao, havendo desta forma uma busca por melhoria contınua. Oproposito do processo Gerencia de Projetos, no que tange a comunicacao e prover in-formacoes sobre o status e progresso do projeto, alem de estabelecer e manter planos quedefinem as atividades, recursos e responsabilidades do projeto.

No nıvel D os requisitos sao validados. Este resultado esperado visa garantir a va-lidacao dos requisitos, desde as fases iniciais do ciclo de vida, atraves de uma comunicacaoeficiente, aumentando desta forma a confianca de que os requisitos elicitados e definidossao capazes de guiar e assegurar o bom desenvolvimento de software.

2.5 CONSIDERACOES FINAIS

Um modelo de qualidade de software implantado com sucesso, nao e somente um con-junto de polıticas, processos e procedimentos. Organizacoes que pretendem adotar algummodelo de qualidade precisam reunir esforcos nos princıpios da comunicacao, para pro-mover uma melhora efetiva dos seus processos. Os melhores processos, envolvem pessoase conhecimento. A documentacao nao deve ser o objetivo da melhoria do processo, o ob-jetivo deve ser a melhoria da comunicacao. Documentos sao um meio para se comunicar,mas nao sao os unicos existentes.

Muitas organizacoes objetivam apenas conseguir o selo de qualidade, e nao analisamde que forma essa implantacao pode melhorar sua estrutura organizacional. Sendo assim,perdem a oportunidade de aumentar a sinergia de suas operacoes atraves da melhoriados contınua dos seus processos.

Em todo modelo de qualidade e visıvel a grande necessidade da comunicacao eficiente,para que todos os processos venham a fluir de maneira positiva. E possıvel perceber quea comunicacao permeia todo o projeto do inıcio ao fim, necessitando que o gerente deprojeto ou lıder de implantacao se preocupe com o benefıcio qualitario para todos, ouseja, com clientes alcancando o melhor entendimento e alta qualidade de atendimentojunto aos ganhos financeiros sao conquistados com o aumento da produtividade.

Finalmente, observa-se que as empresas estao se preocupando cada vez mais com aadocao de modelos de qualidade, as mesmas se preocupam com a cerfiticacao de seus pro-cessos para que possam prover maior qualidade em seus produtos e/ou servicos. Contudo,


mediante este novo desafio da engenharia de software em ter que desenvolver softwarecom equipes separadas geograficamente, onde esses modelos nao dizem o como fazer esim o que fazer. Baseado nisso, foi estudado como funciona a comunicacao em algunsmodelos de qualidade e foi claro que a maioria tratam a comunicacao em todo o modelo,ou seja, a comunicacao permeia todo os nıves de maturidades dos modelos de qualidadenao tendo um documento ou secao que trate especificamente da comunicacao.

Se ja e complicado gerir a comunicacao em projetos centralizados, em projeto dis-tribuıdos podemos imaginar como sera este desafio. Diante deste cenario iremos buscarcriar um documento que trate especificamente da reuniao de boas praticas para a comu-nicacao em DDS.

CAPITULO 3

DESENVOLVIMENTO DISTRIBUIDO DE SOFTWARE(DDS)

Na ultima decada, grandes investimentos ocorreram para promover a expansao e con-versao de mercados nacionais em mercados globais. Consequentemente surgiram, novascategorias de competicao e colaboracao entre os paıses [19]. Nesse ambiente, muitas orga-nizacoes encontraram no Desenvolvimento Distribuıdo de Software (DDS) uma chance deobter o sucesso nos seus negocios que vinham passando por diversas crises. Atualmenteum grande numero de organizacoes desenvolve software com equipes geograficamentedistribuıdas [28],[42].

Entre os fatores que tem contribuıdo para o crescimento do DDS, podemos destacar:

� o custo mais baixo e disponibilidade de mao de obra;

� a evolucao e maior acessibilidade a recursos de telecomunicacao;

� a evolucao das ferramentas de desenvolvimento;

� a necessidade de possuir recursos globais para utilizar em qualquer momento;

� as vantagens de estar perto do mercado local;

� a formacao de equipes distribuıdas para explorar oportunidades de mercado;

� e a pressao para o desenvolvimento time-to-market, ou seja, com reducao de prazo,utilizando as vantagens proporcionadas pelo fuso horario diferente.

Neste sentido, o DDS tem atraıdo um grande numero de pesquisas na area de En-genharia de Software [42], [18]. Considerando sua atual aplicacao e ampla abrangencia,o DDS possui uma grande diversidade de conceitos que ajudam a sua caracterizacao.Dentro do contexto de desenvolvimento distribuıdo podem ser aplicados conceitos deequipes globais [32], e organizacoes virtuais, que aumentam a extensao do conhecimentoenvolvido.

De acordo com Marquardt [32], uma equipe global refere-se a um grupo de pessoasde diferentes nacionalidades que trabalham unidas em um projeto comum, atraves deculturas e fuso-horario distintos, por um extenso perıodo de tempo. Quando a distanciafısica entre os atores de um ambiente de DDS envolve mais de um paıs, Karolak [28] defineuma instancia do DDS chamada de desenvolvimento global de software (Global SoftwareDevelopment - GSD). O GSD e instanciado atraves de equipes globais de desenvolvimentode software (Global Software Teams), que Carmel [6] define como sendo um grupo depessoas distribuıdas em dois ou mais paıses, colaborando ativamente em um projeto

27

28 DESENVOLVIMENTO DISTRIBUIDO DE SOFTWARE (DDS)

comum. Por conseguinte, o DDS tem sido caracterizado pela colaboracao e cooperacaoentre departamentos de organizacoes e pela criacao de grupos de desenvolvedores quetrabalham em conjunto, localizados em cidades ou paıses diferentes.

A Figura 3.1ilustra um gerente com sua equipe em uma mesma localidade fısica eum outro ambiente onde o gerente esta com sua equipe distribuıda em outras cidades,estados ou paıses. As figuras ilustram a mudanca para o novo cenario[28].

Figura 3.1 Equipe centralizada e distribuıda

3.1 MOTIVACOES PARA O DDS

Em decadas anteriores o desenvolvimento de software costumava ser realizado apenas porprofissionais com alto nıvel de especializacao trabalhando em Centro de Processamentode Dados (CPD) em paıses do primeiro mundo [40]. Atualmente, o desenvolvimento desoftware vem ocorrendo de uma forma cada vez mais distribuıda. Conforme Prikladinick[40], no ano de 2000, duzentas e tres das empresas americanas na Fortune 500 realizavamoffshore outsourcing.

Offshore outsourcing e um modelo de negocio que indica a contratacao de uma empresaterceira (outsourcing) para o desenvolvimento de determinados servicos ou produtos desoftware, sendo que a empresa terceirizada esta necessariamente localizada em um paısdiferente da contratante (offshore).

Segundo a International Data Group [26], pode-se alcancar uma economia de 25% a50% em termos de custo quando grandes projetos sao transferidos para offshore. Entre-tanto, custo nao e o unico benefıcio que levam as empresas a adocao do DesenvolvimentoDistribuıdo de Software. Existem outros benefıcios, tais como profissionais habilitadospara trabalhar de forma distribuıda com um idioma diferente (na maioria das vezes alıngua inglesa), diminuicao significativa de turnover e o incentivo de governos que con-tribuem para essa nova forma de desenvolver software.

Nao obstante a isso, podemos citar outras razoes para a adocao do DesenvolvimentoDistribuıdo de Software (DDS), pois existem varias. Tais motivacoes tem incentivadoas organizacoes a aderirem ao uso de DDS. Nesta secao, apresentamos alguns fatoresque estimulam o uso do DDS nas empresas. A Figura 3.2 identifica as principais razoesenvolvidas no DDS.

� Demanda e Custo - A demanda por servicos de desenvolvimento de software tem

3.1 MOTIVACOES PARA O DDS 29

Figura 3.2 Principais razoes envolvidas no DDS (adaptado [40])

superado significativamente a disponibilidade das pessoas/profissionais que os reali-zam (Figura 3.3). Como resultado, o custo dos profissionais de desenvolvimento desoftware aumentou, conforme as empresas entravam em rivalidade e concorrenciapor suas contratacoes [28]. No mercado dos EUA, que e responsavel por grandeparte da demanda, as cotas de vistos de trabalho temporario para area de tec-nologia, findaram antes de terminar o ano fiscal, provocando uma maior escassezde profissionais [6], [8]. Diante deste cenario, a solucao para suprir o numero defuncionarios e custos de contratacao altıssimos, foi visto uma grande oportunidade,a disponibilidade de recursos equivalentes em outras localidades (buscando pelomundo, profissionais/equipes para trabalhar de forma distribuıda) a um custo maisbaixo, tornando-se desta forma um negocio atrativo para as empresas de software,incentivando assim o Desenvolvimento Distribuıdo de Software (DDS).

� Time-to-market - As pressoes para diminuir o tempo necessario para terminar oproduto e coloca-lo no mercado (time-to-market) tambem auxiliam no crescimentodo desenvolvimento distribuıdo de software [25]. A possibilidade de ter um desen-volvimento follow-the-sun e um grande atrativo para empresas que visam diminuirou reduzir o time-to-market. No desenvolvimento follow-the-sun as equipes sao dis-tribuıdas globalmente, de forma que ha sempre pelo menos uma equipe realizando o


Figura 3.3 Demanda por software em relacao ao numero de microcomputadores e profissionaisdisponıveis (adaptado de [28])

trabalho [32]. Dessa maneira, o fuso horario visto como uma desvantagem do DDS,transforma-se em uma vantagem competitiva e estrategica da empresa, permitindotrabalhar 24 horas por dia [6].

� Mercado e presenca global - Conforme os custos diminuem e o poder computacio-nal cresce, o mercado global de informatica aumenta, apresentando uma demandaelevada por solucoes de software nos diversos segmentos de TI [28]. Para melhorsatisfazer o mercado consumidor, as empresas observaram que a presenca das coor-poracoes se torna necessaria para venda, projeto e manutencao do software. Dessaforma, varias empresas optam pelo DDS para alcancar o mercado global e ficaremmais proximas de seus consumidores. Por conseguinte, obtem-se o diferencial de setornar uma empresa global [6].

� Rigor e experiencia no desenvolvimento - Equipes de desenvolvimento centralizadode software (DCS) inclinam-se a utilizar mais mecanismos informais, ou seja, naotendo o devido cuidado no uso de metodologias formais de desenvolvimento. Equi-pes de DDS, em contra ponto, na tentativa de suprir a falta de contato face a facee melhorar a comunicacao entre as equipes de desenvolvimento, tendem a buscara melhoria de forma significativa da documentacao utilizada [6]. Alem disso, de-terminados locais desenvolvem habilidade/experiencia em areas pouco difundidas,onde ha pouca mao de obra qualificada. Nestes casos, a experiencia de um localespecıfico pode ser um diferencial para que o desenvolvimento seja realizado nele.

� Sinergia cultural - A variedade e diversidade cultural aumentam a capacidade de

3.2 CARACTERIZACAO DO DDS 31

criatividade e o entusiasmo na empresa de desenvolvimento de software. Umaequipe global cria uma colaboracao, uma sinergia cultural, buscando e encontrandooutras formas de resolver problemas, projetar produtos, ou pensar sobre formasinovadoras de desenvolvimento [6]. Alem disso, a sinergia cultural, interligada ademanda e aos desafios, amplia a capacidade de aprendizado da empresa [32].

� Escala - Grandes empresas que trabalham com desenvolvimento de software, amedida em que crescem, podem vir a chegar em um ponto de difıcil gerenciamento.Logo, torna-se interessante distribuir o desenvolvimento de software para atender ademanda necessaria [6].

3.2 CARACTERIZACAO DO DDS

Ambientes de desenvolvimento distribuıdos caracterizam-se pela distancia fısica e/ou tem-poral entre os envolvidos no projeto, ou seja, os stakeholders. Podemos definir stakehol-ders como grupos ou indivıduo que possam afetar ou sao afetados por atividades de umaempresa ou projetos. Os mesmos sao os interessados, que segundo Freeman [21] deve serconsiderado como um elemento essencial na planificacao estrategica de negocios. Por-tanto, os stakeholders tem um papel fundamental no desenvolvimento centralizado desoftware, e no desenvolvimento distribuıdo e necessario dar uma relevancia ainda maiordevido a distancia fısica e temporal. Quando esta distancia fısica envolve mais de umpaıs, isso comeca a tomar uma dimensao maior e se caracteriza um desenvolvimento glo-bal de software [40]. De acordo com Prikladnicki [40],o DDS divide-se em varios nıveisde dispersao os quais estao sendo detalhados a seguir.

� Distancia Nacional - Caracteriza-se por equipes ou membros de equipes localiza-das no mesmo paıs, podendo reunir-se pouquıssimas vezes para uma reuniao ouresolucao de algum problema. Pode haver diferencas de fusos horarios em algumasregioes ou diferencas culturais podem ocorrer em maior escala.

� Distancia Continental - Caracteriza-se por ter atores em paıses diferentes em ummesmo continente. As reunioes ficam mais difıceis de acontecerem face a face de-vido a grande dispersao entre os atores. As diferencas de fuso horario e culturalexercem um papel fundamental e importante nas equipes, podendo causar grandesdificuldades no projeto.

� Distancia Global - Caracteriza-se por ter atores em paıses diferentes, em continentesdiferentes formando uma dispersao globalizada. As reunioes face a face quase naoacontecem,ocorrem geralmente so no inıcio do projeto para definir papeis, e integraras equipes. A comunicacao e fortemente dependente da tecnologia e a mesma jun-tamente com as diferencas culturais podem ser barreiras para o sucesso do projeto.O fuso horario pode impedir interacoes entre as equipes.

No contexto deste trabalho, entende-se por DDS quando uma das partes ou integrantesda equipe diretamente envolvida no projeto esta geograficamente dispersa.


3.3 DESAFIOS DO DDS

O desenvolvimento de software tradicional ou centralizado e uma atividade complexa.Por isso existem varios desafios. Tais desafios sao caracterizados a partir de uma seriede perspectivas distintas [40]. Os principais desafios no desenvolvimento tradicional desoftware sao tres: pessoas, processos e tecnologia.

No Desenvolvimento Distribuıdo de Software (DDS), os desafios sao os mesmos dodesenvolvimento tradicional acrescentando, apenas os novos desafios que surgem com adispersao fısica, distancia temporal e diferencas culturais. Alem disso, esta nova maneirade se desenvolver software apresenta um grande impacto na forma como os produtossao desenvolvidos, testados e entregues aos clientes. Desta maneira o DDS tem umainfraestrutura totalmente diferenciado do desenvolvimento tradicional, co-localizados oucentralizados. Nesta secao serao apresentados os principais desafios gerados pelo DDS, navisao de alguns autores [40],[31]. A tabela 4.1 apresenta uma compilacao dos principaisdesafios e questoes envolvidas com o DDS.

Tabela 3.1 Principais Desafios do DDS [40]

Categoria DesafiosCulturais Lideranca

Formacao de gruposEstilo de comunicacaoResolucao de problemasPerspectiva de tempo

Dispersao geografica GerenciamentoFusos HorariosLegislacao

Coordenacao e Controle InterdependenciaGerenciamento de ConfiguracaoConsciencia

Comunicacao ContextoMeio

Espırito de equipe CoesaoConfiancaTamanho

3.4 PROCESSO DE COMUNICACAO

Nossa historia relata bem os primordios da comunicacao entre os indivıduos, pois emsociedades primitivas a fala foi o primeiro tipo de troca de informacoes e ideias [9]. As-sim como, ocorre com toda e qualquer informacao, se faz necessario registrar, guardar asideias que eram feitas atraves da fala e neste caso, a falta desse registro era um limita-dor. Devido a estas necessidades, foram desenvolvidas outras maneiras de se comunicar,

3.4 PROCESSO DE COMUNICACAO 33

como exemplo, podemos citar os desenhos e sımbolos, antes gravados em paredes e ro-chas e, ainda Hoje, esses registros ainda podem ser encontrados e observados em sıtiosarqueologicos [9].

Comunicacao

A comunicacao pode ser definida como um processo que envolve a transmissao e arecepcao de mensagens entre uma fonte emissora e um destinatario, onde as informacoessao codificadas na fonte e descodificadas no destino.

Segundo o Dicionario Aurelio [2], comunicacao e o ato ou efeito de comunicar-seincluindo processo de emissao, transmissao e recepcao de mensagens por meios de metodose/ou sistemas convencionados. ja outros autores, afirmam que comunicacao e a troca deinformacoes entre indivıduos. Significa tornar comum uma mensagem ou informacao.

Um ciclo de comunicacao completo possui varios elementos como: Emissor, Receptor,Meio fısico, Mensagem e o Feedback do receptor, conforme ilustra a Figura 3.4.

Figura 3.4 Componentes da Comunicacao

Caso venha a ocorrer uma falha em algum dos elementos basicos, nao conseguiremoster uma comunicacao completa, mas tao somente um fragmentos de dados transmitidos.Alem disso, em um projeto temos varios elementos envolvidos no processo de comu-nicacao, representado pelo contexto na Figura 3.5.

Esses elementos incluso no contexto podem ser: cultura, influencias, resistencias,polıticas, problemas pessoais, dentre outros. Alguns modelos de qualidade de software,tentam apresentar algumas praticas que podemos utilizar para estabelecer este processo,minimizando assim maiores impactos negativos.

Os componentes ou elementos do processo de comunicacao sao apresentados comdetalhes a seguir:

� Emissor - e responsavel pelo envio da mensagem ao receptor. Ele conhece o que estasendo pretendido pela mensagem e deve codificar a mesma para que seja transmitidapor algum canal de comunicacao, ou seja, pelo meio de comunicacao escolhido.


Figura 3.5 Componentes da Comunicacao Representado pelo Contexto

� Mensagem - e o conteudo escrito ou transmitido por gestos e sımbolos; ela pode sertransmitida pela voz, texto, desenho ou por meios eletronicos.

� Codificacao - e a traducao de pensamentos, mensagem, ideias para uma linguagemque seja entendida pelas outras pessoas.

� Meio ou Canal de comunicacao - e o meio pelo qual se transmite a mensagem e estaatinge o receptor, que as recebe e interpreta.

� Receptor - o destinatario da mensagem que recebe a informacao e interpreta paraseu entendimento.

� Ruıdo - tudo o que interfere na transmissao e no entendimento da mensagem.

� Feedback - e a informacao do receptor para o emissor visando certificar-se que amensagem foi recebida e compreendida.

A comunicacao nao e sinonimo de documentacao, mas muitas pessoas possuem estavisao ao implantar um modelo de qualidade de software como o CMMI ou MPS.BRdentre outros. Para efetuar a gerencia de comunicacoes em projeto seja ele distribuıdo oucentralizado, e necessario obter os processos adequados para garantir a geracao apropriadae oportuna, a coleta, a distribuicao, o armazenamento e o controle basico das informacoesdo projeto. Todos os envolvidos devem estar conscientes e aculturados para enviar ereceber comunicacoes na ”linguagem”do projeto e devem entender como as comunicacoesafetam o projeto como um todo [50].

Segundo Chaves [9] a comunicacao se utiliza de varios canais, cada um deles apresen-tando vantagens e desvantagens em seu uso. Podemos citar entre os canais utilizados:oral, escrito e digital.

A comunicacao oral pode vir a acontecer atraves de uma reuniao face a face, em umtelefonema, vıdeo conferencia ou aula. A interacao entre o emissor e receptor, ou seja,

3.5 PROBLEMAS RELACIONADOS A COMUNICACAO EM DDS 35

entre as partes, e grande, o feedback e imediato e ha otimas possibilidades para se debaterassuntos. Mas, geralmente este canal de comunicacao nao tem registro sobre o que foidito.

A comunicacao escrita e aquela que aparece em textos, livros, jornais. Ela geralmentee revisada antes de ser publicada, pode ser armazenada para consultas futuras e as in-formacoes sao as mesmas para todos os receptores. Neste canal de comunicacao nao hacontrole de quem recebeu a informacao, de como leu e interpretou a mesma.

A comunicacao por meios digitais permite a transmissao de grande volume de dadosatraves da internet, emails, telefonia movel dentre outros. Essas tecnologias permitemdesde o simples envio de pequenos textos a grandes mensagens de dados ou vıdeo con-ferencia, com uma interacao ao vivo entre o emissor e o receptor. No entanto esse canalde comunicacao necessita do correto funcionamento de infra-estrutura tecnologica e deapoio que lhe de suporte.

3.5 PROBLEMAS RELACIONADOS A COMUNICACAO EM DDS

Com o alto crescimento do DDS, engenheiros, gerentes e empresarios tem se confrontadocom parceiros de diferentes nıveis tecnicos, sociais e culturais [25]. A resolucao des-sas diferencas localmente, ja e bastante significativa e complexa, principalmente quandoexiste a comunicacao face a face devido as diferencas de termos tecnicos e jargoes. Numambiente distribuıdo de desenvolvimento esse problema e ainda maior, pois os meiosde comunicacao como correio-eletronico, chats e ligacoes telefonicas, nao sao tao ricosquanto a comunicacao face a face [25], [16]. No inıcio do desenvolvimento de software,muita comunicacao e requerida para o inıcio das definicoes do projeto [39]. Nesse con-texto ha duas formas complementares de comunicacao: formal e a informal. A partirdo momento que a comunicacao estiver mais efetivamente presente entre os membros eque as ferramentas colaborativas possam prover comunicacao informal sıncrona, haveraum aumento na percepcao da equipe virtual, comecando a criar importantes relacoes deconfianca mutua na comunicacao remota [25].

A escolha do meio de comunicacao para a realizacao de determinadas tarefas exigecuidados. Por exemplo, um gerente de DDS deve, regularmente, transmitir a visao deequipe para todos os grupos, de forma a contextualizar os times ou equipes a respeitodo andamento do projeto. Esse meio de comunicacao devera prover nıveis altos de mo-tivacao e emocao [7]. Existem casos em que a comunicacao sıncrona (comunicacao queocorre exatamente ao mesmo tempo, simultanea) pode ser menos apropriada do que aassıncrona (comunicacao que nao ocorre exatamente ao mesmo tempo). Por exemplo:um determinado membro da equipe combina algo com o gerente de projeto por telefone edepois nao se lembra do que realmente foi acordado entre eles, desta forma nao existe ne-nhum historico para confrontar o acordo entre as partes. Ja se todo processo tivesse sidoacordado via email, terıamos algum historico para comprovar o acordo entre as partes.

Em Projetos Distribuıdos, a comunicacao e a base para definir como serao repassadasas informacoes para os stakeholders envolvidos no projeto.

Nao existe uma regra para gerenciar projetos distribuıdos, mas existem boas praticasque sao pontos relevantes e que ajudam os projetos a chegarem a seu objetivo fundamen-


tal: sua conclusao no prazo, dentro do custo e com qualidade.Evaristo [19] afirma que os processos de comunicacao devem ser adaptados as carac-

terısticas de cada organizacao e podem mudar em cada etapa de projeto, na medida emque podem passar a incluir equipes com diferentes culturas.

Uma comunicacao efetiva em projetos distribuıdos constroi a confianca formal e infor-mal entre os colaboradores das equipes. Desta forma serao descritos nas secoes seguintesalguns dos principais desafios para a comunicacao em DDS.

Percepcao ou Awareness

Perceber neste contexto e obter as informacoes por meio dos sentidos, do que real-mente esta acontecendo e do que as outras pessoas estao fazendo, mesmo sem se comunicardiretamente com as pessoas envolvidas. Em um projeto DDS, as equipes acabam dei-xando de disseminar as informacoes importantes para as pessoas certas, e muitas vezesos responsaveis pela disseminacao da informacao nao sabe para quem enviar a mensa-gem e acabam enviando para todos do projeto, isso muitas vezes pode gerar ruıdos nacomunicacao (ma interpretacao da informacao).

No desenvolvimento de software e extremamente importante que se tenha conscienciado que esta acontecendo, quem esta fazendo determinada atividade, onde ela esta sendodesenvolvida, principalmente sobre a documentacao e codigo [40]. E necessario que todosos membros das equipes que participam do projeto, venham saber como estar o andamentodo projeto e os resultados de cada equipe, de forma a maximizar a colaboracao dentre asmesmas. Entretanto, quando surge uma nova informacao no projeto sendo executada poruma equipe distribuıda, geralmente o lıder ou responsavel nao sabe exatamente as pessoasque precisam da informacao. Desta forma, ou ninguem e informado ou acaba enviandoa informacao para pessoas desnecessarias. Neste momento pode comecar a surgir algunsconflitos e isso acontece devido a ser muito difıcil ter uma visao completa de uma equipedistribuıda e as necessidades de cada integrante da equipe.

O melhor cenario seria o seguinte, quando a informacao ou alguma solicitacao demudancas no software chegasse, o responsavel por analisa-la, deve ter capacidade paraidentificar para quem enviar esta solicitacao caso a mesma seja aprovada. O mesmodeve acontecer quando temos equipes dispersas globalmente trabalhando dependente umadas outras em um mesmo projeto com objetivo em comum, pois a consciencia dessadependencia entre as equipes e de suma importancia.

A seguir apresentamos alguns tipos de awareness em projetos DDS de acordo com[8], [40].

� Atividade ou Tarefa - e necessario saber quem esta executando qual tarefa ou ati-vidade, quem foi o responsavel por determinar a mesma e onde estar o resultadodessa atividade.

� Processo - e necessario saber como a tarefa de um grupo pode se integrar com ade outro grupo. Exemplo: foi descoberto algo muito interessante sobre o teste docomponente e e de suma importancia saber para quem sera enviada essa informacao.Quem precisa saber?

3.5 PROBLEMAS RELACIONADOS A COMUNICACAO EM DDS 37

� Disponibilidade - e muito importante estar claro quem estara disponıvel para res-ponder determinadas questoes em alguns momentos ou em todos os momentos.

� Ambiente - e necessario saber como o ambiente do membro da equipe, seja ele tes-tador ou desenvolvedor, pode afetar o seu trabalho. exemplo: condicoes climaticas,bom relacionamentos com companheiros de trabalho dentre outros.

De acordo com esses tipos de Awareness ou percepcao, existem algumas tecnicas paraobter um aumento do nıvel de percepcao das equipes distribuıdas, como por exemplo:Repositorios comuns; sistema para controlar as atividades do projeto; reunioes de statusdo projeto; ambientes integrados; descricao de processos; Cronogramas individual e emgrupo; chat; conversas ou trocas de informacoes sobre o ambiente de trabalho; portal denotıcias.

Para diminuir os problemas de percepcao em Desenvolvimento Distribuıdo de Soft-ware (DDS), varios pesquisadores academicos e profissionais tem concentrado um grandeesforco no estudo de gestao e coordenacao de equipes, alem da adocao de redes sociaispara criar meios de Awareness automatizados para melhorar e ate mesmo facilitar o tra-balho das equipes DDS.

Contexto

O contexto e um grande desafio do ponto de vista de comunicacao. Quando temosalgumas equipes desenvolvendo algum produto referente a um projeto, no mesmo localfısico, compartilhando a mesma cultura e fuso horario, informacoes muitas vezes clarase compreensivas sao ignoradas por ja pertencerem a cultura local, por fazerem parte dodia a dia. Mas, quando aceitamos esse novo desafio de trabalhar de forma distribuıda,nem sempre sabemos por exemplo quando sera o proximo feriado nos paıses onde existemequipes trabalhando de forma distribuıda. Ou seja, nem sempre sabemos a quantidadede horas referente ao fuso horario existente ou qual seria a melhor hora para se fazeruma reuniao. Entretanto, sabemos que em um projeto tradicional ou centralizado, osintegrantes das equipes, mesmo estando proximos fisicamente um do outro, sao passıveisde sucederem em alguns conflitos.

Em projetos DDS se faz necessario que seja bem trabalhada a parte de comparti-lhamento de contexto para que as equipes conhecam seus colaboradores, conhecam ocontexto de cada integrante das equipes que participam do projeto. Desta forma, pode-se evitar conflitos e ruıdos. Para resolver este fator de grande impacto, normalmenteadotamos algumas solucoes como uma intranet, portal de notıcias para que sejam divul-gadas as informacoes, como feriados, fuso horario de paıses, cidades e outras informacoesrelevantes para o projeto. Em muitos casos, a simples acao de enviar um email de umintegrante para outro que esta distribuıdo geograficamente e se caso o remetente do emailnao venha a obter uma resposta em um tempo determinado (horas ou dias), pode ge-rar um conflito que poderia ter sido evitado. A solucao para este problema seria muitosimples, bastando que a equipe compartilhasse o contexto do projeto e tambem de seusintegrantes, atraves de treinamentos ou de uma simples conversa ou bate papo.


Dispersao geografica e temporal

O gerenciamento de equipes fica mais complexo com a dispersao geografica. De acordocom Prikladnicki [40] a distancia fısica e considerada uma das maiores dificuldade em equi-pes distribuıdas. Embora a tecnologia venha incentivando as organizacoes a trabalharemde forma descentralizada, ainda existem grandes limitacoes devido a falta de comunicacaoface a face entre os envolvidos no projeto ou integrantes da equipe. Neste cenario obteruma harmonia ou ate mesmo uma aprovacao na tomada de decisao pode ser muito difıcil.

Alem da dispersao fısica, a dispersao temporal tambem tem grande influencia nodesenvolvimento distribuıdo de software. Os integrantes estao dispersos no tempo quandoas equipes ou integrantes das equipes estao em lugares com fuso horarios diferentes, oque diminue o tempo disponıvel para interacao sıncrona, ou seja interacao em tempo real.Mesmo equipes de projetos centralizados podem sofrer essa diminuicao de tempo devidoa distancia temporal, pois basta algum dos integrantes trabalhar em diferentes turnos.

Sabemos que algumas equipes dispersas podem em algum lugar do mundo estarcomecando o dia, enquanto outras equipes podem estar terminando o expediente. Essasequipes distribuıdas de forma global podem vir a sofrer com o sentimento de isolamento.Neste momento, o papel do gerente de projeto e extremamente importante para naopermitir que as equipes sintam-se abandonadas. E necessario que o gerente sempre man-tenha contato com os lıderes da equipes, com os proprios membros e fazendo com queas equipes comuniquem-se entre as outras equipes dispersas para desta forma criar umnıvel de confianca e vinculo o qual podera minimizar o sentimento de solidao e abandonocausado pela distancia fısica e temporal.

Formas de comunicacao

A distancia fısica ou dispersao geografica tem impacto direto sobre todas as formasde comunicacao, sejam elas formais ou informais.

Primeiramente, a formal, que e a comunicacao oficial, devendo ser passada comclareza. Uma comunicacao confusa ou mal especificada, podera levar a equipe a perdertempo e gerar problemas de coordenacao no projeto [25].

A segunda e a comunicacao informal, que e um excelente canal para percepcao decomo andam as atividades perante o grupo. As chamadas conversas paralelas ajudamas pessoas a terem percepcao do andamento do projeto, facilitando assim o trabalhoem grupo e auxiliando na resolucao de problemas tecnicos, melhorando a eficiencia dosdesenvolvedores [14].

A comunicacao quando muito informal em equipes distribuıdas, tem uma reducaosignificativa na clareza e objetividade no que refere-se ao desenvolvimento de qualquerproduto, seja ele software ou nao. Devido a essa distancia fısica, mais reunioes sao ne-cessarias, entao a dificuldade de coordena-las torna-se muito maior comparado a projetoscentralizados [40]. Neste caso e necessario comunicar-se de forma objetiva e clara, por-tanto, essas comunicacoes podem variar devido as diferencas culturais.

O sentido da comunicacao nao esta somente nas palavras, pode estar no tom devoz, nas expressoes faceais, linguagem corporal no contato visual ou em um simples

3.6 COMPARANDO PROCESSO DE COMUNICACAO DISTRIBUIDO COM CENTRALIZADO 39

silencio [40]. No inıcio de um projeto de desenvolvimento de software, e necessario muitacomunicacao para iniciar as definicoes do projeto [39].

Segundo Cantor [5], para gerir equipes de desenvolvimento software, seja em projetosdistribuıdo ou centralizados, e necessario estar ciente de como geralmente essas pessoasse comunicam, para desta forma poder estudar e adotar o melhor plano de comunicacaopossıvel, pois varios projetos chegam ao fracasso devido ao gerente de projeto adotar ummodelo de comunicacao inapropriado.

O mesmo autor sugere que existem tres modelos de comunicacao que podem seradotados no projeto: comunicacao funcional, comunicacao nao estruturada e time deproduto. A comunicacao funcional acontece quando cada uma das funcoes e assumidapor uma equipe. Neste modelo ha pouca interacao entre os stakeholders do projeto, ouseja, clientes, times do projeto, gerentes e etc. A falta de comunicacao tem como resultadoprodutos inacabados ou nao construıdos da forma que foram planejado e projetados.

O modelo de comunicacao nao estruturado, possui grande interacao entre os stakehol-ders envolvidos no projeto. Este modelo parte do princıpio que todos devem se comunicarentre si. Segundo Zanoni [50], neste modelo nao existe uma estrutura bem definida. comequipes ou times pequenos, esse modelo de comunicacao poderia trazer alguns benefıcios,porem em equipes maiores, que envolve um numero de atores elevado, acabam ocor-rendo problemas que dizem respeito a baixa produtividade, tornando-se complicado eextremamente complexo mensurar os prazos [50].

O modelo de comunicacao de times do produto prefere ter equipes proprias para di-versos processos onde cada equipe fica responsavel por uma atividade principal. Estemodelo preocupa-se em entender como as pessoas trabalham juntas com o objetivo debuscar facilitar os processos e atingir objetivos do projeto [50].

Fuso Horario

Atraves das diferencas de fusos horarios, e percebido que sao minimizadas as inter-seccoes nos horarios de trabalho entre pessoas de equipes distintas. Entretanto, a se-paracao temporal pode tambem existir com uma diferenca de horarios de trabalhos entreas pessoas de um mesmo local, trabalhando em diferentes turnos.

Fuso horario e um fator muito importante quando temos equipes distribuıdas, poisa maior dificuldade imposta pelo fuso horario e a falta de comunicacao face a face e areducao da comunicacao sıncrona. Para tentar minimizar este problema, muitos gerentesde projeto estao adotando websites ou portais para manter os dados com horarios dasregioes envolvidas no projeto, bem como a disponibilidade de cada membro da equipepara comunicacao sıncrona.

3.6 COMPARANDO PROCESSO DE COMUNICACAO DISTRIBUIDO COM CEN-TRALIZADO

Processos distribuıdos sao tipicamente projetados para acesso de informacao eletronicasimultanea, apoiados totalmente na tecnologia, ao inves do fluxo de informacoes consecu-tivas para permitir que membros das equipes visualizem o desenvolvimento do trabalho


atraves de compartilhamento online. Eles podem ver a informacao e alcancar o entendi-mento relativo a todo andamento do processo, o que permite antecipar os problemas enegociar solucoes enquanto o trabalho esta sendo completado [33].

Um exemplo disso pode ser um projeto que utiliza recursos de terceiros, tais comoconsultorias, especialista de industrias entre outros. Como membros de uma equipedistribuıda. Esses membros podem utilizar infraestrutura de rede e transferencia de in-formacoes eletronicas para guiar e avaliar especificacoes de tecnicas enquanto projetamas entregas. Dois esforcos podem ser envolvidos em paralelos embora eles ocorram emdiferentes localidades e sejam dependentes um do outro. Como nas equipes de geren-ciamento de projetos tradicionais, a estimativa do processo da equipe distribuıda e osresultados do trabalho variam entre as equipes, seja distribuıda ou nao. Uma vez que aequipe entra em consenso na comunicacao e no feedback alcancado e o nıvel de satisfacaoe atendido o grau de integracao das tarefas se tornam alcancaveis [33].

A abordagem de tarefas, milistones (marco) preparacao e estruturacao de documentossao todos os topicos que devem ser discutidos pelas equipes de projetos distribuıdos.Uma vez que a documentacao e decidida em conjunto, a equipe parece trabalhar bemmelhor, revelando que padroes sao necessarios para fixar as expectativas e estrategias decomunicacao. Portanto, e sabido que sem esses acordos comuns a todos, a possibilidadede conflitos e confusoes sao mais provaveis de ocorrer.

Socializacao eletronica tornou-se um fator importante quando a colaboracao na formaescrita e envolvida. Tambem, espera-se que todos os membros possuam email para co-municacao, alem de outras ferramentas. Entao e relevante por exemplo determinar quala frequencia que e checada sua caixa de entrada do email, pois essa frequencia, seja elaem minutos ou em horas, e de suma importancia para algumas nacoes.

Embora a comunicacao nao seja o unico fator na colaboracao, membros da equipesdevem se comunicar bem para colaborar bem. Em uma equipe distribuıda, idioma e tec-nologias comuns sao frequentemente importantes/requeridas para um esforco de sucesso.Membros dessas equipes sao normalmente estimulados para falar com outras equipes domesmo projeto que muitas vezes tem outras culturas, desta forma, tendo uma aprendiza-gem mutua, ou seja, uma equipe acaba aprendendo com a outra, e percebendo a fluenciapositiva da comunicacao e compartilhamento de conhecimento com outras equipes pelomundo.

A TIC representa um papel crıtico na transformacao das organizacoes conectadas arede WWW (World Wide Web) , ou seja, as organizacoes que estao aderindo ao projetodistribuıdo. As redes eletronicas nao suprem ou substituem o relacionamento face a faceentre os membros das equipes e isso e muito evidente nesses projetos. Existe definitiva-mente um relacionamento toleravel entre a comunicacao face a face e comunicacao viatecnologias que tentam suprir essa lacuna [33].

3.7 TRABALHOS RELACIONADOS

O Desenvolvimento Distribuıdo de Software apresenta algumas caracterısticas importan-tes que o diferenciam, fundamentalmente, do desenvolvimento centralizado de software[51]. Por exemplo: a engenharia de requisitos possui diversas tarefas que necessitam

3.7 TRABALHOS RELACIONADOS 41

de alto nıvel de comunicacao e coordenacao, o que certamente aumenta as dificuldadesem ambientes de desenvolvimento distribuıdos de software [16],[51]. Embora diversosestudos reconhecam a necessidade de ampliar o conhecimento em comunicacao em am-bientes distribuıdos, apos uma pesquisa extensa, um numero reduzido de artigos sobre otema foi encontrado. Nesta secao e apresentada uma compilacao dos principais estudosrelacionados a comunicacao em ambientes de desenvolvimento distribuıdo de software.

Apesar de varios autores salientarem a importancia da comunicacao em projetos DDS,poucos trabalhos tem enfocado nessa area.

3.7.1 Abordagem de Carmel

Em seu trabalho, Carmel [6] aborda a criacao de equipes distribuıdas, globais ou virtuaisde desenvolvimento de software e os fatores crıticos que devem ser considerados ao criaruma equipe para um projeto DDS, (vide Figura 3.6). O autor sugere a existencia de cincocategorias que podem levar uma equipe distribuıda ao declınio ou fracasso no projeto,sao elas: comunicacao ineficiente, falta de coordenacao, dispersao geografica, perda doespırito de equipe e diferencas culturais, chamadas de forcas centrıfugas. Alem disso,ele tambem sugere a existencia de seis categorias que podem levar a equipe ao exito,ao esperado sucesso, sao elas: infra-estrutura de comunicacao, arquitetura do produto,construcao de uma equipe, metodologia de desenvolvimento, tecnologia de colaboracao etecnicas de gerencia, chamados de forcas centrıpetas. A Figura 3.6 apresenta o modeloproposto.

Figura 3.6 Forcas centrıfugas e centrıpetas de equipes distribuıdas ou globais

A seguir apresenta-se detalhadamente cada uma das forcas centrıfugas e centrıpetasdefinidas por Camel [6].

Forcas centrıfugas.

� Diferencas culturais - o gerenciamento das diferencas culturais sao de suma im-portancia ou essencias para efetividade de uma equipe distribuıda, principalmente


quando se trata de distribuicao global. Segundo Carmel [6], as culturas diferem emvarias dimensoes crıticas, como a necessidade de estrutura, atitudes com relacao ahierarquia, senso de tempo e estilos de comunicacao. Alem disso, diferencas cul-turais interfere diretamente em algumas questoes como: formas de lideranca, decomunicacao e de como resolver os problemas.

� Dispersao - existem dois tipos de dispersao. O primeiro e a distancia geografica, ba-seada na distancia fısica entre os envolvidos nos projetos distribuıdos. O segundorefere-se a dispersao temporal, onde membros de uma equipe estao distribuıdos,dispersos ou espalhados no tempo pela diferenca nos horarios de trabalho, fusoshorarios e/ou ritmo de trabalho que fazem diminuir o tempo disponıvel para co-municacao sıncrona. A dispersao temporal tambem reflete ou afeta a comunicacaodevido aos estados fısicos e mentais dos participantes. Em algum local, alguns mem-bros de equipes podem estar iniciando o dia, enquanto outros estao no terminandoou chegando ao final do expediente [6].

� Falta de coordenacao - equipes distribuıdas geograficamente apresentam dificul-dades na coordenacao e controle. As dificuldades e desafios tomam uma maiordimensao devido aos problemas de cultura, idioma e tecnologia. O grau de de-pendencia das tarefas exerce um papel fundamental na coordenacao. Controlarmudancas nos artefatos em cada uma das localidades e coordenar o processo de mo-dificacao com o processo de desenvolvimento de todo o produto pode ser bastantecomplexo. A manutencao da consistencia de padroes e formato de documentacaotambem e mais difıcil em ambientes de desenvolvimento distribuıdo de software [6].

� Comunicacao Ineficiente - a distribuicao de equipes geograficamente distribuıdastem um grande impacto em todas as formas de comunicacao, principalmente nareducao acentuada da comunicacao informal. As pessoas deixam de se comunicarpor causa das dificuldades impostas, o numero de reunioes aumenta e a comple-xidade de coordena-las tambem. De acordo com Carmel [6], a comunicacao clarae efetiva e primordial para a obtencao do sucesso de equipes distribuıdas, mas emvarios casos e necessario comunicar-se indiretamente (por causa da distancia tempo-ral), prejudicando desta forma a riqueza de contexto. De acordo com os diferentesestagios do ciclo de desenvolvimento de software, algumas tarefas precisam de umacomunicacao mais rica que outras. De uma forma geral, qualquer tarefa que neces-site de uma cooperacao acentuada, requer mais comunicacao, e quanto mais rica,melhor. Determinadas atividades requerem muito cuidado na selecao do meio decomunicacao a ser utilizado. Alguns dos impactos do DDS na comunicacao sao afalta de comprometimento e o desconforto ao utilizar alguns meios [30].

� Perda do espırito de equipe - as equipes podem facilmente ser quebradas, quandoapresentadas as dificuldades como distancia e diferencas culturais, o espırito deequipe geralmente enfraquece ou aos poucos vai desaparecendo[32]. O espırito deequipe e o efeito sinergico que torna a equipe uma unidade coesa[6]. Compartilharuma visao dos objetivos e acoes da equipe pode ser complexo inclusive em ambientes


com uma unica cultura. Em ambientes de desenvolvimento distribuıdo de softwaree em ambientes multi-culturais e muito mas difıcil afirmar que todos os membrosentendem o que e realmente uma equipe. A confianca, componente fundamentalpara o espırito de equipes, torna-se de difıcil manutencao e o tamanho da equipee importante para garantir que a comunicacao entre todos os membros ocorra deforma efetiva [32].

Conforme ja foi dito anteriormente, o tamanho da equipe e importante para garantirque a comunicacao sera efetiva. De acordo com Lopes [31], quanto menor o numero demembros de uma equipe, menor o numero de canais de comunicacao necessarios. Porexemplo, com nove membros, uma equipe precisa gerenciar 36 canais de comunicacao,que crescem com a adicao de novos membros ao grupo (Figura 3.7 ). Desta forma, eimportante que as equipes sejam pequenas, se possıvel nao contendo mais de dez pessoas[6].

Figura 3.7 Numero de canais de comunicacao em uma equipe [31]

.

Forcas centrıpetas.

� Infra-estrutura de comunicacao - os ambientes de desenvolvimento distribuıdo desoftware necessitam de conexoes confiaveis, de alta velocidade para todas as formasde comunicacao e dados. Contudo, em alguns paıses a infra-estrutura de teleco-municacoes nao permite que se consiga nada alem de linhas telefonicas comuns,no geral as localidades dispoe de tecnologias que permitem a transmissao de voz edados com boa performance e confiabilidade.


� Arquitetura do produto - a arquitetura do software e um fator importante para adiminuicao das dificuldades do desenvolvimento distribuıdo de software e deve sebasear no princıpio da modularidade, considerada a principal forma de solucionare alocar atividades complexas de forma distribuıda. Um projeto modular reduza complexidade e permite um desenvolvimento com uma menor interdependenciaentre os locais, podendo diminuir custos adicionais de coordenacao.

� Tecnologia de colaboracao - uma das forcas centrıpetas que Carmel [6] coloca comofator e fundamental a existencia de tecnologias de colaboracao. As mesmas sao utili-zadas para aumentar a comunicacao informal, alem de possibilitar e fomentar novasformas de comunicacao formal entre as equipes envolvidas em projetos DDS. Diantedisso, podem ser divididas varias tecnologias de colaboracao de uso comum (correioeletronico, correio de voz, entre outros) e tecnologias de colaboracao para suporteem atividades mas especıficas a engenharia de software (gerencia de configuracao desoftware, gerencia de projetos, ferramentas CASE, entre outros). Essas ferramentassao muito importantes para apoiar as equipes dispersas geograficamente [6].

� Tecnicas de gerencia de projetos - a gerencia de projetos de DDS exige uma adaptacaode algumas tecnicas utilizadas em projetos centralizados, para tentar reduzir as di-ficuldades causadas pela dispersao das equipes. As tecnicas utilizadas em equipescentralizadas podem perder a efetividade em ambientes DDS e por tal motivo neces-sitam de adaptacoes. Uma equipe de DDS deve possuir uma estrutura flexıvel parasuportar a distribuicao de tarefas e a tomada de decisoes. Os principais aspectosque Carmel elucida [6] sao a gerencia de conflitos, utilizacao de metricas, formasde reconhecimento e bonificacao e escolha de um gerente com perfil para atuar emprojetos distribuıdos.

� Processo de desenvolvimento - a existencia de um processo de desenvolvimentobem definido e institucionalizado entre as equipes do projeto DDS e fundamental.Quando equipes comecam a distribuir seus processos globalmente, a falta de sin-cronizacao muitas vezes pode se tornar crıtica. Dessa forma, um processo comuma todas as equipes envolvidas no projeto impoe um rigor a equipe.

� Formacao de Equipes - as equipes de DDS precisam e necessitam de intenso relacio-namento por meios de comunicacao eficientes e possuir uma visao compartilhada. Ainteracao entre membros de uma equipe tem a confianca como base, que e muito im-portante quando existem interdependencias entre algumas pessoas para realizacaode seus objetivos. O conhecimento dos papeis de cada membro e da estrutura daequipe por todos os envolvidos no projeto e necessario para facilitar o contato comos responsaveis de cada atividade.

Segundo o mesmo autor [6], o DDS, principalmente em ambito global, usualmente en-volve equipes de localidades cujo idioma nativo e diferente. As dificuldades de idioma saosutis e podem causar diversos problemas. Profissionais expostos a um idioma diferentedo nativo usualmente leem mais lentamente, nao percebem algumas ideias, e encontram


dificuldades de concentracao e expressao.

Abordagem de Damian e Zowghi.

Os estudos de Damian e Zowghi [16] tem como objetivo principal, o entendimento edescricao do impacto que a distancia exerce na negociacao de requisitos de software, com-preendendo grande parte do conhecimento atual sobre a comunicacao e outros fatores.Esses fatores, tem grande impacto na engenharia de requisitos em ambientes de desen-volvimento global de software. Por tal motivo, foi conduzida uma pesquisa baseada emestudos de caso, visando esclarecer o impacto causado pela distribuicao dos stakeholdersem ambientes de Desenvolvimento Global de Software (DGS).

Como resultado foi construıdo um modelo dos desafios apresentados pela distribuicaodos stakeholders a engenharia de requisitos, conforme apresentado na figura 3.8. A ca-mada superior do modelo apresenta os quatro maiores problemas da distribuicao ge-ografica dos stakeholders: comunicacao inadequada, gerencia do conhecimento, diversi-dade cultural e diferenca temporal.

Figura 3.8 Modelo de impacto dos desafios apresentados devido dispersao dos stakeholders(adaptado de [16])

Esses problemas tiveram estudo inicial para obtencao de seu alinhamento com estudosanteriores de DGS [6]. A segunda camada que a figura 3.8 apresenta, sao as dificuldadesespecıficas encontradas, decorrentes dos problemas identificados. Na terceira camada, saoapresentadas as atividades da engenharia de requisitos impactadas por cada dificuldadeencontrada. O estudo, alem da construcao do modelo, pode obter tambem diversosresultados, relacionados com comunicacao, conflito, cultura e distancia.

3.7.2 MuNDDoS - Prikladnicki e Audy

O modelo MuNDDoS e resultado de uma dissertacao que teve como base a parceriaentre a Escola de Ciencias de Computacao da PUC do Estado do Rio Grande do Sule a empresa Dell Computer Corporation. Prikladnicki e Audy [41], juntamente comoutros pesquisadores descreveram dois estudos de caso sobre Desenvolvimento Global de


Figura 3.9 Diagrama de influencia das categorias em DDS (adaptado de [40])

Software (DGS) que foram realizados com Equipes distribuıdas cooperando a partir dacidade de Porto Alegre no Estado do Rio Grande do Sul e de Austin nos Estados Unidosda America.

Prikladnicki [42] propoe esse modelo de referencia para a area de DesenvolvimentoDistribuıdo de Software (DDS), contemplando as partes tecnicas e nao-tecnicas. As con-clusoes do autor foram baseadas nos dois estudos de caso realizados citados anteriormente.Nesse trabalho, atraves da comparacao entre a teoria e as descobertas empıricas o au-tor pode apresentar algumas licoes apreendidas, que serviram de bases para o modelode referencia proposto. Dentre as licoes aprendidas, o autor identificou que e necessarioter processos bem definidos, processos padronizados como, por exemplo, o processo decomunicacao no desenvolvimento distribuıdo de software. Alem disso foram identificadascategorias, e os fatores envolvidos em cada uma foi possıvel consolidar um diagrama comtodos os fatores envolvidos em DDS. A figura 3.9 apresenta um diagrama de influencia(mapa conceitual).

Percebeu-se que um processo bem definido, pode ser a solucao para muitas dificuldadesno DDS. Neste caso, as equipes de projeto devem optar por: forcar a padronizacao; criarum novo processo baseado nas melhores praticas encontradas em cada local distribuıdo; ouimpor algumas regras em alto nıvel. De acordo com o autor, os entrevistados deste estudode caso falaram que devido ao projeto ser distribuıdo, os requisitos deve ser passado com omaior detalhe, sem margem para erros ou falsas interpretacoes devido a uma comunicacaodeficiente[42].

Praticamente este estudo teve um maior foco na engenharia de requisitos que identi-ficou como grande problema a falta de ideias convergentes, falta de entendimento devidoa distancia fısica entre as equipes e isso causava uma instabilidade dos requisitos que econsiderado em varias pesquisas um grande desafio no DDS.

3.7.3 Abordagem de Medeiros

Medeiros [34] propoe um processo de requisitos para DDS com intuito de melhorar adocumentacao e validacao com uso de prototipos. Em sua pesquisa, o autor realizou

3.8 COMPARATIVO ENTRE OS TRABALHOS RELACIONADOS 47

um estudo de caso com uma abordagem exploratoria. O caso analisado foi o projetoAMADeUs-MM, um projeto de pesquisa desenvolvido por varias instituicoes.

Por se tratar de um projeto com caracterısticas DDS, ou seja, com os seus integrantesdistribuıdos geograficamente, o mesmo serviu como estudo de caso para a identificacaodas praticas relacionadas a validacao e documentacao, e em seguida propor um processode Engenharia de Requisitos adequado as necessidades existentes no DDS.

A comunicacao existente no projeto AMADeUs pode ser observada e realizada deforma presencial entre os integrantes de uma mesma unidade de desenvolvimento. Paraa comunicacao entre diferentes unidades, foram utilizadas diversas ferramentas de comu-nicacao sıncrona e assıncrona. Diante deste contexto, foi percebido que em alguns mo-mentos o fluxo de comunicacao foi grande, como por exemplo, na elicitacao e negociacaodos requisitos. Esse fluxo de comunicacao bastante intenso foi por conta da necessidadede resolucao de duvidas encontradas nos requisitos e por isso, houve a necessidade dereunioes face a face onde a interacao e muito mais rica.

A pesquisa tambem fala sobre o uso do storyboard como artefato de entrada paraa fase de documentacao dos requisitos o qual e um processo que necessita de grandecomunicacao.

De acordo com Medeiros [34], atraves do acompanhamento da evolucao do artefato edas mensagens trocadas via correio eletronico entre os integrantes, foi identificado que afidelidade do storyboard, impactou no entendimento do mesmo, causando atraso na ela-boracao do artefato. Buscando resolver esse problema, o designer de interface apresentouo storyboard para a unidade 1, atraves do uso de ferramentas VoIP. Atraves desta apre-sentacao foi possıvel mitigar as diversas duvidas referente ao storyboard de forma sıncronamaximizando o grau de confianca em relacao ao entendimento do artefato. Esse trabalhoenfatiza dois modos de comunicacao utilizados no projeto: o sıncrono e assıncrono, alemde seus impactos na execucao de determinadas atividades como por exemplo: Elicitacaoso pode ser realizada de forma sıncrona e a documentacao que pode ser realizada deforma assıncrona e por fim na validacao que tivemos a preparacao da validacao de formaassıncrona e a validacao em si que foi de maneira sıncrona.

3.8 COMPARATIVO ENTRE OS TRABALHOS RELACIONADOS

A gestao de projetos DDS necessita de processos maduros e, para isto, e necessarioprimeiramente entender o que e DDS e em seguida mapear bem os processos de maior re-levancia no projeto DDS. Conforme apresentado nas secoes anteriores, podemos perceberque a maioria das abordagens tem como principal objetivo resolver desafios e problemasinerentes ao DDS. Entretanto, ainda nao temos um modelo maduro suficiente para serhomologado como um padrao internacional com o intuito de guiar o gestor e sua equipeno ambiente distribuıdo. Logo em seguida, apresentamos a figura 3.10 comparando as jacitadas abordagens ou trabalhos relacionados.

Diante do exposto na figura 3.10 e descrito em cada trabalho relacionado, podemosvisualizar que essas abordagens tem como principal foco, as atividades de requisitos.Algumas dessas abordagens identificam a importancia da comunicacao para todos osprojetos, seja ele tradicional ou distribuıdo. Entretanto, nem sempre a tratam com a


Figura 3.10 Comparacao entre os trabalhos relacionados

devida relevancia, pois na maioria dos projetos, os gestores acabam desviando esforcospara outros processos, negligenciando o processo formal e adequado de comunicacao.Desta forma, o mesmo acaba sendo implantado de acordo com a experiencia do gerentede projetos.


A area de desenvolvimento de software esta em processo contınuo de amadurecimento[6]. Por tal motivo, a revisao teorica realizada neste capıtulo identificou diversos pro-blemas e desafios ligados ao processo de desenvolvimento distribuıdo de software e, maisespecificamente, ao processo de comunicacao em DDS.

O DDS, ao se deparar com separacao geografica, dispersao temporal e diferencasculturais, aumenta as dificuldades e desafios presentes se comparado ao desenvolvimentotradicional ou centralizado [42]. Neste capıtulo ficou claro que desenvolver software comequipes centralizadas e muito diferente de desenvolver de forma distribuıda.

Os trabalhos relacionados a este estudo [42], [34], [6] contribuem no sentido de mini-mizar as dificuldades apontadas pelos artigos e literaturas que fazem frente aos desafiosdo ambiente de DDS. Adicionalmente, outros estudos se aprofundam a analise destesfatores e acrescentam outros presentes nao apenas nas equipes, mas em projetos de DDScomo um todo, muitos deles relacionados com os problemas e desafios identificados naliteratura de desenvolvimento de software de um modo geral.

As forcas centrıfugas e centrıpetas propostas por Carmel [6] objetivam nos principaisfatores presentes nas equipes em projetos de desenvolvimento distribuıdo de software. Oprocesso proposto por Medeiros [34] foca no uso de comunicacao assıncrona e sıncronana elicitacao de requisitos e o MuNDDoS de Prikladnicki [40] tem como proposta ummodelo de referencia para DDS, onde o modelo preconiza a definicao dos processos paraminimizar varios problemas no desenvolvimento distribuıdo de software.

CAPITULO 4

METODOLOGIA DE PESQUISA

Este capıtulo apresenta as caracterısticas de uma pesquisa qualitativa, com seus conceitos,fundamentacao teorica e formas de validacao. Nesta pesquisa iremos dar destaque a umaabordagem da pesquisa qualitativa interpretativa, por ser o adotado nesta dissertacao.

4.1 PARADIGMA QUALITATIVO

Os metodos qualitativos e quantitativos embora sejam diferentes, eles nao se excluem.Pode-se diferenciar o foco dado pelo qualitativo do quantitativo, mas seria incorretoafirmar que sao totalmente opostos.

O metodo de pesquisa qualitativa tem enfoque na analise de situacoes complexas,na busca de conhecimento detalhado sobre questoes particulares, alem de descobertas einvestigacoes de fenomenos com o objetivo de entender a natureza e o contexto onde elesestao inseridos [20], [44].

O metodo quantitativo, como o proprio nome indica, caracteriza-se pelo emprego daquantificacao, tanto nas modalidades de coleta de informacoes, quanto no tratamentodelas mediante tecnicas estatısticas, como por exemplo, media, desvio-padrao, coeficientede correlacao, analise de regressao, entre outros [44]. O uso de tecnicas, fundamentadasna estatıstica, preocupam-se em garantir a precisao dos resultados, evitando distorcoes einterpretacoes erroneas, possibilitando alguma seguranca quanto as inferencias [38].

Segundo Flick [20], a metodologia tradicional quantitativa, tem inicio quando o pes-quisador cria um modelo de condicoes e relacoes supostas amparado no conhecimentoteorico. Desta forma, tais hipoteses sao testadas atraves de teorias empıricas, garantindoa representatividade dos dados conforme as amostras aleatorias do objeto estudado. Con-sequentemente, as relacoes complexas coletadas sao fragmentadas em variaveis diferentes,o que permite o pesquisador isolar e testar seus efeitos, gerando, por fim, uma quanti-ficacao do que foi testado [38].

Metodos qualitativos diferem de metodos quantitativos porque utilizam variaveis quenao podem ser medidas, apenas observadas. Metodos qualitativos tem sua origem dasciencias sociais, em contraponto aos metodos quantitativos que vem das ciencias naturais.De um modo geral, metodos qualitativos sao os que se caracterizam por ser um estudoaprofundado de um sistema no ambiente onde ele esta sendo usado, ou, em alguns casos,onde se espera que o sistema seja usado. Metodos qualitativos sempre envolvem pessoas.Ja o metodo quantitativo baseia-se numa visao que: (i)diferentes observadores obteraoos mesmos resultados em observacoes distintas; (ii) nao ha desacordo do que realmentee melhor e o que e o pior para valores dessas variaveis objetivas; (iii) as medicoes emnumeros sao consideradas mais ricas do que as verbais. Essa e uma visao positivista.

Segundo Flick [20], o paradigma qualitativo e formado por oito aspectos essenciais.Esses aspectos serao apresentados logo a seguir, mas nao serao detalhados.

49

50 METODOLOGIA DE PESQUISA

� Apropriabilidade de metodos e teorias : antes de iniciar a pesquisa recomenda-seanalisar o problema a ser estudado e verificar se este pode ser investigado segundoos criterios e procedimentos disponıveis pelo metodo de pesquisa.

� Perspectiva dos participantes e sua diversidade : por tratar das relacoes complexase levar em consideracao o tempo, o local e o contexto acerca do objeto em estudo,a pesquisa qualitativa aprecia toda diversidade de informacao, seja ela: perspectivados participantes (pesquisador, observador, entrevistado, entre outros), praticas poreles realizadas, bem como significados subjetivos e sociais a eles relacionados;

� Reflexibilidade do pesquisador e da pesquisa : a pesquisa qualitativa leva em consi-deracao as reflexoes do pesquisador ou daqueles que fazem parte da pesquisa, bemcomo qualquer tipo de interacao, sejam elas pesquisador-campo ou pesquisador-participante, considerando ambos os casos como parte da producao do conheci-mento;

� Variedade de abordagens e metodos na pesquisa qualitativa : diferente da pesquisaquantitativa que detem padroes obrigatorios e conceitos teoricos e metodologicosunificados, na pesquisa qualitativa e possıvel envolver varias abordagens teoricas,distintas ou nao, pois seus metodos tiveram fundamentacao a partir de linhas einfluencias diversas;

� Compreensao como princıpio epistemologico : a pesquisa qualitativa objetiva conhe-cer o(s) fenomeno(s) estudado(s) a partir de sua observacao e investigacao. Porem,a maneira de expressar essa compreensao em termos de metodologia e dependenteda postura teorica que fundamenta a pesquisa;

� Reconstrucao de casos como ponto de partida : chama-se ”casos”qualquer indivıduoque faz parte do estudo, seu ponto de vista, o contexto no qual esta inserido esua interacao com outros indivıduos. Portanto, antes da elaboracao de enunciadosestuda-se cada caso e posteriormente, a partir do estudo de casos suposicoes saoformuladas;

� Construcao da realidade como base : como mencionado no aspecto anterior, a partirdo estudo de casos e possıvel reconstruir a realidade estudada. Ve-se assim que napesquisa qualitativa a realidade nao e determinada, mas sim reconstruıda a partirde casos, indivıduos, contexto, tempo e local no qual estao inseridos;

� Texto como material empırico : quando sao realizados os estudos de casos, textossao produzidos. A partir desses, analises empıricas e interpretacoes podem serrealizadas.

.

4.1 PARADIGMA QUALITATIVO 51

4.1.1 Comparacao entre Pesquisa Qualitativa e Quantitativa

A pesquisa cientıfica normalmente e definida como quantitativa ou qualitativa devido aotipo de dados coletados (quantitativos ou qualitativos).

Na pesquisa qualitativa o pesquisador desenvolve conceitos, ideias e entendimentosoriundos de padroes encontrados nos dados, ao inves de coletar dados para comprovarteorias, hipoteses e modelos preconcebidos [43].

A pesquisa quantitativa geralmente se apresenta adequada quando existe a possibili-dade de medidas quantificaveis de variaveis a partir de amostras de uma populacao. Emcontrapartida, a pesquisa qualitativa se caracteriza, principalmente, pela falta de medidasnumericas e analises estatısticas, preocupando-se e analisando os aspectos mais profundose subjetivos do tema em estudo [17].

Segundo Dias [17], os metodos qualitativos sao menos estruturados, proporcionam umrelacionamento mais longo e flexıvel entre o pesquisador e os entrevistados, e lidam cominformacoes mais subjetivas, amplas e com maior riqueza de detalhes do que os metodosquantitativos .

Os metodos qualitativos geralmente utilizam procedimentos interpretativos, repre-sentacao verbal dos dados, em contraposicao a representacao numerica do metodo quan-titativo.

Segundo Wildemuth [49], a pesquisa qualitativa e geralmente associada a pesquisaexploratoria interpretativa, enquanto a pesquisa quantitativa e associada a estudos posi-tivistas confirmatorios.

Tabela 4.1 Comparacao entre pesquisa qualitativa e quantitativa.

Quantitativo QualitativoBusca a extensao Busca a profundidadeParte do objetivo Parte do subjetivoReflete o subjetivo Tenta atingir o objetivoA amostra e ampla, calculada a priori, estratificada A amostra e pequenaTrabalha com dados, indicadores e tendencias Trabalha c/ valores, crencasDescartam-se variaveis nao-representativas As variaveis sao importantes

As diferencas nao se restringem a somente ao estudo comparativo da pesquisa quan-titativa com a qualitativa. Ou seja, mesmo, quando a analise trata apenas de pesquisasqualitativas, observa-se que diferem entre si quanto ao metodo, a forma e aos objetivos.Godoy [23] respalda esta diversidade existente entre os trabalhos qualitativos, mas enu-mera um conjunto de caracterısticas essenciais, capazes de gerar uma identidade nestetipo de pesquisa:

� o ambiente natural como fonte direta de dados e o pesquisador como instrumentofundamental;


� o significado que as pessoas atribuem as coisas e a sua vida como preocupacao doinvestigador;

� carater descritivo;

� enfoque indutivo.

Na pesquisa qualitativa, a investigacao do objeto de estudo e guiada pelos seguintesprocedimentos: tecnicas de coleta, coleta, transcricao, analise e interpretacao dos dados.Os mesmos podem ser apresentados independentemente, no entanto eles apresentem umaordem em particular. Na pratica, essa ordem e representada por um processo linearou circular. O processo circular difere do linear por fazer o pesquisador estar semprerefletindo sobre todo o processo, bem como em etapas especıficas. Entretanto, o usodeste processo requer mais tempo do que o linear. Neste trabalho, por questoes detempo, o processo escolhido foi o linear, o qual e apresentado na Figura 4.1.

Figura 4.1 Uma Perspectiva do Processo de Pesquisa Qualitativa

Embora, a ampla revisao teorica desenvolvida, nao tem-se conhecimento de que oproblema tenha sido abordado sob a mesma perspectiva. Sendo assim, a presente pes-quisa pode ser considerada como exploratoria, sendo utilizado como metodo principal avalidacao com especialista da area atraves da entrevista semi-estruturada. A finalidadeda pesquisa exploratoria e desenvolver, esclarecer e modificar conceitos e/ou ideias, tendocomo objetivo a criacao de novas teorias ou amadurecimento de teorias ja existentes [22].

De acordo com o mesmo autor, a pesquisa exploratoria em muitas ocasioes constitui-se na primeira fase ou etapa de uma investigacao mais ampla. O tema em destaque,ou melhor, o tema em foco e generico, tendo a necessidade de seu esclarecimento e suasprovaveis delimitacoes, exigindo uma significativa e solida revisao da literatura, discussaocom especialistas e etc.[42].

4.2 PLANO DE PESQUISA

Nesta secao sera apresentado o plano de pesquisa, definido para realizacao do estudoempırico com Gerentes/Lıderes de projetos distribuıdos. Para tanto foi adotada comoabordagem a entrevista semi-estruturada para coleta de dados.

O pesquisador concentrou o estudo na experiencia do gerente/lıder de projeto emDDS, a fim de descobrir ate que ponto essa experiencia pode influenciar no processo decomunicacao, seja de forma positiva ou negativa. Buscou, inicialmente, o embasamentoconceitual na literatura dos temas correlatos de Desenvolvimento Distribuıdo de Software,

4.2 PLANO DE PESQUISA 53

na observancia da explanacao feita pelo entrevistado para obter um resultado positivo aofinal do projeto.

Nesta busca, as entrevistas semi-estruturadas deveriam garantir a classificacao e cate-gorizacao do material empırico. Desta forma, primeiramente, propos-se um roteiro paraas entrevistas que foi elaborado pelo proprio pesquisador e norteado pelos objetivos dapesquisa, tendo como resultado a primeira versao draft do roteiro. Seguindo as orientacoesda secao 4.1 deste trabalho, este roteiro de entrevistas, ainda sob o formato da versaodraft, foi analisado e recebeu crıticas, quanto a inducao de suas respostas ou clareza dosquestionamentos, por duas pessoas, sendo uma da area de engenharia de software e umaoutra da area de gestao de projetos. Isto resultou em um aprimoramento da escrita doroteiro da entrevista, chegando a uma versao final do mesmo contemplado com vinte eseis questoes abertas (Apendice A):

O plano da pesquisa observa atentamente os componentes basicos de uma pesquisaqualitativa, como: questoes da pesquisa, unidade de analise e criterios para interpretar osresultados. O objetivo principal deste trabalho foi a selecao de boas praticas no processode comunicacao para desenvolvimento distribuıdo de software.

A seguir apresenta-se o plano da pesquisa com suas principais fases como apresentadona Figura 4.2:

Figura 4.2 Plano da Pesquisa

Fase 1- (Concepcao): nesta fase foi pesquisada e estudada a base teorica. Fazemparte desta base teorica o estudo da literatura sobre as areas de comunicacao, gestaode comunicacao em projetos, motivacao para optar pelo desenvolvimento distribuıdo de


software (DDS), o proprio DDS e seus aspectos. Esta fase teve um grau de importanciaelevado, pois foi a partir deste estudo que tivemos uma base teorica consistente parapoder delinear e refinar a pesquisa. Em particular, o resultado do estudo da literaturarevelou que os aspectos de comunicacao em DDS sao considerados crıticos para o sucessode projetos.

Fase 2- (Estudo Empırico): nesta fase foram desenvolvidos e aplicadas uma serie deentrevistas semi - estruturadas com gestores/lıderes de projetos DDS com diferentes con-textos, permitindo o conhecimento mais aprofundado de seus impactos e consequencias.Essas entrevistas visaram levantar dados sobre variaveis presentes no contexto de cadagestor que pratica desenvolvimento o distribuıdo de software.

Fase 3- (Analise e Interpretacao dos Dados): nesta fase foi realizada a analisesobre os dados coletados. Nesta mesma fase foi gerada uma descricao da importanciada comunicacao dos aspectos encontrados e as praticas adotadas pelos gestores/lıderes.Envolveu tambem a identificacao das principais dificuldades referente a comunicacao emDDS e as praticas quem vem sendo utilizadas para resolver as mesmas.

Fase 4- (Definicao de Boas Praticas): nesta ultima fase, foi elaborado um con-junto de boas praticas baseado nas literaturas e no estudo empırico, essa proposta deboas praticas no processo de comunicacao para o DDS, contempla informacoes obtidasna analise e consolidadas atraves dos dados extraıdos na pesquisa junto aos entrevistados.

A pesquisa foi dividida em diversas etapas, como pode ser visualizado na Figura 4.3.Estas etapas descrevem exatamente como esta pesquisa foi conduzida e sao apresentadascom detalhes nos capıtulos posteriores do estudo em questao.

4.3 INSTRUMENTO DE COLETA DE DADOS

O instrumento de coleta de dados escolhido nesta pesquisa foi entrevista semi-estruturadacom perguntas abertas nao indutivas com objetivo de entender como as equipes de desen-volvimento distribuıdo de software se comunicam entre si. A escolha deste instrumentose deu devido ao estudo ser considerado exploratorio. Os projetos dos quais os entrevis-tados participam ou participaram, tinham de possuir como pre-requisitos caracterısticasde desenvolvimento distribuıdo de software, seja a dispersao nacional, continental, globalou na mesma cidade com divergencia de horarios entre as equipes.

O objetivo principal desta etapa da pesquisa foi encontrar problemas recorrentes den-tre essas equipes no que tange ao processo de comunicacao, para ser melhor estudadosna busca de boas praticas no desenvolvimento desta atividade. As entrevistas foramrealizadas de maneira presencial, onde foram feitas perguntas semi-estruturada. Essametodologia tem como objetivo evitar que a visao do entrevistador seja imposta sobre ospontos de vista do entrevistado [20].

As perguntas foram formuladas a partir dos resultados da revisao da literatura apre-sentada nos capıtulos 2 e 3. As entrevistas foram gravadas, tendo uma duracao de

4.4 SELECAO DOS PARTICIPANTES 55

Figura 4.3 Etapas da Pesquisa

aproximadamente 30 minutos. Logo em seguida, foi feita a transcricao dos dados daentrevista para que fosse possıvel definir categorias dos pontos mais importantes e emseguida, analisar os dados.

4.4 SELECAO DOS PARTICIPANTES

Os participantes da pesquisa sao gerentes e lıderes de projeto de desenvolvimento dis-tribuıdo de software . Logo no inıcio da entrevista foram obtidas informacoes sobre aformacao academica, tempo de experiencia na area TI e de gestao de projetos dentre ou-tras informacoes. As entrevista foram baseadas num conjunto de questoes, utilizando-setodas as perguntas elaboradas divididas em quatro secoes (Apendice A):

� Informacoes Basicas - Traca o perfil do Gerente/Lıder de projeto DDS, bem comodireciona perguntas basicas sobre sua experiencia profissional e caracterizacao dosprojetos em que participou.

� Desenvolvimento Distribuıdo de Software(DDS) - Busca informacoes espe-cificamente sobre os projetos DDS em que participou, bem como Investiga ex-periencias vividas pelo Gerente/Lıder nesses projetos.

� Processo de Comunicacao em DDS - O entrevistado explica metodos e praticasque utiliza no processo de comunicacao em seus projetos DDS e qual o seu enten-dimento sobre o assunto.

� Experiencia em DDS - Levanta opinioes pessoais do entrevistado sobre a melhorforma de se ter um bom processo de comunicacao e, adicionalmente, descreveralgum relato pratico sobre o tema vivenciado nesta pesquisa.


Os criterios para escolha dos entrevistados foram: ocupar cargo de gerencia ou lide-ranca de equipe(s) em projetos de desenvolvimento distribuıdo de software(DDS) e estargerenciando no momento algum projeto DDS.

Conforme as entrevistas iam sendo conduzidas, foi-se percebendo que cada entrevis-tado tinha um contexto diferenciado, contribuindo assim com suas experiencias sobrevarios projetos e nao se limitando somente a seu contexto atual.

4.5 COLETA DE DADOS

Como qualquer pesquisa qualitativa que e baseada no estudo empırico, tivemos que criaro instrumento necessario a coleta dos dados. Para isso seguimos alguns passos para ob-termos o instrumento correto as necessidades da investigacao.

Os passos foram os seguintes:

Criamos um documento MS-Word com a entrevista semi estruturada, onde a mesmaestava dividida em quatro partes: informacoes basicas, DDS, processo de comunicacaono desenvolvimento distribuıdo de software e a finalizacao da entrevista.

Para a construcao do questionario foi realizada uma analise dos pontos importantes dodesenvolvimento distribuıdo de Software (DDS), obtidas a partir do estudo da literatura.A entrevista semi-estruturada realizada teve um total de 26 perguntas agrupadas em 4secoes. Durante a apresentacao desse documento ao respondente, o pesquisador reforcavao sigilo das informacoes, o objetivo e a relevancia da pesquisa e a importancia da suacontribuicao. Devido as diferencas existentes em cada projeto o pesquisador pode fazeroutras perguntas de acordo com as respostas de cada entrevistado.

Para cada entrevistado foi enviado um e-mail convite apresentando o pesquisador,explicando o objetivo da pesquisa e as suas necessidades. Caso o convite fosse aceito odestinatario respondia a mensagem informando dia e hora de sua disponibilidade para oinıcio da entrevista.

Essa pesquisa teve como principal objetivo o suporte necessario para a selecao de umconjunto de boas praticas a serem incorporadas na execucao do processo de comunicacaopara o desenvolvimento distribuıdo de software. A analise do resultado esta descrita noCapıtulo 6.

A coleta dos dados foi guiada por um unico roteiro (documento da pesquisa) deentrevistas onde as mesmas foram constituıdas de sete entrevistas semi - estruturadasindividuais em profundidade. Partiu-se de um roteiro basico com questoes abertas naoindutivas. Todas as entrevistas foram gravadas e transcritas para texto a fim de seremanalisadas na fase seguinte.

As gravacoes em audio das entrevistas tiveram como objetivo coletar dados relevantespara serem analisados, e desta forma ajudar a propor as melhores praticas baseadas naexperiencia dos entrevistados, alem dos artigos ja publicados e propostas de modelospara o DDS ja existentes na literatura. Os resultados das entrevistas foram transcritose inseridos no NVIVO [37]. Os mesmos foram usados, como base para melhorar as

4.6 ANALISE DE DADOS 57

atividades de comunicacao realizadas em projetos distribuıdos.

4.6 ANALISE DE DADOS

A analise dos dados e a parte central da pesquisa qualitativa. Tem como objetivo desen-volver a teoria, servindo ao mesmo momento como base para a decisao sobre quais dadosadicionais devem ser coletados [20].

E de grande importancia a categorizacao essencial sobre todas as subcategorias en-volvidas [20]. E necessario que o pesquisador decida quais os fenomenos sao salientes epondera-los para obter como resultado uma categoria central juntamente com as catego-rias a ela relacionadas.

Para analise dos textos oriundos dessa pesquisa (entrevistas) foi utilizado o Softwarechamado NVIVO para auxiliar na criacao das categorias, sendo as mesmas criadas deacordo com o conteudo extraıdo dos entrevistados.

O NVIVO [37] e um software que possibilita a analise qualitativa das informacoesextraıdas em modo texto. Este tipo de software auxilia o pesquisador na organizacao dosregistros do estudo e das interpretacoes dos mesmos. A selecao de uma ferramenta dessase da pela grande dificuldade de classificar e analisar os dados extraıdos.

O NVIVO [37] foi utilizado para facilitar o entendimento dos textos extraıdos dosparticipantes do estudo empırico, das entrevistas transcritas na pesquisa. Nessa analisesomente foram levadas em consideracao as atividades referentes ao processo de comu-nicacao, foco principal desse trabalho.

As categorias foram criadas de acordo com o conteudo de cada texto transcrito. Asrespostas de cada entrevistado foram analisadas e a partir delas foram feitas a identi-ficacao das categorias, incluıdas na arvore de categorias do NVIVO [37], que contem atranscricao de cada entrevista. Levando em consideracao que uma classificacao, para sercorreta, a mesma nao pode ser elaborada de forma arbitraria. A categorizacao da arvoreexposta na Figura 4.4 foi criada e reformulada varias vezes, durante o processo de analisede acordo com [20].

Desta forma, com base na analise dos dados coletados foram identificadas durante asentrevistas realizadas com base nos entrevistados do estudo em questao, dificuldades enecessidades referentes ao processo de comunicacao.


A proposta deste trabalho e de natureza exploratoria, ou seja, nao se possuıa muitasinformacoes sobre o tema que se desejava conhecer o fenomeno. Por isso, optou-se pelaadequacao ao paradigma qualitativo, pelo metodo de estudo empırico.

Neste capıtulo, apresentou-se uma perspectiva do paradigma qualitativo, contem-plando alguns conceitos, atividades e tecnicas utilizadas, quando adotada como metodode pesquisa. Alem de fazer um breve comparativo com a pesquisa quantitativa.

Logo em seguida, procedeu-se um detalhamento do plano de pesquisa elaborado, apre-sentando algumas atividades deste paradigma qualitativo, como: tecnicas de coleta dedados, a coleta de dados, transcricao dos dados e a sua analise e interpretacao. Alem de


Figura 4.4 Arvore de Analise no Software NVivo

tudo, disponibiliza-se e introduz a forma de selecao dos entrevistados.O capıtulo 5 descreve o processo e expoe a analise efetuada, bem como as respostas

desta pesquisa.

CAPITULO 5

RESULTADOS DO ESTUDO EMPIRICO

Neste capıtulo, serao apresentados os resultados do estudo empırico. Inicialmente, seradescrito as caracterısticas de cada um dos participantes. Em seguida, discutir-se-a aanalise das entrevistas, bem como a interpretacao delas. Finalmente, na secao 5.3, seraodescritas as analises resultantes da pesquisa, visando amparar gerentes e lıderes de projetona adocao de boas praticas para o desenvolvimento distribuıdo.

5.1 CARACTERISTICAS DOS PARTICIPANTES

Conforme citado anteriormente, o roteiro da entrevista foi elaborado com o objetivo deobter informacoes sobre as experiencias dos gerentes de projeto no DDS, principalmenteinformacoes referente ao processo de comunicacao empregado pelos mesmos.

O uso desse instrumento de pesquisa possibilitou a formulacao de resultados preli-minares a respeito da caracterizacao dos projetos relatados pelos entrevistados. Alemda caracterizacao mostrada na Tabela 5.1, outros resultados foram encontrados. Um re-sultado importante e que a maioria das empresas onde os entrevistados trabalham temcertificado de qualidade (ISO, CMMI ou MPS.BR), outra resultado importante e que osprojetos relatados sao considerados de medio a grande porte. Estes sao aspectos bas-tante relevante, pois varios estudos tem enfatizado a necessidade de tais empresas emadotar nos seus projetos boas praticas de processo de comunicacao em desenvolvimentodistribuıdo de software. Algumas empresas estao envolvidas em programas de melhoriada qualidade de seus processos e produtos. Dentre os entrevistados , quatro tem suaorganizacao certificada no CMMI nıvel 2, duas tem certificacao ISO 9001 ( vide Figura5.1 uma nao tem nenhuma certificacao de qualidade implantada ou em andamento.

Tabela 5.1 Caracterizacao Geral dos EntrevistadosEntrevistado Idade Escolaridade PMP Experiencia em DDSGerente A 28 Especializacao Nao 3 anosGerente B 30 Mestrado Nao 6 anosGerente C 35 Mestrando Nao 8 anosGerente D 38 Especializacao Nao 8 anosGerente E 29 Mestrando Sim 5 anosGerente F 33 Mestrado Nao 8 anosGerente G 36 Mestrado Sim 12 anos

Para melhor identificar os entrevistados, no transcorrer do capitulo, foram adotadossete codigos (Gerente A ... Gerente G), respeitando, evidentemente, o acordo de sigilodas informacoes prestadas, firmado no momento de abertura das entrevistas.

59

60 RESULTADOS DO ESTUDO EMPIRICO

Figura 5.1 Visao geral da Certificacao de Modelos de Qualidade

Os participantes da pesquisa foram gerentes e lıderes de projeto de desenvolvimentodistribuıdo de software. Logo no inıcio das entrevistas foram obtidas informacoes sobrea formacao academica, idade, tempo de experiencia na area de TI, tempo de experienciana area de gestao de projetos e nıvel de distribuicao do projeto. As entrevistas foramrealizadas de forma presencial, com recursos de gravacao, de modo a facilitar a transcricaodos dados coletados.

Foram realizadas entrevistas com 7 profissionais. Os participantes foram selecionadosem funcao de seu papel no projeto. Foram entrevistados gerentes de projeto/lıderestecnicos, responsaveis pela qualidade da informacao repassadas para as equipes dis-tribuıdas. Os participantes entrevistados possuem um tempo medio de 13 anos de ex-periencia na area de Informatica, sendo o tempo medio de experiencia como gerentes deprojeto de 6,5 anos. A media de idade dos entrevistados e de 32,7 anos, sendo a idademınima de 28 anos e a idade maxima de 38 anos. As entrevistas tiveram uma duracaomedia de 27,14 minutos (entre um mınimo de 25 minutos e um maximo de 40 minutosde duracao) e contaram com total disponibilidade e atencao dos participantes. Foramfornecidas todas as informacoes solicitadas, sempre respeitando a polıtica de privacidadee confidencialidade do projeto em que estavam envolvidos. Com relacao ao nıvel deformacao, o grupo representa adequadamente o alto nıvel de qualificacao. Os entrevista-dos selecionados trabalham com desenvolvimento de software, teste de software, analisede requisitos em projetos distribuıdos/global (vide Figura 5.2).

Alguns resultados interessante sao que todos os entrevistados sao pos-graduados e so-mente 2 possuem o certificado PMP (vide figura 5.4). Com relacao a formacao academica,todos vem das areas da Ciencia da Computacao. Nas entrevistas, percebemos que existia2 nıveis de dispersao dentre todos os respondentes, o Nacional e Global conforme a Figura5.3.

5.2 ANALISE E INTERPRETACAO DOS DADOS DAS ENTREVISTAS 61

Figura 5.2 Area de Atuacao dos Entrevistados

Figura 5.3 Nıvel de Dispersao das Equipes

5.2 ANALISE E INTERPRETACAO DOS DADOS DAS ENTREVISTAS

Neste secao sao descritos os resultados da Entrevista Semi-Estruturada como apresentadona Figura 4.2. Detalhamos as entrevistas realizadas, descrevendo os processos e praticasde comunicacao utilizados pelos entrevistados. Ao final e realizada uma analise nos dadoscom intuito de extrair informacoes relevantes para o processo de comunicacao propostonesse trabalho.

Durante a pesquisa foram conduzidos 7 entrevistas visando explorar a problematicaescolhida para o estudo em questao, bem como obter dados relevantes extraıdos dos en-trevistados para o desenvolvimento distribuıdo de software. As descricoes das entrevistasconduzidas sao realizadas a seguir.

De acordo com o plano de pesquisa, foram conduzidas as entrevistas, visando avaliara percepcao dos envolvidos no projeto DDS, tendo como area especifica, o processo decomunicacao no desenvolvimento distribuıdo de software.

A unidade de analise dos entrevistados foi composta de projetos de desenvolvimentode software que utilizaram ou nao alguma tentativa de formalizar um processo de comu-nicacao para ambientes de DDS. Esses candidatos a serem entrevistados trabalham em


Figura 5.4 Entrevistados com Certificacao PMP

organizacoes consideradas de medio a grande porte. Foi identificado que nas empresasdos entrevistados o processo de desenvolvimento de software e baseado em metodologiasconhecidas, como RUP (Rational Unified Process) e PMI (Project Management Insti-tute).

A maior parte das organizacoes dos entrevistados possuem o certificado CMMI nıvel2. Embora cada candidato para a entrevista fosse relatar sua experiencia nos diversosprojetos DDS que participou, a entrevista em nenhum momento foi aplicada de formaindutiva, onde o objeto principal da pesquisa estava voltado em obter o maximo deinformacoes sobre DDS e mais especificamente sobre o processo de comunicacao nessesprojetos. Apos todos os envolvidos terem ciencia do escopo do estudo em questao, foiaplicada uma entrevista semi-estruturada para a captacao das praticas utilizadas em seudia - dia.

O instrumento de coleta de dados foi validado por uma pesquisadora da UFPE, alemde um gerente de projeto, passando por refinamentos decorrentes das contribuicoes ob-tidas na validacao de conteudo, ate obter sua versao final . Um pre-teste foi conduzidocom dois gerentes de projetos DDS dentre os entrevistado selecionados, sobre a versaopreliminar do instrumento, de forma a descobrir os inconvenientes, eliminar equıvocos eambiguidades e ajustar de forma mais adequada as perguntas para atingir os objetivos dapesquisa. Depois de ajustar o instrumento de acordo com o resultado do pre-teste e le-vando em consideracao sugestoes decorrentes das modificacoes realizadas, foram aplicadaas entrevistas com os gerentes/lıderes selecionados de forma presencial.

Na pesquisa, a entrevista foi respondida por sete pessoas envolvidas em projetos dedesenvolvimento distribuıdo de software, todos sao gerentes de projetos: 1 de Teste desoftware, 1 de Requisitos, 5 de Desenvolvimento de software. Apos o recebimento dasrespostas referente a entrevista aplicada, foi realizada a analise de resultados. Para isso,foi utilizada a tecnica de analise de conteudo.

5.3 CATEGORIAS E FATORES ASSOCIADOS A COMUNICACAO 63

5.3 CATEGORIAS E FATORES ASSOCIADOS A COMUNICACAO

Nesta secao, sao identificadas as principais categorias e fatores relacionados a comu-nicacao em ambientes de desenvolvimento distribuıdo de software originados da analisedas entrevistas.

Em uma primeira analise do tema, foram identificadas as categorias cultura, idioma,fuso horario, falta de documentacao, infra estrutura de comunicacao, ausencia de for-malismo, falta de entendimento entre as equipes e por fim sincronismo nas mudancasa partir dos resultados das entrevistas. Entretanto, observando a divisao realizada porCarmel [6] de forcas centrıfugas e centrıpetas em equipes globais de desenvolvimento desoftware (vide secao 3.7.1), podemos observar que as forcas centrıfugas sao relacionadasa aspectos nao tecnicos, e as forcas centrıpetas, em sua maior parte, a aspectos tecnicos.

Tracando um paralelo com essa abordagem, podemos perceber a pouca exploracao nosaspectos que tange a comunicacao em ambientes de DDS. Desse modo, foram identifica-das algumas categorias que tem impacto significativo sobre a comunicacao entre equipesdispersas, conforme a Figura 5.5. Cada uma das categorias foram exploradas no estudoe serao apresentadas com mais detalhes.

O processo de desenvolvimento distribuıdo de software depende largamente da comu-nicacao entre os envolvidos no projeto, seja de forma direta ou indireta. Nas inumerasabordagens estudadas, a comunicacao aparece como um ponto importante para o sucessodo projeto em ambientes distribuıdos. Dentre os principais fatores relacionados com acomunicacao podemos destacar cultura, idioma, fuso-horario, aspectos tecnicos dentreoutros.

Figura 5.5 Categorias com impacto na Comunicacao

As interpretacoes dos dados da pesquisa nao ratificaram algumas expectativas doautor sobre as respostas fornecidas por alguns gerentes entrevistados, porquanto que opesquisador pretendia dos gerentes experientes, uma maior contribuicao referente a ma-turidade de gestao de projetos DDS. Contudo, a contribuicao deles foi muito aquem doesperado, isto e, nao indo alem das boas praticas ja adotadas no mercado. Amparadoem sua experiencia adquirida nos estudos bibliograficos em conjunto com relatos de ex-periencias, o autor entende que este fato deve-se ao tradicionalismo adotado como padrao,


aplicando metodos e praticas de projetos centralizados para gerir projetos distribuıdos.Assim, justifica-se os problemas enfrentados referente a comunicacao em DDS.

Observou-se que a maioria dos gerentes de projeto DDS que participaram das en-trevistas, nao tem conhecimento o suficiente ou experiencia sobre o desenvolvimentodistribuıdo de software, levando o gesto a cometer erros os quais poderiam ser evitadosou minimizados.

Prosseguindo com a analise e conforme descrito em secoes anteriores, empregaram-se,para agregar as informacoes obtidas nas entrevistas, categorias que estao alinhadas como guia de entrevista utilizado e foram armazenadas no software NVivo, em estrutura dearvore 5.6.

Figura 5.6 Estrutura da Arvore no NVivo

Avaliando-se os nos da arvore, ja devidamente carregados com os textos analisadosface a uma primeira decomposicao do pesquisador, observa-se a condensacao do pen-samento expresso pelos analistas entrevistados, cujas analises destes serao apresentadassequencialmente nas subsecoes abaixo.

Algumas dessas categorias como fuso-horario, cultura e idioma ja foram citadas pordiversos autores [6], [18], [40]. Porem, neste estudo, identificamos outras categorias dosdados extraıdos atraves das entrevistas, as quais sao de grande impacto no processo decomunicacao no DDS. Sao elas:

Abordou-se esses temas, nas entrevistas, para tentar buscar o maximo de informacoespara amadurecer a proposta deste trabalho.

Idioma - Sem duvida o idioma e um fator impactante no desenvolvimento distribuıdode software, pois sabemos que em uma equipe, nem todos sao fluentes no idioma padraoadotado pelo projeto ( na maioria das vezes o idioma padrao e o ingles). Muitas vezes,por causa de uma palavra, podemos criar um grande conflito entre as equipes, e paraque isso nao venha a acontecer, e importante que venhamos a criar pontos focais (pessoas


chaves ou interlocutores) fluentes na lıngua padrao adotada pelo projeto, onde os mesmosserao responsaveis pela comunicacao entre as equipes do projeto. Esta pratica e uma dassugeridas por esta dissertacao no capıtulo 6. Em seguida iremos apresentar alguns trechosdas entrevistas transcritas que permitem ilustrar estes resultados, como por exemplo, acitacao de alguns dos gerentes de projeto:

O Gerente G ressalta que ”a primeira grande dificuldade referente ao idioma, eque nem toda a equipe falava ingles. Entao isso muitas vezes, quando voce trabalha deforma centralizada, voce ja tem uma certa perda das coisas que voce passa para ou equipe.Entao, cada vez que isso acontece na comunicacao voce tem um grau de perda. Agoraimagine isso numa lıngua que nao e a sua de origem. Entao havia esse tipo de perda ealem disso havia o fato de que eu nao podia simplesmente pegar todas as pessoas do time,e colocar dentro de uma sala, em conferencia. Eu fazia isso, que todo mundo sabe ingles,entende um pouco e tal, mas nao tinha uma fluencia de toda a equipe. Entao quandoa gente recebia as informacoes, a gente nem sempre conseguia processa-las de uma ma-neira tranquila.”. O Gerente F cita alguns exemplos como: ”E visıvel que um chinestem sotaque muito forte, o indiano e muito difıcil voce entender, muito difıcil mesmo,ele tem um sotaque muito carregado. Ja o alemao nem tanto, o que acontece, e que agente acaba tendo tantas reunioes, que a gente se acostuma com o sotaque das pessoas.Entao eu sei o que ela ta falando, porque eu ja conheco o sotaque dela, mas no primeiromomento, e complicado. Porque e difıcil de entender e a gente tem que pedir pra repetir.”

Fuso-Horario - Podemos perceber que o fuso horario e um fator de grande impactono projeto, porem pode ser usado em benefıcio do projeto se bem planejado e organi-zado. Podemos tirar proveito de termos equipes distribuıdas globalmente e colocarmosem pratica o desenvolvimento contınuo. Varios dos entrevistados disseram que utilizamdeste artifıcio para obter uma maior produtividade. A maior dificuldade e a comunicacaoem tempo real, pois alguns paıses tem uma diferenca grande de horas comparado a outrospaıses. Essa distancia temporal pode ser minimizada com alguns sacrifıcios das equipes,como por exemplo: ter que fazer reunioes apos o expediente ou so ter uma unica opor-tunidade (um unico horario) no dia para fazer uma reuniao. O Gerente A fala que”muitas vezes juntava horario de verao dos Estados Unidos com o de Sao Paulo, e essefuso horario tambem atrapalhava bastante quando a gente tentava colocar todo mundonuma mesma reuniao.” Diante deste contexto podemos visualizar que dependendo donıvel de dispersao o impacto pode ser maior ou menor.

Cultura - A diversidade cultural e muito grande em um unico paıs como o Brasil.Entao podemos perceber que uma diversidade cultural global e muito maior e pode cau-sar grande problemas ao projeto. Diante deste cenario, todos os entrevistados tratarama cultura como fator de grande impacto na comunicacao entre as equipes. Esse impactofoi devido a falta de conhecimento do contexto cultural de cada equipe. Alguns estudosmostram que existem nacoes que trabalham bem com incerteza e outras nao, em outrasnacoes a diferenca como feminilidade, preocupa-se mais acentuadamente com qualidadee a masculinidade preocupa-se em alcancar os resultados. Essas diferencas podem levar


um projeto ao declınio se mal gerenciado. Sobre a cultura o Gerente E ressalta queem ”relacao a mesma, falaria basicamente que foi o que mais pegou, mas por exemplo,se voce nao conhece o idioma, se voce nao conhece a cultura, e muito facil fazer vocepecar ou errar. Eu tenho por exemplo, lıderes de equipe que sao novos, que entram emcontato com o cliente frequentemente, eu nao autorizo nenhum e-mail que eles mandemsem que eu revise. Por que eles podem utilizar algum termo que seja ofensivo, que pragente e normal. Isso e uma questao cultural”. Neste cenario e facil visualizar que aindaestamos usando metodos e ferramentas pouco adequados para a adocao de forma corretaao desenvolvimento distribuıdo de software. Atraves destas praticas relatadas pelos en-trevistados, vamos poder propor boas praticas para dar um horizontes aos gestores queainda nao estao a vontade na com esta nova forma de desenvolver software.

Falta de documentacao - A falta de documentacao e algo comum em projetos dis-tribuıdos, pois como os gerentes nao tem muita experiencia em DDS, acabam pensandoque para manter uma documentacao atualizada, sera um desgaste muito grande e umaenorme burocracia. Esse pensamento tende a levar o projeto ao caos. segundo o Ge-rente E ”se nao tivermos uma documentacao que realmente seja didatica, que seja ricaem conteudo, teremos grandes problemas e isso tambem dificulta o trabalho dos outrostimes. Entao a gente gasta um bom tempo do desenvolvimento, muito mais do que onormal, pra escrever uma documentacao. Entao, essa documentacao que a gente chamaGuia do Desenvolvedor, tem informacoes dos releases passados, aonde a pessoa pode fazero download, e saber o que veio de novo naquela versao, tem informacao de planejamento,o que vai esta nas versoes pra frente e etc. Tudo isso a gente tem que planejar com 6meses, 1 ano de antecedencia.”. E visıvel a confusao dos gestores em decidir documentarou nao, projetos distribuıdos. Alguns gestores optaram pela adocao de metodologicasageis junto ao desenvolvimento distribuıdo para que desta forma pudesse minimizar aconfeccao de documentacao. Porem, e percebido que a adocao de metodologicas ageis ebem vinda para o DDS, mas nao evita a necessidade de documentacao. Contudo, nao einteressante negligenciar algumas documentacoes como acontece nos projetos centraliza-dos que usam tais metodologicas, pois em DDS barreira temporal e extremamente levadaem consideracao obrigando a uma comunicacao mais formal, clara e objetiva.

Sincronismo nas mudancas - A quantidade de mudancas em projetos e claramentepercebida, pois essas mudancas ja nos traz alguns problemas em equipes centralizadas,e com equipes distribuıdas, esse fator tem maior impacto. Uma vez que temos em umprojeto, um grande fluxo de mudancas e nao temos processos adequados ao DDS paragerencia-los, muito provavelmente teremos equipes desenvolvendo atividades que seraorefeitas devido ao nao sincronismo das mudancas ocorridos no projeto. De acordo com oGerente D - E necessario fazer uma comunicacao, pra todo o time, semanal. E sobreas mudancas do projeto e o engracado, e um projeto que trabalham 40 pessoas e todasemana existem 10 itens novos para serem vistos. Entao a comunicacao, ela tem que serperiodica. (...)adotar templates para comunicacao e interessante. Por exemplo, o que eimportante repassar pro time? Uma mudanca de escopo, entao toda segunda-feira tenhoque passar um e-mail notificando, essa mudanca de escopo. Nao so pro time que ja foi


afetado, por que o time que foi afetado eu ja notifiquei.

Infra-estrutura de comunicacao - Hoje, podemos perceber que existe um investi-mento bem significativo para o desenvolvimento de ferramentas que tem como objetivo,nos auxiliar ao maximo para desenvolver tal produto ou servico. Para o desenvolvimentodistribuıdo de software, ter uma estrutura bem definida, ter a flexibilidade de escolha ouadocao de ferramentas, e muito importante, pois como as equipes estao muito dependen-tes do avanco tecnologico, os gerentes precisam de solucoes para diminuir as barreirascausadas pela dispersao geografica e temporal. O Gerente A diz: hoje visualizamos umgrande problema, que no caso e a falta de um ferramental padronizado pra se realizar acomunicacao e manter a mesma funcionando de forma adequada, talvez fosse interessanteuma ferramenta que gravasse toda comunicacao.

Falta de formalismo - Esse aspecto e comum em projetos centralizados, pois, comoestao proximos fisicamente, a comunicacao informal permeia por toda a organizacao demaneira que nao tem um impacto tao negativo. Este tipo de atitude no DDS e muitocomplexo, pois principalmente em equipes globais, a diversidade cultural e muito grandee a informalidade por ser interpretada como grosseria ou falta de respeito. Desta forma,por causa da falta de formalismo, podemos criar um enorme conflito. Diante de um pro-blema comum ao desenvolvimento centralizado e distribuıdo o Gerente E diz: a gentetenta formalizar o maximo, e nao e por conta da dificuldade de comunicacao, e sim porconta dessa questao de distancia, das pessoas, a gente tenta formalizar o maximo possıvel,tudo que e dito, por exemplo, numa reuniao. A distancia fısica e algo que nos deixa cominterpretacoes erroneas em certos momentos. Por exemplo: Um dos membros pode en-viar um email totalmente informal, algo que nunca tinha acontecido, mas dependendo decomo a pessoa escreveu, voce pode interpretar de varias formas.

Falta de entendimento - Esse aspecto tambem e muito difıcil de solucionar, poisdependendo do tamanho da equipe, a comunicacao fica mais pesada, ou seja, difıcil dese gerenciar e acompanhar para saber se realmente o processo de comunicacao ocorreusem ruıdo. Algumas gerentes falam que ate hoje nao conseguiram achar uma maneirade confirmar se a mensagem foi recebida pelo destinatario, e se a mesma foi interpre-tada corretamente. O Gerente B diz que: para sincronizar o entendimento, a gentetem reunioes quinzenais. Fora isso a gente manda e-mail tambem, caso haja algumamudanca. Mas, o importante e que eu nao posso deixar que passe nada despercebido, ouentao algo que ja foi comentado e que eles ainda nao entenderam. Caso isso aconteca eeu venha a perceber, aı eu tento passar outro e-mail explicando novamente.

Neste capıtulo, outras categorias mais abrangentes poderiam ter sido relacionadas,mas para efeito desse estudo empırico, foram considerados apenas as principais catego-rias de grande impacto no processo de comunicacao em DDS, devido a importancia queadquiriram nas abordagens estudadas [19], [6], [40]. Essa analise visa encontrar e deta-lhar os fatores importantes que devem ser enderecados por um guia de boas praticas noprocesso de comunicacao para ambientes distribuıdos.



Neste capıtulo foi apresentado a caracterizacao dos entrevistados. Onde atraves destasinformacoes foi possıvel tracar um perfil dos mesmos e elaborar uma tabela e um graficocom dados relevantes, como por exemplo: mapear porte de projetos, experiencia dosentrevistados na area de TI e na area de gestao de projetos. Alem disso, a pesquisaidentificou categorias que tem impacto direto no processo de comunicacao. Essas ca-tegorias foram mapeadas atraves da pesquisa em literaturas e o estudo empırico, ondeas informacoes extraıdas das entrevistas forma gravadas e transcritas para o papel. Es-sas categorias foram detalhadas e serviu como base para a elaboracao das Boas praticaspropostas no capıtulo 6.

CAPITULO 6

PROPOSTA DE BOAS PRATICAS PARA PROCESSODE COMUNICACAO EM DDS

Neste capıtulo e apresentada uma proposta de boas praticas do processo de comunicacaopara ambientes de desenvolvimento distribuıdo de software, com base na teoria existenteno assunto e nos resultados do estudo empırico. As boas praticas, visam minimizar oimpacto da dispersao geografica no processo de comunicacao entre as equipes distribuıdasgeograficamente.

Diante da importancia que o processo de comunicacao tem em todo o ciclo de vidade um projeto de desenvolvimento de software, este capıtulo apresenta boas praticas doprocesso de comunicacao baseado nas literaturas e no estudo empırico, que contempla asnecessidades do desenvolvimento distribuıdo de software. Vale salientar que este trabalhotambem contempla solucoes para os desafios encontrados no processo de comunicacao emambientes distribuıdos de desenvolvimento apresentados na no capıtulo 3 e secao 3.5.

Para a elaboracao dessas boas praticas foi utilizado estudo empırico atraves de tecnicasde pesquisa qualitativa com uso de entrevista semi-estruturada nao indutivas [20]. O re-sultado desse estudo esta descrito no capıtulo 5 e secao 5.2. Como resultado da analiseforam extraıdos informacoes relevantes que definiram alguns problemas da comunicacaoem ambientes de desenvolvimento distribuıdo de software (DDS), os quais merecem umaatencao especial quando comparado ao desenvolvimento centralizado, como: falta de do-cumentacao, diversidade cultural, idioma, fuso horario, sincronismo nas mudancas, faltade entendimento, falta de formalidade, ausencia de uma infra estrutura de comunicacao.

Com o desenvolvimento desta proposta, procuramos analisar cuidadosamente e proporboas praticas que fossem genericas o suficiente para domınios distintos com necessidadesde DDS, como por exemplo: diminuir a distancia fısica entre as equipes, maior integracaoda equipes dentre outros. Desta maneira, podemos dizer que a maior contribuicao destapesquisa e fornecer um conjunto coerente de boas praticas baseadas na literatura e noestudo empırico e direcionado para o processo de comunicacao em DDS. Essas boaspraticas podem ajudar ao gerente da equipe a minimizar os impactos negativos causadospela falta de um processo de comunicacao bem definido.

6.1 DESCRICAO DA PRATICAS

O objetivo dessas praticas e apresentar uma forma de guiar o gerenciamento da comu-nicacao em ambientes de desenvolvimento distribuıdos de software. Espera-se que essasboas praticas possam auxiliar os gerentes de DDS a minimizar os insucessos de projetoscausados pelo mal gerenciamento da comunicacao. Um dos principais objetivos dessapesquisa, e diminuir a distancia fısica entre as equipes atraves de uma comunicacao cor-reta e bem definida. Essas praticas foram baseadas e inspiradas nos trabalhos de Ivar

69

70 PROPOSTA DE BOAS PRATICAS PARA PROCESSO DE COMUNICACAO EM DDS

Jacobson e Ian Sommerville [47]. De acordo com Jacobson [27] as boas praticas tem ointuito de permitir que as equipes criem um ambiente de trabalho mais efetivo.

6.1.1 Abertura do Projeto Distribuıdo com Reuniao Presencial

Problema.Devido as equipes estarem separadas geograficamente, muitas vezes a abertura do projetoe feita de forma virtual, ou seja, via tele-conferencia ou video-conferencia. Entretanto, emuito importante essa reuniao de abertura ( kick-off ) para que todos venham a partici-par e entender o objetivo do projeto.

Pratica.

Iniciar a reuniao de kick-off tambem conhecido como ”chute inicial”no projeto deforma presencial. A ideia principal e reunir todos os envolvidos, ou seja, stakeholders efazer uma apresentacao dos topicos e fases do projeto assim como as responsabilidadesde cada equipe. Essa reuniao tambem servira para um primeiro contato entre as equipes,pois devido a distancia, o maior contato sera virtualmente.

Contexto.

E necessario implantar esta pratica sempre que for iniciar um novo projeto, mesmoque esse novo projeto seja com as mesmas equipes.

Responsaveis pela atividade.

Gerentes de projeto, Alta administracao.

Resultados esperados.

A partir desta pratica, podemos esperar um maior comprometimento e alinhamentodas atividades dentre as equipes com o mesmo objetivo entre elas. Desta forma, podemosmanter a motivacao de todos em alta.

Dificuldades.

Devido a dispersao dos membros das equipes, seja nacionalmente ou globalmente, ocusto e alto para reunir todos do projeto, e por tal motivo, as vezes nao e possıvel trazertodos que compoe o projeto.

6.1.2 Criar Pontos Focais

Problema.

6.1 DESCRICAO DA PRATICAS 71

A ausencia de identificacao de responsaveis por cada informacao ou atividade. Asequipes muitas vezes precisam enviar uma informacao e nao sabe para quem enviar, oua equipe pode estar com algum problema e a mesma nao sabe a quem recorrer para so-lucionar o seu problema.

Pratica.

A definicao de pontos focais em todas as localidades responsaveis por cada equipeou tipo de informacao, por exemplo: essa pratica minimiza os problemas existentes nacomunicacao entre as equipes distribuıdas. A lista de pontos focais deve ser totalmentecompartilhada com todas as equipes do projeto, para que todos envolvidos no processopossam consultar, quando necessario.

Contexto.

E necessario implantar essa pratica quando as reunioes face a face basicamente naoexistem, sendo a comunicacao quase em sua completude apoiada pelos meios tecnologicos.Quando temos projetos que a distancia temporal e muito grande, os pontos focais temum valor mais significativo ainda dentro do projeto, pois e neste momento que o pontofocal assume a responsabilidade e tenta minimizar os conflitos de informacoes causadosmuitas vezes pela diversidade cultural.


Gerentes e Lıderes de projeto.


Uma vez que essa pratica e estabelecida e institucionalizada dentro do projeto, iremosminimizar o overheard de mensagens (envio exagerado de mensagens desnecessarias) ouconsultas as pessoas erradas, iremos obter a clareza nas informacoes e maior objetividadedentro do projeto, alem de criar um canal de comunicacao informal entre as localidadesenvolvidas, entre os outros pontos focais das equipes distribuıdas.

Dificuldades.

Uma das dificuldades para se criar um ponto focal e basicamente encontrar dentroda equipe alguem com esse perfil. O profissional tem que saber se relacionar bem comas pessoas, alem de ter uma boa comunicacao e interpretacao para conseguir ser claro,objetivo e fiel a informacao original recebida. Uma vez que ele tera que ser o porta vozentre as equipes. Esse profissional tem que ter uma facilidade para lidar com culturasdiversas.


6.1.3 Manter a Cordealidade

Problema.Devido a necessidade de estar sempre em contato com novas culturas, seja no brasil ouno exterior. Se faz necessario manter harmonia no ambiente e no projeto.

Pratica.

Aprender a tratar os membros, colaboradores do projeto de forma cordial, educadae tranquila para nao gerar problemas futuros entre as equipes do projeto. Exemplo:sempre agradecer a atencao; tentar responder os emails em tempo habil; mesmo quandodiscordar de algo, tente nao de impor sua visao de forma autoritaria.

Contexto.

E necessario que esse tipo de tratamento permeia todo o ciclo de vida do projeto.


Os Stakeholders.


Maior harmonia entre as equipes distribuıdas pertencente ao projeto e menos conflitosno ambiente de trabalho.

Dificuldades.Cultura, recursos humano.

6.1.4 Documentacao

Problema.

Em projetos distribuıdos e facil perceber que documentacao nao e um ponto forte dasequipes. Pois e fato, que documentar requer tempo, e em DDS tempo e muito precioso.

Pratica.Registrar e documentar tudo que seja para entendimento e uso das equipes diistribuıdas.Como por exemplo: Atas, Emails, Guia de desenvolvimento de software, informacoesde bugtrack, plano de comunicacao dentre outros. Alem disso, e interessante antes dequalquer reuniao, seja ela virtual ou presencial, elaborar uma pauta, e enviar aos par-ticipantes para saber se alguem quer sugerir algum outro topico para ser discutido nareuniao. Adotar atas nas reunioes para firmar o acordo diante de todos os participantes.


Dependendo da reuniao, ela pode ate ser filmada para servir como registro.

Contexto.

E muito comum as reunioes nao terem atas ou registros e apos a mesma, cada membrosai com sua propria percepcao/interpretacao da reuniao.




Minimizar conflitos em reunioes e no progresso do Projeto DDS.

Dificuldades.

Falta de definicao de processos padronizados e falta de cultura referente a importanciada documentacao.

6.1.5 Definicao de Vocabulario

Problema.

Devido as diversidades culturais, cada equipe pode ter um vocabulario distinto difi-cultando assim a comunicacao com as outras equipes do projeto.

Pratica.

Definir e institucionalizar um vocabulario para o desenvolvimento do produto no pro-jeto, onde todos possam entender o que esta sendo dito e comunicado de forma clarae objetiva. Alem disso, e interessante definir um dicionario do Idioma escolhido para oprojeto com uma quantidade de palavras pertinentes a complexidade do projeto (as maisusadas), que permitem as equipes nao nativas no idioma escolhido, a terem uma maiorfacilidade para compreender as informacoes

Contexto.

Ambiente sem padronizacao e com varios idiomas nativos entre as equipes envolvidasno projeto.



Gerentes de projeto, Integrantes das equipes.


Um vocabulario unico no projeto e um dicionario do idioma escolhido.

Dificuldades.

Escolha do modelo para servir de referencia para a definicao do vocabulario. Institu-cionalizar o vocabulario no projeto.

6.1.6 Criar Portal Institucional

Problema.

Hoje nos projetos DDS, a maioria nao tem uma institucionalizacao do que e o projeto,quem sao as equipes, qual o nıvel de dispersao, contexto e o que elas estao fazendo.

Pratica.

Criar um portal que ira descrever o projeto, descrever perfis das equipes participantesdo projeto (informacoes de cada membro), quais atividades cada equipe esta desenvol-vendo, status do projeto, guia de desenvolvimento. Alem de toda documentacao estardisponıvel para as pessoas pertinentes no portal.

Contexto.

A ausencia de informacoes relevantes sobre as equipes e principalmente do projeto,causa uma desmotivacao e muitas vezes falta de comprometimento. Alem de deixar claroa definicao de responsabilidades das atividades de cada equipe e seus respectivos membros.


Gerentes de projeto.


Equipes mais bem informadas, motivadas, equipe consciente da definicao dos papeisde cada membro do projeto, maior interacao entre as equipes. Criar uma base de conhe-cimento para reunir as informacoes em um unico lugar e permitir as equipes acessarempara acompanhar o projeto de forma centralizado.

Dificuldades.


Requer tempo para implementar, a falta de importancia devido a pouca experienciaem projetos DDS.

6.1.7 Definicao de um Plano de Comunicacao

Problema.

As empresas conhecem a necessidade de se gerenciar comunicacao, de manter umacomunicacao correta, porem nao dao a devida importancia.

Pratica.

Nesta Pratica, a colocacao das informacoes necessarias a disposicao das partes inte-ressadas no projeto no momento adequado. Pode ser no portal institucional. Alem disso,no plano de comunicacao e importante conter quais artefatos serao documentados e atu-alizados. Esta pratica e totalmente relacionada a pratica de documentacao. Escolhertecnologia que apoiem o DDS como por exemplo: Tele-conferencia, Video-Conferencia,email, Netmeeting dentre outros.

Contexto.

A comunicacao adequada entre as partes envolvidas em um projeto e fator fundamen-tal para seu sucesso e exige o uso de instrumentos adequados e formalizados.


Gerentes de projeto.


Uma comunicacao correta, formalizada, isntitucionalizada e que esteja sendo execu-tada dentro do projeto.

Dificuldades.

Falta de conhecimento, falta de importancia a esta area de conhecimento.

6.1.8 Curso de Ingles para Negocios

Problema.


Devido a muitos membros das equipes nao serem nativos do idioma escolhido (namaioria das vezes o ingles, EUA e Inglaterra) podem ocorrer em algum momento umaofensa a alguma equipe por nao saberem exatamente como falar de forma adequada.

Pratica.

Implantar um curso de ingles para negocio. Desta forma os membros da equipe iraoaprender a falar o idioma corretamente de acordo com o contexto do projeto.

Contexto.

O idioma universal e o ingles. Em projetos DDS existem equipes Globais, ou seja,equipes distribuıdas no japao, China, India, Alemanha e etc. Diante deste cenario, te-mos uma diversidade cultural muito grande onde precisamos saber exatamente como eo que falar em uma reuniao, em uma conversa informal, para nao gerar conflitos ou malentendido.




Como resultado, esperamos diminuir os conflitos oriundos do mal entendido por causado idioma.

Dificuldades.

Custo e tempo disponıvel dos membros de cada equipe para o estudo .

6.1.9 Adocao Video-Conferencia

Problema.

Muitas empresas adotam varias ferramentas para apoiar o desenvolvimento distribuıdo,mas as ferramentas selecionadas nao suprem a real necessidade do projeto.

Pratica.

Implantar video-conferencia para diminuir a barreira da distancia fısica e a falta decontato face a face entre as equipes.

Contexto.


Hoje em dia, estamos cada vez mais utilizando ferramentas para nos comunicarmoscom outras pessoas, Essas ferramentas geralmente sao: email, chat, telefone skype dentreoutras. Em projetos DDS e necessario que essas ferramentas estejam disponıveis parauso. Porem, devido a distancia fısica e necessario fazermos reunioes face a face e isso epossıvel somente atraves de uma video conferencia ou alguma ferramenta que possibiliteessa interacao. Esse tipo de interacao minimiza os erros na interpretacao.




Reunioes mais produtivas, diminuicao de mal entendidos em reunioes, desenvolvi-mento de atividades e no levantamento de requisitos.

Dificuldades.

Alto Custo.

6.1.10 Reunioes Periodicas

Problema.

A equipe pode se sentir abandonada (isolada) e perder a motivacao pelo projeto.

Pratica.

Reunioes virtuais semanalmente com as equipes distribuıdas para poder acompanharo projeto e seus resultados com maior clareza.

A cada 3 meses, reunioes presencias com os lıderes de equipe ou pontos focais parare-alinhar as mudancas de escopo dentre outros assuntos.

Contexto.

E comum que as equipes se falem pouco ou quase nao se vejam no perıodo do pro-jetos DDS. Isso pode causar um impacto grande no momento da integracao das partesdesenvolvidas por cada equipe, devido a nao estarem sincronizadas.





Diminuir o impacto de problemas e duvidas no projeto, tirar duvidas mais cedo noprojeto e por fim, manter todos alinhados com o objetivo do projeto. Alem de fazer comque cada equipe possam ajudar as demais.

Dificuldades.

Fuso-horario.

6.1.11 Criar e Alimentar a Base de Informacoes Culturais

Problema.

No DDS, as diferencas culturais e diferencas de contexto, podem causar uma visaodiferenciada entre as equipes, referente ao sistema a ser desenvolvido.

Pratica.

Criar uma base de dados com informacoes culturais e de contexto (base de conheci-mento) para servir como base de informacoes para as equipes distribuıdas.

Contexto.

Quando estiver com equipes distribuıdas e existir divergencias no entendimento dasinformacoes.


Todos os envolvidos.


Maior integracao entre as equipes.

Dificuldades.

Custo.

6.2 CONSIDERACOES FINAIS 79


Atualmente, podemos visualizar o crescente numero de empresas que estao aderindoao desenvolvimento distribuıdo de software. Essas empresas, buscam as vantagens queo DDS pode promover como benefıcio. Contudo, essas empresas esquecem de definira estrategia de negocio e em seguida, definir seus processos. Hoje, uma boa parte dosestudos sobre DDS, estao direcionados a engenharia de requisitos, por ser um dos maioresproblemas do desenvolvimento em geral, seja ele centralizado ou distribuıdo.

Neste capıtulo foi apresentado as boas praticas baseado na literatura e nos trabalhosmundialmente conhecido de Ivar jacobson [27] e Ian Sommerville [47], alem dos relatosde experiencias dos entrevistados.

Essas praticas tem como objetivo principal guiar o gerente para que o mesmo possaminimizar os impactos negativos no projeto.

CAPITULO 7

CONCLUSAO E TRABALHOS FUTUROS

Neste capıtulo, oportunamente expomos as contribuicoes de boas praticas derivadas destabase de informacoes. Finalizando o capıtulo com sugestoes de trabalhos futuros que namesma linha de pesquisa o complementaria.

E muito comum encontrarmos gerentes de projeto de desenvolvimento de softwaresem o conhecimento necessario para compreender a importancia de um processo de co-municacao. Em um ambiente onde existe a distribuicao fısica dos participantes e nao haum processo definido de comunicacao, os problemas se agravam e fica mais difıcil planejar,estimar o tamanho, modificar e produzir o software.

A tecnologia e uma peca fundamental para e cada vez mais indispensavel para o de-senvolvimento distribuıdo, pois o mesmo e altamente dependente da mesma. Atualmentediversas empresas estao distribuindo seus processos globalmente, objetivando ganhos deprodutividade, diminuicao de custos e melhorias na qualidade. Neste contexto, o ambi-ente de DDS surge como um grande desafio na area de Engenharia de Software. As boaspraticas no processo de comunicacao propostas para DDS e uma tentativa de contribuirna busca de respostas a uma nova categoria de problemas que o ambiente distribuıdoapresenta. Portanto, do prisma cientıfico, a proposta de boas praticas e decorrente doprocesso de pesquisa como um todo, representado pelo plano de pesquisa detalhado nasdiversas fases do estudo, conforme apresentado no capıtulo 4.

O desenvolvimento de software sempre se apresentou de forma complexa. Existemvarios problemas e desafios inerentes ao processo [38]. Assim como o processo de desen-volvimento de software tem se tornado cada mais complexo, a distribuicao de processos,a distribuicao das equipes no tempo e no espaco tem tornado o DDS cada vez mais co-muns. Projetos centralizados permitem uma gestao atraves de observacao, tendo algumasdesvantagens como por exemplo: a comunicacao informal. Entretanto, por outro lado, adistribuicao das equipes possui suas vantagens. Dentre elas, podemos citar a existenciade grupos propensos a inovacao e um maior formalismo em todas as tarefas e acoes [40].

O DDS, ao acrescentar fatores como distancia fısica, fuso horario e diferencas cul-turais, herdou alguns dos desafios existentes e acrescentou novos desafios ao processode desenvolvimento. Entre estes desafios podemos citar questoes estrategicas, questoesculturais, gestao do conhecimento e gerencia de riscos. Por isso, o trabalho em ambi-entes DDS e mais complexo do que em ambientes centralizados. O valor da interacaosocial nao deve ser tratado como irrelevante. A construcao de confianca entre as equipesdistribuıdas deve ser fomentada e facilitada [6], [32]. Por isso, o trabalho na prevencaode dificuldades e problemas decorrentes tanto dos fatores tecnicos como dos nao-tecnicosdevem ser sempre valorizado.

81

82 CONCLUSAO E TRABALHOS FUTUROS

7.1 CONTRIBUICOES

De uma forma geral, a proposta deste trabalho auxiliou a atender melhor o Desenvolvi-mento Distribuıdo de Software-DDS e mais especificamente o processo de comunicacaoinserido neste contexto.

� A Identificacao e apresentacao de problemas relacionados a comunicacao nos mos-trou que Percepcao ou Awareness, Contexto, Dispersao geografica e temporal, For-mas de comunicacao, Fuso Horario, sao fatores que quando identificados, fica masfacil de se gerenciar um projeto distribuıdo. Uma vez que o Gerente dar a devidaimportancia a cada um desses fatores, o projeto amadurece e minimiza as probabi-lidades de impactos negativos;

� A Falta de experiencia dos Gerentes no desenvolvimento distribuıdo de software, evisıvel ao longo das entrevistas, pois foram colocados dentro desses projetos, semuma previa contextualizacao do que e ou o que vem a ser DDS. Gerenciar um projetodistribuıdo nao e o mesmo que gerenciar um projeto centralizado. Entretanto,podemos aproveitar muito da experiencia vivenciada pelo gerente nos varios projetosque o memso participou. Contudo, o desenvolvimento distribuıdo de software e temos mesmos problemas do desenvolvimento centralizado e outras dificuldades geradaspela dispersao fısica;

� A Definicao de boas praticas e fruto de um estudo da teoria junto com o estudoempırico. Este estudo nos levou a propor boas praticas para dar um ”horizonte”aosgerentes de projetos DDS apresentado no capıtulo 6. As boas praticas sao:

1. Abertura do Projeto Distribuıdo com Reuniao Presencial;

2. Criar Pontos Focais;

3. Manter a Cordealidade;

4. Documentacao;

5. Definicao de Vocabulario;

6. Criar Portal Institucional;

7. Definicao de um Plano de Comunicacao;

8. Curso de Ingles para Negocios;

9. Adocao Video-Conferencia;

10. Reunioes Periodicas;

11. Criar e Alimentar a Base de Informacoes Culturais.

7.2 LIMITACOES DO TRABALHO 83

7.2 LIMITACOES DO TRABALHO

Uma das principais limitacoes da pesquisa refere-se ao numero de entrevitados na pes-quisa empırica do estudo, restringindo a generalizacao dos resultados obtidos. Deve-se,entretanto, destacar que os resultados do estudo principalmente os da categorizacao doselementos, foram sustentados na base teorica estudada e nas informacoes extraıdas dasentrevistas, o que permite um bom grau de seguranca nas conclusoes obtidas.

7.3 TRABALHOS FUTUROS

Como pesquisas futuras, sugere-se:

A realizacao de experimentos visando avaliar a proposta de boas praticas no processode comunicacao para DDS;

Um aprofundamento do estudo na area do processo de comunicacao, onde problemascomo a falta de uma ferramenta que unifique necessidades do DDS como comunicacaoescrita e visual, transferencia de documentos, desenvolvimento de software e etc.

Por fim, a elaboracao de uma proposta de um modelo de referencia para o processode comunicacao no desenvolvimento distribuıdo de software.

CAPITULO 8

APENDICE A

Introducao

O objetivo desta pesquisa e buscar informacoes baseada na experiencia dos gerentes deprojetos em DDS, para que venha ajudar a identificar os principais problemas/ dificulda-des e suas respectivas solucoes, quando houver, no processo de comunicacao de Projetosque tenham equipes dispersas (separadas) geograficamente.

Observacoes:

Essa entrevista tem 26 perguntas basicas;Todo conteudo da entrevista sera tratado como confidencial e na minha dissertacao naoirei divulgar nomes/empresas que participaram da pesquisa.

Parte I - informacoes Basicas

1. Quantos anos de experiencia voce tem na area de informatica?2. Quantos anos de experiencia voce tem como Gerente de Projetos ?3. Explique qual o tipo de projeto que normalmente voce esta envolvido?4. Poderia falar de alguns projetos que voce ja participou?5. A empresa ou projeto que voce participa e certificado em algum modelo de qualidade(CMMI, MPS.BR e etc.) ?6. No projeto, existe algum processo formal de desenvolvimento de software utilizado(metodologia, ciclo de vida)?7. Voce saberia me dizer o que levou a empresa aderir ao Desenvolvimento Distribuıdode SW?8. Se a decisao fosse sua, voce optava por Desenvolvimento Distribuıdo de SW?

Parte II - DDS

9. Quantas pessoas geralmente participam de uma equipe no projeto de Desenvolvi-mento Distribuıdo de Software (DDS) na qual voce gerenciou?10. Como e feita a atribuicao dos papeis de cada membro da equipe?11. Qual o nıvel de dispersao das equipes (Nacional, Continental ou Global)?12. No projeto, voce tinha alguma formalizacao na maneira de se comunicar entre asequipes ( expressoes, jargoes e etc.)?13. Caso o projeto tenha como nıvel de dispersao continental ou global, existe a forma-lizacao de um idioma padrao?

85

86 APENDICE A

14. Em projetos de DDS, quais as principais dificuldades enfrentadas?

Parte III - Processo de Comunicacao em DDS

15. Na sua opiniao, quais os principais desafios em ordem de dificuldades enfrentadascom relacao a comunicacao em DDS?16. Para cada dificuldade encontrada, quais solucoes foram adotadas?17. Como sao realizadas as reunioes do projeto DDS?18. Quem participa das reunioes?19. No seu projeto e usada alguma ferramenta de apoio ao DDS?20. Voce utiliza alguma ferramenta especıfica para dar suporte a comunicacao para essesprojetos?21. Como e feita a escolha das ferramentas?22. Como e feita a gestao de conflitos entre equipes distribuıdas?

Parte IV - Experiencia em DDS

23. Tendo como base sua experiencia em desenvolvimento de software, como voce com-para o desenvolvimento tradicional ou centralizado com o DDS?24. Na sua opiniao, quais sao os principais fatores para obter sucesso em projetos DDS?25. Na sua opiniao, como podemos melhorar uma comunicacao em um projeto DDS?26. Voce teria algum comentario adicional sobre a sua experiencia em DDS?

REFERENCIAS BIBLIOGRAFICAS

[1] I. T. 15504. Iso spice - norma iso iec tr 15504.http://www.isospice.typepad.com/isospice pt tr15504/, 2005.

[2] F. E. AL. Miniaurelio Seculo XXI Escolar: O mini dicionario da lıngua portuguesa.2001.

[3] E. A. BECKER, C.A. Oportunidades de Melhoria Identificadas no MR MPS apartir do Mapeamento com o Modelo CMMI e as Normas ISO/IEC 12207 e ISO/IEC15504, no contexto do Projeto Cooperativa MPS. BR no RS. ProQualiti–Qualidadena Producao de Software.

[4] E. A. BISCARO, A.L.P. Busca da qualidade na producao tecnologica: um relatoempırico da implatacao do cmmi. XXV Encontro Nacional de Eng. de Prod. - PortoAlegre, RS, Brasil, 29 outubro a 01 de novembro de 2005.

[5] M. R. CANTOR. Object-Oriented Project Management with UML. New York: WileyComputer Publishing, 1998.

[6] E. CARMEL. Global software teams: collaborating across borders and time zones.Prentice Hall PTR Upper Saddle River, NJ, USA, 1999.

[7] E. CARMEL and R. AGARWAL. Tactical approaches for alleviating distance inglobal softwaredevelopment. Software, IEEE, 18(2):22–29, 2001.

[8] E. Carmel and P. Tjia. Offshoring Information Technology: Sourcing and Outsour-cing to a Global Workforce. , 2005.

[9] E. A. CHAVES, L. Gerenciamento de Comunicacao em Projetos. 2006.

[10] M. CHRISSIS, M. KONRAD, and S. SHRUM. CMMI: Guidelines for Process Inte-gration and Product Improvement. Addison-Wesley Professional, 2003.

[11] CMMI. Sei 2006. http://www.sei.cmu.edu/cmmi, 2006.

[12] A. COUTO. CMMI - Integracao dos modelos de capacitacao e Maturidade de sis-tema. 2007.

[13] M. CORTES. Modelos de Qualidade de Software. Sao Paulo: Editora da Unicamp,Instituto de Computacao, 2001.

87

88 REFERENCIAS BIBLIOGRAFICAS

[14] D. DAMIAN. The study of requirements engineering in global software development:as challenging as important. Proceedings of International Workshop on Global Soft-ware Development–ICSE 2002, 2002.

[15] D. DAMIAN and D. MOITRA. Guest Editors’ Introduction: Global Software De-velopment: How Far Have We Come? Software, IEEE, 23(5):17–19, 2006.

[16] D. DAMIAN and D. ZOWGHI. The impact of stakeholders’ geographical distributionon managing requirements in a multi-site organization. Requirements Engineering,2002. Proceedings. IEEE Joint International Conference on, pages 319–328, 2002.

[17] C. DIAS. Grupo focal: tecnica de coleta de dados em pesquisas qualitativas. 1999.

[18] J. EVARISTO and R. SCUDDER. Geographically distributed project teams: adimensional analysis. System Sciences, 2000. Proceedings of the 33rd Annual HawaiiInternational Conference on, page 11, 2000.

[19] R. EVARISTO. Projetos distribuıdos. Mundo PM, 2005.

[20] U. FLICK. An Introduction to Qualitative Research. 2004.

[21] R. FREEMAN. Strategic Management: A Stakeholder Approach. Boston:Pitman.,1984.

[22] A. GIL. Metodos e Tecnicas de pesquisa social. 1995.

[23] A. S. GODOY. Introducao a pesquisa qualitativa e suas possibilidades. 1995.

[24] P. Guide. A Guide to the Project Management Body of Knowledge. 2004.

[25] J. HERBSLEB and D. MOITRA. Global software development. Software, IEEE,18(2):16–20, 2001.

[26] IDC. Idc-international data group. http://www.idc.com/, 2006.

[27] JACOBSON. Practices. http://www.ivarjacobson.com/products/essup/essup-practices/team-essentials.cfm, 2008.

[28] D. W. KAROLAK. Global. IEEE Computer Society.

[29] H. KERZNER. Gestao de Projetos. As melhores Praticas. 2. ed. Traducao: LeneBelcon Ribeiro. Porto Alegre: Bocckman, 2006.

[30] O. P. F. A. LAYZELL, PAUL; BRERENTON. Supporting Collaboration in Distribu-ted Software Engineering Teams. In: Asia-Pacific Software Engineering Conference(APSEC’00), 2000, Sinpore. Proceedings IEEE Computer Society, 2000.

[31] L. LOPES. Um Modelo de Processo de Engenharia de Requisitos para Ambientes deDesenvolvimento Distribuıdo de Software. Dissertacao de Mestrado, Facin - PPGCC,PUCRS, Porto Alegre, 2004.

REFERENCIAS BIBLIOGRAFICAS 89

[32] M. MARQUARDT and L. HORVATH. Global Teams: how top multinationals spanboundaries and cultures with high-speed . Davies-Black Publishing, 2001.

[33] M. MAYER. The Virtual Edge: Embracing Thecnology For Distributed Project TeamSucess. Pennsylvania : PMI - Project Management institute Head, 1998.

[34] M. MEDEIROS. Proposta de Processo de Requisitos para Equipes de Desenvol-vimento Distribuıdas Visando Melhorar a Documentacao e Validacao com Uso dePrototipos. Dissertacao de Mestrado, CIN - UFPE, Pernambuco, 2007.

[35] R. MENDES. Modelagem e Avaliacao do CMMI no SPEM para Definicao de umMeta-Processo de Software. Trabalho de Conclusao de Curso - TCC, CIN, UFPE,Recife - PE, 2005.

[36] C. E. A. MOREIRA. Gerencia de Comunicacao e o CMMI. 2008.

[37] NVIVO. Nvivo 2.0. http://www.qsrinternational.com/, 2006.

[38] S. PEREIRA. Um estudo empırico sobre engenharia de requisitos em empresas deprodutos de software. 2007.

[39] D. PERRY, N. STAUDENMAYER, and L. VOTTA. People, organizations, andprocess improvement. Software, IEEE, 11(4):36–45, 1994.

[40] J. L. N. PRIKLADINICKI, R.; AUDY. Desenvolvimento Distribuıdo de Software.2007.

[41] J. L. N. PRIKLADNICKI, R.; AUDY. Um Modelo de Referencia para Desenvolvi-mento Distribuıdo de Software. In: WORKSHOP DE TESTES EM ENGENHARIADE SOFTWARE (WTES 2003), 8., 2003, Manaus. Anais. Manaus: EDUA - Edi-tora da Universidade Federal do Amazonas, 2003. v.1. p.89-94, 2003.

[42] R. PRIKLADNICKI and J. AUDY. MuNDDoS-Um Modelo de Referencia paraDesenvolvimento Distribuıdo de Software. XVIII Simposio Brasileiro de Engenhariade Software-2004-Brasılia, DF, Brasil. Anais, pages 289–304.

[43] M. H. RENEKER. A qualitative study of information seeking among members of naacademic community: methodological issues and problems. Library Quarterly, v. 63,n. 4, p. 487-507, Oct, 1993.

[44] R. J. RICHARDSON. Pesquisa Social: Metodos e Tecnicas. Sao Paulo: Atlas. ISBN85-224-2111-0., 1999.

[45] SOFTEX. Mps.br 2007. http://www.softex.br, 2007.

[46] I. SOMMERVILLE. Engenharia de Software. Traducao Maurıcio de Andrade. SaoPaulo: Addison-Wesley, 2003.

[47] P. SOMMERVILLE, I. SAWYER. A Good Practice Guide. 1997.

90 REFERENCIAS BIBLIOGRAFICAS

[48] E. A. WEBBER, K. C. Uma estrategia para melhoria de processos de software nasempresas brasileiras. Quatic’ 2004, 2004.

[49] B. M. WILDEMUTH. Post-positivist research: two examples of methodological plu-ralism. Library Quarterly, Library Quarterly, v. 63, n. 4, Oct, 1993.

[50] J. L. N. ZANONI, R.; AUDY. Project Management Model for a Physically Distribu-ted Software Development Environment. In: HAWAII INTERNATIONAL CONFE-RENCE ON SYSTEM SCIENCES, 36., Hawaii, 2003. Proceedings. IEEE ComputerSociety Press, 2003.

[51] D. ZOWGHI. Does Global Software Development Need a Different RequirementsEngineering Process? In: International Workshop on Global Software Developmentat ICSE, 2002, Florida. Proceedings - EUA, 2002.

Este volume foi tipografado em LATEX na classe UFPEThesis (www.cin.ufpe.br/∼paguso/ufpethesis).

Uma Proposta de Boas Práticas do Processo de Comunicação … · 2015-09-29 · Dentre os...

Documents

Transcript of Uma Proposta de Boas Práticas do Processo de Comunicação … · 2015-09-29 · Dentre os...