Você está na página 1de 18

UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar

CURSO SUPERIOR DE TECNLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Sistema de teleatendimento médico para consulta de pacientes via


APP/Web

2022
SÃO PAULO
UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar – PIM VI

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Sistema de teleatendimento médico para consulta de pacientes via APP/Web

Nome(s) Completo(s) dos Aluno(s): Rafaella Macena, Tiago Alexandre


RA(s): 2176061 (Rafaella), 2176587 (Tiago)
Curso: Análise e Desenvolvimento de Sistemas
Semestre:4° Semestre

2022
SÃO PAULO
RESUMO

O Projeto Integrado Multidisciplinar (PIM VII) tem como objetivo deste o


desenvolvimento de um projeto de sistema para a realização de consultas médicas e
seus devidos acompanhamentos clínicos por meio de APP/Web. E tem como
finalidade aplicar os conhecimentos adquiridos nas matérias de empreendedorismo,
Gerenciamento de Projeto de Software, Gestão da Qualidade e Projeto de Sistemas
Orientado a Objetos.

Palavras-chave: Telemedicina, aplicativo, saúde.


ABSTRACT

The Integrated Multidisciplinary Project (PIM VII) aims to develop a system project
to carry out medical consultations and their appropriate clinical follow-ups through
APP/Web. And it aims to apply the knowledge acquired in the settings of
entrepreneurship, Software Design, Quality and Object Oriented Systems Design.

Keywords: Telemedicine, app, healthcare.


SUMÁRIO

1. INTRODUÇÃO ........................................................................................ 6
2. PLANO DE NEGÓCIOS .............................................................................. 7
2.1 CUSTOS DO PROJETO ........................................................................... 7
3. ARQUITETURA DE SOFTWARE ............................................................... 8
3.1 DEMONSTRAÇÃO DA ARQUITETURA MVC .......................................... 8
3.2 CAMADA MODEL ..................................................................................... 9
3.3 CAMADA VIEW ........................................................................................ 9
3.4 CAMADA CONTROLLER ......................................................................... 9
3.5 CAMADA PEDRO ..................................................................................... 9
4. REQUISITOS FUNCIONAIS ..................................................................... 10
5. REQUISITOS NÃO FUNCIONAIS ............................................................. 11
6. DIAGRAMA DE CLASSE DE IMPLEMENTAÇÃO ................................... 12
6.1 QUALIDADE DO PROCESSO DE SOFTWARE ..................................... 12
7. GERENCIAMENTO DE PROJETO ........................................................... 13
8.CONCLUSÃO ............................................................................................ 16
9. REFERENCIAS ......................................................................................... 17
6

1. INTRODUÇÃO

No Brasil, a telemedicina foi regulamentada pela Lei 1.643 de 2002, que permite
o uso de computadores e celulares para atendimentos médicos em áreas remotas,
responsabilizando o médico pela proteção dos dados dos pacientes. Com o
surgimento da pandemia de COVID-19 no fim do ano de 2019, essa prática se
tornou uma necessidade.

A telemedicina é um processo avançado para monitoramento de pacientes,


troca de informações médicas e análise de resultados de diferentes exames, por
meio da telemedicina, os especialistas conseguem acessar os exames de qualquer
lugar do país, utilizando computador e dispositivos móveis, como smartphones e
tablets conectados à internet.

O objetivo desse projeto de um sistema de teleatendimento médico via internet


que tem como propósito diminuir as visitas e agilizar os atendimentos médicos em
épocas de pandemias nos hospitais, seguindo as normas regulamentadas pela lei
1.643 de 2002.
7

2. PLANO DE NEGÓCIOS

O objetivo deste trabalho será desenvolver um projeto de sistema que visa


atender o cliente em todos os aspectos, desde sua realização em consultas médicas
até o acompanhamento clínico por meio de diversos aparelhos tecnológicos que
possuírem os requisitos necessários e suportados pelo app, como: smartphone, tablet,
notebook etc.

2.1 CUSTOS DO PROJETO

Para o desenvolvimento deste projeto de sistema, os custos serão baixos, mas


irá atender todos os requisitos necessário de todos os clientes. O custo do projeto final
dando os gastos que teremos contratado um engenheiro de software que irá utilizar o
processo de software, que consiste em vários modelos, porem todos tem em comum
quatro atividades essenciais, A especificação do sistema (como realizar o cadastro),
o objetivo (para que serve), manuseamento do sistema (interação do usuário com a
plataforma), finalidade (eficiência e êxito do sistema). Todas as quatro atividades
buscam um objetivo final que é a satisfação do cliente com o sistema lhe oferecido
para suas necessidades. O custo do projeto será de R$ 50.000,00. Já estimado todos
os gastos e despesas com funcionários e profissionais da área tecnológica,
equipamentos.
8

3. ARQUITETURA DE SOFTWARE

Nesta etapa será utilizado a arquitetura de software criada na década de 70 e


desenvolvida para ser usado em projetos de interface visual. A arquitetura MVC
(MODEL, VIEW, CONTROLLER) consiste na separação do código fonte em três
camadas, separando as informações de sua apresentação.

3.1 DEMONSTRAÇÃO DA ARQUITETURA MVC

Figura 1.
9

3.2 CAMADA MODEL

A camada MODEL ou modelo atua isoladamente e não tem conhecimento de


quais serão a ou as interfaces que terá de atualizar, apenas acessando à base de
dados e deixando os dados prontos para o controlador encaminhar para a visão
correta.

3.3 CAMADA VIEW

A camada VIEW ou visão é a camada de apresentação com usuário, a interface,


ela é responsável por exibir uma representação dos dados modelados os quais os
usuários interagem diretamente.

3.4 CAMADA CONTROLLER

A camada CONTROLLER ou controlador não tem a responsabilidade de buscar


ou exibir dados, ela trabalha apenas controlando e mapeando as ações, decidindo qual
model usar, quais solicitações serão enviadas e qual combinação de VIEWS será
utilizada para a exibição do retorno dos dados da camada MODEL.

3.5 CAMADA PEDRO

A camada PEDRO, representado um usuário que é responsável por fornecer


os dados necessários para seu livre acesso do sistema, sendo permitido conectar e
desconectar quando desejar.
10

4. REQUISITOS FUNCIONAIS

Para pacientes:

O paciente cria seu perfil informando


Cadastro nome, data de nascimento, sexo,
endereço, número para contato e outros
dados necessários para iniciar o
atendimento
Esse caso de uso permite que o
Agendamento de consulta paciente agende uma consulta a todos
os médicos especialistas que fizerem
parte do Plano, Instituição ou ao Posto
de Saúde do SUS escolhido.
Esse caso permite ao paciente atender
Videochamadas a chamada realizada pelo profissional e
ser atendido
Lembretes e registro de O aplicativo guarda as prescrições que o
medicamentos médico passou.

Figura 2.

Para os médicos:

O médico precisa informar nome,


Cadastro especialização, foto, CRM e
disponibilidade.
Agendamento Isso permite que o médico veja a
disponibilidade para atender o paciente
11

Esse caso de uso permite que o


Atendimento com vídeo profissional de saúde faça a chamada
para realizar a consulta agendada
Cadastro do atendimento médico Permite que o médico registre no
realizado sistema os dados referentes a consulta
realizada ou em andamento
Prescrever ações ou medicamentos O médico faz a prescrição de ações ou
medicamentos para os pacientes

Figura 3.

5. REQUISITOS NÃO FUNCIONAIS

Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação


em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade,
manutenibilidade e tecnologias envolvidas. Em um processo de levantamento,
normalmente o cliente não precisa citar estes requisitos, pois são particularidades
mínimas de um software ou serviço. Dentro do cenário proposto os requisitos em
questão são:

• Segurança de acesso: O uso de boas práticas de segurança impede ataques


externos;

• Disponibilidade do sistema: A disponibilidade deve ser a todo momento;

• Desempenho da internet: Garantir o ótimo funcionamento da rede.


12

6. DIAGRAMA DE CLASSE DE IMPLEMENTAÇÃO

A principal característica de um diagrama de classes é permitir a visualização


das classes que irão compor o sistema, representando seus atributos e métodos e
demonstrar como as classes se relacionam entre si.
Iniciaremos a apresentação a seguir de todos os diagramas de classe de
implementação desenvolvidos com base no diagrama de casos de uso que foi
desenhado na figura 1. A seguir apresentaremos cada caso de uso que possuirá seus
diagramas específicos utilizando como base o desenho da arquitetura MVC mostrado
na figura 1. Foi adicionado as classes estereótipos para facilitar ainda mais a
identificação a qual camada classe pertence.

6.1 QUALIDADE DO PROCESSO DE SOFTWARE

A qualidade se tornou um diferencial competitivo sendo cada vem mais um fator


importante no mercado de trabalho, gerando um fator crítico de sucesso. O uso de um
diagrama de classes inadequado ou um sistema pode reduzir a qualidade ou a
utilidade do produto de software a ser desenvolvido ou aumentar os custos de
desenvolvimento ficando inacessível sua entrega para o cliente.
Esse fato importante leva inúmeras organizações que produzem software a
usar processos de desenvolvimento que sejam eficientes e que atendam plenamente
suas necessidades.
A figura 1 apresenta o desenvolvimento de um sistema de qualidade que atenda
o cliente e seus requisitos é atribuído ao engenheiro de software com o uso do
processo de software, é possível identificar, compreender e realizar todas as
demandas dos usuários.
13

O qual consiste em vários modelos, mas com atividades fundamentais em


comum e um único objetivo, sendo a qualidade na entrega:

• A validação do software, fase em que podemos identificar se as


necessidades dos clientes foram atendidas

• Evolução do sistema, futuramente todo sistema terá que ser atualizado,


modificado, alterado, sempre visando atender inovações, melhorias, que
o mercado demanda e que surgirão.

• Sua especificação, onde o sistema é definido, assim como suas


restrições em suas operações, colocando limites até onde os usuários
poderão interagir com o programa.

• Implementação e Projeto, nessa etapa é verificado o projeto do sistema,


sua programação, suas demandas e especificações estabelecidas e
exigidas que atenderão a todo tipo de usuário.

7. GERENCIAMENTO DE PROJETO

• Termo de abertura:

É um documento que apresenta uma mensagem convincente e sucinta


com os objetivos, escopo e responsabilidades, no intuito de obter a aprovação
dos principais participantes do projeto. É emitido antes do início do projeto por
alguém com autoridade formal para designar ou solicitar a liberação de
recursos da organização, tanto financeiros quanto máquinas, equipamentos,
materiais e os recursos humanos necessários para sua execução.
14

Pode ser desenvolvido pelo Patrocinador, por um diretor, pelo PMO ou pelo
órgão ou comitê responsável pela gestão de portfólio.

1) Informações gerais: Deve conter o nome do projeto, data, nome do


patrocinador, número de projeto e origem;

2) Visão geral do projeto: No fim de março, o Conselho Federal de Medicina


(CFM) divulgou uma resolução que permite o trabalho remoto de
médicos. O Ministério da Saúde ratificou a liberação do uso da
telemedicina em uma portaria publicada dias depois no Diário Oficial da
União. “Já não era sem tempo”, afirmou Renato Velloso, CEO da rede
de centros médicos “Dr. Consulta”, em artigo de opinião veiculado pelo
Estadão;

3) Objetivo do projeto: O objetivo é apresentar um projeto de sistema para


realização de consultas médicas via APP/Web, como propósito diminuir
as visitas e agilizar os atendimentos médicos;

4) Requisitos: Desenvolver um plano de negócios, requisitos funcionais,


requisitos não funcionais e regras de negócios, que serão necessários
para a confecção deste sistema;

5) Justificativa empresarial: Com o desenvolvimento desse projeto, é mais


um ponto positivo da telemedicina no combate a pandemia de covid-19.
Com a prática desse novo método, os médicos podem transmitir
orientações e acompanhar os pacientes sem ter contato físico com eles.
E permite que os pacientes recebam as orientações e recomendações
de casa, não precisando ir em clínicas e hospitais;

6) Custo de recursos: Onde deve ser documentado todos os custos do


projeto e cada categoria de item que irá ser usado;
15

7) Funções e responsabilidades: Mostra todos os envolvidos do projeto,


função de cada um e suas responsabilidades dentro do projeto;

8) Análise de riscos: Descreve os riscos que poderá ocorrer no projeto, a


probabilidade de acontecer e os efeitos que irão ser causados por ele;

9) Assinaturas: Onde deverá conter as assinaturas dos envolvidos do


projeto.
16

8.CONCLUSÃO

Neste projeto foi de grande importância o aprofundamento no conhecimento de


todas as disciplinas do 4º semestre, Gestão da Qualidade, Projeto de Sistemas
Orientado a Objetos, Gerenciamento de Projetos de Software e Empreendedorismo,
projeto elaborado desde sua teoria, voltado até a sua prática.

O uso da arquitetura MVC foi de extrema importância para a identificação que


o cliente precisa e as funções do software exigidas pelo sistema, onde que através
desse processo é possível detectar suas necessidades, pois deste modo é possível
comprovar a utilidade e relevância que a arquitetura MVC apresenta para o
desenvolvimento do sistema.

Portanto, conclui-se que o projeto teve como propósito apresentar e


desenvolver um sistema capaz de gerenciar todos os usuários cadastrados na
plataforma e facilitar suas necessidades no plano de usabilidade de cada usuário,
gerando agilidade e inteligência no processo.
17

9. REFERENCIAS

CANVA. https://www.canva.com. Acesso em: 20/09/2022.

[CAMPOS, 1992] CAMPOS, VICENTE. TQC – Controle da Qualidade Total. Belo

Horizonte: Bloch Ed, 1992.

[DENNIS, 2005] DENNIS, Alan. Análise e Projeto de Sistemas. Rio de Janeiro, LTC,

2005.

[MALDONADO, 2001] Qualidade de Software, Teoria e prática. São Paulo: Pearson,

2001.

http://www.mct.gov.br. Acesso em 20/09/2022.

https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-
funcionais/9525. Acesso em 28/09/2022.

https://codificar.com.br/requisitos-funcionais-nao-funcionais/. Acesso em 28/09/2022.

https://www.apolomarcas.com.br/as-7-etapas-do-plano-de-negocios-
simplificado/#:~:text=As%20etapas%20que%20devem%20ser,%2C%20operacional%
2C%20estrat%C3%A9gias%20e%20marketing. Acesso em 28/09/2022.

https://www.sebrae.com.br/sites/PortalSebrae/artigos/passo-a-passo-para-elaborar-o-
plano-de-negocios-de-sua-
empresa,d7296a2bd9ded410VgnVCM1000003b74010aRCRD. Acesso em
28/09/2022.
18

https://asana.com/pt/resources/project-charter. Acesso em 29/29/2022.

https://www.objective.com.br/insights/termo-de-abertura-do-projeto-o-que-e-como-
funciona-e-como-podemos-utiliza-lo-na-agilidade/. Acesso em 29/09/2022.

https://www.ibm.com/suppoort/knowledgecenter/ptbr/SS8PJ7_9.6.0/com.ibm.xtools.m
odeler.doc/topics/cacted.html>. Acesso em 25/09/2022

htps://www.devmedia.com.br/processos-de-software/21977>. Acesso em 27/09/2022

https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308>. Acesso em
28/09/2022

https://www.linhadecodigo.com.br/artigo/2367/abordando-a-arquitetura-mvc-e-design-
patterns-observer-composite-strategy.aspx>. Acesso em 29/09/2022

https://www.ibm.com/docs/pt-br/rsas/7.5.0?topic=topologies-deployment-diagrams.
Acesso em 29/09/2022

Você também pode gostar