UNIVERSIDADE FEDERAL DE PELOTAS         INSTITUTO DE FÍSICA E MATEMÁTICA          DEPARTAMENTO DE INFORMÁTICA      BACHARE...
Lista de FigurasFigura 1: Interface do ADM Médico............................................................................
SumárioApresentação .........................................................................................................
Apresentação         Este trabalho tem como objetivo o desenvolvimento de uma aplicação dotipo EMR (Emergency Medical Reco...
1. Projeto1.1 Conceito      Ao começar a pesquisa para verificar qual seria o foco do projeto a serdesenvolvido, tivemos e...
ágeis poderiam contribuir no desenvolvimento deste projeto e também exploraruma área que é relativamente intocada pelos pr...
Figura 1: Interface do ADM Médico1.2.2 Clinicas Integradas 1.1:       Este software faz o gerenciamento de consultórios mé...
•   Cartões de páscoa, aniversário e natal;      •   Agenda de contatos.1.2.3 Medicsystem 2.01:      O Medicsystem é um si...
•   Contas a receber por médico e convênio;•   Aniversariantes do mês;•   E mais: suporte gratuito via fone, e-mail ou on-...
2. Metodologias Empregadas2.1. Método ágil      Desenvolvimento ágil de software é um conjunto de metodologias dedesenvolv...
•     Softwares funcionais são a principal medida de progresso do projeto;      •     Até mesmo mudanças tardias de escopo...
No nosso caso, devido a ser um grupo pequeno de desenvolvedores,resolvemos adotar uma combinação da metodologia XP e Scrum...
estimam. O cliente é essencial neste processo e assim ele fica sabendo oque está acontecendo e o que vai acontecer no proj...
•     Testes de Aceitação: São testes construídos pelo cliente e conjuntode analistas e testadores, para aceitar um determ...
desenvolvimento de muitos anos. Só que os testes unitários são essenciais      para que a qualidade do projeto seja mantid...
•      Um backlog é conjunto de requisitos, priorizado pelo cliente;      •      Há entrega de conjunto fixo de itens do b...
realizadas durante o próximo sprint para implementar alguns dos itens principaisno backlog do produto. O backlog de produt...
3. Softwares Auxiliares3.1 Controle de versão      Utilizando uma metodologia ágil, temos inúmeras versões do software que...
Vários clientes podem editar cópias do mesmo projeto de maneiraconcorrente. Quando eles confirmam suas alterações, o servi...
•   Não permite "checkout" reservados (permite que dois usuários alterem o       mesmo arquivo ao mesmo tempo) e em alguns...
•      Binds para python e ruby•      Mais de 30 bugs corrigidos•      trancamento de ficheiros para ficheiros infundiveis...
Figura 3: Estrutura de um repositório SVN3.2 Gerência de projeto       Quando se esta trabalha com o desenvolvimento de so...
geograficamente, a solução é a utilização de um software que possa armazenar asinformações sobre as tarefas e também a cap...
Figura 4: Gráfico de Gantt do ClockingIT3.2.2. Web Chamado      WebChamado é um software focado no auxilio da evolução de ...
projeto a fim de diminuir o tempo de resposta dos chamados abertos nesteperíodo de maior ocorrência de chamados, seja prov...
OpenProj é uma das melhores iniciativas em se tratando de programas comcódigo aberto para a gerencia de projetos, apresent...
assim um processo que costumar ser ardiloso de ser implementado. Mas devido afalta de tempo deixado para esta tarefa, a do...
O phpDocumentator usa um sistema de templates extensíveis para mudaros comentários do código fonte em um formato útil para...
4. Sistema de Integração de Informações Médicas4.1 Cronograma de desenvolvimento      Na primeira semana de realização do ...
Os primeiros scripts de php realizados eram referentes estrutura dainterface, pois tentamos estruturar o programa de forma...
5. Conclusão      Com o desenvolvimento desse trabalho, podemos como as metodologiaságeis pode ser adaptadas para diferent...
Referências Bibliográficashttp://www.extremeprogramming.org/http://www.ime.usp.br/~xphttp://www.softwarereality.com/Extrem...
Próximos SlideShares
Carregando em…5
×

Sistema de integração de Informações Médicas (SIIM) - Versão artigo

934 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
934
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
11
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Sistema de integração de Informações Médicas (SIIM) - Versão artigo

  1. 1. UNIVERSIDADE FEDERAL DE PELOTAS INSTITUTO DE FÍSICA E MATEMÁTICA DEPARTAMENTO DE INFORMÁTICA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃOSIIM: 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
  2. 2. Lista de FigurasFigura 1: Interface do ADM Médico...................................................................................... 7Figura 2: Tela de cadastro de clientes do Medicsystem ......................................................... 9Figura 3: Estrutura de um repositório SVN.......................................................................... 22Figura 4: Gráfico de Gantt do ClockingIT ........................................................................... 24Figura 5: Lista de chamados do Web Chamado .................................................................. 25Figura 6: Gráfico de Gantt do OpenProj .............................................................................. 26Figura 7: Tela de abertura do SIIM ...................................................................................... 30
  3. 3. SumárioApresentação .......................................................................................................................... 41. 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:................................................................................................. 82. 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 .......................................................... 173. 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 ................................................................................................ 274. Sistema de Integração de Informações Médicas............................................................... 29 4.1 Cronograma de desenvolvimento ............................................................................... 295. Conclusão ......................................................................................................................... 31Referências Bibliográficas.................................................................................................... 32
  4. 4. Apresentação Este trabalho tem como objetivo o desenvolvimento de uma aplicação dotipo EMR (Emergency Medical Record), que são aplicações dedicas aarmazenamento de informações da área da saúde. Para o desenvolvimento da mesma, foi feito um estudo sobre o a aplicaçãode metodologias de desenvolvimento ágil sobre um ambiente distribuído, ou seja,onde os desenvolvedores estão dispersos geograficamente; e também sobreferramentas para auxiliar a aplicação dessas metodologias e a evolução do projetoem si. Começaremos demonstrando a viabilidade de nosso idéia inicial, mostrandotambém algumas idéias sobre os softwares existentes nesse área atualmente.Após, será abordado como adaptamos as metodologias de desenvolvimento deacordo com nosso ambiente, e algumas ferramentas que podem auxiliar nagerência de um projeto. No final, mostramos a característica do produtodesenvolvido, e alguns comentários sobre o mesmo.
  5. 5. 1. Projeto1.1 Conceito Ao começar a pesquisa para verificar qual seria o foco do projeto a serdesenvolvido, tivemos enfoque em idéias sobre áreas de software em expansão. Aidéia mais promissora encontrada segundo nossas pesquisas foi a área detecnologia da informação da saúde, com enfoque em sistemas dearmazenamentos de dados médicos e clínicos, conhecidos também como EMR. Softwares do tipo EMR podem ser implementados nos mais diversos tiposde estabelecimentos, de clinicas médicas, ortodônticas, cirúrgicas, a grandeshospitais e empresas do ramo de saúde. Sua variedade e diversidade de formasde implementação são tão vastas que alguns paises adotaram padrões deinteroperabilidade, para garantir a coexistência de diversos sistemaintercomunicáveis, facilitando assim a troca de informações entre diferenteestabelecimentos. Alguns países também estão em processo de adoção desistemas únicos para os órgãos públicos de saúde, visando diminuir os custos dasaúde pública. A demanda por este tipo de software ocorre devido a agilidade queele adiciona ao funcionamento de uma clinica, resultando segundo vários estudosaté mesmo em ganho financeiro perante sua adoção, pois possibilita oatendimento de mais pacientes e a diminui a tarefa de busca de informaçõesprévias. Já no Brasil, softwares EMR não tem uma classificação especifica, sãochamados de softwares médicos, ou softwares de clinicas, e não existe nenhumatentativa de padronização para os mesmos, o que ocasiona em formatos desoftware proprietários, sem regulamentação, sem possibilidade de comunicaçãoentre eles e cada um com um tipo de funcionalidade determinada pelos seusdesenvolvedores. Tendo isto em mente, resolvemos pela criação do SIIM (sistema deintegração de informações médicas) para verificarmos como as metodologias
  6. 6. ágeis poderiam contribuir no desenvolvimento deste projeto e também exploraruma área que é relativamente intocada pelos programadores brasileiros.1.2 Funcionalidades Para verificar o que deveria ser implementado no software em termos defuncionalidades, Em um projeto normal seria necessário analisar os requisitosdefinido por um cliente, mas visto que este software foi feito para fim de estudos,verificamos as funcionalidades a serem desenvolvidas de acordo com a analisedos 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 umsistema rápido, objetivo e com informações essenciais. Suporta base de dadosgrande, 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.
  7. 7. Figura 1: Interface do ADM Médico1.2.2 Clinicas Integradas 1.1: Este software faz o gerenciamento de consultórios médicos, odontológicose 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;
  8. 8. • 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óriosmédicos. É uma programa multi-usuário, ou seja, permitindo que diversos usuáriosutilizem o sistema simultaneamente. Todas as telas são integradas, apóscadastrar um paciente já é possível agendar uma consulta automaticamente, umatendimento, 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;
  9. 9. • 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
  10. 10. 2. Metodologias Empregadas2.1. Método ágil Desenvolvimento ágil de software é um conjunto de metodologias dedesenvolvimento de software. O desenvolvimento ágil, tal como qualquermetodologia de software, providencia uma estrutura conceitual para reger projetosde engenharia de software. Existem inúmeros métodos de desenvolvimento de software rápido, sendoque a maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento dosoftware em curtos períodos, chamados de iteração, os quais gastam tipicamentemenos de uma semana a até quatro. Cada iteração é como um projeto desoftware em miniatura de seu próprio, e inclui todas as tarefas necessárias paraimplantar o mini-incremento da nova funcionalidade: planejamento, Análise deRequisitos, projeto, codificação, teste e documentação. Enquanto em um processoconvencional, cada iteração não está necessariamente focada em adicionar umnovo conjunto significativo de funcionalidades, um projeto de software ágil busca acapacidade 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, preferencialmenteface a face, a documentos escritos. A maioria dos componentes de um grupo ágildevem estar agrupados em uma sala. Isto inclui todas as pessoas necessáriaspara 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);
  11. 11. • 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 dosusuários definem o grau de sucesso e/ou fracasso de cada atividade. Os controlesmais rígidos e sistematizados aplicados em um processo implicam em altos níveisde responsabilidade para os usuários. A degradação de procedimentos bem-intencionados pode levar as atividades a serem caracterizadas como codificaçãocowboy. Embora os métodos ágeis apresentem diferenças entre suas práticas, elescompartilham inúmeras características em comum, incluindo o desenvolvimentoiterativo, e um foco na comunicação interativa e na redução do esforço empregadoem artefatos intermediários. A aplicabilidade dos métodos ágeis em geral pode serexaminada de múltiplas perspectivas. Da perspectiva do produto, métodos ágeissão mais adequados quando os requisitos estão emergindo e mudandorapidamente. De uma perspectiva organizacional, a aplicabilidade pode serexpressa examinando três dimensões chaves da organização: cultura, pessoal ecomunicação.
  12. 12. No nosso caso, devido a ser um grupo pequeno de desenvolvedores,resolvemos adotar uma combinação da metodologia XP e Scrum, adaptada asnossas 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 comrequisitos vagos e em constante mudança. Para isso, adota a estratégia deconstante acompanhamento e realização de vários pequenos ajustes durante odesenvolvimento de software. Os quatro valores fundamentais da metodologia XP são: comunicação,simplicidade, feedback e coragem. A partir desses valores, possui como princípiosbásicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçarmudanças e trabalho de qualidade. Dentre as variáveis de controle em projetos (custo, tempo, qualidade eescopo), há um foco explícito em escopo. Para isso, recomenda-se a priorizaçãode funcionalidades que representem maior valor possível para o negócio. Destaforma, caso seja necessário a diminuição de escopo, as funcionalidades menosvaliosas serão adiadas ou canceladas. A XP incentiva o controle da qualidade como variável do projeto, pois opequeno 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 sinergiaentre elas, os pontos fracos de cada uma são superados pelos pontos fortes deoutras. • 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
  13. 13. estimam. O cliente é essencial neste processo e assim ele fica sabendo oque está acontecendo e o que vai acontecer no projeto. Como o escopo éreavaliado semanalmente, o projeto é regido por um contrato de escoponegociável, que difere significativamente das formas tradicionais decontratação de projetos de software. Ao final de cada semana, o clienterecebe novas funcionalidades, completamente testadas e prontas paraserem postas em produção.• Pequenas Versões: A liberação de pequenas versões funcionais doprojeto 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 chegama ser ainda menores que as produzidas por outras metodologiasincrementais, como o RUP.• Metáfora: Procura facilitar a comunicação com o cliente, entendendoa realidade dele. O conceito de rápido para um cliente de um sistemajurídico é diferente para um programador experiente em controlarcomunicação em sistemas em tempo real, como controle de tráfego aéreo.É preciso traduzir as palavras do cliente para o significado que ele esperadentro do projeto.• Projeto Simples : Simplicidade é um princípio da XP. Projeto simplessignifica dizer que caso o cliente tenha pedido que na primeira versãoapenas o usuário "teste" possa entrar no sistema com a senha "123" eassim ter acesso a todo o sistema, você vai fazer o código exato para queesta funcionalidade seja implementada, sem se preocupar com sistemas deautenticação e restrições de acesso. Um erro comum ao adotar essaprática é a confusão por parte dos programadores de código simples ecódigo fácil. Nem sempre o código mais fácil de ser desenvolvido levará asolução mais simples por parte de projeto. Esse entendimento éfundamental para o bom andamento do XP. Código fácil deve seridentificado e substituído por código simples.• Time Coeso: A equipe de desenvolvimento é formada pelo cliente epela equipe de desenvolvimento.
  14. 14. • Testes de Aceitação: São testes construídos pelo cliente e conjuntode analistas e testadores, para aceitar um determinado requisito dosistema.• Ritmo Sustentável: Trabalhar com qualidade, buscando ter ritmo detrabalho saudável, sem horas extras. Horas extras são permitidas quandotrouxerem produtividade para a execução do projeto. Outra prática que severifica neste processo é a prática de trabalho energizado, onde se buscatrabalho motivado sempre. Para isto o ambiente de trabalho e a motivaçãoda equipe devem estar sempre em harmonia.• Reuniões em pé: Reuniões em pé para não se perder o foco nosassuntos, produzindo reuniões rápidas, apenas abordando tarefasrealizadas e tarefas a realizar pela equipe.• Posse Coletiva: O código fonte não tem dono e ninguém precisasolicitar 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 únicocomputador. Geralmente a dupla é formada por um iniciante na linguageme outra pessoa funcionando como um instrutor. Como é apenas umcomputador, o novato é que fica à frente fazendo a codificação, e o instrutoracompanha ajudando a desenvolver suas habilidades. Desta forma oprograma sempre é revisto por duas pessoas, evitando e diminuindo assima 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 precisaestabelecer regras para programar e todos devem seguir estas regras.Desta forma parecerá que todo o código fonte foi editado pela mesmapessoa, mesmo quando a equipe possui 10 ou 100 membros.• Desenvolvimento Orientado a Testes: Primeiro crie os testesunitários e depois crie o código para que os testes funcionem. Estaabordagem é complexa no início, pois vai contra o processo de
  15. 15. 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 deprojetos em empresas de fabricação de automóveis e produtos de consumo, ondefoi notado que projetos usando equipes pequenas e multidisciplinares produziamos melhores resultados. A função primária do Scrum é ser utilizado para o gerenciamento deprojetos de desenvolvimento de software. Porém, teoricamente pode ser aplicadoem qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntaspara atingir um objetivo comum, como iniciar uma escola pequena, projetos depesquisa científica, ou até mesmo o planejamento de um casamento. Mesmo que o Scrum tenha sido idealizado para ser usado em gestão deprojetos de desenvolvimento de software, ele também pode ser usado paragerenciar equipes de manutenção, ou como uma abordagem para gestão deprogramas: Scrum de Scrums. Características de Scrum: • Cada sprint é uma iteração que segue o ciclo PDCA e entrega incremento de software pronto.
  16. 16. • 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áriaremover qualquer impedimento à habilidade de uma equipe de entregar o objetivodo 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ênciadesestabilizadora. 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 acomunicação verbal entre todos os membros da equipe e entre todas asdisciplinas que estão envolvidas no projeto. Um princípio chave do Scrum é o reconhecimento de que desafiosfundamentalmente empíricos não podem ser resolvidos com sucesso utilizandouma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagemempírica, aceitando que o problema não pode ser totalmente entendido oudefinido, 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 umsoftware. O backlog de produto é mantido pelo Proprietário do Produto e é umalista de requisitos que tipicamente vêm do cliente. O backlog de sprint é umainterpretação do backlog do produto e contém tarefas concretas que serão
  17. 17. realizadas durante o próximo sprint para implementar alguns dos itens principaisno backlog do produto. O backlog de produto e de sprint são, então, duas coisastotalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundocontendo informações sobre como a equipe irá implementar os requisitos. Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipedecidem no que a equipe irá trabalhar durante o próximo sprint. O Proprietário doProduto mantém uma lista priorizada de itens de backlog, o backlog do produto, oque pode ser repriorizado durante o planejamento do sprint. A Equipe selecionaitens do topo do backlog do produto. Eles selecionam somente o quanto detrabalho eles podem executar para terminar. A Equipe então planeja a arquiteturae o design de como o backlog do produto pode ser implementado. Os itens dobacklog do produto são então destrinchados em tarefas que se tornam o backlogdo sprint.2.2. Metodologias ágeis em um ambiente disperso Tendo em vista as características citadas do Scrum e do XP, elas sofremalgumas 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 umcliente, como a verificação dos requisitos, é feita por um integrante da equipe, quetem um papel fixo para o controle de qualidade.
  18. 18. 3. Softwares Auxiliares3.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 mesmocódigo. Em projetos com grande números de versões esse fato se torna umacomplicação a mais a ser gerenciada, logo, procuramos por ferramentas queautomatizem esta tarefa, permitindo o armazenamento e a recuperação de códigoantigo com um alto grau de precisão e facilidade. As ferramentas que Verificamosforam o CVS, GIT e SVN, sendo que acabamos por usar o SVN, pelo uso fácil epor ser multiplataforma.3.1.1. CVS O CVS, (Sistema de Versões Concorrentes) é um sistema de controle deversão que permite que se trabalhe com diversas versões de arquivosorganizados em um diretório e localizados local ou remotamente, mantendo-sesuas versões antigas e os logs de quem e quando manipulou os arquivos. É especialmente útil para se controlar versões de um software durante seudesenvolvimento, ou para composição colaborativa de um documento. CVS utiliza uma arquitetura cliente-servidor: um servidor armazena asversões atuais do projeto e seu histórico, e os clientes se conectam a esseservidor para obter uma cópia completa do projeto, trabalhar nessa cópia e entãodevolver suas modificações. Tipicamente, cliente e servidor devem estarconectados por uma rede local de computadores, ou pela Internet, mas o cliente eo servidor podem estar na mesma máquina se a configuração do CVS for feita demaneira a dar acesso a versões e histórico do projeto apenas a usuários locais. Oservidor geralmente roda sistema ao estilo Unix, enquanto o cliente CVS poderodar qualquer sistema operacional.
  19. 19. Vários clientes podem editar cópias do mesmo projeto de maneiraconcorrente. Quando eles confirmam suas alterações, o servidor tenta fazer umafusão delas. Se isso não for possível, por exemplo porque mais de um clientetentou executar alterações na mesma linha do documento, o servidor apenasexecuta a primeira alteração e informa ao responsável pela segunda alteração quehouve conflito, e que é necessário uma intervenção humana. Se a validação daalteraçã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 (fornecidapelo 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 umhistó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. Muitosprojetos de código aberto permitem acesso para leitura anônimo, o que significaque qualquer pessoa pode baixar ou comparar versões sem necessidade deautenticação; somente para salvar mudanças é necessário informar a senhanesses casos. Clientes também podem usar o comando "update" para manter suas cópiaslocais atualizadas com a última versão do servidor. Isso elimina a necessidade dese 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 debugs, enquanto outra versão, que está realmente sob desenvolvimento, sofrendoalterações e tendo novas funcionalidades implementadas, forma o outro estado. O CVS usa compressão delta para armazenar de maneira eficientediferentes 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.
  20. 20. • 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 umsoftware 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 ehabilidade total de controle das revisões, não depedente de acesso a uma rede oua 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 mecanismode baixo nível, que outros poderiam usar para escrever front ends como o Cogitoou o StGIT. Entretanto, o projeto principal do Git acabou virando um sistema de controlede versão completo, que pode ser usado diretamente. Hoje em dia, vários projetosde alto nível já usam o Git para controle de versões, destacando-se entre eles okernel Linux.3.1.3. Subversion Subversion (também conhecido por SVN) é um sistema de controle deversão desenhado especificamente para ser um substituto moderno do CVS, quese 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.
  21. 21. • Binds para python e ruby• Mais de 30 bugs corrigidos• trancamento de ficheiros para ficheiros infundiveis ("reservedcheckouts")• 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 deficheiros.• as características mais correntes do CVS• Diretórios, mudanças de nome e meta-data de ficheiros sãoversionadas• as operações de "commit" são verdadeiramente atômicas• servidor HTTP Apache como servidor de rede, WebDAV/DeltaVcomo protocolo (também existe um processo independente de servidor queusa um protocolo personalizado sobre TCP/IP)• a ramificação e a etiquetagem são operações "baratas" (em tempoconstante)• desenho nativo de arquitectura cliente-servidor e de "biblioteca emcamadas"• o protocolo cliente-servidor envia diffs em ambas as direcções• os custos são proporcionais ao tamanho das mudanças e não aotamanho 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éneroApache-style"
  22. 22. Figura 3: Estrutura de um repositório SVN3.2 Gerência de projeto Quando se esta trabalha com o desenvolvimento de software, temosdiversas tarefas que devem ser realizadas, e quando se trabalha em grupo, temde se existir um controle sobre quem está responsável por quais tarefas, além doandamento das mesmas e possíveis novas tarefas que possam existir. Como serianecessário um canal de comunicação constante para a realização desta tarefa, ecomo isso não é possível em grupo de desenvolvimento distribuído
  23. 23. geograficamente, a solução é a utilização de um software que possa armazenar asinformações sobre as tarefas e também a capacidade de delegar as mesmas. Nósverificamos 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. OClockingIT segue a mesma receita de muitos projetos de alta qualidade e valoragregado disponíveis atualmente: nasceu de uma necessidade do própriodesenvolvedor. O sistema permite o cadastro de diversos projetos e colaboradores. Emcada projeto, é possível criar milestones e tarefas (com diversos graus deprioridade, nível de dificuldade, tempo estimado de execução e data de entrega) edesignar um colaborador para sua execução. Além disso, o sistema permite acriação de subtarefas e permite registrar o tempo levado para executar cadatarefa, gerando um log de trabalho. O grande diferencial do clockingIT é a qualidade da interface. O designgráfico é simples, limpo e extremamente intuitivo, fazendo um uso intensivo einteligente de scripts e recursos assíncronos. A interação como o site éextremamente ágil e leve, exatamente como em software desktop. Qualquer açãoefetuada por algum usuário é imediatamente refletida na tela de outros usuáriosconectados 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çasao chat embutido, é possível até conversar com outros colaboradores. O sistema oferece integração com iCal (pode ser integrado com GoogleCalendar 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áriomarque o início e fim de uma tarefa (com botões de start, stop e pause e umcronômetro rodando em tempo real).
  24. 24. Figura 4: Gráfico de Gantt do ClockingIT3.2.2. Web Chamado WebChamado é um software focado no auxilio da evolução de outrosprojetos por meio de abertura e acompanhamento de chamados. Totalmente Web,possibilita o acompanhamento de chamados na internet ou intranet, podendoassim 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 meiode quem abriu o chamado ou pelo responsável envolvido no processo, assim queo chamado sofrer uma iteração automaticamente todas as pessoas envolvidasserão notificadas. Permite um acompanhamento por meio de gráficos estatísticos queauxiliam na tomada de decisão referente a um determinado projeto, como porexemplo em qual período do mês um determinado projeto recebe uma maiorquantidade de chamados, desta forma pode-se ampliar a equipe responsável pelo
  25. 25. projeto a fim de diminuir o tempo de resposta dos chamados abertos nesteperíodo de maior ocorrência de chamados, seja proveniente de correção deproblemas ou solicitação de evolução. Figura 5: Lista de chamados do Web Chamado3.2.3. OpenProj OpenProj é um gerenciador de projetos desenvolvido como alternativa aoMicrosoft Project. Com código aberto, o programa oferece várias opções para ainclusão e administração de todas as atividades co-relacionadas aodesenvolvimento das atividades, apresentando os resultados, em especial, sob oformato de Gráficos de Gantt. Este tipo de gráfico ilustra, na forma de barras, o cronograma de umprojeto, com as datas de início, fim e todas as tarefas atribuídas devidamenteregistradas, sendo, por este motivo, muito utilizado para representar o status atualda programação de um projeto.
  26. 26. OpenProj é uma das melhores iniciativas em se tratando de programas comcódigo aberto para a gerencia de projetos, apresentando todas as opçõesnecessárias para o usuário armazenar suas informações e obter sucesso em seusnegócios. OpenProj é um programa realmente versátil. Com uma interface simplesde usar, o gerenciador de projetos apresenta todas as opções importantes para serealizar uma administração de informações e tarefas a serem cumpridas. Ametodologia aplicada é a de diagramas de Gantt, muito usada na atualidade,podendo ser adaptado para metodologias PMBOK, um conjunto de práticas emgerência de projetos de muita qualidade. Figura 6: Gráfico de Gantt do OpenProj3.3. Documentação Para a criação da documentação, resolvemos no primeiro momento adotaralgum software que realizasse essa tarefa de forma automatizada, agilizando
  27. 27. assim um processo que costumar ser ardiloso de ser implementado. Mas devido afalta de tempo deixado para esta tarefa, a documentação ficou restrita somenteaos comentários situados no código, mas mostraremos as características dosprogramas que exploramos para futura referência.3.3.1. Doxygen Doxygen é um programa que gera a documentação de um programa apartir da analise dos fontes de um programa escrito diversas linguagens. Nestaanálise são reconhecidas declarações de estruturas de dados e funções ecomentários feitos com uma sintaxe especial. Muitas vezes é necessário ter uma documentação externa ao fonte. Se estadocumentação não for gerada de forma automática, é necessário mantersincronizadas três coisas: o código, os comentários e a documentação. Com oDoxygen 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 desaída, como DOC, PDF e CHM.3.3.2. Phpdocumentator O phpDocumentator é uma ferramenta para auto-documentação utilizadocom a linguagem php. Similar ao Javadoc, e escrito em php. O phpDocumentatorpode ser ainda usado na linha de comando ou através de uma interface web paracriar 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 ecriação de código destacado com referência para documentação geral dephp. As tags para a criação da documentação são inseridas através dentro decomentários.
  28. 28. O phpDocumentator usa um sistema de templates extensíveis para mudaros comentários do código fonte em um formato útil para que possamos ler. Essesistema permite a fácil criação para ler o documento em 15 diferentes HTMLdesigners, formato PDF, CHM e em DocBook XML.
  29. 29. 4. Sistema de Integração de Informações Médicas4.1 Cronograma de desenvolvimento Na primeira semana de realização do projeto, começamos a pesquisar qualseria o assunto a ser abordado (metodologias a serem aplicadas) e qual seria otipo de aplicação a ser desenvolvida. Ao final da segunda semana chegamos aconclusão através da analise de diversos projetos que a mistura entre XP e Scrumseria 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 queo software a ser desenvolvido seria do tipo EMR. Da terceira a nona semana, nos dedicamos a pesquisa de softwares queauxiliassem a concepção do projeto, e verificando quais as características quecada software continha, e qual deles se adaptariam de melhor forma a nossasnecessidades. Nesse meio tempo também definimos as bases do projeto, como autilização de php e mysql para criação do mesmo, e quais seriam asfuncionalidades a serem implementadas, com base nas funcionalidades dosprogramas 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 quearmazenaria 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 nenhumadependência de informações sobre elas, pois já estaria definido o formato dasinformações a ser manipulado. Na décima segunda semana até décima oitava semana, trabalhamos naimplementação das funcionalidades desejadas através de scripts de php, além damodelagem da interface, que envolveu a aplicação de CSS para criação de umestilo padrão para o programa. Neste ponto tivemos a ajuda do aluno MoisésDorneles, que foi responsável pela edição das imagens utilizadas.
  30. 30. Os primeiros scripts de php realizados eram referentes estrutura dainterface, pois tentamos estruturar o programa de forma a em qualquer uma dasopções abordadas, se mantivessem diversos elementos em comum. Após,começou o trabalho a como seria feito a entrada no sistema, que ficou sendoatravés de um username e password, sendo que cada username teria atribuídoum nível, que seria relativo a suas permissões quanto a alteração e visualizaçãode dados. Também foi sendo desenvolvido as duas principais entidades a seremmanipuladas, médicos e pacientes, além da implementação de um calendário paraagendamento de consultas. As últimas alterações a serem feitas foram a interfacede administração e de funcionários administrativos, que devido ao tempo nãoforam completamente implementados. As duas últimas semanas saímos fora metodologia habitual devido a ser operíodo de provas da faculdade, e resolvemos parar com os ciclos dedesenvolvimento e nos concentrar apenas nos testes da interface e verificação dacomunicação entre os módulos, dando forma ao produto final. Figura 7: Tela de abertura do SIIM
  31. 31. 5. Conclusão Com o desenvolvimento desse trabalho, podemos como as metodologiaságeis pode ser adaptadas para diferente ambientes, com regras flexíveis e grandeefetivas, se forem exercidas corretamente. A quantidade de ferramentas relativasao processo de desenvolvimento também tem um grande impacto, ajudando arevisão de erros, distribuição de tarefas e a automatização de tarefas relativas aodesenvolvimento. Também observamos a tendência da migração da plataforma dasaplicações para web, devido a infinidade de sistemas e ferramentas suportado poreste tipo de ambiente, possibilitando uma alta disponibilidade sem umadependência de acesso físico ao ambiente a ser implementado. Notamos que apesar de utilizar modularidade durante a codificação doprograma, houve um certo alto nível de dependência entre os módulos, de forma aobrigar quem estava a alterar um módulo de conhecer a estrutura básica dosoutros módulos conectados ao mesmo. Isso é um efeito totalmente indesejável emum 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 serdesenvolvido, e ficou restrito a pequenos comentários ao longo do código, o quetalvez não ajude a entender toda a extensão do programa, demonstrando anecessidade de uma documentação adequada para um melhoramento continuodo 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 dedesenvolvimento, fazendo com que o atraso se propagasse pro outras tarefas); etambém uma particularidade de trabalhar em um ambiente distribuído, que eragarantir comunicação direta entre os membros, o que pode ser feito através desoftwares específicos e planejamento de longo prazo.
  32. 32. Referências Bibliográficashttp://www.extremeprogramming.org/http://www.ime.usp.br/~xphttp://www.softwarereality.com/ExtremeProgrammingRefactored.jsphttp://www.agilemanifesto.org/http://www.improveit.com.br/xp/dissertacaoXP.pdfhttp://www.mountaingoatsoftware.com/scrum/http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdfwww.clockingit.com/http://superdownloads.uol.com.br/windows/empresas/clinicas-farmacias-consultorios.htmlhttp://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.htmlhttp://www.phpdoc.org/

×