UNIVERSIDADE FEDERAL DE LAVRAS




UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E
 GESTÃO DE PROJETO DE SOFTWARE LIVRE P...
ANTONIO SÉRGIO NOGUEIRA




UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E
 GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQU...
ANTONIO SÉRGIO NOGUEIRA



       UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E
        GESTÃO DE PROJETO DE SOFTWARE L...
Este trabalho é especialmente dedicado à Equipe do
     Invesalius do Centro Tecnológico da Informação
Renato Archer pelo ...
AGRADECIMENTOS




Agradeço a Deus por me dar força para correr atrás do meu sonho e para executar
este trabalho.

À mamãe...
Sumário
INTRODUÇÃO...........................................................................................................
.............................................................................................................................
Figuras
Figura 1. Relacionamento entre engenharia de processo, engenharia de produto e o
gerenciamento de projeto............
Tabelas

Tabela 1. Relação entre as áreas de conhecimento e processos do gerenciamento
de projetos...........................
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E
      GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES
      GEOGRAFICAME...
está estruturado da seguinte forma e terá sequência nas outras monografia escritas pelo
grupo da UFLA que será disponibili...
Capítulo 1. SOFTWARE LIVRE

     É interessante antes de discutirmos sobre práticas de desenvolvimento usando
metodologia ...
software livre não é algo anticapitalista ou anarquista mas sim um modelo alternativo de
negócio para a indústria de softw...
   Manter o copyright original na redistribuição do código fonte;
          O software Xfree 86, o banco de dados Postgr...
    Apache – Servidor, mais usado no mundo. Disponível para download em:
         http://www.apache.org.
        Gimp – ...
Capítulo 2. GERÊNCIA DE PROJETOS

2.1 O gerenciamento de projeto
        O aumento cada vez maior da participação do softw...
   Definição do cronograma - que exige estimar esforços associados a resolução de
       problemas, adicionar pessoas ao ...
Depois das atividades da engenharia de processo, a gerência de projeto é a
primeira camada do processo de desenvolvimento ...
Tabela 1. Relação entre as áreas de conhecimento e processos do gerenciamento de projetos




Gerência de integração: envo...
dentro do orçamento aprovado. Consiste no planejamento dos recursos, estimativa,
orçamento e controle de custos.
Gerência ...
Capítulo 3. PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

3.1 Introdução
       É um conjunto de atividades, parcialmente orde...
porções menores ou miniprojetos. As iterações referem-se a passos no fluxo de
desenvolvimento, e incrementos a evoluções d...
planos estão estáveis o bastante para que se possa fazer uma estimativa segura do custo
e do prazo final de conclusão do p...
software controlando mudanças;
       Fluxo de gerenciamento do produto: fornecer frameworks para gerenciamento
de projeto...
3.2.2.2 Conceitos Básicos de XP
       A Extreme Programming, também conhecido pela abreviação XP, é uma
metodologia criad...
Pequenos lançamentos (small releases) - Disponibiliza, a cada iteração, software 100%
funcional.
Metáfora - Equipes XP man...
orientadas ao cliente e baseadas em papel. Uma análise superficial nos diria que tratam a
dinâmica de desenvolvimento de s...
Capítulo 4. PROCESSO DE DESENVOLVIMENTO DE PROJETO DE SL

4.1 Práticas de gestão de Projetos pelas comunidades de SL
     ...
que estes papéis dependem muito do projeto e das pessoas envolvidas. Diferentes
projetos, com diferentes perfis, podem faz...
Líderes de Projeto - geralmente são pessoas que iniciaram um projeto de SL, porém esta
liderança pode ser repassada a outr...
Figura 7. Organização Hierárquica de uma comunidade de SL(Fonte:Via Digital)

4.1.2 Ferramentas utilizadas em projetos de ...
ferramentas para provimento de um ambiente colaborativo (integração de ferramentas
destinadas ao desenvolvimento de SL em ...
4.1.3.4 Página do projeto
        Descrição: as comunidades de SL utilizam ferramentas de apoio à comunicação,
como citada...
Todos.
         Restrições: Não há restrições de acesso a este sistema.

4.1.4.3 Sistemas de rastreamento e acompanhamento...
Os softwares e suas versões disponibilizados pelas comunidades de SL devem
estar acessíveis para download através da Inter...
servidor.
       Restrições: No lado do cliente qualquer um pode utilizar uma ferramenta deste tipo
para construção do pro...
Capítulo 5. PORTAL DO SOFTWARE PÚBLICO BRASILEIRO

5.1. Introdução
         Este portal tem como proposta facilitar a impl...
“É um software livre e público desenvolvido e utilizado pela Prototipagem Rápida
para Medicina(ProMED) para o tratamento d...
Capítulo 6. DESCRIÇÃO DA PRÁTICA DO DESENVOLVIMENTO DO
PROJETO: Sistema de Importação de dados de Clínicas Radiológicas
us...
Pequenos Lançamentos: O primeiro release será entregue em outubro de 2008. (vide
anexo D). No projeto Ufla-Invesalius plan...
6.4.4 O Cliente XP UFLA-Invesalius
       Um dos requisitos de XP é ter sempre o cliente disponível, não apenas para ajuda...
E as nossas considerações iniciais sobre as colocações da equipe UFLA, seguem abaixo:

01) O controle de código, no caso c...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSA...
Upcoming SlideShare
Loading in...5
×

UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSAS: CASO INVESALIUS

10,361

Published on

Esta monografia descreve o processo de desenvolvimento de
um projeto de software livre. Para este desenvolvimento usamos a
metodologia Extreme Programming (XP) que foi devidamente adaptada ao
processo.

Published in: Education, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,361
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
457
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSAS: CASO INVESALIUS

  1. 1. UNIVERSIDADE FEDERAL DE LAVRAS UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSAS: CASO INVESALIUS ANTONIO SÉRGIO NOGUEIRA LAVRAS MINAS GERAIS - BRASIL 2008
  2. 2. ANTONIO SÉRGIO NOGUEIRA UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSAS: CASO INVESALIUS Monografia apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras, como parte das exigências do curso de Pós-Graduação Lato Sensu em Produção de Software Livre, para a obtenção do título de especialização. Orientadora Prof. Ângela Maria Alves LAVRAS MINAS GERAIS - BRASIL 2008
  3. 3. ANTONIO SÉRGIO NOGUEIRA UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSAS: CASO INVESALIUS Monografia apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras, como parte das exigências do curso de Pós-Graduação Lato Sensu em Produção de Software Livre, para a obtenção do título de especialização. APROVADA em __ de _________ de _____. Prof. ______________________ Prof. ______________________ Prof.___________________ UFLA Ângela Maria Alves LAVRAS MINAS GERAIS - BRASIL
  4. 4. Este trabalho é especialmente dedicado à Equipe do Invesalius do Centro Tecnológico da Informação Renato Archer pelo carinho, paciência e colaboração. E também ao Portal do SOFTWARE PÚBLICO BRASILEIRO iniciativa grandiosa que beneficiará toda sociedade brasileira.
  5. 5. AGRADECIMENTOS Agradeço a Deus por me dar força para correr atrás do meu sonho e para executar este trabalho. À mamãe e ao papai que fizeram de mim um homem de respeito e que saudades deixaram com as suas partidas, que Deus lhes iluminem. À Rosângela pela compreensão que tem comigo, me perdoando das falhas e nunca deixando eu esquecer que tenho família. À Vanessa minha filha linda e adorada que será um dia uma grande mulher. Aos meus irmãos que adoro de coração. À professora e orientadora Ângela pelo carinho de seus e-mails e pela oportunidade que nos deu de participar deste grandioso projeto. Ao Corinto Meffe por atender aos pedidos da nossa querida orientadora e nos abrir as portas do Portal do Software Público Brasileiro para executar este grande trabalho. Ao pessoal do projeto InVesalius, que nos recebeu e nos orientou com grande carinho durante dois dias. Aos colegas de curso Fernando, Saulo, Flávio e Sandro por participar comigo desta empreitada. E por fim, lembrem-se todos que o mais importante nesta vida é ser feliz.
  6. 6. Sumário INTRODUÇÃO........................................................................................................................10 Capítulo 1. SOFTWARE LIVRE .............................................................................................12 1.1 Conceito..........................................................................................................................12 1.2 Histórico.........................................................................................................................12 1.3 Licenças..........................................................................................................................13 1.3.1 Licença GPL...........................................................................................................13 1.3.2 Licença BSD...........................................................................................................13 1.3.3 Outras Licenças e a GPL Brasileira (LPG-PC)......................................................14 1.4 Modelo de Desenvolvimento de Software Livre............................................................14 1.5 Comunidades de Software Livre....................................................................................14 Capítulo 2. GERÊNCIA DE PROJETOS.................................................................................16 2.1 O gerenciamento de projeto...........................................................................................16 2.2 A Engenharia do Processo..............................................................................................17 2.3 A Engenharia de Produto...............................................................................................17 2.4 PMBOK - Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. .17 Capítulo 3. PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE.............................21 ..................................................................................................................................................21 3.1 Introdução ......................................................................................................................21 3.2 Processos Tradicionais versus Ágeis..............................................................................21 3.2.1 Processo RUP.........................................................................................................21 3.2.1.1Conceitos básicos do RUP...............................................................................22 3.2.1.2 Fases do RUP..................................................................................................22 3.2.1.3 As disciplinas do RUP....................................................................................23 3.2.1.4 Fluxos do RUP................................................................................................23 3.2.2 Processo Extreme Programming (XP)....................................................................24 3.2.2.1 Processos Ágeis..............................................................................................24 3.2.2.2 Conceitos Básicos de XP................................................................................25 3.2.2.2.1 Valores....................................................................................................25 3.2.2.2.2 Princípios de XP......................................................................................25 3.2.2.2.3 Práticas de XP.........................................................................................25 3.2.2.2.4 Ciclo de Vida do XP...............................................................................26 3.2.2.2.5 Papéis envolvidos em XP........................................................................26 3.2.2.2.6 Quando não usar XP................................................................................26 3.2.3 Análise Comparativa entre XP e RUP....................................................................26 Capítulo 4. PROCESSO DE DESENVOLVIMENTO DE PROJETO DE SL........................28 4.1 Práticas de gestão de Projetos pelas comunidades de SL...............................................28 4.1.1 Participantes............................................................................................................28 4.1.2 Ferramentas utilizadas em projetos de Software Livre..........................................31 4.1.3 Comunicação..........................................................................................................32 4.1.3.1 Lista de discussões..........................................................................................32 4.1.3.2 Wiki.................................................................................................................32 4.1.3.3 Ferramentas de mensagens instantâneas ........................................................32 4.1.3.4 Página do projeto............................................................................................33 4.1.4 Apoio ao processo de desenvolvimento.................................................................33 4.1.4.1 Gerência de configuração (GC)......................................................................33 4.1.4.2 Sistemas de visualização de arquivos em repositórios...................................33 4.1.4.3 Sistemas de rastreamento e acompanhamento de mudanças (tracking systems)
  7. 7. .....................................................................................................................................34 4.1.4.4 Ferramentas de suporte ao lançamento de versões.........................................34 4.1.5 Qualidade................................................................................................................35 4.1.5.1. Ferramentas de testes automatizados.............................................................35 4.1.5.2. Ferramentas para construções do software (builds tools)..............................35 4.1.6 Colaboração e Gerência de projetos.......................................................................36 4.1.6.1. Ambiente colaborativo de desenvolvimento..................................................36 Capítulo 5. PORTAL DO SOFTWARE PÚBLICO BRASILEIRO.......................................37 5.1. Introdução......................................................................................................................37 5.2. Descrição do Portal.......................................................................................................37 5.3 O projeto InVesalius.......................................................................................................37 5.4 Demandas do Software Público Brasileiro.....................................................................38 Capítulo 6. DESCRIÇÃO DA PRÁTICA DO DESENVOLVIMENTO DO PROJETO: Sistema de Importação de dados de Clínicas Radiológicas usando XP....................................39 6.1 Objetivo do produto .......................................................................................................39 6.2 Especificação do Produto...............................................................................................39 6.3 Comunidade do SL e o Projeto UFLA-Invesalius .........................................................39 6.4 A Metodologia XP e o Projeto UFLA-Invesalius..........................................................39 6.4.1 Princípios do XP aplicado ao Projeto UFLA- Invesalius.......................................39 6.4.2 Práticas do XP aplicadas ao Projeto UFLA-Invesalius..........................................39 6.4.3 Equipe de Desenvolvimento XP ...........................................................................40 6.4.4 O Cliente XP UFLA-Invesalius..............................................................................41 6.4.5 Ferramentas Utilizadas no Projeto UFLA-Invesalius.............................................42 6.4.6 Documentação XP do Projeto UFLA-Invesalius....................................................42 6.5 A gerência de Projeto.....................................................................................................43 6.5.1 Coordenar a inicialização do projeto .....................................................................43 6.5.2 Acompanhar Projeto...............................................................................................43 6.5.3 Verificação de releases...........................................................................................43 6.5.4 Distribuir responsabilidades e Definir prioridades ................................................43 CONCLUSÃO..........................................................................................................................44 Referências Bibliográficas........................................................................................................45 Anexos......................................................................................................................................47 Anexo A: Demanda do Software Público Brasileiro................................................................48 Anexo B – Objetivo do Portal do Software Público Brasileiro................................................50 Anexo C: Especificação do Projeto Ufla-Invesalius................................................................51 Anexo D: Cronograma Projeto UFLA-Invesalius....................................................................54 Anexo E: Zoho..........................................................................................................................56 Anexo F: Metáforas..................................................................................................................57 Anexo G: Estórias do Usuário..................................................................................................63 Anexo H: Reunião via internet da equipe UFLA-Invesalius com participação da orientadora do Projeto .................................................................................................................................68 Anexo I - Documentação..........................................................................................................73 Anexo J: Documento: ESCOPO DO Ponto DICOM ...............................................................79 Anexo K: Relatório UFLA-Invesalius......................................................................................84 Anexo L:Documento: Ponto DICOM Fases da Metodologia XP ............................................88 Anexo M: ponto DICOM prototipagem das janelas ................................................................91 Anexo N: Pré- Projeto...............................................................................................................94 Anexo O: Projeto UFLA InVesalius.........................................................................................95
  8. 8. Figuras Figura 1. Relacionamento entre engenharia de processo, engenharia de produto e o gerenciamento de projeto..........................................................................................................17 Figura 2. Mapeamento entre os grupos de processos de gerenciamento de projetos................18 Figura 3. Visão geral das áreas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos ( PMBOK – 2004).....................................................................20 Figura 4. Fases do RUP.............................................................................................................22 Figura 5. Fluxos do RUP...........................................................................................................24 Figura 6. Modelo de Representação de Práticas (Fonte:Via Digital)........................................28 Figura 7. Organização Hierárquica de uma comunidade de SL(Fonte:Via Digital).................31 Figura 8. Bugzilla sendo executado no Firefox .......................................................................34 Figura 9: Cronograma Equipe UFLA-Invesalius......................................................................54 Figura 10 . Tela Inicial do ZOHO Projects...............................................................................56 Figura 11: Esboço do Sistema DICOM....................................................................................80 Figura 12. ponto Dicom receptor..............................................................................................91 Figura 13. ponto Dicom Transmissão.......................................................................................93 Figura 14. ponto Dicom importar busca...................................................................................93
  9. 9. Tabelas Tabela 1. Relação entre as áreas de conhecimento e processos do gerenciamento de projetos..............................................................................................................19 Tabela 2: Equipe UFLA Invesalius...........................................................................41 Tabela 3: Ferramentas............................................................................................42 Tabela 4: Tempo de Implementação das Estórias dos Usuários.............................77 Tabela 5: Ferramentas do Projeto...........................................................................77 Tabela 6: Equipe de Desenvolvimento....................................................................78
  10. 10. UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSAS: CASO INVESALIUS Antonio Sérgio Nogueira Departamento de Ciência e Computação – Universidade Federal de Lavras (UFLA) Caixa Postal 3142 – 37.200-000 – Lavras – MG – Brasil asergionogueira@gmail.com Abstract: This paper describes the process of developing a project for free software. For this development we used the methodology Extreme Programming (XP) which was duly adapted to the process. Resumo: Esta monografia descreve o processo de desenvolvimento de um projeto de software livre. Para este desenvolvimento usamos a metodologia Extreme Programming (XP) que foi devidamente adaptada ao processo. INTRODUÇÃO Com o objetivo de desenvolver um projeto de software livre, reuniu-se uma equipe de alunos da UFLA, através da orientadora professora Ângela Maria Alves foi feito um contato com um dos responsáveis pelo portal do Software Público Brasileiro-SPB, Corinto Meffe, e uma lista de projetos que precisavam de colaboração foi enviada para o grupo, desta lista os alunos da UFLA escolheram o projeto InVesalius, um Software Livre e Público atualmente desenvolvido e mantido pelo Centro Tecnológico de Informação CTI. Dentro das propostas do InVesalius havia 3 demandas de desenvolvimento da qual escolhemos apenas uma: SISTEMA DE IMPORTAÇÃO DE DADOS DE CLÍNICAS RADIOLÓGICAS. O projeto consiste em um módulo para o InVesalius que adicionará a funcionalidade de importar imagens diretamente de servidores PACS. Este documento tem como objetivo mostrar uma prática de gestão de projetos de Software Livre(SL) usando um processo ágil de desenvolvimento de software denominado Extreme Programming (XP) que tem se mostrado eficiente para gerenciar pequenas equipes de projetos. No desenvolvimento deste projeto participam uma equipe de alunos da UFLA (citada anteriormente), juntamente com auxílio do pessoal de desenvolvimento do Invesalius e uma aderência do portal do SPB como citado em artigo do portal:" O modelo de colaboração tem um grau de inovação significativo, pois os projetos desenvolvidos terão uma aderência direta ao Portal, possibilitando que um projeto de graduação, por exemplo, seja acompanhado pelos professores, orientadores, outros alunos e a própria comunidade. Uma outra característica é que tais projetos vão alcançar uma aderência maior com as necessidades da sociedade". [PSPB]) O desenvolvimento do projeto está presente em um repositório de projetos do Software Público Brasileiro que pode ser acessado através da Internet. Este documento 10
  11. 11. está estruturado da seguinte forma e terá sequência nas outras monografia escritas pelo grupo da UFLA que será disponibilizada pelo portal do SPB. O texto a seguir é estruturado da seguinte forma: No Capítulo 1, Software Livre o objetivo é apresentar o SL abordando seus aspectos mais importantes como: conceito, histórico, licenças de uso, modelos de desenvolvimento e comunidades. No Capítulo 2, Gerência de Projetos o objetivo é apresentar a Engenharia de Processo, A Engenharia do Produto e dar ênfase a Gerência de Projetos e as melhores práticas que devem ser aplicadas dentro das Organizações de Desenvolvimento de Software(ODS) previstas pelo Project Management Body of Knowledge (PMBOK ). No Capítulo 3, Processos de Desenvolvimento de Software o objetivo é apresentar os processos Rational Unified Process(RUP) e Extreme Programming(XP), que auxiliam no processo de produção de software com qualidade e custos reduzidos. No Capítulo 4, Processo de Desenvolvimento de Projeto de SL o objetivo mostrar uma prática de gestão de projetos de Software Livre(SL) usando metodologia XP. No Capítulo 5, Portal do Software Público Brasileiro o objetivo é apresentar o portal, seus objetivos e experiência com o seu uso. No Capítulo 6, Descrição da Prática do desenvolvimento do projeto: Sistema de Importação de dados de Clínicas Radiológicas usando XP também chamado de Ponto DICOM, o objetivo é apresentar o software Invesalius juntamente com a demanda que gerou nosso projeto, a metodologia XP aplicada ao projeto e a gerência do projeto. Finalmente a Conclusão, proposição final que se chega após desenvolvermos este projeto, relatando as dificuldades e resultados obtidos no desenvolvimento de um software através do Portal do Software Público Brasileiro. 11
  12. 12. Capítulo 1. SOFTWARE LIVRE É interessante antes de discutirmos sobre práticas de desenvolvimento usando metodologia XP e gestão do projeto, falarmos sobre SL. 1.1 Conceito Software livre é um conceito de extrema importância no mundo da computação. De forma básica, quando um software é livre, significa que seu código-fonte está disponível para qualquer um e você pode alterá-lo para adequá-lo às suas necessidades, sem ter de pagar. Portanto, software livre é de fato gratuito, mas usar este termo somente para designar softwares sem custo é um erro grosseiro. O software gratuito (freeware), por si só, é um software que você usa sem precisar pagar. Você não tem acesso ao seu código- fonte, portanto não pode alterá-lo ou simplesmente estudá-lo, somente pode usá-lo, da forma como ele foi disponibilizado. Isso deixa claro a diferença entre software livre e um software simplesmente gratuito. Software Livre, ou Free Software, conforme a definição de software livre criada pela Free Software Foundation(FSF), é o software que pode ser usado, copiado, estudado, modificado e redistribuído sem restrição. A forma usual de um software ser distribuído livremente é sendo acompanhado por uma licença de software livre (como a GPL ou a BSD), e com a disponibilização do seu código-fonte [FREES]. Software Aberto, ou Open Source, o conceito foi criado pela Open Source Initiative(OSI) e se refere ao mesmo software também chamado de software livre, ou seja, aquele que respeita as o liberdades definidas pela FSF ( usar, copiar, estudar, modifica e redistribuir sem restrição). Desta forma a diferença entre os dois está no discurso. A FSF usa "Software Livre" para um discurso baseado em questões éticas, direitos e liberdade, a OSI usa o termo "Código Aberto" sobre um ponto de vista puramente técnico, sem conflitar questões éticas, apresentando o software livre de uma forma mais agradável as corporações. [OSI] 1.2 Histórico Era hábito na década de 70, os programadores compartilhar seus softwares. Ao fim desta década as empresas, que até a presente data tinham seus lucros com a venda de hardware, descobriram que a venda de software era bem mais rentável e começaram a impor restrições aos usuários e desenvolvedores com o uso de licenças de software. Descontente com essas medidas em 1983, Richard M. Stallman criou o Projeto GNU, com o objetivo de criar um sistema operacional totalmente livre, que qualquer pessoa teria direito de usar, modificar e redistribuir, o programa e seu código fonte, desde que garantido para todos os mesmos direitos. Stallman escolheu o nome GNU porque este nome, além do significado original do mamífero GNU, é um acrônimo recursivo de: GNU is Not Unix (em português: GNU não é Unix). Vários programadores aderiram a causa e começaram a desenvolver as peças principais de um sistema operacional, editores de texto, linguiagem de programação etc. Em outubro de 1985 Richard Stallman fundou a FSF e Stallman introduziu os conceitos de software livre e copyleft, os quais foram especificamente desenvolvidos para garantir que a liberdade dos usuários fosse preservada. [FREES] O OPEN SOURCE tem sua origem na época do aparecimento da Internet. A denominação "Open Source" surgiu em fevereiro de 1998. Numa reunião que juntou personalidades como Todd Anderson, Chris Peterson, Jon Maddog Hall, Larry Augustin, Sam Ockman e Eric Raymond [WIK1]. O Open Source é um movimento que sustenta que 12
  13. 13. software livre não é algo anticapitalista ou anarquista mas sim um modelo alternativo de negócio para a indústria de software. Esta dissidência da ideologia da FSF e de sua licença GNU-GPL, foi gerada pelo incomodo deste componente social e ideologizante. Surge então o conceito de Código Aberto, que por definição não faz nenhuma referência a aspectos políticos, sociais e de liberdade. Dando assim abertura, para que sejam criadas licenças, que permitam que o código aberto seja fechado e possa ser distribuído como software proprietário. Esse movimento também acredita na eficiência econômica e técnica do modelo aberto. [OSI] 1.3 Licenças Ao falarmos de licença nos deparamos com dois tipos de propriedade intectual: o direito autoral e o direito de patentes. O direito autoral é dividido em patrimonial e moral. O patrimonial trata da negociação da obra (licenciamento, aluguel, comercialização, transferência....). No Brasil o software é protegido pelo direito autoral, válido por 50 anos, após o qual cai em domínio público. O direito moral é aquele que tem o autor de ter sempre seu nome ligado à obra (Lei no. 9606 de 1998). O direito de patente corresponde à concessão dada pelo Estado, para explorar por tempo determinado a invenção ou um processo produtivo. As leis americanas permitem ao autor do software optar por um dos dois direitos. 1.3.1 Licença GPL Nos idos de 1989, com a idéia formada do conceito de copyleft (“ Copyleft é uma forma de usar a legislação de proteção dos direitos autorais com o objetivo de retirar barreiras à utilização, difusão e modificação de uma obra criativa devido à aplicação clássica das normas de propriedade intelectual, sendo assim diferente do domínio público que não apresenta tais restrições. "Copyleft" é um trocadilho com o termo "copyright" que, traduzido literalmente, significa "direitos de copia” [WIKI]. “), foi criada, pela FSF, a licença de Software GNU GPL (General Public License), cujo objetivo era estabelecer restrições ao uso do Software Livre, pelo seu autor, e garantir as liberdades do Software Livre citadas anteriormente. As suas restrições fundamentais são: 1. garantir que todos trabalhos derivados devem ser licenciados pela GPL, e que é permitida a não distribuição das alterações realizadas no programa, desde que usadas privadamente; 2. Não é permitida a alteração das condições da licença. A GPL por outro lado incentiva o uso do Software Livre para prestação de serviços, vendas de mídias e suporte técnico como meio de auferir rendimentos. O foco do GPL é, então, a liberdade, e não a gratuidade. A FSF possui mais duas licenças Lesser General Public License-LPGL e a Free Document License-FDL. A LGPL, voltada para componentes chamados bibliotecas, libera o uso das bibliotecas para qualquer tipo de software derivado dela, com o objetivo de popularizar o uso de bibliotecas livres e não inviabilizar o software proprietário que rode em GNU. A FDL é a licença do tipo copyleft, que tem como propósito assegurar a efetiva liberdade de copiar, redistribuir, modificar ou não, comercialmente ou não, textos escritos. 1.3.2 Licença BSD É uma licença que enquadra com a filosofia do movimento código aberto, não tendo restrições ao uso do código, que pode ser utilizado para qualquer finalidade, bem como para gerar software proprietário. Suas restrições básicas são: 13
  14. 14.  Manter o copyright original na redistribuição do código fonte;  O software Xfree 86, o banco de dados PostgreSQL e o sistema TCP/IP são exemplos de licenciamentos BSD.  Colocar o copyright na documentação das versões binárias, não utilizando o nome do autor para endossar as modificações efetuadas. 1.3.3 Outras Licenças e a GPL Brasileira (LPG-PC) Existem várias outras licenças como a Mozilla Public License, a Sun Country Source License (considerada não livre, pois tem limitações de acesso ao código fontes), as licenças Creative Commons idealizadas para permitir a padronização de declarações de vontade no tocante ao licenciamento e distribuição de conteúdos culturais em geral (textos, músicas, imagens, filmes e outros). No tocante a GPL brasileira chamada de LPG-PC (Licença Pública Geral para Programas de Computadores), organizada por Pablo de Camargo Cerdeira, ela é uma adaptação da GPL às leis brasileiras. No tocante as licenças em vigor, o governo federal adotou a licença LPG-PC e a Creative Commons como padrões para desenvolvimento de seu software. 1.4 Modelo de Desenvolvimento de Software Livre No desenvolvimento do software livre em grande parte dos projetos, a equipe trabalha motivada mais pela emoção do que pela razão, com um único objetivo: desenvolver um software eficiente que atenda à necessidade meta e conquiste o maior número de usuários possível. Geralmente não existe uma preocupação quanto ao estilo de programação utilizado ou à documentação. Em geral, o desenvolvimento de um Software Livre utiliza-se de técnicas totalmente opostas às, até então vistas pelo mundo dos desenvolvedores de software. A falta de investidores para os projetos, como normalmente ocorre, livram os desenvolvedores de compromissos, que ocorrem em um projeto tradicional de desenvolvimento de software em organizações, como prazos curtos, funcionalidades pré-estabelecidas, e muitas vezes até mesmo um modelo de negócios. O código não passa por uma verificação formal ou informal, não existem os papéis do aferidor de qualidade ou outros papéis que normalmente existem em uma estrutura hierárquica empresarial. Os sistemas são testados no uso, por uma enorme comunidade que, de forma colaborativa, se dispõe a utilizá-los, encontrar erros e adicionar ou corrigir funções por conta própria, doando ao projeto seu tempo como programador [JLB]. Pode-se inferir, a partir da descrição feita acima, que o modelo de desenvolvimento do SL é Iterativo e Incremental, onde são disponibilizadas, em um curto período de tempo, novas versões do software com pequenas melhorias, que devem ser testadas e analisadas por seus usuários, que sempre influenciam na produção de uma nova versão, e que sempre que possível reaproveitam os códigos prontos, ou mesmo estudam as técnicas usadas no desenvovlimento do software utilizado como modelo. [DOP] 1.5 Comunidades de Software Livre Antes de falarmos sobre a comunidade e sua composição apresentamos aqui uma pequena lista de projetos de software livre:  KDE – Gerenciador de janelas para Linux concorrente do, também Open Source, Gnome. Disponível para download em: http://www.kde.org. 14
  15. 15.  Apache – Servidor, mais usado no mundo. Disponível para download em: http://www.apache.org.  Gimp – Editor profissional de imagens multiplataforma, concorrente do Software proprietário1 Adobe Photoshop. Disponível para download em: http://www.gimp.org.  Inkscape – Editor profissional de imagens vetoriais multiplataforma, concorrente do Software proprietário Corel Draw. Disponível para download em: http://www.inkscape.org.  Mozilla Firefox – Navegador Web multiplataforma, concorrente do proprietário Internet Explorer. Disponível para download em: http://br.mozdev.org/. As comunidades de software livre são formadas por pessoas envolvidas em um projeto, que são classificadas pelo tipo de papel que exercem detalheremos isto no Capítulo 4 - no item Participantes.[CHRI] 1 Software proprietário ou não livre é aquele cuja cópia, redistribuição ou modificação são em alguma medida proibidos pelo seu criador ou distribuidor. 15
  16. 16. Capítulo 2. GERÊNCIA DE PROJETOS 2.1 O gerenciamento de projeto O aumento cada vez maior da participação do software em nossas vidas, a globalização e seu elevado grau de competição, as mudanças e as adaptações agora presentes constantemente, trouxeram um aumento enorme na complexidade do software. Nos primórdios da informática, os programas eram pequenos, havia um único desenvolvedor e era utilizado por especialistas, atualmente as aplicações são muito diferentes e envolvem aspectos como: equipes de desenvolvimento multidisciplinares, projetos extensos, programas desenvolvidos por pessoas de fora da área de atuação do software, e ambientes que empregam diversas tecnologias. Com isto, criou-se uma grande defasagem nas técnicas de programação, o que gerou a necessidade do estabelecimento de instrumentos que permitam ao homem manipular esta complexidade cada vez crescente. Visualizando este contexto é que surge a necessidade do planejamento e do gerenciamento do software, visando estabelecer uma melhor utilização de investimentos em recursos humanos, de software e hardware com o objetivo de garantir a sobrevivência e a competitividade das ODS. Por ser um produto diferenciado (não é concreto) o software requer a adoção de novos procedimentos gerenciais e novas tecnologias, diferentes da engenharia tradicional. Surge então a engenharia de software 2 englobando várias disciplinas, visando criar e aplicar, ao processo de desenvolvimento e manutenção, métodos, procedimentos e ferramentas adequadas da engenharia para produzir software com qualidade, com previsibilidade de custo, cronogramas válidos e com produtividade. Esta tarefa árdua tem falhado. Assim, atualmente, verifica-se que o maior problema é a falta de gerenciamento. É preciso administrar e gerenciar (gerência do projeto) o projeto de software para que este seja bem conduzido de modo a obter resultados satisfatórios em termos de produtividade (engenharia do processo) e qualidade (engenharia do produto). Então podemos definir gerência de projetos como a aplicação dos conhecimentos, habilidades e técnicas para projetar tarefas que visem atingir ou exceder as necessidades e expectativas das partes envolvidas no projeto (definição do Project Management Body of Knowledge Versão 1.0 (PMBOK)). Os pontos principais na gerência de projetos consistem em fazer do gerente de projeto o elemento de integração que realiza as seguintes atividades:  Planejamento do projeto - gerar um documento que descreve as atividades, os recursos e o cronograma usado no desenvolvimento;  Seleção de Pessoal - dentro das restrições impostas como orçamento e experiência apropriada do pessoal, muitas vezes o gerente assume o papel de selecionador e treinador de pessoal;  Gerenciamento de riscos - é o gerente que deve tratar da identificação dos riscos e da preparação de planos para minimizar os efeitos deles no projeto( Identificação, análise, estratégias para evitar, estratégias para minimizar e planos de contingência);  Definição de atividades, marcos de referência e produtos entregues; 2 Termo empregado pela primeira vez na NATO 1968 - conferência para avaliar e discutir a crise de software. 16
  17. 17.  Definição do cronograma - que exige estimar esforços associados a resolução de problemas, adicionar pessoas ao projeto para não atrasar o projeto, planejar com folga, definição de tarefas adequadas aos elementos que compõe o grupo; 2.2 A Engenharia do Processo Tem como meta a definição e manutenção dos processos de empresas e organizações voltadas para o desenvolvimento de softwares. O investimento na melhoria de seus processos traz grandes benefícios para a empresa ou organização, aumentando a qualidade de seus produtos e diminuindo os esforços para produzi-los e mantê-los. Entretanto, a aplicação de um programa de melhoria de processos não é simples, pois não existe um método padronizado para a sua execução. Visando a melhoria da qualidade dos processos de desenvolvimento de software, existem diversos padrões, referências, ou modelos reconhecidos que podem ser aplicados para uma empresa ou organização, como o ISO/IEC 15504, o Capability Maturity Model Integration (CMMI), o Project Management Body of Knowledge (PMBoK) , e o Software Engineering Body of Knowledge (SWEBoK). 2.3 A Engenharia de Produto É encarregada da construção de um produto de software (codificação, verificação, testes unitários, testes de integração), da manutenção e do serviço prestado por ele. Segundo o SWEBOK, a engenharia de produto divide-se em três áreas: Fundamentos da Construção, Gerenciamento da Construção e Considerações Práticas. O relacionamento entre estes três grupos de atividades é mostrado a seguir: Figura 1. Relacionamento entre engenharia de processo, engenharia de produto e o gerenciamento de projeto Fonte: Qualidade de Software[IESQ] 2.4 PMBOK - Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos 17
  18. 18. Depois das atividades da engenharia de processo, a gerência de projeto é a primeira camada do processo de desenvolvimento de software e abrange todo seu ciclo de vida de desenvolvimento. O principal objetivo do Guia PMBOK® é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa. Ele também fornece e promove um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de projetos. Esse vocabulário padrão é um elemento essencial de uma profissão. Para abranger todas as áreas que fazem parte da gerência de projetos o PMBOK se subdividiu em cinco grupos de processos de gerenciamento de projetos, conforme abaixo: Figura 2. Mapeamento entre os grupos de processos de gerenciamento de projetos  Grupo de processos de iniciação. Define e autoriza o projeto ou uma fase do projeto.  Grupo de processos de planejamento. Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado.  Grupo de processos de execução. Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto.  Grupo de processos de monitoramento e controle. Mede e monitora regularmente o progresso para identificar variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto.  Grupo de processos de encerramento. Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.[PMBOK] Os processos do PMBOK acima estão organizados por áreas de conhecimento. Os cinco grupos de processos acima descritos podem ocorrer dentro dessas áreas de conhecimento. Existe uma interação entre os processos acima e cada um deles podem envolver o esforço de um, de mais de um ou de um grupo de indivíduos, isso depende do projeto e de sua necessidades do projeto e ocorrerem, geralmente, pelo menos uma vez em cada fase do projeto. 18
  19. 19. Tabela 1. Relação entre as áreas de conhecimento e processos do gerenciamento de projetos Gerência de integração: envolve os processos necessários (desenvolvimento, execução dos planos de projetos e controle geral de mudanças) para garantir que os vários elementos de um projeto sejam propriamente coordenados, realizando as negociações dos conflitos entre objetivos e alternativas do projeto, com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Gerência de escopo de projetos: inclui os processos requeridos para assegurar que o projeto inclua somente o trabalho necessário, para complementar de forma bem sucedida o projeto. A preocupação fundamental compreende definir e controlar o que está ou não incluído no projeto. Gerência de tempo de projetos: tem como objetivo garantir o término do projeto no tempo certo. Consiste da definição, ordenação e estimativa de duração das atividades, e de elaboração e controle de cronogramas. Gerência de custos de projetos: seu objetivo é garantir que o projeto seja executado 19
  20. 20. dentro do orçamento aprovado. Consiste no planejamento dos recursos, estimativa, orçamento e controle de custos. Gerência de qualidade de projetos: o objetivo é garantir que o projeto vai satisfazer as exigências para as quais foi contratado. Consiste de planejamento, garantia e controle de qualidade. Gerência de recursos humanos de projetos: tem como objetivo garantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste de planejamento organizacional, alocação de pessoal e desenvolvimento de equipe. Gerência de comunicação de projetos: seu objetivo principal é garantir a geração adequada e apropriada, coleta, disseminação, armazenamento e disponibilização da informação. Gerência de riscos de projetos: A gerência de risco objetiva maximizar os resultados de ocorrências positivas e minimizar as conseqüências de ocorrências negativas. Consiste de identificação, quantificação, tratamento e controle dos riscos. Gerência de aquisição de projetos: A gerência de aquisição tem como objetivo principal obter bens e serviços externos à organização executora. Consiste na seleção de fornecedores, planejamento de aquisição, planejamento de solicitação, solicitação de propostas, e administração e encerramento de contratos. Figura 3. Visão geral das áreas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos ( PMBOK – 2004) 20
  21. 21. Capítulo 3. PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 3.1 Introdução É um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. Dentro da área de Engenharia de Software é considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do Software. Um processo de software tem por objetivo final possibilitar o desenvolvimento de software com qualidade, obedecendo a prazo e orçamento determinados. [ESL1] 3.2 Processos Tradicionais versus Ágeis Apontadas como uma alternativa às abordagens tradicionais, as Metodologias ágeis têm sido usadas para o desenvolvimento de software. As metodologias tradicionais, conhecidas também como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situações em que os requisitos do sistema são estáveis e requisitos futuros são previsíveis. Em projetos em que há muitas mudanças, que os requisitos são passíveis de alterações, que refazer partes do código não é uma atividade que apresenta alto custo, que equipes são pequenas, que datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, não pode haver requisitos estáticos, é necessário então usar metodologias ágeis. Processos orientados a documentação para o desenvolvimento de software são, de certa forma, fatores limitadores aos desenvolvedores e muitas organizações não possuem recursos ou inclinação para processos pesados de produção de software. Por esta razão, as organizações pequenas acabam por não usar nenhum processo. Isto pode levar a efeitos desastrosos na qualidade do produto final, além de dificultar a entrega do software nos prazos e custos predefinidos. Em particular, o processo Rational Unified Process- RUP será apresentado como exemplo de metodologia tradicional. Dentre todas as metodologias ágeis existentes, uma que vem se destacando em número de adeptos e projetos é a Extreme Programming (XP) que abordaremos. 3.2.1 Processo RUP Criado para apoiar o desenvolvimento orientado a objetos, o Processo Unificado proposto pela Rational (uma metodologia para desenvolvimento de software criada pela Rational Software, IBM, SofTeam, Unisys, Nihon Unisys, Alcatel e Q-Labs) fornece uma forma sistemática de se obter reais vantagens no uso da Linguagem de Modelagem Unificada (UML). O RUP de fato é um processo genérico que fornece uma abordagem disciplinada para tarefas e responsabilidades do projeto para diferentes áreas de aplicação, tipos de organização, níveis de competência e tamanhos de projetos. O RUP está fundamentado em três princípios básicos: orientação a casos de uso, centrado na arquitetura, iterativo e incremental. Orientação a casos de uso: é um modelo que define o que o sistema deve fazer da perspectiva dos usuários, desta forma são criados uma série de modelos de análise, projeto e implementação; Centrado na arquitetura: defende a definição de um esqueleto para a aplicação (a arquitetura), descrevendo elementos mais importantes e uma coleção de visões dos modelos do sistema que fornece uma base sólida para construção do software, melhor compreensão do sistema e organização do desenvolvimento; Iterativo e Incremental: oferece uma abordagem para particionar o trabalho em 21
  22. 22. porções menores ou miniprojetos. As iterações referem-se a passos no fluxo de desenvolvimento, e incrementos a evoluções do produto. Possui vários benefícios como a redução do risco de custos com despesas em um único incremento, redução de riscos de atraso, reconhecimento sempre presente das necessidades do usuário e acelera o desenvolvimento porque os desenvolvedores trabalham na direção efetiva de um resultado claro.[ESL1] 3.2.1.1Conceitos básicos do RUP Baseado em conceitos cujos relacionamentos descrevem a estrutura do processo. Os principais conceitos são: Disciplina: é uma coleção de atividades relacionadas a um determinado assunto, por exemplo, testes; Fluxo de Trabalho: uma seqüência de atividades de uma disciplina que produz um resultado de valor para o projeto. Um fluxo de trabalho descreve o processo, indicando, de maneira macro, a ordem em que as atividades devem ser executadas; Detalhes do Fluxo: os detalhes do fluxo, ou sub-fluxos, auxiliam a descrição dos fluxos de trabalho. Eles mostram conjuntos de atividades que geralmente são executadas em conjunto, indicando os papéis e artefatos envolvidos; Papel: um papel define o comportamento e o conjunto de responsabilidades de um indivíduo ou de um conjunto de indivíduos que trabalham como uma equipe; Atividade: uma atividade descreve os passos a serem seguidos por um papel para prover resultados significativos para o projeto. A atividade é considerada a unidade básica de trabalho, tendo duração de poucas horas a poucos dias. Uma mesma atividade pode ser executada várias vezes em um mesmo artefato, principalmente para detalhá-lo, no decorrer de uma série de iterações; Artefato: um artefato é o produto de trabalho do processo. As atividades produzem artefatos, que irão servir de entrada para outras atividades. Documentos, modelos, o código-fonte e uma versão executável do sistema são exemplos de artefatos. 3.2.1.2 Fases do RUP Dividido em quatro fases, o ciclo de vida do projeto em cada fase possui objetivos específicos e um término onde estes objetivos são verificados. Ao final da última fase é produzida uma versão do produto, que pode evoluir e passar novamente pelas quatro fases: Concepção, Elaboração, Construção e Transição. Figura 4. Fases do RUP Concepção: tem como objetivos principais definir o escopo do projeto, identificar os casos de uso críticos para o sistema e propor uma arquitetura que os atenda. Elaboração: o objetivo é estabilizar arquitetura do sistema, dessa forma gera uma base estável ao projeto, que auxilia na próxima fase. Deve-se garantir que os requisitos e 22
  23. 23. planos estão estáveis o bastante para que se possa fazer uma estimativa segura do custo e do prazo final de conclusão do projeto. Construção: complementam-se os cenários restantes de todos os casos de uso, produzindo versões de teste do software para os usuários. Nesta fase, deve existir uma preocupação com a gestão dos recursos e com a qualidade do projeto, com o objetivo de evitar possíveis descartes ou retrabalhos desnecessários. Transição: disponibiliza a versão final do sistema no ambiente do usuário final. Isto inclui disponibilização e instalação do produto, migração de dados, caso seja necessário, treinamento dos usuários, pequenos ajustes de desempenho e correções finais de erros. Para finalizar o projeto basta a concordância dos envolvidos que o projeto está concluído. 3.2.1.3 As disciplinas do RUP Em cada fase há iterações, que são pequenos desenvolvimentos em “cascata”, onde apenas uma parte da funcionalidade do sistema é atacada, passando-se por todas as disciplinas do processo. A ênfase em cada disciplina será ditada pela fase em que o projeto se encontra. A Figura 1 mostra o relacionamento entre as fases e disciplinas do RUP. Na fase de Concepção, por exemplo, há uma grande ênfase nas disciplinas Modelagem do Negócio e Requisitos, enquanto na Construção, a ênfase nas atividades de Implementação é maior. Modelagem do negócio: entender a organização onde o sistema será implantado, desde sua estrutura e funcionamento até os problemas existentes. Requisitos: definir, em acordo com os envolvidos o que o sistema deve fazer. Análise e Projeto: transformar os requisitos definidos em uma especificação de implementação. Implementação: inclui desde a organização do código, para refletir a estrutura de subsistemas definida durante o projeto, até a codificação dos componentes. Testes: avaliar a qualidade do produto, identificando defeitos existentes e garantindo que eles serão corrigidos antes da entrega final do produto. Implantação: são as atividades relacionadas com a disponibilização do produto para seus usuários finais. Gerenciamento de Projeto: seu principal objetivo é entregar um produto que atende às necessidades do usuário, dentro do prazo e do custo planejados. Gerência de Configuração e Mudanças: tem como propósito garantir que os artefatos produzidos durante o projeto estejam sempre íntegros. Ambiente: tem como objetivo descrever as atividades necessárias para a adaptação do RUP no âmbito da organização ou de um projeto. 3.2.1.4 Fluxos do RUP Fluxo de modelagem: entendimento da estrutura e da dinâmica da organização; Fluxo de requisitos: estabelecimento e manutenção de acordos entre clientes e stakeholders, ou melhor, entendimento dos requisitos do software; Fluxo de análise & projeto: transformar requisitos em projeto, definir arquitetura robusta, adaptação do projeto ao ambiente; Fluxo de implementação: definir a organização do código; Fluxo de teste: solucionar defeitos e verificar atendimento de requisitos; Fluxo de implantação: entrega dos softwares ao usuário em sua versão final; Fluxo de gerenciamento da configuração e mudanças: mantém integridade do 23
  24. 24. software controlando mudanças; Fluxo de gerenciamento do produto: fornecer frameworks para gerenciamento de projetos, gerenciamento de pessoal, planejamento, riscos etc.. Fluxo de ambiente: foca as atividades necessárias na configuração de um processo para o projeto. Figura 5. Fluxos do RUP 3.2.2 Processo Extreme Programming (XP) O XP (programação extrema) é uma metodologia para desenvolvimento de software ágil, para equipes pequenas e médias, com qualidade e que atenda as necessidades do cliente e para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. 3.2.2.1 Processos Ágeis A partir de 1990, como parte de uma reação contra métodos tradicionais "pesados", caracterizados por uma pesada regulamentação, muitos pesquisadores e especialistas de desenvolvimento de software passaram a questionar a eficiência dos processos. Essa visão de que o modelo usado era burocrático, lento e contraditório a forma usual com que os engenheiros de software sempre realizaram trabalho com eficiência levou ao desenvolvimento de métodos ágeis e iterativos. Inicialmente, métodos ágeis eram conhecidos como métodos leves. Em 2001, membros proeminentes da comunidade se reuniram em uma estação de esqui e adotaram o nome métodos ágeis. Mais tarde, algumas pessoas formaram A Agile Alliance, uma organização não lucrativa que promove o desenvolvimento ágil. O termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que são apresentados a seguir: "Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:  Indivíduos e interação entre eles mais que processos e ferramentas  Software em funcionamento mais que documentação abrangente  Colaboração com o cliente mais que negociação de contratos  Responder a mudanças mais que seguir um plano 24
  25. 25. 3.2.2.2 Conceitos Básicos de XP A Extreme Programming, também conhecido pela abreviação XP, é uma metodologia criada por Kent Beck no final dos anos 90. O XP é composto por um pequeno conjunto de práticas, que giram em torno de alguns valores básicos e que tem Princípios que servem de ponte entre os Valores e as Práticas. 3.2.2.2.1 Valores Valores são critérios gerais e abstratos usados para justificar o que se vê, pensa ou faz. Feedback - Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado, isto é feedback. Comunicação - Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreenderem da melhor maneira possível. Simplicidade - O XP utiliza o conceito de simplicidade, fazer apenas aquilo que é claramente necessário e evitar fazer o que poderia vir a ser necessário, mas que ainda não se provou essencial. Coragem - Ao invés de frear a criatividade do cliente e evitar mudanças, equipes XP as consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção. As práticas do XP são voltadas, entre outras coisas, para proteger o software de inúmeras formas. Equipes XP confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças. 3.2.2.2.2 Princípios de XP Princípios servem de ponte entre os Valores e as Práticas. O XP define um conjunto de princípios que devem ser seguidos, que servirão para ajudar na escolha de alternativas de solução de problemas. A alternativa deve atender os princípios de forma completa. Feedback Rápido - Os envolvidos no projeto devem se comunicar sempre, para alertar rapidamente riscos, dúvidas e problemas. Assumir Simplicidade – ao fazer mudanças estas devem ser incrementais e feitas aos poucos. Abraçando Mudanças – as mudanças devem ser sempre bem-vindas, facilitando sempre o ato de inclusão de alterações através de princípios e práticas. Trabalho de qualidade – o XP trata a qualidade no sentido de se ter um sistema que atenda os requisitos do cliente. 3.2.2.2.3 Práticas de XP Constituem a estrutura a estrutura do XP. Jogo de planejamento (planning game) - Prática XP na qual se define: estimativas de prazo para cada tarefa e as prioridades: quais as tarefas mais importantes. 25
  26. 26. Pequenos lançamentos (small releases) - Disponibiliza, a cada iteração, software 100% funcional. Metáfora - Equipes XP mantêm uma visão compartilhada do funcionamento do sistema. Pode ser uma analogia com algum outro sistema que facilite a comunicação entre os membros da equipe e cliente. Projeto simples - O design está presente em todas as etapas do XP. O projeto começa simples e se mantém simples através de testes e refinamento do design. Busca-se design simples e claro. Em XP, levamos isto a níveis extremos. Testes - O seu desenvolvimento é guiado por testes, que servem de mecanismo para assegurar um sistema livre de erros. Refinamento do design (refatoramento) – Não existe uma etapa isolada de design em XP, o design é melhorado continuamente através de etapas para torná-lo mais simples e melhor estruturado. Programação em Pares – Todo o desenvolvimento em XP é feito em duplas. Um computador, um teclado e dois programadores. Melhor qualidade do design, código e testes. Posse coletiva - Em um projeto XP, qualquer dupla de programadores pode melhorar o sistema a qualquer momento. Todo o código recebe a atenção de todos os participantes resultando em maior comunicação. Menos riscos e menos dependência de indivíduos. Integração contínua – Projetos XP mantêm o sistema integrado o tempo todo. Integração de todo o sistema pode ocorrer várias vezes ao dia. Isto expõe o estado atual do desenvolvimento (viabiliza lançamentos pequenos e freqüentes). Semana de 40 horas - Ritmo saudável. Projetos com cronogramas apertados que sugam todas as energias dos programadores não são projetos XP. Semanas de 80 horas levam à baixa produtividade. Cliente no local – A participação do cliente ou pessoa que conhece o negócio. Padrões de codificação - O código escrito em projetos XP segue um padrão de codificação, definido pela equipe. Todo o código parece que foi escrito por uma única pessoa. 3.2.2.2.4 Ciclo de Vida do XP O ciclo de vida XP é bastante curto e, à primeira vista, difere dos padrões dos modelos de processo convencionais. Na fase de planejamento, os requisitos do cliente são cuidadosamente coletados à medida que são fornecidos. A seguir, os testes são elaborados a partir das especificações do cliente, e a fase de codificação é realizada visando atender esses testes. Existe uma relação próxima e contínua entre as fases de teste e codificação. E, por fim, o sistema é novamente projetado (ou reconstruído) à medida que novas funcionalidades são incorporadas. 3.2.2.2.5 Papéis envolvidos em XP Os Papéis envolvidos são: treinador, rastreador, programador, cliente, testador e consultor. Estando a cargo da gerência o papel de treinador (execução e evolução técnica do processo) e rastreador (verificar as métricas confrontando-as com as estimativas). 3.2.2.2.6 Quando não usar XP Equipes grandes e espalhadas (acima de 12 programadores) geograficamente. Situações onde não se tem controle sobre o código. Situações onde o feedback é demorado. 3.2.3 Análise Comparativa entre XP e RUP As metodologias RUP e XP têm seu funcionamento baseado em iterações, são 26
  27. 27. orientadas ao cliente e baseadas em papel. Uma análise superficial nos diria que tratam a dinâmica de desenvolvimento de software da mesma forma. Planejamento: O RUP baseia-se em 4 fases denominadas Concepção, Elaboração, Construção e Transição, que são parte do planejamento de um projeto dividido em macro planejamento (planejamento das fases) e micro planejamento ( planejamento das iterações). Já o XP está diretamente relacionado ao código, que é definido a partir de estórias elaboradas pelo cliente em cada release. Requisitos: O RUP se baseia em caso de usos para obter requisitos e o XP em estórias e utiliza o cliente no local para esclarecer requisitos. Análise e Projeto: o RUP traduz os requisitos numa especificação usada para implementar o sistema. O XP usa qualquer recurso na modelagem do projeto, desde um rascunho até diagramas UML. Implementação: O RUP constrói partes do sistema, unidades e componentes individuais testados e combinados individualmente. Já o XP o desenvolvimento é em pares e o código é constantemente refatorado e integrado. Testes: fluxo de testes são usados pelo RUP para verificar integração de componentes e interação de objetos e componentes, verificando implementação de requisitos e defeitos. No XP os testes de unidade e de aceitação são responsabilidade dos desenvolvedores e dos clientes. Implantação: O XP utiliza integração contínua, o que permite novas versões até diariamente. Já no RUP existem fases como produção, montagem, empacotamento, distribuição, treinamento, planejamento e condução de testes, migração e a aceitação formal do software. 27
  28. 28. Capítulo 4. PROCESSO DE DESENVOLVIMENTO DE PROJETO DE SL 4.1 Práticas de gestão de Projetos pelas comunidades de SL A descrição das práticas de gestão de projetos de SL está no contexto do que é feito nas comunidades de SL para gestão de seus respectivos projetos e no contexto de padrões que são seguidos por comunidades de SL. Para mostrar como um projeto de SL é gerido através de práticas, montamos um modelo de representação uniforme para mostrar cada prática identificada nos projetos de SL observados. Assim, dividimos a representação das práticas conforme a Figura abaixo. Figura 6. Modelo de Representação de Práticas (Fonte:Via Digital) Os participantes são os executores de uma determinada prática, de maneira que, obtemos os responsáveis por realizar a prática sob discussão. As ferramentas são os recursos computacionais envolvidos na execução de uma prática ou sub-prática. Na descrição da prática relatamos de maneira geral o que é feito. Esta descrição tem como propósito fornecer informações suficientes a respeito da prática numa visão de desenvolvimento voltada para a Engenharia de Software Livre. As sub-práticas consistem em atividades ou padrões utilizados em projetos de SL para mostrar como se dá a execução de uma prática. 4.1.1 Participantes Primeiro devemos avaliar quem são os participantes da Comunidade de SL, quais os papéis que podem assumir e como podem colaborar com o projeto de SL. Observamos 28
  29. 29. que estes papéis dependem muito do projeto e das pessoas envolvidas. Diferentes projetos, com diferentes perfis, podem fazer uso de um grupo grande de participantes com vários papéis definidos. Outros projetos podem fazer uso de um esquema simples de definição de papéis. Desta forma enumeramos aqui os possíveis papéis encontrados em diferentes projetos de software livre. Usuários passivos - apenas fazem uso do software e não colaboram diretamente com a comunidade, são atraídos pela qualidade e pela potencialidade de modificações que podem atender suas necessidades. Usuários ativos – diferem dos usuários passivos por ter maior participação na comunidade, não apenas fazendo download do software, mas participando de listas de discussões. Relatores de bugs – contribuem com o projeto localizando problemas e especificando-os em locais destinados a esta atividade. Corretores de bugs – fazem correções dos bugs cadastrados enviando-os para os membros do núcleo do projeto ou para desenvolvedores ativos. Desenvolvedores periféricos - São desenvolvedores que contribuem de maneira ocasional para o projeto, não são comprometidos com a comunidade. Essas pessoas e contribuem, principalmente, com implementações de funcionalidades isoladas para o projeto. Testadores – executam testes para auferir a qualidade do software, estes testes podem ser automatizados. Desenvolvedores ativos - contribuem de maneira constante para o projeto, tendo responsabilidade por grande parte do código fonte construído. Este papel é desempenhado por pessoas que têm grande conhecimento do funcionamento do projeto. Documentadores – responsáveis pelos documentos e manuais para o projeto. Estes artefatos podem fazer referência tanto ao projeto quanto à comunidade que o constrói como: manuais de utilização, instruções de instalação, configuração, apresentação das funcionalidades do software, informativos de como participar da comunidade ou contribuir com o projeto, políticas e regras utilizadas pela comunidade, padrões de codificação utilizados, etc. Tradutores - Traduzem artefatos construídos pela comunidade de SL para outros idiomas. Estes artefatos incluem: o próprio software (ênfase à internacionalização da interface com o usuário), a página de acompanhamento do projeto e a documentação pertinente ao sistema e/ou comunidade (manuais, FAQs, HOWTOs, tutoriais, regras da comunidade, etc.). Membros de núcleo – Responsáveis pela maioria do desenvolvimento, participam do projeto desde seu início, ou já possuem grande experiência nele, que pode ser obtida através do tempo e da consistência de suas interações com a comunidade. O número de membros de núcleo em um projeto não é grande (não chega a mais de dez pessoas), na maioria dos projetos. Líderes de módulos/subsistemas - Responsáveis por módulos/subsistemas do software produzido por uma comunidade. Centralizam decisões tomadas nos subsistemas do software, decidindo que alterações ou funcionalidades podem ser somadas ao subsistema. Conselheiros/Patrocinadores - Alguns projetos de SL podem ser patrocinados por empresas ou organizações externas (como a IBM e a HP, que patrocinam diversos projetos de SL). Desta maneira, membros destas entidades podem participar da comunidade como conselheiros, participando ativamente do processo de decisão dos rumos do projeto, na medida em que interesses de uma empresa podem estar envolvidos com a evolução do software. 29
  30. 30. Líderes de Projeto - geralmente são pessoas que iniciaram um projeto de SL, porém esta liderança pode ser repassada a outras pessoas, fato que pode ocorrer caso o líder de um determinando projeto não possa executar de forma satisfatória suas funções. O seu trabalho torna-se evidente quando a comunidade está organizada sob o modelo de liderança centralizada (ditador benevolente). O que o faz centralizador das decisões tomadas para a evolução do projeto. Membros de Comitê Administrativo - agem em conjunto no sentido de gerenciar a comunidade. Eles basicamente executam as mesmas funções de um líder único de projeto, no entanto dividem as responsabilidades entre si. Portanto devem existir políticas internas à comunidade para escolha destes membros e padrões para tomada de decisões na comunidade (tal como a decisão baseada em votos)[ROTH]. 30
  31. 31. Figura 7. Organização Hierárquica de uma comunidade de SL(Fonte:Via Digital) 4.1.2 Ferramentas utilizadas em projetos de Software Livre Uma das características mais marcantes em projeto de SL é o uso de um ferramental disponível na internet. Projetos de SL usam sempre um conjunto mínimo de ferramentas para prover um ambiente de interação necessário ao desenvolvimento de projetos de SL. Podemos classificar as ferramentas utilizadas em: ferramentas de comunicação, ferramentas de apoio ao processo, ferramentas de controle de qualidade e 31
  32. 32. ferramentas para provimento de um ambiente colaborativo (integração de ferramentas destinadas ao desenvolvimento de SL em um único pacote). Citaremos cada ferramenta enfatizando os seguintes aspectos: ● Descrição da ferramenta: qual a principal função da ferramenta e em que cenário são utilizadas;  Exemplos de ferramentas;  Papéis: que papéis fazem uso da ferramenta em discussão no contexto software livre;  Restrições: discute limitações de uso, acesso e regras em relação à ferramenta em discussão. 4.1.3 Comunicação 4.1.3.1 Lista de discussões Descrição: utilizados pelas comunidades baseados na captura de mensagens enviadas pelos participantes e armazenamento das mesmas. As mensagens são dispostas em forma de texto simples sem formatação e estão acessíveis através da Internet, na forma de arquivos de discussões realizadas. São as ferramentas primordiais em comunidades de SL, na medida em que podem ser usadas para diferentes finalidades: discussão de requisitos, votações, resolução de conflitos anúncios de novas versões, servir como documentação para novos usuários e desenvolvedores, etc. Exemplos: Mailman, Majordomo e SmartList Papéis que fazem uso da lista: todos Restrições: os participantes devem estar cadastrados 4.1.3.2 Wiki Descrição: WikiWeb é uma ferramenta colaborativa de edição de páginas Web, a qual é diretamente realizada através dos navegadores dos usuários. Permite que os documentos sejam editados coletivamente de forma muito simples e eficaz, através da utilização de um navegador web. A essência do sistema é permitir que qualquer um edite páginas através da Web para geração de conteúdo dinâmico. A maior vantagem do uso deste tipo de sistema está na ausência de necessidade de uso de um software no lado do cliente para edição de páginas HTML, toda esta tarefa é feita diretamente do navegador. Exemplos: TWiki, WikiWeb Papéis que fazem uso da lista: todos Restrições: Algumas wiki têm restrições. Restrições: algumas Wiki tem restrições de acesso 4.1.3.3 Ferramentas de mensagens instantâneas Descrição: é uma aplicação que permite o envio e o recebimento de mensagens de texto em tempo real, também conhecido por IM ( do inglês Instant Messenging). Várias ferramentas podem ser utilizadas como clientes de mensagens instantâneas, nas comunidades de SL a mais popular entre elas é o uso de IRC (Internet Relay Chat). Desta maneira, as comunidades mantêm canais de bate-papo em servidores de IRC onde os participantes das comunidades trocam e amadurecem idéias sobre o projeto. Exemplos de ferramentas: Meebo(http://www.meebo.com/),mIRC (http://www.mirc.com/) Pidgin(http://www.pidgin.im/) Papéis que fazem uso de mensagens instantâneas: todo Restrições: não há restrição para uso destas ferramentas e participação de conversas em canais. 32
  33. 33. 4.1.3.4 Página do projeto Descrição: as comunidades de SL utilizam ferramentas de apoio à comunicação, como citadas anteriormente, e ferramentas de apoio ao desenvolvimento, tais como um sistema de gerência de configuração. Entretanto, as páginas dos projetos tornaram-se ferramenta essencial para difundir informações pertinentes às comunidades de SL: sumário do projeto, guias para os usuários, informações sobre membros fundadores e participantes da comunidade, detalhes sobre a licença do projeto, dicas para participar da comunidade, entre outros. Exemplos de ferramentas para construção de páginas: Bluefish (http://bluefish.openoffice.nl/), Nvu (http://www.nvu.com/) Exemplos de ambientes que permitem disponibilizar páginas de projetos de SL: SourceForge (http://sourceforge.net/), CódigoLivre (http://codigolivre.org.br/) Papéis que fazem têm acesso de escrita aos arquivos das páginas do projeto: Tradutores, documentadores, membros de núcleo, líderes de subsistemas, membros, líderes de projetos, membros de comitê administrativo. Restrições: A edição do conteúdo das páginas é realizada por participantes com acesso de escrita às mesmas. O acesso à página do projeto é irrestrito. 4.1.4 Apoio ao processo de desenvolvimento 4.1.4.1 Gerência de configuração (GC) É um conjunto de atividades de apoio ao desenvolvimento que permite que as mudanças inerentes ao desenvolvimento sejam absorvidas pelo projeto de maneira controlada, mantendo a estabilidade na evolução do software, para realizar este trabalho de forma segura e consistente temos as ferramentas de gerência de configuração de um ambiente onde o desenvolvimento é dado de forma descentralizada e paralela. Nos projetos de SL a ferramenta padrão para realizar esta tarefa é o Concurrent Versions Systems(CVS), principalmente por se tratar de um sistema livre e possuir grande estabilidade e manutenção dada por sua comunidade. Exemplos de ferramentas: CVS (http://www.gnu.org/software/cvs/), Subversion (http://subversion.tigris.org/) Papéis que têm acesso de escrita ao sistema de gerência de configuração utilizado no projeto: Desenvolvedores ativos, testadores, documentadores, tradutores, membros de núcleo, líderes de módulos, líderes de projeto, conselheiros. Restrições: Apenas os participantes autorizados pela liderança, ou por papéis que exercem liderança e possuem privilégios na comunidade, podem acessar o sistema de gerência de configuração utilizado no projeto. 4.1.4.2 Sistemas de visualização de arquivos em repositórios Estes sistemas são utilizados para visualização de arquivos mantidos em repositórios de dados (como CVS e Subversion) a partir de um navegador Web, possibilitando a navegação nos diretórios presentes no repositório. Podem ser apresentadas versões específicas de arquivos, logs de alterações e diferenças entre estas versões. Este sistema possibilita o acompanhamento online de alterações efetuadas nos artefatos do projeto que estão armazenados em um repositório sob a administração de um sistema de gerência de configuração. Exemplos de ferramentas: ViewVC (http://www.viewvc.org/), CVSWeb (http://www.freebsd.org/projects/cvsweb.html),Bonsai (http://developer.mozilla.org/en/Bonsai) Papéis têm acesso ao sistema de visualização de arquivos em repositórios: 33
  34. 34. Todos. Restrições: Não há restrições de acesso a este sistema. 4.1.4.3 Sistemas de rastreamento e acompanhamento de mudanças (tracking systems) São ferramentas baseadas em Web e e-mail que dá suporte ao desenvolvimento do projeto fazendo rastreamento e acompanhamento de mudanças que são contextualizados principalmente em termos de gerência de modificações pedidas e efetuadas no software, como também no acompanhamento de defeitos encontrados e corrigidos (bugs). Estes sistemas também podem ser utilizados em processos de revisões, na medida em que permitem que anexos de arquivos sejam colocados para análise, facilitando o acesso a artefatos que estão passando por tal processo. Exemplos de ferramentas: Bugzilla (http://www.bugzilla.org/), GNATS (http://www.gnu.org/software/gnats/) Figura 8. Bugzilla sendo executado no Firefox Papéis que usam tracking systems para cadastrar bugs: Qualquer indivíduo que esteja cadastrado neste sistema (relator de bugs) ou que usem o sistema para atualização do estado de bugs, desenvolvedores ativos, tradutores, testadores, membros de núcleo, líderes de módulos, conselheiros, líderes de projeto. Restrições: o uso para cadastrar bugs só é dado a participantes cadastrados no sistema. 4.1.4.4 Ferramentas de suporte ao lançamento de versões 34
  35. 35. Os softwares e suas versões disponibilizados pelas comunidades de SL devem estar acessíveis para download através da Internet, estas versões devem, no entanto, estar em formatos que viabilizem a execução de seu download e deployment no ambiente do cliente. Para isto existem ferramentas que geram pacotes de software para diferentes plataformas operacionais, como Linux, Mac OS, Windows, BSD, entre outros. Além disso, existe a possibilidade de trabalhar com arquivos comprimidos para realizar a distribuição do projeto. Entre os tipos de formatos que estas ferramentas suportam estão: .rpm, .tar.gz, .tar.bz2, .zip, .pkg, .deb, etc. Exemplos de ferramentas: Gzip (http://www.gzip.org/), Gnu Tar (http://directory.fsf.org/tar.html), RPM (http://www.rpm.org/) Papéis têm acesso ao uso de ferramentas para empacotamento e lançamento de versões: Líderes de módulos, membros de núcleo, líderes de projeto. Restrições: O uso destas ferramentas é restrito aos papéis que têm acesso ao servidor de arquivos do projeto e podem construir arquivos para disponibilizar versões do projeto. 4.1.5 Qualidade No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento, desta forma, é comum que a busca por um software de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento. 4.1.5.1. Ferramentas de testes automatizados As ferramentas de testes permitem a execução de garantia de qualidade em produtos de software, testando consistência de código, qualidade, funcionalidade e desempenho. Realizados principalmente através do uso de frameworks para testes de unidade (tais como, JUnit, PHPUnit, CUnit), como também através de scripts automatizados de testes que podem vir juntos à distribuição do software. A utilização de testes automatizados garante que modificações efetuadas no software devam estar em concordância com tais testes. Quando é exercido um controle de qualidade rígido (o que ocorre em projetos da Apache Software Foundation), o não funcionamento dos testes escritos implica na reprovação da liberação de algum componente de software para compor o projeto. Exemplos de ferramentas: JUnit (http://junit.sourceforge.net/), CUnit (http://cunit.sourceforge.net/) Papéis usam frameworks ou scripts para testes: Testadores. Restrições: Normalmente não há restrições para o uso de frameworks ou scripts de testes, qualquer pessoa que baixe o projeto pode escrever testes para ele. 4.1.5.2. Ferramentas para construções do software (builds tools) Uma aplicação de software tem vários módulos e para atender esta integração é que temos as ferramentas de construção de software. Elas possibilitam tanto a construção automática, como viabilizam questões do lado do cliente como configurações e dependências de pacotes e bibliotecas externas, quanto do lado do servidor, para garantir que a versão esteja compilando corretamente após a efetivação de qualquer tipo de alteração no repositório de dados. Exemplos de ferramentas: Apache Ant (http://ant.apache.org/), Eclipse (http://www.eclipse.org/ ) Papéis usam ferramentas para realização de construções de software: Todos – lado do cliente. Líderes de módulo, líderes de projeto, membros de núcleo – lado do 35
  36. 36. servidor. Restrições: No lado do cliente qualquer um pode utilizar uma ferramenta deste tipo para construção do projeto. Já no lado do servidor as construções são feitas por papéis com acesso ao servidor de arquivos do projeto. Neste caso, podem ser configuradas para execuções previamente agendadas. 4.1.6 Colaboração e Gerência de projetos 4.1.6.1. Ambiente colaborativo de desenvolvimento Observamos que para integrar os atores que participam do projeto de SL e facilitar o gerenciamento de ambientes colaborativos existem ferramentas que provêem um ambiente integrado de ferramentas para comunicação, apoio ao processo de qualidade e gerência e acompanhamento de projetos como o SourceCast (utilizado para desenvolvimento de projetos do portal tigris.org e do projeto NetBeans) e o SourceForge (utilizado para suportar as comunidades do portal sourceforge.net). Desta forma, a comunidade faz uso de todas as ferramentas disponíveis em um projeto de maneira integrada e padronizada. Igualmente, estes ambientes oferecem subsistemas para gerência e acompanhamento do projeto como: número de visitas à página do projeto, número de downloads da ferramenta, quantidade de mensagens postadas nas listas de discussões, quantidades de commits realizados no repositório de dados, quantidade de entradas nos sistemas de rastreamento, entre outros. Exemplos de ferramentas: SourceCast (https://www.sourcecast.com/), SourceForge (https://sourceforge.net/) Papéis usam ferramentas de colaboração para gerenciamento/acompanhamento de projetos: Lideres de projetos. Restrições: O uso destas ferramentas requer o cadastramento de um projeto de SL, incluindo: o nome do projeto, o líder, sua descrição, sua categoria (domínio de aplicação) e sua licença. [VIAD] 36
  37. 37. Capítulo 5. PORTAL DO SOFTWARE PÚBLICO BRASILEIRO 5.1. Introdução Este portal tem como proposta facilitar a implantação de novas ferramentas nos setores administrativos do estado, divulgar, integrar e fornecer soluções livres, baseadas no bem software, para toda sociedade. O conceito software público deriva do conceito software livre e é definido por Corinto Meffe em <planejamento.gov.br> como sendo: “Os softwares públicos devem ser demandados pela sociedade ou são aqueles que o ente público, em função de seu interesse, deseja manter certo protagonismo assumindo uma comunidade. Os livres continuam sendo os softwares que obedecem às quatro liberdades: restrição de não fechar o código e o seu tripé de sustentação, licença livre, padrão aberto e comunidade. Sendo assim, os governos também poderão disponibilizar um conjunto de softwares livres e somente uma parte destas soluções será alçada como software público. Esse acréscimo de nível será determinado por um conjunto de critérios, regras e modelos. “ Desta forma o portal pode acelerar o processo de divulgação dos softwares públicos produzidos pelo estado, de forma que eles tornem-se um bem de uso geral e irrestrito pela sociedade, aplicando-lhes as principais modalidades de licenciamento associadas ao Software Livre para superar os aspectos limitadores, critérios e receios citados pelos desenvolvedores e potenciais usuários [DICA]. 5.2. Descrição do Portal O Portal do SPB surge da necessidade de compartilhar os desenvolvimentos da Administração Pública evitando sobreposição de custos compartilhando soluções e melhorando as soluções já criadas, este portal disponibiliza seus softwares para toda a sociedade. O portal disponibiliza os seguintes softwares públicos: o Coletor Automático de Configurações Computacionais (Cacic) - desenvolvido pela Dataprev, o Sisau-Saci-Contra - Ministério do Desenvolvimento Agrário, o Controle Centralizado de Administração de Rede (Cocar) – Dataprev, o Sistema de Gestão de Demandas (SGD) - Fundo Nacional de Desenvolvimento da Educação, InVesalius - Software público para área de saúde que visa auxiliar o diagnóstico e o planejamento cirúrgico - CTI Renato Archer e outros. As soluções disponibilizadas atenderão as seguintes exigências: O produto - tratar o software como um produto acabado, com documentação completa de instalação e preparado para funcionar, como outro software qualquer disponibilizado comercialmente. Os serviços associados - organização serviços básicos, tais como: página na internet, fórum e lista de discussão para desenvolvimento, suporte e projetos, ferramenta de controle de versão e a documentação existente do sistema. A prestação de serviços – fornecer e resolver as questões relacionadas ao software com a disponibilização, por parte do governo, de uma equipe de atendimento para comunidade. A gestão da colaboração - incentivo à colaboração entre os usuários e desenvolvedores da ferramenta, sejam eles pessoa física ou jurídica, de qualquer setor da economia. Estruturar instrumentos de gestão e controle rigorosos, como a periodicidade de lançamento de novas versões e os parâmetros de controle de qualidade do desenvolvimento. 5.3 O projeto InVesalius 37
  38. 38. “É um software livre e público desenvolvido e utilizado pela Prototipagem Rápida para Medicina(ProMED) para o tratamento de imagens médicas. Em 2001 não existiam softwares gratuitos de imagens médicas em português que atendessem as necessidades de hospitais e clínicas brasileiras, o que fez com que o Centro de Tecnologia de Informática Renato Archer (CTI) optasse por desenvolvê-lo. Atualmente a utilização do software cresceu - InVesalius 2 está disponível em inglês e possui mais de 800 usuários de todo mundo. Além de ser utilizado para pesquisa e prototipagem rápida de modelos cranio-faciais e ortopédicos, o software InVesalius também permite que cirurgiões representem, visualizem e interpretem as imagens obtidas com equipamentos de Tomografia Computadorizada. Isso estimula a inovação tecnológica e auxilia na formação de profissionais na área de imagens médicas, sem custos. O InVesalius importa dados de tomógrafos e aparelhos de ressonância magnética em formato DICOM e permite ao usuário visualizar imagens em duas e três dimensões, segmentar objetos de interesse, aplicar técnicas de extração de contorno e interpolação e exportar dados em formato STL. Estes recursos são de extrema utilidade no planejamento e documentação de procedimentos cirúrgicos” [INVS]. O software InVesalius está disponível para download no Portal do SPB (http://www.softwarepublico.gov.br/). 5.4 Demandas do Software Público Brasileiro Na busca de um tema de SL para desenvolvermos o Trabalho de Conclusão de Curso – TCC solicitamos um tema para nossa orientadora e prontamente nos colocou em contato com o Corinto Meffe – SPB que nos disponibilizou um documento contendo todas as demandas do Software Público Brasileiro (Anexo A). De posse do documento, a equipe da UFLA escolheu um dos temas: Sistema de Importação de dados de Clínicas Radiológicas também chamado de Ponto DICOM- Sistema de comunicação via Internet que possibilitará a importação de dados para o software InVesalius, integrando o mesmo a sistemas Clínicas Radiológicas. 38
  39. 39. Capítulo 6. DESCRIÇÃO DA PRÁTICA DO DESENVOLVIMENTO DO PROJETO: Sistema de Importação de dados de Clínicas Radiológicas usando XP 6.1 Objetivo do produto Este projeto é uma demanda do software público brasileiro que tem como principal objetivo fazer a aquisição de exames médicos através da internet, buscando esses exames em servidores Picture Archiving and Communication System – Pacs. Um sistema PACS consiste de um servidor central que armazena um banco de dados contendo imagens médicas armazenadas no formato Digital Imaging Communications- DICOM. O objetivo do Portal SPB esta descrito no anexo B. 6.2 Especificação do Produto Com o objetivo de especificar o produto a equipe de desenvolvimento do Invesalius enviou o documento de especificação do produto (Anexo C). 6.3 Comunidade do SL e o Projeto UFLA-Invesalius No projeto Sistema de Importação de dados de Clínicas Radiológicas (Demanda Invesalius) a equipe UFLA deve participar da comunidade nos níveis hierárquicos 1, 2 e 3, assumindo os papéis de Liderança, Líderes de módulo, Membros do Núcleo, Conselheiros, Desenvolvedores Ativos, Documentadores e Testadores, em cima desta participação a equipe UFLA utiliza uma Adaptação da Metodologia de Desenvolvimento de Software XP. 6.4 A Metodologia XP e o Projeto UFLA-Invesalius 6.4.1 Princípios do XP aplicado ao Projeto UFLA- Invesalius Feedback Rápido - A equipe UFLA-Invesalius faz reuniões semanais de 2a., 4a. e 6a. entre seus membros para discutir os problemas e soluções, e de 4a. e 6a. utilizamos o chat do Invesalius no Portal do SPB (chat MSN) para sanar dúvidas com a equipe de projetistas do CTI.(Anexo H) Assumir Simplicidade - A equipe UFLA-Invesalius determinou que inicialmente implemente apenas as estórias do usuário prioritárias e que estas estórias serão implementadas da forma mais simples possível sofrendo mudanças incrementais nas próximas releases. Abraçando Mudanças - Ao fazer pequenas releases a equipe UFLA-Invesalius realmente está preparada para abraçar mudanças. Trabalho de Qualidade - Estabelecer uma especificação (anexo C) do produto foi a forma de atender aos requisitos do cliente com qualidade. 6.4.2 Práticas do XP aplicadas ao Projeto UFLA-Invesalius Jogo de Planejamento - A equipe UFLA-Invesalius de posse da especificação do projeto, fez uma minuciosa análise do mesmo e preparou os casos de usuário que foram discutidos em uma reunião com o cliente CTI, desta forma um novo cronograma foi gerado para adequar o projeto (Anexo D). Antes desta especificação do cliente a equipe UFLA-Invesalius desenvolveu alguns artefatos e cronogramas iniciais que foram postados em: http://invesalius.projects.zoho.com(Anexo E) 39
  40. 40. Pequenos Lançamentos: O primeiro release será entregue em outubro de 2008. (vide anexo D). No projeto Ufla-Invesalius planejamos pequenas estórias a partir da especificação do projeto proposto(Anexo C) pelo cliente. A partir da reunião com o cliente avaliamos a especificação do cliente quanto ao projeto e ferramentas a serem utilizadas e as estórias de usuário a ser implementadas (anexo G). Metáfora: Foi disponibilizado no Zoho ( anexo E) documentos e links de software que utilizam a rede para troca de dados e de que forma isto é possível. Desta forma fizemos analogias para a compreensão de parte do sistema. (Anexo F) Projeto Simples: O sistema foi divido em 2 módulos: a parte gráfica com telas (anexo M) para interação com o usuário e a parte de comunicação do Invesalius com o Servidor PACS. Testes: O teste começa com a análise das telas de comunicação, depois de aprovadas e revisadas, será feito o teste de integração. Paralelamente temos os testes de comunicação com o servidor PACS. Refinamento do Design: Ao estabelecermos pequenas releases deixamos de lado detalhes que serão implementados posteriormente, assim teremos o refinamento do projeto. Programação em Pares: Para conseguirmos atender a este requisito a equipe foi dividida e estamos utilizando o treinador para receber o programa gerado pelos programadores e auxiliar nas suas modificações, formando assim a programação em pares. Estabelecemos que todos da equipe podem programar. Posse Coletiva: O treinador está recebendo todos os códigos e providenciando disponibilizando-os no portal SPB. Nas reuniões são discutidas as implementações e o software disponibilizado. Semana de 40 horas: Estamos adequando o desenvolvimento aos nossos horários disponíveis de tal forma a não sobrecarregar o programador, o objetivo desta prática é não sobrecarregar o programador. Integração Contínua: Esta prática só acontecerá após a primeira realease uma vez que o nosso projeto é composto basicamente de dois módulos. Cliente no local: Para atendermos está prática a equipe UFLA-Invesalius solicitou ao cliente horários de contato via chat, onde são sanadas as dúvidas. Padrão de Codificação: O treinador responsável pelo recebimento do material e armazenamento no portal revisa o código e estabelecendo os padrões. 6.4.3 Equipe de Desenvolvimento XP É composta por: Gerente, treinador, rastreador, programador, testador e cliente. Tabela 2: Equipe UFLA-Invesalius 40
  41. 41. 6.4.4 O Cliente XP UFLA-Invesalius Um dos requisitos de XP é ter sempre o cliente disponível, não apenas para ajudar a equipe mas também para ser parte dela. Embora o contato seja preferencialmente cara a cara, isso não quer dizer que o desenvolvimento de SL não tem o cliente sempre presente. Normalmente quando se desenvolve SL, o cliente é o próprio desenvolvedor no inicio do projeto. Após o software ser publicado o cliente então passa a ser toda comunidade, é a partir desse instante que várias pessoas trabalharão juntas para melhorar, mudar e corrigir o código, todos desenvolvedores/clientes, atendendo assim os Requisitos do XP. O cliente do projeto UFLA-Invesalius é a equipe de desenvolvimento do Invesalius e o Portal do SPB. A forma de comunicação entre o cliente e a equipe Ufla se dá através de CHAT, Lista do Projeto, Documentação via email e Encontro Pessoal. Documento Inicial Escopo do Projeto Via email: 2008/8/7 Corinth Meffe <Corinto.Meffe@planejamento.gov.br> Prezados Carlos Passos, Jorge Silva e Tatiana Martins, No dia 09 de julho deste ano informamos sobre o interesse dos alunos da Universidade Federal de Lavras em desenvolver um projeto final aderente as demandas do Portal do Software Público Brasileiro. No dia 25 de julho recebemos o primeiro desenho do projeto proposto pelos alunos, que trata das questões administrativas, de gestão e de definição do projeto final, para uma análise nossa e posterior envio à coordenação da solução InVesalius. Fizemos algumas breves considerações, ao final,sobre os primeiros itens técnicos apresentados pela equipe de desenvolvimento, que submetemos para análise de vocês. E aguardamos as considerações sobre o projeto apresentado pela equipe de desenvolvimento da UFLA. Pode ser realizada um análise preliminar em função do tempo e depois os ajustes podem ocorrer durante o processo de desenvolvimento, com os devidos registros das mudanças de rumo. As primeiras considerações técnicas da equipe UFLA estão na mensagem em anexo. 41
  42. 42. E as nossas considerações iniciais sobre as colocações da equipe UFLA, seguem abaixo: 01) O controle de código, no caso com o uso do SVN, deverá ser feito no próprio Portal do Software Público. Tal ação facilitará o envolvimento da coordenação técnica e da comunidade. 02) A ferramenta de desenvolvimento pode ser a proposta por vocês, desde que não exista alguma incompatibilidade técnica com o que o CenPRA (agora CTI) adota ou indica. 03) A ferramenta de Projetos também pode ser a adotada por vocês, mas nós vamos subir uma área de controle de projetos dentro do Portal. Ela será muito simplificada, servirá para controlar a data de início, a data final, pontos de controle, produtos gerados, etc.. Algo importante para registrar o comportamento dos graduandos dentro da comunidade e dar o devido destaque para os envolvidos no Projeto dentro do Portal. Solicitamos que a análise de vocês seja encaminhado primeiro para o meu correio eletrônico para fecharmos uma análise conjunta. Atenciosamente, Corinto Meffe 6.4.5 Ferramentas Utilizadas no Projeto UFLA-Invesalius Ferramentas para desenvolvimento do projeto: Tabela 3: Ferramentas Ferramenta Python 2.5.2 wxPython 2.8 Boa Constructor 0.6.1 Dcm4chee 2.0 A ferramentas utilizadas são softwares open source. Ferramentas para comunicação: Chat - Portas SPB, Messenger e Google Talk; Ferramentas de gerenciamento: Zoho Projects, Área de projetos do Portal SPB; Ferramentas para controle de versão: SVN do Portal do SPB. 6.4.6 Documentação XP do Projeto UFLA-Invesalius O uso de uma documentação muito extensa é totalmente desencorajado no XP. Encoraja-se usar padrões de códigos, que deixa o código mais legível e fácil para qualquer membro da equipe entende-lo e modifica-lo. No desenvolvimento open-source não é muito diferente; a maioria dos desenvolvedores tem pratica em fuçar o código para entender o design e nunca precisaram de muito formalismo descrevendo este. Sem contar a grande influencia das listas de discussão, de onde saem a maioria das idéias, sugestões e assim futuras implementações. No Projeto UFLA-Invesalius (Anexo O) os documentos gerados são relatórios, cronogramas, estórias de usos, telas do sistema e código disponibilizado no SVN do Portal.(Anexo I) 42

×