UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar

Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

Sara Braga Nogueira – RA 2243249

Ian Vinicius Gonçalves de Marins – RA 2243243

PROJETO INTEGRADO MULTIDISCIPLINAR VII

UNIP EaD Polo República - Metrô República

2023
 Sara Braga Nogueira – RA 2243249

Ian Vinicius Gonçalves de Marins – RA 2243243

PROJETO INTEGRADO MULTIDISCIPLINAR VII

Projeto Integrado Multidisciplinar em

Análise e Desenvolvimento de Projetos

Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em

Análise e Desenvolvimento de Sistemas, apresentado à Universidade Paulista –

UNIP EaD.

UNIP EaD Polo República - Metrô República

2023
 RESUMO

Neste projeto, nosso objetivo principal consiste em criar um aplicativo de

telemedicina voltado para o atendimento de casos que não demandem a presença
física, reservando, assim, as consultas presenciais para situações urgentes ou que
exijam avaliação física do paciente. Para embasar nosso trabalho, utilizamos como
base os conhecimentos adquiridos nas disciplinas disponibilizadas, tais como
gerenciamento de projeto de software, gestão de qualidade, projeto de sistemas
orientados a objetos e empreendedorismo.

Com o auxílio dessas disciplinas, conseguimos desenvolver um sistema capaz

de proporcionar atendimento e monitoramento remoto de pacientes. Adotamos como
método de pesquisa a revisão bibliográfica, consultando obras de autores
relacionadas diretamente ao tema e às disciplinas em questão. A partir dessas
referências, elaboramos a parte documental do projeto de forma a atender às
necessidades estabelecidas.

Palavras-chave: Atendimento, Telemedicina, Distância.

 ABSTRAC

In this project, our main objective is to create a telemedicine application aimed

at handling cases that do not require physical presence, thus reserving in-person
consultations for urgent situations or those involving a physical examination of the
patient. We based our work on the knowledge acquired in the available disciplines,
such as software project management, quality management, object-oriented system
design, and entrepreneurship.

With the assistance of these disciplines, we were able to develop a system

capable of providing remote patient care and monitoring. We employed a literature
review as our research method, consulting works by authors directly related to the topic
and the relevant disciplines. Based on this literature, we formulated the project's
documentation to meet the established needs.

Keywords: project, booking, prototype, audiovisual.

 Sumário

1. Introdução .................................................................................................................................... 6

2. Plano de negócio ........................................................................................................................ 7

1.2 Equipe ..................................................................................................................................... 7

1.3 Produtos e Serviços............................................................................................................ 8

2. Definições de qualidade ........................................................................................................... 8

2.1 Níveis de maturidade ..................................................................................................... 9

2.2 Nosso nível de maturidade ........................................................................................ 10

3.1 Requisitos funcionais do projeto ............................................................................. 12

3.2 Regras de negocio ....................................................................................................... 14

4.Termo de abertura ........................................................................................................................ 17

4.1 Partes interessadas .......................................................................................................... 17

4.2 Fora do escopo .................................................................................................................. 18

4.3 Prazos e orçamento ..................................................................................................... 18

4.4 Riscos iniciais ............................................................................................................... 18

Conclusão .......................................................................................................................................... 20

Referências ........................................................................................................................................ 21
 6

1. Introdução

Neste projeto, nosso objetivo principal consiste em detalhar a parte teórica de um

aplicativo voltado para telemedicina. O propósito é reduzir a necessidade de presença
física dos pacientes em hospitais, aliviando a sobrecarga do sistema público de saúde
e permitindo a presença física apenas em situações de extrema necessidade.

Para a elaboração deste projeto, nos basearemos nas disciplinas do semestre,

que incluem gerenciamento de projetos de software, empreendedorismo, projeto de
sistemas orientados a objetos e gestão de qualidade. No contexto do
empreendedorismo, documentaremos o desenvolvimento do startup responsável por
criar o programa de software.

A disciplina de gerenciamento de projetos de software será fundamental para

estabelecer cronogramas e definir as funções de cada membro da equipe. A gestão
de qualidade desempenhará um papel importante na definição da metodologia de
qualidade adotada pelo startup. Além disso, a disciplina de projeto de sistemas
orientados a objetos será crucial para descrever as regras, requisitos e aspectos de
negócios incorporados no projeto.

Utilizaremos a pesquisa bibliográfica para embasar nossas decisões, com base

nas contribuições de especialistas no campo, a fim de garantir que o projeto atenda
às necessidades do cliente (Biofarma). Nosso objetivo principal é criar um projeto que
forneça orientações claras para a equipe de desenvolvimento de software, permitindo
que eles alcancem os objetivos estabelecidos.
 7

2. Plano de negócio

No contexto deste projeto, a primeira etapa essencial é a definição do plano de

negócios. Isso visa estabelecer os alicerces para a criação de uma empresa ou projeto
de sucesso, com a aspiração final de alcançar um crescimento substancial. Planejar
o negócio é imperativo; não podemos simplesmente lançar-nos ao desconhecido e
esperar pelo melhor. Mesmo quando temos confiança de que o negócio "irá
prosperar", é inconcebível negligenciar a elaboração de um planejamento. A utilização
adequada dessa ferramenta de planejamento é essencial para obter vantagens
significativas.

Em suma, é crucial estabelecer nossos objetivos desde o início do projeto, pois é

somente através de metas e objetivos bem definidos que conseguiremos progredir e
superá-los. A nossa empresa, denominada TA.tec (Tecnologia Avançada.tec), terá
como diferencial a oferta de um atendimento humanizado, um suporte excepcional
para o nosso produto e, é claro, um software de alta qualidade. O nosso foco será
aprimorar a experiência do cliente, assegurando-lhe que sua voz seja ouvida e
valorizada.

Comprometemo-nos a respeitar os prazos e orçamentos, com a intenção de

fidelizar os nossos clientes. Desejamos que eles voltem a utilizar os nossos serviços
devido à garantia de um tratamento leal e respeitoso. Reconhecemos que o plano de
negócios é a parte mais crítica do planejamento, como enfatizado por Biagio (2005):

"É o instrumento de planejamento mais completo e indispensável para micro e

pequenas empresas, tanto nos estágios iniciais quanto para orientar os resultados
após alguns anos de atuação no mercado."

1.2 Equipe
Com o propósito de inovação e enriquecimento da experiência do cliente, nossa
equipe será composta por profissionais tanto da área de tecnologia quanto da área de
gestão de pessoas. O objetivo é estreitar e humanizar a relação entre o cliente e a
tecnologia, permitindo que o cliente compartilhe suas necessidades e soluções de
forma direta conosco. Desejamos estabelecer uma comunicação aberta entre o cliente
e o programador, proporcionando um atendimento mais pessoal e próximo.
 8

Como mencionado por Luiza Helena Trajano em um artigo para o site

ecommercebrasil (2018):

"Empresas que não têm propósito, não promovem a equidade de gênero e não
demonstram preocupação social serão excluídas do mercado - não pelos
concorrentes, mas pelos próprios clientes, que estão cada vez mais atentos à
responsabilidade das empresas em suas ações."

Mesmo sendo uma empresa nova no mercado, nosso foco não se desviará de
ser um modelo para outras empresas. O planejamento cuidadoso desde o início nos
proporcionará um apoio sólido para um crescimento sustentável no futuro.

1.3 Produtos e Serviços

A nossa empresa será composta por especialistas em software, dedicados a
criar produtos de software personalizados para cada cliente. Inicialmente,
abordaremos a diversidade de oportunidades que o mercado oferece, com o objetivo
de conquistar clientes. Daremos ênfase à criação de aplicativos "multiplataforma", o
que nos permitirá operar em vários canais ao mesmo tempo.

2. Definições de qualidade
Antes de iniciar a programação, é crucial estabelecer os métodos de qualidade
que serão rigorosamente seguidos. Isso visa evitar as situações que foram
destacadas por Schach (2010) como as "crises de software," nas quais a qualidade
do software era inaceitável, e os prazos e orçamentos não eram respeitados.

Embora sejamos uma empresa pequena no setor de software, mantemos

ambições significativas em relação ao crescimento. Portanto, desde o início,
concentramo-nos em adotar uma metodologia de qualidade que promova esse
crescimento. Nesse sentido, optamos por implementar o método MPS.Br (Melhoria de
Processo de Software Brasileiro), como destacado por Silveira (2012):

"O MPS.Br atua como um selo que indica o nível de maturidade da empresa
em relação às práticas relacionadas ao desenvolvimento de software. Esse selo
engloba diversos níveis, e cada um deles inclui várias práticas associadas. Uma
empresa que possui o selo MPS.Br adota essas melhores práticas e, teoricamente,
 9

está bem preparada para desenvolver softwares com qualidade, dentro dos prazos e
orçamentos estimados."

No modelo MPS.Br, existem diversos níveis de maturidade de software, como

ilustrado abaixo:

Figura 1- Figura 1 – Níveis de maturidade do modelo MPS.br

No modelo MPS.br são sete níveis que representam os níveis de maturidade,

neste caso os níveis de maturidade são sequenciais e dependem um do outro.

2.1 Níveis de maturidade

Para obter um entendimento claro do nível de maturidade atual, é de extrema
importância compreender o significado de cada nível e por que existem sete níveis,
enquanto outros modelos de qualidade têm um número menor de estágios de
crescimento. Para uma explicação mais abrangente, recorremos ao Guia Geral de
MPS de Software disponibilizado pela SOFTEX (2012):

"A divisão em sete estágios tem como objetivo facilitar a implementação e

avaliação adequada, especialmente para micro, pequenas e médias empresas. A
inclusão de mais níveis possibilita uma melhor visão dos resultados das melhorias nos
processos em prazos mais curtos. Os sete níveis de maturidade são: A (Otimização),
 10

B (Gerenciado Quantitativamente), C (Definido), D (Amplamente Definido), E

(Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de
maturidade começa no nível G e avança até o nível A. Cada nível concentra-se em
áreas específicas nas quais a empresa deve direcionar seus esforços para aprimorar
seus processos."

Isso explica por que o modelo MPS.Br inclui sete níveis de maturidade, permitindo
uma abordagem mais granular e adaptável à realidade das empresas, especialmente
aquelas de menor porte. Isso também possibilita a avaliação e melhoria contínua dos
processos em um período de tempo mais curto, atendendo às necessidades das
empresas em diferentes estágios de desenvolvimento.

2.2 Nosso nível de maturidade

Com o objetivo de simplificar a explicação, concentraremos nossa atenção no

nível atual em que nos encontramos, o nível G (parcialmente gerenciado). Para
alcançar esse nível, é necessário cumprir determinadas metas e continuar
trabalhando para possibilitar nossa evolução no futuro.

De acordo com as diretrizes da SOFTEX (2012), os atributos do nível G são os

seguintes:

o Execução do Processo: Este atributo destaca o quanto o processo é

seguido.
o Gerenciamento do Processo: Este atributo avalia o grau de gerenciamento
da execução do processo e inclui questões como:
o Existe uma política organizacional estabelecida e mantida para o
processo?
o A execução do processo é planejada?
o A execução do processo é monitorada e ajustes são realizados?

Dado o curto período de existência de nossa empresa, o nível de maturidade

ainda está em desenvolvimento. No entanto, é essencial que nos alinhemos com os
modelos de qualidade desde o início para evitar problemas futuros. Essa abordagem
nos prepara para uma transição mais suave para outros modelos de qualidade,
inclusive internacionais. Ao adotar o modelo MPS.Br agora, estamos adquirindo
experiência. Embora esse modelo se aplique principalmente ao território nacional, ele
 11

nos prepara para uma possível transição para um modelo de qualidade internacional,
ao contrário de empresas que crescem sem um modelo e enfrentam dificuldades para
se adequar aos padrões internacionais exigidos.

Selecionamos deliberadamente o modelo MPS.Br devido à sua inclusão de

referências internacionais e à sua adaptabilidade para implantação em micro e
pequenas empresas no cenário nacional. Na imagem a seguir, é possível observar
os componentes do modelo MPS.Br.

Figura 2- Componentes do modelo MPS.br

Fonte: MPS.BR: Guia geral MPS de software 1

Dado nosso desejo de alcançar um crescimento constante e tomar decisões

com responsabilidade, a escolha do modelo MPS.Br se revela uma decisão acertada.
Isto se deve ao fato de que nosso plano de curto prazo não envolve a expansão para
além do território nacional, mas sim o desenvolvimento futuro de produtos destinados
ao governo nacional. É importante mencionar que uma das exigências para empresas
que desejam fornecer produtos de software ao governo é a obtenção do selo de
qualidade MPS.Br.

O custo de implementação do modelo se mostra viável para uma empresa em

estágio inicial, quando comparado a outras opções disponíveis, como o CMMI ou o
 12

ISO, que demandam investimentos substanciais em sua implementação. Essa

percepção é respaldada por Koscianski (2007), que afirma:

"O MPS.Br (Melhoria de Processo do Software Brasileiro) tem como objetivo

aprimorar a qualidade e a produtividade de soluções e serviços de software, seguindo
os padrões de qualidade internacionais, mas com custos acessíveis para as empresas
nacionais, especialmente as de pequeno e médio porte. Ele está em conformidade
com as normas internacionais ISO/IEC 12207 e 15504, e é compatível com o CMMI
(Modelo de Maturidade de Capacidade Integrado), além de se adequar à realidade
das empresas brasileiras."

Portanto, a escolha do modelo MPS.Br não apenas se alinha com nossos

objetivos de crescimento, mas também se revela economicamente sensata para uma
empresa iniciante como a nossa.

3. Os requisitos

Ao reunir os principais interessados no projeto e conduzir uma reunião, são

estabelecidos os requisitos que devem ser incorporados ao sistema para assegurar
o sucesso do projeto.

De acordo com Sommerville (2007):

"Os requisitos de um sistema têm como finalidade definir as funcionalidades que

o sistema deve apresentar, identificar as necessidades reais e estabelecer as
restrições que devem ser consideradas durante o desenvolvimento do software. É
nessa etapa da engenharia de software que ocorre a comunicação eficaz entre o
cliente e a equipe de desenvolvimento."

3.1 Requisitos funcionais do projeto

A seguir, procederemos à elaboração de uma lista das necessidades exigidas

pelo projeto. Utilizaremos essas necessidades para a criação do caso de uso do
programa e para verificar se os requisitos estabelecidos pelo cliente foram atendidos
no desenvolvimento do projeto. Conforme explicado por Sommerville (2010),
"requisitos funcionais descrevem o comportamento esperado de um sistema de
 13

software, especificando o que o sistema deve fazer e, idealmente, o que o sistema

não deve fazer". Abaixo, descrevemos os requisitos funcionais do sistema:

RF01 - Consulta a Pacientes:

o Quando o paciente inserir informações como e-mail e senha, o sistema

verificará se há um cadastro existente.
o Se o paciente estiver cadastrado, ele terá acesso ao sistema.
o Caso contrário, ele será direcionado para realizar o cadastro, fornecendo
informações pessoais, como CPF, endereço, telefone, e-mail válido e senha.

RF02 - Consulta a Doutores:

o A tela de login para médicos será a mesma utilizada pelos pacientes.

o Após o login, o médico será redirecionado para uma área exclusiva no
sistema, onde poderá atender os pacientes.

RF03 - Consulta Cortesia:

o Ao informar na tela de login que se trata de um primeiro acesso e digitar o CPF,

o paciente receberá uma notificação informando que ele recebeu uma consulta
gratuita de uma hora.

RF04 - Pagamento:

o Após a utilização da consulta gratuita, o sistema solicitará ao paciente que

insira informações de pagamento, caso ele planeje realizar consultas futuras.

Após a definição dos requisitos funcionais do sistema, é necessário também

estabelecer os requisitos não funcionais, a fim de compreender as restrições
relacionadas aos serviços oferecidos pelo sistema de software, conforme destacado
por Sommerville (2010). Aqui estão os requisitos não funcionais:

RNF01 - Validação:

o Somente pacientes e médicos que efetuarem login e forem validados terão

acesso ao sistema.

RNF02 - Jornada de Trabalho:

 14

o A medição da jornada de trabalho dos médicos será registrada por meio de

login e logout no sistema, ou seja, entrada e saída no sistema.

RNF03 - Acesso:

o O sistema deverá direcionar pacientes e médicos para suas áreas de

atendimento correspondentes, garantindo que cada um acesse apenas a sua
área de atuação.

RNF04 - Pagamento:

o Após a utilização da consulta gratuita, o paciente só poderá agendar outra

consulta após fornecer informações de pagamento.
o Em seguida, haverá um processo de validação, cobrança e confirmação da
consulta.

Esses requisitos funcionais e não funcionais são essenciais para orientar o

desenvolvimento do sistema de software, garantindo que atenda às necessidades do
cliente e funcione de maneira eficaz.

3.2 Regras de negocio

"As regras de negócio consistem em um conjunto de restrições que definem a
maneira como um processo de negócio de uma organização deve ser executado.
Elas não apenas representam o conhecimento relativo a um processo, mas também
impõem restrições significativas à sua execução" (BUSINESS RULES GROUP,
2000).

Para garantir que o projeto permaneça alinhado com as expectativas do cliente

e não se desvie do escopo pretendido, é essencial que essas restrições sejam
claramente definidas. Isso ajuda a manter o projeto dentro dos limites e das
expectativas estabelecidas pelo cliente, bem como a considerar o ambiente em que
o sistema será instalado e utilizado.

Aqui estão algumas das regras de negócio identificadas:

1. Todos os profissionais que realizam atendimentos devem possuir um CRM

válido, que pode ser verificado no site do Conselho de Medicina.
 15

2. Após cada atendimento, o médico deve criar um breve resumo do que

ocorreu na consulta. Em seguida, o prontuário online será disponibilizado ao
médico.

Agora, podemos visualizar como um caso de uso é representado de forma

significativa e como ele contribui para a documentação do sistema:

Caso de Uso: Efetuar Login

o Identificação: Efetuar Login

o Escopo: Sistema online acessível por meio de um computador com
conexão à internet em nosso site.
o Descrição do Propósito: Este caso de uso permite que médicos ou
pacientes realizem o processo de login no sistema.
o Ator Primário: Médico/Paciente
o Interessados: Médico/Paciente
o Pré-condição: O computador deve estar ligado e conectado a uma rede
local funcional.
o Pós-condição: O médico ou paciente efetua o login com sucesso e obtém
acesso ao sistema de atendimento correspondente.

Fluxo Normal

1. O médico ou paciente insere seu login e senha.

2. O sistema verifica a validade do login e senha, bem como a qual banco de dados
eles pertencem.
3. O sistema redireciona o usuário para a tela de boas-vindas correspondente.

Fluxos Alternativos

1.1 Caso a senha estiver incorreta, o sistema exibirá a mensagem "Dados digitados
incorretamente".

1.2 Caso o e-mail não estiver registrado na base de dados, será exibida a
mensagem "E-mail não encontrado. Favor realizar o cadastro".
 16

2.1 Caso o login estiver na base de dados "médicos", o sistema direcionará o médico
para o sistema de atendimento profissional.

2.1.1 Caso o login do médico for confirmado, o sistema registrará o horário de

entrada na ficha do médico correspondente.

2.2 Caso o login estiver na base de dados "pacientes", o sistema direcionará o

paciente para o sistema de boas-vindas do paciente.

Requisitos Relacionados: RF01, RF02, RNF01, RNF02, RNF03

Caso de Uso: Cadastro de Clientes

o Identificação: Cadastro de Clientes

o Escopo: Sistema acessível por meio de um computador com conexão à
internet, em nosso site.
o Descrição do Propósito: Este caso de uso permite que os usuários realizem o
processo de cadastro em nosso sistema.
o Ator Primário: Usuário
o Interessados: Usuário e Empresa
o Pré-condição: O computador deve estar ligado e conectado a uma rede local
funcional, e o usuário deve estar fazendo seu primeiro acesso ao sistema.
o Pós-condição: Um novo cliente é cadastrado com sucesso no sistema.

Fluxo Normal

1. Um novo cliente acessa a página de login de nosso sistema.

2. O usuário escolhe a opção "Realizar Cadastro".
3. O usuário preenche os campos obrigatórios, que incluem nome, e-mail,
senha, telefone, endereço e CPF.
4. O cadastro é concluído com êxito.

Fluxos Alternativos
 17

3.1 Caso algum dos campos for preenchido incorretamente, o botão de prosseguir
não estará disponível.

3.2 Caso o e-mail já estiver cadastrado, uma mensagem informando "E-mail já está
cadastrado" será exibida.

3.3 Caso o CPF já estiver cadastrado, uma mensagem informando "Cliente já

cadastrado. Efetue o login na tela inicial" será exibida.

Requisitos Relacionados: RF01, RNF01.

4.Termo de abertura
Objetivo e Escopo do Projeto PMO

O propósito deste projeto é estabelecer uma solução alternativa para o

atendimento médico à distância, em resposta à pandemia de COVID-19. Este sistema
visa facilitar a comunicação entre médicos devidamente registrados com CRM válido
e pacientes, permitindo que eles agendem consultas e realizem consultas remotas
com os especialistas de sua escolha. O objetivo principal é reduzir a sobrecarga nos
hospitais, proporcionando uma alternativa segura e eficaz.

Dentro deste sistema, os médicos têm a capacidade de formalizar prontuários

dos pacientes, os quais podem ser compartilhados com outros profissionais de saúde,
caso o paciente opte por buscar uma segunda opinião.

Como mencionado anteriormente, cada novo usuário terá direito a uma

consulta gratuita inicial. Após a primeira consulta, o paciente deverá cadastrar suas
informações de pagamento caso deseje continuar agendando consultas. O valor
simbólico de R$ 10,00 por consulta será aplicado, e esse montante será destinado
principalmente à cobertura de custos de manutenção do sistema e remuneração dos
profissionais de saúde envolvidos.

4.1 Partes interessadas

O principal interessado neste projeto, sem dúvida, é o nosso contratante, a empresa
farmacêutica BioFarma. Dada a atual situação do país, a BioFarma está em pleno
crescimento e busca uma entrada rápida no mercado de telemedicina. Fabrino Garcia,
CEO da empresa, e o Dr. Charles Silva, médico-chefe, desempenharão papéis
 18

fundamentais, supervisionando nossa equipe de desenvolvimento, a fim de garantir

que o projeto esteja alinhado com suas expectativas e requisitos.

4.2 Fora do escopo

No sistema, não será necessário desenvolver uma ferramenta de vídeo, uma
vez que iremos utilizar ferramentas de terceiros prontamente disponíveis no mercado,
que são gratuitas, seguras e eficazes. Os usuários apenas precisarão ter um cadastro
na ferramenta escolhida. O sistema incluirá suas próprias ferramentas para
funcionalidades como login, agendamento e organização dos prontuários.

Além disso, disponibilizaremos uma seção de "Ajuda" no sistema, onde os

usuários que não estão familiarizados com a tecnologia poderão encontrar
orientações passo a passo para facilitar a realização de suas consultas.

4.3 Prazos e orçamento

Dada a situação atual do país, é evidente que este projeto precisa ser concluído
em um prazo bastante curto. Planejamos um período de dois meses para a entrega
do projeto, com um orçamento inicial de dez mil reais. O primeiro pagamento será
de cinquenta por cento desse valor, conforme acordado com o cliente. Nos últimos
cinco semanas do projeto, o valor restante será dividido em cinco parcelas iguais,
com um pagamento de dez por cento do valor a cada semana.

Concordamos que, ao implementar o sistema, a empresa receberá uma

porcentagem do valor arrecadado com o uso do sistema. Essa porcentagem será
calculada com base na receita gerada, reconhecendo que quanto mais usuários
utilizarem o sistema, maior será o suporte necessário e, consequentemente, maior
será o retorno financeiro que nossa empresa receberá.

4.4 Riscos iniciais

Como mencionado por Fontoura e Priceeng (2004), "O controle de risco envolve
as atividades relacionadas à resolução de riscos. O controle de risco é o processo de
elaborar planos para abordar riscos, monitorar o status dos riscos, implementar planos
de resolução de riscos e ajustar o plano, quando necessário."

Este projeto é de extrema urgência devido à atual situação do país, uma vez
que o software pode desempenhar um papel fundamental na contenção da pandemia.
Além de sua utilidade durante a pandemia, é provável que o software continue sendo
 19

usado após o período pandêmico, uma vez que elimina a necessidade de que as
pessoas se desloquem para hospitais em certos casos.

Dado que nossa equipe não possui experiência prévia em projetos com essa
magnitude de urgência, estamos tomando medidas proativas para evitar danos à
imagem da empresa. Para isso, contaremos com consultorias externas, visando a
redução de erros e o desenvolvimento de um programa eficiente. O conhecimento
adquirido por meio dessa consultoria será valioso e será aplicado em projetos futuros.
 20

Conclusão

Neste projeto, enfrentamos o desafio de documentar a fundamentação teórica

de um sistema voltado para a área médica. Trata-se de um sistema em que os
pacientes não precisariam mais realizar consultas médicas fisicamente, já que essas
consultas seriam conduzidas por meio de video-chamadas. O objetivo principal ao
desenvolver esta solução de telemedicina era aliviar a sobrecarga dos hospitais,
especialmente durante a pandemia, quando é crucial evitar aglomerações e o contato
presencial.

A execução do projeto envolveu diversas disciplinas, cada uma

desempenhando um papel fundamental:

 O empreendedorismo desempenhou um papel crucial ao identificar a oportunidade

e estabelecer os fundamentos para a criação da empresa voltada para o projeto.
 O gerenciamento de projeto de software desempenhou um papel central na gestão
do cronograma e na atribuição de funções a cada membro da equipe de
desenvolvimento.
 A gestão da qualidade foi responsável por definir a metodologia de qualidade que
seguimos para conduzir o desenvolvimento do software.
 O projeto de sistemas orientado a objetos orientou-nos na identificação e adoção
dos requisitos e regras necessários para o projeto.

Além disso, realizamos uma pesquisa bibliográfica, com base nos principais
autores do campo de estudo, e os resultados obtidos nos permitiram atender às
expectativas do projeto estabelecidas pela empresa farmacêutica BioFarma.
Acreditamos que a conclusão deste trabalho cumpriu integralmente as diretrizes
estabelecidas, com ênfase na parte documental, que foi o ponto central do projeto.
 21

Referências
BIAGIO, L. P. (25 de setembro de 2005). Plano de negócios: estratégia para micro e pequenas
empresas. Fonte: BUSINESS RULES GROUP.:
http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_ Bed.pdf

CHIAVENATO, I. (25 de setembro de 2023). Empreendedorismo: dando asas ao espirito

empreendedor. Fonte: ECOMMERCEBRASIL:
https://www.ecommercebrasil.com.br/noticias/magazine-luizacliente-um-so/

FONTOURA, L. M. (24 de setembro de 2023). Usando GQM para Gerenciar. Universidade Federal do
Rio Grande do Sul., p. 16.

KOSCIANSKI, A., & SOARES, M. d. (24 de setembro de 2023). Qualidade de Software.1. . Ed. Novatec,
p. 395.

MPS.BR: Guia geral MPS de software. (23 de setembro de 2023). Fonte: SOFTEX:
https://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia

SCHACH, S. R. (2010). Engenharia de software: os paradigmas clássicos e orientados. Porto Alegre:

AMGH.

SILVEIRA, A. R. (23 de setembro de 2023). Oficina da net. 2012. Fonte: O que é o MPS.br?:
https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-deprocessos-do-
software-brasileiro--mpsbr