11 processos para desenvolvimento distribuído de software camila cunha borges [email protected] ccb2...

11

Processos para Desenvolvimento Distribuído de Software

Camila Cunha Borges

[email protected]://cin.ufpe.br/~ccb2

Setembro 2009

mailto:[email protected]

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

1010

DDS - Desafios

CATEGORIAS DESAFIOS

PessoasConfiança; Conflitos; Diferenças Culturais

Processos

Arquitetura do software;Engenharia de Requisitos; Gerencia de Configuração; Processo de Desenvolvimento

TecnologiaTecnologias de Colaboração;Telecomunicações

GestãoCoordenação e Controle; Gerenciamento de Projetos; Gerenciamento de Risco

ComunicaçãoEstilo 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

1717

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

User

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


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


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


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


– 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


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


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

2525

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


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


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


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

2929

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

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


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


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


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


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

11 processos para desenvolvimento distribuído de software camila cunha borges [email protected] ccb2...

Documents