Processos para Desenvolvimento
Distribuído de Software
Alex Nery Borges Júnior
[email protected]
1
Centro de Informática – CIn/UFPE
Setembro / 2010
Estrutura da Apresentação
• Introdução;
• Conceitos de DDS;
• Motivações para o DDS;
• Níveis de Dispersão;
• Modelos de Negócios;
• Desafios do DDS;
• Processos para o DDS;
• Oportunidades de Pesquisas;
2
• Considerações Finais;
Introdução
3
DDS - Introdução
• Globalização de negócios;
• Avanços das tecnologias de informação e comunicação;
• Aumento da importância dos softwares para as empresas;
• Processos de terceirização de serviços;
• Distribuição dos processos de software e surgimento do DDS;
4
Conceitos
5
DDS - Conceitos
6

Desenvolvimento Distribuído de Software: “é um modelo de
desenvolvimento de software onde os envolvidos em um
determinado projeto estão dispersos” (Carmel, 1999).

Características:
– Distância Física;
– Diferença de fuso-horário;
– Diferenças culturais;
DDS - Conceitos
7

Equipe global: é um conjunto de desenvolvedores localizados
em cidades ou países diferentes que trabalham em conjunto
em um projeto comum.

Organizações virtuais: são empresas caracterizadas por
realizar partes de um projeto em departamentos localizados em
cidades ou países diferentes, comportando-se como se
estivesse em um mesmo local.

Desenvolvimento Global de Software (GSD): é uma forma
de desenvolvimento distribuído de software que ocorre quando
a distância física entre os envolvidos no projeto envolve mais
de uma país (Karolak, 1998).
DDS - Terminologias
8

GSD – Global Software Development

DSD – Distributed Software Development

GDD – Geographically Distributed Development

DDS – Desenvolvimento Distribuído de Software
Motivações
9
DDS - Motivações
10

Disponibilidade de recursos globais equivalentes com custo
mais baixo e a qualquer hora;

Possibilidade de rápida formação de equipes virtuais para
explorar as oportunidades de mercado;

Disponibilidade de recursos especializados em determinadas
áreas;
DDS - Motivações
11

Possibilidade de desenvolvimento follow-the-sun (24 horas
contínuas de trabalho), que permite o aumento de produtividade
e a redução dos prazos de entrega dos produtos;

Escalabilidade, que permite o crescimento de empresas para
outras regiões;

Vantagem de presença no mercado local, que permite o
conhecimento dos clientes, das condições locais e o
desenvolvimento do produto perto do cliente;
Níveis de Dispersão
12
DDS - Níveis de Dispersão

13
Distância Física Inter-Atores;
DDS - Níveis de Dispersão

Mesma localização física: todos os atores estão em um mesmo lugar.
Não existem dificuldades de reuniões e há comunicação constantes entre
os membros.
Distância Nacional: as equipes distribuídas estão localizadas em um
mesmo país. As reuniões acontecem com menos freqüência.

Distância Continental: as equipes distribuídas estão localizadas em
países diferentes, mas nomes continente. As reuniões face a face ficam
mais difíceis de acontecer e o fuso-horário pode dificultar a interação entre
as equipes.

Distância Global: as equipes estão em países e continentes diferentes.
As reuniões face a face geralmente acontecem no início do projeto e as
dificuldades de comunicação e diferenças culturais podem ser barreiras
para o projeto.

14
Modelos de Negócio
15
DDS – Modelos de Negócio (Prikladiniki)
16

Onshore Insourcing: departamento dentro da empresa ou uma
subsidiária da empresa no mesmo país.

Offshore Insourcing: subsidiária da empresa para prover serviços
de desenvolvimento de software em um país diferente da empresa
contratante.

Onshore Outsourcing: contratação de um empresa terceirizada
localizada no mesmo país da empresa contratante.

Offshore Outsourcing: contratação de uma empresa terceirizada
localizada em um país diferente da contratante
Desafios
17
DDS - Desafios
18

O DDS envolve fatores como a distância física, diferenças de
fuso-horário e diferenças culturais;

Antigos desafios são agravados e novos desafios são
acrescentados na área de desenvolvimento de software;
DDS - Desafios
CATEGORIAS
Pessoas
Tecnologia
DESAFIOS
Confiança; Conflitos; Diferenças Culturais
Arquitetura do software;Engenharia de
Requisitos; Gerencia de Configuração;
Processo de Desenvolvimento
Tecnologias de
Colaboração;Telecomunicações
Gestão
Coordenação e Controle; Gerenciamento
de Projetos; Gerenciamento de Risco
Comunicação
Estilo de Comunicação; Formas de
Comunicação
Processos
19
DDS - Desafios

Arquitetura do Software:
–
–
20
A definição de uma arquitetura apropriada reduz a
complexidade do projeto;
A arquitetura apropriada para um projeto com equipes
distribuídas deve se basear no princípio da modularidade
(Karolak, 1998);
 Reduz a complexidade;
 Permite alocar tarefas de forma distribuída;
 Permite um desenvolvimento em paralelo simplificado;
DDS - Desafios

Engenharia de Requisitos:
–
–
–
21
A Engenharia de Requisitos contém diversas tarefas que
necessitam de boa comunicação e coordenação;
Com isso, essas tarefas se tornam mais complexas em um
ambiente de DDS;
É importante uma boa infra-estrutura de comunicação para
as equipes;
DDS - Desafios

Gerência de Configurações:
–
–
–
22
O controle de modificações simultâneas nos artefatos a
partir de locais diferentes pode ser uma tarefa bastante
complexa e gerar riscos para o projeto;
O gerenciamento de configuração é uma atividade
fundamental para controlar as varias partes desenvolvidas
em um projeto distribuído;
É importante utilizar ferramentas de gerência de
configuração no controle da documentação e do software;
DDS - Desafios

Processo de Desenvolvimento:
–
–
23
O uso de metodologias de desenvolvimento para auxiliar o
processo de desenvolvimento distribuído é importante, pois
permite o alinhamento e a padronização das atividades
realizadas pelas equipes distribuídas;
O processo de desenvolvimento deve padrão em um
ambiente distribuído;
Processos
24
DDS - Processos

O DDS causa impacto não só no mercado em si, mas também
nas etapas do processo de desenvolvimento de software;

É necessário a utilização de processos de desenvolvimento
específicos para o ambiente distribuído;

A seguir serão apresentados 2 processos específicos para o
DDS, criados a partir da adaptação de processos voltados para
o desenvolvimento co-localizado:
–
–
25
Modelo de Karolak;
DXP (Distributed Extreme Programming);
DDS - Processos (Modelo de Karolak)
26

Modelo de Karolak

O autor aborda o DDS seguindo o ciclo de vida tradicional de
um projeto de desenvolvimento de software (visão e escopo,
requisitos, modelagem, implementação, teste, entrega e
manutenção);

Modelo para desenvolver projetos de DDS que define um
conjunto de atividades que devem ocorrer ao longo do ciclo de
vida do projeto e as características de cada atividade;
DDS - Processos (Modelo de Karolak)

27
Modelo de Karolak
DDS - Processos (DXP)


O DXP é um processo para o DDS que aplica
princípios do XP em equipes distribuídas;
O DXP aborda:
–
–
–
–
–
28
Conectividade entre os membros (uso da internet);
Uso de ferramentas de gerenciamento de configuração;
Compartilhamento de aplicação;
Uso de videoconferência;
Familiaridade entre os membros;
DDS - Processos (DXP)
A tabela abaixo mostra alguns aspectos de XP que são relevantes
para o DXP e se esses aspectos são ou não impactados devido a
distribuição das equipes:
Práticas do XP
29
É necessário a equipe ser colocalizada?
Jogo do Planejamento
Programação em Par
Integração Contínua
Cliente local
Sim. Estes fatores dependem de uma
aproximação entre o negócio, cliente e
pessoal técnico.
Releases Pequenos
Metáforas
Design Simples
Testes
Refatoramento
Propriedade Coletiva
40 horas semanais
Padrão de codificação
Não. Independem de a equipe ser colocalizada ou não.
DDS - Processos (DXP)

Desafios e Práticas:
–
–
–
–
–
30
Comunicação: em algumas situações deve ser analisada
qual forma de comunicação deve ser adotada;
Coordenação: é necessário planejamento das atividades e
uma comunicação eficaz;
Infra-estrutura: é importante a escolha correta do Hardware
e Software;
Disponibilidade: deve ser divulgado um calendário diário ou
semanal com a disponibilidade de cada membro da equipe;
Gestão: relatórios diários ou semanais com o andamento
das atividades;
Oportunidades de Pesquisa
31
DDS - Oportunidades de Pesquisa
32

Ferramentas de Colaboração e Suporte ao desenvolvimento
– Escassez de ferramentas de Awareness de atividades (quem
está fazendo o que);
– Escassez de ferramentas de disponibilidade (quem está
disponível quando);
– Escassez de ferramentas de Processo (quem deve fazer o
que).

Processo de Desenvolvimento em um Ambiente Distribuído
– Análise e definição de quais práticas são efetivas em quais
circunstâncias /cenários;
DDS - Oportunidades de Pesquisa
33

Testes de Software em Ambientes Distribuídos
– Criação de Técnicas para lidar com a privacidade dos dados;
– Processos específicos para minimizar a falta de precisão dos
documentos de testes que são trocados entre Equipes
Distribuídas.

Arquitetura de Software
– Como projetar a arquitetura do software de forma a minimizar
problemas de coordenação entre as equipes.
DDS - Oportunidades de Pesquisa
34

Especificação e Gerência de Requisitos
– Prever de forma proativa e através de métodos específicos,
quais requisitos, em um determinado cenário distribuído
pode riam ser considerado instáveis.

Desenvolvimento de Modelos de Maturidade para Ambientes
Distribuídos
– Modelos de qualidade de software (CMMI, ISO 9001, MR
MPS) não suportam DDS;
– Necessidade de abordagens de maturidade e capacidade.
Considerações Finais
35
DDS - Considerações finais
36

No contexto da globalização, a distribuição dos processos de
desenvolvimento de software em locais estrategicamente
distribuídos tem se tornado uma prática cada vez mais comum;

Com o desenvolvimento distribuído de software, os problemas
tradicionais da ES aumentaram e foram gerados novos desafios
para a área;

A existência de um processo de desenvolvimento de software
único e bem definido responde por grande parte dos resultados
obtidos em um projeto de desenvolvimento distribuído;
DDS - Considerações finais
37

Os requisitos são vistos como um grande desafio, envolvendo
atividades desde a realização de reuniões até a formalização
(documentação) dos requisitos definidos, a rastreabilidade e
controle dos mesmos;

Um processo único e bem definido de acordo com o ambiente
em que o projeto está sendo desenvolvido pode ser a solução
para muitas dificuldades do desenvolvimento distribuído;

Ferramentas de apoio atuam como facilitador na interação
distribuída;
Referências
38

Herbsleb, J. D., Moitra, D. “Global Software Development”, IEEE
Software, March/April, EUA, 2001, p. 16-20.

Karolak, D. W. “Global Software Development – Managing Virtual
Teams and Environments”. Los Alamitos, IEEE Computer Society,
EUA, 1998, 159p.

Global Software Development at ICSE, Oregon, EUA, 2003, 4p.

Herbsleb, J.D., Mockus, A., Finholt, T.A. e Grinter, R. E. “An empirical
study of global software development: distance and speed”, In: ICSE
2001, Toronto, Canada.

Carmel, E. “Global Software Teams – Collaborating Across Borders
and Time-Zones” Prentice Hall, EUA, 1999, 269p.
Referências
39

Marquardt, M. J., Horvath, L. “Global Teams: how top multinationals
span boundariesand cultures with high-speed teamwork”. DaviesBlack. Palo Alto, EUA, 2001.

Prikladnicki, R., Audy, J. L. N., Evaristo, R. “Global Software
Development in Practice: Lessons Learned”, Journal of Software
Process: Practice and Improvement – Special Issue on Global
Software Development, 2004.

Prikladnicki, R. “MuNDDoS: Um Modelo de Referência para
Desenvolvimento Distribuído de Software”. Dissertação de Mestrado,
PPGCC – PUCRS, Brasil, 2003.

SOMMERVILLE, Ian. Software Enginnering. 8.ed. [S.l] ADDISON
WESLEY, 2007.

J. L. N. PRIKLADINICKI, R.; AUDY. Desenvolvimento Distribuído de
Software. 2007.
Referências
40

[KRUCHTEN, 2001] KRUCHTEN, Philippe. What Is the Rational Unified
Process?.
Rational
Software.
Disponível
em:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan01
/WhatIstheRationalUnifiedProcessJan01.pdf. Acessado em: 20 Maio 2009.

[PERRELLI, 2009] Perrelli, Hermano. Visão Geral do RUP. Centro de
Informática, Universidade Federal de Pernambuco. Disponível em:
http://www.cin.ufpe.br/~if717/slides/3-visao-geral-do-rup.pdf. Acessado em 20
Maio 2009.

[TELES, 2004] TELES, Vinícius Manhães. Extreme Programming: Aprenda
como encantar seus usuários desenvolvendo software com agilidade e alta
qualidade. 1. ed. São paulo: Novatec, 2004. 320 p.
Dúvidas ??
41