Aula de introdução aos conceitos de desenvolvimento distribuído de software

1. 1
Introdução a Projetos de
Desenvolvimento Distribuído de Software
Adailton Magalhães Lima
Universidade Federal do Pará
Campus Universitário de Castanhal
Curso Bacharelado em Sistemas de Informação

2. 2
Introdução

3. 3
 Na Engenharia de Software, vem se destacando o chamado
Desenvolvimento Distribuído de Software (DDS);
 DDS implica na dispersão do desenvolvimento de
componentes de software entre diversas localidades no
mundo; [Moitra 2001] [Ebert 2006]
A B
C
Distância entre países
Distância no mesmo país
Contexto

4. 4
 Relação Organizacional:
 In Sourcing;
 Outsourcing;
 Distância geográfica:
 Onshore;
 Offshore;
 Variantes:
 Outsourcing: Alliance,
Multi-Sourcing;
 In Sourcing: Join Venture;
Dissertação PPGCC - Adailton Lima
4
A B
C
Distância entre países
Distância no mesmo país
[Hyder 2006][Audy 2007]
Contexto
Diferentes Modelos Organizacionais

5. 5
Contexto
 Coordenação de Projetos:
 Distribuição
 dispersão física dos dados e as entidades
envolvidas no desenvolvimento de software [Ben-
Shaul 1994];
 relacionada com Sistemas Distribuídos [Coulouris
2005];
Dissertação PPGCC - Adailton Lima
5
Distribuído
Local

6. 6
Contexto
Dissertação PPGCC - Adailton Lima
6
[Rittgen 2007]
Negociação
Acordo
1
2
Cliente Fornecedor
Processo de Engenharia no Fornecedor3
4
Relatórios de Monitoração
Processo de Aquisição do MPS.BR

7. 7
Desenvolvimento Distribuído de Software
 Significa que o desenvolvimento de software
está distribuído em diversos sítios diferentes
localizados em cidades diferentes
 Porque é interessante?
 Pela dificuldade da coordenação das atividades;
 O caso SERPRO:
 Clientes em Brasília;
 Desenvolvimento em Belém;

8. 8
8
Desenvolvimento Global de Software
 Significa que o desenvolvimento de software está
distribuído em diversos sítios localizados em países
diferentes e até mesmo diferentes continentes.
 Exemplo
 Lucent tem desenvolvimento nos EUA, Alemanha, Inglaterra,
Índia e Brasil;
 IBM desenvolve nos EUA, Irlanda e Canadá, e testa na China;
 Motorola desenvolve nos EUA e testa no Brasil (Recife);
 Dell desenvolve software nos EUA e no Brasil (POA);
 Siemens desenvolve software na Alemanha, Brasil, EUA,
Polônia, e vários outros países;

9. 9
Níveis de Dispersão
 Distância Física Inter-Atores;

10. 10Projeto de Qualificação – Adailton M. Lima / PPGEE-UFPA
 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.
Níveis de Dispersão

11. 11
Contexto
Coordenação de projetos DDS
 Atividades:
 atualização ;
 divulgação da situação do projeto;
 São peças chave na manutenção do feedback
entre as equipes distribuídas;
[Sengupta 2006] [Ebert 2006]
Dissertação PPGCC - Adailton Lima
11

12. 12
12
Motivação
 Compra de empresas e união (“merge”) de empresas
para complementar produtos desenvolvidos por
companhias;
 Para a participação em determinados mercados, certas
leis requerem o desenvolvimento de certas operações
localmente;
 Partes da organização devem estar perto de onde o
mercado para elas existe;
 Competição por profissionais competentes;

13. 13
13
Motivação
 Organizações acreditam que a distribuição possa levar
a desenvolvimento de software em tempo integral
(“round-the-clock development ” ), o que levaria a
redução de custos;
 Quando alguém pára de desenvolver na Califórnia,
outra pessoa começa a desenvolver na Índia:
 Chamado de “siga o sol” (follow-the-sun);
 Em teoria diminui o tempo de desenvolvimento em 50%;

14. 14
14
Problemas
 Diferença em Fusos Horários
 Comunicação
 Informal
 Linguagem
 Coordenação
 Cultura
 Confiança
 Encontrar pessoas (experts)

15. 15
15
Efeitos da Distância
 Dificuldade na comunicação, através de email ou em
horários inadequados devido ao fuso horário;
 Perda da comunicação informal, que é essencial para a
coordenação do projeto;
 Dificuldade de saber quando contactar uma
determinada pessoa;
 Dificuldade de saber quem é responsável por um
determinado componente (quem projetou ou
implementou) para resolver um problema.

16. 16
16
Problemas de Cultura
 Culturas diferentes geralmente tem
comportamento diferente
 Alemães ligam para um desenvolvedor e dizem:
“Tem um problema no seu código”.
 Os ingleses esperam uma abordagem mais
“educada” onde uma pessoa sugere problemas no
código da outra;
 Diferenças no idioma e na forma de utilização
do idioma;
 Feriados e normas religiosas são diferentes;

17. 17
17
Problemas
 Em resumo
 Desenvolvimento de software distribuído é
mais lento que desenvolvimento quando
colocado (Herbsleb e colegas, 2000);
 Mas, é necessário!

18. 18
Riscos em projetos DDS
 O que é Risco?
 É a probabilidade de sofrer perdas diante dos
objetivos do projeto;[Pandian 2007]
 Riscos podem resultar em problemas de projeto tais
como estouro de custo e prazos; [Huey-Ming 2009]
 Avaliação de riscos deve prover apoio à
quantificação destes impactos em objetivos do
projeto; [Bohem 1991]

19. 19
Riscos em projetos DDS
 Projetos DDS intensificam os riscos envolvidos nos
projetos de desenvolvimento de software; [Aspray
2006]
 São criados novos riscos, que não são tratados
adequadamente em projetos DDS; [Hussey 2008]
 Continua um campo aberto para pesquisa a
identificação de quais práticas de gerenciamento
e processos se adequam melhor a projetos DDS;
[Ramasubbu 2007]

20. 20
Riscos em projetos DDS
 Segundo [Ebert 2008], dentre os principais riscos
envolvidos em projetos DDS podem-se destacar:
① Estouro de prazo;
② Estouro de custo;
③ Baixa qualidade dos produtos;
④ Problemas de coordenação causados pela distância
geográfica;
⑤ Conflitos causados pela distância cultural;
⑥ Alta rotatividade das equipes;
⑦ Expertise insuficiente;
⑧ Inflação de custos e salários;
⑨ Dependência de fornecedores;

21. 21
Riscos em projetos DDS
 Segundo [Ebert 2008], dentre os principais riscos
envolvidos em projetos DDS podem-se destacar:
① Estouro de prazo;
② Estouro de custo;
③ Baixa qualidade dos produtos;
④ Problemas de coordenação causados pela distância
geográfica;
⑤ Conflitos causados pela distância cultural;
⑥ Alta rotatividade das equipes;
⑦ Expertise insuficiente;
⑧ Inflação de custos e salários;
⑨ Dependência de fornecedores;
Críticos
em DDS

22. 22
Exemplo de Projeto DDS

23. 23
Observação na Siemens
• Caracterização do projeto e equipes:
• 11 Equipes trabalhando de maneira distribuída;
• 5 sites diferentes;
• Não iniciaram o projeto de maneira sincronizada;
• Contexto organizacional
• Projeto de desenvolvimento gerenciado em SCRUM;
• Integração de várias sub-empresas adquiridas pela
Siemens que possuíam tecnologias complementares,
mas em diferentes plataformas;
• O objetivo era integrar o conhecimento distribuído em
apenas uma plataforma e tecnologia, capaz de tornar a
empresa líder o setor.

24. 24Projeto de Qualificação – Adailton M. Lima / PPGEE-UFPA
Milão
Bangalore
Pune
Princeton
Chicago
1
2
3
3
2
Contexto - Sites Envolvidos
X Número de equipes no mesmo site

25. 25Projeto de Qualificação – Adailton M. Lima / PPGEE-UFPA
Milão
Bangalore
Pune
Princeton
Chicago
1
2
3
3
2
Contexto – Concentração dos testes de integração
Integração e Testes
X Número de equipes no mesmo site

26. 26
Descrição do contexto
 Em projeto de desenvolvimento de software, onde o
desenvolvimento de um sistema é distribuído entre diferentes
sites de acordo com expertise da equipe local.
 Cada equipe trabalha com ciclos iterativos, contendo medição
sobre:
 estimativas da capacidade de desenvolvimento da iteração;
 conjunto de requisitos pendentes das iterações anteriores (retrabalho);
 conjunto de requisitos desenvolvidos;
 conjunto de requisitos não finalizados;
 esforço estimado e real para cada tarefa;
 agrupamento de tarefas em:
 Garantia da Qualidade;
 Overhead;
 Problemas;
 Desenvolvimento de Funcionalidades;

27. 27
Riscos envolvidos em projetos DDS
 Estouro de prazo;
  Atual
 Estouro de custo;
  Adicionar custo médio ao tempo de trabalho das equipes
 Baixa qualidade dos produtos;
  Adicionar taxa de erros ao modelo (já incluída nas planilhas);
 Problemas de coordenação causados pela distância
geográfica;
  Medir impacto do delay em cada site e no projeto total do
atraso de comunicação;
 Dependência de fornecedores;
  Comparar resultados entre alocação a 1 site e outros sites
com menor ou expertise equivalente;
 Verificar o impacto das variaveis de netrada
Projeto de Qualificação – Adailton M. Lima / PPGEE-UFPA
[Ebert 2008]

28. 28
 Communication Workload alto [Hanakawa 2002]
 Utiliza informação de dependência entre tarefas e
produtos derivados destas;
Projeto de Qualificação – Adailton M. Lima / PPGEE-UFPA
Riscos envolvidos em projetos DDS

29. 29
Outros fatores a considerar em riscos
de projetos DDS
 Outros fatores a influenciar comunicação remota:
 Qualidade dos produtos;
 Nível de abertura de comunicação;
 Experiência passada com assunto ou funcionalidade;
 Considerar custos na avaliação de riscos;
 Novas heurísticas encontradas na literatura [Verner 2012]
 Definir pontos de sincronização das equipes;
 Minimizar número de sites distribuídos;
 Colocalização temporária de equipes em fases críticas;
 Resolver problemas imediatamente;
 Etc...

30. 30
Coleta de Dados
 Entrevistas com participantes do projeto;
 Planilhas gerenciais contendo:
 base de dados de gerência das atividades de 10
releases para 5 sites (12 equipes) distribuídos;
 Listagem de requisitos do sistema;
 Tácito: conversas informais com arquiteto de
software do projeto durante análise de dados;

31. 31
Entrevistas - Algumas afirmações
 Entre as equipes, as mais motivadas tinham que compensar a
produtividade das menos motivadas; [Gerente]
 Entre todas as equipes havia contexto similar de pressão, onde algumas
possuíam melhores recursos que outras; [Gerente]
 A equipe de integração era a única responsável por integrar e testar o
software; [Testador 1]
 A diferença de produtividade interna pode ser causada por: estimativas
super-otimistas e pela baixa qualidade dos produtos entregues para testes;
[Testador 1]
 O gerente não deixava tirar dúvidas diretamente com os desenvolvedores
do PCT1, pois achava que tomava tempo deles; [Testador 1]
 Produtos com baixa qualidade demandaram mais sessões de conversa
remota. Em muitos casos precisou de demonstrações pra entender as
funcionalidades; [Testador 2]
 Quando funcionalidades estavam quebradas tiveram dificuldades em
contatar as pessoas corretas pra tratar do problema; [Testador 2]
Comunicação
Produtividade
Centralização

32. 32
Relações lógicas do modelo
Para cada time de Desenvolvimento ou Integração e Testes
 Produtividade
 A produtividade real é impactada negativamente por outros fatores, tais como a necessidade de
comunicação com outras equipes e o overhead de outras atividades do processo;
 Comunicação
 Durante atividades de desenvolvimento, existem momentos em que é necessário se comunicar com
outros times para esclarecer dúvidas sobre a tarefa específica que se está atuando;
 Timezone
 Quanto maior a diferença de timezone com a outra equipe a qual faz-se uma requisição de informação,
maior a probabilidade da outra equipe não estar disponível online para responder as questões
solicitadas. Desta forma demora-se mais tempo para responder a uma requisição de comunicação;
 Expertise
 Quanto menor o expertise de um time na tarefa que lhe foi delegada, maior a probabilidade deste time
precisar realizar requisições a outras equipes mais experientes para sanar dúvidas;
 Overhead
 Existe o overhead de outras atividades durante o desenvolvimento de software, que podem ser
overheads locais ou inerentes ao DDS. Como exemplo de overhead local podem-se citar: reuniões locais
e tarefas para resolução de problemas de infraestrutura. Como exemplo de overhead inerente ao DDS
podem-se citar: viagens, reuniões com pessoas de outros sites e contato de suporte de outros times
remotos.

33. 33
Conclusões

34. 34
34
Soluções para DDS
 Tecnologias Colaborativas e Infra-Estrutura de
Tele-Comunicações;
 Dinâmicas de Grupo para Motivação de Times
(team building);
 Pessoas que viajam para outros sites com certa
frequência para servem como “ponte” para a
facilitar a colaboração entre os sites;
 Ajuda a estabelecer confiança entre os times;

35. 35
35
Soluções para DDS
 Lideranças;
 Arquitetura do Software e Alocação de Tarefas;
 Utilização de Metodologias de
Desenvolvimento de Software (Processo de
Software);

36. 36
36
Conclusões
 Desenvolvimento de software é uma atividade
colaborativa que requer ferramentas, abordagens, e
técnicas para seu sucesso;
 Como treinar estudantes e profissionais?
 Desenvolvimento de software é hoje uma tarefa
globalizada
 Problemas difíceis, mas as soluções estão sendo
encontradas;
 Excelente Oportunidade de Negócios!

37. 37
37
Conclusões
 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;

38. 38
38
Conclusões
 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;

39. 39
39
Conclusões
 Mercado precisa de profissionais capazes de
liderar ou apenas trabalhar em projetos DDS;
 Aquisição de conhecimento/expertise demanda
experiência e um contexto de projetos prática
que não são facilmente encontrados na
academia;

40. 40
Introdução a Projetos de
Desenvolvimento Distribuído de Software
Adailton Magalhães Lima
Universidade Federal do Pará
Campus Universitário de Castanhal
Curso Bacharelado em Sistemas de Informação