Apresentação Final DONE is Open Not Enclosed - A free Software Factory 22/08/05.

Slides:



Advertisements
Apresentações semelhantes
Engenharia de Software Qualidade de Software Uma abordagem conceitual André Luis Zanon São Carlos SP – UFSCAR 2010 Engenharia de Software – UFSCAR.
Advertisements

Engenharia de Software
Garantia da Qualidade Mário Eduardo.
Garantia da Qualidade Mário Eduardo. 2 Desafios & Soluções.
O Processo Praxis 3.0 Processos de Software 25/03/2017
Engenharia de Software
Sistema Gerenciador de Ocorrências
Rational Unified Process(RUP)
Valéria Maria Lauande Março/2010
Mitos e Problemas Relacionados ao Software
Metodologia de Desenvolvimento de Software
Processo Desenvolvimento de Software Tradicional
MPS.BR Dextra Dextra Edite Martins.
Instituto de Pesquisas Eldorado
S ISTEMA DE G ERENCIAMENTO F INANCEIRO. O S I NTEGRANTES Caio Mac Cord Fernando Bianchini Pessoa Joel Ferreira José Enes Mateus Mauricio Lederer.
Prof. Jorge Luis Risco Becerra Auxiliares:Prof. Eduardo Lobo
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Rational Unified Process
RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo)
RUPinho Qualidade de Software
Engenharia de Software
Planejamento e Gerenciamento de Projetos
Visão Geral PRO.NET.
Fundamentos de Engenharia de SW
Avaliação do RUP como processo para desenvolvimento de software
Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
IFSul – Campus Venâncio Aires
Relato de Experiência do processo de desenvolvimento do GSAN
Introdução à Qualidade
Apresentação Final DONE is Open Not Enclosed - A free Software Factory 22/08/05.
ANÁLISE E DESENVOLVIMENTO
Software engineering, the software process and their support M.M. Lehman Apresentadora: Tarciana Dias da Silva.
(Open Unified Process)
The Factory Produzindo Arte Manufaturada. The Factory Objetivo Prover uma linha de produção de soluções que atendam às necessidades específicas de cada.
Abr-17 Atividades, Artefatos e Responsáveis da Disciplina de Análise e Projeto Fluxo de análise e projeto.
Análise e Projeto Orientados a Objetos
Bruno Silva Desenvolvido a partir de
 Objetivos do Projeto:  Automatizar um processo de estimativa de esforço para realização de tarefas num projeto baseado no método Wideband Delphi. 
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Gerência de Configuração Autor: Silvio Cortez. Fluxos e papeis Escrever plano Definir ferramentas Escrever plano de gerência de configuração Gerente de.
RUP - Cap. 4 – Processo Centrado na Arquitetura
Processo de Desenvolvimento de Software – PDS C Construção - PAS
Testes Baseados Em Riscos: Uma revisão do Estado-da- Arte Nielson Pontes Outubro, 2010.
Modelos de Qualidade para indivíduos e grupos: PSP & TSP
Hukarz Open Source Process D01 Alan Kelon, Silvio Meira Recife, 01/12/2006.
1 Mesa de Compras Apresentação Fábrica 16/06/2003.
Engenharia de Software
Planejamento e Gerência de Projeto Plácido Antonio de Souza Neto
ADS – 5º Semestre Trabalho de Conclusão de Curso
Apresentação Fábrica IESolutions
Gestão de projetos de Software GTI-16
Integração.
UML e a Ferramenta Astah
Projeto e-Build. Apresentação FábricaEquipeProdutoMercado ProjetoEscopoMetodologiaCronograma ArtefatosPrincipais riscosArquiteturaLições aprendidas.
Desenvolvimento Global de Software Mestrado de Informática / UFPB Francilene Procópio Garcia, D.Sc. Configuração do Processo - Parte.
© Nabor C. Mendonça Processo / Metodologia de Desenvolvimento de Software.
SISTEMA DE MONITORAMENTO DA TECNOLOGIA DA INFORMAÇÃO.
Apresentação do Projeto Piloto
Maraca² RFP Reply. Introdução Reuso dentro da organização Busca e recuperação.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
MHP – RFP 2 Luiz Eduardo Sílvio Meira Jones Albuquerque
PSDS com CMMI Nível 2 Dimitri de Almeida Malheiros Barbosa 27/03/2006.
IF 718 Análise e Projeto de Sistemas Augusto Sampaio Vitor Braga (Estágio docência) Camila Sá (Monitora) Parte do material cedido pela Qualiti Software.
MAPS: Um Modelo de Adaptação de Processos de Software Ciro Carneiro Coelho Orientador Prof. Hermano Perrelli de Moura.
SECRETARIA DA FAZENDA DO ESTADO DE SÃO PAULO Gerenciamento de Serviços de TI - Evolução, Lições Aprendidas e Resultados Práticos - Dezembro / 2015.
O uso de XP em uma Organização CMM 2 Renata Endriss
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Atividades, Artefatos e Responsáveis da Disciplina de Análise e Projeto.
Maracatwo RFP Reply. Introdução Reuso dentro da organização Busca e recuperação.
Transcrição da apresentação:

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 PapelEquipe Gerente de ProjetoJarley / Marcely Líder TécnicoRodrigo / Eduardo Analista de NegócioVinicius / Marcely Arquiteto de SoftwareGibeon Engenheiro de QualidadePaula Engenheiro de ConfiguraçãoStarch Engenheiros de SoftwareFred, Ednaldo, Kellyton, Rodrigo, Eduardo, Gibeon Engenheiro de TestesEmerson / André / Carol Apoio (site / outros)Carol, Kellyton, Vinicius, Paula, Jarley

Equipe Definição Papéis Ferramentas Projeto MARACATU FerramentaFinalidade XPlannerReportagem de Esforço CVSControlador de Versões Issue TrackerGerenciador de Mudanças / Atividades ArgoUMLModelagem UML Eclipse + Plug-insCodificação JavaNCSS + JDependMétricas de Código AntIntegração MS/WordDocumentação Skype / MSNComunicaçã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. Eclipse O mecanismo de busca é baseado no Lucene, uma ferramenta Open Source criada pela Apache Software Foundation.Lucene, 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.RiSE - Reuse in Software Engineering

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 !!!