PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Curso de Mestrado Desenvolvimento Distribuído de Software e Processos de Desenvolvimento de Software Trabalho Individual II Rafael Prikladnicki Orientador Prof. Dr. Jorge Luis Nicolas Audy Porto Alegre, 30 de agosto de 2002.
O que é o desenvolvimento de software? Uma arte, ciência, engenharia ou algo mais como um todo? Será que isto importa? Sim, isto importa, e importa para todos nós. Nossas ações e os resultados que são gerados podem ser diferentes, de acordo com a definição que for mais correta. Então, a idéia principal é: Todos nós precisamos que o nosso software seja desenvolvido da forma mais rápida possível e sem erros. Mas muito mais do que isso, nós precisamos sempre saber como a nossa equipe está desenvolvendo ao longo deste caminho. Alistair Cockburn ii
SUMÁRIO LISTA DE FIGURAS... v LISTA DE TABELAS... vi LISTA DE ABREVIATURAS E SIGLAS...vii INTRODUÇÃO... 8 1 Desenvolvimento Distribuído de Software (DDS)... 10 1.1 Critérios que caracterizam o nível de DDS... 13 1.1.1 Distância física dos atores... 15 1.1.2 Distribuição da Equipe de Desenvolvimento... 17 1.2 Alguns Cenários de Desenvolvimento Distribuído de Software (DDS)... 18 1.2.1 Cenário 1: Centro de Pesquisa em E-Business DELL/PUCRS... 19 1.2.2 Cenário 2: Centro de Desenvolvimento da Oikodomo Brasil... 20 1.3 Fatores de Sucesso de Desenvolvimento Distribuído de Software (DDS)... 21 1.4 Sintetizando a Pesquisa sobre DDS... 22 2 Os Principais Processos de Desenvolvimento de Software... 26 2.1 A ISO e a IEC... 26 2.2 Norma ISO/IEC 12.207 (NBR ISO/IEC 12207)... 27 2.2.1 Os Processos Fundamentais... 28 2.2.2 Processos de Apoio... 28 2.2.3 Processos Organizacionais... 29 2.2.4 Limitações da NBR ISO/IEC 12207... 30 2.3 Rational Unified Process RUP... 31 2.3.1 Análise Crítica... 35 2.4 Microsoft Solutions Framework MSF... 37 2.4.1 Modelo de Gerência de Risco do MSF... 37 2.4.2 Modelo de Equipe do MSF... 38 2.4.3 Modelo de Processo do MSF... 39 2.4.4 Análise Crítica... 40 iii
2.5 Agile Software Development - ASD... 42 2.5.1 Análise Crítica... 47 2.6 Extreme Programming XP... 48 2.6.1 Análise Crítica... 54 3 Análise Comparativa entre os Processos de Desenvolvimento... 56 3.1.1 Definição dos Critérios de Análise... 56 3.1.2 Análise Comparativa... 58 CONCLUSÕES... 62 REFERÊNCIAS BIBLIOGRÁFICAS... 64 iv
LISTA DE FIGURAS Figura 1 Mesma localização Física.... 15 Figura 2 Distância Municipal.... 15 Figura 3 Distância Regional.... 16 Figura 4 Distância Continental.... 16 Figura 5 Distância Global.... 17 Figura 6 Distribuição em sub-equipes.... 17 Figura 7 Distribuição individual.... 17 Figura 8 Equipe de Desenvolvimento Centralizada.... 18 Figura 9 Ilustração do Cenário 1.... 20 Figura 10 - Ilustração do Cenário 2.... 21 Figura 11 Fatores de Sucesso do DDS... 21 Figura 12 Os três atores envolvidos... 24 Figura 13 Critérios de definição do nível de distribuição do DDS.... 24 Figura 14 Relação da distância com os processos de desenvolvimento.... 24 Figura 15 Estrutura da NBR ISO/IEC 12207.... 27 Figura 16 o Rational Unified Process - Fonte: [PRI 02a]... 32 Figura 17 Gerência de Risco no MSF.... 38 Figura 18 Os papéis definidos no MSF.... 38 Figura 19 O modelo de processo do MSF.... 40 Figura 20 Os elementos de um... 46 Figura 21 As três dimensões do escopo de um processo - Fonte: [COC 02]... 46 Figura 22 A instância de um escopo... 47 Figura 23 As quatro dimensões do XP.... 49 Figura 24 O XP é visto como um conjunto de peças.... 50 v
LISTA DE TABELAS Tabela 1 Os critérios definidos para a análise comparativa.... 58 Tabela 2 Análise comparativa.... 61 vi
LISTA DE ABREVIATURAS E SIGLAS ACM - Association for Computing Machinery ASD Agile Software Development DDS Desenvolvimento Distribuído de Software IEC International Electrotechnical Commission ISO International Organization for Standardization MCS Microsoft Consulting Services MSF - Microsoft Solutions Framework NBR Normas Brasileiras OOPSLA - Object Oriented Programming, Systems, Languages and Applications PDTSD - Process Support Distributed Team-Based Software Development RUP Rational Unified Process TI Tecnologia da Informação XP Extreme Programming vii
INTRODUÇÃO Hoje em dia, ao mesmo tempo em que a área da engenharia de software se desenvolve de uma forma cada vez mais rápida, é necessário desenvolver software de altíssima qualidade. Com o passar dos anos e durante a evolução desta área, é interessante observar como alguns dos princípios fundamentais desse desenvolvimento permanecem os mesmos de 30 anos atrás e como os desafios que os engenheiros de software encontram hoje são semelhantes aos existentes quando a engenharia de software ainda engatinhava. Após 30 anos, ainda temos que nos esforçar para desenvolver softwares confiáveis [PET 01]. Neste contexto, percebe-se cada vez mais a necessidade das organizações desenvolverem software tendo por base um processo bem definido. De acordo com o que foi escrito em [PRI 02b], um processo de software é representado por um modelo. Existem diversos modelos na área de desenvolvimento de software. Sendo assim, as empresas adotam um determinado modelo como referência, customizando-o e adequando este modelo de acordo com a sua realidade. Este modelo deve ser operacionalizado por meio de uma metodologia, estabelecendo basicamente a seqüência de atividades existentes e a relação entre elas, incluindo neste contexto os métodos e as ferramentas que dão suporte ao modelo, procurando sempre a qualidade total, tanto do processo como do produto final gerado seguindo-se o processo. Também se verificou em [PRI 02b] que existem diversos problemas e desafios ainda presentes no processo de desenvolvimento de software. Um dos problemas mais significativos é o planejamento, pois ele é o ponto de partida de qualquer atividade relacionada ao desenvolvimento de software. Considerando os desafios apresentados, um dos mais significativos envolve o processo de desenvolvimento de software 8
baseado em equipes e ambientes fisicamente distribuídos, ou seja, o Desenvolvimento Distribuído do Software (DDS). Hoje em dia as grandes organizações estão cada vez mais distribuindo seus processos de desenvolvimento de software ao redor do mundo, visando ganhos de produtividade, redução de custos, diluição de riscos e melhorias na qualidade. Ou seja, o software está ficando cada vez mais sofisticado, o processo de desenvolvimento de software está evoluindo de uma forma muito rápida e, além disso, se vê a necessidade de distribuir o desenvolvimento, trazendo muitos benefícios para as organizações. Por este motivo, o Trabalho Individual II tem como objetivo realizar um estudo aprofundado sobre o estado da arte do Desenvolvimento Distribuído de Software (DDS), suas características e definições, e dos principais modelos de processo de desenvolvimento de software existentes. Pretende-se analisar os diferentes cenários do DDS e descrever e analisar os seguintes modelos de processo: - o Rational Unified Process (RUP); - o Microsoft Solutions Framework (MSF); - o Agile Software Development (ASD); - o Extreme Programming (XP). Juntamente com a análise comparativa, pretende-se verificar que tipo de suporte cada um destes modelos de processo possui para um desenvolvimento distribuído de software. O capítulo 1 irá abordar a questão do desenvolvimento distribuído de software, analisando os diferentes cenários existentes. O capítulo 2 pretende descrever e analisar os principais modelos de processo de desenvolvimento software, identificando o estado da arte destes modelos. Por último, o capítulo 3 faz uma análise comparativa entre os processos analisados no capítulo 2, procurando sistematizar esta análise através de um critério de comparação previamente definido, e explicado no próprio capítulo. 9
1 Desenvolvimento Distribuído de Software (DDS) Ao longo dos anos, cada vez mais se percebe que o desenvolvimento de software nunca foi uma tarefa simples. Conforme foi abordado em [PRI 02b], viu-se que existe uma série de problemas e desafios inerentes ao processo de desenvolvimento de software. Entre os problemas encontrados, os projetos de software freqüentemente apresentam cronogramas atrasados, execução orçamentária abaixo do previsto e produtos defeituosos. Uma das razões para estas situações, especialmente para projetos grandes, está na coordenação das atividades da equipe de projeto e na manutenção do controle do projeto. Hoje em dia, gerenciar grandes projetos de desenvolvimento de software tem se tornado uma tarefa cada vez mais complexa. Não apenas por causa do crescimento dos projetos, mas também por que as equipes de projeto vêm se distribuindo no tempo e no espaço, inserido no conceito de globalização que a sociedade têm vivenciado nos últimos anos. Isto configura então o Desenvolvimento Distribuído de Software (DDS), onde algumas pessoas envolvidas no processo de desenvolvimento estão fisicamente distantes. Várias ferramentas e ambientes têm sido desenvolvidos ao longo dos últimos quatro anos para ajudar no controle e coordenação das equipes de desenvolvimento que estão inseridas neste tipo de ambiente. Muitas destas ferramentas estão focadas no suporte aos procedimentos de comunicação formal tais como elaboração de documentos, processos automatizados e outros canais de comunicação não interativos. Um estudo de caso feito por [KRA 95] concluiu que o desenvolvimento de software necessita de um suporte extensivo para a comunicação informal e interativa. Além disso, viu-se em [PRI 02b] que trabalhar com DDS talvez seja um dos maiores desafios que o atual ambiente de negócios apresenta do ponto de vista do 10
processo de desenvolvimento de software. Muitas empresas estão distribuindo seu processo de desenvolvimento de software em países como Índia e Brasil. Muitas vezes este processo se dá dentro de um mesmo país, em regiões com incentivos fiscais ou de concentração de massa crítica em determinadas áreas. As empresas buscam vantagens competitivas em termos de custos, qualidade ou flexibilidade na área de desenvolvimento de sistemas [PRI 02], além de ganhos de produtividade e diluição de riscos [McC 96]. Neste caso, ao optar por instanciar um ambiente de desenvolvimento distante fisicamente da sua sede, uma organização começa a encarar diversos desafios de adaptação, diferenças culturais, planejamento do trabalho, treinamento da nova equipe, entre outros. Sendo assim, surgem os conceitos de outsourcing e offshore outsourcing, e todos os desafios existentes no DDS ganham proporções maiores. Outsourcing é a prática de contratar uma organização externa para desenvolver um sistema, ao invés de desenvolver na sua própria sede (in-house) [McC 96]. As organizações que utilizam outsourcing podem se especializar em uma determinada área, ter mais desenvolvedores para trabalhar em um determinado projeto e ter uma grande biblioteca de código reutilizável. A combinação destes fatores pode resultar numa significativa redução no tempo necessário para desenvolver um produto. Muitas vezes os custos de desenvolvimento também podem diminuir. Uma das opções do outsourcing que vem se tornando bastante popular ao longo dos últimos anos é o offshore outsourcing. Organizações offshore são empresas que estão localizadas em algum outro país, e que oferecem custos mais baixos de desenvolvimento. Além disso, também oferecem uma qualidade que é, no mínimo, equivalente à qualidade das organizações localizadas no próprio país [McC 96]. O desenvolvimento de ambientes tecnológicos, modelos e ferramentas para atuar neste tipo de ambiente é um desafio cada vez mais importante, tanto para a teoria na área de engenharia de software como para as empresas que enfrentam as dificuldades criadas por este tipo de ambiente. E é por isto que nos últimos anos diversos estudos e eventos têm dado uma grande importância para este assunto. 11
Em 2001, em uma conferência anual em programação, sistemas, linguagens e aplicações orientados a objeto (OOPSLA 1 ), promovida pela ACM (Association for Computing Machinery), um painel com alguns dos principais pesquisadores da área de desenvolvimento de software que estavam participando da conferência apresentou a seguinte questão: Como é possível ter um desenvolvimento ágil se a equipe de desenvolvimento estiver fisicamente distribuída, cada um trabalhando na sua casa?. Todos os painelistas foram mais ou menos pela mesma resposta, dizendo "We wouldn't even try!, ou seja, Nós nunca tentamos! [DAD 02]. Além disso, neste mesmo painel foram citados alguns pontos relacionados com a questão apresentada e o cenário mundial de desenvolvimento de software naquele momento. O principal ponto discutido foi o de que diversas experiências envolvendo o desenvolvimento distribuído de software estavam sendo realizadas, mas nenhuma delas tratava de casos reais, incluindo as pressões de prazos, custo e escopo, tão comuns em projetos da área de software. Eram estudos basicamente acadêmicos, com o objetivo de aproximar os pesquisadores desta nova realidade, permitindo a ampliação de conhecimento nesta área. O que se sabia era que o DDS podia se transformar em um caminho real a ser seguido no futuro. Desde então, a comunidade científica está desenvolvendo estudos empíricos na área de DDS. Por este motivo, devido à multiplicidade de possibilidades existentes neste contexto de DDS, neste capítulo busca-se identificar os principais critérios que caracterizam um ambiente distribuído de desenvolvimento de software e seu nível de distribuição, além de identificar cenários que combinam alguns destes critérios e ilustram o DDS. Alguns destes critérios já existem, como resultado de trabalhos publicados em congressos internacionais, como o OOPSLA 01 ou ainda o workshop PDTSD 02 2. Outros critérios foram identificados através de um estudo aprofundado da 1 OOPSLA - http://oopsla.acm.org/, ACM - http://www.acm.org. 2 3o International Workshop on Process Support for Distributed Team-Based Software Development, no 6o World MultiConference on Systemics, Cybernetics and Informatics (SCI) - http://www.iiisci.org/sci2002. 12
realidade em que as empresas estão inseridas, considerando diversos cenários possíveis para o DDS. Estes critérios consideram a existência de três atores principais no processo, tendo papéis distintos uns dos outros, cada um com a sua importância. Estes atores são: D C U Equipe de Desenvolvimento Cliente Usuário A equipe de desenvolvimento representa todas as pessoas envolvidas no desenvolvimento de um determinado projeto, podendo também ser formada por um conjunto de sub-equipes. Esta equipe pode envolver pessoas responsáveis pela área de negócios, gerência de projetos, desenvolvimento, testes, controle de qualidade, responsáveis pelo suporte de ferramentas dentro do projeto, entre outros. O cliente é a pessoa física ou jurídica que solicitou e contratou o desenvolvimento de um determinado projeto. O usuário representa as pessoas responsáveis por fornecer todas as informações necessárias (requisitos) para o correto desenvolvimento do projeto e são responsáveis por utilizar o produto gerado. Às vezes, clientes e usuários podem ser as mesmas pessoas, representando os dois papéis simultaneamente. 1.1 Critérios que caracterizam o nível de DDS Ao longo deste trabalho [ALT 98], [DAD 02], [EVA 00], [EVA 01], [BIU 02], [HAY 00] [McC 96] foram encontrados diversos critérios que, envolvendo os atores acima e combinados nas suas diversas possibilidades, podem caracterizar o nível de DDS. Os critérios encontrados são apresentados a seguir: - Distância física dos atores [DAD 02]; - Distribuição da equipe de desenvolvimento [DAD 02]; - Terceirização do desenvolvimento [McC 96]; - Diferenças culturais [DAD 02], [EVA 01]; 13
- Tamanho do projeto [DAD 02], [EVA 01]; Ao aprofundar-se a análise referente a estes critérios, concluiu-se que: - a terceirização (normalmente citada na literatura como outsourcing) não se caracteriza especificamente como um critério de DDS. Diversas empresas têm utilizado o conceito de outsourcing para representar uma estratégia de negócios onde uma unidade (subsidiária) da empresa localizada em outro país ou estado torna-se responsável pela atividade envolvendo o processo de desenvolvimento de software. Neste caso, o outsourcing não envolve uma terceirização no conceito tradicional, pois a unidade responsável pelo desenvolvimento é da própria empresa contratante. São inúmeros os exemplos de organizações que adotam esta estratégia na área de desenvolvimento de software (DELL Computers, Nestlê, HP, Bank of Boston, entre outras). Neste sentido, a questão da terceirização será abordada como uma característica das equipes participantes do processo de desenvolvimento e não como um critério de DDS. - cultura é, por definição, um fator multidimensional que pode afetar em diferentes maneiras a performance de projetos geograficamente distribuídos [EVA 01]. As diferenças culturais em um ambiente de DDS surgem das diferenças culturais entre os membros das equipes e entre os locais fisicamente distantes. Por isso, diferenças culturais são aspectos importantes para o DDS, pois diversos problemas podem ser causados por estas diferenças. Apesar de ser um critério importante, ele não se aplica para este estudo no sentido de ser um critério que caracterize a distribuição. As diferenças culturais são consideradas um fator crítico de sucesso no processo de DDS. - o tamanho de um projeto é um critério importante quando se opta pelo DDS, pois este critério pode indicar o tamanho da equipe, o volume de documentação existente e exigido, etc. Mas este critério também não se aplica para este estudo para efeito de caracterização do DDS e sim como uma dos fatores que podem levar uma empresa a optar por um desenvolvimento distribuído, assim como custo ou prazos. 14
Sendo assim, a seguir serão detalhados os critérios julgados convenientes para esta pesquisa, para efeito de caracterização de um ambiente de DDS. 1.1.1 Distância física dos atores A distância física dos atores participantes do processo é um critério utilizado para definir o quão distantes estão os três atores envolvidos e suas respectivas áreas de negócio. Para este critério foram definidas cinco situações que ajudam a verificar qual o tipo de distância física existente e suas características principais. As situações para a distância física dos atores estão definidas da seguinte maneira: - Mesma localização física: esta é a situação onde a empresa possui toda a sua equipe instalada em um mesmo local (sala, prédio, universidade), considerando todos os atores envolvidos. A figura 1 ilustra esta situação: D D C D D U Figura 1 Mesma localização Física. - Distância municipal: esta é uma situação onde a equipe está localizada dentro da mesma cidade, estando fisicamente distante no máximo em 50km. Neste cenário a equipe pode se reunir quase que diariamente. A figura 2 ilustra esta situação mostrando uma equipe localizada dentro da cidade de Porto Alegre. U C D Figura 2 Distância Municipal. 15
- Distância Regional: esta situação caracteriza-se por ter a equipe localizada dentro de um mesmo Estado ou de um mesmo País, estando distante entre três e seis horas de viagem de avião, em zonas de fuso horário igual ou vizinho. Nesta situação, a equipe pode se reunir em curtos intervalos de tempo. A figura 3 ilustra este cenário, mostrando uma equipe localizada dentro do estado do Rio Grande do Sul. C U D Figura 3 Distância Regional. - Distância Continental: esta situação caracteriza-se por ter a equipe separada dentro de um mesmo continente, onde cada integrante deve estar em uma zona de fuso horário de no máximo 4 horas de diferença do outro. Nesta situação já se torna inconveniente uma reunião com toda a equipe de forma freqüente, mas algumas viagens podem ocorrer. A figura 4 ilustra este cenário, mostrando uma equipe de desenvolvimento localizada dentro do continente Europeu. C D U Figura 4 Distância Continental. - Distância Global: esta situação caracteriza-se por ter a equipe separada, onde cada integrante está em algum lugar do mundo, de forma que o tempo de uma viagem para reunir toda a equipe em um lugar comum ultrapassa a duração de 24 horas. Nesta situação, normalmente os membros da equipe se reúnem por algumas 16
semanas no início de um projeto. A figura 5 ilustra este cenário, mostrando uma equipe distribuída em 3 continentes (América do Norte, América do Sul e Ásia). U C D Figura 5 Distância Global. 1.1.2 Distribuição da Equipe de Desenvolvimento Ter toda a equipe participante do processo de desenvolvimento de software (cliente, usuário e equipe de desenvolvimento) distante fisicamente de acordo com alguma das cinco situações previstas no item anterior não indica que a equipe de desenvolvimento esteja distribuída. Sendo assim, um ambiente de desenvolvimento distribuído de software pode ter a equipe de desenvolvimento estruturada em duas situações principais: - Equipe de desenvolvimento distribuída: esta situação indica que a equipe de desenvolvimento pode ser distribuída de forma a trabalhar distante fisicamente. Esta distribuição pode ter cada integrante da equipe distante fisicamente, ou podem existir subequipes de desenvolvimento que estão distribuídas. As figuras 6 e 7 a seguir ilustram estas possibilidades: D D D D D D D D Figura 6 Distribuição em sub-equipes. Figura 7 Distribuição individual. 17
- Equipe de desenvolvimento centralizada: esta situação indica que a equipe de desenvolvimento estará localizada no mesmo espaço físico, ou seja, trabalhará sempre fisicamente junta. A figura 8 ilustra a equipe de desenvolvimento localizada em um mesmo espaço físico. D D D D D D D D Figura 8 Equipe de Desenvolvimento Centralizada. Cabe salientar que a distribuição da equipe de desenvolvimento não leva em conta a localização dos outros atores, cliente e usuário. 1.2 Alguns Cenários de Desenvolvimento Distribuído de Software (DDS) Um ambiente para o desenvolvimento distribuído de software (DDS) tem diversas possibilidades de configuração. Conforme foi apresentado no item 1.1, dois critérios podem auxiliar na definição do nível de distribuição existente. Cada critério possui um conjunto de situações, e a combinação de uma determinada situação de cada critério indica como a empresa realiza o desenvolvimento de um projeto de software, considerando os atores envolvidos. Um ambiente DDS pode ser visto sob duas perspectivas principais: - Considerando apenas a equipe de desenvolvimento; - Considerando a equipe de desenvolvimento, clientes e usuários. O nível de DDS a ser utilizado no processo de desenvolvimento de software depende da organização e do projeto a ser desenvolvido. Este processo de DDS pode ser implementado internamente na própria empresa, onde cliente, usuário e equipe de desenvolvimento são da própria empresa, ou envolvendo outras empresas, onde os clientes e os usuários não pertencem à empresa que desenvolverá o projeto. Baseando-se nestas perspectivas e nos critérios anteriormente citados, a seguir serão 18
apresentados dois cenários diferentes, baseados em casos reais, que possuem um desenvolvimento distribuído de software. O primeiro cenário corresponde a uma empresa que possui os três atores (equipe de desenvolvimento, cliente e usuário) no seu quadro de funcionários, cada um na sua área de negócio. Já o segundo cenário corresponde a uma empresa que possui apenas uma equipe de desenvolvimento, sendo que clientes e usuários são atores externos, que contratam o serviço de desenvolvimento de software desta empresa. Para efeito deste estudo, foram considerados dois centros de desenvolvimento de software, pertencentes a duas empresas localizadas em Porto Alegre (Dell Computers e Oikodomo Brasil). Estes centros de desenvolvimento são cenários reais de desenvolvimento distribuído de software, cada um com suas características específicas. Portanto, foram analisados: - o Centro de Pesquisa em E-Business DELL/PUCRS; - o Centro de Desenvolvimento da Oikodomo no Brasil; 1.2.1 Cenário 1: Centro de Pesquisa em E-Business DELL/PUCRS Neste cenário, a empresa DELL Computers possui um centro de pesquisa e desenvolvimento de software voltado para e-business, sendo responsável, entre outras atividades, pelo desenvolvimento dos softwares de e-business corporativos da empresa, ou seja, sistemas que serão utilizados na própria empresa (sistemas para outros setores, automatização de determinadas atividades, entre outros). Sabendo-se dos dois critérios definidos no item 1.1, pode-se enquadrar este centro de pesquisa e desenvolvimento no seguinte cenário: Considerando que a empresa possui este centro em Porto Alegre e a sua sede está localizada nos Estados Unidos, os atores participantes do processo de desenvolvimento possuem uma distância continental, onde o cliente e/ou o usuário podem estar localizados nos Estados Unidos enquanto que a equipe de desenvolvimento está localizada em Porto Alegre. Além disso, existe uma possibilidade de distribuição da equipe de desenvolvimento, visto que o analista de negócios pode estar nos Estados Unidos, bem como a pessoa responsável 19
pela instalação do sistema, caso o sistema esteja sendo desenvolvido para ser utilizado em toda a empresa e sua instalação seja feita na sede, ou seja, nos Estados Unidos. Por último, alguns integrantes da equipe de desenvolvimento podem ser terceirizados, sendo contratados para um período específico de tempo, mas estes integrantes não estão distribuídos, estando fisicamente próximos de todo o resto da equipe. A figura 9 ilustra a configuração deste cenário de desenvolvimento. U C D D D Figura 9 Ilustração do Cenário 1. O que se percebe na figura 9 é que os atores estão fisicamente distribuídos, mas a equipe de desenvolvimento está localizada no mesmo espaço físico, tendo um integrante terceirizado. 1.2.2 Cenário 2: Centro de Desenvolvimento da Oikodomo Brasil Neste cenário, a empresa Oikodomo Global Technologies possui um centro de desenvolvimento de software no Brasil, localizado em Porto Alegre, sendo responsável por todo o desenvolvimento de software da empresa num âmbito mundial, podendo desenvolver para qualquer cliente, dentro ou fora da empresa. Sabendo-se dos dois critérios definidos no item 1.1, pode-se enquadrar este centro de desenvolvimento de software no seguinte cenário: Considerando que a empresa possui este centro de desenvolvimento em Porto Alegre e a sua sede está localizada nos Estados Unidos, os atores participantes do processo de desenvolvimento possuem uma distância continental, onde o cliente e o usuário estão localizados nos Estados Unidos enquanto que a equipe de desenvolvimento está localizada em Porto Alegre e também nos Estados Unidos, caracterizando assim a distribuição da equipe de desenvolvimento, visto que o analista de negócios está nos Estados Unidos, enquanto que os outros integrantes da equipe de desenvolvimento estão em Porto Alegre. Por último, alguns integrantes da 20
equipe de desenvolvimento podem ser terceirizados, sendo contratados para um período específico de tempo, mas estes integrantes não estão distribuídos, estando fisicamente próximos de todo o resto da equipe. A figura 10 ilustra como ocorre o desenvolvimento de um projeto de software dentro desta empresa, neste exemplo específico. U C D D D D Figura 10 - Ilustração do Cenário 2. O que se percebe na figura 10 é que, além de os atores estarem fisicamente distribuídos, existe a distribuição da equipe de desenvolvimento, onde existe um analista de negócios localizado nos Estados Unidos junto com clientes e usuários, e o restante da equipe de desenvolvimento está localizada em Porto Alegre, tendo esta equipe ainda um integrante terceirizado. 1.3 Fatores de Sucesso de Desenvolvimento Distribuído de Software (DDS) A pesquisa realizada com relação à identificação dos critérios de DDS [ALT 98], [DAD 02], [EVA 00], [EVA 01], [BIU 02], [HAY 00], mostrou a existência de uma série de fatores envolvidos no processo. Alguns destes fatores foram utilizados para caracterizar o DDS e seu nível de presença (distância física e distribuição da equipe de desenvolvimento). Outros fatores identificados podem ser considerados como fatores críticos de sucesso dos processos de DDS. Desta forma, para o sucesso de um projeto em um ambiente de DDS, identifica-se um conjunto de fatores (figura 11): DIFERENÇAS CULTURAIS COOPERAÇÃO DDS COMUNICAÇÃO CONFIANÇA COORDENAÇÃO Figura 11 Fatores de Sucesso do DDS 21
- Comunicação: a comunicação em um DDS é a chave para o bom andamento e execução de um projeto. Já a falta de comunicação faz com que as equipes fisicamente distantes não saibam de informações básicas sobre o projeto, sobre a equipe de projeto, entre outros. Por isso, deve existir um fluxo de informações ágil e eficaz entre os membros da equipe; - Confiança: confiança em um DDS é de vital importância para o bom fluxo de informações entre as equipes distribuídas. Ter confiança é ter segurança e firmeza no trabalho da equipe como um todo, independente de quem faça este trabalho. Por isso, torna-se essencial a procura de mecanismos que propiciem o estabelecimento de um clima de confiança nas relações e ações entre os atores envolvidos; - Cooperação: cooperação em um DDS significa colaboração da equipe para um objetivo comum, ou seja, ajudar e pensar como equipe. Por isso, é fundamental a cooperação entre as equipes fisicamente distantes, pois de nada adianta uma boa coordenação e uma ótima comunicação se não existir cooperação entre os membros das equipes; - Coordenação: a coordenação em um DDS é um fator que visa dispor as atividades de forma ordenada baseando-se em processos e regras previamente definidos. Por isso, deve existir um eficiente suporte para a coordenação das atividades de desenvolvimento; - Diferenças Culturais: quando se desenvolve software em um cenário onde exista o DDS, uma das primeiras atividades deve ser verificar qual o nível de diferenças culturais existentes entre as equipes fisicamente distantes, pois às vezes determinadas ações podem ser mal interpretadas pelo simples fato de ser parte da cultura de uma equipe e não da outra. Estas diferenças devem ser identificadas e acomodadas entre os participantes do processo. 1.4 Sintetizando a Pesquisa sobre DDS A partir da análise crítica do estudo realizado, buscou-se identificar os critérios a serem adotados na pesquisa com relação ao DDS visando o futuro do trabalho. Num 22