11 Processos para Desenvolvimento Distribuído de Software Camila Cunha Borges Setembro 2009

22 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 Estrutura da apresentação

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

44 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

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

66 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

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

88 DDS - Cenários Setembro 2009 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;

99 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

10 DDS - Desafios CATEGORIASDESAFIOS PessoasConfiança; Conflitos; Diferenças Culturais Processos Arquitetura do software;Engenharia de Requisitos; Gerencia de Configuração; Processo de Desenvolvimento Tecnologia 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 Setembro 2009

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

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

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 s; Artefatos: : a planilha de tarefas no Google Docs, o burndown e o grupo de ; 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 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; Estudo de Caso 2: SCRUM X DDS Setembro 2009

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 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, 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, Prikladnicki, R. “MuNDDoS: Um Modelo de Referência para Desenvolvimento Distribuído de Software”. Dissertação de Mestrado, PPGCC – PUCRS, Brasil, Prikladnicki, R., Yamaguti, M. H., Antunes, D. C. “Risk Management in SOMMERVILLE, Ian. Software Enginnering. 8.ed. [S.l] ADDISON WESLEY, J. L. N. PRIKLADINICKI, R.; AUDY. Desenvolvimento Distribuído de Software Setembro 2009

40 Referências [KRUCHTEN, 2001] KRUCHTEN, Philippe. What Is the Rational Unified Process?. Rational Software. Disponível em: /WhatIstheRationalUnifiedProcessJan01.pdf. Acessado em: 20 Maio [PERRELLI, 2009] Perrelli, Hermano. Visão Geral do RUP. Centro de Informática, Universidade Federal de Pernambuco. Disponível em: Acessado em 20 Maio [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, p. Setembro 2009