UNIVERSIDADE FEDERAL DE PELOTAS INSTITUTO DE FÍSICA E MATEMÁTICA DEPARTAMENTO DE INFORMÁTICA

BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

SIIM: SISTEMA DE INTEGRAÇÃO DE INFORMAÇÕES MÉDICAS

Dário Knuppe Jerônimo Medina Madruga Rodrigo Trindade Prestes

Trabalho de pesquisa apresentado na disciplina de Engenharia de Software 2 do Curso de Bacharelado em Ciência da Computação, Instituto de Física e Matemática, Universidade Federal de Pelotas. Professor: Profa. Msc. Eliane da Silva Alcoforado Diniz

2009

Lista de Figuras

Figura 1: Interface do ADM Médico......................................................................................7 Figura 2: Tela de cadastro de clientes do Medicsystem .........................................................9 Figura 3: Estrutura de um repositório SVN..........................................................................22 Figura 4: Gráfico de Gantt do ClockingIT ...........................................................................24 Figura 5: Lista de chamados do Web Chamado..................................................................25 Figura 6: Gráfico de Gantt do OpenProj ..............................................................................26 Figura 7: Tela de abertura do SIIM ......................................................................................30

Sumário

Apresentação ..........................................................................................................................4 1. Projeto.................................................................................................................................5

1.1 Conceito........................................................................................................................5 1.2 Funcionalidades............................................................................................................6

1.2.1 Adm Médico 3.15:.................................................................................................6 1.2.2 Clinicas Integradas 1.1: .........................................................................................7 1.2.3 Medicsystem 2.01:.................................................................................................8

2. Metodologias Empregadas ...............................................................................................10 2.1. Método ágil................................................................................................................10

2.1.1. XP .......................................................................................................................12 2.1.1. SCRUM ..............................................................................................................15

2.2. Metodologias agéis em um ambiente disperso..........................................................17 3. Softwares Auxiliares ........................................................................................................18

3.1 Controle de versão......................................................................................................18 3.1.1. CVS ....................................................................................................................18 3.1.2. GIT .....................................................................................................................20 3.1.3. Subversion ..........................................................................................................20

3.2 Gerência de projeto.....................................................................................................22 3.2.1.ClockingIT...........................................................................................................23 3.2.2. Web Chamado ....................................................................................................24 3.2.3. OpenProj.............................................................................................................25

3.3. Documentação ...........................................................................................................26 3.3.1. Doxygen .............................................................................................................27 3.3.2. Phpdocumentator ................................................................................................27

4. Sistema de Integração de Informações Médicas...............................................................29 4.1 Cronograma de desenvolvimento ...............................................................................29

5. Conclusão .........................................................................................................................31 Referências Bibliográficas....................................................................................................32

Apresentação

Este trabalho tem como objetivo o desenvolvimento de uma aplicação do

tipo EMR (Emergency Medical Record), que são aplicações dedicas a

armazenamento de informações da área da saúde.

Para o desenvolvimento da mesma, foi feito um estudo sobre o a aplicação

de metodologias de desenvolvimento ágil sobre um ambiente distribuído, ou seja,

onde os desenvolvedores estão dispersos geograficamente; e também sobre

ferramentas para auxiliar a aplicação dessas metodologias e a evolução do projeto

em si.

Começaremos demonstrando a viabilidade de nosso idéia inicial, mostrando

também algumas idéias sobre os softwares existentes nesse área atualmente.

Após, será abordado como adaptamos as metodologias de desenvolvimento de

acordo com nosso ambiente, e algumas ferramentas que podem auxiliar na

gerência de um projeto. No final, mostramos a característica do produto

desenvolvido, e alguns comentários sobre o mesmo.

1. Projeto

1.1 Conceito

Ao começar a pesquisa para verificar qual seria o foco do projeto a ser

desenvolvido, tivemos enfoque em idéias sobre áreas de software em expansão. A

idéia mais promissora encontrada segundo nossas pesquisas foi a área de

tecnologia da informação da saúde, com enfoque em sistemas de

armazenamentos de dados médicos e clínicos, conhecidos também como EMR.

Softwares do tipo EMR podem ser implementados nos mais diversos tipos

de estabelecimentos, de clinicas médicas, ortodônticas, cirúrgicas, a grandes

hospitais e empresas do ramo de saúde. Sua variedade e diversidade de formas

de implementação são tão vastas que alguns paises adotaram padrões de

interoperabilidade, para garantir a coexistência de diversos sistema

intercomunicáveis, facilitando assim a troca de informações entre diferente

estabelecimentos. Alguns países também estão em processo de adoção de

sistemas únicos para os órgãos públicos de saúde, visando diminuir os custos da

saúde pública. A demanda por este tipo de software ocorre devido a agilidade que

ele adiciona ao funcionamento de uma clinica, resultando segundo vários estudos

até mesmo em ganho financeiro perante sua adoção, pois possibilita o

atendimento de mais pacientes e a diminui a tarefa de busca de informações

prévias.

Já no Brasil, softwares EMR não tem uma classificação especifica, são

chamados de softwares médicos, ou softwares de clinicas, e não existe nenhuma

tentativa de padronização para os mesmos, o que ocasiona em formatos de

software proprietários, sem regulamentação, sem possibilidade de comunicação

entre eles e cada um com um tipo de funcionalidade determinada pelos seus

desenvolvedores.

Tendo isto em mente, resolvemos pela criação do SIIM (sistema de

integração de informações médicas) para verificarmos como as metodologias

ágeis poderiam contribuir no desenvolvimento deste projeto e também explorar

uma área que é relativamente intocada pelos programadores brasileiros.

1.2 Funcionalidades

Para verificar o que deveria ser implementado no software em termos de

funcionalidades, Em um projeto normal seria necessário analisar os requisitos

definido por um cliente, mas visto que este software foi feito para fim de estudos,

verificamos as funcionalidades a serem desenvolvidas de acordo com a analise

dos produtos que o mercado oferece, conforme descrito a seguir.

1.2.1 Adm Médico 3.15:

Software para gestão de consultórios médicos que necessitem de um

sistema rápido, objetivo e com informações essenciais. Suporta base de dados

grande, e é totalmente ajustável à necessidades específicas.

Em sua versão Free:

• Cadastro de pacientes;

• Backup de dados;

• Agenda de consultas;

• Interação com softwares aplicativos;

• Integração de dados;

• Calendário.

Em sua versão completa:

• Cadastro de anamnese;

• Contas a pagar;

• Contas a receber;

• Textos modelos (receita, cobrança, retorno...);

• Avisos (alarmes e retornos de consultas);

• Ficha clínica.

Figura 1: Interface do ADM Médico

1.2.2 Clinicas Integradas 1.1:

Este software faz o gerenciamento de consultórios médicos, odontológicos

e fisioterápicos.

Controles:

• Pacientes ativos e inativos;

• Agenda de atendimento;

• Fluxo de caixa diário simples;

• Emissão de receitas e atestados;

• Controle e impressão de contratos;

• Controle e impressão de orçamentos;

• Mala direta;

• Cartões de páscoa, aniversário e natal;

• Agenda de contatos.

1.2.3 Medicsystem 2.01:

O Medicsystem é um sistema para gerenciar clínicas ou consultórios

médicos. É uma programa multi-usuário, ou seja, permitindo que diversos usuários

utilizem o sistema simultaneamente. Todas as telas são integradas, após

cadastrar um paciente já é possível agendar uma consulta automaticamente, um

atendimento, gera um contas a receber para o médico que prestou o atendimento.

Principais recursos:

• Agenda da secretária;

• Cadastro de clientes e fornecedores;

• Atendimento ao cliente;

• Emissão de receitas;

• Acompanhamento de dados do atendimento (pressão, temperatura,

peso);

• Relação de clientes por categoria;

• No momento do atendimento, o médico poderá visualizar os

atendimentos anteriores e assim saber o que já foi escrito ao cliente.

Medicsystem Master (versão completa):

• AMB e CID;

• Acesso ao sistema por usuário e senha

• Emissão de atestado;

• 5 opções para emissão de etiquetas para clientes;

• Texto padrão (permite o uso de texto previamente cadastrados em

receitas e atestados);

• Controle bancário;

• Centro de custo;

• Levantamento de receitas/despesas;

• Contas a receber por médico e convênio;

• Aniversariantes do mês;

• E mais: suporte gratuito via fone, e-mail ou on-line, sem taxas de

manutenção mensal.

Figura 2: Tela de cadastro de clientes do Medicsystem

2. Metodologias Empregadas

2.1. Método ágil

Desenvolvimento ágil de software é um conjunto de metodologias de

desenvolvimento de software. O desenvolvimento ágil, tal como qualquer

metodologia de software, providencia uma estrutura conceitual para reger projetos

de engenharia de software.

Existem inúmeros métodos de desenvolvimento de software rápido, sendo

que a maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do

software em curtos períodos, chamados de iteração, os quais gastam tipicamente

menos de uma semana a até quatro. Cada iteração é como um projeto de

software em miniatura de seu próprio, e inclui todas as tarefas necessárias para

implantar o mini-incremento da nova funcionalidade: planejamento, Análise de

Requisitos, projeto, codificação, teste e documentação. Enquanto em um processo

convencional, cada iteração não está necessariamente focada em adicionar um

novo conjunto significativo de funcionalidades, um projeto de software ágil busca a

capacidade de implantar uma nova versão do software ao fim de cada iteração,

etapa a qual a equipe responsável reavalia as prioridades do projeto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente

face a face, a documentos escritos. A maioria dos componentes de um grupo ágil

devem estar agrupados em uma sala. Isto inclui todas as pessoas necessárias

para terminar o software. No mínimo, isto inclui os programadores e seus clientes .

Nesta sala devem também se encontrar os testadores, projetistas de iteração,

redatores técnicos e gerentes.

Princípios:

• Garantir a satisfação do consumidor entregando rapidamente e

continuamente softwares funcionais;

• Softwares funcionais são entregues frequentemente (semanas, ao

invés de meses);

• Softwares funcionais são a principal medida de progresso do projeto;

• Até mesmo mudanças tardias de escopo no projeto são bem-vindas.

• Cooperação constante entre pessoas que entendem do 'negócio' e

desenvolvedores;

• Projetos surgem através de indivíduos motivados, e que deve existir

uma relação de confiança.

• Design do software deve prezar pela excelência técnica;

• Simplicidade;

• Rápida adaptação às mudanças;

• Indivíduos e interações mais do que processos e ferramentas;

• Software funcional mais do que documentação extensa;

• Colaboração com clientes mais do que negociação de contratos;

• Responder a mudanças mais do que seguir um plano.

Como em todas as metodologias, o conhecimento e a experiência dos

usuários definem o grau de sucesso e/ou fracasso de cada atividade. Os controles

mais rígidos e sistematizados aplicados em um processo implicam em altos níveis

de responsabilidade para os usuários. A degradação de procedimentos bem-

intencionados pode levar as atividades a serem caracterizadas como codificação

cowboy.

Embora os métodos ágeis apresentem diferenças entre suas práticas, eles

compartilham inúmeras características em comum, incluindo o desenvolvimento

iterativo, e um foco na comunicação interativa e na redução do esforço empregado

em artefatos intermediários. A aplicabilidade dos métodos ágeis em geral pode ser

examinada de múltiplas perspectivas. Da perspectiva do produto, métodos ágeis

são mais adequados quando os requisitos estão emergindo e mudando

rapidamente. De uma perspectiva organizacional, a aplicabilidade pode ser

expressa examinando três dimensões chaves da organização: cultura, pessoal e

comunicação.

No nosso caso, devido a ser um grupo pequeno de desenvolvedores,

resolvemos adotar uma combinação da metodologia XP e Scrum, adaptada as

nossas necessidades, como será descrito posteriormente.

2.1.1. XP

Programação extrema, também conhecida como XP, é uma metodologia

ágil para equipes pequenas e médias e que irão desenvolver software com

requisitos vagos e em constante mudança. Para isso, adota a estratégia de

constante acompanhamento e realização de vários pequenos ajustes durante o

desenvolvimento de software.

Os quatro valores fundamentais da metodologia XP são: comunicação,

simplicidade, feedback e coragem. A partir desses valores, possui como princípios

básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar

mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e

escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização

de funcionalidades que representem maior valor possível para o negócio. Desta

forma, caso seja necessário a diminuição de escopo, as funcionalidades menos

valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto, pois o

pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é

compensado por perdas (ou até impedimentos) a médio e longo prazo.

Para aplicar os valores e princípios durante o desenvolvimento de software,

XP propõe uma série de práticas. Há uma confiança muito grande na sinergia

entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de

outras.

• Jogo de Planejamento : O desenvolvimento é feito em iterações

semanais. No início da semana, desenvolvedores e cliente reúnem-se para

priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do

Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as

estimam. O cliente é essencial neste processo e assim ele fica sabendo o

que está acontecendo e o que vai acontecer no projeto. Como o escopo é

reavaliado semanalmente, o projeto é regido por um contrato de escopo

negociável, que difere significativamente das formas tradicionais de

contratação de projetos de software. Ao final de cada semana, o cliente

recebe novas funcionalidades, completamente testadas e prontas para

serem postas em produção.

• Pequenas Versões: A liberação de pequenas versões funcionais do

projeto auxilia muito no processo de aceitação por parte do cliente, que já

pode testar uma parte do sistema que está comprando. As versões chegam

a ser ainda menores que as produzidas por outras metodologias

incrementais, como o RUP.

• Metáfora: Procura facilitar a comunicação com o cliente, entendendo

a realidade dele. O conceito de rápido para um cliente de um sistema

jurídico é diferente para um programador experiente em controlar

comunicação em sistemas em tempo real, como controle de tráfego aéreo.

É preciso traduzir as palavras do cliente para o significado que ele espera

dentro do projeto.

• Projeto Simples : Simplicidade é um princípio da XP. Projeto simples

significa dizer que caso o cliente tenha pedido que na primeira versão

apenas o usuário "teste" possa entrar no sistema com a senha "123" e

assim ter acesso a todo o sistema, você vai fazer o código exato para que

esta funcionalidade seja implementada, sem se preocupar com sistemas de

autenticação e restrições de acesso. Um erro comum ao adotar essa

prática é a confusão por parte dos programadores de código simples e

código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a

solução mais simples por parte de projeto. Esse entendimento é

fundamental para o bom andamento do XP. Código fácil deve ser

identificado e substituído por código simples.

• Time Coeso: A equipe de desenvolvimento é formada pelo cliente e

pela equipe de desenvolvimento.

• Testes de Aceitação: São testes construídos pelo cliente e conjunto

de analistas e testadores, para aceitar um determinado requisito do

sistema.

• Ritmo Sustentável: Trabalhar com qualidade, buscando ter ritmo de

trabalho saudável, sem horas extras. Horas extras são permitidas quando

trouxerem produtividade para a execução do projeto. Outra prática que se

verifica neste processo é a prática de trabalho energizado, onde se busca

trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação

da equipe devem estar sempre em harmonia.

• Reuniões em pé: Reuniões em pé para não se perder o foco nos

assuntos, produzindo reuniões rápidas, apenas abordando tarefas

realizadas e tarefas a realizar pela equipe.

• Posse Coletiva: O código fonte não tem dono e ninguém precisa

solicitar permissão para poder modificar o mesmo. O objetivo com isto é

fazer a equipe conhecer todas as partes do sistema.

• Programação em Pares: é a programação em par/dupla num único

computador. Geralmente a dupla é formada por um iniciante na linguagem

e outra pessoa funcionando como um instrutor. Como é apenas um

computador, o novato é que fica à frente fazendo a codificação, e o instrutor

acompanha ajudando a desenvolver suas habilidades. Desta forma o

programa sempre é revisto por duas pessoas, evitando e diminuindo assim

a possibilidade de erros. Com isto busca-se sempre a evolução da equipe,

melhorando a qualidade do código fonte gerado.

• Padrões de Codificação: A equipe de desenvolvimento precisa

estabelecer regras para programar e todos devem seguir estas regras.

Desta forma parecerá que todo o código fonte foi editado pela mesma

pessoa, mesmo quando a equipe possui 10 ou 100 membros.

• Desenvolvimento Orientado a Testes: Primeiro crie os testes

unitários e depois crie o código para que os testes funcionem. Esta

abordagem é complexa no início, pois vai contra o processo de

desenvolvimento de muitos anos. Só que os testes unitários são essenciais

para que a qualidade do projeto seja mantida.

• Refatoração: É um processo que permite a melhoria continua da

programação, com o mínimo de introdução de erros e mantendo a

compatibilidade com o código já existente. Refabricar melhora a clareza

(leitura) do código, divide-o em módulos mais coesos e de maior

reaproveitamento, evitando a duplicação de código-fonte;

• Integração Contínua: Sempre que produzir uma nova funcionalidade,

nunca esperar uma semana para integrar à versão atual do sistema. Isto só

aumenta a possibilidade de conflitos e a possibilidade de erros no código

fonte. Integrar de forma contínua permite saber o status real da

programação.

2.1.1. SCRUM

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de

projetos em empresas de fabricação de automóveis e produtos de consumo, onde

foi notado que projetos usando equipes pequenas e multidisciplinares produziam

os melhores resultados.

A função primária do Scrum é ser utilizado para o gerenciamento de

projetos de desenvolvimento de software. Porém, teoricamente pode ser aplicado

em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas

para atingir um objetivo comum, como iniciar uma escola pequena, projetos de

pesquisa científica, ou até mesmo o planejamento de um casamento.

Mesmo que o Scrum tenha sido idealizado para ser usado em gestão de

projetos de desenvolvimento de software, ele também pode ser usado para

gerenciar equipes de manutenção, ou como uma abordagem para gestão de

programas: Scrum de Scrums.

Características de Scrum:

• Cada sprint é uma iteração que segue o ciclo PDCA e entrega

incremento de software pronto.

• Um backlog é conjunto de requisitos, priorizado pelo cliente;

• Há entrega de conjunto fixo de itens do backlog em série de

iterações curtas ou sprints;

• Breve reunião diária, ou scrum, em que cada participante fala sobre o

progresso conseguido, o trabalho a ser realizado e/ou o que o impede de

seguir avançando (também chamado de Standup Meeting, já que os

membros do time geralmente ficam em pé).

• Breve sessão de planejamento, na qual os itens do backlog para uma

sprint (iteração) são definidos;

• Retrospectiva, na qual todos os membros da equipe refletem sobre a

sprint passada.

O Scrum é facilitado por um Scrum Master, que tem como função primária

remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo

do sprint. O Scrum Master não é o líder da equipe (já que as equipes são auto-

organizadas) mas atua como uma barreira entre a equipe e qualquer influência

desestabilizadora. Outra função extremamente importante de um Scrum Master é

o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum,

motivando-os e mantendo o foco na meta da Sprint.

Scrum permite a criação de equipes auto-organizadas, encorajando a

comunicação verbal entre todos os membros da equipe e entre todas as

disciplinas que estão envolvidas no projeto.

Um princípio chave do Scrum é o reconhecimento de que desafios

fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando

uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem

empírica, aceitando que o problema não pode ser totalmente entendido ou

definido, focando na maximização da habilidade da equipe de responder de forma

ágil aos desafios emergentes.

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um

software. O backlog de produto é mantido pelo Proprietário do Produto e é uma

lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma

interpretação do backlog do produto e contém tarefas concretas que serão

realizadas durante o próximo sprint para implementar alguns dos itens principais

no backlog do produto. O backlog de produto e de sprint são, então, duas coisas

totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo

contendo informações sobre como a equipe irá implementar os requisitos.

Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipe

decidem no que a equipe irá trabalhar durante o próximo sprint. O Proprietário do

Produto mantém uma lista priorizada de itens de backlog, o backlog do produto, o

que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona

itens do topo do backlog do produto. Eles selecionam somente o quanto de

trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura

e o design de como o backlog do produto pode ser implementado. Os itens do

backlog do produto são então destrinchados em tarefas que se tornam o backlog

do sprint.

2.2. Metodologias ágeis em um ambiente disperso

Tendo em vista as características citadas do Scrum e do XP, elas sofrem

algumas adaptações levando em conta equipes que trabalham remotamente:

• Reuniões presenciais foram substituídas pela troca de mensagens

instantâneas em momentos programados, estabelecendo tempo de inicio e

de termino, para evitar reuniões longas.

• Conversas habituais e questionamentos eventuais tomam a forma de

e-mails, mas sempre destinados a todos do grupo, evocando uma conversa

multilateral e garantindo que todos os membros estejam a par da evolução

do projeto.

• A programação em pares não é possível, mas cada mudança é feita

por um membro é revisada por no mínimo mais um membro, tentado assim

simular o mesmo efeito desta prática.

Devido a falta de cliente neste projeto, toda referencia que requisitaria um

cliente, como a verificação dos requisitos, é feita por um integrante da equipe, que

tem um papel fixo para o controle de qualidade.

3. Softwares Auxiliares

3.1 Controle de versão Utilizando uma metodologia ágil, temos inúmeras versões do software que é

construído de forma crescente, o que resulta em diversas versões do mesmo

código. Em projetos com grande números de versões esse fato se torna uma

complicação a mais a ser gerenciada, logo, procuramos por ferramentas que

automatizem esta tarefa, permitindo o armazenamento e a recuperação de código

antigo com um alto grau de precisão e facilidade. As ferramentas que Verificamos

foram o CVS, GIT e SVN, sendo que acabamos por usar o SVN, pelo uso fácil e

por ser multiplataforma.

3.1.1. CVS

O CVS, (Sistema de Versões Concorrentes) é um sistema de controle de

versão que permite que se trabalhe com diversas versões de arquivos

organizados em um diretório e localizados local ou remotamente, mantendo-se

suas versões antigas e os logs de quem e quando manipulou os arquivos.

É especialmente útil para se controlar versões de um software durante seu

desenvolvimento, ou para composição colaborativa de um documento.

CVS utiliza uma arquitetura cliente-servidor: um servidor armazena as

versões atuais do projeto e seu histórico, e os clientes se conectam a esse

servidor para obter uma cópia completa do projeto, trabalhar nessa cópia e então

devolver suas modificações. Tipicamente, cliente e servidor devem estar

conectados por uma rede local de computadores, ou pela Internet, mas o cliente e

o servidor podem estar na mesma máquina se a configuração do CVS for feita de

maneira a dar acesso a versões e histórico do projeto apenas a usuários locais. O

servidor geralmente roda sistema ao estilo Unix, enquanto o cliente CVS pode

rodar qualquer sistema operacional.

Vários clientes podem editar cópias do mesmo projeto de maneira

concorrente. Quando eles confirmam suas alterações, o servidor tenta fazer uma

fusão delas. Se isso não for possível, por exemplo porque mais de um cliente

tentou executar alterações na mesma linha do documento, o servidor apenas

executa a primeira alteração e informa ao responsável pela segunda alteração que

houve conflito, e que é necessário uma intervenção humana. Se a validação da

alteração for bem sucedida, o número de versão de cada cliente arquivo envolvido

é incrementado, e o servidor CVS escreve uma linha de observação (fornecida

pelo usuário), a data e o autor das alterações em seus arquivos de log.

Clientes podem comparar diferentes versões de um arquivo, pedir um

histórico completo das alterações, ou baixar uma determinada versão do projeto,

ou de uma data específica, não necessariamente a versão mais atual. Muitos

projetos de código aberto permitem acesso para leitura anônimo, o que significa

que qualquer pessoa pode baixar ou comparar versões sem necessidade de

autenticação; somente para salvar mudanças é necessário informar a senha

nesses casos.

Clientes também podem usar o comando "update" para manter suas cópias

locais atualizadas com a última versão do servidor. Isso elimina a necessidade de

se fazer diversos downloads de todo o projeto.

O CVS também pode manter diferentes "estados" do projeto. Por exemplo,

uma versão do software pode ser um desses estados, usado para correção de

bugs, enquanto outra versão, que está realmente sob desenvolvimento, sofrendo

alterações e tendo novas funcionalidades implementadas, forma o outro estado.

O CVS usa compressão delta para armazenar de maneira eficiente

diferentes versões de um mesmo arquivo.

Limitações:

• Os arquivos em um repositório CVS não podem ser renomeados, eles

devem ser explicitamente removidos e readicionados.

• O protocolo do CVS não permite que os diretórios sejam movidos ou

renomeados. Cada arquivo do subdiretório em questão deve ser

individualmente removido e readicionado.

• Não permite "checkout" reservados (permite que dois usuários alterem o

mesmo arquivo ao mesmo tempo) e em alguns casos pode ser mais

custoso resolver o conflito do que evitar que ele ocorra.

3.1.2. GIT

Git é um software gratuito para controle de versão distribuido, ou seja um

software para gerencimento de código fonte com enfase em ser rápido.

Cada diretório de trabalho Git é um repositório com todos os históricos e

habilidade total de controle das revisões, não depedente de acesso a uma rede ou

a um servidor central.

O design do Git foi inspirado por dois outros sistemas de versionamento:

BitKeeper e Monotone. O Git foi criado originalmente apenas como um mecanismo

de baixo nível, que outros poderiam usar para escrever front ends como o Cogito

ou o StGIT.

Entretanto, o projeto principal do Git acabou virando um sistema de controle

de versão completo, que pode ser usado diretamente. Hoje em dia, vários projetos

de alto nível já usam o Git para controle de versões, destacando-se entre eles o

kernel Linux.

3.1.3. Subversion

Subversion (também conhecido por SVN) é um sistema de controle de

versão desenhado especificamente para ser um substituto moderno do CVS, que

se considera ter algumas limitações.

Características:

• Rastreamento de mesclagens.

• Suporte ao BDB 4.4

• O acesso ao repostório mudou um pouco. Quer dizer que seu

repositório vai ser gradativamente sendo atualizado. Então versões

anteriores não poderão acessar novos repositórios.

• Binds para python e ruby

• Mais de 30 bugs corrigidos

• trancamento de ficheiros para ficheiros infundiveis ("reserved

checkouts")

• autoversionamento WebDAV integral

• mensagens internacionalizadas do programa

• versionamento de atalhos simbólicos

• um novo formato de repositório, FSFS, que não usa um "back-end"

de base de dados, guardando as revisões em ficheiros no sistema de

ficheiros.

• as características mais correntes do CVS

• Diretórios, mudanças de nome e meta-data de ficheiros são

versionadas

• as operações de "commit" são verdadeiramente atômicas

• servidor HTTP Apache como servidor de rede, WebDAV/DeltaV

como protocolo (também existe um processo independente de servidor que

usa um protocolo personalizado sobre TCP/IP)

• a ramificação e a etiquetagem são operações "baratas" (em tempo

constante)

• desenho nativo de arquitectura cliente-servidor e de "biblioteca em

camadas"

• o protocolo cliente-servidor envia diffs em ambas as direcções

• os custos são proporcionais ao tamanho das mudanças e não ao

tamanho dos dados

• tratamento eficiente de ficheiros binários.

• saida de informação passivel de ser analisada gramaticalmente

(incluindo a saida de registos em formato XML)

• licença de software livre - "licença CollabNet/Tigris.org do género

Apache-style"

Figura 3: Estrutura de um repositório SVN

3.2 Gerência de projeto Quando se esta trabalha com o desenvolvimento de software, temos

diversas tarefas que devem ser realizadas, e quando se trabalha em grupo, tem

de se existir um controle sobre quem está responsável por quais tarefas, além do

andamento das mesmas e possíveis novas tarefas que possam existir. Como seria

necessário um canal de comunicação constante para a realização desta tarefa, e

como isso não é possível em grupo de desenvolvimento distribuído

geograficamente, a solução é a utilização de um software que possa armazenar as

informações sobre as tarefas e também a capacidade de delegar as mesmas. Nós

verificamos 3 softwares desta categoria, ClockingIT, Web Chamado e OpenProj.

Acabamos escolhendo o ClockingIT, pois ele funciona no formato webserver,

possibilitando a consulta remota desde que o servidor se encontre disponível..

3.2.1.ClockingIT

ClockingIT é uma ferramenta para controle de projetos, bugs e releases. O

ClockingIT segue a mesma receita de muitos projetos de alta qualidade e valor

agregado disponíveis atualmente: nasceu de uma necessidade do próprio

desenvolvedor.

O sistema permite o cadastro de diversos projetos e colaboradores. Em

cada projeto, é possível criar milestones e tarefas (com diversos graus de

prioridade, nível de dificuldade, tempo estimado de execução e data de entrega) e

designar um colaborador para sua execução. Além disso, o sistema permite a

criação de subtarefas e permite registrar o tempo levado para executar cada

tarefa, gerando um log de trabalho.

O grande diferencial do clockingIT é a qualidade da interface. O design

gráfico é simples, limpo e extremamente intuitivo, fazendo um uso intensivo e

inteligente de scripts e recursos assíncronos. A interação como o site é

extremamente ágil e leve, exatamente como em software desktop. Qualquer ação

efetuada por algum usuário é imediatamente refletida na tela de outros usuários

conectados no mesmo projeto. É possível saber em tempo real quem está

conectado no sistema, o que está fazendo, a quanto tempo está fazendo. E graças

ao chat embutido, é possível até conversar com outros colaboradores.

O sistema oferece integração com iCal (pode ser integrado com Google

Calendar ou com o calendário da Apple por exemplo), sistema de RSS, um wiki,

fórum , e uma speedbar (uma janelinha pequena) que permite que o usuário

marque o início e fim de uma tarefa (com botões de start, stop e pause e um

cronômetro rodando em tempo real).

Figura 4: Gráfico de Gantt do ClockingIT

3.2.2. Web Chamado

WebChamado é um software focado no auxilio da evolução de outros

projetos por meio de abertura e acompanhamento de chamados. Totalmente Web,

possibilita o acompanhamento de chamados na internet ou intranet, podendo

assim a abertura e acompanhamento de chamados em qualquer lugar,

dependendo somente de uma conexão com a internet.

Todas as iterações com o projeto é notificada por e-mail, seja ela por meio

de quem abriu o chamado ou pelo responsável envolvido no processo, assim que

o chamado sofrer uma iteração automaticamente todas as pessoas envolvidas

serão notificadas.

Permite um acompanhamento por meio de gráficos estatísticos que

auxiliam na tomada de decisão referente a um determinado projeto, como por

exemplo em qual período do mês um determinado projeto recebe uma maior

quantidade de chamados, desta forma pode-se ampliar a equipe responsável pelo

projeto a fim de diminuir o tempo de resposta dos chamados abertos neste

período de maior ocorrência de chamados, seja proveniente de correção de

problemas ou solicitação de evolução.

Figura 5: Lista de chamados do Web Chamado

3.2.3. OpenProj

OpenProj é um gerenciador de projetos desenvolvido como alternativa ao

Microsoft Project. Com código aberto, o programa oferece várias opções para a

inclusão e administração de todas as atividades co-relacionadas ao

desenvolvimento das atividades, apresentando os resultados, em especial, sob o

formato de Gráficos de Gantt.

Este tipo de gráfico ilustra, na forma de barras, o cronograma de um

projeto, com as datas de início, fim e todas as tarefas atribuídas devidamente

registradas, sendo, por este motivo, muito utilizado para representar o status atual

da programação de um projeto.

OpenProj é uma das melhores iniciativas em se tratando de programas com

código aberto para a gerencia de projetos, apresentando todas as opções

necessárias para o usuário armazenar suas informações e obter sucesso em seus

negócios. OpenProj é um programa realmente versátil. Com uma interface simples

de usar, o gerenciador de projetos apresenta todas as opções importantes para se

realizar uma administração de informações e tarefas a serem cumpridas. A

metodologia aplicada é a de diagramas de Gantt, muito usada na atualidade,

podendo ser adaptado para metodologias PMBOK, um conjunto de práticas em

gerência de projetos de muita qualidade.

Figura 6: Gráfico de Gantt do OpenProj

3.3. Documentação Para a criação da documentação, resolvemos no primeiro momento adotar

algum software que realizasse essa tarefa de forma automatizada, agilizando

assim um processo que costumar ser ardiloso de ser implementado. Mas devido a

falta de tempo deixado para esta tarefa, a documentação ficou restrita somente

aos comentários situados no código, mas mostraremos as características dos

programas que exploramos para futura referência.

3.3.1. Doxygen

Doxygen é um programa que gera a documentação de um programa a

partir da analise dos fontes de um programa escrito diversas linguagens. Nesta

análise são reconhecidas declarações de estruturas de dados e funções e

comentários feitos com uma sintaxe especial.

Muitas vezes é necessário ter uma documentação externa ao fonte. Se esta

documentação não for gerada de forma automática, é necessário manter

sincronizadas três coisas: o código, os comentários e a documentação. Com o

Doxygen basta manter sincronizados os dois primeiros, a documentação será

gerada diretamente a partir deles.

A saída nativa do Doxygen é HTML, mas ele suporta diversos tipos de

saída, como DOC, PDF e CHM.

3.3.2. Phpdocumentator

O phpDocumentator é uma ferramenta para auto-documentação utilizado

com a linguagem php. Similar ao Javadoc, e escrito em php. O phpDocumentator

pode ser ainda usado na linha de comando ou através de uma interface web para

criar documentação profissional do código php da aplicação.

O phpDocumentator tem suporte para a linkagem entre documentos,

incluindo a criação de documentos a níveis de usuários como tutoriais e

criação de código destacado com referência para documentação geral de

php.

As tags para a criação da documentação são inseridas através dentro de

comentários.

O phpDocumentator usa um sistema de templates extensíveis para mudar

os comentários do código fonte em um formato útil para que possamos ler. Esse

sistema permite a fácil criação para ler o documento em 15 diferentes HTML

designers, formato PDF, CHM e em DocBook XML.

4. Sistema de Integração de Informações Médicas

4.1 Cronograma de desenvolvimento

Na primeira semana de realização do projeto, começamos a pesquisar qual

seria o assunto a ser abordado (metodologias a serem aplicadas) e qual seria o

tipo de aplicação a ser desenvolvida. Ao final da segunda semana chegamos a

conclusão através da analise de diversos projetos que a mistura entre XP e Scrum

seria a mais indicada para nosso caso (equipe pequena, projeto de pequeno porte,

prazo médio de 6 meses, possibilidade de comunicação constante); e também que

o software a ser desenvolvido seria do tipo EMR.

Da terceira a nona semana, nos dedicamos a pesquisa de softwares que

auxiliassem a concepção do projeto, e verificando quais as características que

cada software continha, e qual deles se adaptariam de melhor forma a nossas

necessidades. Nesse meio tempo também definimos as bases do projeto, como a

utilização de php e mysql para criação do mesmo, e quais seriam as

funcionalidades a serem implementadas, com base nas funcionalidades dos

programas pesquisados.

A partir da décima semana, começamos com a codificação do projeto em si,

dedicando as duas primeiras semanas para a formulação do banco de dados que

armazenaria as informações, visando que após a formulação do banco de dados,

as tarefas poderiam ocorrer de forma simultânea pois não haveria nenhuma

dependência de informações sobre elas, pois já estaria definido o formato das

informações a ser manipulado.

Na décima segunda semana até décima oitava semana, trabalhamos na

implementação das funcionalidades desejadas através de scripts de php, além da

modelagem da interface, que envolveu a aplicação de CSS para criação de um

estilo padrão para o programa. Neste ponto tivemos a ajuda do aluno Moisés

Dorneles, que foi responsável pela edição das imagens utilizadas.

Os primeiros scripts de php realizados eram referentes estrutura da

interface, pois tentamos estruturar o programa de forma a em qualquer uma das

opções abordadas, se mantivessem diversos elementos em comum. Após,

começou o trabalho a como seria feito a entrada no sistema, que ficou sendo

através de um username e password, sendo que cada username teria atribuído

um nível, que seria relativo a suas permissões quanto a alteração e visualização

de dados. Também foi sendo desenvolvido as duas principais entidades a serem

manipuladas, médicos e pacientes, além da implementação de um calendário para

agendamento de consultas. As últimas alterações a serem feitas foram a interface

de administração e de funcionários administrativos, que devido ao tempo não

foram completamente implementados.

As duas últimas semanas saímos fora metodologia habitual devido a ser o

período de provas da faculdade, e resolvemos parar com os ciclos de

desenvolvimento e nos concentrar apenas nos testes da interface e verificação da

comunicação entre os módulos, dando forma ao produto final.

Figura 7: Tela de abertura do SIIM

5. Conclusão Com o desenvolvimento desse trabalho, podemos como as metodologias

ágeis pode ser adaptadas para diferente ambientes, com regras flexíveis e grande

efetivas, se forem exercidas corretamente. A quantidade de ferramentas relativas

ao processo de desenvolvimento também tem um grande impacto, ajudando a

revisão de erros, distribuição de tarefas e a automatização de tarefas relativas ao

desenvolvimento.

Também observamos a tendência da migração da plataforma das

aplicações para web, devido a infinidade de sistemas e ferramentas suportado por

este tipo de ambiente, possibilitando uma alta disponibilidade sem uma

dependência de acesso físico ao ambiente a ser implementado.

Notamos que apesar de utilizar modularidade durante a codificação do

programa, houve um certo alto nível de dependência entre os módulos, de forma a

obrigar quem estava a alterar um módulo de conhecer a estrutura básica dos

outros módulos conectados ao mesmo. Isso é um efeito totalmente indesejável em

um projeto de grande porte, e deve ser evitado ao máximo possível.

Pela falta de enfoque na documentação, este foi o último item a ser

desenvolvido, e ficou restrito a pequenos comentários ao longo do código, o que

talvez não ajude a entender toda a extensão do programa, demonstrando a

necessidade de uma documentação adequada para um melhoramento continuo

do código com agilidade.

Por último, vimos que as das tarefas mais árduas seguindo metodologias

ágeis são a estipulação de tempo para implementação de cada funcionalidade

(pois um calculo errado de tempo e poderia afetar todo o calendário de

desenvolvimento, fazendo com que o atraso se propagasse pro outras tarefas); e

também uma particularidade de trabalhar em um ambiente distribuído, que era

garantir comunicação direta entre os membros, o que pode ser feito através de

softwares específicos e planejamento de longo prazo.

Referências Bibliográficas

http://www.extremeprogramming.org/

http://www.ime.usp.br/~xp

http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp

http://www.agilemanifesto.org/

http://www.improveit.com.br/xp/dissertacaoXP.pdf

http://www.mountaingoatsoftware.com/scrum/

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

www.clockingit.com/

http://superdownloads.uol.com.br/windows/empresas/clinicas-farmacias-

consultorios.html

http://savannah.nongnu.org/projects/cvs/

http://subversion.tigris.org/

http://git-scm.com/

http://webchamado.sourceforge.net/

http://sourceforge.net/projects/openproj/

http://www.stack.nl/~dimitri/doxygen/manual.html

http://www.phpdoc.org/