11
Processos para Desenvolvimento Distribuído de Software
Camila Cunha Borges
ccb2@cin.ufpe.br http://cin.ufpe.br/~ccb2
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 10
DDS - Desafios
CATEGORIAS DESAFIOS
Pessoas Confianç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 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 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 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 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 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. 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
