PIM_VII UNIP ADS 2020

Prévia do material em texto

8
9
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
PROJETO DE DESENVOLVIMENTO DO SISTEMA MEDTECH CONSULTA A DISTÂNCIA
UNIP Polo Japão
2020
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
PROJETO DE DESENVOLVIMENTO DO SISTEMA MEDTECH CONSULTA A DISTÂNCIA
Nome: Matheus Tomio Carneiro Matsushita
RA: 0512673
Curso: Analise e Desenvolvimento de Sistemas
Semestre: 3º Semestre
UNIP Polo Japão
2020
RESUMO
O seguinte trabalho tem como objetivo, solucionar o caso apresentado pela UNIP Interativa no qual encontramos o cenário de pandemia que tem provocado a necessidade de que as pessoas adotem medidas preventivas afim de evitar e diminuir os casos de contagio da doença causada pelo coronavirus. 
O projeto a ser apresentado, visa solucionar o problema vivenciado pela instituição trazendo aos pacientes e funcionários uma solução para o problema vivenciado, permitindo que se realize consultas por meio de vídeo conferencia. Permitindo que os pacientes que se encontram em isolamento, não quebrem as medidas e ambas as partes se conservem seguras e menos expostas ao vírus. 
Palavras-chave: Tecnologia, Projeto, Hospital, Covid-19.
ABSTRACT
The following work aims to solve the case presented by UNIP Interactive in which we find the pandemic scenario that has caused the need for people to take preventive measures in order to avoid and decrease cases of disease infection caused by coronavirus.  
The project to be presented, aims to solve the problem experienced by the institution by bringing patients and employees a solution to the problem experienced, allowing consultations to be made through video conferencing. Allowing patients who are in isolation, do not break the measurements and both parties remain safe and less exposed to the virus.
Keywords: Technology, Project, Hospital, Covid-19.
SUMÁRIO
1.	INTRODUÇÃO	8
2.	PLANO DE NEGOCIOS	8
3.	VISÃO GERAL DO SISTEMA	10
4.	REQUISITOS FUNCIONAIS	10
5.	REQUISITOS NÃO FUNCIONAIS	14
6.	REGRAS DE NEGÓCIOS	15
7.	DIAGRAMAS	17
a.	Diagrama de Caso de Uso.............................................................18
b.	Diagrama de Atividades................................................................19
c.	Diagrama de Classes.....................................................................20
d.	Diagrama de Sequência.................................................................21
e.	Diagrama de componentes e implementação.............................24
8.	METODOLOGIA DE QUALIDADE	25
9.	ABERTURA DO PROJETO	26
10.	CONCLUSÃO	28
REFERÊNCIAS BIBLIOGRÁFICAS	30
TABELA DE ILUSTRAÇÕES
Figura 1 - Diagrama de caso de uso	18
Figura 2 - Diagram de atividades	19
Figura 3 - Exemplo de Classe	20
Figura 4 – Diagrama de classes	21
Figura 5 - Diagrama de sequência usuário moderador	22
Figura 6 - Diagrama de sequência usuário médico	22
Figura 7 - Diagrama de sequência usuário paciente	23
Figura 8 - Diagrama de componentes e implementação	24
INTRODUÇÃO
O projeto desenvolvido se trata de um software para trazer a solução do problema enfrentado por um hospital onde é necessário a implementação de mudanças na forma de atendimento de seus pacientes, visando garantir a segurança da saúde de toda a equipe do estabelecimento e consequentemente de outras pessoas que aderiram a medida de isolamento social como manobra para que se diminua os casos de contagio e propagação do COVID-19.
O projeto foi desenvolvido para auxiliar o hospital de maneira que se tenha uma melhor gerencia de seus agendamentos e também ser implantado o sistema de teleconsulta, método que dispensa a presença do paciente no consultório médico para realização da avaliação pelo profissional de saúde.
Abordaremos no projeto trabalhado pontos como a apresentação dos requisitos em geral do sistema, diagramas para que se entenda como o software deve trabalhar e também o termo de abertura do projeto. 
PLANO DE NEGOCIOS
 Detalhamento do negócio
Nossa empresa tem como objetivo para atuação no mercado de desenvolvimento de softwares e soluções no nicho de tecnologia em geral. Apesar de pouco tempo atuando no mercado a empresa tem adquirido ao longo dos últimos anos experiências relevantes e de grande importância com os projetos desenvolvidos para os clientes que compõe a carteira de clientes até o momento.
 Setor de atuação
A empresa tem o foco direcionada para o desenvolvimento de softwares e ferramentas que apresente soluções para os problemas levantados pelos clientes que nos procuram.
Produtos ou serviços ofertados
Desenvolvimento de websites, apps, softwares e ferramentas
Mercado consumidor potencial
Grandes e medias empresas.
Necessidade de capital
Capital humano: Dobrar o tamanho da equipe. Atualmente contamos com 15 profissionais e para que o negocio cresça e se desenvolva foi feita uma projeção de se contratar mais 15 profissionais.
Capital físico: Investir na ampliação de infraestrutura como: aquisição de mais quantidade de máquinas, ampliar o espaço de trabalho da equipe.
Capital financeiro: De acordo com a projeção realizada estima-se que o capital a ser investido será de R$ 700.000,00. 
Estimativas de faturamento mensal
Baseado na atual situação da empresa, após analise e projeção realizada com os dados propostos para o plano de negócio.
Estima-se um faturamento mensal de R$ 160.000,00
 
Previsão de Retorno do Capital Investido
Projeção para retorno de investimento: 14 meses
Sócios e empreendedores envolvidos
Os sócios são compostos por familiares, já os investidores não sócios tratam-se de terceiros que buscavam por uma oportunidade de investimento promissor na área de tecnologia.
VISÃO GERAL DO SISTEMA
O sistema consiste, basicamente, do gerenciamento de agendamento de consultas médicas e também tem suporte para que o médico possa realizar uma consulta por vídeo conferência.
O sistema tem como objetivo principal, dar a possibilidade que essa modalidade de consulta esteja disponível devido o cenário atualmente enfrentado por todos.
REQUISITOS FUNCIONAIS
RF 001: Cadastro de usuário médico
Descrição: Somente o funcionário designado pela clínica como responsável pela administração do sistema poderá cadastrar um novo usuário médico.
	Entrada: Nome do profissional; especialidade; CRM e senha.
	Processo: Os dados são incluídos no banco de dados.
Saída: Mensagem de confirmação de cadastro efetuado com sucesso ou erro em caso de falta de informações.
RF002: Cadastro de usuário paciente
Descrição: O paciente acessa o sistema via App ou WEB em seu dispositivo e seleciona opção “Cadastrar-se”. Qualquer pessoa pode efetuar o cadastro como paciente. O sistema impede casos de cadastro em duplicidade.
Entrada: Nome completo; data de nascimento; cpf; rg; e-mail; cep; endereço; cidade; estado e senha.
	Processo: Os dados são incluídos no banco de dados.
Saída: Mensagem de confirmação de cadastro efetuado com sucesso ou erro em caso de falta de informações.
RF003: Alterar cadastro de usuário médico
Descrição: Somente o funcionário designado pela clínica como responsável pela administração do sistema poderá alterar o cadastro do usuário médico.
Entrada: Alteração das informações.
	Processo: Os dados são atualizados no banco de dados.
Saída: Mensagem de confirmação de cadastro efetuado com sucesso ou erro em caso de falta de informações.
RF004: Alterar cadastro de usuário paciente
Descrição: O usuário paciente pode alterar seus dados quando se fizer necessário.
Entrada: Alteração das informações.
	Processo: Os dados são atualizados no banco de dados.
Saída: Mensagem de confirmação de cadastro efetuado com sucesso ou erro em caso de falta de informações.
RF005: Alterar status de usuário médico
Descrição: Somente o funcionário designado pela clínica como responsável pela administração do sistema poderá alterar o status de cadastro do usuário médico entre “Ativo” e “Inativo” em caso de desligamento do quadro de funcionários, porém se mantem as informações nome; especialidade;CRM e o histórico de pacientes atendidos, sem possibilidade de alterar os campos ou excluir as informações.
Entrada: Alteração de status.
Processo: Somente o status é alterado e atualizado no banco de dados.
Saída: Mensagem de confirmação de alteração de status de cadastro efetuado com sucesso ou erro em caso de procedimento incorreto.
RF006: Alterar status de usuário paciente
Descrição: Somente o funcionário designado pela clínica como responsável pela administração do sistema e com a devida solicitação de um parente do paciente em questão poderá alterar o status de cadastro do usuário paciente. A função é destinada em caso de óbito do paciente alterando seu cadastro para “inativo”, porém permitindo a consulta de histórico para fins específicos.
Entrada: Alteração de status.
	Processo: Somente o status é alterado e atualizado no banco de dados.
Saída: Mensagem de confirmação de alteração de status de cadastro efetuado com sucesso ou erro em caso de procedimento incorreto.
RF007: Login de usuário
Descrição: O usuário acessa o sistema para efetuar agendamento de consultas (paciente) ou atender pacientes (médico).
Entrada: Código de usuário e senha
	Processo: Os dados são conferidos no banco dedos
Saída: Acesso ao painel de serviços do sistema ou erro em caso de inserção de informações erradas.
RF008: Agendamento de consulta
Descrição: Paciente logado em sistema para efetuar agendamento de consulta.
Entrada: Selecionar opção “agendar consulta”; especialidade; médico; data; horário.
	Processo: O sistema insere as informações no banco de dados.
Saída: Mensagem de confirmação de consulta agendada com sucesso e geração de protocolo com informações de agendamento ou mensagem de erro em caso de data ou horário indisponíveis.
RF009: Cancelar consulta agendada
Descrição: Paciente deseja cancelar consulta agendada anteriormente.
Entrada: Selecionar opção “meus agendamentos”; selecionar consulta desejada pesquisando por data ou utilizando protocolo; clicar em opção “cancelar agendamento”.
Processo: O sistema busca informações no banco de dados e registra alteração de dados.
Saída: Mensagem de confirmação “deseja cancelar consulta?”, caso paciente selecione opção sim, mensagem “consulta cancelada com sucesso” é apresentada ou sistema retorna tela de agendamento se paciente selecionar opção não.
RF010: Notificação para profissional médico
Descrição: O médico logado em sistema é notificado quando há alteração em sua agenda de atendimentos.
Entrada: Agendamento ou cancelamento efetuado pelo paciente
Processo: O sistema insere ou atualiza as informações no banco de dados
Saída: Mensagem sinalizada e destacada no painel de trabalho do médico e aviso sonoro.
RF011: Realizar vide consulta.
Descrição: O médico logado e paciente logados estabelecem conexão para realizar consulta.
Entrada: Médico clica em ícone de câmera; solicitação para utilizar câmera e microfone do dispositivo aprovados por ambos.
Processo: O sistema estabelece a conexão entre os dispositivos.
Saída: Comunicação através de vídeo chamada é estabelecida e realizada entre médico e paciente.
RF012: Criar novo prontuário
Descrição: O médico durante consulta realiza anamnese do paciente e registra informações.
Entrada: Médico está com ficha do paciente aberta no sistema, clica na opção “Novo prontuário”
Processo: O sistema processa informação e retorna interação.
Saída: É aberta uma nova janela com espaço em branco para o médico realizar o registro escrito das informações de diagnóstico.
RF013: Emitir receita médica
Descrição: O médico durante consulta realiza prognostico do paciente e precisa receitar a forma de tratamento.
Entrada: Médico está com ficha do paciente aberta no sistema, clica na opção “Nova receita”
Processo: O sistema processa informação e retorna interação Saída: É aberta uma nova janela com espaço em branco para o médico receitar a forma de tratamento para o paciente.
REQUISITOS NÃO FUNCIONAIS
RNF1
O sistema deve ser confiável, nesse sentido, deve atender as suas especificações com sucesso. 
RNF2
A probabilidade de o sistema estar operacional num instante de tempo determinado deve ser alta. 
RNF3 
O software deve ser portável, ou seja, deve ser utilizado em qualquer plataforma de hardware e de sistema operacional. 
RNF4
O sistema deve tratar acessos não autorizados, sendo assim, deve garantir alto grau de segurança e, ainda, controlar o acesso às funcionalidades através de grupos de administradores e de usuários comuns. 
RNF5
 A interface do software deve ser amigável, ou seja, o usuário deve se sentir confortável ao utilizar o sistema, de forma que sua experiência se torne fácil. 
RNF6
 A persistência das informações deve ser implementada em um Sistema Gerenciador de Bancos de Dados Relacional (SGBDR) livre (PostgreSQL).
REGRAS DE NEGÓCIOS
O ACESSO AO SISTEMA DEVE SER REALIZADO ATRAVÉS DE UM CODIGO DE USUARIO E SENHA, NO QUAL PARA O PROFISSIONAL DE SAÚDE SERÁ USADO O CRM DO MESMO PARA O CAMPO DE CODIGO DO USUARIO E A SENHA SERÁ DEFINIDA POR ELE PODENDO SER ALTERADA E/OU RECUPERADA QUANDO HOUVER NECESSECIDADE. JÁ PARA O PACIENTE O CODIGO DO USUÁRIO SERÁ O CPF DO MESMO E A SENHA SERÁ DEFINIDA PELO PACIENTE COM POSSIBILIDADE DE ALTERAÇÃO E/OU RECUPERAÇÃO QUANDO HOUVER NECESSIDADE.
O SISTEMA DEVE POSSUIR EM SEU BANCO DE DADOS AS SEGUINTES INFORMAÇÕES: DADOS DA CLINICA, DADOS DOS PROFISSIONAIS DE SAÚDE; DATA E HORÁRIO DISPONIVEIS PARA AGENDAMENTO E DADOS DO PACIENTE.
O SISTEMA DEVE PERMITIR AO O USUARIO PACIENTE, DEVIDAMENTE VALIDADO, EFETUAR O AGENDAMENTO COM O PROFISSIONAL QUE DESEJA, RESPEITANDO A DISPONIBILIDADE DE DATA E HORÁRIO QUE SERÁ INFORMADO PELO SISTEMA SEGUINDO AS SEGUINTES ETAPAS: SELECIONAR A ESPECILIDADE DO MÉDICO, O SISTEMA INFORMA A DISPONIBILIDADE DE DATAS, QUAL PROFISSIONAL ESTÁ DIPONIVEL NA DATA SELECIONADA, LOGO EM SEGUIDA AS OPÇÕES DE HORÁRIO.
NO FINAL DO AGENDAMENTO O SISTEMA DEVE GERAR UM PROTOCOLO DE ATENDIMENTO CONTENDO INFORMAÇÕES COMO NOME DO MÉDICO; ESPECIALIDADE; NOME DO PACIENTE; DATA E HORÁRIO DA CONSULTA AGENDADA.
O SISTEMA DEVE ENVIAR UM E-MAIL DE CONFIRMAÇÃO PARA O PACIENTE CONTENDO O PROTOCOLO DE AGENDAMENTO COM INFORMAÇÃO DA CONSULTA.
O SISTEMA DEVE PERMITIR QUE O USUARIO PACIENTE TENHA ACESSO AO STATUS DA CONSULTA APRESENTANDO AO MESMO A OPÇÃO DE CANCELAMENTO.
O SISTEMA DEVE PERMITIR AO USUARIO PACIENTE CANCELAR A CONSULTA AGENDADA COM O PRAZO DE NO MINIMO 24H E NO MAXIMO 1H ANTES DO HORÁRIO MARCADO.
O SISTEMA DEVE NOTIFICAR O USUARIO MEDICO QUANDO HOUVER UM NOVO AGENDAMENTO E/OU ALTERAÇÃO DO STATUS DA CONSULTA AGENDADA APRESENTANDO O NOME DO PACIENTE, DATA E HORA DA CONSULTA E STATUS ATUAL DO AGENDAMENTO
O SISTEMA DEVE PERMITIR AO USUARIO MÉDICO REALIZARA A ABERTURA DE UM NOVO PRONTUARIO NA FICHA DO PACIENTE PARA INSERIR AS INFORMAÇÕES DO ATENDIMENTO QUE SERÁ REALIZADO.
O SISTEMA DEVE PERMITIR AO USUARIO MÉDICO EMITIR E ENVIAR AO PACIENTE UMA PRESCRIÇÃO DE REMÉDIOS OU TRATAMENTO DE FORMA DIGITAL
O SISTEMA DEVE PERMITIR QUE O USUARIO MEDICO TENHAM ACESSO AO HISTORICO DE CONSULTAS E PRESCRIÇÕES JÁ REALIZADAS
O SISTEMA DEVE PERMITIR AO USUARIO PACIENTE O ACESSO AO HISTORICO DE PRESCRIÇÕES
O SISTEMA DEVE IMPEDIR QUALQUER ALTERAÇÃO OU EXCLUSÃO NO HISTORICO DE PRONTUARIO E PRESCRIÇÕES.
O SISTEMA DEVE SOLICITAR AO USUÁRIO PERMISSÃO PARA UTILIZAR A CAMERA E MICROFONE DO DISPOSITIVO EM QUE O SOFTWARE SE ENCONTRARÁ INSTALADO
DIAGRAMAS
Segundo Booch, Rumbaugh e Jacobson (2005) os diagramas são meios utilizados para a visualização de blocos de construção básicos, como classes, interfaces, colaborações, 30 componentes, nós, dependências, generalizações e associações. O diagrama tem como finalidade ajudar na compreensão do sistema a ser desenvolvido e cada um oferece uma visão diferente acerca dos elementos que constituem esse sistema. Por tais motivos, é muito importante a escolha do conjunto de diagramas que serão utilizados na modelagem de um Software. 
Ainda segundo os autores Booch, Rumbaugh e Jacobson (2005) alguns diagramas contribuem para a visualização de partes estáticas,sendo conhecidos como diagramas estruturais: Diagrama de classes; Diagrama de objetos; Diagrama de componentes; Diagrama de estruturas compostas; Diagrama de implantação. E outros diagramas contribuem para visualizar as partes dinâmicas de um sistema, sendo conhecidos como diagramas comportamentais: Diagrama de caso de uso; Diagrama de sequências; Diagrama de comunicação; Diagrama de gráfico de estados; Diagrama de atividades. 
Para a modelagem deste sistema foram selecionados os seguintes diagramas: diagrama de casos de usos; diagrama de classes; diagrama de sequência; diagrama de componentes e implantação. A seguir tais diagramas serão mais bem descritos, a fim de se obter um melhor entendimento de seus funcionamentos demonstrando o porquê, de sua escolha.
Diagrama de Caso de Uso
Primeiramente é importante saber a definição de casos de uso, que segundo Melo (2010, p. 57) “um caso de uso descreve uma sequência de ações que representam um cenário principal (perfeito) e cenários alternativos, com o objetivo de demonstrar o comportamento de um sistema (ou parte dele), através de interações com autores.” E ainda segundo Booch, Rumbaugh e Jacobson (2005, p. 231) “um caso de uso é uma descrição de um conjunto de sequências de ações, inclusive variantes, que um sistema executa para produzir um resultado de valor observável por um ator.” Para os autores Lima (2011) e Booch, Rumbaugh e Jacobson (2005) o diagrama de casos de uso tem um papel central na modelagem do comportamento de um sistema, representando toda a funcionalidade de um sistema, evidenciando interações externas com outras entidades. Os autores Booch, Rumbaugh e Jacobson (2005) definem “um diagrama de caso de uso como um diagrama que mostra um conjunto de casos de uso e atores e seus relacionamentos.” Logo abaixo, está representado o diagrama de caso de uso do sistema proposto neste projeto.Figura 1 - Diagrama de caso de uso
Fonte: O Autor (2020).
Diagrama de Atividades
Para Lima (2011, p. 260) “o diagrama de atividades permite modelar o comportamento do sistema, denotando os caminhos lógicos que um processo pode seguir. Ele é um dos diagramas que compõem a visão dinâmica da UML.” O diagrama de atividades é um modelo gráfico que analisa a estrutura e as etapas sequenciais em um processo computacional, dando ênfase ao fluxo de controle de uma etapa para outra. Autores definem um diagrama de atividade da seguinte maneira: 
“um diagrama de atividades mostra o fluxo de uma atividade para outra. Uma atividade é uma execução em andamento não-atômica em uma máquina de estados. As atividades efetivamente resultam em alguma ação, formada pelas computações executáveis atômicas que resultam em uma mudança de estado do sistema ou o retorno de um valor. As ações abrangem a chamada a outras operações, enviando um sinal, criando ou destruindo um objeto ou alguma computação pura, como o cálculo de uma expressão.” Booch, Rumbaugh e Jacobson (2005, p. 270) 
Logo abaixo, está representado o diagrama de atividades do sistema proposto neste projeto.Figura 2 - Diagram de atividades
Fonte: O Autor (2020).
Diagrama de Classes
O diagrama de classes é fundamental na modelagem de um Software, como demonstra Melo (2010), afirmando que ele é a estrela principal de um sistema orientado a objetos. Tal diagrama tem como principal finalidade detalhar as classes pertencentes ao modelo e identificar seus relacionamentos. Segundo Booch, Rumbaugh e Jacobson (2005, p. 51) “classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.” Cada classe possui seus atributos e operações. 
Os atributos representam alguma propriedade da classe na qual ele está inserido, uma classe não necessariamente precisa ter atributos. Já uma operação é uma atividade que pode ser realizada por um objeto da classe na qual esta operação está inserida. Como afirmam os autores Booch, Rumbaugh e Jacobson (2005) e Melo (2010), a maioria das classes não trabalham sozinhas, elas precisam se relacionar, colaborando uma com a outra. Os primeiros autores defendem a ideia de que existem três tipos de relacionamentos na modelagem orientada a objetos: dependências, generalizações e associações. 
Um exemplo de uma classe pode ser visto na Figura 3 – Exemplo de Classe, a seguir:
Figura 3 - Exemplo de Classe
Fonte: Melo (2010, p.105)
Logo abaixo, está representado o diagrama de classes do sistema proposto neste projeto.
Figura 4 – Diagrama de classes
Fonte: O Autor (2020).
Diagrama de Sequência
Segundo Booch, Rumbaugh e Jacobson (2005, p. 254) o diagrama de sequência é “...um diagrama de interação que dá ênfase a ordenação temporal de mensagens, mostra um conjunto de papeis e as mensagens enviadas e recebidas pelas instancias que representam os papeis.” A importância de se compreender a ordem e tempo das mensagens que transitam pelo sistema proporciona ao leitor uma melhor compreensão do funcionamento do software.
Logo abaixo, está representado o diagrama de sequência do sistema proposto neste projeto que será divido em três imagens sendo: diagrama de sequência do usuário moderador; diagrama de sequência do usuário médico e diagrama de sequência do usuário paciente.
Figura 5 - Diagrama de sequência usuário moderador
Fonte: O Autor (2020).
Figura 6 - Diagrama de sequência usuário médico
Fonte: O Autor (2020).
Figura 7 - Diagrama de sequência usuário paciente
Fonte: O Autor (2020).
Diagrama de componentes e implementação
O diagrama de Implantação segundo Booch, Rumbaugh e Jacobson (2005) e Melo (2010) mostra a estrutura de nós nos quais os componentes e artefatos são implantados. Ele é empregado para a modelagem da visão estática da implantação de um sistema. E permite definir a arquitetura de execução dos sistemas que representam a designação de artefatos de Software.
Para Lima (2011, p. 322) “o diagrama de implantação especifica o conjunto de elementos usado para definir a arquitetura do sistema e que representa a distribuição dos artefatos da aplicação pelos nós da tipologia de hardware em que o sistema será executado.” Já para Booch, Rumbaugh e Jacobson (2005, p. 413) “o diagrama de implantação é um diagrama que mostra a configuração de nós de processamento em tempo de execução e os artefatos que neles existem.”
Logo abaixo, está representado o diagrama de componentes e implementação do sistema proposto neste projeto.
Figura 8 - Diagrama de componentes e implementação
Fonte: O Autor (2020).
METODOLOGIA DE QUALIDADE
Baseado no conhecimento adquirido através de projetos realizados posteriormente, a metodologia de qualidade que melhor se aplica ao caso é a MPS.BR.
Para as organizações aderirem aos modelos internacionais citados, há exigência de um alto investimento, que só grandes empresas dispõem de recursos para arcar com os custos, o que não é possível para pequenas e médias empresas.
Isso está ligado tanto aos investimentos obrigatórios para implantação, como contratos de consultoria e auditoria, mas também às necessidades de profissionais especializados e dedicação da organização para alcançar os padrões de processos exigidos (KOSCIANSKI, 2007; FERNANDES, 2012).
O modelo MPS.BR é um modelo elaborado com base nas normas ISO/IEC 12207; ISO/IEC 15504;ISO/IEC 25000 e no modelo CMMI, é utilizado em território nacional e atende a necessidade de implantar os princípios da engenharia de software de forma adequada ao contexto das empresas brasileiras, seguindo as principais abordagens internacionais para definição, avaliação e melhoria de processo de software (SOFTEX, 2012).
Possui uma limitação de reconhecimento quanto ao seu selo e qualidade e certificação fornecida que se aplica somente em território nacional, mesmo possuindo um alinhamento aos padrões internacionais mencionados no paragrafo acima.
Assim como os outros modelos estudados, o MPS.BR também possui níveis de evolução de maturidade da organização que são divididos em sete níveis iniciando no nível G (nível mais baixo) ascendendo até o nível A (nívelmais alto), os quais necessitam ser implementados e avaliados de maneira sequencial, pois são dependentes entre si. Por constituir-se de maior número de níveis, o modelo permite que as organizações consigam evoluir de forma lenta, porém consistente e com custos reduzidos.
Quanto aos níveis de maturidade utilizados pelo modelo, o nível mais baixo é o G nomeado como parcialmente no qual consiste parcialmente em gerenciamento com o foco voltado para a gestão de requisitos e de projetos. O nível F nomeado como gerenciado, é voltado para demais praticas de configuração, qualidade e medição são inclusas. No nível E, como parcialmente definido, começa a expansão de maturidade para a organização, e não somente para o projeto. No nível D, o processo é considerado largamente definido. No nível C, é considerado definido. Nível B, encontra - se estabelecido um processo de medição para evolução de qualidade. O nível A refere – se ao processo continuo de melhora do processo. Se relacionarmos o modelo MPS.BR com o modelo CMMI, o nível A equivale ao nível 5, o nível B ao nível 4, os níveis C, D e E condizem com o nível 3 e os níveis F e G se equiparam ao nível 2 do modelo CMMI.
A escolha do Modelo MPS.BR foi realizada focando o cenário de que a empresa a desenvolver o software não dispõe de capital necessário para se investir em modelos como ISO e CMMI, que possuem um custo para implementação mais elevado, tanto para valor de investimento como para tempo de implementação. Observando também que o cenário proposto pelo trabalho não necessita de um modelo que possua certificação internacional.
ABERTURA DO PROJETO
Título do projeto
· Sistema de teleconsulta Medtec
Gerente de projeto responsável
· Matheus Tomio Carneiro Matsushita
Justificativa do projeto
O projeto tem como objetivo auxiliar o processo de gerência de marcação de consultas e atendimento de pacientes do hospital. Devido o atual cenário de pandemia mundial causado pelo COVID-19, uma simples consulta presencial pode trazer transtornos a todos aqueles que se dirijam ao estabelecimento em busca de atendimento médico. 
Objetivos e metas do projeto
As metas e objetivos do projeto são auxiliar ao hospital a manter o atendimento de seus pacientes de forma que se mantenha ordem no gerenciamento do agendamento de consultas de forma que, para os casos menos graves e que não necessitam de consulta presencial, o médico possa atender o paciente e avaliar a situação do mesmo através de uma vídeo conferência. Tal procedimento auxiliará as pessoas a manterem as medidas de isolamento.
Descrição do projeto
O projeto consiste em um sistema que será utilizado para controle de consultas médicas permitindo que o médico atenda o paciente sem a necessidade de uma consulta presencial, nos casos de menor gravidade, e que permitem que tal procedimento seja realizado de acordo com a indicação do médico.
O sistema é instalado nas máquinas do hospital dos setores de recepção, escritórios médicos e R.H. Já no caso dos pacientes o sistema é disponibilizado em formato de aplicativo para dispositivos móveis ou desktop.
Com a implantação do projeto os pacientes, em grande maioria, não precisarão se deslocar de sua residência e interromper as medidas de isolamento evitando assim o contato direto com outras pessoas, em transporte público por exemplo, e evitando também aglomeração no hospital.
Premissas do projeto
Temos como premissa que o usuário paciente terá acesso aos diagnósticos e suas fichas de prontuário.
Restrições do projeto
As restrições do projeto se resumem a dois fatores, o curto prazo para desenvolvimento e ao fato de nossa equipe se reunir 2 vezes durante a semana devido medidas preventivas para evitar contaminação e disseminação do vírus. 
Principais stakeholders
Estão envolvidos no projeto o cliente, sendo representado pelo gerente pelo setor de T.I do hospital, dois responsáveis pelo conselho de acionistas do cliente, o gerente de projetos, e dois representantes da equipe de desenvolvedores.
Riscos do projeto
O risco que projetamos está relacionado a vazamento de informações e possíveis invasores que podem comprometer o desenvolvimento do sistema.
Marcos do projeto
· Assinatura do termo de abertura
· Liberação de valor de investimento
· Validar etapas concluídas com cliente
Custo e prazo estimados do projeto
O custo estimado do projeto: R$ 25.000,00
Prazo estimado: 2 meses
                                                                       
CONCLUSÃO
O desenvolvimento do presente estudo possibilitou uma análise da importância do uso da tecnologia para processos de gestão, como o caso estudado envolvendo o Colégio Vencer Sempre. 
O processo de reserva que, até então, é realizado de maneira manual, traz consigo inúmeras falhas que por si acarretou no problema do não aproveitamento de uma estrutura que a instituição dispunha a favor de seus funcionários. 
Com base nos estudos feitos para o desenvolvimento do projeto, a implementação do software trará a solução para o problema enfrentado pela instituição e consequentemente acarretará em uma melhoria significativa nas atividades que serão desenvolvidas e aplicadas pelos professores e coordenadores. 
Com a aplicação de um sistema de teleconsulta integrado a um sistema de agendamento de consultas, podemos observar que a ferramenta possibilita manter o atendimento na área da saúde sem expor aos riscos de contaminação massiva, como poderia acontecer no cenário atual, preservando a equipe de profissionais, que passarão a ter contato com um número menor de pessoas, os pacientes que não enfrentarão aglomerações em transporte público ou no próprio hospital. 
 Portanto a implementação do projeto pode ser considerada viável e benéfica para a instituição, para que ela possa manter suas atividades e contribuir com as recomendações a serem seguidas durante o período de pandemia.
REFERÊNCIAS BIBLIOGRÁFICAS
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software. 1ªedição. Editora Novatec. 2007.
SOFTEX. Guia Geral do MPS.Br, 2020. Disponível em: <https://softex.br/download/mps-br-guia-geral-software-2020/>. Acesso em 25 Set 2020
PRESSMAN, R. S. Engenharia de software. 6. ed. Rio de Janeiro: McGraw‑Hill, 2006.
BOOCH, GRADY; James RUMBAUGH; e Ivar, JACOBSON. UML: guia do usuário. 6° Reimpressão. Rio de Janeiro. Editora Elsevier, 2005.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2 do conceito à implementação. 3° edição. Rio de Janeiro. Editora Brasport, 2010.
LIMA, Adilson da Silva. UML 2.3 do requisito à solução. 1° edição. São Paulo: Editora Érica, 2011.
GUEDES, Gilleanes T. A. UML 2, uma abordagem prática. 2° edição. São Paulo: Editora Novatec, 2011.