Projeto Integrado Multidisciplinar Unip Sistema de teleatendimento médico - Nota 9.5

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas 
 
 
MARIANA SCORALICH MARTINS – 0559850 
MEDHOME: TELEATENDIMENTO MÉDICO 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Polo Juiz de Fora 
2021 
 
 
MARIANA SCORALICH MARTINS – 0559850 
MEDHOME: TELEATENDIMENTO MÉDICO 
 
 
 
 
 
 
 
 
 
Projeto Integrado Multidisciplinar para 
obtenção do título de tecnólogo em Análise 
e Desenvolvimento de Sistemas 
apresentado à Universidade Paulista – 
UNIP EaD. 
Orientadora: Profa. MSc. Priscila Facciolli 
 
 
 
 
 
 
 
Polo Juiz de Fora 
2021 
 
 
RESUMO 
 O Presente trabalho vem demonstrar a aplicação prática das disciplinas de 
Empreendedorismo, Programação Orientada a Objetos e Gestão de Negócios na 
criação de um software de teleatendimento médico. 
 O sistema deverá permitir um acesso simplificado, em um ambiente seguro, 
onde médicos e pacientes poderão trocar informações e orientações, evitando o 
deslocamento desnecessário até uma unidade de saúde, requer apenas um 
computador ou smartphone e acesso à Internet para utilizar a aplicação. 
Foi elaborado um plano de negócios, a demonstração dos diagramas mais 
importantes e os detalhamentos dos casos de uso. 
 As principais telas de usuários também estão prototipadas, usando a 
ferramenta Justmind. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Palavras-chave: SGBD. Teleatendimento. Coronavírus. Medicina. Sistemas de 
Informação. 
 
 
ABSTRACT 
This work demonstrates the practical application of the disciplines of 
Entrepreneurship, Object Oriented Programming and Business Management in the 
creation of a medical teleservice software. 
The system should allow simplified access, in a safe environment, where 
doctors and patients can exchange information and guidance, avoiding unnecessary 
travel to a health unit, requires only a computer or smartphone and internet access to 
use the application 
A business plan was prepared, a demonstration of the most important diagrams 
and details of the use cases. 
 The main user screens are also prototyped, using the Justmind tool. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Keywords: SGBD. Telecare. Coronavirus. Medicine. Information Systems. 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO ......................................................................................... ......... 06 
2. TERMO DE ABERTURA DO PROJETO .......................................................... 07 
2.1. Visão .................................................................................................... 07 
2.2. Objetivos ............................................................................................. 07 
2.3. Usuários............................................................................................... 07 
2.4. Clientes .............................................................................................. 07 
2.5. Papéis de Responsabilidades .......................................................... 08 
2.6. Matriz de Responsabilidades ........................................................... 08 
2.7. Cronograma de atividades e custos ................................................ 09 
2.8. Análise de riscos ............................................................................... 09 
2.8.1. Identificando os Riscos .................................................................... 09 
2.9. Lições Aprendidas ............................................................................ 10 
3. PLANO DE NEGÓCIO ..................................................................................... 12 
3.1. Conceitos ........................................................................................... 12 
3.2. Apresentação ..................................................................................... 12 
4. DESENVOLVIMENTO DO SISTEMA ............................................................... 13 
 4.1. Requisitos Não Funcionais .............................................................. 13 
 4.2. Requisitos Funcionais ...................................................................... 13 
 4.3. Regras de Negócios .......................................................................... 14 
 4.4. Casos de Uso ..................................................................................... 15 
 4.4.1. Diagramas de Casos de Uso ............................................................ 18 
 4.5. Diagrama de Atividades .................................................................... 18 
 
 
 4.6. Diagrama de Classes ......................................................................... 20 
 4.7. Diagrama de Sequência ..................................................................... 21 
4.8. Diagrama de Componentes ............................................................... 22 
4.9. Diagrama de Implementação ............................................................. 23 
5. INTERAÇÃO COM O USUÁRIO ............................................................. 24 
5.1. Tela de Login ....................................................................................... 24 
5.2. Tela de Agendamento ......................................................................... 24 
5.3. Tela de Prontuário .............................................................................. 25 
 CONCLUSÃO .............................................................................................. 26 
 REFERÊNCIAS ........................................................................................... 27 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 
 
1. INTRODUÇÃO 
 A pandemia do novo coronavírus trouxe grandes mudanças mundiais. Diversos 
protocolos foram criados visando a proteção e a diminuição do contágio pelo COVID-
19. 
Uma das medidas mais importantes trata do distanciamento social, onde deve-
se evitar o máximo possível estar em meio a aglomerações e só sair de casa para o 
estritamente necessário. 
Visando manter a segurança dos pacientes, foi solicitada a elaboração de um 
sistema de teleatendimento, seguindo as recomendações do Ministério da Saúde, em 
acordo com o Conselho Federal de Medicina, permitindo que o paciente possa receber 
orientação e acompanhamento sem a necessidade de se deslocar até um posto de 
atendimento físico, mantendo todas as regras do atendimento presencial, como sigilo 
profissional e registro do atendimento em um prontuário. Este sistema também deverá 
permitir a troca de informações entre os profissionais de saúde (interconsultas). 
Sendo a telemedicina regulamentada pela Lei 1.643 de 2002, muito há o que 
se de desenvolver no quesito segurança e abrangência, já que inicialmente, só era 
permitido o teleatendimento em áreas remotas e não compreendia os avanços 
tecnológicos. 
Baseando em conhecimentos técnicos, elaborou-se o desenvolvimento do 
sistema MedHome: Teleatendimento Médico. 
 
 
 
 
 
 
 
 
7 
 
2. TERMO DE ABERTURA DE PROJETO 
Projeto de Implantação do Sistema HomeMed de teleatendimento médico 
2.1. Visão 
 Desenvolver um sistema de teleatendimento médico à distância, que permita o 
atendimento por videochamada ou mensagem e que guarde as informações dos 
usuários em um banco de dados. 
2.2. Objetivos 
O HomeMed tem como objetivo auxiliar no atendimento médico aos pacientes 
no modo remoto, facilitando ao paciente sanar dúvidas sem a necessidade de sair de 
sua casa e diminuindo o risco de contágio pela circulação do vírus da COVID 21. 
O atendimento será por meio de videochamada ou chat. 
Todos os dados de usuários e prontuários de atendimento deverão ser salvos 
no sistema. 
2.3. Usuários 
 Médicos e pacientes cadastrados. 
2.4. Clientes 
• Convênios médicos 
• Planos de Saúde 
• Ministério da Saúde – SUS 
• Clínicas Particulares 
• Hospitais Particulares 
2.5. Papéis de ResponsabilidadesA equipe é composta por Arquiteto, Analista e Gerente de Projetos, seguindo as 
seguintes atribuições: 
• Arquiteto: 
✓ Coordenar o projeto técnico do sistema e tomar as decisões técnicas; 
✓ Identificar e documentar os aspectos significativos para a arquitetura do 
sistema; 
8 
 
✓ Justificar as soluções técnicas, reduzir os riscos 
✓ Garantir que as soluções sejam comunicadas, validadas e seguidas pela 
equipe; 
✓ Trabalhar lado a lado com os demais gerentes de projeto, recursos humanos e 
planejamento do projeto; 
✓ Trabalhar lado a lado com os analistas e desenvolvedores para garantir que o 
guia da arquitetura seja seguido. 
 
• Analista 
✓ Identificar e detalhar os requisitos; 
✓ Descrever os casos de uso; 
✓ Auxiliar no desenvolvimento da visão técnica. 
 
• Gerente de Projetos 
✓ Lidera a equipe, sendo o responsável pela aceitação do produto por parte do 
cliente mediante bons resultados; 
✓ Deve avaliar os riscos do projeto e controlar esses riscos por meio de 
estratégias de mitigação. 
✓ Deve colocar em prática o conhecimento em gestão, habilidades, ferramentas 
e técnicas para entregar o resultado desejado em tempo hábil. 
2.6. Matriz de Responsabilidades 
 Para elaboração da Matriz de Responsabilidades, foi usada a técnica RACI: 
R: Responsible ou Responsável; 
A: Accountable ou Aprovador/Autoridade; 
C: Consulted ou Consultado; 
I: Informed ou Informado. 
AÇÃO MÉDICO PACIENTE DESENVOLVEDOR CONTRATANTE 
Funcionalidade do Sistema I I R A 
Design do Sistema I R A 
Cadastro de Usuário R R - A 
Agendamento de Consultas R A - I 
Tabela 1: Matriz de Responsabilidades - autoria própria 
9 
 
Nesta tabela observamos que o cadastro de usuário, por exemplo, é de 
RESPONSABILIDADE do médico, mediante APROVAÇÃO do paciente, devendo o 
contratante ser INFORMADO da situação. 
2.7. Cronograma de atividades e custos 
 Para Vargas (2005) “Um projeto bem-sucedido é aquele que é realizado 
conforme o planejado.” 
Projeto é um empreendimento não repetitivo, caracterizado por uma 
sequência clara e lógica de eventos, com início, meio e fim, que se destina a 
atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de 
parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade. 
(VARGAS, 2005, P.7) 
Com base em projetos anteriores, estimando os prazos e profissionais 
envolvidos, chegou-se ao prazo estimado de 80 dias e um valor final de R$ 30.000, 
00 (trinta mil reais), conforme detalhado abaixo. 
 ATIVIDADE CRONOGRAMA CUSTO ESTIMADO 
Levantamento de Requisitos 7 dias R$ 2.500,00 
Funcionalidade do sistema 50 dias R$ 19.000,00 
Design do sistema 20 dias R$ 8.000,00 
Implantação do Sistema 3 dias R$ 500,00 
Tabela 2: Cronograma de atividades e custos - autoria própria 
2.8. Análise de riscos 
 Risco – evento ou condição incerta que, se ocorrer, terá um efeito positivo 
ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, âmbito 
ou qualidade – PMI, PMBOK Guide 2004, pag. 238. 
 O gerenciamento de risco define as ações que irão identificar, analisar e 
responder aos riscos. As ações devem ser preventivas e não reativas. Na ação 
preventiva, o risco é avaliado, diminui-se o impacto e cria-se planos de prevenção. Na 
ação reativa, espera-se o risco acontecer para só então buscar solução, baseando em 
tentativa e erro, colocando o projeto em risco. 
2.8.1. Identificando os riscos 
10 
 
 O diagrama de causa e efeito, também conhecido como Diagrama de Ishkawa, 
é utilizado para identificar a causa raiz de um problema que pode se tornar um risco 
ao projeto. 
 
Figura 1:Diagrama de Ishkawa - autoria própria 
2.9. Lições Aprendidas 
 Registrar as Lições Aprendidas contribui para a melhoria contínua dos 
processos. Para auxiliar esse trabalho, é feito um formulário que auxilia o Gerente de 
Projetos e a equipe a documentar os fatos relevantes do projeto. Este registro deve 
ser feito de maneira simples, conforme o exemplo abaixo: 
Lições aprendidas por Área de Conhecimento 
ÁREA PROBLEMA IMPACTO LIÇÕES APRENDIDAS 
CUSTOS ITENS SUBESTIMADOS 
OU SUPERESTIMADOS 
ORÇAMENTOS NÃO 
REALISTAS QUE 
PODEM 
INVIABILIZAR O 
PROJETO 
TRABALHAR SEMPRE COM UMA 
ESTIMATIVA DE CUSTOS QUE INCLUA 
PESQUISA DE PRODUTOS JÁ 
EXISTENTES, DIMENSIONANDO O 
TEMPO A SER GASTO NO 
DESENVOLVIMENTO E MÃO DE OBRA , 
ALEM DE BASEAR EM TRABALHOS 
FEITOS ANTERIORMENTE 
11 
 
PRAZO TEMPO PARA O 
DESENVOLVIMENTO 
MAL CALCULADO 
PODE ATRASAR A 
ENTREGA OU 
SOLICITAR UM 
TEMPO EXCESSIVO 
QUE DESMOTIVE O 
CLIENTE 
USAR A TÉCNICA PERT PARA AVALIAR A 
ESTIMATIVA DE PRAZO MAIS PRÓXIMA 
DO REAL 
ESCOPO PROJETO EM PDF DIFICULDADE NO 
LEVANTAMENTO 
DOS DADOS DO 
PROJETO 
MANTER UMA PLANILHA COM OS 
DADOS PARA TORNAR MAIS FÁCIL A 
BUSCA E FILTRAGEM DAS 
INFORMAÇÕES 
Tabela 3:Lições Aprendidas - autoria própria 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 
 
3. PLANO DE NEGÓCIO 
3.1. Conceitos 
Segundo Chiavenatto (2008), “planejar consiste em simular o futuro desejado 
e estabelecer previamente os cursos de ação exigidos e os meios adequados para 
atingi-los”. 
3.2. Apresentação 
Plano de Negócios da MedHome modelo Canvas via Sebrae: 
 
Figura 2:Modelo de Negócios via Canvas/Sebrae - autoria própria 
13 
 
4. DESENVOLVIMENTO DO SISTEMA 
 Neste item, falaremos sobre os requisitos funcionais, requisitos não funcionais 
e regras de negócio. Em seguida serão abordados os projetos dos Diagramas de Caso 
de Uso, de Atividades, de Classes, de Sequência, de Componentes e de Implantação. 
4.1. Requisitos Não Funcionais 
 Os Requisitos Não Funcionais (RNF) são os itens de qualidade, relacionados 
aos critérios de desempenho, usabilidade, segurança, entre outros. 
RNF01 DESEMPENHO 
VELOCIDADE DE 
PROCESSO 
O tempo de execução dos 
processos deve ser curto 
RNF02 DESEMPENHO 
ATUALIZAÇÃO DE 
BANCO DE DADOS 
O sistema deverá atualizar os 
dados em tempo real, assim que o 
usuário acessar o sistema e fizer 
a solicitação 
RNF03 DESEMPENHO 
VOLUME DE 
UTILIZAÇÃO 
O sistema deverá suportar um alto 
número de usuários simultâneos 
RNF04 SEGURANÇA 
AUTENTICAÇÃO DO 
USUÁRIO 
Somente deve ter acesso ao 
sistema o usuário devidamente 
cadastrado e logado 
RNF05 SEGURANÇA 
AUTORIZAÇÃO DE 
ACESSO 
Os dados de usuários devem ser 
protegidos contra acesso não 
autorizado 
RNF06 USABILIDADE 
USABILIDADE DE 
USUÁRIOS 
A interface gráfica deverá ser 
intuitiva e prática, não exigindo 
um alto nível de conhecimento 
para a sua utilização pelo usuário 
Tabela 4: Requisitos não funcionais - autoria própria 
4.2. Requisitos Funcionais 
 Os Requisitos Funcionais (RF) precisam ser determinados para o bom 
desempenho do sistema. Seguem alguns deles: 
RF01 
CADASTRO DE 
USUARIO 
PERMITE O CADASTRO DO USUÁRIO NO SISTEMA 
RF02 LOGIN PERMITE ACESSO DO USUÁRIO AO SISTEMA 
RF03 
ALTERAR 
SENHA 
PERMITE QUE USUÁRIO ALTERE SUA SENHA 
14 
 
RF04 
RECUPERAR 
SENHA 
PERMITE QUE USUÁRIO RECUPERE SUA SENHA 
RF05 
AGENDAR 
CONSULTA 
PERMITE AGENDAMENTO DO ATENDIMENTO 
RF06 
ACESSAR 
CONSULTA 
ACESSO DO USUÁRIO AO ATENDIMENTO 
AGENDADO 
RF07 
REGISTRA 
ATENDIMENTO 
EFETUADO 
PERMITE QUE O PROFISSIONAL DA SAÚDE 
REGISTRE O QUE FOI REALIZADO DURANTE O 
ATENDIMENTO 
Tabela 5:Requisitos Funcionais - autoria própria 
4.3. Regras de Negócio 
 As Regras de Negócio (RN) definem como um determinado processo deve 
ser executado. A seguir estão demonstradas as regras a serem aplicadas: 
IDENTIFICADOR RN01 
NOME PRAZO DE VALIDADE DO SOFTWARE 
DESCRIÇÃO 
O software ficará disponível para utilização enquanto o 
teleatendimento for autorizado pelo Ministério da Saúde e pelo 
Conselho Federal de Medicina. 
IDENTIFICADOR RN02 
NOME SERVIÇOS AUTORIZADOS 
DESCRIÇÃO 
Estão autorizados, de acordo com a Lei 1.643 de 2002, os 
teleatendimentos médicos, permitindo a realização de consultas 
médicas e acompanhamentosclínicos dos pacientes. 
IDENTIFICADOR RN03 
NOME PROTEÇÃO DOS DADOS 
DESCRIÇÃO 
De acordo com a Lei Geral de Proteção de Dados Pessoais 
(LGPD) nº 13.709, de 14 de agosto de 2018, os dados pessoais 
dos usuários deverão estar protegidos contra acesso de 
terceiros não autorizados, bem como o prontuário médico. 
15 
 
IDENTIFICADOR RN04 
NOME REGISTRO DE PRONTUÁRIO 
DESCRIÇÃO 
De acordo com a Lei nº 13.787, de 27 de dezembro de 2018, o 
processo de digitalização de prontuário de paciente será 
realizado de forma a assegurar a integridade, a autenticidade e 
a confidencialidade do documento digital. Todos os 
atendimentos deverão ter seu registro efetuado em sistema e o 
paciente poderá ter acesso sempre que solicitado, mediante 
identificação por usuário e senha. 
Tabela 6:Regras de Negócio - autoria própria 
4.4. Casos de Uso 
 Segundo Ivar Jacobson, podemos dizer que um caso de uso é um "documento 
narrativo que descreve a sequência de eventos de um ator que usa um sistema para 
completar um processo". Demonstramos a seguir os principais casos de uso, seus 
fluxos principais e requisitos relacionados. 
IDENTIFICAÇÃO CADASTRO DE USUARIO - UC01 
DESCRIÇÃO Permitir cadastro do usuário no sistema 
PRÉ CONDIÇÃO 
Usuário deve possuir vínculo com alguma das instituições 
cadastradas 
PÓS CONDIÇÃO Usuário cadastrado 
FLUXO NORMAL 
1. Profissional preenche os dados solicitados pelo sistema 
2. Sistema valida as informações e verifica se o usuário é 
elegível ao cadastro 
3. Sistema solicita ao usuário que cadastre uma senha e um 
login de acesso e grava as informações 
REQUISITOS 
RELACIONADOS 
RF01 – Cadastro de Usuário 
RNF02 - Atualização de banco de dados 
RNF04 - Autenticação de usuário 
Tabela 7:Caso de Uso Cadastro - autoria própria 
IDENTIFICAÇÃO EFETUAR LOGIN - UC02 
DESCRIÇÃO Permitir acesso do usuário ao sistema 
PRÉ CONDIÇÃO Usuário deve estar logado 
PÓS CONDIÇÃO 
Usuário logado e direcionado às opções referentes ao seu 
cadastro (médico ou paciente) 
FLUXO NORMAL 
1. Usuário digita login e senha 
2. Sistema valida as informações 
3. Usuário é logado 
16 
 
REQUISITOS 
RELACIONADOS 
RF02 – Login 
RNF03 - Volume de utilização 
RNF04 - Autenticação de usuário 
RNF05 - Autorização de acesso 
Tabela 8:Caso de Uso Login - autoria própria 
IDENTIFICAÇÃO ALTERAR SENHA- UC03 
DESCRIÇÃO Permitir que usuário altere sua senha 
PRÉ CONDIÇÃO Usuário deve estar logado 
PÓS CONDIÇÃO Nova senha cadastrada e atualizada no sistema 
FLUXO NORMAL 
1. Usuário digita login e senha 
2. Sistema valida as informações 
3. Usuário é logado e seleciona a opção "alterar senha" 
4. Sistema solicita que digite a nova senha em dois campos 
 5. O sistema verifica se as senhas digitadas são 
correspondentes e exibe uma solicitação de confirmação da 
alteração 
 6. Usuário confirma e o sistema grava a informação 
REQUISITOS RELA 
CIONADOS 
RF03 – Alterar Senha 
RNF02 - Atualização de banco de dados 
RNF03 - Volume de utilização 
RNF04 - Autenticação de usuário 
RNF05 - Autorização de acesso 
Tabela 9:Caso de Uso Alterar Senha - autoria própria 
IDENTIFICAÇÃO RECUPERAR SENHA- UC04 
DESCRIÇÃO Permitir que usuário recupere sua senha 
PRÉ CONDIÇÃO Usuário pré-cadastrado no sistema 
PÓS CONDIÇÃO Nova senha cadastrada e validada no sistema 
FLUXO NORMAL 
1. Usuário digita login e seleciona a opção "esqueci a senha" 
2. Sistema solicita informações de verificação de identidade 
3. Usuário recebe um e-mail com um link para recuperar a 
senha 
4. Usuário clica e é redirecionado para a área de "alterar 
senha" 
5. Sistema solicita que digite a nova senha em dois campos 
6. O sistema verifica se as senhas digitadas são 
correspondentes e exibe uma solicitação de confirmação da 
alteração 
7. Usuário confirma e o sistema grava a informação 
REQUISITOS 
RELACIONADOS 
RF04 - Recuperar senha 
RNF02 - Atualização de banco de dados 
RNF03 - Volume de utilização 
RNF04 - Autenticação de usuário 
RNF05 - Autorização de acesso 
Tabela 10:Caso de Uso Recuperar senha - autoria própria 
17 
 
IDENTIFICAÇÃO AGENDA CONSULTA - RF05 
DESCRIÇÃO Permitir agendamento do atendimento 
PRÉ CONDIÇÃO Paciente logado no sistema 
PÓS CONDIÇÃO Agendamento efetuado 
FLUXO NORMAL 
1. Paciente seleciona a especialidade 
2. Sistema exibe datas e horários disponíveis 
3. Paciente seleciona o horário desejado para 
atendimento 
4. Sistema exibe um protocolo com a data e horário do 
agendamento 
REQUISITOS 
RELACIONADOS 
RF05 – Agendar Consulta 
RNF02 - Atualização de banco de dados 
RNF03 - Volume de utilização 
RNF04 - Autenticação de usuário 
RNF05 - Autorização de acesso 
Tabela 11:Caso de Uso Agenda Consulta - autoria própria 
IDENTIFICAÇÃO ACESSAR CONSULTA - RF06 
DESCRIÇÃO Acesso do usuário ao atendimento agendado 
PRÉ CONDIÇÃO Usuário deve estar logado 
PÓS CONDIÇÃO Atendimento liberado 
FLUXO NORMAL 
1. Usuário acessa área de atendimento 
2. Sistema valida data e horário agendados 
3. Usuário é direcionado ao atendimento 
REQUISITOS 
RELACIONADOS 
RNF02 - Atualização de banco de dados 
RNF03 - Volume de utilização 
RNF04 - Autenticação de usuário 
RNF05 - Autorização de acesso 
Tabela 12:Caso de Uso Acessa Consulta - autoria própria 
IDENTIFICAÇÃO REGISTRA ATENDIMENTO EFETUADO - RF07 
DESCRIÇÃO 
Permite que o profissional da saúde registre o que foi 
realizado durante o atendimento 
PRÉ CONDIÇÃO Profissional deve estar logado e em atendimento 
PÓS CONDIÇÃO Prontuário registrado 
FLUXO NORMAL 
1. Profissional acessa área de registro e insere os dados 
do atendimento atual 
2. Sistema grava as informações 
REQUISITOS 
RELACIONADOS 
RNF02 - Atualização de banco de dados 
RNF03 - Volume de utilização 
RNF04 - Autenticação de usuário 
RNF05 - Autorização de acesso 
Tabela 13:Caso de Uso Registra Atendimento Efetuado - autoria própria 
18 
 
4.4.1. Diagrama de Casos de Uso 
 O Diagrama de Casos de Uso demonstra a maneira como ocorrerão as 
interações no sistema. 
 Souza (2008, p. 37), diz que 
[...] um caso de uso é uma sequência de interações entre o ator (alguém ou 
algo que interage com o sistema) e o sistema, que acontece de forma 
atômica, na perspectiva do autor. Isso significa que quando criamos um caso 
de uso apenas nos preocupamos com “o que” o sistema deve fazer e não 
“como” deve fazer. 
 
 
Figura 3: Diagrama de Casos de Uso – autoria própria 
 
4.5. Diagrama de Atividades 
O diagrama de atividades ilustra graficamente como será o funcionamento do 
software, a execução de suas partes, e a atuação do sistema na realidadede 
negócio na qual ele está inserido. 
Para Guedes (2011, p. 36), o Diagrama de Atividade 
[...] preocupa-se em descrever os passos a serem percorridos para a 
conclusão de uma atividade específica, podendo esta ser representada por 
19 
 
um método com certo grau de complexidade, um algoritmo, ou mesmo por 
um processo completo. O diagrama de atividade concentra-se na 
representação do fluxo de controle de uma atividade. 
 
Figura 4:Diagrama de Atividades Cadastra Paciente - autoria própria 
 
 
Figura 5:Diagrama de Atividades Agenda Consulta - autoria própria 
 
20 
 
 
Figura 6:Diagrama de Atividades Registra Atendimento Efetuado - autoria própria 
 
4.6. Diagrama de Classes 
 Um Diagrama de Classes é uma representação utilizada na área da 
programação para descrever a estrutura de um sistema. Tem como objetivo principal 
a especificação dos componentes do software e como estes se interligam, do 
ponto de vista estrutural. 
 Conforme definição de Rumbaugh et al. (1994, p. 4), Herança é 
[...] o compartilhamento de atributos e operações entre classes, com base em 
um relacionamento hierárquico. Uma classe pode ser definida de forma 
abrangente e depois refinada em sucessivas subclasses mais definidas. 
Cada subclasse incorpora, ou herda, todas as propriedades de sua 
superclasse e acrescenta suas próprias e exclusivas características. As 
propriedades da superclasse não precisam ser repetidas em cada subclasse. 
No exemplo a seguir, as classes PACIENTE e MÉDICO herdam os atributos da 
classe PESSOA. 
21 
 
 
Figura 7: Diagrama de Classes (Usuário) - autoria própria 
 
4.7. Diagrama de Sequência 
Um diagrama de sequência é um diagrama de interação que dá ênfase à 
ordenação temporal de mensagens. Um diagrama de sequência mostra o 
conjunto de objetos e as mensagens enviadas e recebidas por esses objetos. 
Tipicamente os objetos são instâncias nomeadas ou anônimas de classes, 
mas também podem representar instâncias de outros itens, como 
colaborações, componentes e nós. (BOOCH; JACOBSON; RUMBAUGH, 
2000, p 96). 
Abaixo temos a representação do diagrama de sequência no cadastro de um novo 
paciente. 
22 
 
 
Figura 8: Diagrama de Sequência (cadastra paciente) - autoria própria 
 
4.8. Diagrama de Componentes 
Os diagramas de componentes mostram a estrutura do sistema de software, 
que descreve os componentes do software, suas interfaces e suas dependências. 
Demonstramos a seguir a comunicação entre os componentes onde o usuário 
acessa via site/app, o gerenciador de login valida o acesso junto ao banco de dados 
ou direciona ao cadastro de usuário. 
 
Figura 9: Diagrama de componentes - autoria própria 
23 
 
4.9. Diagrama de Implementação 
 O Diagrama de Implementação é útil quando o sistema é modelado para ser 
executado em várias máquinas, que executem determinados módulos do software ou 
armazenem arquivos necessários. Ele organiza a arquitetura física sobre a qual o 
software será implantado e executado em termos de hardware, define como essas 
máquinas estarão conectadas e por meio de quais protocolos se comunicarão e 
transmitirão essas informações. 
 
Figura 10: Diagrama de implantação - autoria própria 
 
 
 
 
 
 
 
 
24 
 
5. INTERAÇÃO COM O USUÁRIO 
 Sabendo da importância do sistema e que ele atenderia a pessoas com os mais 
variados níveis de conhecimento tecnológico, foi feito um esforço para que a tela de 
usuário fosse simples, intuitiva e não exigisse muito para a sua utilização. 
Nesse sentido, utilizamos a ferramenta Justinmind para criar a prototipagem das 
principais telas, em sua versão desktop e mobile. 
5.1. Tela de Login 
 Usuário recebe as informações claras sobre como preencher cada campo de 
acesso. Tanto a versão Desktop quanto mobile terão aparências semelhantes para 
facilitar o entendimento do usuário. 
 
Figura 11:Tela login Desktop - autoria própria 
 
 
Figura 12:Tela login mobile - autoria própria 
5.2. Tela de Agendamento 
 O paciente irá selecionar uma especialidade dentre as apresentadas, então o 
sistema irá informar quais datas e horários estão disponíveis para agendamento.
 
Figura 13:Tela de agendamento desktop 1 - autoria própria 
 
Figura 14:Tela de agendamento desktop 2 - autoria própria
25 
 
 
Figura 15:Tela de agendamento mobile 1 - autoria própria 
 
Figura 16:Tela de agendamento mobile 2 - autoria própria 
5.3 Tela de prontuário 
 O profissional de saúde deverá acessar a tela de registro de atendimento 
preenchendo os campos solicitados. 
 
Figura 17:Tela de prontuário desktop - autoria própria 
Na versão mobile, o preenchimento se dará por partes, em sequência: 
 
Figura 18: tela de prontuário mobile - autoria própria 
26 
 
CONCLUSÃO 
A pandemia de COVID-19 trouxe uma nova realidade e novas necessidades ao 
mercado. A utilização de sistemas de informação permite dar maior segurança aos 
atendimentos realizados diariamente e assegura uma melhor guarda das informações 
produzidas. 
No presente trabalho propôs-se o desenvolvimento de um sistema de teleatendimento 
médico, com o objetivo de permitir o atendimento remoto dos pacientes, além da troca 
de informações entre os profissionais. Tal atendimento traz maior segurança ao 
diminuir a exposição dos usuários a uma possível contaminação pelo coronavírus, 
garantindo o distanciamento social sempre que possível. 
Algumas questões se fizeram essenciais durante o desenvolvimento, tais como a 
garantia do sigilo das informações dos pacientes, a proteção contra acesso não 
autorizado, registro dos atendimentos realizados e facilidade na utilização. 
Foi definido um plano de negócios, descrevendo as características da empresa, 
elaborado o Termo de abertura do projeto, a definição dos projetos dos diagramas de 
caso de uso, diagrama de atividades, diagrama de classes, diagrama de sequência, 
diagrama de componentes e diagrama de implantação. 
Durante o desenvolvimento das interfaces de usuário, buscou-se aliar simplicidade e 
eficiência, e ter pouca variação visual entre as versões desktop e mobile. 
 
 
 
 
 
 
 
 
 
27 
 
REFERÊNCIAS 
ANDRADE, Luiza. Diagrama de Ishikawa: o que é e como fazer. 2017. Disponível em: 
https://www.siteware.com.br/metodologias/diagrama-de-ishikawa/. Acesso em: 12 
out. 2021. 
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: Guia do usuário. Rio de Janeiro: 
Campus, 2000. 
BRASIL. CONSTITUIÇÃO FEDERAL. . LEI Nº 13.787, DE 27 DE DEZEMBRO DE 
2018. 2018. Disponível em: http://www.planalto.gov.br/ccivil_03/_ato2015-
2018/2018/lei/L13787.htm. Acesso em: 12 out. 2021. 
BRASIL. CONSTITUIÇÃO FEDERAL. . Lei Geral de Proteção de Dados Pessoais. 
2018. Disponível em: http://www.planalto.gov.br/ccivil_03/_ato2015-
2018/2018/lei/l13709.htm. Acesso em: 12 out. 2021. 
CANVA. https://www.canva.com . Acesso em:01 out. 2021. 
COUTINHO, Thiago. Termo de abertura do projeto: saiba o que é e como fazer o seu. 
2020. Disponível em: https://www.voitto.com.br/blog/artigo/o-que-e-termo-de-
abertura-do-projeto. Acesso em: 26 set. 2021. 
GAJ. L. Tornando a administração estratégica possível. São Paulo: McGraw-Hill, 
1990. 
GONÇALVES, Adriana. Canvas: Como estruturar seu modelo de negócios. 2019. 
Disponível em: https://www.sebraepr.com.br/canvas-como-estruturar-seu-modelo-de-
negocios/. Acesso em: 26 set. 2021. 
GUEDES, G. T. A. UML: Uma abordagem pratica. 1 ed. São Paulo:Novatec, 2004. 
IBM CORPORATION. Rational Software Modeler: diagramas de sequência. 
Diagramas de Sequência. Disponível em: https://www.ibm.com/docs/pt-
br/rsm/7.5.0?topic=uml-sequence-diagrams. Acesso em: 12 out. 2021. 
JACOBSON, I.; BOOCH, G; RUMBAUGH, J. The unified software development 
process. Boston: Addison-Wesley, 1999. 
28 
 
MEDEIROS, Higor. INTRODUÇÃO AO MODELO CASCATA. 2013. Disponível em: 
https://www.devmedia.com.br/introducao-ao-modelo-cascata/29843. Acesso em: 08 
out. 2021. 
MCT. Qualidade no setor desoftware brasileiro: 1995. Brasília, DF. 
http://www.mct.gov.br . Acesso em 13 out. 2021. 
PEINADO, Jurandir; GRAEML, Alexandre Reis. Administração da produção: 
operações industriais e de serviços. Curitiba: UnicenP, 2007. 
RODRIGUES, Eli. Como fazer o Encerramento de um Projeto. 2016. Disponível em: 
https://blogdaqualidade.com.br/diagrama-de-ishikawa-2/. Acesso em: 12 out. 2021. 
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de 
Janeiro: Campus, 1994. 
SOUZA, Vinicius Lourenço. Desenvolvimento de software dirigido por caso de uso. 
Revista Engenharia de Software Magazine, Rio de Janeiro, n. 2, p. 36-40, 2008. 
TRIBUNAL REGIONAL DO TRABALHO DO PARANÁ. (org.). Conceito: Requisitos 
Não-Funcionais. Disponível em: 
https://www.trt9.jus.br/pds/pdstrt9/guidances/concepts/supporting_requirements_B2
C4D610.html. Acesso em: 12 out. 2021.