Apresentação Final
DONE is Open Not Enclosed - A free
Software Factory
22/08/05
Agenda
• Equipe
• Definição
• Papéis
• Ferramentas
• Projeto MARACATU
• Processo
– Fases
– Ciclo de Vida
• Evolução do Processo
• Conclusão
Equipe Definição Papéis Ferramentas Projeto MARACATU
1. André Assad (2a. fase)
2. Carolina Maia
3. Ednaldo Souza Filho
4. Eduardo Cruz
5. Emerson Espínola
6. Fred Durão
7. Gibeon Aquino
8. Jarley Nóbrega
9. Kellyton Brito
10.Marcely Santos
11.Paula Ferreira
12.Rodrigo Mendes
13.Starch Souza
14.Vinícius Garcia
Equipe Definição Papéis Ferramentas Projeto MARACATU
• História
O processo D.O.N.E é baseado na necessidade de
desenvolvimento de software livre usando o modelo de
Fábrica de Software. Ele foi elaborado por um grupo de
estudantes de mestrado e doutorado do CIn/UFPE para
dar suporte às atividades da disciplina Engenharia de
Software – IN953 (2005.1)
Equipe Definição Papéis Ferramentas Projeto MARACATU
Papel
Equipe
Gerente de Projeto
Jarley / Marcely
Líder Técnico
Rodrigo / Eduardo
Analista de Negócio
Vinicius / Marcely
Arquiteto de Software
Gibeon
Engenheiro de Qualidade
Paula
Engenheiro de Configuração
Starch
Engenheiros de Software
Fred, Ednaldo, Kellyton, Rodrigo,
Eduardo, Gibeon
Engenheiro de Testes
Emerson / André / Carol
Apoio (site / outros)
Carol, Kellyton, Vinicius, Paula, Jarley
Equipe Definição Papéis Ferramentas Projeto MARACATU
Ferramenta
Finalidade
XPlanner
Reportagem de Esforço
CVS
Controlador de Versões
Issue Tracker
Gerenciador de Mudanças /
Atividades
ArgoUML
Modelagem UML
Eclipse + Plug-ins
Codificação
JavaNCSS + JDepend
Métricas de Código
Ant
Integração
MS/Word
Documentação
Skype / MSN
Comunicação
Equipe Definição Papéis Ferramentas Projeto MARACATU
•
O projeto foi orientado visando o desenvolvimento de um plugin para o
Eclipse para realizar a busca de componentes em repositórios de projetos
na web através de palavras-chave e facetas.
•
O mecanismo de busca é baseado no Lucene, uma ferramenta Open
Source criada pela Apache Software Foundation.
•
A tecnologia e as pesquisas utilizadas para este projeto tiveram o suporte
do grupo RiSE - Reuse in Software Engineering, criado em Abril de 2004
pelo professor Sílvio Romero de Lemos Meira e seus estudantes. O
objetivo principal do RiSE é investigar e desenvolver o estado da arte de
práticas relacionadas ao reuso de software.
Processo Fases Ciclo de Vida Evolução Conclusão
• Modelo do Processo
O processo foi desenvolvido com foco nas atividades de
desenvolvimento de software Open Source com base nas
metodologias RUP e XP.
O processo tem duas grandes áreas: Suporte e
Engenharia.
Processo Fases Ciclo de Vida Evolução Conclusão
• Áreas de Suporte
– Venda
– Planejamento e Acompanhamento
– Garantia da Qualidade
– Gerência de Configuração
– Delivery
• Áreas de Engenharia
– Requisitos
– Análise e Projeto
– Implementação
– Testes
– Avaliação
Processo Fases Ciclo de Vida Evolução Conclusão
• O ciclo de vida é composto por pequenas iterações.
Processo Fases Ciclo de Vida Evolução Conclusão
• Foram escritos 2 processos
– Na fase 1, o processo contemplava muitas práticas do RUP,
muitos artefatos, mas percebeu-se que era sobrecarregado e
não foi seguido.
– Na fase 2, o processo foi completamente reescrito
considerando que Open Source não era apenas o produto com
código aberto, mas também a forma de desenvolvimento
distribuída, ou seja, através do uso de ferramentas para
facilitar a distribuição das atividades, comunicação da equipe e
coleta de métricas.
Apesar de dois processos terem sido definidos, nenhum deles
funcionou efetivamente...
Processo Fases Ciclo de Vida Evolução Conclusão
• Pontos fortes do processo
– Foi montado com a participação de todos os membros; do
projeto;
– Artefatos simples;
– Auditorias para auxílio da visibilidade;
– Uso de métricas para auxílio da visibilidade;
– Papéis claramente definidos;
– Pouca burocracia para entrada de novos membros;
– Uso de ferramentas;
– Leve e flexível;
Processo Fases Ciclo de Vida Evolução Conclusão
• Pontos fracos do processo
– Não é adequado para utilização no desenvolvimento de
software em comunidades abertas;
– Plano de CM confuso e pouco utilizado;
– Excesso de artefatos;
– Falta de definição de formas de controle das atividades
distribuídas;
– Falta de treinamento;
– Foco nos artefatos a serem produzidos e não nas atividades a
serem desenvolvidas;
Processo Fases Ciclo de Vida Evolução Conclusão
• Onde erramos...
– Falta de acompanhamento das atividades (pouca visibilidade);
– Falta de liderança efetiva do projeto;
– Falta de acompanhamento da satisfação do cliente;
– Disponibilidade para o projeto não era compatível com alguns papéis;
– Uso de tecnologias que a equipe desconhecia;
– Falta de ousadia e o conservadorismo da equipe na escolha do RUP;
– Muitas críticas e poucas iniciativas;
– Não demitimos aqueles que não estavam contribuindo;
– Sobrecarga de atividades pessoais (falta de conhecimento das próprias
limitações);
– Falta de proatividade;
Processo Fases Ciclo de Vida Evolução Conclusão
• Dificuldades em ambos processos
– Foco no produto e não no processo;
– Falta de treinamento sobre o processo;
– Pouco gerenciamento e acompanhamento do projeto;
– Papéis e responsabilidades mal definidos;
– Atividades mal distribuídas;
– Alocação super estimada;
– Esforço sub estimado;
– Falta de requisitos de interface gráfica;
– Falta de entendimento/consenso da equipe sobre os requisitos;
Processo Fases Ciclo de Vida Evolução Conclusão
• Dificuldades em ambos processos
– Falha de comunicação entre os membros da equipe;
– Complexidade do projeto piloto, por falta de conhecimento nas
ferramentas;
– Pouca gerência de configuração (baselines);
– Falta de interesse e disciplina dos membros da equipe;
– Dedicação a outros projetos pessoais;
– Foco no prazo cumprido e não na qualidade;
Processo Fases Ciclo de Vida Evolução Conclusão
• A experiência foi surpreendente para todos os integrantes;
• Consideramos que realmente trabalhamos e vivenciamos
problemas de uma comunidade Open Source;
• Aprendemos que um projeto presencial é difícil e que em
comunidade é muito mais complicado;
• Percebemos que mesmo com um processo definido, sem
uma liderança e gerência efetiva qualquer projeto pode
falhar;
• O foco deveria ter sido no processo e não no produto.
Obrigado!
Everything you want will be
D.O.N.E !!!
Download

DONE-FINAL