Em busca de uma METODOLOGIA

1
Desenvolvimento Distribuído de Software

• Em busca de uma METODOLOGIA

Yuska Paola Costa Aguiar yuska_at_dsc.ufcg.edu.br www
.dsc.ufcg.edu.br/yuska Novembro de 2005
2
Roteiro

• Introdução
• Cenários
• Práticas
• Ferramentas
• Processo de Desenvolvimento
• Mensuração do Esforço Empenhado
• Conclusões
• Referências

3
Introdução

• Desenvolvimento Distribuído de Software (DDS) é
  uma realidade baseada em práticas e apoiada em
  ferramentas
• É possível adequar metodologias e processos
  existentes para a realidade do DDS?
• É mais prudente propor uma metodologia capaz de
  guiar o DDS a partir das características, das
  práticas e das ferramentas existentes?

4
Cenários ANGIONI, SANNA, SORO-2005

• Outsourcing
• Uma empresa contrata outra para desenvolver
  módulos ou partes do software
• Offshore Outsourcing as empresas estão
  localizadas em países diferentes. Maior
  dificuldade devido as barreiras culturais, de
  idioma, de padrões...
• E-lancing MALONE - 1998
• Rede virtual de freelancer que trabalham juntos
  no desenvolvimento de um software. Quando o
  software é concluído a rede se dissolve e seus
  membros continuam a trabalhar independentemente
• Open Source
• Um time de desenvolvedores central é responsável
  por integrar as funcionalidades, partes do código
  desenvolvidas por outros programadores que estão
  geograficamente distribuídos e contribuindo
  voluntariamente para com o projeto

5
Práticas ROBINS - 2005

• Prover acesso imediato e universal
• Disponibilizar todos os artefatos atualizados
  (custo zero)
• Código da aplicação, projeto, bugs em aberto,
  responsabilidades dos desenvolvedores,
  cronograma, projeto arquitetural...
• Voluntários motivados
• Colaboradores geralmente são usuários Open Source
• Incluir necessidades particulares no software
• Prazer de ter sua contribuição aceita
• Necessitar de validação externa de suas
  habilidades...
• Encorajar a pluralidade de colaboradores
• Os colaboradores devem apoiar uns aos outros
• Crescimento da população
• Estímulo para a criação de novas funcionalidades

6
PráticasROBINS - 2005

• Trabalhar em comunidade (Práticas)
• A fim de acumular bens de software
• Ambiente Colaborativos de Desenvolvimento
  (SourceForge e SourceCast)
• Seguir Padrões
• Validação do projeto
• Tomada de decisão de escopo
• Implantação do reuso
• Cultura de Reuso
• Contribui no gerenciamento do escopo
• Apresenta resultados mais rapidamente
• Evita duplicação de código

7
PráticasROBINS - 2005

• Releases rápidos e freqüentes
• Revisão dos colegas
• Eliminação de defeitos de codificação
• Aumento na qualidade do código produzido
• Integração JORGENSEN - 2005
• Sua prática freqüente reduz a carga de trabalho
• Na maioria dos casos Open Source é uma atividade
  centralizada
• Centralização da Integração em um ambiente
  descentralizado. Existe uma contradição?

8
IntegraçãoJORGENSEN - 2005

• Integração Centralizada
• Sobrecarregar o executor da tarefa
• Demandar mais tempo para disponibilizar uma nova
  versão
• Desestimular o relato ou reparo de erros
• Integração Descentralizada
• É responsabilidade do programador integrar o
  código modificado
• Deve ser acompanhado por Testes e Revisão dos
  Colegas
• O código não tem dono, mas existe um responsável
  pela manutenção do mesmo no que diz respeito a
  fixar bugs encontrados por outros desenvolvedores
  e responder aos problemas reportados
• Estimula os desenvolvedores

9
FerramentasROBINS - 2005

• Controle de Versão
• CVS, WinCVS, CVSWeb, TortoiseSVN
• Acesso universal - Releases freqüentes -
  Integração Revisão dos colegas
• Suporte Técnico e Rastreamento de Erros
• Bugzilla, Scarab
• Releases freqüentes Revisão dos colegas
• Lista de e-mails
• Comunicação
• Sites Web do projeto
• Acesso universal Reuso

10
FerramentasROBINS - 2005

• HOWTOs, FAQs
• Orientada a objetivos
• Acesso universal Comunicação
• Wiki, TWiki, SubWiki
• Atualização feita pelos usuários
• Exemplo de como organizar as informações
• Acesso universal Comunicação
• Construção do Sistema
• Make, Automake, Autoconf, Ant, Tinderbox, gump,
  CruiseControl, XenoFarm, Maven
• Motiva os desenvolvedores

11
FerramentasROBINS - 2005

• Projeto e Geração de Código
• Torque, Castor, Hibernate
• XDoclet, vDoclet.JUnitDoclet, Doxygen
• Motiva os desenvolvedores
• Garantia de Segurança
• JUnit, PHPUnit, PyUnit, NUnit (testes)
• Lint, LCLint, Checkstyle, JCSC, JDepend, PyCheck,
  RATS, Flawfinder (erros de inicialização de
  variáveis, chamada a bibliotecas incorretas)
• Codestriker (revisão remota de código)
• Qualidade Integração Revisão dos colegas

12
FerramentasROBINS - 2005

• O que falta?
• Suporte para atividade tradicionais de
• Gerenciamento de requisitos
• Gerenciamento de projeto
• Métricas
• Estimativas
• Cronograma
• Projeto de teste

13
Impacto da Utilização das Ferramentas ROBINS -
2005

• Ferramentas são gratuitas
• Mais membros do time de desenvolvimento estão
  aptos a acessar e contribuir com os artefatos
  durante todas as fases do desenvolvimento
• Todos os artefatos disponíveis e atualizados
• Redução de retrabalho
• Reuso
• Contribuição dos Stakeholders
• Acesso a informações atualizadas pode estimular a
  participação dos interessados

14
Impacto da Utilização das Ferramentas ROBINS -
2005

• Ferramentas suportam releases incrementais
• Os releases podem acontecer mais cedo e com
  maior freqüência
• Diminuição da sobrecarga dos desenvolvedores
• Aumento da produção e da satisfação dos
  desenvolvedores
• O suporte a revisão dos colegas
• Aumenta a qualidade do produto
• Diminui o retrabalho
• Erros são encontrados precocemente

15
Processo de Desenvolvimento

• Metodologias tradicionais não dão suporte as
  características existentes no Desenvolvimento
  Distribuído de Software
• Algumas práticas apontam para um conjunto de
  aspectos a serem levados em consideração quando
  se tenta elaborar um processo de desenvolvimento
  de software adequado a essa realidade
• Processos Ágeis parecem ser mais adequados as
  características do Desenvolvimento Distribuído de
  Software

16
Processo de DesenvolvimentoANGIONI, SANNA, SORO
- 2005

• Metodologias Ágeis X DDS
• Características Comuns
• Mudança como regra
• Releases freqüentes
• Feedback contínuo
• Padrões de codificação
• Valorização da comunicação
• Propriedade coletiva de código
• Características Divergentes
• Cliente real não existe (Open Source)

17
Processo de DesenvolvimentoANGIONI, SANNA, SORO
- 2005

• MAAD (Methodology for Agile Distributed
  Development)
• Projeto
• Todos devem ter uma visão única
• Requisitos
• Descritos detalhadamente (Mapeamento requisito ?
  código deve ser fácil)
• Tarefas
• As maiores devem ser quebradas em menores, e as
  menores agrupadas em maiores
• Desenvolvedores
• Escolhe com o que trabalhar (respeitando as
  prioridades estabelecidas)
• Devem estar informados sobre o que os outros
  desenvolvedores estão fazendo (Open Source?)
• Releases
• Constantes, flexíveis no conteúdo, mas rígidos na
  data de entrega (Open Source?)

18
Processo de DesenvolvimentoANGIONI, SANNA, SORO
- 2005

• Documentação
• Atualizada
• Disponível
• Enxuta
• Código
• Padrões de codificação
• Documentação
• Testes
• Refatoramento
• Integração contínua
• Feedback
• Do time de desenvolvimento
• Do cliente (Open Source)

19
Mensuração do Esforço EmpenhadoDALLE, DAVID -
2005

• Tentativa de encontrar um modelo de produção
  (matemático econômico) capaz de representar o
  esforço empenhado pelos desenvolvedores em um
  projeto onde o desenvolvimento acontece de forma
  distribuída
• Número de linhas adicionadas e removidas
• Correção de bugs
• Melhoria do código
• Módulos de baixo nível possuem mais valor
• Diversidade de funcionalidades possibilita
  combinações
• Maior confiabilidade em códigos mais conhecido
  pela comunidade
• O empenho depende da motivação dos colaboradores
• Um único colaborador contribuindo para o
  crescimento de vários projetos distintos
• A alocação de pessoal é mais probabilística do
  que determinística

20
Conclusões

• Questões presentes em metodologias ágeis não
  podem ser substituídas, com mesma eficiência, por
  encontros virtuais ou revisão dos amigos
• Stand-up Meeting
• Programação em Pares
• As características de Outsourcing, E-lancing e
  Open Source podem ser consideradas distantes
  quando se tenta traçar uma metodologia comum aos
  três cenários
• Presença do Cliente
• Gestão de Pessoal
• Os projetos oferecem características peculiares,
  fator que dificulta a consolidação de uma
  metodologia de apoio. O que é mais provável é a
  indicação de aspectos a considerar quando se fala
  de ambiente distribuído de software
• Comunicação
• Integração Contínua
• Releases Freqüentes
• Uso de Padrões

21
Referências

• JORGENSEN - 2005 JORGENSEN, Niels. Incremental
  and decentralized Integration in FreeBSD. In
  FELLER, Joseph, FITZGERALD, Brian, HISSAM, Scott
  A., LAKHANI, Karim R.. Perspectives on Free and
  Open source Software. Massachusets Institute of
  Tecnology, Library of Congress Cataloging-Publicat
  ion Data, 2005. p. 227-243.
• ROBBINS - 2005 ROBBINS, Jason. Adopting Open
  Source Software Engineering (OSSE) Pratices by
  Adopting OSSE Tools. In FELLER, Joseph,
  FITZGERALD, Brian, HISSAM, Scott A., LAKHANI,
  Karim R.. Perspectives on Free and Open source
  Software. Massachusets Institute of Tecnology,
  Library of Congress Cataloging-Publication Data,
  2005. p. 245-264.
• DALLE, DAVID - 2005 DALLE, Jean-Michel, DAVID,
  Paul A.. Allocation of Software Development
  Resources in Open Source Procuction Mode. In
  FELLER, Joseph, FITZGERALD, Brian, HISSAM, Scott
  A., LAKHANI, Karim R.. Perspectives on Free and
  Open source Software. Massachusets Institute of
  Tecnology, Library of Congress Cataloging-Publicat
  ion Data, 2005. p. 297-227.
• ANGIONI, SANNA, SORO - 2005 ANGIONI, Manuela,
  SANNA, Raffaella, SORO, Alessandro. Defining a
  Distributed Agile Methodology for na Open Source
  Scenario. Proceedings of the First International
  Conference on Open Source Systems, Genova, Julho
  de 2005. p. 209- 214.
• MALONE - 1998 MALONE, Thomas W., LAUBACHER,
  Robert J.. The Dawn of e-lance Economy. Harvard
  Business Review, 1998. p. 145-152. Download em
  http//www.hbsp.harvard.edu.