Sistema de integração de informações médicas

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/

Sistema de integração de informações médicas

Recommended

Recommended

More Related Content

Similar to Sistema de integração de informações médicas

Similar to Sistema de integração de informações médicas (20)

More from Jerônimo Medina Madruga

More from Jerônimo Medina Madruga (20)

Sistema de integração de informações médicas