Processos para Desenvolvimento Distribuído de Software

1. Processos para Desenvolvimento Distribuído de Software Alex Nery Borges Júnior anbj@cin.ufpe.br Centro de Informática – CIn/UFPE Setembro / 2010 1

2. 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; • Considerações Finais; 2

3. Introdução

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

5. Conceitos

6. DDS - Conceitos • 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; 6

7. DDS - Conceitos • 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). 7

8. DDS - Terminologias • GSD – Global Software Development • DSD – Distributed Software Development • GDD – Geographically Distributed Development • DDS – Desenvolvimento Distribuído de Software 8

9. Motivações

10. DDS - Motivações 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; 10

11. DDS - Motivações 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; 11

12. Níveis de Dispersão

13. DDS - Níveis de Dispersão • Distância Física Inter-Atores;

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

15. Modelos de Negócio

16. DDS – Modelos de Negócio (Prikladiniki) • 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 16

17. Desafios

18. DDS - Desafios • 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; 18

19. DDS - Desafios 19

20. DDS - Desafios • Arquitetura do Software: • 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;

21. DDS - Desafios • Engenharia de Requisitos: • 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;

22. DDS - Desafios • Gerência de Configurações: • 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;

23. DDS - Desafios • Processo de Desenvolvimento: • 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;

24. Processos

25. 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: Modelo de Karolak; DXP (Distributed Extreme Programming); 25

26. DDS - Processos (Modelo de Karolak) 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; 26

27. DDS - Processos (Modelo de Karolak) Modelo de Karolak 27

28. DDS - Processos (DXP) • O DXP é um processo para o DDS que aplica princípios do XP em equipes distribuídas; • O DXP aborda: • 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;

29. 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: 29

30. DDS - Processos (DXP) • Desafios e Práticas: • 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;

31. Oportunidades de Pesquisa

32. DDS - Oportunidades de Pesquisa • 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;

33. DDS - Oportunidades de Pesquisa • 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.

34. DDS - Oportunidades de Pesquisa • 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.

35. Considerações Finais

36. DDS - Considerações finais • 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;

37. DDS - Considerações finais • 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;

38. Referências • 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.

39. Referências • Marquardt, M. J., Horvath, L. “Global Teams: how top multinationals span boundariesand cultures with high-speed teamwork”. Davies-Black. 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.

40. Referências • [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.

41. Dúvidas ??