CENTRO UNIVERSITÁRIO SENAC

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS
PROJETO INTEGRADOR II: DESENVOLVIMENTO
ESTRUTURADO DE SISTEMAS

SISTEMA DE CARTÃO VIRTUAL DE VACINAÇÃO

Ligia Maia Tostes Brusamolin de Rezende

Paulo Fernando Rodrigues Jordão
Vinicius Valença Costa

São Paulo
2021
 CENTRO UNIVERSITÁRIO SENAC

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS
PROJETO INTEGRADOR II: DESENVOLVIMENTO
ESTRUTURADO DE SISTEMAS

SISTEMA DE CARTÃO VIRTUAL DE VACINAÇÃO

Trabalho de Projeto Integrador

II Desenvolvido como exigência para
a obtenção de nota parcial para o 2º
semestre do curso de Tecnologia em
Análise e Desenvolvimento de
Sistemas – Centro Universitário
Senac, sob orientação do Prof. Msc.
Fabio Versolatto.

São Paulo
2021
 SUMÁRIO
INTRODUÇÃO ...................................................................................................................................... 2
1. VISÃO GERAL DO PRODUTO ..................................................................................................... 3
2. ESPECIFICAÇÃO DE REQUISITOS DO PRODUTO ............................................................... 4
2.1 Processo de Elicitação de Requisitos .................................................................................... 5
2.2 Requisitos Extraídos ................................................................................................................. 6
2.2.1 Requisitos Funcionais ........................................................................................................ 6
2.2.1 Requisitos não Funcionais .............................................................................................. 10
3. ESTUDO DE VIABILIDADE ......................................................................................................... 13
4. ESTIMATIVA DE ESFORÇO PARA O DESENVOLVIMENTO DA SOLUÇÃO ................... 15
4.1 Elicitação de Entidades........................................................................................................... 17
4.2 Diagrama de Entidades de Relacionamentos (DER) ......................................................... 18
CONSIDERAÇÕES FINAIS .............................................................................................................. 19
REFERÊNCIAS .................................................................................................................................. 20
 2

INTRODUÇÃO

Devido a pandemia que se iniciou em 2019, por causa do Coronavírus, diversos

protocolos de segurança foram desenvolvidos pelos os órgãos de saúde no Brasil e
no mundo, em um esforço de minimizar a propagação da Covid-19. Considerando que
o contágio do Coronavírus ocorre através do contato entre duas ou mais pessoas, que
compartilham gotículas da mucosa do nariz ou da boca infectadas com o vírus. Assim,
a proposta desse trabalho é desenvolver um sistema de carteira de vacinação online,
que permita realizar o controle de todas as vacinas, contribuindo para diminuir o
contato entre pessoas. Também facilita o controle e atualização da carteira de
vacinação, uma vez que com o tempo novas doenças e vacinas surgem, não sendo
possível atualizar um papel impresso, forma como são feitos os cartões de vacinação
atualmente. Além disso, os cartões de vacinação no formato de caderneta são fáceis
de perder e deteriorar; com o sistema de carteira de vacinação online, a atualização
das vacinas é feita no sistema, sem a necessidade de imprimir, distribuir novas
carteiras de vacinação e contato direto entre indivíduos; facilitando também o controle
da população, uma vez que o sistema ficará disponível 24 horas por dia na nuvem e
poderá ser acessado através de diferentes dispositivos.
 3

1. VISÃO GERAL DO PRODUTO

O projeto consiste no desenvolvimento de um sistema de carteira de vacinação

online, para facilitar o controle da vacinação da população, principalmente em
períodos de pandemia, contribuindo com a redução do contágio de doenças
infectocontagiosas, como a Covid-19. Além disso, a carteira de vacinação online
possui o benefício secundário de facilitar o controle e acesso dos profissionais e
população a respeito das informações sobre as vacinas, uma vez que o sistema fica
disponível 24 horas por dia na nuvem e é acessível por qualquer dispositivo que seja
capaz de se conectar à internet.

O público-alvo do sistema de carteira de vacinação online são os entes

federativos (municípios, estados, Distrito Federal e União), uma vez que o Sistema
Único de Saúde (SUS) é o responsável pela aplicação das vacinas obrigatórias.
Porém, o sistema também será disponibilizado para organizações privadas,
considerando que as vacinas obrigatórias e não obrigatórias também podem ser
aplicadas em hospitais e clínicas particulares.

A carteira de vacinação online dispõe de três tipos de usuários: administrativo,

profissional da saúde e paciente. Os usuários administrativos são os indivíduos
pertencentes às administrações públicas, responsáveis por administrar o sistema
realizando o registro de informações gerais de doenças e vacinas obrigatórias e não
obrigatórias, campanhas de vacinação e cadastro de usuários profissionais da saúde
(médicos e enfermeiros). Os usuários profissionais da saúde são os profissionais
pertencentes às organizações públicas ou particulares, responsáveis por registrar
uma aplicação de vacina, toda vez que aplicarem uma vacina em um usuário paciente,
além de também poderem realizar o cadastro de um novo usuário paciente. Os
usuários pacientes podem se cadastrar através de um aplicativo móvel ou site do
sistema, oportunidade na qual devem inserir os dados obrigatórios, tais como: nome
completo, CPF, RG, endereço, data de nascimento, filiação, histórico de doenças,
entre outras informações exigidas pelo SUS. Os usuários pacientes que já possuem
um histórico de vacinação, receberão a orientação para se dirigirem ao posto de saúde
mais próximo, a fim de atualizarem às suas respectivas carteiras de vacinação online,
uma vez que somente os usuários profissionais de saúde podem realizar o registro de
 4

uma vacina aplicada. As informações coletadas dos usuários do sistema serão

armazenadas nos bancos de dados de responsabilidade de cada ente federativo, por
meio de seus órgãos de tecnologia da informação ou de suas secretarias de saúde,
para acompanhamento, material de apoio à pesquisa para desenvolvimento de
políticas públicas, prestação de informações à população, entre outras iniciativas.

Seus objetivos principais são: i) entregar às pessoas informações mais precisas

sobre seus históricos de vacinação; ii) melhorar o controle pessoal em relação aos
prazos e campanhas para a aplicação de novas vacinas e doses de reforço, para que
não os percam, por meio de notificações eletrônicas; iii) construir um banco de dados
para os entes federativos que sirva de material para implementação de políticas
públicas no âmbito da saúde; iv) disponibilização de informações digitais a respeito do
histórico de vacinação das pessoas em qualquer lugar e horário, evitando que fiquem
registradas única e exclusivamente em cartões físicos, que são fáceis de perder ou
deteriorar; v) possibilitar que os pacientes agendem consultas diretamente pelo
aplicativo ou site do sistema, para tomarem as vacinas faltantes ou doses de reforços.

Tal iniciativa vem à tona devido à necessidade histórica de enfretamento aos

surtos, epidemias, endemias, e atualmente, mais precisamente à pandemia do SarS-
COVID-19, pelos entes federativos, e pela própria população. Como a vacinação é um
importante instrumento na prevenção e controle de doenças imunopreveníveis, criar
um sistema de cartão de vacinação online, que seja devidamente alimentado e
atualizado, é uma política de saúde pública potencialmente efetiva.

2. ESPECIFICAÇÃO DE REQUISITOS DO PRODUTO

Para toda nova proposta de software é exigido que se levante os requisitos

necessários para que ele seja devidamente desenvolvido. Os requisitos são as
necessidades de todos os tipos usuários do sistema. Eles são divididos,
principalmente, em dois grupos: os funcionais e os não funcionais. Para tanto, existem
várias técnicas para que seja feita a elicitação dos requisitos. A técnica utilizada para
o presente projeto foi a de levantamento em grupo, que Segundo Nusebeh e
Easterbrook (2000), consiste em: realização de reuniões para promover acordos entre
 5

os principais envolvidos, por meio de dinâmicas de grupos, workshops e

brainstorming.

Por meio da aplicação da técnica de levantamento em grupo, foram extraídas

tais informações quanto aos requisitos funcionais do software: i) uma interface de
identificação e acesso por tipo de usuário através de um par de e-mail e senha. A
depender do tipo de usuário, a interface será carregada com as informações e
permissões do perfil; ii) um menu com opções e permissões de acordo com o
respectivo tipo de usuário.

Os dados registrados no aplicativo serão armazenados nos datacenters dos

entes federativos, de acordo com suas normas próprias. Alguns dados não poderão
ser alterados após a validação do cadastro, como filiação, CPF, RG e data
nascimento. Os demais são passíveis de mudança.

Quanto aos requisitos não funcionais, o software terá uma interface gráfica
intuitiva, facilitando seu uso. Seu uso será disponibilizado em tempo integral, exceto
pelos curtos períodos de manutenção nos servidores que armazenam os dados, nos
quais o serviço ficará temporariamente indisponível.

Do ponto de vista da confiabilidade, o software trabalhará com dados

criptografados de ponta a ponta, o que dificulta a atuação de hackers e afins. Os dados
só poderão ser revelados por decisão judicial, devidamente fundamentada.

No tocante à portabilidade, serão compiladas versões mobile (iOS, Android) e

desktop (Windows, Linux e MacOS). O aplicativo cliente terá entre 20 e 25 megabytes,
que é considerado leve, se comparado com o tamanho dos aplicativos atuais mais
utilizados na atualidade. Além disso, a interface do usuário terá detalhes gráficos
simples, privilegiando seu desempenho, em detrimento do seu visual, o que gera um
bom desempenho em dispositivos de baixa capacidade de processamento e memória.

2.1 Processo de Elicitação de Requisitos

O processo de elicitação de requisitos foi conduzido por meio de duas sessões

de brainstorm, nos quais os participantes fizeram perguntas e levantaram
questionamentos sobre o escopo do sistema. As sessões foram preparadas com um
 6

roteiro de apoio para ajudar na organização dos trabalhos. Além disso foi escolhido
um agente facilitador, que atuou como cerimonialista, com a função principal de
manter o grupo focado, eliminar a inibição e o julgamento.

Antes das sessões serem realizadas o objeto delas já tinha sido apresentado
aos participantes, como uma forma de melhor definir os problemas a serem resolvidos.
Além disso foram distribuídos papéis/documentos para que as anotações fossem
feitas na medida que houvesse necessidade. As sessões duraram uma hora cada, e,
ao final delas, foram feitas representações visuais das ideias trazidas. As
representações visuais foram feitas a partir de colagens, recortes, associações,
imagens pelo agente facilitador.

O resultado das sessões foi um conjunto requisitos funcionais e não funcionais

que serão detalhados a seguir.

Requisitos funcionais: 1) Verificar se o usuário é cadastrado e o perfil de

usuário; 2) Apresentar histórico de vacinação; 3) Agendar vacinação; 4) Alterar dados
cadastrais;

Requisitos não funcionais: 1) Disponibilização do sistema para usuários 22

horas por dia / 7 dias por semana; 2) Disponibilização para atualizações e correções
de segurança durante duas horas por dia / 7 dias por semana; 3) Usuário profissional
da saúde deve ser capaz de registrar a aplicação de uma vacina em 3 cliques; 4)
Aumento da escalabilidade do serviço em 50% dentro de 7 dias.

2.2 Requisitos Extraídos

Abaixo a documentação dos requisitos extraídos, divididos por Requisitos

Funcionais e Requisitos não Funcionais:

2.2.1 Requisitos Funcionais

Identificação do Requisito RC1

Tipo de Requisito Funcional
 7

Objetivo Login de usuário com sucesso.

Estado Inicial -Verificar se usuário está cadastrado no
sistema;
-Verificar qual tipo de usuário.
Estado Final Usuário é redirecionado para a página
do painel administrativo correspondente
ao seu perfil de usuário.
Fluxo Principal 1.Usuário informa e-mail e senha para o
sistema na página de login;
2.O sistema verifica se o e-mail e senha
são válidos;
3.Se o e-mail e senha são válidos,
usuário é redirecionado para sua
respectiva página de perfil.
Fluxo Alternativo 1.Caso o usuário insira um e-mail
inválido, o sistema retornará mensagem
de erro pedindo para verificar erros de
digitação do e-mail;
1.1.Caso o e-mail não corresponda a
um registro válido de usuário dentro do
sistema, perguntar se a pessoa deseja
se cadastrar no sistema;
2.Caso o usuário insira uma senha
inválida, sistema retornará mensagem
de erro pedindo para verificar erros de
digitação da senha e apresentará a
opção para a pessoa reiniciar a senha.

Identificação do Requisito RC2

Tipo de Requisito Funcional
Objetivo Apresentar histórico de vacinação com
possibilidade de edição.
 8

Estado Inicial -Usuário deve possuir acesso ao

sistema.

Estado Final Usuário visualiza histórico de

vacinação.
Fluxo Principal 1.Usuários dos tipos paciente ou
profissional da saúde realizam login no
sistema;
2.Usuários verificam o histórico de
vacinação;
3.Caso seja usuário do tipo profissional
da saúde, pode realizar alterações no
histórico de vacinação do paciente.
Fluxo Alternativo 1.Caso o usuário seja do tipo paciente,
poderá apenas visualizar seu histórico
de vacinas e realizar alterações nos
dados cadastrais e de contato;
2.Caso o paciente não tenha cadastro
no sistema, o profissional da saúde
poderá cadastrar o paciente e atualizar
o histórico de vacinação.

Identificação do Requisito RC3

Tipo de Requisito Funcional
Objetivo Agendamento de vacinação.
Estado Inicial -Usuário deve possuir acesso ao
sistema;
-Usuário deve selecionar a vacina e
local de vacinação.

Estado Final Local, data, local e horário da vacina

agendados com sucesso.
 9

Fluxo Principal 1.Usuário do tipo paciente acessa o

sistema;
2.Usuário clica sobre a opção no menu
“agendar vacina”;
3.Usuário seleciona um posto de saúde
disponível;
4.Usuário seleciona data e horários
disponíveis.
Fluxo Alternativo 1.Caso o usuário não esteja cadastrado
no sistema, será convidado a se
cadastrar;
2.Caso o usuário não encontre um
posto de saúde próximo disponível, será
convidado a buscar em outras
localidades ou aguardar até 24 horas,
para que a base do sistema seja
atualizada e assim realizar uma nova
busca;
3. Caso o usuário não encontre data e
horários disponíveis, será convidado a
aguardar até 24 horas, para que a base
do sistema seja atualizada e assim
realizar uma nova busca.

Identificação do Requisito RC4

Tipo de Requisito Funcional
Objetivo Atualização de dados cadastrais.
Estado Inicial -Usuário deve possuir acesso ao
sistema;
-Usuário deve selecionar qual
informação deseja alterar.
 10

Estado Final Informações cadastrais atualizadas com

sucesso.
Fluxo Principal 1.Usuário acessa o sistema;
2.Usuário seleciona no menu a opção
alterar dados cadastrais;
3.Usuário seleciona a informação que
deseja alterar;
4.Após alterações, o usuário salva a
modificação feita.
Fluxo Alternativo 1.Caso o usuário não esteja cadastrado
no sistema, será convidado a se
cadastrar;
2.Caso o usuário altere e salve uma
informação, mas a mesma não
aparecerá atualizada, poderá abrir um
chamado no suporte.

2.2.1 Requisitos não Funcionais

Identificação do Requisito RD1

Tipo de Requisito Não Funcional
Objetivo Disponibilização do sistema para
usuários 22 horas por dia / 7 dias por
semana.
Estado Inicial Sistema armazenado em nuvem e
disponível para uso.
Estado Final O sistema fica disponível para usuários
acessarem, realizarem consultas e
alterações.
Fluxo Principal 1.O sistema é armazenado em nuvem;
2.Durante 22 horas e 7 dias por
semana, a contar a partir das 2 horas
da manhã até às 23 horas e 59 minutos
 11

da noite, o sistema estará em pleno

funcionamento para uso de todos os
tipos de usuários.
Fluxo Alternativo 1.Caso o sistema saia do ar durante as
22 horas de disponibilidade, o usuário
poderá abrir chamado para o suporte;
2.Caso o usuário perceba erros nas
funcionalidades ou base dedos, poderá
abrir chamado no suporte solicitando
revisão do sistema e até restauração de
backup.

Identificação do Requisito RD2

Tipo de Requisito Não Funcional
Objetivo Disponibilização para atualizações e
correções de segurança durante duas
horas por dia / 7 dias por semana.
Estado Inicial Sistema armazenado em nuvem e
disponível para manutenção.
Estado Final Sistema revisado e atualizado com
sucesso.
Fluxo Principal 1.O sistema é armazenado em nuvem;
2.Durante duas horas e 7 dias por
semana, a contar a partir das 0 horas
até 1 hora e 59 minutos da manhã, o
sistema estará disponível para a equipe
técnica;
3.A equipe técnica deverá acessar a
aplicação;
4.A equipe técnica deverá realizar as
correções e atualizações de
 12

funcionalidades e segurança na
aplicação.
Fluxo Alternativo 1.Caso o sistema saia do ar durante as
22 horas de disponibilidade, a equipe
técnica deverá entrar em ação para
correções emergenciais;
2.Caso a equipe técnica necessite
realizar intervenções no sistema fora do
período de atualizações e correções,
deverá notificar todos os usuários, com
no mínimo 72 horas de antecedência,
através de e-mail e mensagem de alerta
na aplicação.

Identificação do Requisito RD3

Tipo de Requisito Não Funcional
Objetivo Usuário profissional da saúde deve ser
capaz de registrar a aplicação de uma
vacina em 3 cliques.
Estado Inicial Registro de usuário disponível para
atualizações.
Estado Final Registro de usuário atualizado com
sucesso.
Fluxo Principal 1.Usuário do tipo profissional da saúde
deverá acessar o sistema;
2.Posteriormente, localizar o respectivo
usuário paciente;
3.Posteriormente realizar o registro da
dose da vacina aplicada.
Fluxo Alternativo 1.Caso o sistema esteja indisponível, o
usuário deverá abrir um chamado;
 13

2.Caso o usuário paciente não esteja

cadastrado, o usuário profissional da
saúde deverá realizar o cadastro do
paciente no sistema.

Identificação do Requisito RD4

Tipo de Requisito Não Funcional
Objetivo Aumento da escalabilidade do serviço
em 50% dentro de 7 dias.
Estado Inicial Disponibilidade do serviço.
Estado Final Disponibilidade do serviço com
capacidade 50% maior.
Fluxo Principal 1.Aumentar a capacidade de
armazenamento de dados do sistema;
2.Aumentar o número de profissionais
da equipe técnica, para garantir a
qualidade do atendimento.
Fluxo Alternativo 1.Caso não seja possível contratar
novos profissionais, terceirizar
temporariamente parte da equipe
técnica.

3. ESTUDO DE VIABILIDADE

Para que o software funcione conforme foi planejado, será exigido o

desenvolvimento e preparo de outros serviços, como armazenamento e hospedagem,
serviço de geolocalização, comunicação com os bancos de dados dos entes
federativos, entre outros aspectos.

Um ponto importante nesse projeto é a necessidade de os entes federativos

cadastrarem corretamente os postos de saúde de suas jurisdições, isso porque será
onde os usuários serão atendidos. Isto posto, uma vez que as opções oferecidas aos
usuários estarão diretamente ligadas à sua localização (serviço de geolocalização), o
 14

software fará buscas de locais mais próximos ao usuário, evitando que sejam
marcadas consultas em postos muito longes.

Outro ponto importante no tocante à complexidade do projeto é a necessidade

do serviço de cloud, principalmente para armazenamento e hospedagem. Haja vista
a massiva necessidade de se armazenar dados, tanto dos usuários finais, como dos
agentes públicos dos entes federativos, que inserirão dados de várias naturezas.

Um ponto positivo quanto ao presente projeto é que todas as tecnologias que

serão utilizadas já foram desenvolvidas e estão presentes em outros softwares do
mercado, em pleno funcionamento, facilitando suas implementações, bem como
reduzindo os custos de desenvolvimento. Além disso, devido ao fato de aplicativo ter
poucas instruções, não exigindo muito processamento, nem memória, pode funcionar
de forma satisfatória em vários dispositivos, inclusive os menos potentes, bastando
possuir tão somente o sistema operacional compatível.

Do ponto de vista da complexidade econômica, o presente projeto exige

investimentos de alta escala em alguns pontos. Primeiramente, devido ao fato de se
tratar de um software de larga utilização, haja vista o alto número de migração previsto
de usuários de cartão de vacinação impresso para esse software mais moderno, os
custos com armazenamento de dados serão altos. Como será utilizado serviços de
cloud storage, os custos serão mensurados pela volumetria, ou seja, a quantidade de
dados armazenados e utilizados pelos usuários e agentes públicos. Dado a esse fato,
os custos de armazenamento terão uma relação direta com a população estimada de
cada ente federativo. Quanto maior, mais altos serão os custos.

Como já explicado anteriormente, será necessária a utilização de serviços de

terceiros, como o de geolocalização e mapas. Nesse caso, o serviço a ser utilizado
será o Google Maps, que cobra por licença. Aqui, também, trata-se de uma licença
por volumetria, ou seja, quanto maior o número de usuários, maiores serão os custos.

Além disso, é necessário estipular os custos de desenvolvimento do próprio

software. Dado que o aplicativo será disponibilizado em três versões diferentes
(Android, iOS, Windows), é necessário custear o seu desenvolvimento com uma
estimativa de horas utilizadas para finalizá-lo. Dado a baixa complexidade do
aplicativo/serviço, estipulou-se um total de 200 horas para cada plataforma, ou seja,
600 horas para as três plataformas.
 15

O modelo de comercialização é o de licenciamento por assinatura. Assim, os

assinantes (entes federativos) devem pagar a mensalidade para utilização do software
e todos seus serviços, com direito a suporte e utilização do software na versão mais
atualizada. Esse método é de grande vantagem e atrativo para os assinantes, por
mitigar a necessidade de mobilização dos agentes de tecnologia da informação (T.I.)
dos entes federativos para realizarem atualizações no software, uma vez que
atualizações e manutenções do sistema são atividades de responsabilidade da
empresa desenvolvedora.

4. ESTIMATIVA DE ESFORÇO PARA O DESENVOLVIMENTO DA SOLUÇÃO

Utilizaremos o método pontos de função para temos uma estimativa do tempo

e custo do desenvolvimento. A técnica de pontos de função consiste em uma métrica
para estimar tamanho e, consequentemente, tempo e custo de desenvolvimento de
um software. O cálculo é feito com base na estimativa de dois tipos de funções:
Funções de Dados - representam a funcionalidade oferecida ao usuário para cumprir
requisitos de dados. Podem ser de dois tipos:

1. Arquivo Lógico Interno (ALI): tabelas do modelo relacional;

2. Arquivo de Interface Externa (AIE): arquivos externos. Para cada um desses
tipos de funções de dados estimar os seguintes elementos:
a. TER – Tipo de elemento de registro. Subgrupo de dados dentro de um
ALI/AIE reconhecível pelo usuário;
b. TED – Tipo de elemento de dado. Campo único, não repetitivo e
reconhecível pelo usuário O número de pontos de função para cada ALI
e AIE é obtido por meio das seguintes tabelas:

Tabela de Referencias: complexidade de ALI`s e AIE`s

TED
1-19 20-5 >50
TER
1 Baixa Baixa Média
2-5 Baixa Média Alta
 16

>5 Média Alta Alta

Peso das Funções de Dados

Tipo de
Baixa Média Alta
Funcionalidade
ALI x7 x 10 x 15
AIE x5 x7 x 10

Com base no número de TED e TERs estimados em cada ALI e AIR, obtém-se
a complexidade na primeira tabela. Com base na complexidade, consulta-se na
segunda tabela o número de pontos de função (X7, por exemplo, significa que são
pontos de função).

O segundo tipo de funções exigida para o cálculo são as Funções de Transação

- representam a funcionalidade oferecida ao usuário para processar dados da
aplicação. Podem ser de três tipos:

1. Entrada Externa (EE): quaisquer entradas de dados fornecidas pelo

usuário;
2. Saída Externa (SE): relatórios, saídas exibidas ao usuário;
3. Consulta Externa (CE): telas de consultas aos dados armazenados via
EEs.

Para cada um desses tipos de funções de transação e necessário estimar os

seguintes elementos:

1. TARs: tipos de arquivos referenciados. Quantidade de ALIs/AIEs

mantidos (exceto CE) ou referenciados pela função de transação;
2. TEDs: tipos de elementos de dados. Campos reconhecíveis pelo
usuário, que cruzam a fronteira da aplicação durante a Função de
transação. O número de pontos de função para cada EE, SE e CE é
obtido por meio das seguintes tabelas:

Tabela de Referência: complexidade EE’s

TED 1-4 1-6 >15

 17

TER
<2 Baixa Baixa Média
2 Baixa Média Alta
>2 Média Alta Alta

Tabela de Referencia: complexidade de SE’s e CE’s

TED
1-5 6-19 >19
TER
<2 Baixa Baixa Média
2-3 Baixa Média Alta
>3 Média Alta Alta

Peso das Funções de Transação

Tipo de
Baixa Média Alta
Funcionalidade
EE x3 x4 x6
SE x4 x5 x7
CE x3 x4 x6

Com base no número de TED e TARs estimados em cada EE, SE e CE, obtém-
se a complexidade na primeira tabela (EE) e na segunda tabela (SE e CE). Com base
na complexidade, consulta-se na segunda tabela o número de pontos de função (X7,
por exemplo, significa que são pontos de função).

4.1 Elicitação de Entidades

Abaixo estão listadas as entidades que compõe os registros de usuários,

vacinas e unidades de saúde dentro do sistema.

Paciente Unidade de Saúde Endereço Vacina

 18

CPF Nome Logradouro Tipo

RG Número Número Campanha

Cartão SUS Complemento Fabricante

Idade Cidade Data

E-mail CEP Validade

Nome Estado Dose

Bairro

4.2 Diagrama de Entidades de Relacionamentos (DER)

Imagem 1 – Diagrama de Entidades de Relacionamento (DER).

 19

CONSIDERAÇÕES FINAIS

O sistema de carteira de vacinação online é uma solução viável, que se justifica

por apresentar utilidade e contribuição para a saúde pública, por ser uma ferramenta
que auxilia na prevenção de doenças infectocontagiosas. O software apresenta um
valor de investimento com boa relação entre de custo-benefício, principalmente se
comparado à outras iniciativas, como o cartão impresso de vacinação e campanhas
de vacinação mal divulgadas, por falta de métodos eficazes de comunicação. O
esforço para o desenvolvimento e manutenção da solução são razoáveis e, quando
mensurados os benefícios que a solução traz a população, compensam o
investimento.
 20

REFERÊNCIAS

1. ANDRADE, Luiza. Tutorial: como fazer brainstorming passo a passo. Siteware.

Disponível em: <https://www.siteware.com.br/blog/metodologias/como-fazer-
brainstorming-passo-a-passo/.>. Acesso em 24 de maio de 2021.

2. LEONARDO, André. Como acessar a carteira de vacinação digital do SUS.

Tecnoblog, Americana, 09 de fev. de 2021. Disponível
em:<https://tecnoblog.net/409966/como-acessar-a-carteira-de-vacinacao-digital-do-
sus/>. Acesso: 06 de abr. de 2021.

3. LICHIRGU, Ana Gabriela F. B.. Contagem de Pontos de Função. Revista de

Engenharia de Software, Rio de Janeiro, 2016. Disponível em:<
https://www.devmedia.com.br/contagem-de-pontos-de-funcao/34390>. Acesso em:
07 de abr. de 2021.

4. LOPES, Jéssica Pereira et al . Avaliação de cartão de vacina digital na prática de

enfermagem em sala de vacinação. Rev. Latino-Am. Enfermagem, Ribeirão Preto
, v. 27, e3225, 2019 . Disponivel em
<http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-
11692019000100405&lng=en&nrm=iso>. Acesso em 06 abr. de 2021. Epub Dec 05,
2019. http://dx.doi.org/10.1590/1518-8345.3058.3225.

5. MINISTERIO DA SAÚDE. Coronavírus Covid-19: O que você precisa saber,

Brasília, 2020. Disponível em:< https://coronavirus.saude.gov.br/>. Acesso em 07 de
abr. de 2021.

6. SADI. Licenciamento de Software por Assinatura: vantagens que você não pode
ignorar. Sucurra, 22 de jan. de 2018. Disponível em:<
https://www.scurra.com.br/blog/licenciamento-de-software-por-assinatura-vantagens-
que-voce-nao-pode-ignorar/>. Acesso em: 04 de abr. de 2021.