PIM VII ANÁLISE E DESENVOLVIMENTO DE SISTEMAS - NOTA 10 REIMUR

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP 
 
 
 
LUIZ FELIPE MENDONÇA – 0580005 
DANIEL SILVA MOREIRA - 0596199 
 
 
 
 
 
 
 
 
 
 
 
PROGRAMA MEDICINA ONLINE 
PROJETO INTEGRADO MULTIDISCIPLINAR VII 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SÃO PAULO 
 2021 
LUIZ FELIPE MENDONÇA - 0580005 
DANIEL SILVA MOREIRA - 0596199 
 
 
 
 
 
 
 
 
 
APLICATIVO MEDICO 
PROJETO INTEGRADO MULTIDISCIPLINAR VII 
 
 
 
 
 
 
Projeto Integrado Multidisciplinar – PIM VII, 
apresentado como um dos pré-requisitos 
para aprovação no bimestre vigente, na 
graduação de Analise e Desenvolvimento 
de Sistemas. 
 
Orientador (a): Priscila Facciolli 
 
 
 
 
 
 
 
 
 
 
 
SÃO PAULO 
 2021
RESUMO 
 
O projeto teve como objetivo atender o que solicitado no projeto integrado 
multidisciplinar VII (PIM VII), com o objetivo de criar um aplicativo de telemedicina 
para unir pacientes necessitados de atendimento com médicos capacitados, assim, 
deixando hospitais e sistemas públicos de saúde apenas para casos de emergência 
e necessidade de atendimento físico. Teve como base para sua elaboração as 
disciplinas estudadas no bimestre, empreendedorismo, gerenciamento de projeto 
de software, gestão da qualidade e projeto de sistemas orientado a objetos, com a 
integração dessas quatro matérias gerou um sistema funcional e seguro para orientar 
e monitorar pacientes que necessitavam de consultas rápidas ou acompanhamento 
médico continuo. O método de pesquisa usando foi o de pesquisa bibliográfica em 
obras de autores entendidos no assunto em questão. Teve como principal objetivo o 
desenvolvimento da parte documental do projeto em questão de modo a atender o 
que solicitado pelo cliente em questão. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Palavras-chave: Sistema. Médicos. Pacientes. Desenvolvimento. Programa. 
ABSTRACT 
 
The project aimed to meet what was requested in the multidisciplinary integrated 
project VII (PIM VII), with the objective of creating a a p p telemedicine system to 
unite patients in need of care with trained doctors thus leaving hospitals and public 
health systems only for urgent cases and need for physical care. Based on the 
elaboration of the disciplines studied in the two months, entrepreneurship, project 
management software, quality management and object-oriented systems design, with 
the integration of these four materials generated a functional and safe system to guide 
and monitor patients who needed quick consultations or continuous medical 
monitoring. The research method used was that of bibliographic research in works by 
authors understood in the subject in question. Its main objective was to develop the 
documentary part of the project in question in order to meet what was requested by 
the client in question. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Keywords: System. Doctors. Patients. Development. Program. 
Sumário 
INTRODUÇÃO ..........................................................................................................................6 
1 PLANO DE NEGÓCIOS ........................................................................................................7 
 EQUIPE ...................................................................................................................................................... 7 
 PRODUTOS E SERVIÇOS ......................................................................................................................... 8 
2 DEFINIÇÕES DE QUALIDADE .............................................................................................9 
 NÍVEL DE MATURIDADE ......................................................................................................................... 10 
 NOSSO NÍVEL DE MATURIDADE ........................................................................................................... 10 
3 OS REQUISITOS ................................................................................................................ 13 
 REQUISITOS FUNCIONAIS DESTE PROJETO ....................................................................................... 13 
 REQUISITOS NÃO FUNCIONAIS ............................................................................................................ 14 
 REGRAS DE NEGÓCIOS ......................................................................................................................... 14 
4 TERMO DE ABERTURA .................................................................................................... 17 
 OBJETIVO E ESCOPO DO PROJETO PMO ......................................................................... 17 
 PARTES INTERESSADAS ....................................................................................................................... 17 
 MATRIZ DE RESPONSABILIDADES ....................................................................................................... 17 
 FORA DO ESCOPO.................................................................................................................................. 18 
 PRAZOS E ORÇAMENTOS ..................................................................................................................... 18 
 RISCOS INICIAIS ..................................................................................................................................... 19 
5 CONCLUSÃO ..................................................................................................................... 20 
REFERENCIAS ..................................................................................................................... 21 
6 
 
INTRODUÇÃO 
 
O presente projeto terá como objetivo a documentação da parte teórica de um 
aplicativo de telemedicina para auxiliar pacientes a terem o devido tratamento sem a 
necessidade de consultas presenciais, assim deixando sistemas de saúde pública e 
hospitais apenas para reais necessidades. 
 
Terá como base as disciplinas de empreendedorismo, gerenciamento de 
projeto de software, gestão da qualidade e projeto de sistemas orientado a objetos, 
das quais empreendedorismo será responsável por documentar a parte de 
desenvolvimento da startup encarregada por gerar o programa de software. 
Gerenciamento de projeto de software cuidará dos cronogramas, e pela definição dos 
papeis de cada integrante da equipe de desenvolvimento. Gestão da qualidade 
definira a metodologia de qualidade de software adotada pela startup e a detalhará. E 
por fim projeto de sistemas orientado a objetos demonstrará os requisitos e regras e 
negocio adotados no projeto. 
 
Servira como exercício da teoria estudada no bimestre nas matérias citadas 
anteriormente, demonstrando de maneira pratica como surgirão os problemas durante 
a programação e suas respectivas soluções no decorrer do projeto. 
 
A metodologia adotada será a de pesquisa bibliográfica fundamentada nos 
principais autores disponíveis sobre o tema em questão, para um melhor 
embasamento teórico das práticas adotadas. 
 
O resultado esperado será a entrega da documentação do projeto atendendo 
as solicitações feiras pelo cliente, nesse caso a empresa farmacêutica BioFarma, com 
a geração de um documento detalhado que auxiliará o entendimento do cliente e da 
equipe de programação, assim, criando um programa coeso que atenda às 
necessidades elicitadas. 
7 
 
1 PLANO DE NEGÓCIOS 
 
Antes de iniciarmos nossas atividades precisamos definir nosso plano de 
negócio para podermos ser uma empresa bem sucedida e atingir o crescimento 
desejado. 
 
O primeiro passo para o empreendedor é que ele precisa planejar o seu 
negócio. Saltar no escuro não e exatamente uma boa pedida. 
Empreendedores tendem a negligenciar o estágio de planejamento, seja pela 
ansiedade em iniciar o novo negócio, seja pela descrença no instrumento ou 
mesmo pela desinformação sobre como elaborar um planejamento. 
 
Precisaremos terdefinidos nossos objetivos desde o princípio, pois uma 
startup (um negócio no geral) não evoluirá se não tiver objetivos a alcançar e 
ultrapassar. 
 
A startup DW.tec (Digital World.tec) terá o diferencial de oferecer ao cliente 
além de um produto de software de qualidade e um suporte a altura deste produto, 
uma experiencia de atendimento mais humana e com qualidade excepcional. Prezara 
pelo atendimento da melhor maneira possível colocando o cliente em primeiro lugar. 
 
O principal objetivo será o respeito a prazos e orçamentos, ou seja, o 
planejamento eficiente, assim fidelizando o contratante para no futuro retornar a busca 
a nossos serviços de atendimento e de desenvolvimento. O plano de negócios, é a 
parte mais importante do planejamento e como citado por Biagio (2005), é o mais 
completo e indispensável instrumento de planejamento para as micro e pequenas 
empresas, tanto nos primeiros momentos de atividade quanto no balizamento dos 
resultados depois de alguns anos de atuação no mercado. 
 
 
 
 Equipe 
 
A equipe terá o objetivo de inovar e transmitir o conhecimento e respeito ao 
cliente, sendo formada por profissionais capacitados nas áreas de tecnologia em 
geral, mas também tendo como foco áreas de gestão de pessoas para gerar esta 
unificação entre a tecnologia e o ser humano. 
 
Este será o proposito desta equipe/empresa aproximar os problemas dos 
clientes aos programadores assim tornando o atendimento mais direto e pessoal para 
8 
 
cada cliente. Como citado por Luiza Helena Trajano em matéria para o site e 
ecommercebrasil (2018): 
 
A empresa que não tiver propósito, equidade de gênero nem preocupação 
com o social será excluída do mercado – não pelos outros varejistas, mas 
pelos próprios clientes, cada vez mais preocupados com a responsabilidade 
das companhias. 
 
E como citado acima não será por sermos uma empresa nova no mercado 
que está não será uma empresa modelo as demais, este tipo de planejamento já no 
início do funcionamento ajudará no crescimento exponencial da empresa no futuro. 
 
 
 
 Produtos e serviços 
 
A empresa terá em seu catalogo especialistas de software para desenvolver 
aplicativos e programas únicos para cada cliente, atuando de início em áreas diversas 
áreas para angariar clientes. O enfoque inicial será em aplicativos multiplataforma, 
para atuar em diversos canais e sistemas de forma simultânea. 
9 
 
2 DEFINIÇÕES DE QUALIDADE 
 
Antes mesmo de iniciar a parte de programação da empresa é necessário 
definir os métodos de qualidade os quais serão seguidos para evitar o que citado por 
Schach (2010) como as crises de software, onde a qualidade desses era inaceitável 
e os prazos e orçamentos não eram respeitados. 
 
Apesar de ainda uma empresa pequena de software os objetivos de 
crescimento são ambiciosos, portanto, desde o início de nossas atividades já existe a 
necessidade de uma metodologia de qualidade que visa esse crescimento. Faremos 
o uso do método conhecido como MPS.br (Melhoria de Processo do Software 
Brasileiro). 
 
Como explicado por Silveira (2012) 
 
O MPS. Br serve 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 possui níveis. Cada nível tem diversas práticas associadas. Uma 
empresa que possui o "selo" MPS. Br utiliza essas boas práticas e, 
teoricamente, tem bastantes condições de desenvolver softwares com 
qualidade e com custos e prazos dentro do estimado. 
 
Como citado existem diversos níveis de maturidade de software no modelo 
MPS.br como podemos ver na figura 1. 
 
Figura 1- Níveis de maturidade do modelo MPS.br 
Fonte: Livro texto (2020) 
10 
 
Os níveis no caso do MPS.br são sete e representam o nível de maturidade 
da empresa que adota esse sistema de classificação, os níveis são sequencias e 
dependentes entre si. 
 
 
 
 Nível de maturidade 
 
Para um entendimento de nosso nível de maturidade atual é necessário 
entender o que cada nível significa e também o porquê da existência de sete quando 
os outros modelos de qualidade apresentam menos níveis para crescimento. Para 
isso vamos verificar o que foi escrito no guia geral de MPS de software disponibilizado 
pela SOFTEX (2012) 
 
A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e 
avaliação adequada aos micros, pequenas e médias empresas. A 
possibilidade de se realizar avaliações considerando mais níveis também 
permite uma visibilidade dos resultados de melhoria de processos em prazos 
mais curtos. 
 
Os sete níveis de maturidade são: A (em otimização), B (gerenciado 
quantitativamente), C (definido), D (largamente 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 possui um foco de onde a empresa deve colocar 
seus esforços de melhoria. 
 
 
 
 Nosso nível de maturidade 
 
Para evitar uma explicação muito técnica o foco será em explicar nosso nível 
de maturidade atual, o nível G (parcialmente gerenciado), para tal nível é necessário 
atingir alguns atributos, assim como para que no futuro haja possibilidade de evolução. 
 
Os atributos do nível G são segundo a SOFTEX (2012); 
 
• Atributo 1.1 – O processo é executado: esse atributo evidencia quanto o processo é 
seguido. 
 
• Atributo 2.1 – O processo é gerenciado: esse atributo evidencia quanto a execução 
do processo é gerenciada com perguntas como: 
11 
 
• Existe uma política organizacional estabelecida e mantida para o processo. 
• A execução do processo é planejada. 
• A execução do processo é monitorada e ajustes são realizados; 
 
Como uma empresa ainda relativamente nova, nosso nível de maturidade 
ainda está se desenvolvendo, porem todas as empresas de software precisaram se 
adaptar aos modelos de qualidade algum dia, assim sendo, começar essa adaptação 
desde o início torna no futuro uma transição muito mais fácil até mesmo para um 
modelo internacional de qualidade, visto que atualmente o modelo MPS.br apesar de 
ser um modelo que abre muitas portas, como a possibilidade de desenvolver 
programas para o governo brasileiro, ele ainda só é aceito em território nacional, 
tornando nossa transição no futuro muito suave, se comparada com empresas já de 
grande porte que para sair para o setor internacional precisam abruptamente mudar 
seu modelo de qualidade para um que não tinham nenhum conhecimento prévio. 
 
O MPS.br foi selecionado no nosso caso devido ao sua referência a diversos 
modelos de qualidade internacional (figura 2), assim sendo sua base é solida e já 
reconhecida aqui no brasil, além de ter sido desenvolvida justamente de maneira a 
facilitar sua implantação em micro e pequenas empresas como citado anteriormente 
nesse trabalho pela SOFTEX. 
 
Figura 2- Componentes do modelo MPS.br 
Fonte: MPS.BR: Guia geral MPS de software, página 14 (2012). 
12 
 
Sendo assim como nosso objetivo é um crescimento calmo e com decisões 
bem pensadas, se torna a melhor escolha, além do fato de nossa empresa pelo menos 
de momento não ter a intenção de sair do território nacional e sim de no futuro 
desenvolver sistemas para o governo de nosso país, o qual já solicita que empresas 
que trabalhem para ele tenham o selo de qualidade MPS.br. 
 
Outro fator importante é o custo de implementação do modelo, o qual é muito 
mais viável a uma empresa que está iniciando agora do que outros modelos como 
CMMI ou ISSO que possuem seus custos de implementação mais elevados, o que os 
torna de certa forma inviáveis ao nosso modelo de negócios atuais. Esse ponto é 
reforçado por Koscianski (2007). 
 
O MPS.BR - Melhoria de processo do Software Brasileiro [...], tem como 
objetivo promover a melhoria da qualidade e da produtividade de soluções e 
serviços de software de acordo com os padrões de qualidade internacional, 
com custos acessíveis às empresas nacionais,principalmente 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 (Capability Maturity 
Model Integration), além de ser adequado à realidade das empresas 
brasileiras. 
‘ 
13 
 
3 OS REQUISITOS 
 
Nesta fase, após algumas reuniões com os interessados no projeto 
(funcionários, gerencia, analistas e clientes envolvidos no projeto) são gerados os 
requisitos que o sistema necessitará ter para ser considerado um sucesso. 
 
Os requisitos de um sistema segundo Sommerville (2007), tem como objetivo 
definir o que o sistema deve fazer, quais as necessidades reais e identificar 
quais restrições existem para que o software seja desenvolvido. É nesse 
passo da engenharia de software que ocorre a comunicação entre o cliente e 
a equipe de desenvolvimento. 
 
 
 Requisitos funcionais deste projeto 
 
A seguir se verá uma lista das necessidades solicitadas para o programa de 
consultas médicas e seus devidos acompanhamentos clínicos a pacientes, estas 
necessidades serão utilizadas para os casos de uso do programa e para verificar se 
os pedidos do cliente foram atendidos no decorrer do desenvolvimento do mesmo. 
 
Requisitos funcionais (RF) descrevem o comportamento esperado de um 
sistema de software, explicita o que o sistema deve fazer e idealmente o que o sistema 
não deve fazer (SOMMERVILLE, 2010). 
 
• RF01 consulta a clientes: Ao inserir e-mail e senha no site o sistema 
deve ser capaz, caso possua cadastro, liberar o login do cliente e caso 
contrário solicitar o cadastro do mesmo, mediante solicitação de e-mail, 
senha, CPF, endereço e telefone validos. 
• RF02 consulta doutores: o sistema de login será o mesmo que para 
pacientes porem ao identificar e-mail e senha cadastrados na lista de 
doutores do sistema o mesmo tem que ser capaz de direcionara o 
médico ao sistema de atendimento ao paciente. 
• RF03 consulta cortesia: o sistema ao identificar um novo CPF na base 
de dados disponibilizará uma consulta gratuita de uma hora a este novo 
cliente. 
• RF04 pagamento: o sistema após a utilização da consulta gratuita 
deve solicitar os dados de pagamento do cliente para consultas futuras 
(apenas cartões de credito serão aceitos inicialmente). 
14 
 
Mediante definição dos requisitos funcionais do sistema também é necessário 
a definição dos requisitos não funcionais para o correto entendimento das 
necessidades antes do início da diagramação e posterior programação. Como citado 
por Sommerville (2010) Requisitos não funcionais (RNF) descrevem restrições sobre 
os serviços oferecidos pelo sistema de software 
 
 
 
 Requisitos não funcionais 
 
Como citado anteriormente a seguir uma listagem dos requisitos não 
funcionais apresentados nesse projeto; 
 
• RNF01 validação: o sistema somente liberara acesso a tela de 
atendimento tanto para médicos quanto para pacientes mediante login 
e senhas validos. 
• RNF02 jornada de trabalho: toda vez que um médico efetuar login ou 
logout este será salvo em seu arquivo com data e horário para posterior 
pagamento de horas de trabalho. 
• RNF03 acesso: o sistema deve ser capaz de conceder privilégios 
diferentes aos logins (médicos/pacientes) assim direcionando cada um 
para sua respectiva área de atendimento. 
• RNF04 pagamento: após a consulta gratuita o sistema só finalizará o 
próximo agendamento mediante verificação do cartão de credito 
apresentado, assim efetuando a cobrança da consulta no ato da 
confirmação do agendamento. 
 
 
 Regras de negócios 
 
As regras de negócios são um conjunto de restrições que definem como um 
processo de negócio de uma organização deve ser executado, além de 
representar determinados conhecimentos a respeito de um processo, 
também representam importantes restrições na execução deste processo 
(BUSINESS RULES GROUP, 2000). 
 
As restrições devem estar bem definidas para assim o projeto não fugir do 
escopo correto que o cliente quer que ele execute, se mantendo dentro das 
expectativas e limitações impostas pelo cliente e localidade onde o sistema será 
instalado para uso. 
15 
 
• Os médicos cadastrados somente serão liberados para atendimento 
mediante apresentação de CRM valido e conferido no site do conselho 
de medicina http://portal.cfm.org.br/ 
• Os médicos após cada consulta devem preencher um breve resumo da 
mesma e o prontuário online que ao enceramento do vídeo chamado 
será apresentado ao médico. 
 
A seguir podemos ver de forma representativa como o documento de casos 
de uso é representado e como servirá para a documentação do sistema. O arquivo 
mais detalhado pode ser consultado no Link: 
https://docs.google.com/document/d/1sa3JHU6uJRWdzVh_Sznlr7KrNsty8QqQEYOq 
bzOMMzM/edit?usp=sharing, tal link online permite atualizações por parte de toda a 
equipe e um histórico de atualizações muito importante para a documentação do 
projeto. 
 
Figura 3- Caso de uso efetuar login 
Fonte: Autoria própria, ferramenta google documentos (2020) 
http://portal.cfm.org.br/
https://docs.google.com/document/d/1sa3JHU6uJRWdzVh_Sznlr7KrNsty8QqQEYOqbzOMMzM/edit?usp=sharing
https://docs.google.com/document/d/1sa3JHU6uJRWdzVh_Sznlr7KrNsty8QqQEYOqbzOMMzM/edit?usp=sharing
16 
 
A seguir a diagramação do caso de uso documentado anteriormente (o 
mesmo arquivo pode ser encontrado na pasta de entrega deste projeto para uma 
melhor visualização) 
 
Figura 4 - Diagrama caso de uso login 
Fonte: Autoria própria, Site app.lucidchart.com (2020) 
17 
 
4 TERMO DE ABERTURA 
 
 Objetivo e escopo do projeto PMO 
 
Este projeto terá como objetivo desenvolver um sistema de controle que una 
médicos e pacientes que necessitam de atendimento nesta época de pandemia 
(COVID-19). 
 
O sistema deverá possibilitar acesso e comunicação de pacientes e médicos 
(com CRM valida e ativa) tendo a capacidade de agendar consultas com especialistas, 
assim deixando hospitais menos lotados e evitando tumultos. Médicos terão acesso a 
um prontuário exclusivo para cada paciente que poderá ser preenchido durante a 
consulta e acessado por outros profissionais caso o cliente desejar uma segunda 
opinião. 
 
O sistema terá uma consulta gratuita de uma hora por usuário cadastrado, 
após esta consulta o sistema deve solicitar um cartão de credito para cobrar o valor 
simbólico de R$10,00 por hora (a consulta será de uma hora no máximo) este valor 
será apenas para manutenção e pagamento dos profissionais. 
 
 Partes interessadas 
 
O principal interessado em nosso projeto, será nosso contratante a empresa 
farmacêutica BioFarma que está em ascensão na atual situação do país e quer entrar 
no mercado de telemedicina. Por parte da empresa teremos a participação do CEO 
(Fabrino Garcia), seu médico chefe (Doutor Charles Silva), os quais serão 
responsáveis por supervisionar e aprovar ideias e projetos da nossa equipe de 
desenvolvimento e programação. 
 
 Matriz de responsabilidades 
 
A seguir uma divisão das responsabilidades por parte da equipe no 
desenvolvimento deste projeto. Esta divisão será apresentada na primeira reunião de 
equipe deixando claro o papel desempenhado por todos os envolvidos. 
18 
 
Figura 5 - Matriz de responsabilidade 
Fonte: Autoria própria (baseado no livro texto 2020) 
 
 Fora do escopo 
 
O sistema não precisará fornecer a feramente de vídeo conferencia apenas o 
sistema de login, agendamento e organização de prontuários online. Tal ferramenta 
em decisão mutua será terceirizada, utilizando a feramente gratuita da gigante da 
comunicação Google, o hangouts, pela segurança oferecida e por todo usuário o qual 
se cadastrarem em nosso sistema necessitam ter um e-mail valido o acesso a 
ferramenta em questão é quase certo. 
 
Mesmo assim o sistema terá tutoriais e abas de ajuda para usuários mais 
inexperientes ou com dúvidas de como proceder para realizar a consulta online. 
 
 
 Prazos e orçamentos 
 
Devido a urgênciada situação atual do país o prazo deste projeto será muito 
reduzido. Tal tem um limite máximo de entrega de 2 meses com orçamento de 
R$10000,00 iniciais. Com um pagamento inicial de 50% e nas cinco últimas semanas 
do projeto durante reuniões de avanço pagamentos parciais de 10% por 
semana/reunião. 
 
Após a publicação do sistema como forma de incentivo e para manter um 
suporte impecável, em contrato foi estabelecido uma participação de nossa empresa 
de 1% da receita gerada pelo programa. Assim quanto mais usuários utilizarem o 
sistema mais suporte será necessário consequentemente nossa empresa recebera 
um valor exponencial assim ficando justo para ambas as partes. 
19 
 
 Riscos iniciais 
 
Segundo Fontoura e Priceeng (2004) 
 
O controle de risco abrange as atividades que tratam da solução do risco. 
Controle de risco é o processo de elaborar planos de resolução de riscos, 
monitorar o status do risco, implementar planos de resolução de riscos, e 
corrigir desvios do plano 
 
Devido a urgência, o prazo é algo a se levar em consideração neste projeto, 
apesar de ser um programa que provavelmente permanecerá pós pandemia seu 
lançamento nesta faze crucial não só alavancará sua disseminação como ajudará na 
contenção do avanço da pandemia. 
 
Além disso a inexperiência da equipe com um projeto desta magnitude 
também não pode ser deixada de lado, mas para evitar uma mancha na reputação de 
nossa empresa consultorias externas serão realizadas caso necessário. Tais 
consultorias ficaram como custo de nossa empresa de software já que o conhecimento 
trazido por consultores será usado em diversos projetos não somente nesse em 
questão. 
20 
 
5 CONCLUSÃO 
 
O presente projeto teve como objetivo a documentação da parte teórica de 
um sistema de telemedicina para auxiliar pacientes a terem o devido tratamento sem 
a necessidade de consultas presenciais, assim deixando sistemas de saúde pública e 
hospitais apenas para reais necessidades. 
 
Teve como base as disciplinas de empreendedorismo, gerenciamento de 
projeto de software, gestão da qualidade e projeto de sistemas orientado a objetos, 
das quais empreendedorismo foi responsável por documentar a parte de 
desenvolvimento da startup encarregada por gerar o programa de software. 
Gerenciamento de projeto de software cuidou dos cronogramas, e das definições dos 
papeis de cada integrante da equipe de desenvolvimento. Gestão da qualidade definiu 
a metodologia de qualidade de software adotada pela startup e a detalhou. E por fim 
projeto de sistemas orientado a objetos demonstrou os requisitos e regras de negócio 
adotados no projeto. 
 
Serviu como exercício da teoria estudada no bimestre nas matérias citadas 
anteriormente, demonstrando de maneira pratica como surgirão os problemas durante 
a programação e suas respectivas soluções no decorrer do projeto. 
 
A metodologia adotada foi a de pesquisa bibliográfica fundamentada nos 
principais autores disponíveis sobre o tema em questão, para um melhor 
embasamento teórico das práticas adotadas. 
 
O resultado foi a entrega da documentação do projeto atendendo as 
solicitações feitas pelo cliente, nesse caso a empresa farmacêutica BioFarma, com a 
geração de um documento detalhado que auxiliou o entendimento do cliente e da 
equipe de programação, assim, possibilitando o início das fazes de desenvolvimento 
e entrega das necessidades elicitadas. 
 
Conforme detalhado nesse trabalho o projeto em questão foi realizado e 
concluído com êxito, assim concluindo seu objetivo de detalhar de maneira 
documental como os requisitos e regras foram desenvolvidas teoricamente, sendo 
assim a parte documental que era parte única e fundamental desse trabalho encontra- 
se concluída apresentando o que solicitado no projeto integrado multidisciplinar VII. 
21 
 
REFERENCIAS 
 
BIAGIO, L. Plano de negócios: estratégia para micro e pequenas empresas. 
Barueri: Manole, 2005. 
 
BUSINESS RULES GROUP. Defining business rules: what are they really? 2000. 
Disponível em: http://www.businessrulesgroup.org/first_paper/BRG- 
whatisBR_3ed.pdf Acesso em: 30 de set. de 2020. 
 
CHIAVENATO, I. Empreendedorismo: dando asas ao espirito empreendedor. São 
Paulo: Saraiva: 2008. 
 
ECOMMERCEBRASIL. Para Luiza Trajano, do magazine Luiza, ‘o cliente é um só’. 
Disponível em: https://www.ecommercebrasil.com.br/noticias/magazine-luiza-cliente- 
um-so/. Acessado em: 21 e setembro, 2020. 
 
FONTOURA, Lisandra M.; PRICEENG, Roberto. Usando GQM para Gerenciar 
Riscos em Projetos de Software. Universidade Federal do Rio Grande do Sul. 
2004. 
 
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software.1. Ed. 
Novatec. 2007. 
 
SCHACH, Stephen R. Engenharia de software: os paradigmas clássicos e 
orientados a objeto. 7. Ed. Porto Alegre. AMGH. 2010. 
 
SILVEIRA, Arthur Rafael da. O que é o MPS.br? Oficina da net. 2012. Disponível 
em: https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-de-processos- 
do-software-brasileiro--mpsbr. Acessado em 30 de set. de 2020. 
 
SOFTEX. MPS.BR: Guia geral MPS de software. 2012. Disponível em; 
https://www.softex.br/wp- 
content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf 
Acessado em 30 de set. de 2020. 
 
SOMMERVILLE, Ian. Engenharia de software, 9ª ed São Paulo: Pearson Addison- 
Wesley. 2010. 
 
SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison- 
Wesley, 2007. 
http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf
http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf
https://www.ecommercebrasil.com.br/noticias/magazine-luiza-cliente-um-so/
https://www.ecommercebrasil.com.br/noticias/magazine-luiza-cliente-um-so/
https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-de-processos-do-software-brasileiro--mpsbr
https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-de-processos-do-software-brasileiro--mpsbr
https://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf
https://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf