Processos para Desenvolvimento Distribuído de Software

1. Processos para Desenvolvimento Distribuído de Software Camila Cunha Borges ccb2@cin.ufpe.br http://cin.ufpe.br/~ccb2 Setembro 2009 1

2. Estrutura da apresentação • Introdução (O que é DDS, terminologias e cenários); • Adaptação de processos para desenvolvimento distribuído de software; (Práticas: Scrum,XP,RUP) • Oportunidades de Pesquisas; • Considerações Finais; • Referencias; Setembro 2009 2

3. Desenvolvimento Distribuído de Software “É um modelo de desenvolvimento de software onde os envolvidos em um determinado projeto estão dispersos” (CARMEL, 1999) Setembro 2009 3

4. DDS - Conceitos • Equipe global: Um conjunto de pessoas de diferentes nacionalidades que trabalham unidas em um projeto comum, através de culturas e fusos horários distintos, por um extenso período de tempo (Marquardt e Horvath, 2001). • Organizações virtuais: Entidades caracterizadas por realizar partes de um projeto em locais distintos, comportando-se como se estivesse em um mesmo local. (Karolak, 1998). Setembro 2009 4

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

6. 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 Setembro 2009 6

7. DDS - Cenários • Distância Física Inter-Atores; Setembro 2009

8. DDS - Cenários • Distância Física Intra-Atores: Distribuição interna dos atores (projeto, clientes ou usuários); • As equipes podem estar centralizadas ou distribuídas; • A distribuição intra-atores não leva em conta a distribuição inter-atores; Setembro 2009 8

9. Fatores que levam ao DDS • Necessidade de recursos globais para serem utilizados a qualquer hora; • Vantagem de estar perto do mercado local (conhecimento dos clientes e condições locais explorando as oportunidades de mercado); • Pressão para o desenvolvimento time-to-market, desenvolvimento follow-the-sun proporcionado pelas 24hs continuas das equipes distantes; Setembro 2009 9

10. DDS - Desafios Setembro 2009 10

11. DDS - Processos • Arquitetura do software: • Deve se basear no princípio da modularidade: • Reduz a complexidade; • Permite um desenvolvimento em paralelo simplificado; • Permite um desenvolvimento com menor; interdependência entre os locais; • Reduz custos adicionais de coordenação. Setembro 2009

12. DDS – Processos • Engenharia de Requisitos: “Em ambientes DDS, dificuldades como distância, comunicação e cultura causam um aprofundamento dos problemas inerentes ao processo de engenharia de requisitos, que adquire caráter ainda mais crítico ” (Zowghi, 2002) • Os participantes devem buscar obter uma visão comum sobre os requisitos; • Informações de diversas origens devem ser compartilhadas com todos os stakeholders; Setembro 2009

13. DDS – Processos • Gerencia de Configuração: • Gerência de modificações simultâneas em um produto a partir de diferentes locais; • Aplicação de padrões; • Uso de ferramentas de gerência de configuração compartilhada por duas ou mais equipes distribuídas; Setembro 2009

14. DDS – Processos • Processo de Desenvolvimento: • Deve ser comum a equipes distribuídas; • Quando processos são distribuídos em diversas localidades, a falta de sincronização pode se tornar crítica; • Ex: Quando a equipe de desenvolvimento e equipe de testes estão em localidades diferentes e definem teste de integração de forma diferentes. • Uma metodologia de desenvolvimento auxilia diretamente na sincronização e impõe rigor à equipe. Setembro 2009

15. DDS – Processos • Ciclo de vida tradicional (Karolak 1998): • 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); Setembro 2009

16. DDS – Processos • Práticas Ágeis: • Releases frequentes; • Feedback contínuo; • Padrões de codificação; • Valorização da comunicação; Setembro 2009

17. DDS – Processos • Os processos de software atuais são capazes de lidar com as características do desenvolvimento distribuído e ao mesmo tempo garantir a qualidade do produto?  Necessidade de um processo flexível, leve, ágil (adaptação à comunicação remota), disciplinado, iterativo e incremental. Setembro 2009 17

18. Estudo de Caso 1: RUP X DDS • Organização brasileira de grande porte; • Sede: Interior de São Paulo; • Escritórios: Em algumas capitais brasileiras e no exterior (EUA, Espanha e Argentina); • 350 clientes espalhados e 2.500 colaboradores; • Unidade de análise: Matriz (80 desenvolvedores) Setembro 2009

19. Estudo de Caso 1: RUP X DDS • Projeto 1: Desenvolver uma aplicação para uma grande empresa cuja matriz estava localizada nos EUA, o projeto também era gerenciado por uma filial no Brasil. • Equipe do projeto localizada no Brasil (em locais diferentes) e os clientes tanto no Brasil quanto nos EUA. • Os usuários estavam nos EUA e no Brasil. Setembro 2009

20. Estudo de Caso 1: RUP X DDS • O processo é baseado no RUP para o desenvolvimento de software e na metodologia do PMI para o gerenciamento de projetos; • O processo é adaptado à realidade da organização; • O processo é igual para todas as outras unidades de desenvolvimento; Setembro 2009

21. Estudo de Caso 1: RUP X DDS • O processo é dividido em 6 fases: • Controlar: Acompanhamento e controle; • Especificar: Levantamento de informações, desenho lógico, modelo de dados e projeto conceitual; • Prototipar: Telas funcionais e relatórios; Setembro 2009

22. Estudo de Caso 1: RUP X DDS • Desenvolver: especificação e o desenvolvimento do projeto, além da execução dos testes; • Validar: são executadas as validações junto ao cliente; • Implantar: é elaborado o manual do usuário, treinamento do cliente e implantação do projeto em produção; Setembro 2009

23. Estudo de Caso 1: RUP X DDS • Dificuldades: • Gestão do Conhecimento; • Gerência de Configuração de Software; • Gerência de Requisitos; • Comunicação e idioma; • Confiança; • Falta de definição de padrões. Setembro 2009

24. Estudo de Caso 1: RUP X DDS • Soluções: • Definição de padrões; • Gerência de Riscos; • Integração das equipes; • Avaliação constante da produtividade das equipes; • Investimento em planejamento; • Documentação das atividades e dos problemas; • Treinamento. Setembro 2009

25. Estudo de Caso 2: SCRUM X DDS • Disciplina de Engenharia de Software (2009); • Projeto: FireScrum; • Equipe: 60 alunos divididos em 6 times; • TaskBoard, Planning Poker, Test Module, BugTracking e Desktop Agent • Metodologia utilizada: Scrum; Setembro 2009 25

26. Estudo de Caso 2: SCRUM X DDS • Unidade de análise: Módulo Bugtracking; • O time era composto de 9 estutantes; • 6 distribuídos no estado de Pernambuco, 2 no estado da Paraíba e 1 na Bahia; • As Sprints duravam 15 dias; • As aulas da disciplina aconteciam as segundas-feiras; Setembro 2009

27. Estudo de Caso 2: SCRUM X DDS • Sprint Planning 1: Reunião presencial após as aulas; • Definição dos itens de backlog que seriam atendidos na sprint. • Sprint Planning 2: Reunião remota (msn, skype, lista de discussão); • Daily scrum meeting: msn, skype e lista de emails; • Artefatos: : a planilha de tarefas no Google Docs, o burndown e o grupo de email; Setembro 2009

28. Estudo de Caso 2: SCRUM X DDS • Dificuldades: • As reuniões Daily scrum meeting não aconteciam diariamente; • Comunicação face a face; • Incompatibilidade de horário entre os membros; • Falta de auto-gerenciamento dos demais times (algumas tarefas dependiam de outros times); • Pouco conhecimento nas ferramentas utilizadas; Setembro 2009

29. Estudo de Caso 2: SCRUM X DDS • Soluções: • O time optou por realizar a reuniao Daily scrum meeting por skype a cada 2 dias; • Foi criada uma lista de discussão para o time; • Divisão do time em duplas ou em trios; • Treinamento interno entre os membros do time; • Reuniões aos sábados que antecediam a entrega da sprint; Setembro 2009 29

30. DXP - Distributed Extreme Programming • O DXP aplica princípios do XP em equipes distribuídas.; • O DXP aborda: • Conectividade entre os membros (uso da internet); • Uso de ferramenta de gerenciamento de configuração; • Compartilhamento de aplicação; • Uso de videoconferência; • Familiaridade entre os membros; Setembro 2009

31. DXP - Distributed Extreme Programming • Benefícios do DXP: • A terceirização de um projeto de software pode oferecer um custo menos (Ex: Índia e China); • Envolvimento do cliente através de videoconferência (as vezes o cliente não tem disponibilidade de estar no local de desenvolvimento); • Integração harmoniosa entre os membros de uma equipe móvel (Ex: Caso necessitem se deslocar, podem utilizar equipamentos móveis para participar das atividades de desenvolvimento); Setembro 2009

32. DXP - Distributed Extreme Programming • Desafios: • 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 antamento das atividades; Setembro 2009

33. 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; Setembro 2009

34. 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. Setembro 2009

35. 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. Setembro 2009

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

37. Considerações finais • A gestão do conhecimento incentiva o compartilhamento de informações e estimula a aprendizagem por experiência; • 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; • Ferramentas de apoio atuam como facilitador na interação distribuída; Setembro 2009

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. • Kiel, L. “Experiences in Distributed Development: A Case Study”, In: Workshop on • 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. Setembro 2009

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. • Yin, Robert. “Estudo de Caso: planejamento e métodos”. SP: Bookman, 2001, 205p. • 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. • Prikladnicki, R., Yamaguti, M. H., Antunes, D. C. “Risk Management in • SOMMERVILLE, Ian. Software Enginnering. 8.ed. [S.l] ADDISON WESLEY, 2007. • J. L. N. PRIKLADINICKI, R.; AUDY. Desenvolvimento Distribuído de Software. 2007. Setembro 2009

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. Setembro 2009