uma sugestÃo de metodologia de desenvolvimento e gestÃo de projeto de software livre para equipes...

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

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

OrientadoraProf. Ângela Maria Alves


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


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árioINTRODUÇÃO........................................................................................................................10Capítulo 1. SOFTWARE LIVRE .............................................................................................12

1.1 Conceito..........................................................................................................................121.2 Histórico.........................................................................................................................121.3 Licenças..........................................................................................................................13

1.3.1 Licença GPL...........................................................................................................131.3.2 Licença BSD...........................................................................................................131.3.3 Outras Licenças e a GPL Brasileira (LPG-PC)......................................................14

1.4 Modelo de Desenvolvimento de Software Livre............................................................141.5 Comunidades de Software Livre....................................................................................14

Capítulo 2. GERÊNCIA DE PROJETOS.................................................................................162.1 O gerenciamento de projeto...........................................................................................162.2 A Engenharia do Processo..............................................................................................172.3 A Engenharia de Produto...............................................................................................172.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 ......................................................................................................................213.2 Processos Tradicionais versus Ágeis..............................................................................21

3.2.1 Processo RUP.........................................................................................................213.2.1.1Conceitos básicos do RUP...............................................................................223.2.1.2 Fases do RUP..................................................................................................223.2.1.3 As disciplinas do RUP....................................................................................233.2.1.4 Fluxos do RUP................................................................................................23

3.2.2 Processo Extreme Programming (XP)....................................................................243.2.2.1 Processos Ágeis..............................................................................................243.2.2.2 Conceitos Básicos de XP................................................................................25

3.2.2.2.1 Valores....................................................................................................253.2.2.2.2 Princípios de XP......................................................................................253.2.2.2.3 Práticas de XP.........................................................................................253.2.2.2.4 Ciclo de Vida do XP...............................................................................263.2.2.2.5 Papéis envolvidos em XP........................................................................263.2.2.2.6 Quando não usar XP................................................................................26

3.2.3 Análise Comparativa entre XP e RUP....................................................................26Capítulo 4. PROCESSO DE DESENVOLVIMENTO DE PROJETO DE SL........................28

4.1 Práticas de gestão de Projetos pelas comunidades de SL...............................................284.1.1 Participantes............................................................................................................284.1.2 Ferramentas utilizadas em projetos de Software Livre..........................................314.1.3 Comunicação..........................................................................................................32

4.1.3.1 Lista de discussões..........................................................................................324.1.3.2 Wiki.................................................................................................................324.1.3.3 Ferramentas de mensagens instantâneas ........................................................324.1.3.4 Página do projeto............................................................................................33

4.1.4 Apoio ao processo de desenvolvimento.................................................................334.1.4.1 Gerência de configuração (GC)......................................................................334.1.4.2 Sistemas de visualização de arquivos em repositórios...................................334.1.4.3 Sistemas de rastreamento e acompanhamento de mudanças (tracking systems)

.....................................................................................................................................344.1.4.4 Ferramentas de suporte ao lançamento de versões.........................................34

4.1.5 Qualidade................................................................................................................354.1.5.1. Ferramentas de testes automatizados.............................................................354.1.5.2. Ferramentas para construções do software (builds tools)..............................35

4.1.6 Colaboração e Gerência de projetos.......................................................................364.1.6.1. Ambiente colaborativo de desenvolvimento..................................................36

Capítulo 5. PORTAL DO SOFTWARE PÚBLICO BRASILEIRO.......................................375.1. Introdução......................................................................................................................375.2. Descrição do Portal.......................................................................................................375.3 O projeto InVesalius.......................................................................................................375.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 .......................................................................................................396.2 Especificação do Produto...............................................................................................396.3 Comunidade do SL e o Projeto UFLA-Invesalius .........................................................396.4 A Metodologia XP e o Projeto UFLA-Invesalius..........................................................39

6.4.1 Princípios do XP aplicado ao Projeto UFLA- Invesalius.......................................396.4.2 Práticas do XP aplicadas ao Projeto UFLA-Invesalius..........................................396.4.3 Equipe de Desenvolvimento XP ...........................................................................406.4.4 O Cliente XP UFLA-Invesalius..............................................................................416.4.5 Ferramentas Utilizadas no Projeto UFLA-Invesalius.............................................426.4.6 Documentação XP do Projeto UFLA-Invesalius....................................................42

6.5 A gerência de Projeto.....................................................................................................436.5.1 Coordenar a inicialização do projeto .....................................................................436.5.2 Acompanhar Projeto...............................................................................................436.5.3 Verificação de releases...........................................................................................436.5.4 Distribuir responsabilidades e Definir prioridades ................................................43

CONCLUSÃO..........................................................................................................................44Referências Bibliográficas........................................................................................................45Anexos......................................................................................................................................47Anexo A: Demanda do Software Público Brasileiro................................................................48Anexo B – Objetivo do Portal do Software Público Brasileiro................................................50Anexo C: Especificação do Projeto Ufla-Invesalius................................................................51Anexo D: Cronograma Projeto UFLA-Invesalius....................................................................54Anexo E: Zoho..........................................................................................................................56Anexo F: Metáforas..................................................................................................................57Anexo G: Estórias do Usuário..................................................................................................63Anexo H: Reunião via internet da equipe UFLA-Invesalius com participação da orientadora do Projeto .................................................................................................................................68Anexo I - Documentação..........................................................................................................73Anexo J: Documento: ESCOPO DO Ponto DICOM ...............................................................79Anexo K: Relatório UFLA-Invesalius......................................................................................84Anexo L:Documento: Ponto DICOM Fases da Metodologia XP ............................................88Anexo M: ponto DICOM prototipagem das janelas ................................................................91Anexo N: Pré- Projeto...............................................................................................................94Anexo O: Projeto UFLA InVesalius.........................................................................................95

FigurasFigura 1. Relacionamento entre engenharia de processo, engenharia de produto e o gerenciamento de projeto..........................................................................................................17Figura 2. Mapeamento entre os grupos de processos de gerenciamento de projetos................18Figura 3. Visão geral das áreas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos ( PMBOK – 2004).....................................................................20Figura 4. Fases do RUP.............................................................................................................22Figura 5. Fluxos do RUP...........................................................................................................24Figura 6. Modelo de Representação de Práticas (Fonte:Via Digital)........................................28Figura 7. Organização Hierárquica de uma comunidade de SL(Fonte:Via Digital).................31Figura 8. Bugzilla sendo executado no Firefox .......................................................................34Figura 9: Cronograma Equipe UFLA-Invesalius......................................................................54Figura 10 . Tela Inicial do ZOHO Projects...............................................................................56Figura 11: Esboço do Sistema DICOM....................................................................................80Figura 12. ponto Dicom receptor..............................................................................................91Figura 13. ponto Dicom Transmissão.......................................................................................93Figura 14. ponto Dicom importar busca...................................................................................93

Tabelas

Tabela 1. Relação entre as áreas de conhecimento e processos do gerenciamento de projetos..............................................................................................................19Tabela 2: Equipe UFLA Invesalius...........................................................................41Tabela 3: Ferramentas............................................................................................42Tabela 4: Tempo de Implementação das Estórias dos Usuários.............................77Tabela 5: Ferramentas do Projeto...........................................................................77Tabela 6: Equipe de Desenvolvimento....................................................................78

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

Antonio Sérgio Nogueira

Departamento de Ciência e Computação – Universidade Federal de Lavras (UFLA)Caixa Postal 3142 – 37.200-000 – Lavras – MG – Brasil

[email protected]

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 ConceitoSoftware 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óricoEra 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çasAo 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 GPLNos 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 LivreNo 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 LivreAntes 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

http://www.kde.org/

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

http://br.mozdev.org/

http://www.inkscape.org/

http://www.gimp.org/

http://www.apache.org/

Capítulo 2. GERÊNCIA DE PROJETOS

2.1 O gerenciamento de projetoO 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 software2 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 ProcessoTem 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 ÁgeisApontadas 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 RUPCriado 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 RUPBaseado 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 RUPDividido 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 RUPEm 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 RUPFluxo 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 ÁgeisA 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 XPA 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 ValoresValores 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 XPPrincí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 XPConstituem 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 XPO 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 XPOs 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 XPEquipes 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 RUPAs 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 SLA 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 ParticipantesPrimeiro 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 LivreUma 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õesDescriçã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 SmartListPapéis que fazem uso da lista: todosRestrições: os participantes devem estar cadastrados

4.1.3.2 WikiDescriçã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, WikiWebPapé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 projetoDescriçã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 queexercem 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óriosEstes 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

http://pt.wikipedia.org/wiki/E-mail

http://pt.wikipedia.org/wiki/Web

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 QualidadeNo 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 automatizadosAs 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 desenvolvimentoObservamos 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 projetosdo 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çãoEste 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 PortalO 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 BrasileiroNa 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 ProdutoCom 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- InvesaliusFeedback 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-InvesaliusJogo 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-InvesaliusUm 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 <[email protected]>

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

mailto:[email protected]

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: FerramentasFerramentaPython 2.5.2wxPython 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-InvesaliusO 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

6.5 A gerência de Projeto

6.5.1 Coordenar a inicialização do projeto Fizemos o primeiro contato com Corinto Meffe do Portal do SPB em 20/06/2008.

Neste primeiro contato foi apresentada a equipe de desenvolvimento. No dia 23/06/2008 o Sr. Corinto Meffe nos enviou os projetos que poderiam ser implementados para o portal do SPB( Anexo A). Analisamos o documento e após a decisão do tema enviamos um email ao Sr. Corinto Meffe e elaboramos um pré-projeto que enviamos a UFLA (Anexo N). Fomos prontamente atendidos pelo Sr. Corinto que nos solicitou em 09/07/2008 os seguintes dados:Quando vocês pretendem começar o projeto ?Qual a duração ?Quantas pessoas envolvidas ?Quantos orientadores ?Quais os pontos de controle para o projeto ?Em 23/08/2008 entregamos a documentação para nossa orientadora e em 25/08/2008 encaminhamos ao Sr. Corinto ( Anexo K) em 26/08/2008 estava definido o tema junto ao portal. A partir desta data o cronograma mostra os próximos passos e documentações (Anexo D).

6.5.2 Acompanhar ProjetoSão feitas reuniões semanais entre a equipe e o CTI, e só a equipe para revisar

cronogramas e apresentar trabalhos efetuados.

6.5.3 Verificação de releasesA primeira verificação ocorrerá em final no final de outubro de 2008.

6.5.4 Distribuir responsabilidades e Definir prioridades Está relatado no cronograma e na definição da equipe.

43

CONCLUSÃO

Ficou claro que realmente desenvolver softwares open sources não é praticar XP na integra, mas também ficou evidente que existe muito XP no desenvolvimento Open Source, e isso fica mais claro ainda, quando pensamos no desenvolvimento open source como uma mescla de valores e princípios, que se assemelham muito com as propostas pela metodologia XP. Ambos podem aprender muito um com o outro, e realmente há certas influências. Ficou também evidente que o gerenciamento como proposto no PMBOK teve que sofrer algumas adaptações. É importante notar que o gerenciamento do projeto de SL acontece de forma transparente ao desenvolvimento do projeto. Assim as diversas gerências se enquadram no projeto da seguinte forma:

Gerência de Recursos Humanos: definimos os elementos e suas atividades dentro do projeto, isto ocorreu durante o inicio do projeto com a definição do gerente e terminou após o envio da documentação de especificação do software pelo cliente, quando definimos os outros papéis.

Gerência de Aquisição do Projeto: esta gerência não se aplica ao projeto de software livre, desenvolvido pela comunidade e sem incentivo das grandes empresas.

Gerência de Comunicação de Projetos: para atender a esta gerência estabelecemos o software Zoho Projects que permite disponibilizar e armazenar documentos, agendar tarefas e acompanhar o projeto.

Gerência de Escopo de Projetos: para atender a esta gerência solicitamos ao cliente uma especificação do projeto e uma reunião, onde conseguimos definir o escopo real do projeto com o auxílio das estórias de usuário.

Gerência de Tempos de Projeto: utilizamos um cronograma que está sendo revisado a cada fase e está dentro do prazo estabelecido. Um projeto que conta com desenvolvedores voluntários e que não tem pressões econômicas capazes de acelerar o desenvolvimento, como garantir que metas e prazos serão cumpridos? Este é um dos grandes problemas a serem resolvidos no SL. Neste tipo de projeto que estamos engajados a equipe que participa da comunidade está reunida em torno de um trabalho em parceira com a universidade que cobra prazos e soluções, por isto que o projeto esta dentro dos prazos.

Gerência de Custos do Projeto: só se aplica quando os projetos são patrocinados por grandes empresas ou são grandes projetos que tem visibilidade e a comunidade contribui com eles. A comunidade não cobra nada pelo seu serviço de desenvolvimento.

Gerência de Qualidade: para atender o cliente a equipe desenvolve o projeto com ferramentas e especificações do cliente e utiliza testes para avaliar o produto.

Gerência de Riscos: foi feita uma avaliação da viabilidade do projeto em parceria com o cliente que já desenvolvedor do software Invesalius e já utiliza as ferramentas. Esta avaliação ocorreu quando a equipe teve contato pessoal com o CTI.

Gerência de Integração: Envolve o desenvolvimento e a execução do plano de projeto e o controle geral das mudanças, acompanhadas através do cronograma. (Anexo D).

Desta forma podemos finalizar dizendo que gestão de projetos é uma tarefa árdua e muito complexa e que abrange áreas do conhecimento humano indo da psicologia a engenharia de software. Um dos maiores desafios ainda em engenharia de software livre é engajar o indivíduo no projeto de tal forma que as metas sejam cumpridas, com a certeza que num futuro próximo podemos auferir bons resultados pelo trabalho

44

executado.

Referências Bibliográficas

[ANGE] ALVES, Ângela Maria. Introdução à Produção de Software: Software Livre / Código Aberto (SL/CA). Lavras: UFLA/FAEPE 2005.[CHRI] Caracterização de um Processo de Software para Projetos de Software Livre Christian Robottom Reis Dissertação apresentada ao Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo para a obtenção do título de Mestre em Ciências da Computação e Matemática Computacional.São Carlos, São PauloFevereiro de 2003.

[CHRI] CHRISTOPH, Roberto de Holanda. Engenharia de software para software livre / Roberto de Holanda Christoph; orientador: Julio Cesar Sampaio do Prado Leite. Rio de Janeiro: PUC, Departamento de Informática, 2004.

[DICA] DARLEN, Daniel. Materialização do Conceito de Software Público - Iniciativa CACIC. Disponível em: <http://www.dicas-l.com.br/dicas-l/20060727.php>. Último acesso em 01 ago 2008.

[DOP]Open Source Software. Disponível em http://www.comunidadeabiblia.net/tecnologia/arti-gos/open-source-software-tecnicas-de-desenvolvimento-e-modelo-de-negocios.html. Último acesso em 01 out 2008.

[ESL1] VASCONCELOS, Alexandre Marcos Lins de. Engenharia de Software para Soft-ware Livre 1. Lavras: UFLA/FAEPE, 2005.

[FREES] Free Software Foundation. Disponível em http://www.fsf.org/ . Último acesso em: 10 out 2008.

[IDBR] IDBRASIL.A economia com software livre. Disponível em: <http://www.idbrasil.gov.br/software_livre/econ_sw>. Acesso em: 29 nov 2007.

[IESQ] VASCONCELOS, Alexandre Marcos Lins de ...[ et al.]. Qualidade de Software. Lavras: UFLA, 2006.

Institute of Electrical and Electronic Engineering (IEEE). SWEBoK – Guide to the Software Engineering Body of Knowledge, 2004.

International Standards Organization (ISO). ISO/IEC 15504 Standard, 2003.

[INVS] InVesalius. Disponível em http://www.cenpra.gov.br/promed/software.htm. Último acesso 06/09/2008.

45

http://www.dicas-l.com.br/dicas-l/20060727.php

[JLB] Engenharia de Software e o Movimento open Source. Disponível em http://zeluisbraga.wordpress.com/2007/07/17/engenharia-de-software-e-o-movimento-opensource/. Último acesso em 01 out 2008.

[OSI] Open Source. Disponível em http://www.opensource.org/. Último acesso em: 15/10/2008.

[PBGT] "Este documento é parte da dissertação de mestrado de Paula Geralda Barbosa Coelho Torreão - http://www.cin.ufpe.br/~if717/leituras/artigo-gerenciamento-de-projetos-paula-coelho.pdf"

[PSPB] Portal do Software Público Brasileiro. Disponível em http://www.softwarepublico.gov.br/O_que_e_o_SPB. Último acesso em 06/09/2008.

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge, 2004.

[ROTH] Rothfuss, G. J. (2002) “A Framework for Open Source Projects”. Master thesis in Computer Science. Department of Information Technology University of Zurich. Disponível em: <http://greg.abstrakt.ch/docs/OSP_framework.pdf>.

VASCONCELOS, Alexandre Marcos Lins de. Engenharia de Software para Software Livre 1. Lavras: UFLA/FAEPE, 2005.

VIADIGITAL. Disponível em www.viadigital.org.br. Último acesso em: 15 out 2008.

[VIAD] Gestão de Projetos de Software Livre: Uma abordagem de práticas. Disponível em http://www.viadigital.org.br. Último acesso em: 01/09/2008.

[WIKI] WIKIPÉDIA.Engenharia de software . Disponível em: <http://pt.wikipedia.org/wiki/Engenharia_de_software>. Último acesso em: 01 set 2008.

[WIK1] Wikipédia. Disponível em: http://pt.wikipedia.org/wiki/Open_source. Último acesso em 01 out 2008.

46

Anexos

47

Anexo A: Demanda do Software Público Brasileiro

Documento: Soluções do Portal do Software Público Brasileiro – Documento enviado por Corinto Meffe páginas de 5 a 7.

I.2. Solução InVesalius - Software de Reconstrução 3D de Imagens MédicasDescrição:InVesalius é um software público que busca revolucionar os procedimentos cirúrgicos em hospitais brasileiros. A partir de imagens 2D de equipamentos de Tomografia Computadorizada ou Ressonância Magnética, o programa permite criar modelos virtuais 3D de estruturas anatômicas, fornecendo ao cirurgião uma visão mais clara da situação clínica de seu paciente. O programa foi desenvolvido pelo CenPRA (Centro de Pesquisas Renato Archer) através das linguagens de programação Python e C++. Atualmente opera apenas em Windows, sendo que é licenciado pela CC-GNU GPL (Licença Pública Geral) versão 2 (em português).Título 1:Descrição da solução: InVesalius - Software de Reconstrução 3D de Imagens MédicasEntidade Mantenedora: Centro de Pesquisas Renato Archer - CenPRAVersão: 2.0Data de homologação da versão atual: novembro de 2007Objetivos do Sistema:• Auxiliar no diagnóstico e planejamento cirúrgico;• Auxiliar no ensino de medicina, odontologia, buco-maxilo facial, veterinária, paleontologia, dentre outros; • Possibilitar a geração de modelos físicos de estruturas anatômicas, exportando dados em formato adequado para prototipagem rápida;• Oferecer ferramentas de computação gráfica e processamento de imagens de modo acessível a profissionais da área de saúde.Principais funcionalidades suportadas:• Reconstrução tridimensional de imagens médicas bidimensionais no formato DICOM (tomografia computadorizada / ressonância magnética);• Visualização bi e tridimensional dos dados;• Simulação de câmera endoscópica;• Segmentação de estruturas de interesse;• Manipulação e edição dos dados;• Ferramenta auxiliar a geração de relatórios para análise de casos clínicos;• Geração de malha STL usada para prototipagem rápida, a fim de fazer reconstruções físicas;Tipo de Solução: Imagens médicasQuantidade de participantes na comunidade: 395Usuários principais: Cirurgiões; Médicos; Odontologistas; Veterinários; Radiologistas; Pacientes que tenham realizado exames de tomografia computadorizada ou ressonância magnética, dentre outros.Beneficiários: Hospitais, clínicas e órgãos na área de Saúde Pública e Privada; Laboratórios radiológicos; dentre outros.Benefícios para a sociedade: Melhoria no planejamento cirúrgico; facilitação de intervenções cirúrgicas; redução de custos de internação do paciente.Demandas de Desenvolvimento:1. Sistema de Integração do InVesalius a sistemas de Prontuário Eletrônico do Paciente

48

Objeto: Sistema de comunicação via Internet que possibilitará a exportação e importação de dados de e para o software InVesalius, integrando o mesmo a sistemas de Prontuário Eletrônico do Paciente.Necessidade atendida: O software InVesalius gera muitas imagens e dados úteis no diagnóstico e planejamento cirúrgico. Entretanto, ele ainda não está integrado a sistemas de Prontuário Eletrônico do Paciente, que buscam gerenciar bancos de dados com informações clínicas de pacientes. Com o desenvolvimento do novo módulo, será possível gerar relatórios a partir do software, InVesalius exportando dados, imagens e arquivos para ferramentas de Prontuário Eletrônico. A integração do módulo ao InVesalius permitirá que o usuário tenha acesso a uma grande variedade de serviços, permitindo que os dados gerados pelo programa sejam armazenados de modo estruturado em bancos de dado e possam ser facilmente recuperados. O compartilhamento dos dados permitirá que cirurgiões fisicamente distantes possam discutir de modo mais efetivo casos clínicos complexos, contribuindo com a crescente área de Telemedicina.Benefícios para a solução: O desenvolvimento do módulo estimulará o uso do software por mais profissionais, oferecendo novas perspectivas para a área de diagnóstico médico por imagem.Benefícios indiretos: Estímulo para o desenvolvimento de empresas nacionais na área de imagens médicas.Detalhamento técnico: Construir um sistema em Python de integração e comunicação do software InVesalius a sistemas de Prontuário Eletrônicos. Os arquivos importados e exportados pelo InVesalius deverão poder ser transmitidos de e para softwares de Prontuário Eletrônico. Deverá ser empregado um protocolo adequado com padrões para sistemas de transmissão de dados médicos e registro eletrônico de saúde.Observações técnicas: O sistema deve ser desenvolvido de acordo com as especificações técnicas do Trac InVesalius. Juntamente, ele deve ser diretamente utilizável nos sistemas Linux, Mac OS X e Windows.2. Sistema de Importação de dados de Clínicas RadiológicasObjeto: 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ógicasNecessidade atendida: Atualmente, para o InVesalius gerar a reconstrução tridimensional da estrutura anatômica, é necessário que as imagens DICOM estejam armazenadas localmente no computador do usuário ou que o usuário tenha as mesmas gravadas em CD. Muitas vezes o cirurgião não tem o CD em mãos, mastem acesso via Internet à clínica onde foi gerado o exame. Tendo-se um sistema PACS (Picture Archiving and Communication Systems) de comunicação via rede para recuperação e distribuição de imagens armazenadas em clinicas radiológicas, será possível apresentar as imagens com o InVesalius e fazer a reconstrução das mesmas a distância dos arquivos originais.Benefícios para a solução: O desenvolvimento do módulo estimulará o uso do software por mais profissionais, oferecendo novas perspectivas para a área de diagnóstico médico por imagem.Benefícios indiretos: Estímulo para o desenvolvimento de empresas nacionais na área de imagens médicas.Detalhamento técnico: Construir um sistema em Python de integração e comunicação do software InVesalius a bancos de dados de clínicas radiológicas e hospitais. Os arquivos importados pelo InVesalius (DICOM) deverão poder ser trabalhados localmente pelo usuário. Deverá ser empregado um protocolo adequado com padrões para sistemas de transmissão de dados médicos e registro eletrônico de saúde.Observações técnicas: O sistema deve ser desenvolvido de acordo com as especificações técnicas do Trac InVesalius. Juntamente, ele deve ser diretamente utilizável nos sistemas Linux, Mac OS X e Windows.

49

Anexo B – Objetivo do Portal do Software Público Brasileiro

“Uma bela iniciativa nacional, do governo federal, impressiona: o Portal do Software Público Brasileiro. Esse portal iniciou com a disponibilização do sistema de inventário Cacic, desenvolvido pela Dataprev. O objetivo é o compartilhamento de soluções entre as instituições públicas, em particular as instituições de informática pública. Dessa forma, qualquer esforço de implementação de um sistema de informática pelo governo, assim que finalizasse, poderia ser disponibilizadas livremente para todas as instituições, públicas e privadas. Importante salientar também que, quando um software é disponibilizado livremente num portal com licença GPL, ele passa a contar com uma comunidade de desenvolvedores e usuários, que provêem o crescimento do software. Atualmente, o Portal do Software Público Brasileiro conta inclusive com softwares de sucesso criados por empresas privadas que preferiram disponibilizá-lo livremente para a população do que vendê-lo. Como essas empresas ganharão dinheiro? Vendendo serviços, é claro!”

(http://www.zanuz.com/2008/09/um-pouco-sobre-o-portal-do-software.html acesso em 06/10/2008)

50

http://www.zanuz.com/2008/09/um-pouco-sobre-o-portal-do-software.html acesso em 06/10/2008

http://www.zanuz.com/2008/09/um-pouco-sobre-o-portal-do-software.html acesso em 06/10/2008

http://pt.wikipedia.org/wiki/Gnu_general_public_license

http://www.softwarepublico.gov.br/ver-comunidade?community_id=3585

http://www.softwarepublico.gov.br/ver-comunidade?community_id=3585

http://www.softwarepublico.gov.br/

http://www.softwarepublico.gov.br/

Anexo C: Especificação do Projeto Ufla-Invesalius

Sistema de Importação de dados de Clínicas Radiológicasintegrado ao visualizador InVesalius 2Especificação:Eng. Tatiana Al-Chueyr Pereira Martins (1)Paulo Henrique Junqueira Amorim (1)(1) CTI - Centro de Tecnologia da Informação Renato ArcherRevisão:Versão 1 (08/08/2008)1. IntroduçãoTipicamente um sistema PACS (Picture Archiving and Communication System) consiste em um servidor PACS central que irá armazenar um banco de dados contendo imagens, e múltiplos clientes que consigam recuperar e exibir estas imagens utilizando um software de imagens médicas. As imagens são armazenadas no formato DICOM (Digital Imaging Communications). Os equipamentos do centro radiológico (RM, TC, PET, Ultrassom, ...) enviam as imagens para o Servidor PACS utilizando o “push” DICOM (DICOM C-Store). O servidor e os clientes se comunicam utilizando o protocolo DICOM (DICOM C-Store ou Query & Retrieve). O cliente exibe as imagens utilizando um visualizador de imagens médicas: um visualizador DICOM.Cada computador em uma rede PACS é identificado por seu endereço de rede (endereço IP), a porta de comunicação (porta TCP/IP) e o nome (AETitle): cada computador é um Ponto DICOM da rede PACS. O endereço IP, a porta TCP/IP e o AETitle são informações necessárias para que cada Ponto DICOM se comunique com a rede PACS.Portanto, para elaborar uma rede de comunicação PACS, é necessário:1. Servidor PACS: um computador com bastante disponibilidade de espaço em disco e um software de Servidor de PACS, como o dcm4che ou O3. O software do Servidor PACS precisa ser robusto, trabalhar sem interrupções 24 horas 7 dias por semana, ter uma ferramenta poderosa de banco de dados, e ser capaz de armazenar milhares de imagens DICOM2. Clientes PACS: um computador com um software visualizador de DICOM (InVesalius).Estes clientes PACS poderão fazer buscas e recuperar as imagens DICOM armazenadas no Servidor PACS, utilizando o protocolo de rede DICOM (DICOM C-Move, C-Store, C-Find,etc).O objetivo deste projeto é integrar projetos de software livre consolidados (InVesalius e servidor PACS livre pré-determinado) de modo que hospitais públicos, clínicas radiológicas e outras instituições possam ter uma rede PACS livre para transmissão de arquivos de imagens médicas.Espera-se que seja implementado um conjunto de ferramentas que permitam que o InVesalius comunique-se diretamente com servidores PACS para a visualização e reconstrução de imagens médicas. Denominaremos este conjunto de ferramentas a ser implementado de módulo. A seguir serão detalhadas especificações técnicas necessárias e sugestões das tarefas a serem implementadas.2. Requisitos TécnicosLinguagem de ProgramaçãoConforme determinado na especificação, Python deverá ser utilizado para o desenvolvimento do módulo em questão. Em específico, espera-se o uso do interpretador da versão 2.5.

51

Interface GráficaEspera-se que as janelas de interface gráfica sejam desenvolvidas utilizando a biblioteca wxPython através da IDE BoaConstructor.Lembrando que o código deverá ser multi-plataforma. Espera-se que o mesmo código-fonte Python possa ser executado satisfatoriamente em GNU Linux Ubuntu 8.04 e Micorsoft Windows XP. Opcionalmente em Mac OSX Leopard 10.0.5 e outras distribuições e sistemas operacionais. Sugere-se que seja utilizada a ferramenta dcm4che (http://www.dcm4che.org/) como Servidor PACS.Recomenda-se consultar o conjunto de normas do padrão de arquivo e de transmissão DICOM disponivel em ftp://medical.nema.org/medical/dicom/2008/2. Ferramentas de desenvolvimentoControle de VersãoDeverá ser utilizado o servidor SVN da Comunidade InVesalius do Portal do Software Público. Será criado um branch para o projeto em questão. Cabe a UFLA definir apenas os clientes SVN que serão utilizados.Editor de TextoCabe ao desenvolvedor da UFLA definir seu editor / IDE de preferência. A única restrição é que para a elaboração de telas de comunicação com o usuário seja utilizada a IDE BoaConstructor (software livre) de construção de interfaces gráficas utilizando wxPython. As classes de interface gráfica deverão poder ser editadas visualmente utilizando a ferramenta BoaConstructor posteriormente.3. Características Necessárias do Módulo– Transferência rápida de imagens (limitada pela banda da rede utilizada)– Armazenamento eficiente das imagens no cliente (Ponto DICOM), de modo a serem carregadas rapidamente pelo InVesalius.4. Sugestão de Execução de Tarefas de Implementação4.1. Instalação de servidor PACSSugere-se que seja utilizada a ferramenta dcm4che (http://www.dcm4che.org/) como Servidor PACS.No que diz respeito a dados para inserir em tal servidor, a equipe do projeto ProMED (Prototipagem Rápida para Medicina) do CTI pode ceder um conjunto de arquivos no formato DICOM de casos reais anonimizados.4.2. Preferências do Ponto DICOM receptorPara que ocorra a comunicação entre pontos do sistema PACS é importante haver uma ferramenta que permita ao usuário do InVesalius configurar e ver as configurações do Ponto DICOM local. Tal configuração deverá ser feita por uma janela (interface gráfica) dentro do InVesalius, utilizando as ferramentas previamente citadas.Esta janela será aberta através do menu “Preferências”, submenu “Transmissão via rede”, clicando-se sobre o item “Receptor”.Funcionalidades esperadas através desta janela:Funcionalidades / Campos CaracterísticasAETitle Será gerado um nome automático (INVESALIUS-CLIENTEXXX), mas o usuário também deverá poder alterar seu valor Endereço TCP/IP Deverá ser capturado automaticamente do computador, mas o usuário também deverá poder alterar seu valorNúmero da Porta TCP/IP Padrão: 4096 (mas deverá poder ser alterado pelo usuário)Nome Computador + DomínioExemplo: laptop.empresa.com.br. Deverá ser capturadoautomaticamente do computador, mas o usuário também deverá poder alterar seu valorVerificação de atualização Padrão: 30 segundos. Irá verificar se há novos arquivos de 30em 30 segundos.

52

Time-out de comunicação Padrão: 2 segundos. Tempo máximo para aguardar requisiçãode determinado conjunto de arquivo DICOM.Tempo de armazenamento de log Padrão: semanalmente. Tempo de armazenamento de logs contendo informações de transmissão e possíveis erros.Diretório Padrão: “/home/nome-usuario/invesalius” ou “C:\Documentsand Settings\usuario\invesalius”. Diretório onde serão armazenados localmente os arquivos.Lembrando que a janela deverá ter interface gráfica clara e limpa, com o mínimo de informações técnicas dado que o público alvo do InVesalius é leigo, de um modo geral.4.3. Preferências de transmissão do Ponto DICOM receptorPara que ocorra a comunicação entre pontos do sistema PACS é necessário configurar em cada ponto qual será o servidor DICOM central. Tal configuração deverá ser feita através de uma janela (interface gráfica) dentro do InVesalius, utilizando as ferramentas previamente citadas.Esta janela será aberta através do menu “Preferências”, submenu “Transmissão via rede”, clicando-se sobre o item “Transmissão”.Espera-se que esta janela apresente uma lista de servidores acessíveis com o endereço IP, AETitle, Porta e Descrição, permitindo sua configuração manualmente.Exemplo:AETitle Endereço Porta DescriçãoPACS_X 192.0.0.1 4445 Servidor do Hospital XPACS_Y 192.0.0.2 4444 PACS da Clinica YTambém é interessante que haja alguma ferramenta (função nesta janela) para verificar adisponibilidade dos servidores (através de testes com ping, C-Echo).4.4. Importação via rede de DICOM através do PACSA ferramenta de importação de DICOM via rede será utilizada pelos usuários do software InVesalius para consultar os dados disponíveis no servidor DICOM central. Tal ferramenta deverá conter uma janela (interface gráfica) dentro do InVesalius, utilizando as ferramentas previamente citadas.Esta janela será aberta através do menu “Arquivo”, submenu “Novo”, clicando-se sobre o item “Importar de servidor”. O objetivo dela é que ela se comunique, permitindo uma busca e seleção do exame de interesse.Recursos que devem estar disponíveis através da interface:Identificação de ServidoresAtivo AETitle Descrição EndereçoX PACS_X Servidor do Hospital X 192.0.0.1:4445PACS_Y PACS da Clinica Y 192.0.0.2:4444Termos para busca de exames em servidores:Nome do PacienteModalidade (TC, MR, US,...)Data de AquisiçãoIdadeSexoResultado da busca (conjunto de exames que obedecem a critérios estabelecidos previamente):AETitle Nome do Paciente Idade Sexo Modalidade ...PACS_X Dom Pedro 60 M RM ...PACS_X Santos Dumont 35 M TC ...

53

Anexo D: Cronograma Projeto UFLA-Invesalius

Cronograma do Projeto UFLA-Invesalius (dia 10/10/2008)

Figura 9: Cronograma Equipe UFLA-Invesalius

Artefatos gerados em cada tarefa

Explorações Iniciais 25/08 a 07/09Definição do grupo de desenvolvimentoSoluções do problema e viabilidadeConstrução do Cronograma

Curso 11/09 a 12/09 - Discussões sobre estórias de Usuário e compreensão da especificação do cliente.

Definição e revisão dos Requisitos 03/09 a 15/09

54

Escrita das Estórias

Testar o ambiente de desenvolvimento 15/09 a 18/09

Planejamento de Release 15/09 a 19/0Escolha das estórias a serem implementadasPlano de Release

Planejar Iteração 19/09 a 23/09 Escolha das estórias a serem implementadasEstimativa das estórias

Escrever Testes Funcionais 19/09 a 23/09Cenários de teste

Fazer projeto 24/09 a 08/10Os documentos do projeto em questão

Fazer Testes Funcionais 08/10 a 09/10Testes de Unidade

Planejar 2ª Iteração 10/10 a 14/10Implementar novas estórias

Escrever novos testes funcionais 10/10 a 14/10Cenários de teste

Fazer Projeto 15/10 a 29/10Documentos do projeto

Fazer Novos Testes Funcionais 29/10 a 30/10Testes de Unidade

Finalizar Versão Alfa 31/10 a 31/10Código gerado

55

Anexo E: Zoho

Para gerenciar o projeto inicialmente optamos pelo sistema de gerenciamento de projetos Zoho, disponível na Internet de forma gratuita para gerenciar um projeto. Assim que o portal SPB disponibilizar todo ferramental de gerenciamento, a documentação será transferida.

Figura 10 . Tela Inicial do ZOHO Projects

56

Anexo F: Metáforas

Tutorial de Sockets - Parte I Por: Frederico Perim ( 14/08/2001 )

O que é um Socket?

Você já deve ter ouvido falar sobre Sockets e talvez esteja imaginando do que se trata exatamente.

Bem, resumindo: através de Sockets nos comunicamos com outros programas usando discritores de arquivos Unix padrão. O que? Tudo bem. Você deve ter ouvido algum guru em Unix dizer,"Tudo no Unix é um arquivo!". O que esta pessoa esta querendo dizer, na verdade, é o fato de que quando sistemas Unix realizam qualquer tipo de E/S(Entrada/Saída), eles o fazem lendo ou escrevendo através de um descritor de arquivo. Um descritor de arquivo é simplesmente um inteiro associado a um arquivo aberto. Mas(e aqui está o detalhe), este arquivo pode ser uma conexão de rede,um FIFO, um pipe, um terminal, um arquivo no disco, ou qualquer outra coisa. Tudo no Unix(Linux) é um arquivo!.Assim quando você quiser se comunicar com outro programa na internet você vai usar um descritor de arquivo. A partir dai, você realiza chamadas de socket send() e recv().

"Mas, peraí!", você deve estar pensando. "Se é um descritor de arquivo, porque não usar as chamadas read() e write() para se comunicar através de um Socket?"a resposta é,"Você pode!"a resposta completa é,"Você pode, mas send() e recv() oferecem melhor controle sobre a transmissão de dados".

"Tá bom, e daí?"Que tal isto: existem vários tipos de Sockets.Tem o DARPA(Sockets de Internet), Sockets Unix, CCITT X.25 e provavelmente outros dependendo da sua versão Unix. Este artigo abordará somente o primeiro: Sockets de Internet.

Dois Tipos de Sockets

O que é isto? Existem dois tipos de Sockets de Internet? Sim. Bem,na verdade não.Tem mais, mas não quero assustá-lo. Irei abordar apenas dois tipos.O primeiro é o "Stream Sockets", o outro "Datagram Sockets", que a partir de agora serão chamados de "SOCK_STREAM" e "SOCK_DGRAM", respectivamente. Os "Datagram Sockets" também são conhecidos como sockets sem conexão, embora você possa usar a chamada connect().

Os "Stream Sockets" são fluxos de comunicação confiáveis. Se você enviar 2 itens na ordem "1,2", eles irão chegar chegar na ordem "1,2" no outro extremo do link.Eles também são livres de erros. Qualquer erro que você encontrar é apenas ilusão da sua mente :-).

O que realmente utiliza um "Stream Socket"? Você já deve ter ouvido falar no programa Telnet. Pois bem, todos os caracteres que você digita precisam chegar na mesma ordem em que você os digitou logo este aplicativo consegue isto através de "Stream Sockets".Além disso os browsers, que utilizam o protocolo HTTP, usam "Stream Sockets" para receber páginas.

Como os "Stream Sockets" conseguem este alto grau de qualidade de transmissão de dados? Eles utilizam um protocolo chamado "Protocolo de Controle de Transmissão", mais conhecido como "TCP". TCP assegura que os dados chegarão sequencialmente e livres de erros. Você deve ter ouvido falar que TCP é a melhor metade do TCP/IP, onde IP significa Protocolo de Internet. IP cuida basicamente do roteamento e não é responsável pela integridade dos dados.

Legal. E os "Datagram Sockets"? Porque são conhecidos como sem conexão? Porque não são confiáveis? Bem, alguns fatos: Se você enviar um datagrama, ele pode chegar. Ele pode chegar fora

57

mailto:[email protected]

de ordem. Se chegar , os dados contidos no pacote estarão livres de erros.

"Datagram Sockets" também usam o IP para roteamento, mas eles não utilizam TCP, e sim o "UDP".

Porque são sem conexão? Bem , basicamente devido ao fato de você não precisar manter uma conexão aberta como os "Stream Sockets". Você constrói um pacote, anexa um cabeçalho IP com informações de destino, e envia. Não precisa haver conexão. Ele são mais utilizados para transferências pacote por pacote de informações. Alguns aplicativos que utilizam UDP: tftp, bootp,etc.

"Chega!", você diz. "Como estes programas funcionam se um pacote pode se perder na rota?"Bem, meu caro amigo, cada um tem se próprio protocolo acima do UDP. Por exemplo, o protocolo tftp diz que para cada pacote que é enviado, o receptor tem que enviar um pacote de volta que diz, "Eu recebi!"(um pacote "ACK") Se o emissor do pacote original não receber uma resposta, digamos, em cinco segundos , ele irá retransmitir o pacote até que receba um "ACK". Este procedimento é muito importante quando você for implementar aplicações que utilizam "SOCK_DGRAM".

Alguma Teoria de Rede

Já que mencionei algumas camadas de protocolos, é hora de falar como as redes realmente funcionam, e mostrar alguns exemplos de como pacotes SOCK_DGRAM são construídos. Você pode pular esta parte se não estiver interessado.

É hora de aprender sobre Encapsulamento de Dados. Isto é muito importante. Basicamente, é isto: um pacote é criado, o pacote é empacotado("encapsulado") em um cabeçalho pelo primeiro protocolo (digamos, o protocolo TFTP), então tudo (cabeçalho TFTP incluído) é empacotado novamente pelo próximo protocolo (por exemplo, UDP), novamente pelo próximo (IP) , e então finalmente pelo último protocolo no hardware(camada física) , por exemplo Ethernet.

Quando outro computador receber o pacote, o hardware retira o cabeçalho Ethernet, o kernel retira os cabeçalhos IP e UDP, e o programa TFTP retira o cabeçalho TFTP, e finalmente se tem os dados.

Agora finalmente posso falar sobre o temível Modelo de Camadas de Rede. Este modelo descreve um sistema de funcionalidade de rede que tem muitas vantagens sobre outros modelos. Por exemplo, você pode escrever programas de sockets que não se importam como os dados são fisicamente transmitidos (serial, thin ETHERNET,AUI, seja lá o que for) porque programas nos níveis mais baixos tomam conta disto pra você.

O hardware de rede e a topologia são transparentes para o programador.

Bem sem mais enrolação, irei apresentar o modelo completo:

• Camada de Aplicação (Application Layer) • Camada de Transporte (TCP,UDP) • Camada de Internet (IP) • Camada de Acesso de Rede (Ethernet, ATM)

Nesse momento você provavelmente deve estar imaginando como estas camadas correspondem ao encapsulamento dos dados.

Veja quanto trabalho para construir um simples pacote? E você ainda tem que digitar os cabeçalhos do pacote usando "cat"!. Brincadeirinha. Tudo que você tem que fazer para utilizar "Sockets Streams" é enviar (send()) os dados. Com relação aos "Sockets Datagram" é empacotar os pacotes num método de sua escolha e enviar(sendto()) os dados. O kernel constrói a Camada de Transporte e a Camada de Internet pra você e o hardware cuida das camadas mais baixas.

58

Bem aqui termina nossa breve introdução em teoria de redes. AH, esqueci de mencionar alguma coisa sobre roteamento: nada! Isso mesmo , não irei falar sobre isso. O roteador retira o cabeçalho IP, consulta a tabela de roteamento , etc,etc.

Estruturas e Manipulação de Dados

Bem finalmente é hora de falar sobre programação. Nesta parte , vou cobrir alguns tipos de dados usados pelas interfaces de sockets, já que algumas são um pouco complicadas.

Primeiro a mais fácil: um descritor de socket. O descritor de socket é do seguinte tipo:

int Apenas um simples int.

As coisas começam a se complicar daqui em diante, então vamos lá. Saiba isto: existem dois tipos de ordenamentos de byte: primeiro byte mais significante(também chamados de "octeto"), e primeiro byte menos significante, chamado de "Network Byte Order". Algumas máquinas armazenam números internamente em Network Byte Order, algumas não. Quando digo que algo deve estar em "Network Byte Order", você tem que chamar uma função (htons()) para mudar de "Host Byte Order". Se não for dito "Network Byte Order" , então você pode deixar como "Host Byte Order".

A primeira estrutura contém informações sobre tipos de sockets:strut sockaddr {

unsigned short sa_family; // tipo de endereço, AF_xxx

char sa_data[14]; // 14 bytes do endereço de protocolo

};sa_family pode ser uma variedade de coisas, mas será AF_INET para tudo que fizermos neste documento. sa_data contém um endereço de destino e número de porta para o socket. Isto é um tanto confuso, já que não queremos empacotar o endereço sa_data manualmente.

Para tratar de strut sockaddr, programdores criaram uma estrutura paralela: struct sockaddr_in("in" para "internet")struct sockaddr_in {

short int sin_family; // tipo de endereço

unsigned short int sin_port; //Número da porta

struct in_addr sin_addr; //Endereço da Internet

unsigned char sin_zero[8]; //Mesmo tamanho de struct sockaddr

};Esta estrutura torna mais fácil referenciar elementos de um endereço de socket. Note que sin_zero (que é incluído para acomadar a estrutura ao tamanho de struct sockaddr) deve ser setada para zeros através da função memset(). Ainda, e isto é muito importante, um ponteiro para um struct sockaddr_in pode ser convertido para um struct sockaddr e vice-versa. Assim mesmo que socket() queira um struct sockaddr*, você pode ainda usar um struct sockaddr_in e converter no momento apropriado. Note também que sin_family corresponde a sa_family em strutct sockaddr e deve ser setado para "AF_INET". Finalmente ,sin_port e sin_addr devem estar em "Network Byte Order".

59

"Mas um momento! Como pode toda estrutura, struct in_addr sin_addr, estar em Network Byte Order?" Esta questão requer uma análise cuidadosa da estrutura struct in_addr :// Endereço de Internet

struct in_addr {

unsigned long s_addr;

};

Então se você declarou ina para ser do tipo struct sockaddr_in, então ina.sin_addr.s_addr referencia um endereço IP de 4 bytes (em "Network Byte Order").

Convertendo Valores

Houve muito falatório sobre conversão para Network Byte Order. Agora é hora de ação!

Tudo bem. Existem dois tipos que você pode converter: um short de Host Byte Order para Network Byte Order. Comece com "h" para "host", seguindo com "to", e então "n" para "network", e "s" para "short" : h-to-n-s ou htons() ( leia-se: "Host to Network Short").

Nem é tão difícil assim...

Você pode usar combinações de "n", "h", "s" e "l" que quiser, sem contar as estúpidas. Por exemplo , não existe uma função stolh() ("Short to Long Host") - pelo menos não aqui. Mas existem :

• htons() -- "Host to Network Short" • htonl() -- "Host to Network Long" • ntohs() -- "Network to Host Short" • ntohl() -- "Network to Host Long"

Agora, você deve estar começando a entender. Você pode pensar, "O que eu faço para mudar a ordem de byte em char?" Então você pensa , "Deixa pra lá". Você também deve imaginar que sua máquina 68000 já usa "Network Byte Order" , e não precisa chamar htonl() no seus endereços IP. Você estaria certo, MAS se você tentar portar para uma máquina que tem ordem de byte de rede reverso seu programa não vai rodar. Tente escrever programas portáveis a outras arquiteturas! Este é um mundo Unix (Linux). Lembre-se: pode seus bytes em Network Byte Order antes de botá-los na rede.

Uma último esclarecimento: porque sin_addr e sin_port precisam estar em Network Byte Order em um struc sockaddr_in, mas sin_family não? A resposta: sin_addr e sin_port são encapsulados no pacote nas layers IP e UDP, respectivamente. Assim, eles devem estar em Network Byte Order. No entanto, o campo sin_family não é enviado pela rede, ele pode estar em Host Byte Order.

Endereços IP e como Lidar com eles

Felizmente para você , existem várias funções que te permitem manipular endereços IP. Não é necessário tratá-los manualmente e colocá-los em um long com um operador <<.

Primeiro , digamos que você tem um endereço IP "10.12.110.57" e deseja armazená-lo em um struct sockaddr_in ina. A função que você deseja usar , inet_addr(), converte um endereço IP na notação de números e pontos em um unsigned long. A forma é a seguinte:

ina.sin_addr.s_addr = inet_addr("10.12.110.57");Note que int_addr() retorna o endereço em Network Byte Order, você não precisa chamar htonl().

60

Beleza!!!

Agora, o código acima não é muito robusto porque não existe checagem de erro. inet_addr() retorna -1 em caso de erro. Lembra de números binários? (unsigned) -1 corresponde ao endereço IP 255.255.255.255! Este é o endereço de broadcast!. Lembre-se de checar erros apropriadamente.

Na verdade , há uma forma interface melhor que inet_addr(): é chamada inet_aton() ("aton" significa "ascii to nerwork");

int inet_aton(const char *cp , struct in_addr *inp);E aqui está um exemplo prático: este exemplo fará mais sentido quando abordamos bind() e connect()!!struct sockaddr_in meu_end;

meu_end.sin_family = AF_INET; //host byte order

meu_end.sin_port = htons(MYPORT); //short, network byte order

inet_aton("10.12.110.57", &(meu_end.sin_addr));

memset(&(meu_end.sin_zero), ' \0' , 8); // zera o resto daestruturainet_aton, diferente de praticamente todas as outras funções relacionadas a sockets, retorna um número diferente de zero em caso de sucesso, e zero caso contrário ( Se alguém souber porque , me diga) E o endereço é passado de volta em inp.

Infelizmente , nem todas plataformas implementam inet_aton() assim , embora seu uso seja recomendado, a função inet_addr() será usada neste artigo.

Tudo bem, agora você pode converter um string de endereço IP em suas representações binárias. E a forma inversa? E se você tem um struc in_addr e quer mostrar na notação de pontos e números? Neste caso , você terá que usar a função inet_ntoa() ("ntoa" significa "network to asscii") da seguinte forma:

printf ("%s", inet_ntoa(ina.sin_addr));Isto irá mostrar o endereço IP. Note que inet_ntoa() tem um struct in_addr como argumento, não um long. Note também que ela retorna um ponteiro para um char. Isto aponta para um array estaticamente armazenado em inet_ntoa() assim toda vez que você chamar inet_ntoa() ela irá sobrescrever o último endereço IP que você chamou. Por exemplo:char *a1, *a2;////a1 = inet_ntoa(ina1.sin_addr); isto é 192.168.4.14a2 = inet_ntoa(ina2.sin_addr); isto é 10.14.110.60printf ("endereço 1: %s\n", a1);printf("endereço 2: %s\n", a2);a saída é:endereço 1: 10.14.110.60endereço 2: 10.14.110.60Se você precisar salvar o endereço, use strcpy() em seu próprio array de caracteres.

Conclusão

No próximo artigo desta série nos aprofundaremos nas chamadas de sistemas e portas desconhecidas, como o caso do Bind. Até lá!

61

Arquivo original em: http://www.ecst.csuchico.edu/~beej/guide/net/

62

http://www.ecst.csuchico.edu/~beej/guide/net/

Anexo G: Estórias do Usuário

HISTÓRICO DE ALTERAÇÕES

Versão Data Alteração Responsável Descrição

1.0 03/09/2008 Equipe UFLA Versão Inicial

INTRODUÇÃO

Este documento descreve os “User Stories” necessários aos desenvolvedores as para a execução e implementação do projeto o modulo de comunicação do InVesalius com servidores PACS, que adicionará a funcionalidade de importação de dados para o InVesalius. Os “User Stories” foram divididos em 5 temas sendo eles:

• Ponto DICOM Receptor • Ponto DICOM Transmissão • Ponto DICOM Importar • Ponto DICOM Log de Comunicação • Ponto DICOM Exportar

USER STORIES

TEMA 1: Ponto DICOM Receptor

<01>

Criação da janela do Ponto DICOM Receptor

Prioridade Estimativa Nome do teste janPDR

Criação de uma janela mostrando para o usuário os seguintes campos: • AETitle • TCP/IP • Número da porta do TCP/IP • Nome Computador + Domínio • Verificação de atualização • Time-out de comunicação • Tempo de armazenamento de log • Diretório

Essa janela estará disponível a partir do MENU: PREFERÊNCIAS→TRANSMISSÃO VIA REDE→RECEPTOR

63

Estes dados também poderão ser modificados pelo usuário e deverá haver ajuda para todos os campos. As configurações ficarão salvas em um arquivo.

<02>

Identificação de informações do computador local

Prioridade Estimativa Nome do teste InfoCompLocal

Identifica a configuração do computador local e informa ao usuário na janela do US<01>, sendo que a preferência de certos campos são dada pelo arquivo salvo com as modificações feita pelo usuário anteriormente. Abaixo é mostrado os dados que são pegos no computador local, os dados com um * na frente, são os que tem como o arquivo salvo no computador como prioritário.

• *AETitle • TCP/IP • Número da porta do TCP/IP • Nome Computador + Domínio • *Verificação de atualização • *Time-out de comunicação • *Tempo de armazenamento de log • *Diretório (Onde o invesalius setará corretamente o endereço do diretório que

armazenará os arquivos, Padrão no Linux: “/home/nome-usuario/invesalius” e Padrão no Windows: “C:\Documents and Settings\usuario\invesalius”).

Obs.: Na primeira execução do InVesalius, deverá ser criado um arquivo com estes dados.

<03>

Limpeza do arquivo de log

Prioridade Estimativa Nome do teste LimpArqLog

O arquivo de log deverá ser verificado e limpo conforme o número de semanas definido na tela de definição do Ponto DICOM Receptor no US<01>.

<04>

Salvar Configuração

Prioridade Estimativa Nome do teste SalConf

Ao clicar em "OK" na janela do ponto DICOM receptor no US<01> haverá uma verificação se houve alteração das configurações e se houver, armazena as novas configurações para que o InVesalius possa utilizá-las. TEMA 2: Ponto DICOM Transmissão

64

<05>

Criação de janela do Ponto DICOM Transmissão

Prioridade Estimativa Nome do teste janPDT

Criação de uma janela que permita adicionar, remover e alterar informações usadas para acesso aos servidores PACS, os seguintes campos são necessários:

• AETitle • Endereço TCP/IP • Porta TCP/IP • Descrição • Lista de Servidores • Campos de autenticação (Usuário e Senha)

Essa janela estará disponível a partir do MENU: PREFERÊNCIAS→TRANSMISSÃO VIA REDE→TRANSMISSÃO O usuário poderá acrescentar novos servidores, sendo que os campos Endereço e Porta TCP/IP são campos obrigatórios. Caso algum servidor necessite de autenticação o usuário já poderá fornecer quando acrescentar servidor.O usuário poderá selecionar um servidor da "Lista de Servidores" e utilizar as opções REMOVE ou ALTER para remover ou alterar algum servidor. O usuário poderá clicar em C-ECHO para verificar se os servidores estão disponíveis.Os configurações ficarão salvas em um arquivo.obs: O botão ADD mudará para ALTER caso o usuário clique em um dos servidores da lista.

<06>

Verificar status dos servidores

Prioridade Estimativa Nome do teste VerStatusServ

Emite um comando, para cada servidor, para saber o status do mesmo.

TEMA 3: Ponto DICOM Importar

<07>

Criação da janela do ponto DICOM Importar busca

Prioridade Estimativa Nome do teste janPDIbusca

Criação de uma janela que permitirá ao usuário fazer uma busca nos servidor PACS, a busca pode ser feita utilizando um dos campos pré definidos:

• AETitle

65

• Nome do Paciente • Modalidade • Idade • Sexo • Data de Aquisição

Essa janela estará disponível a partir do MENU:NOVO→ BUSCA NO SERVIDOR O usuário pode escolher que tipo de busca deseja fazer no servidor PACS, escolhendo entre informações do Paciente, Estudo, Series, Equipamento, Referência do Frame e da Imagem. Os dados retornados são listados na tabela de RESULTADO onde o usuário poderá selecionar qual Imagem deseja abrir no InVesalius.Para importar a imagem no InVesalius o usuário deve clicar sobre a informação no tabela resultado e clicar na opção OK.

<08>

Conectar ao servidor PAC

Prioridade Estimativa Nome do teste ConecServPAC

O servidor que o usuário escolher no US<07> deverá fazer autenticação no servidor PAC.

<09>

Pesquisa no servidor PAC

Prioridade Estimativa Nome do teste PesqServPAC

Após o usuário estiver conectado ao servidor PAC, ele poderá fazer a pesquisa no banco de dados.

<10>

Importar dados do PAC e armazenar no cliente

Prioridade Estimativa Nome do teste ImpArmDadosPAC

Após o usuário receber a lista da pesquisa US<09> e clicar no item almejado, será realizado a importação dos arquivos mostrados na pesquisa e armazenados no diretório padrão que foi configurado no US<01>. TEMA 4: Ponto DICOM Log de Comunicação

<11>

Criar tabela de Erros

Prioridade Estimativa Nome do teste

66

Criar uma tabela de erros para o sistema com: Código do ERRO e Descrição, usada pelo sistema pra definir os erros.

<12>

Visualizar LOG de comunicação

Prioridade Estimativa Nome do teste VisLogCom

Permite a visualização dos erros ocorridos nos módulo ponto DICOM. Os campos armazenados são: Essa janela estará disponível no MENU: PREFERÊNCIAS→VISUALIZAR LOG DE COMUNICAÇÃO

• AETitle • Endereço TCP/IP • Porta TCP/IP • Descrição do Evento • Data e Hora

Esta informação estará disponível a partir no MENU: PREFERÊNCIAS→VISUALIZAR LOG DE COMUNICAÇÃO

67

Anexo H: Reunião via internet da equipe UFLA-Invesalius com participação da orientadora do Projeto

Abaixo segue o relatório de nossa reunião que ocorreu dia 5/8/2008, estamos ansiosos para passar para uma nova fase nesse projeto e mostrar que estamos aqui para agregar valores.Estamos realizando sempre reuniões para ficarmos cada vez mais por dentro do assunto. sauLo diz:

boa noite pessoal

Sergio diz:to lendo a msg do corinto chegou agora

Sergio diz:td bem mas vou mandar o e-mail do corinto para todos

Sergio diz:recebi msg do corinto agora to repassando

Fernando - Be happy diz:opa, blz

Fernando - Be happy diz:q bom

Fernando - Be happy diz:agora podemos dar prosseguimento

Sergio diz:so um minuto e vcs vao ler

Sergio diz:a professora ta on-line to google

Flavio diz:como é que faz grupo lá?

Fernando - Be happy diz:pelo google tem jeito de fazer conferenci não

Fernando - Be happy diz:*conferencia

Sergio diz:entao vamos continuar por aqui

Flavio diz:ahhhhhhhh

Fernando - Be happy diz:blz, vou ler a mensagem, recebi agora

Sergio diz:vcs leram aquilo que postei no zoho

sauLo diz:sistema multimidia em phyton via internet ?

Flavio diz:

68

http://libdigi.unicamp.br/document/?code=vtls000428249

Sergio diz:eu fiz um resumo e postei a parte necessaria ao nosso software no zoho com a ideia de socket

Fernando - Be happy saiu da conversa. Sergio diz:

vcs receberam o email do corintosauLo diz:

sim

sauLo diz:mais falta ele dizer a data

Flavio diz:a gente precisa dar uma corrida com o nosso projeto. Datas são importantes.

[email protected] está na conversa. Sergio diz:

fernando recebeu a mensagem do corinto?Fernando - Be happy diz:

recebi sim, minha net hoje tá uma caganba

Fernando - Be happy diz:já li a mensagem

Alves diz:Tb li.

Sergio diz:Oi professora boa noite

Alves diz:Boa noite meninos. Tudo certinho?

Fernando - Be happy diz:achei interessante a mensagem, porém esse começo, para nós que não temos experiencia vai ser bem dificil, boa noite professora angela

sauLo diz:boa noite.. tudo joia

Alves diz:Vai ser difícil nada. Vocês vão tirar de letra. Garanto.

Alves diz:É só alinhar.

Alves diz:O mais dificil vocês já fizeram. Encarar o novo e o desafio que evm daí. O resto, bem ..é resto.

Sergio diz:Angela postei uma ideia no zoho nao sei se voce chegou a ver mas acho que eh a solução do problema

Alves diz:Vi não. Postou quando?

Sergio diz:Semana passada.

69

Alves diz:Hummmm. Vou ver.

Fernando - Be happy diz:Agora temos que esperar a resposta da coordenação né

Sergio diz:fernando vc leu a ideia?

Fernando - Be happy diz:do phyton criando sockets?

Sergio diz:isso

Fernando - Be happy diz:vi sim, é um ponto interessante para analisar

Sergio diz:o mais legal e que o pessoal ja tem software rodando desta ideia basta adaptarmos e testar

Fernando - Be happy diz:fazer a conexão dessa forma é bem interessante para criar o modulo do invesalius

Fernando - Be happy diz:é sim

Sergio diz:inclusive vc tem alguma programa q desenha tela

Sergio diz:pq ja tenho ate a ideia de como fazer a interface

Sergio diz:Fernando, Saulo e Flavio o que acharam da ideia que postei no zoho?

Flavio diz:a ideia é boa ... mas vamos ter que pegar firme o projeto para funcionar legal.

Sergio diz:eu acho que eh boa a ideia e ja tem software rodando agora basta nos adaptarmos ele para que o produto funcione

Flavio diz:aahhh ... Sergio ... vc já está manjando tudo de python ?

Sergio diz:nao mas acho que nao vai ser necessario porque nosso software so vai abrir a porta de comunicacao e ficar aguardando pra enviar e receber mensagens e arquivos isso eh facil de fazer

Flavio diz:ok

Sergio diz:Saulo vc ja consegui ver a ideia?

sauLo diz:nessa parte sim, mas como vamos pegar os dados nas PACS ?

Sergio diz:Angela agora temos que aguardar o cliente para ver o que ele precisa. O que vc acha?

70

Sergio diz:a minha ideia eh que as PACS tenham um software que quando executado deve disponibilizar os dados

Sergio diz:esta semana vou disponibilizar umas ideias e vou ver como funciona o software que os caras desenvolveram em pyton e depois vamos implementar ja um primeiro meio de

Sergio diz:comunicacao

Fernando - Be happy diz:já decidiu a ferramenta que vai utilizar?

sauLo diz:existem varias PACS talvez exista um jeito pradonizado d comunicao com elas

Fernando - Be happy diz:usa o Tkinter

Sergio diz:estou vendo o nosso cronograma e agora vi a msg do corinto e acho q temos q definir isso

Sergio diz:Saulo prefiro aguardar o nosso cliente e pensar que temos que sugerir ideias para solucionar o possivel problema, mas se tiver uma padronizacao melhor

Sergio diz:Tkinter o que e?

Fernando - Be happy diz:é o criador gráfico que o pessoal criou no projeto que vc mandou

Sergio diz:que projeto?

Fernando - Be happy diz:o do python

Sergio diz:ah beleza

Alves diz:É pessoal, temos mesmo que prestar muita atenção no cliente. Acho que toda decisão deve ser discutida com ele.

Fernando - Be happy diz:por isso que falei que o começo é dificil, ainda não temos um "cliente direto" para o projeto

Sergio diz:Entao acho que devemos postar ideias, pesquisar e aguardar o cliente, pelo menos ja sabemos que caminho poderemos seguir.

sauLo diz:acho q precisamos de um design inicial pra poder criticar ele discutir melhor as ideias

Alves diz:Uma idéia....

Alves diz:Pro que vocês não mandam uma cópia deste chat para o Corinto?

71

Alves diz:Daí ele tem uma ideía do que rola..

Sergio diz:Legal uma boa idéiaFernando - Be happy diz:é boa ideia, assim ele poderá ver que estamos ativos e ansiosos para entrar em uma nova fasePorém no momento, temos que fazer como o sergio disse, continuarmos buscando conhecimento

Alves diz:Certo. Façam isso então.

Sergio diz:Entao vou fazer assim vou mandar uma cópia deste chat para ele saber das nossas dificuldades e convida-lo para o zoho para ter nocao do que estamos fazendo

Alves diz:Perfeito.

Sergio diz:Combinado então vamos terminar aqui e aguardar novos contatos. Boa Noite a todos e obrigado Angela pelo seu precioso tempo.

Alves diz:Bom pessoal, vou nessa. Boa noite a todos.

Alves diz:Ora, é sempre um prazer.

72

Anexo I - Documentação

Plano do ReleaseIntrodução

Este documento destina-se a elaboração do Plano de Release referente ao desenvolvimento do modulo DICOM InVesalius. O objetivo deste documento é descrever as estórias fornecidas pelo cliente, suas dependências, tempo estimado para cada estória e os papeis de cada membro da equipe durante o projeto.

Escopo

Neste release é utilizado a metodologia XP para o desenvolvimento do módulo DICOM InVesalius, abordando-se neste release os temas que serão especificados no item abaixo.

Estórias do Release

<01>Criação da janela do Ponto DICOM Receptor

PrioridadeMédia

Estimativa1 dia

Nome do testejanPDR

Criação de uma janela mostrando para o usuário os seguintes campos: AETitle TCP/IP Número da porta do TCP/IP Nome Computador + Domínio Verificação de atualização Time-out de comunicação Tempo de armazenamento de log Diretório

Essa janela estará disponível a partir do MENU: PREFERÊNCIAS→TRANSMISSÃO VIA REDE→RECEPTOR Estes dados também poderão ser modificados pelo usuário e deverá haver ajuda para todos os campos.As configurações ficarão salvas em um arquivo.

73

<02>Identificação de informações do computador local

PrioridadeAlta

Estimativa2 dias

Nome do testeInfoCompLocal

Identifica a configuração do computador local e informa ao usuário na janela do US<01>, sendo que a preferência de certos campos são dada pelo arquivo salvo com as modificações feita pelo usuário anteriormente. Abaixo é mostrado os dados que são pegos no computador local, os dados com um * na frente, são os que tem como o arquivo salvo no computador como prioritário.

TCP/IP Número da porta do TCP/IP Nome Computador + Domínio *Verificação de atualização *Time-out de comunicação *Tempo de armazenamento de log *Diretório (Onde o invesalius setará corretamente o endereço do diretório que

armazenará os arquivos, Padrão no Linux: “/home/nome-usuario/invesalius” e Padrão no Windows: “C:\Documents and Settings\usuario\invesalius”).

Obs.: Na primeira execução do InVesalius, deverá ser criado um arquivo com estes dados.

<03>Limpeza do arquivo de log

PrioridadeBaixa

Estimativa1 dia

Nome do testeLimpArqLog

O arquivo de log deverá ser verificado e limpo conforme o número de semanas definido na tela de definição do Ponto DICOM Receptor no US<01>.

<04>Salvar Configuração

PrioridadeAlta

Estimativa2 dias

Nome do testeSalConf

Ao clicar em "OK" na janela do ponto DICOM receptor no US<01> haverá uma verificação se houve alteração das configurações e se houver, armazena as novas configurações para que o InVesalius possa utilizá-las.

<05>Criação de janela do Ponto DICOM Transmissão

PrioridadeMédia

Estimativa1 dia

Nome do testejanPDT

Criação de uma janela que permita adicionar, remover e alterar informações usadas para acesso aos servidores PACS, os seguintes campos são necessários:

AETitle Endereço TCP/IP Porta TCP/IP

74

Descrição Lista de Servidores Campos de autenticação (Usuário e Senha)

Essa janela estará disponível a partir do MENU: PREFERÊNCIAS→TRANSMISSÃO VIA REDE→TRANSMISSÃOO usuário poderá acrescentar novos servidores, sendo que os campos Endereço e Porta TCP/IP são campos obrigatórios.Caso algum servidor necessite de autenticação o usuário já poderá fornecer quando acrescentar servidor.O usuário poderá selecionar um servidor da "Lista de Servidores" e utilizar as opções REMOVE ou ALTER para remover ou alterar algum servidor.O usuário poderá clicar em C-ECHO para verificar se os servidores estão disponíveis.Os configurações ficarão salvas em um arquivo.obs: O botão ADD mudará para ALTER caso o usuário clique em um dos servidores da lista.

<06>Verificar status dos servidores

PrioridadeAlta

Estimativa3 dias

Nome do testeVerStatusServ

Emite um comando, para cada servidor, para saber o status do mesmo.

<07>Criação da janela do ponto DICOM Importar busca

PrioridadeMédia

Estimativa1 dia

Nome do testejanPDIbusca

Criação de uma janela que permitirá ao usuário fazer uma busca nos servidor PACS, a busca pode ser feita utilizando um dos campos pré definidos:

AETitle Nome do Paciente Modalidade Idade Sexo Data de Aquisição

Essa janela estará disponível a partir do MENU:NOVO→ BUSCA NO SERVIDORO usuário pode escolher que tipo de busca deseja fazer no servidor PACS, escolhendo entre informações do Paciente, Estudo, Series, Equipamento, Referencia do Frame e da Imagem. Os dados retornados são listados na tabela de RESULTADO onde o usuário poderá selecionar qual Imagem deseja abrir no InVesalius.Para importar a imagem no InVesalius o usuário deve clicar sobre a informação no tabela resultado e clicar na opção OK.

<08>Conectar ao servidor PAC

PrioridadeAlta

Estimativa5 dias

Nome do testeConecServPAC

75

O servidor que o usuário escolher no US<07> deverá fazer autenticação no servidor PAC.

<09>Pesquisa no servidor PAC

PrioridadeAlta

Estimativa3 dias

Nome do testePesqServPAC

Após o usuário estiver conectado ao servidor PAC, ele poderá fazer a pesquisa no banco de dados.

<10>Importar dados do PAC e armazenar no cliente

PrioridadeAlta

Estimativa5 dias

Nome do testeImpArmDadosPAC

Após o usuário receber a lista da pesquisa US<09> e clicar no item almejado, será realizado a importação dos arquivos mostrados na pesquisa e armazenados no diretório padrão que foi configurado no US<01>.

TEMA 4: Ponto DICOM Log de Comunicação

<11>Criar tabela de Erros

PrioridadeBaixa

Estimativa1 dia

Nome do teste

Criar uma tabela de erros para o sistema com: Código do ERRO e Descrição, usada pelo sistema pra definir os erros.

<12>Visualizar LOG de comunicação

PrioridadeBaixa

Estimativa1 dia

Nome do testeVisLogCom

Permite a visualização dos erros ocorridos nos módulo ponto DICOM.Os campos armazenados são:Essa janela estará disponível no MENU:PREFERÊNCIAS→VISUALIZAR LOG DE COMUNICAÇÃO

AETitle Endereço TCP/IP Porta TCP/IP Descrição do Evento Data e Hora

Esta informação estará disponível a partir no MENU:PREFERÊNCIAS→VISUALIZAR LOG DE COMUNICAÇÃO

76

Planejamento

O desenvolvimento será realizadas em 2 iterações, onde as estórias foram distribuídas conforme a dificuldade existente. A tabela abaixo especifica o tempo para implementação de cada estória. A segunda iteração terá seu tempo definido mais adiante.Tabela 4: Tempo de Implementação das Estórias dos Usuários

Estória Data Inicial Data Final

1ª Iteração

<01> Criação da janela do Ponto DICOM Receptor 11/10/2008 12/10/2008

<02> Identificação de informações do computador local 12/10/2008 14/10/2008

<04> Salvar Configuração 13/10/2008 14/10/2008

<05> Criação de janela do Ponto DICOM Transmissão 11/10/2008 12/10/2008

<07> Criação da janela do ponto DICOM Importar busca 11/10/2008 12/10/2008

<11> Criar tabela de Erros 11/10/2008 14/10/2008

2ª Iteração<03> Limpeza do arquivo de log

<06> Verificar status dos servidores

<08> Conectar ao servidor PAC

<09> Pesquisa no servidor PAC

<10> Importar dados do PAC e armazenar no cliente

<12> Visualizar LOG de comunição

Recursos

Os recursos que iremos utilizar para implementar as iterações é definido logo abaixo.

Recursos Hardware

Os computadores usados serão os computadores de cada usuário e o servidor Dcm4chee além de instalado em cada máquina, um deles ficará aberto para acesso em rede.

Recursos de SoftwareAs ferramentas necessárias durante o projeto:

Tabela 5: Ferramentas do ProjetoFerramentaPython 2.5.2wxPython 2.8 Boa Constructor 0.6.1 Dcm4chee 2.0

As ferramentas utilizadas são softwares com licença aberta.

77

Recursos Humanos

A tabela abaixo define a equipe de desenvolvimento e seus papéis dentro do projeto:

Tabela 6: Equipe de Desenvolvimento

Referências

• Disciplina de Desenvolvimento de sistemas http://www.cin.ufpe.br/~if719

78

http://www.cin.ufpe.br/~if719

Anexo J: Documento: ESCOPO DO Ponto DICOM

1 - HISTÓRICO DE ALTERAÇÕES



2.0 03/09/2008 Equipe UFLA Nova Versão

2 - Introdução

Este documento especifica informações gerais a respeito do sistema, mostrando as funcionalidades que serão agregadas ao software InVesalius.

3 - Objetivo Geral

Fornecer um módulo de software livre que satisfaça as necessidades do Projeto InVesalius que é a implementação de um módulo para importação de dados dos PACS (Picture Archiving and Communication System) para o Software Invesalius pela intranet ou internet.

4 - Ferramentas que serão utilizadas

Linguagem de Programação Conforme determinado na especificação, Python deverá ser utilizado para o desenvolvimento dos módulos em questão. Em específico, espera-se o uso do interpretador da versão 2.5.

Interface Gráfica Espera-se que as janelas de interface gráfica sejam desenvolvidas utilizando a biblioteca wxPython através da IDE BoaConstructor.

5 – Esboço do sistema

79

Figura 11: Esboço do Sistema DICOM

6 - Objetivo específico do produto

Nome do Produto: ponto DICOM

O objetivo deste projeto é integrar os projetos de software livre consolidados (InVesalius e servidor PACS livre pré-determinado) de modo que hospitais públicos, clínicas radiológicas e outras instituições possam disponibilizar através de Servidores PACS exames que podem ser acessados através do InVesalius).

O produto “Ponto DICOM” é um módulo do InVesalius e será dividido em 5 submódulos:

Ponto DICOM Receptor Ponto DICOM Transmissão Ponto DICOM Importar Ponto DICOM Log de Comunicação Ponto DICOM Exportar (essa opção não será definida agora)

6.1 - Ponto DICOM Receptor

O Ponto DICOM receptor vai permitir ao usuário configurar e ver as configurações básicas locais. O Ponto DICOM receptor terá acesso através do menu “PREFERÊNCIAS” → submenu “TRANSMISSÃO VIA REDE” → item “RECEPTOR”. Ao clicar no item “receptor” será aberta uma janela onde terá os seguintes campos: AETitle, TCP/IP, Número da porta do TCP/IP, Nome Computador + Domínio, Verificação de atualização, Time-out de comunicação, Tempo de armazenamento de log e Diretório. Para cada campo haverá ao lado uma opção de ajuda que permitirá o usuário a ter um melhor entendimento do termo

80

utilizado no campo e como deverá ser preenchido este campo, caso necessário. Abaixo segue uma tabela mostrando as características de cada campo, sendo que todos os campos poderão ser alterados pelo usuário.

CAMPOS CARACTERÍSTICAS

AETitle Será gerado um nome automático (INVESALIUS-CLIENTE-XXX).

Endereço TCP/IP Deverá ser capturado automaticamente do computador.

Porta TCP/IP Padrão: 4096 (mas deverá poder ser alterado pelo usuário)

Nome Computador + Domínio Exemplo: laptop.empresa.com.br. Deverá ser capturado automaticamente do computador.

Verificação de atualização Padrão: 30 segundos. Irá verificar se há novos arquivos de 30 em 30 segundos.

Time-out de comunicação Padrão: 2 segundos. Tempo máximo para aguardar requisição de determinado conjunto de arquivo DICOM.

Tempo de armazenamento de log Padrão: semanalmente. Tempo de armazenamento de logs contendo informações de transmissão e possíveis erros.

Diretório

Padrão: “/home/nome-usuario/invesalius” ou “C:\Documents and Settings\usuario\invesalius”. Diretório onde serão armazenados localmente os arquivos.

6.2 - Ponto DICOM Transmissão

O Ponto DICOM Transmissão permitirá ao usuário visualizar servidores previamente cadastrados, acessíveis via internet, sendo possível também cadastrar novos servidores DICOM. O Ponto DICOM Transmissão terá acesso através do menu “PREFERÊNCIAS” → submenu “TRANSMISSÃO VIA REDE” → item “TRANSMISSÃO”. Ao clicar no item “transmissão” será aberta uma janela onde será mostrada em tipo de lista os servidores já cadastrados, mostrando os campos AETitle, Endereço TCP/IP, Porta TCP/IP, Descrição e Status (onde será informado se o servidor está ou não disponível) e no fim um botão permitindo a configuração manual. Nessa janela também haverá um botão para que possa ser acrescentado novos servidores DICOM, ao clicar neste botão aparecerá uma nova janela com os seguintes campos para serem preenchidos: AETitle, Endereço TCP/IP, Porta TCP/IP, Descrição, sendo que apenas os campos Endereço TCP/IP, Porta TCP/IP serão obrigatórios. Caso o servidor DICOM necessite de senha para autenticação, o usuário pode já deixar a senha armazenada. Para saber o status do servidor(s), será feito uma verificação através de testes como ping ou C-Echo. Abaixo é mostrado um exemplo de lista de servidores:

81

AETitle Endereço TCP/IP Porta TCP/IP Descrição Status

PACS_X 192.0.0.1 4445 Servidor do Hospital X Ativo Configura

r

PACS_Y 192.0.0.2 4444 PACS da Clinica Y Inativo Configura

r

PACS_Z 200.10.5.9 4444 Hospital Z Ativo Configurar

6.3 - Ponto DICOM Importar

O Ponto DICOM Importar permitirá ao usuário pesquisar dados em um determinado servidor DICOM e fazer a importação dos dados que o usuário estiver necessitando. O Ponto DICOM Importar terá acesso através do menu “NOVO” → item “IMPORTAR DO SERVIDOR”. Ao clicar em Importar do Servidor, será aberta uma janela mostrando ao usuário os servidores encontrados e se estão ou não ativos, ao selecionar o servidor almejado (se necessitar de autenticação, será pedida ao usuário), depois abrirá uma nova janela onde o usuário poderá fazer uma busca no servidor DICOM, ele poderá pesquisar utilizando um dos seguintes campos ou uma combinação deles, Nome do Paciente, Modalidade (TC, MR, US,...), Data de Aquisição, Idade, Sexo. Abaixo mostra uma tabela como será mostrado a lista dos servidores:

AETitle Endereço TCP/IP Porta TCP/IP Descrição Status

Botão de Acesso

PACS_X 192.0.0.1 4445 Servidor do Hospital X Ativo Acessar

PACS_Y 192.0.0.2 4444 PACS da Clinica Y Inativo Acessar

PACS_Z 200.10.5.9 4444 Hospital Z Ativo Acessar

Após realizar a consulta no servidor será mostrado uma lista com todos os dados encontrados, como é mostrado na tabela abaixo:

AETitle Nome do Paciente Modalidade Idade Sexo ...

PACS_X Dom Pedro RM 60 Masculino ...

PACS_X Joana Dark TC 35 Feminino ...

6.4 - Ponto DICOM Log de comunicação

O Ponto DICOM Log de comunicação conterá os registros de comunicação feita ao servidor DICOM central.

82

O Ponto DICOM Log de comunicação terá acesso através do menu “PREFERÊNCIAS” → item “VISUALIZAR LOG DE COMUNICAÇÃO”. Na tabela abaixo é mostrado os campos composto no log de comunicação.

AETitle Endereço TCP/IP Porta TCP/IP Descrição do Evento Data Hora

PACS_X 192.0.0.1 4445 Time-out 25/08/2008 12:00

PACS_Z 200.10.5.9 4444 Erro de transmissão 26/08/2008 13:05

PACS_Y 192.0.0.2 4444 Sucesso 30/08/2008 19:17

6.5 - Ponto DICOM Exportar

O ponto DICOM exportar permitirá ao usuário enviar para o servidor o estudo que foi realizado localmente. O ponto DICOM exportar terá acesso através do menu “NOVO” → item “EXPORTAR PARA SERVIDOR”.

Obs.: esta parte não será detalhada agora.

83

Anexo K: Relatório UFLA-Invesalius

RELATÓRIO UFLA INVESALIUS

PROJETO UFLA INVESALIUS SOFTWARE PÚBLICO BRASILEIRO - SISTEMA DE IMPORTAÇÃO DE DADOS DE

CLÍNICAS RADIOLÓGICAS

18/09/2008

AUTOR: ANTONIO SÉRGIO NOGUEIRA

LAVRAS - MG

1. IntroduçãoA proposta deste projeto é desenvolver uma comunicação via Internet que possibilitará a

importação de dados para o software InVesalius, integrando o mesmo a sistemas Clínicas Radiológicas. Atualmente, para o InVesalius gerar a reconstrução tridimensional da estrutura anatômica, é necessário que as imagens DICOM estejam armazenadas localmente no computador do usuário ou que o usuário tenha as mesmas gravadas em CD. Muitas vezes o cirurgião não tem o

84

CD em mãos, mas tem acesso via Internet à clínica onde foi gerado o exame. Tendo-se um sistema PACS (Picture Archiving and Communication Systems) de comunicação via rede para recuperação e distribuição de imagens armazenadas em clinicas radiológicas, será possível apresentar as imagens com o InVesalius e fazer a reconstrução das mesmas a distância dos arquivos originais.

2. Atividades realizadas

ARTEFATOS GERADOS EM CADA TAREFA

Explorações Iniciais

-> Definição do grupo de desenvolvimento

-> Soluções do problema e viabilidade

-> Construção do cronograma

Curso

Definição e revisão de requisitos

-> Escrita das estórias (obs.: Esta epata necessitará do apoio de alguém do grupo Invesalius que possa estar se comunicando de forma mais ágil conosco)

Planejamento do Release

-> Escolha das estórias a serem implementadas

-> Plano do Release

Explorações Iniciais:25/08/2008Curso: 11 e 12/09/2008Escrita das Estórias: 03/09 a 15/09/2008Testar Ambiente de Desenvolvimento: 15/09 a 18/09/2008Planejamento do Release: 15/09 a 19/09/2008

3. Próxima AtividadePlanejar Iteração ( escolher estórias para implementar e estimativa das estórias): 19/09 a 23/09/2008

4. Métodos Utilizados para desenvolver o projeto

Estamos utilizando o processo de desenvolvimento ágil chamado de XP. Para que o método fosse utilizado fizemos algumas adaptações, já que a equipe e o cliente encontra-se em locais distintos, desta forma toda comunicação será feita através de chats e de possíveis reuniões com parte da equipe e do pessoal de trabalha no CTI. Adotaremos deste método XP: Simplicidade,

85

Mudanças serão incrementais, Releases pequenos, testes constantes, programação em pares programadores trabalharão na mesma estória de uso), Padronizaremos a codificação e código será coletivo.

5. Métodos para solução do projeto

5.1 Reuniões

Estamos utilizando reuniões diárias entre o treinador e o gerente do projeto para definirmos como será feita esta implementação, estamos nos comunicando por e-mail com toda a equipe e também estamos marcando reuniões no mínimo uma vez por semana com toda a equipe.

5.2 Reunião entre cliente(CTI) e UFLA

Foi realizada no dia 11 e 12/09/2008 uma reunião entre dois membros da equipe UFLA (Sérgio e Flávio) e os três membros do CTI (Tatiana, Thiago e Paulo). Nesta reunião foi discutido:

Documentação dos requisitos do sistema Quais ferramentas serão utilizadas e como utilizá-las:

JBOSS - framework java para executar DCM4CHEEJDK 5.1 - compilador javaDCM4CHEE - servidor de arquivos de imagens DICOMPYTHON 5 - desenvolvimento de sockets BOA Constructor - ide gráfica para PythonMYSQL - banco de dados

Discutimos também a necessidade da área de projeto do Portal SPB estar disponível para documentarmos o projeto ( inclusive enviei um e-mail ao Corinto solicitando agilizar esta área)

Foi apresentado uma mostra do socket para a comunicacao com o servidor, bem como a instalação do servidor que é demasiadamente complexa

Foi discutida com Tatiana uma forma de comunicação entre equipe UFLA e CTI Ficou estabelecido que toda documentação deverá ser postada no portal Ficou decidido que o CTI tentará disponibilizar imediatamente o SVN do portal para

armazenarmos o software Discutimos a complexidade do protocolo DICOM Tivemos contato com a IDE BOA Constructor Foi fornecido as imagens anonimizadas para testarmos no servidor Será enviado os testes bem como o software básico em python para comunicação com o

DICOM

6. ConclusãoO projeto começa agora com o planejamento da release, da instalação das ferramentas e com

o estudo do protocolo DICOM. Até a presente data(18/09/2008) a equipe consegui instalar os softwares para executar o servidor PAC, neste exato momento estamos tentando armazenar os dados no servidor usando ferramentas em java ou com algum software já desenvolvido como o

86

OSIRIX que só roda nos computadores da APPLE.

Gargalos do projeto: O maior gargalo para executar o projeto é que não temos bibliotecas em Python para

DICOM e isto dificulta o desenvolvimento do projeto, uma vez que o protocolo DICOM apresenta especificações que possuem centenas de páginas, distribuídas em vários documentos que deverão ser lidos para implementar esta biblioteca.

O segundo maior desafio está sendo gerenciar esta documentação do projeto e que depois deverá migrar para a área do Portal.

Inexperiência de desenvolvimento de projeto de software livre com a utilização de metodologia.

Falta de padrões de codificação que terão que ser definidos, uma vez que não há este documento no projeto.

Facilitação para desenvolver o projeto: O portal já deveria estar preparado para receber o projeto, estes ajustes que estão sendo

efetuados dificultam tremendamente os prazos do projeto. A equipe do CTI-InVesalius deveria estar preparada para lidar com este projeto de

desenvolvimento do software livre, o que não ocorre porque somos a primeira equipe; Maior prazo de desenvolvimento e suporte ao protocolo DICOM.

Prazos do Projeto Até a presente data o projeto está dentro dos prazos de acordo com o segundo

cronograma .

87

Anexo L:Documento: Ponto DICOM Fases da Metodologia XP

1 - Histórico de Alterações



2. Introdução

Este documento específica informações gerais a respeito do desenvolvimento do módulo ponto DICOM com base na metodologia XP, sendo que alguns processos tiveram que ser adaptados para proporcionar um trabalho mais eficaz.

3 - Metodologia XP (Extreme Programming)

3.1 Planejamento

1. Os clientes têm que expressar usando histórias descrevendo o que eles querem que o sistema faça (User Stories (Estórias dos usuários)).

2.Faça o Planejamento da Release. A equipe técnica avalia a duração de cada história baseada em sua complexidade e o gerente de produto juntamente com o cliente atribui prioridades para as histórias de modo que uma linha de tempo do projeto seja definida (Etapa a ser definida com o cliente na reunião em Campinas).

3.Comece a cada dia com uma reunião stand-up. Esta será uma sessão de informação onde, participam desenvolvedores e gerente, serão abordadas as dificuldades e as soluções que serão oferecidas. (Será efetuada uma reunião diária via internet.)

3.2 Projeto

1.Faça desenhos simples e fáceis de ler. Transforme desenhos complexos em componentes simples.

2.Crie um programa que será uma solução paliativa para minimizar o risco de uma sobrecarga extrema de um problema.

3.Revise o código para mantê-lo simples, reutilizável, extensível e limpo. Este é um dos mais importantes componentes do XP.

88

3.3Codificação

1.Permita que o cliente possa sempre ser acessado pela equipe de desenvolvimento e pelo gerente do projeto para a questão de esclarecimentos e comentários.

2. Definir um estilo uniforme de programação entre os desenvolvedores (Padrão para nomes de métodos, classes, variáveis, organização do código (chaves, etc.). Todo o código parece que foi escrito por uma só pessoa). E também dividir o software em camadas.

3.Criar um primeiro teste, com base na história. O teste irá definir as condições-limite para a programação extrema (XP) do código que deve ser escrito.

4.Use o modelo de programação em pares. Um programador irá fazer o plano da concepção enquanto o outro vai fazer a codificação, alternando sempre estes papéis. Este é um dos mais importantes componentes de programação extrema.

5.Construa sempre novas versões do código e use um sistema de controle de versão(Gerencia de projetos do Software Público Brasileiro).

6.Otimize no final o projeto XP.

3.4 Testes

1.Realize uma unidade teste em cada linha de código para se certificar de que é funcional.2.Executar um teste de aceitação para cada componente que corresponde a uma história a fim de garantir que os resultados devolvidos são os esperados. Isto finaliza o XP.

3.Criar um teste para cada erro que for encontrada para evitar o erro reapareça.

4. A Equipe do Projeto XP

Todos em um projeto XP são parte de uma equipe que deve incluir um representante do cliente que estabelece os requisitos do projeto, define prioridades e controla o rumo:

Papéis da Equipe XP:

Cliente: Usuário Final (Equipe CTI - Tatiana Martins - Equipe UFLA)

Programadores: Equipe UFLA (Sandro, Sérgio, Saulo, Fernando, Flávio)

89

Testadores: Auxiliam o cliente com o teste de aceitação - Equipe UFLA

Analistas: Ajudam o cliente a definir requisitos - Equipe UFLA

Gerente: Coordena a equipe e garante os recursos necessários - Sérgio

Coach (Treinador): Orienta a equipe e controla a aplicação - Fernando

Tracker (Rastreador): Coleta as métricas - Fernando

Anexo: Camadas de um software

A camada de apresentação é um serviço que seu sistema presta para alguém, pode ser um ser humano ou outro sistema.

A camada de persistência é uma interface para coisas que estão provendo ao seu sistema.

A camada de negócio é uma nova camada entre as duas anteriores, que modela o domínio da aplicação e onde ficam as regras de negócio.

90

Anexo M: ponto DICOM prototipagem das janelas

1 - HISTÓRICO DE ALTERAÇÕES



2 - INTRODUÇÃO

Este documento mostra a prototipagem das janelas que serão criadas no software InVesalius.

3 - Ferramentas que serão utilizadas

Será utilizado a biblioteca wxPython através da IDE BoaConstructo.

4 - Protótipos das janelas

4.1 - ponto DICOM receptor

91

Figura 12. ponto Dicom receptor

4.2 - ponto DICOM transmissão

92

Figura 13. ponto Dicom Transmissão4.3 - ponto DICOM importar busca

Figura 14. ponto Dicom importar busca

93

Anexo N: Pré- Projeto

Data da defesa: : Novembro/2008 Título:Desenvolvimento do Sistema de comunicação via Internet que possibilitará a exportação e importação de dados de e para o software InVesalius, integrando o mesmo a sistemas de Prontuário Eletrônico do Paciente.Flávio - Camada de apresentação e AplicaçãoSaulo - Integração e Camada de persistênciaFernando - Camada de apresentação e AplicaçãoSandro - Integração e Camada de Persistência

Sérgio - gerenciamentoGerenciar os projetos: com o objetivo de medir, controlar,e modificar os projetos de software, ou seja, tratar do planejamento das atividades voltadas para assegurar que o software seja entregue dentro do prazo e orçamento previstos e de acordo com os requisitos especificados pelas organizações que estão desenvolvendo eadquirindo o software.

94

Anexo O: Projeto UFLA InVesaliusSistema de Importação de dados de Clínicas Radiológicas

1. Análise do Domínio / Definição de Ferramenta de Gerenciamento:

Início: 21/07Término: 03/08

Definição do grupo de desenvolvimentoPossíveis soluções do problema e viabilidade das soluçõesCronograma geral

2. Planejamento:


Definir ferramentasDefinir e Revisar RequisitosPlanejar Release

3. Execução do projeto:


Cada iteração será realizado:Planejar a iteraçãoCriar o projetoEscrever testes de unidadeCodificarTestarIntegrarRealizar testes funcionais

4. Finalização do projeto:


5.Colocar em produção

Documentação a ser Entregue

Documento: Análise do Domínio – Previsão de Entrega: 03/08/2008

Artefatos:Definição do grupo desenvolvimentoPossíveis soluções do problema e Viabilidade das

95

soluções Revisão do Cronograma

Documento: Planejamento – Previsão de Entrega: 28/08/2008Artefatos:

Definição das Estórias a serem Implementadas(requisitos funcionais)

Especificação e avaliação das estórias(requisitos funcionais)

Definição de Requisitos não FuncionaisDefinição de Iterações Definição de ferramentasRevisão do Cronograma

Documento: Execução do Projeto - Previsão de Entrega:14/09 e 11/10/2008Artefatos:

Codificação de cada EstóriaDescrição dos testes unitáriosResultados dos testes unitáriosRevisão do Cronograma

Documento: Relatório fases de Iteração - Previsão de Entrega: 26/10/2008Artefatos:

Testes de IntegraçãoCronograma Final do Desenvolvimento

Documento: Entrega do Projeto: Previsão de Entrega: 03/11/2008 Artefatos:

Compilação de todos Documentos

96

uma sugestÃo de metodologia de desenvolvimento e gestÃo de projeto de software livre para equipes...

Education