PROJETO INTEGRADO MULTIDISCIPLINAR VII

Prévia do material em texto

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 maiscrí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 
objetivosde 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