Processos para Desenvolvimento Distribudo de Software Camila Cunha

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

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; 2 Setembro 2009

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

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

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

DDS – Modelos de Negócio (Prikladiniki) 6 l Onshore Insourcing: departamento dentro da empresa ou uma subsidiária da empresa no mesmo país. l Offshore Insourcing: subsidiária da empresa para prover serviços de desenvolvimento de software em um país diferente da empresa contratante. l Onshore Outsourcing: contratação de um empresa terceirizada localizada no mesmo país da empresa contratante. l Offshore Outsourcing: contratação de uma empresa terceirizada localizada em um país diferente da contratante Setembro 2009

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

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

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

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

DDS - Processos l Arquitetura do software: – Deve se basear no princípio da modularidade: l l 11 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

DDS – Processos l Engenharia de Requisitos: – – 12 “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

DDS – Processos l Gerencia de Configuração: – – – 13 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

DDS – Processos l 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; l – 14 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

DDS – Processos l Ciclo de vida tradicional (Karolak 1998): – 15 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

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

DDS – Processos l 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. 17 Setembro 2009

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

Estudo de Caso 1: RUP X DDS l l l 19 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

Estudo de Caso 1: RUP X DDS l l l 20 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

Estudo de Caso 1: RUP X DDS l 21 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

Estudo de Caso 1: RUP X DDS – – – 22 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

Estudo de Caso 1: RUP X DDS l 23 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

Estudo de Caso 1: RUP X DDS l 24 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

Estudo de Caso 2: SCRUM X DDS l l l Disciplina de Engenharia de Software (2009); Projeto: Fire. Scrum; Equipe: 60 alunos divididos em 6 times; – l 25 Task. Board, Planning Poker, Test Module, Bug. Tracking e Desktop Agent Metodologia utilizada: Scrum; Setembro 2009

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

Estudo de Caso 2: SCRUM X DDS l Sprint Planning 1: Reunião presencial após as aulas; – l l l 27 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

Estudo de Caso 2: SCRUM X DDS l Dificuldades: – – – 28 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

Estudo de Caso 2: SCRUM X DDS l 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; Setembro 2009

DXP - Distributed Extreme Programming l l O DXP aplica princípios do XP em equipes distribuídas. ; O DXP aborda: – – – 30 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

DXP - Distributed Extreme Programming l Benefícios do DXP: – – – 31 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

DXP - Distributed Extreme Programming l Desafios: – – – 32 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

Oportunidades de Pesquisa 33 l 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). l 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

Oportunidades de Pesquisa 34 l 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. l Arquitetura de Software – Como projetar a arquitetura do software de forma a minimizar problemas de coordenação entre as equipes. Setembro 2009

Oportunidades de Pesquisa 35 l 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. l 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

Considerações finais 36 l 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; l 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

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

Referências l l l l 38 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, 159 p. Kiel, L. “Experiences in Distributed Development: A Case Study”, In: Workshop on Global Software Development at ICSE, Oregon, EUA, 2003, 4 p. 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, 269 p. Setembro 2009

Referências l l l l 39 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, 205 p. 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. “Mu. NDDo. S: 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

Referências l l l 40 [KRUCHTEN, 2001] KRUCHTEN, Philippe. What Is the Rational Unified Process? . Rational Software. Disponível em: http: //www. ibm. com/developerworks/rational/library/content/Rational. Edge/jan 01 /What. Isthe. Rational. Unified. Process. Jan 01. 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/~if 717/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