Desenvolvimento Distribuído de Software

1. Desenvolvimento Distribuído de Software Em busca de uma METODOLOGIA Yuska Paola Costa Aguiar yuska@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á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

7. 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?

8. 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

9. 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

10. 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

11. 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

12. Ferramentas[ROBINS - 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 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)

17. Processo de Desenvolvimento[ANGIONI, 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 Desenvolvimento[ANGIONI, 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 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

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-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 e-lance Economy. Harvard Business Review, 1998. p. 145-152. Download em: http://www.hbsp.harvard.edu.