Em busca de uma METODOLOGIA Yuska Paola Costa Aguiar [email protected] yuska Novembro de 2005...
Transcript of Em busca de uma METODOLOGIA Yuska Paola Costa Aguiar [email protected] yuska Novembro de 2005...
Em busca de uma METODOLOGIA
Yuska Paola Costa [email protected]
www.dsc.ufcg.edu.br/~yuska
Novembro de 2005
Desenvolvimento Distribuído de Software
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 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
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
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 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?)
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)
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
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
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.