Desenvolvimento Distribuído de
Software
Em busca de uma METODOLOGIA
Yuska Paola Costa Aguiar
[email protected]
www.dsc.ufcg.edu.br/~yuska
Novembro de 2005
Roteiro

Introdução

Cenários

Práticas

Ferramentas

Processo de Desenvolvimento

Mensuração do Esforço Empenhado

Conclusões

Referências
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?
Cenários
[ANGIONI, SANNA, SORO-2005]

Outsourcing



E-lancing


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...
[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
Práticas
[ROBINS - 2005]

Prover acesso imediato e universal



Voluntários motivados





Disponibilizar todos os artefatos atualizados (custo zero)
Código da aplicação, projeto, bugs em aberto, responsabilidades
dos desenvolvedores, cronograma, projeto arquitetural...
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
Práticas
[ROBINS - 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
Práticas
[ROBINS - 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?

Integração
[JORGENSEN - 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

Ferramentas
[ROBINS - 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
Ferramentas
[ROBINS - 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
Ferramentas
[ROBINS - 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

Ferramentas
[ROBINS - 2005]
 O que falta?

Suporte para atividade tradicionais de:

Gerenciamento de requisitos

Gerenciamento de projeto

Métricas

Estimativas

Cronograma

Projeto de teste
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
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

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
Processo de Desenvolvimento
[ANGIONI, 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)
Processo de Desenvolvimento
[ANGIONI, SANNA, SORO - 2005]

MAAD (Methodology for Agile Distributed Development)

Projeto


Requisitos


As maiores devem ser quebradas em menores, e as menores
agrupadas em maiores
Desenvolvedores



Descritos detalhadamente (Mapeamento requisito  código deve ser
fácil)
Tarefas


Todos devem ter uma visão única
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?)
Processo de Desenvolvimento
[ANGIONI, SANNA, SORO - 2005]

Documentação




Código






Atualizada
Disponível
Enxuta
Padrões de codificação
Documentação
Testes
Refatoramento
Integração contínua
Feedback


Do time de desenvolvimento
Do cliente (Open Source)
Mensuração do Esforço Empenhado
[DALLE, 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
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



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



Stand-up Meeting
Programação em Pares
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
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-Publication
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-Publication 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 elance Economy. Harvard Business Review, 1998. p. 145-152. Download em:
http://www.hbsp.harvard.edu.