Projeto Agenda Saúde Requisitos e Modelagem UML

Transcrição

1 Projeto Agenda Saúde Requisitos e Modelagem UML Clenya Barros Ilo Rivero Lucas Farias Luiz Siviero Jousival Vilela Weverson Machado

2 Histórico de Revisão Versão Data 01/06/09 21/06/09 23/06/09 Revisor Ilo Weverson Lucas Descrição Versão inicial Correções Versão para publicação

3 Sumário 1. Introdução Visão geral deste documento Módulos do Sistema Prioridades dos requisitos Requisitos Funcionais Controle de Acesso e cadastro...6 [RF001] Solicitar acesso inicial ao sistema...6 [RF002] Acessar o sistema...6 [RF003] Alterar senha...6 [RF004] Cadastramento de usuário...6 [RF005] Identificação positiva do usuário/paciente Agendamento de Consultas...7 [RF006] Agendamento de Consultas...7 [RF007] Agendamento de Retorno...7 [RF008] Re-agendamento de consulta ou retorno...7 [RF009] Bloqueio de horários...7 [RF010] Desmarcar consulta Atendimento no Posto de Saúde...8 [RF011] Identificação de presença do usuário/paciente...8 [RF012] Permuta de horários...8 [RF013] Fila de atendimento...8 [RF014] Atendimento Médico Impressões e relatórios...9 [RF015] Receita médica...9 [RF016] Atestados...9 [RF017] Emissão de guias/requisições...9 [RF018] Impressão de Relatórios Requisitos Não Funcionais Requisitos do Produto...11 [NF001] Usabilidade...11 [NF002] Confiabilidade...11 [NF003] Disponibilidade de uso Requisitos do Processo...12 [NF004] Padrões de Desenvolvimento...12 [NF005] Linguagens de Desenvolvimento...12 [NF006] Linguagem de Desenvolvimento para Internet...12 [NF007] Sistema de Banco de Dados...12 [NF008] Ambientes de Desenvolvimento...12 Diagramas UML 4. Diagramas de Caso de Uso Justificativa Diagramas de Caso de Uso Clínicas/Hospitais Diagramas de Caso de Uso Paciente Diagramas de Caso de Uso Posto de Saúde Diagramas de Caso de Uso Secretaria de Saúde Diagramas de Classe Justificativa Diagramas de Classe Diagrama de Atividades Justificativa Diagrama de Atividades Atendimento Diagrama de Atividades Autenticar Diagrama de Atividades Marcar Consulta...19

4 8 Diagrama de Componente Justificativa Diagrama de Componente Diagrama de Seqüência Diagrama de Seqüência Posto Saúde ColaboradorRegistrarPresencaPaciente MedicoRegistrarConsultaPreencherProntuario Diagrama de Seqüência Adminitrador EmissaoRelatorioEstatisticoEGerencial Diagrama de Seqüência Paciente PacienteDesmarcarConsulta PacienteMarcarConsulta...24 Considerações Finais...25

5 1. Introdução Com o propósito de aplicar os conhecimentos no curso de Software Livre e com o intuito de poder fazer uma ferramenta que fosse útil à sociedade, principalmente por que afeta aos menos favorecidos que precisam constantemente do serviço público de saúde e, por sabermos que a maioria dos municípios não contam com sistemas informatizados, foi definido a execução de um software para agendamento de consultas médicas em postos de saúde dos municípios brasileiros. Apesar da informatização ainda não atingir a maioria das pessoas, principalmente em suas residências, mas o crescimento de lugares pagos e de acesso público aliado às escolas públicas, gera uma expectativa de reversão do atual quadro. Este sistema tem como meta permitir que o usuário escolha qual especialidade médica deseja fazer consulta e será possível na tela escolher dia e horário, dentro ou fora do centro de saúde, facilitando e democratizando o atendimento médico. Será realizado um cadastro prévio dos usuários com ficha médica e registros das consultas realizadas. Posteriormente, o sistema deverá ter acesso a rede onde de qualquer posto de saúde poderá ser visualizado o histórico médico do paciente, assim como adicionar novos dados. O agendamento das consultas poderá ser feito em qualquer posto de saúde, via celular ou internet. A metodologia utilizada para execução do processo foi a Ágil de desenvolvimento XP, com modelagem de processos BPMN(Business Process Management Notation) utilizando o Intalio, UML ( Linguagem de Modelagem Unificada) utilizando a ferramenta NetBeans com programação Java. O software foi denominado AgendaSaúde, e foi efetuado o seu desenvolvimento no ambiente Google Code, assim como efetuadas a suas atualizações de configuração. A primeira parte da construção do software foram levantados os requisitos que constitui a principal parte de modelagem, através da compreensão das necessidades do usuário e o que ele deseja que o sistema realize. Como é um software desenvolvido para estudo, os próprios participantes simularam as necessidades, que foram registradas no ambiente de desenvolvimento. Na segunda parte foi efetuado Diagrama de Casos de Uso que utilizou o Levantamento e os Requisitos anteriores, melhorando assim o entendimento do processo e facilitando o seu uso posterior. O terceira parte do desenvolvimento foi efetuado o Diagrama de Classes que definiu a estrutura de classes utilizadas pelo sistema, atributos e métodos possuídos por cada classe e o relacionamento entre elas. Na quarta parte, foi efetuado o Diagrama de Seqüência que tem o objetivo de verificar a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo. Foi baseado nos casos de uso anteriores e no Diagrama de Classes para determinar os objetos das classes envolvidas. A quinta parte dos Diagramas foi realizado o Diagrama de Estado que é utilizado para acompanhar os estados por que passa uma instância de uma classe ou estados de um caso de uso ou estados gerais de um sub-sistema ou mesmo o sistema completo. A sexta parte foi efetuado o Diagrama de Atividades utilizando o BPMN e a ferramenta Intalio, descrevendo os passos a serem percorridos para a conclusão de uma atividade específica, representando o fluxo de controle das atividades. Como último Diagrama desta modelagem do processo do AgendaSaúde, foi realizado o Diagrama de Componentes que está associado à linguagem de programação que será utilizada para desenvolvimento do sistema. Na última parte foi realizada a conclusão do presente trabalho. Este documento especifica o sistema AgendaSaúde a ser desenvolvido para a UFLA. Seu propósito é colecionar, analisar e definir as necessidades do cliente e as características de alto nível que o sistema deve prover, focando nos requisitos técnicos identificados e no motivo destes existirem. 1.1 Visão geral deste documento Abaixo estão descritas as seções que compõem este documento: Seção 2 Requisitos funcionais: lista os requisitos funcionais do sistema, especificando seus objetivos e prioridades. Seção 3 Requisitos não funcionais: especifica todos os requisitos não funcionais do sistema, divididos em requisitos de usabilidade, confiabilidade, desempenho, segurança, distribuição, adequação a padrões e requisitos de hardware e software. 1.2 Módulos do Sistema O sistema é composto por três módulos interconectados: S001 - Módulo da Secretaria de Saúde

6 Neste módulo é feito o cadastramento dos postos de saúde, bem como senhas, permissões de acesso, cadastramento de usuários do posto de saúde, cadastramento de médicos e especialidades médicas disponíveis em cada posto. S002 - Módulo do Posto de Saúde, dividido em duas partes: S002.1 Módulo de atendimento: Neste módulo é efetuado o cadastramento dos pacientes da região, o agendamento de horários quando o paciente comparecer ao posto, remarcação de horários, acesso a ficha médica do paciente. S002.2 Módulo de atendimento médico: Este módulo possibilita ao médico acessar a ficha médica do paciente, acrescentar informações a essa ficha, prescrever receitas e exames médicos, bem como imprimir receitas e requisições de exames e atestados. S003 Módulo do Usuário/Paciente: Este módulo é acessado via internet, onde o usuário/paciente poderá fazer seu pré-cadastro, e após os dados serem confirmados pelo posto de saúde, poderá solicitar reservas de horários para consultas médicas 1.3 Prioridades dos requisitos Para estabelecer a prioridade dos requisitos foram adotadas as denominações essencial, importante e desejável. A prioridade dos requisitos é utilizada no gerenciamento do escopo das etapas do projeto e na definição das prioridades durante o desenvolvimento do sistema. Essencial: requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, devem ser implementados desde as primeiras implantações do sistema. Importante: requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implantados o mais rápido possível, mas, se não forem, parte do sistema poderá ser implantada mesmo assim. Desejável: requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser implantados por último, sem comprometer o funcionamento do sistema.

7 2. Requisitos Funcionais 2.1 Controle de Acesso e cadastro Esta seção agrupa os requisitos funcionais associados ao controle de acesso dos usuários. [RF001] Solicitar acesso inicial ao sistema S002.1, S002.2 Os funcionários do posto de saúde, atendentes e médicos, bem como os postos de saúde, deverão ser cadastrados pela Secretaria de Saúde, no qual receberão um login e senha para poderem acessar o sistema no posto de saúde específico. [RF002] Acessar o sistema S002.1, S002.2,S003 Para acessar o sistema, deve-se informar o login e a senha corretos e login e a senha serão validados para permitir o acesso. [RF003] Alterar senha S002.1, S002.2,S003 O sistema permitirá a alteração de senha pelo usuário, contanto que o mesmo informe a senha atual e a nova senha, esta última deverá ser digitada duas vezes e serão comparadas para evitar inconsistências. Essencial Importante Desejável [RF004] Cadastramento de usuário S002.1, S003 O cadastramento deverá ser feito informando nome completo, número do Cartão Nacional do SUS, endereço completo, telefone para contato, telefone celular, tipo sanguineo, documento de identidade com órgão emissor, nome de uma pessoa para contato, endereço de e uma senha, esta última digitada duas vezes para evitar inconsistências. O status do cadastro ficará marcado como DOCUMENTAÇÃO PENDENTE até que seja apresentado no posto de saúde documentos para a identificação positiva do paciente. [RF005] Identificação positiva do usuário/paciente S002.1 O sistema permitirá a alteração do cadastro do paciente, com a modificação do status do cadastro de DOCUMENTAÇÃO PENDENTE para DOCUMENTAÇÃO CONFERIDA. Essa alteração poderá ser feita em qualquer visita do paciente ao Posto de Saúde ou na primeira consulta. 2.2 Agendamento de Consultas

8 [RF006] Agendamento de Consultas S002.1, S003 O usuário, após sua identificação no sistema, poderá marcar apenas um horário e uma especialidade médica, onde deverá ser apresentado ao usuário a relação dos horários disponíveis. [RF007] Agendamento de Retorno S002.1 O atendente do posto de saúde poderá marcar uma ou mais datas de retorno de acordo com as datas estipuladas pelo médico. É necessária a identificação do paciente. [RF008] Re-agendamento de consulta ou retorno S002.1 O atendente do posto de saúde poderá alterar a data de uma consulta ou retorno do paciente ao médico especificado, no caso de solicitação do paciente, do médico ou da ausência de algum deles. É necessária a identificação do paciente. [RF009] Cadastramento e Bloqueio de horários S001, S002.1 O atendente do posto de saúde ou secretaria de saúde poderá marcar ou bloquear um ou mais horários ou faixa de horários para um ou mais médicos ou especialidades, para utilização interna do posto de saúde, a critério da administração do posto ou dos médicos. [RF010] Desmarcar consulta S002.1,S003 O atendente do posto de saúde poderá cancelar uma ou mais datas de retorno a pedido do usuário/paciente, sendo que a solicitação poderá ser feita diretamente no posto ou pela Internet. [RF011] Consultar horários marcados S002.1, S002.2,S003 O sistema deverá permitir a consulta dos horários já marcados

9 2.3 Atendimento no Posto de Saúde [RF011] Identificação de presença do usuário/paciente S002.1 O atendente do posto de saúde registrará a presença do usuário/paciente no sistema após a identificação positiva dele, colocando-o na sequência de atendimento pré-definida. [RF012] Permuta de horários S002.1 O atendente do posto de saúde poderá permutar o horário de um paciente com outro, caso seja solicitado pelos pacientes ou caso um paciente não esteja no posto no horário pré-determinado. [RF013] Fila de atendimento S002.1, S002.2 O atendente do posto de saúde e o médico deverão ser informados pelo sistema da ordem de atendimento, bem como deverá ser mostrado visualmente os pacientes que faltaram e os que já foram atendidos [RF014] Atendimento Médico S002.2 A cada atendimento, o médico receberá do sistema a ficha médica do usuário/paciente, e poderá incluir informações sobre a consulta, exames solicitados, bem como observações e informações adicionais sobre o paciente.

10 2.4 Impressões e relatórios [RF015] Receita médica S002.2 O médico poderá prescrever e imprimir receitas médicas no sistema. As receitas serão armazenadas pelo sistema e vinculadas a ficha do paciente. [RF016] Atestados S002.2 O médico poderá digitar e imprimir atestados médicos a pedido do paciente. Os atestados serão armazenados pelo sistema e vinculados a ficha do paciente. [RF017] Emissão de guias/requisições S002.2 O médico poderá imprimir guias de internação, bem como requisições de exames, que também ficarão armazenadas e vinculadas a ficha do paciente. [RF018] Impressão de Relatórios S001, S002.1,S002.2 O atendente do posto de saúde, médicos e secretaria de saúde poderão imprimir relatórios: pacientes atendidos, pacientes ausentes, número de atendimentos, estatísticas de atendimento e quantidade de exames solicitados. O sistema deverá permitir a configuração e escolha dos dados a serem impressos.

11 3. Requisitos Não Funcionais 3.1 Requisitos do Produto [NF001] Usabilidade S001, S002.1, S002.2, S003 Deve ser oferecida uma interface amigável, considerando as diferentes características sociais,econômicas e culturais dos potenciais usuários deste sistema. A navegabilidade entre as telas deve ser simples e de fácil entendimento [NF002] Confiabilidade S001, S002.1, S002.2, S003 As informações apresentadas pelo sistema, assim como os resultados gerados a partir da interação do usuário devem ser corretos. [NF003] Disponibilidade de uso S001, S002.1, S002.2, S003 O sistema deve estar disponível 24 horas por dia e 7 dias na semana.

12 3.2 Requisitos do Processo [NF004] Padrões de Desenvolvimento S001, S002.1, S002.2, S003 O sistema deverá ser desenvolvido utilizando as notações BPMN, UML bem como o processo de desenvolvimento Extreme Programming (XP) [NF005] Linguagens de Desenvolvimento S001, S002.1, S002.2 O sistema deverá ser desenvolvido utilizando a linguagem de programação JAVA Essencial Importante Desejável [NF006] Linguagem de Desenvolvimento para Internet S003 O sistema deverá ser desenvolvido utilizando a linguagem de programação JAVA - JSP Essencial Importante Desejável [NF007] Sistema de Banco de Dados S001, S002.1, S002.2, S003 O sistema deverá ser utilizado o sistema de banco de dados MySQL nos postos de saúde, com replicação no servidor da Secretaria de Saúde. O acesso ao banco de dados pela internet será feito através da Secretaria de Saúde. [NF008] Ambientes de Desenvolvimento S001, S002.1, S002.2, S003 Deverão ser utilizadas as ferramentas NetBeans e Intalio BPMN Essencial Importante Desejável

13 Diagramas de Caso de Uso Justificativa Foi escolhido a criação de Casos de Uso pelo fato dele modelar como as pessoas esperam usar o sistema descrevendo quem são os usuários relevantes, os serviços que eles exigem e que precisam oferecer ao sistema. Foi criado também para nos auxiliar a identificar todos os recursos que o sistema deve possuir baseados no que os clientes querem, identificando as expectativas dos clientes, identificando recursos específicos, mostrando o comportamento compartilhado entre os recursos do sistema e mostrando de forma simples os requisitos aos clientes para validação do sistema.

14

15

16

17 Diagramas de Classes Justificativa A criação de diagramas de classe se deve ao fato dele modelar as definições dos recursos essenciais à operação correta do sistema modelando os recursos usados para montar e operar o sistema onde cada recurso é modelado em termos de sua estrutura, relacionamentos e comportamentos, além dele ser o principal diagrama de captura de todas as regras que governam a definição e o uso dos obejtos do sistema. Em resumo criamos os diagramas de classe por eles nos auxiliarem na definição dos recursos essenciais do sistema, por gerar e modelar o código fonte e principalmente por oferecer um foco para outros possíveis diagramas que venham ser construídos.

18 Diagrama de atividades Justificativa O diagrama de atividades foi escolhido para descrever o processo que envolve o sistema. Para se construir escrever ou gerar código é preciso entender o processo, por isso a escolha do diagrama de atividades. Ele foi escolhido também por ser visto como parte da visão funcional do sistema por descrever os processos lógicos ou funções. Nossos diagramas descrevem a lógica exigida para implementar comportamentos do sistema, auxiliando-nos no entendimento do processo para que possa ser construído o código do projeto. Diagrama de Atividades - Atendimento

19 Diagrama de Atividades -Autenticar Diagrama de Atividades -Marcar Consulta

20 Diagrama de componentes Justificativa Este diagrama foi escolhido por representar partes do software no ambiente de implementação. Outros diagramas modelam o projeto lógico, mas este diagrama modela a visão da implementação. São importantes por modelar o software real no ambiente de implementação, auxilia na configuração de software através de seus relacionamentos de dependência e nos fornece uma imagem precisa do sistema antes de serem efetuadas mudanças ou melhorias. Auxilia também na divisão de tarefas entre a equipe. Esses forma os motivos que nos levaram a construir tal diagrama.

21 Diagramas de Sequência Justificativa Escolhemos o diagrama de sequência para esclarecer à equipe as interações entre os objetos orientada ao tempo, assim podemos identificar como os objetos enviam mensagens um para o outro facilitando na correção de possíveis falhas no sistema e auxiliando mais ainda na construção do sistema podendo até evitar que tais falhas possam aparecer. Diagramas de Sequência - Posto Saúde ColaboradorCadastrarPaciente

22 ColaboradorRegistrarPresencaPaciente MedicoRegistrarConsultaPreencherProntuario DiagramaSequencia Administrador EmissãoRelatórioEstatisticosEGerencial

23 DiagramaDeSequencia-Paciente PacienteDesmarcarConsulta PacienteMarcarConsulta

24

25 Considerações Finais O presente documento de requisitos é considerado o documento base proposto para a construção do sistema AgendaSaúde, especificando os requisitos utilizados no desenvolvimento do software, fornecendo à equipe de desenvolvedores informações necessárias para a execução do mesmo, ou seja, ditando as regras do que deverá ser feito. É primordial que este documento seja (tenha sido) analisado pelos clientes, gestores e engenheiros para que assim possa haver uma integração entre o que se deseja e o que será sendo desenvolvido, visando verificar junto ao cliente se todos os requisitos listados neste são válidos e estão bem entendido por ambas as partes. Neste encontramos especificações em relação ao sistema proposto, tais como: o comportamento externo, os requisitos funcionais e não-funcionais, as restrições de implantação, entre outros. Portanto, consideramos, mediante todo o levantamento mostrado neste documento, que o desenvolvimento do sistema AgendaSaúde é viável sob o ponto de vista tecnológico, trazendo contribuição satisfatória para o seu público alvo.