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

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



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
2008



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

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.

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.

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)

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

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

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

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

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

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

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

 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

 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

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

 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“É 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

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

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

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

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

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (7)

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

Ähnlich wie UMA SUGESTÃO DE METODOLOGIA DE DESENVOLVIMENTO E GESTÃO DE PROJETO DE SOFTWARE LIVRE PARA EQUIPES GEOGRAFICAMENTE DISPERSAS: CASO INVESALIUS (20)

Mehr von antonio sérgio nogueira

Mehr von antonio sérgio nogueira (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

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