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

Apresentação em tema: "11 Processos para Desenvolvimento Distribuído de Software Camila Cunha Borges Setembro 2009."— Transcrição da apresentação:

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

2 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

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

4 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

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

6 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 7 DDS - Cenários Distância Física Inter-Atores; Setembro 2009

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

9 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 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 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 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 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 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 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 16 DDS – Processos Práticas Ágeis: – Releases frequentes; – Feedback contínuo; – Padrões de codificação; – Valorização da comunicação; Setembro 2009

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