Engenharia de Software para Sistemas de Informação em Saúde

Transcrição

1 Engenharia de Software para Sistemas de Informação em Saúde Renata Granato da Costa Bergamin 1, Ricardo A. Quintano Neira 2, Adriana C. Martins Mendoza Cuellas 3, Fabiane Bizinella Nardon 4 1,2,3,4, Brasil Resumo Este artigo apresenta um processo de desenvolvimento de sistema de informação em saúde, mostrando que é possível fazer especificações em menos tempo e também que é possível reutilizar especificações em outras aplicações. São apresentados resultados obtidos, benefícios do processo, problemas e soluções encontradas. Palavras-chave: Engenharia de Software, Padrões em Informática em Saúde, Sistemas Computadorizados de Registros Médicos. Abstract This paper presents a process of development of health information system, showing that is possible make specifications in less time and also that is possible reuse specifications in other applications. Solutions, advantages of the process, difficulties and solutions encountered will be presented. Key-words: Software Engineering, Standards on Healthcare Informatics, Computerized Medical Records Systems. Introdução O processo exposto neste trabalho foi planejado com o objetivo de atender as necessidades de um desenvolvimento baseado em componentes Os componentes são definidos como sistemas independentes que apresentam um conjunto de funcionalidades claras e bem definidas. Os componentes quando agrupados com outros componentes podem apresentar funcionalidades extras. Como exemplo tem-se o componente de endereço que é utilizado no cadastro de pacientes, de profissionais, pessoa jurídica entre outros. Durante todo o processo de especificação existe a preocupação de especificar funcionalidades que possam se tornar componentes de software que serão reutilizados em outras aplicações desenvolvidas pela empresa. Cada nova funcionalidade especificada é adicionada ao repositório de componentes em saúde da empresa. Este processo tem como premissas básicas utilizar o Rational Unified Process [1] e UML (Unified Modeling Language) [2] [3] [4], tendo como artefato central a especificação de casos de uso que apresentam uma descrição detalhada dos componentes. Este processo utiliza a ferramenta case Enterprise Architect [5], integrada com o subversion [6] e com o DocToR (Documents To Report). O Enterprise Architect é uma ferramenta que permite a documentação de casos de uso, de casos de teste, criação de esboços de tela, entre outros recursos. O subversion é um sistema de controle de versões que permite que diversas pessoas trabalhem simultaneamente e o DocToR é uma ferramenta interna da empresa que permite converter XML gerado pelo Enterprise Architect em documentos de caso de uso, caso de teste, regras de negócio e requisitos de software no formato PDF. Muitos pontos deste processo surgiram em função de problemas encontrados em experiências anteriores como a especificação do projeto SIGA Saúde [7] [8]. Durante a especificação do SIGA Saúde se utilizava o Enterprise Architect para criar todos os diagramas e descrições para, em um momento posterior, estes diagramas e descrições serem copiados para um template em formato Word que é artefato para o cliente entregue para o cliente. Despendia-se um tempo elevado neste processo e, a cada nova atualização de funcionalidade era necessário alterar o conteúdo no Enterprise Architect assim como do documento Word correspondente. Este processo gerava uma quantidade elevada de erros já que era totalmente manual. Em épocas de alta demanda de trabalho, ocorreu a apenas a atualização do documento Word para economizar tempo. Assim não se podia mais confiar no conteúdo do Enterprise Architect visto que em muitos casos estava defasado. Este trabalho tem como objetivo descrever o processo de trabalho de engenharia de software para desenvolver sistemas de informação em saúde. Para resolver o problema da geração de documentos e eliminar o processo de cópia de conteúdo, uma ferramenta foi desenvolvida

2 internamente para automatizar a geração de documentos a partir do Enterprise Architect, o DocToR. O DocToR permite gerar duas versões de documentos de casos de uso, uma para o cliente apenas com informações necessárias para entendimento da funcionalidade e outra contendo além das informações da versão para o cliente, informações específicas para a equipe de desenvolvimento como, por exemplo, o domínio, nomes de campos, ícones, etc. Metodologia act Fluxo Geral Regras de Negócio Início Lev antamento de Funcionalidades Casos de Uso Caso de Teste Funcional Arquitetura em Saúde Arquitetura de Software Implementação Final Requisitos Figura 1 Representação das Atividades do Processo Participam deste processo quatro áreas que são: Negócios: responsável por identificar o as funcionalidades que um módulo deve apresentar. Análise e Especificação: responsável por aprofundar o conteúdo de um módulo da aplicação e gerar os artefatos de regras de negócio, requisitos de software, casos de uso e casos de teste. Arquitetura em Saúde: responsável por identificar os padrões (vocabulários, conteúdo e comunicação) que serão utilizados nos sistemas assim como é responsável pela visão de integração entre módulos. Desenvolvimento: responsável por implementar os casos de uso. O processo de engenharia de software tratado neste trabalho apresenta quatro etapas, as quais são descritas abaixo: 1. Definição do Negócio O processo de especificação tem início com a atividade de levantamento de funcionalidades que consiste na realização de uma reunião (reunião de negócios) com áreas de negócio, análise e arquitetura para discussão das funcionalidades essenciais do sistema e definição de como deve ser o sistema do ponto de vista de negócio. Quando necessário, são envolvidos consultores externos, especialistas no negócio da aplicação. Nesta fase é elaborada pelo analista de requisitos a especificação de negócios da aplicação, que passa por uma validação da área de negócios antes que as demais fases tenham início. A especificação de negócios surgiu da dificuldade que existia de delimitação de escopo. Aplicações para a área de saúde são bastante complexas e existe sempre a necessidade de adequação a diferentes cenários e processos de trabalho apresentados por cada estabelecimento e saúde. Delimitar o escopo de uma aplicação para a área de saúde é uma tarefa complexa e ao longo do tempo descobriu-se que somente os meios oferecidos pela UML como listas de regras de negócio e listas de requisitos de software não eram suficientes além de gerar re-trabalho na alteração das especificações depois de prontas. Criou-se então a especificação de negócios, um documento que relaciona tudo o que é necessário ter na aplicação para que ela funcione e atenda às necessidades de qualquer estabelecimento de saúde. O documento de negócios relaciona os principais conceitos e definições do negócio, storybords com exemplos fictícios de processos do sistema, os papéis que as pessoas desempenham, a delimitação do escopo a ser desenvolvido e integrações com outros sistemas.

3 Com base na especificação de negócios acontecem as demais fases do processo de especificação, que são as fases da UML. As atividades seguintes do processo são o levantamento de regras de negócio e levantamento de requisitos que acontecem simultaneamente. As listas de regras de negócios e requisitos têm sua versão inicial gerada durante a reunião de negócios e são complementadas nesta fase do processo. As regras de negócio e os requisitos necessários para construir a aplicação são identificados, registrados no Enterprise Architect e posteriormente é gerado um documento de regras de negócio e um documento de requisitos, a partir do próprio Enterprise Architect utilizando o DocToR. uc UC Manter Registros de Profissional de Saúde UC Manter Registros de Atendimento UC Consultar Atendimentos Alterar Registro de «include» «include» Cancelar Registro de Manter Registros de Visualizar Registro de Registrar Após serem elaborados, os documentos de regras de negócio e de requisitos passam por validação e aprovação da área de negócio da empresa e depois são encaminhados para validação e aprovação pelo cliente. Estes dois documentos formalizam o escopo do projeto com o cliente. É importante ressaltar que embora seja a lista de requisitos o instrumento utilizado para fechamento de escopo junto ao cliente, uma lista de requisitos não é fechada completamente na fase inicial da especificação do sistema, novos requisitos poderão surgir ao longo da especificação do sistema e estes deverão ser acrescentados à lista, mantendo-a sempre atualizada. Outro ponto importante com relação aos requisitos, é que os requisitos não funcionais são identificados e registrados na lista de requisitos, pois eles também ajudam a construir o software. 2. Definição dos casos de uso Após a validação das regras de negócio e requisitos, tem início a atividade de especificação de casos de uso que consiste em definir os casos de uso necessários para a construção do sistema. Cada caso de uso identificado é preparado utilizando o Enterprise Architect para criar os diagramas e esboços de tela, assim como para registrar as descrições do caso de uso e requisitos especiais. Durante a atividade de especificação de caso de uso são gerados os seguintes produtos: Diagrama de caso de uso com a respectiva descrição e com os cenários primário e secundários definidos e descritos com as précondições, pós-condições, requisitos e requisitos especiais necessários para implementação do sistema; Figura 2 Exemplo de Diagrama de Caso de Uso Esboços de tela definidos e descritos; Figura 3 Parte de Um Esboço de Tela Diagrama com o fluxo navegacional de telas; analysis UC Manter Registros de Profissional de Saúde Tela da Lista de Trabalho (UC00148) Tela de Consulta de Atendimentos (UC00088) Registrar Alterar Visualizar Cancelar Localizar Registro Tela de Edição de Registro de Tela de Confirmação de Cancelamento Gravar Cancelar Registro de Figura 4 Exemplo de Diagrama de Fluxo de Navegação de Telas Documento de especificação de caso de uso (versão cliente e versão desenvolvimento); Documento de atores atualizado com os atores do caso de uso especificado;

4 Figura 5 Versão Cliente: Sem Informações de Domínio e Permissões uso. Este documento apresenta as integrações com outros módulos e sistemas, um diagrama com todas as entidades e atributos e o domínio que será utilizado. Também são ajustados os documentos de caso de uso para a inclusão de informações exclusivas para o desenvolvimento. Todos os documentos até o momento especificam componentes que podem ser reutilizados em diferentes sistemas, assim todos são identificados com um seqüencial único da empresa (GID Global Identifier). class icd parent Figura 6 Versão Desenvolvimento: Com Informações de Domínio e Permissões Glossário do projeto atualizado com termos utilizando no caso de uso. No final desta etapa é realizada uma reunião de validação dos casos de uso, onde as equipes de negócio, análise, arquitetura em saúde e desenvolvimento discutem os casos de uso. Ao final o analista de requisitos faz os ajustes necessários nos casos de uso, finalizando esta etapa. 3. Definição dos Casos de Testes A próxima atividade do processo é a especificação de caso de teste funcional. Para cada caso de uso do sistema é elaborado um caso de teste funcional. O caso de teste também é criado no Enterprise Architect, utilizando os recursos oferecidos pela ferramenta e em seguida é gerado o documento de caso de testes utilizando o DocToR. Este documento de caso de teste apresenta os objetivos, pré-requisitos para executar os testes e possíveis cenários de testes detalhados passo a passo. 4. Definição da Arquitetura em Saúde Com o objetivo de manter os sistemas seguindo os padrões em saúde nacionais e internacionais existes, a etapa de arquitetura em saúde. Nesta etapa são definidos os domínios da aplicação com um estudo aprofundado nos padrões existentes e sempre buscando formas de tornar os componentes os mais genéricos possíveis para qualquer país. Um exemplo é o componente endereço que deve se ajustar para qualquer país. Assim o Brasil apresenta logradouro, complemento, estado, município e CEP enquanto que em Angola existe residência, número, município e província. Esta etapa cria o documento de arquitetura que agrupa um conjunto de casos de entity:: ICD_HIERARCHICAL_LEV EL - chapter: TEXT = 20 - descriptor: TEXT = 200 hierarchicallevel entity::diagnosis - code: TEXT = 5 - descriptor: TEXT = 200 Figura 7 Diagrama de Domínio 5. Desenvolvimento de Software Nesta etapa a equipe de desenvolvimento inicia a arquitetura de software onde o arquiteto de software responsável faz um estudo nos documentos de caso de uso e arquitetura de saúde e cria um documento que apresenta instruções para os desenvolvedores de quais componentes utilizarem, quais os novos componentes. Em seguida o componente é desenvolvido e é iniciada a fase de testes. 6. Execução de Testes Funcionais Uma vez desenvolvido e instalado em servidor institucional o sistema passa por quatro seqüências de testes: Checklist: o sistema é validado seguindo uma seqüência pré-definida e padrão: campos obrigatórios, layout da tela, identificadores da tela, funcionamento básico dos eventos. Teste utilizando o caso de teste: o sistema é validado seguindo a seqüência de passos indicados no caso de teste. 1

5 Aprovação pelo analista de requisitos: o analista que especificou o caso de uso faz um teste completo na aplicação. Resultados No início da implantação deste processo existiu muita resistência dos analistas porque eram muitos detalhes, muitas informações para serem registradas no Enterprise Architect para que fosse permitida a geração automática de documentos utilizando o DocToR, porém, com o tempo os analistas se adequaram ao processo e passaram a contribuir com a sua evolução sugerindo melhorias e fazendo críticas ao processo. Após um ano de existência viu-se que o processo ajudou muito, reduzindo o tempo de especificação de um caso de uso de cadastro, por exemplo, que tem as operações de inclusão alteração, exclusão e consulta que era de aproximadamente nove horas para quatro horas. Para cada caso de uso criado no Enterprise Architect, a ferramenta gera um XML e muitos analistas ao invés de começar a especificação de um caso de uso de cadastro do zero, editam o arquivo XML, de outro caso de uso de cadastro já especificado e fazem as alterações necessárias para o novo cadastro, reduzindo ainda mais o tempo de especificação que em alguns casos passa a ser de duas horas. O documento de arquitetura em saúde mostrou-se muito útil para a equipe de desenvolvimento visto que tem uma visão de todas as entidades envolvidas na aplicação assim como todas as integrações. O documento de arquitetura em saúde passou por adequações para auxiliar ainda mais no trabalho dos desenvolvedores e hoje, por exemplo, é indicado no documento o tipo de integração entre sistemas, se forte ou franca. Os resultados obtidos com o processo foram comprovados através da utilização da ferramenta JIRA [9] que faz o controle de pendências e de tempo gasto em atividades. A ferramenta permite a geração de relatórios que foram utilizados para comparação de tempos gastos em especificações antes e depois da implantação deste processo. Também foram realizadas reuniões individuais e coletivas com os analistas para discutir a percepção do processo. Um problema deste processo são os casos de testes. Com o tempo viu-se que os casos de testes gerados utilizando Enterprise Architect não são muito eficientes, é difícil alimentar os resultados do teste, leva muito tempo para criar o caso de teste e o resultado final obtido com o caso de teste não é bom e não justifica o tempo gasto na sua especificação. Outra dificuldade que enfrentada é com relação à criação de esboços de tela no Enterprise Architect, pois a ferramenta não é muito amigável para este tipo de diagrama e gasta-se muito tempo atualmente desenhando telas na ferramenta. Discussão e Conclusões Com este processo foi possível reduzir o tempo de especificação de uma aplicação, assim como reutilizar especificações de caso de uso. Para solucionar o problema dos testes casos de testes está em implantação o uso da ferramenta Testlink [10] que permite adicionar os resultados de cada um dos testes executados e permite visualizar os resultados globais da execução dos testes. Os analistas de testes ao encontrar um novo cenário adicionam na ferramenta para posterior revisão de um comitê de testes que avalia se o cenário será ou não incorporados aos testes da aplicação. Está em estudo a possibilidade de utilização de um plug-in do Enterprise Architect que é próprio para criação de protótipos de tela para resolver o problema da criação de esboços de tela. Acredita-se que com este plug-in o tempo de especificação ficará ainda mais reduzido. Agradecimentos Agradeço a toda a equipe Zilics pelas críticas e sugestões que ajudaram a construir e aprimorar este processo de especificação. Referências [1] Kruchten P. Introdução ao RUP Rational Unified Process. Editora Ciência Moderna [2] Booch G, Rumbaugh J, Jacobson I. UML - Guia do Usuário. Editora Campus [3] Pender, Tom, UML - A Bíblia / CAMPUS. [4] Guedes, Gilleanes T. A., UML - Uma Abordagem Prática. Editora Novatec. 3ª Edição. [5] Enterprise Architect, [6] Subversion, [7] Ricardo Alfredo Quintano Neira, Paulo Roberto de Lima Lopes, Adriano de Jesus Holanda, Márcia Treglia, Henrique Manuel Lederman, Paulo Schor, Ivan Torres Pisa. Construção e Avaliação de Ferramenta de Teleconsulta Assíncrona Multi-especialidades. CBIS -

6 [8] Medeiros, Rogerio, Heloisa Helena A. Corral. A Saúde de São Paulo entra na era do bit!!!! CBIS - [9] JIRA, [10] Testlink, Contato Renata Granato da Costa Bergamin renata.granato@zilics.com.br ricardo.neira@zilics.com.br Adriana Cláudia Martins Mendoza Cuellas adriana.martins@zilics.com.br Fabiane Bizinella Nardon fabiane.nardon@zilics.com.br Ricardo Alfredo Quintano Neira