PIMVII - ANÁLISE E DESENVOLVIMENTO DE SISTEMAS (NOTA 9.5) 2021

Prévia do material em texto

6
UNIVERSIDADE PAULISTA
ANÁLISE E DESENVOLVIMENTO DE SISTEMA
SEU NOME
PROJETO INTEGRADO MULTIDISCIPLINAR VII
Projeto de telemedicina 
SÃO PAULO – SP
2021
UNIVERSIDADE PAULISTA
ANÁLISE E DESENVOLVIMENTO DE SISTEMA
PROJETO INTEGRADO MULTIDISCIPLINAR VII
Projeto de telemedicina 
Nome: SEU NOME
RA: XXXXX
Curso: Análise e Desenvolvimento de Sistema
Semestre: 04/2021
SÃO PAULO – SP
2021
RESUMO
O presente Projeto Integrado Multidisciplinar, proposto pela universidade UNIP Interativa, visa aplicar o conhecimento adquirido no bimestre pelas aulas de Empreendedorismo, Gerenciamento de Projeto de Software, Gestão de Qualidade e Projeto de Sistemas Orientado a Objetos. Este trabalho tem como objetivo realizar o projeto de um sistema de teleatendimento médico que tem como propósito a diminuição dos atendimentos presenciais assim agilizando os atendimentos médicos em épocas de pandemias nos hospitais. Para este projeto identificaremos os Requisitos de Software e Regras de Negócios, descrevendo os comportamentos pertinentes a eles atrelados. Representaremos os Casos de Uso e Diagramas bem como a aplicação no projeto proposto. Aplicaremos a metodologia frente as Normas Internacionais. Identificação e elaboração do Termo de Abertura do Projeto, a Definição de Matriz de Papéis de Responsabilidades, o Cronograma de Atividades e Custos, Análise de Riscos e para finalização do trabalho as considerações finais das Lições Aprendidas.
Palavras-chave: Requisitos de Software, Teleatendimento, Normas Internacionais.
ABSTRACT
The present Integrated Multidisciplinary Project, proposed by the UNIP Interactive University, aims to apply the knowledge acquired in the bimester by the classes of Entrepreneurship, Software Project Management, Quality Management and Object-Oriented Systems Design. The objective of this work is to design a medical telephone answering system that has the purpose of reducing the number of in-person visits, thus speeding up medical services in times of pandemics in hospitals. For this project we will identify the Software Requirements and Business Rules, describing the behaviors related to them. We will represent the Use Cases and Diagrams as well as the application in the proposed project. We will apply the methodology according to the International Standards. Identification and elaboration of the Project Opening Term, the Definition of the Responsibility Roles Matrix, the Activities and Costs Schedule, the Risk Analysis and to finish the work the final considerations of the Lessons Learned.
Keywords: Software Requirements, Telecare, International Standards.
LISTA DE ILUSTRAÇÕES
Figura 1 - Diagrama de Casos de Uso - Controle de Usuários	22
Figura 2 - Diagrama de Casos de Uso - Atendimento	23
Figura 3 - Diagrama de Classes	24
Figura 4 - Diagrama de Atividades - Cadastro de Usuário	25
Figura 5 - Diagrama de Atividades - Cadastro de Paciente	26
Figura 6 - Diagrama de Atividades - Login no Sistema	27
Figura 7 - Diagrama de Atividades - Atendimento	28
Figura 8 - Diagrama de Sequência - Cadastro de Usuário	29
Figura 9 - Diagrama de Sequência - Alterar Usuário	29
Figura 10 - Diagrama de Sequência - Excluir Usuário	30
Figura 11 - Diagrama de Sequência - Consultar Usuário	30
Figura 12 - Diagrama de Sequência - Cadastro de Paciente	31
Figura 13 - Diagrama de Sequência - Alterar Paciente	31
Figura 14 - Diagrama de Sequência - Excluir Paciente	31
Figura 15 - Diagrama de Sequência - Consultar Paciente	32
Figura 16 - Diagrama de Sequência - Efetuar Login	32
Figura 17 - Diagrama de Sequência - Atendimento Paciente	33
Figura 18 - Diagrama de Componentes - Controle de Usuário	33
Figura 19 - Diagrama de Componentes - Atendimento	34
Figura 20 - Diagrama de Implantação - Sistema Portal Empresas Telemedicina	35
Figura 21 - Modelo de Qualidade - Externa e Interna	36
Figura 22 - Diagrama de Atividades – Gráfico de Gantt	40
LISTA DE TABELAS
Tabela 1 - Requisitos Funcionais	11
Tabela 2 - Requisitos Não Funcionais	11
Tabela 3 - Regras de Negócios	13
Tabela 4 - Descrição de Casos de Uso - Controlar Usuário	14
Tabela 5 - Descrição de Casos de Uso - Manter Paciente	15
Tabela 6 - Descrição de Casos de Uso - Realizar Login	17
Tabela 7 - Descrição de Casos de Uso - Encaminhar para fila de atendimento	18
Tabela 8 - Descrição de Casos de Uso - Atender Paciente	18
Tabela 9 - Descrição de Casos de Uso - Emitir receita médica	19
Tabela 10 - Descrição de Casos de Uso - Emitir Atestado	20
Tabela 11 - Descrição de Casos de Uso - Solicitar Exame Covid-19	21
Tabela 12 - Matriz de Responsabilidades – RACI	39
Tabela 13 - Gerenciamento de Custos	41
SUMÁRIO
1.	INTRODUÇÃO	6
2.	DEFINIÇÃO DA EMPRESA STARTUP	7
2.1 Recursos Humanos	7
2.2 Estratégia Técnica	8
2.3 Recurso Financeiro	8
2.4 O Plano de Recurso do Negócio	8
3.	APRESENTAÇÃO DO PROJETO	9
4.	ANÁLISE DE REQUISITOS	10
4.1 Requisitos Funcionais	10
4.2 Requisitos Não Funcionais	11
4.3 Regras de Negócios	13
5.	CASOS DE USO	14
5.1 Descrição Casos de Uso – Controlar Usuário	14
5.2 Descrição Casos de Uso – Manter Paciente	15
5.3 Descrição Casos de Uso – Realizar Login	17
5.4 Descrição Casos de Uso – Encaminhar Para Fila Atendimento	18
5.5 Descrição Casos de Uso – Atender Paciente	18
5.6 Descrição Casos de Uso – Emitir Receita Médica	19
5.7 Descrição Casos de Uso – Emitir Atestado	20
5.8 Descrição Casos de Uso – Solicitar Exame Covid-19	21
5.9 Diagrama de Casos de Uso	22
6.	DIAGRAMA DE CLASSES	23
7.	DIAGRAMA DE ATIVIDADES	24
7.1 Diagrama de Atividades – Cadastro de Usuário	25
7.2 Diagrama de Atividades – Cadastro de Usuário	26
7.3 Diagrama de Atividades – Login no Sistema	27
7.4 Diagrama de Atividades – Atendimento	28
8.	DIAGRAMA DE SEQUÊNCIA	28
8.1 Diagrama de Sequência – Cadastro de Usuário	29
8.2 Diagrama de Sequência – Alterar Usuário	29
8.3 Diagrama de Sequência – Excluir Usuário	30
8.4 Diagrama de Sequência – Consultar Usuário	30
8.5 Diagrama de Sequência – Cadastro de Paciente	31
8.6 Diagrama de Sequência – Alterar Paciente	31
8.7 Diagrama de Sequência – Excluir Paciente	31
8.8 Diagrama de Sequência – Consultar Paciente	32
8.9 Diagrama de Sequência – Efetuar Login	32
8.10 Diagrama de Sequência – Atendimento Paciente	33
9.	DIAGRAMA DE COMPONENTES	33
9.1 Diagrama de Componentes – Controle de Usuário	33
9.2 Diagrama de Componentes – Atendimento	34
10.	DIAGRAMA DE IMPLANTAÇÃO	34
11.	METODOLOGIA APLICADA AO SISTEMA - NBR ISO/IEC 9126-1	35
11.1 Modelo de Qualidade	36
11.2 Aplicação da Metodologia no Projeto	37
12.	TERMO DE ABERTURA DE PROJETO	38
13.	CRONOGRAMA DE ATIVIDADES	40
14.	GERENCIAMENTO DE CUSTOS	40
15.	ANÁLISE DE RISCOS	42
16.	LIÇÕES APRENDIDAS	42
17.	CONCLUSÃO	43
 REFERÊNCIAS ...................................................................................................45
1. INTRODUÇÃO
Com o cenário que estamos presenciando atualmente, nessa época de pandemias e grandes números de casos nos hospitais e para evitar maior contágio e superlotação dentro dos hospitais o proposto projeto integrado multidisciplinar traz como objetivo um projeto de telemedicina que é um processo de tecnologia avançado para monitoramento de pacientes, troca de informações médicas e análise de resultados de diferentes exames, que são avaliados e entregues de forma digital, sendo suporte e apoio para a medicina tradicional. A telemedicina como o termo já tem o significado abrange toda a prática médica realizada a distância que evita que os pacientes precisem ir presencialmente e sair do isolamento para procurar os serviços de saúde. 
Através desta maneira diminui o possível número de contaminação no transporte público e nós locais de atendimento de saúde. Outro benefício que mesmo que o paciente esteja contaminado ou com a suspeita de Covid-19, podem permanecer em quarentena e ser tratados em casa por receita médica e atestado médicos emitidos pelos profissionais médicos que atendem o serviço de telemedicina sendo digitais anexados na plataforma de telemedicina, sendo assim o paciente pode permanecerem quarentena e diminuir a circulação do vírus na sociedade. Outro ponto em questão positivo é a preservação dos profissionais de saúde, com a solução da telemedicina os médicos podem transmitir orientações e acompanhar os pacientes sem ter o contato físico com eles, assim permanecendo em segurança de um futuro contágio com o vírus. Com a solução proposta os atendimentos remotos ajudam a diminuir a pressão nos sistemas de saúde, recebendo monitoramento e orientação no seu domicílio, deixando as clínicas e os hospitais livres para casos de saúde que é necessário de um cuidado presencial.
Neste projeto será apresentado um projeto de sistema de teleatendimento médico, via app/web, que tem como objetivo a tecnologia de telemedicina que tem como proposito diminuir as visitas e agilizar os atendimentos médicos de forma dinâmica, em épocas de pandemias nos hospitais. Na seguinte proposta iremos desenvolver o plano de negócios para empresa startup que irá desenvolver o sistema bem como a forma de captação do investimento por ser uma empresa nova deste imenso mercado de desenvolvimento contamos com a inovação da ideia e um plano para atrair investidores e clientes, tendo como base uma boa equipe que tenha expertise com o negócio e focando na prototipagem para apresentação do projeto. O projeto irá conter a descrição dos requisitos funcionais, os requisitos não funcionais e as regras de negócios. Serão elaborados os seguintes diagramas: casos de uso, diagrama de atividades, diagramas de classes, diagrama de sequência, diagrama de componentes e de implantação. Identificaremos qual a metodologia de gestão de qualidade adotada no projeto, redigir o termo de abertura de projeto, a definição de matriz de papéis de responsabilidades, o cronograma de atividades e custos, a análise de riscos e por fim listar as lições aprendidas.
2. DEFINIÇÃO DA EMPRESA STARTUP
Para gerarmos o plano de negócios da empresa de tecnologia que desenvolverá o sistema de telemedicina para as empresas privadas do ramo da saúde, partindo do ponto inicial como podemos definir uma startup, uma das definições que podemos usar é um modelo de negócio escalável e repetível, que veremos a definição abaixo: 
· O modelo repetível é aquele capaz de ser negociado o mesmo produto para todos os clientes e mercados.
· O modelo escalável tem capacidade para expandir e atender grandes quantidades de cliente sem aumentar seus custos.
Para definirmos os recursos que serão agregados a empresa e que ajudarão na conclusão do projeto do sistema de telemedicina e futuros projetos, sendo tão importantes quanto o recurso monetário o time que formará a equipe, buscando pessoas apaixonados pelo negócio que desenvolveremos. Definindo a cultura organizacional da empresa através de transparência entre os funcionários. 
2.1 Recursos Humanos
Na fase inicial da empresa que precisamos de recursos humanos. Priorizaremos a diversidade com várias competências, sendo profissionais do setor de negócios, tecnologia (analista, desenvolvedor, design), vendas, administração e finanças e uma peça-chave sendo fundamental um mentor com expertise no segmento ele não participa do negócio, sendo um dos responsáveis por abrir as portas com networking, oferecendo sua experiência para orientar o empreendedor e desenvolver mais rápido o crescimento da startup.
2.2 Estratégia Técnica
A estratégia técnica da startup que iremos usar para validação com os clientes será a prototipação dos sistemas desenvolvidos para ele avaliar e dizer do que gosta e do que não gosta, após a validação, sendo fundamental os ajustes necessários ou pivotagem, que define a direção se continua a mesma ou precisamos mudar o foco do projeto e do modelo de negócio.
2.3 Recurso Financeiro
Sendo um dos fatores muito importante para o negócio deslanchar, para captação de investidores e patrocínios focaremos na prototipação funcionais dos sistemas, mais fielmente ao projeto final e não apresentações amadoras e cruas para ser mostrados a ideia aos investidores. Gastando até muito tempo no desenvolvimento do protótipo (site, aplicativo) porém o custo baixo para o desenvolvimento e assim apresentando aos investidores e clientes validarem. A startup poderá usar a estratégia de captar recursos públicos ou privados. 
Mesmo com a validação do cliente, deixaremos em aberto a opção de mudança se o cliente assim desejar implantar algo mais ou mesmo dar aquela temperada no sistema se achar que está faltando algo para atender a demanda do mesmo e assim adotando a flexibilidade do produto modelo e se precisar alteração do valor cobrado do produto dependendo da função que o cliente necessitar.
2.4 O Plano de Recurso do Negócio
Sabendo que os avaliadores do futuro investidor recebem centenas de propostas de ideias de negócios, a empresa focará na explicação de informações que considera essenciais sobre o empreendimento tais como:
•	Proposta de valor: qual diferencial da empresa que torna inovadora.
•	Produto ou Serviço: que está sendo oferecido ao mercado.
•	Modelo de negócio: ligado à como a empresa startup em potencial e o investidor ganharão dinheiro, ou seja, as fontes de receita da empresa e quanto custará ao consumidor do produto e serviço.
•	O time: quais os perfis da equipe e qual expertise e diferencial dos membros que a compõem, qual colaborador sabe administrar, qual sabe vender etc.
•	Saúde financeira: qual a projeção de faturamento para os próximos meses e anos, usando a transparência da real situação do caixa da empresa atual.
•	Recurso necessário: de quanto será o custo de cada fase do projeto e onde o dinheiro será injetado.
Tendo a ideia de que o investidor não tem vínculos afetivo com o negócio e projeto, buscaremos fornecer informações objetivas, para ganhar pontos positivos.
3. APRESENTAÇÃO DO PROJETO
Usando o plano de projeto de telemedicina que estará sendo desenvolvido neste trabalho pela empresa startup e usado para conquista de investidores, quando for apresentado o pitch da empresa que seria a apresentação rápida do projeto, colocaremos o número que representa o valuation (projeto, valor da ideia, negócio, startup) da empresa. A apresentação do projeto, ou seja, o pitch, teremos como objetivos abaixo:
•	Histórico da startup.
•	Atividade principal da empresa: produto e serviço fornecido e qual a forma que oferece soluções.
•	O mercado da empresa: números de consumidores em potenciais, principais concorrentes do mercado, seus pontos positivos e negativos.
•	O modelo de crescimento: se é necessário aumentar a produção ou se precisamos de mais mão de obra para o crescimento.
•	Os recursos financeiros: quais valores que poderiam ser um bom investimento e como seriam usados.
•	A equipe: o que cada membro pode ter a oferecer, ou seja, a expertise de cada membro do time.
•	O modelo de receita: como vai ser faturado e quais serão as fontes de receita (se vai alugar, vender o produto, oferecer download de aplicativo, etc).
O objetivo é falar tudo isso em poucos minutos para o investidor na primeira apresentação, com pensamento em ser notado e ter uma segunda chance para detalhar o projeto e a startup. Com foco em não desperdiçar nenhuma chance de chamar atenção para o negócio da startup e mostrar a proposta de forma concisa e clara. 
Usaremos o nome do sistema proposto como “Portal Empresa Telemedicina” que será a base do projeto é a plataforma que será cadastrado os usuários do sistema, verificará se o beneficiário (paciente) é elegível ou não elegível para passar no atendimento médico através da verificação do cadastro que o usuário da empresa cliente efetuou para ele, onde o médico atenderá o paciente através da fila de atendimento encaminhado pela recepção, assim dando o desfecho devido.
4. ANÁLISE DE REQUISITOS
Com base nas necessidades do cliente para construção do software de telemedicina proposto por este trabalho, estaremos nas próximas sessões identificando os requisitos e organizando neste documento e posteriormente efetuando as construções dos diagramas que forem pertinentes ao projeto.
Sommerville(2011), observa que os requisitos são descrições de procedimentos que um sistema deve efetuar, serviços e as restrições de seu funcionamento, o processo de esclarecer, analisar e documentar e efetuar a verificação desses serviços e restrições é conhecido como engenharia de requisitos.
De forma bem resumida o projeto do programa proposto de telemedicina, terá que ter os cadastros dos usuários que efetuarão o uso do sistema, paciente será encaminhado pela recepção para passar pelo atendimento médico na plataforma, emissões de documentos e relatórios pertinentes ao usuário requisitante. Na próxima sessão veremos de maneira mais organizada para entender com mais clareza a proposta do projeto.
4.1 Requisitos Funcionais 
“Requisitos funcionais. São declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações.” (SOMMERVILLE, 2011, p. 59).
Para descrever explicitamente as funcionalidades e serviços do sistema proposto, iremos usar as siglas [RF-XX] que será para demonstrar os requisitos funcionais do sistema de telemedicina através do levantamento das necessidades do cliente, conforme a Tabela 1 abaixo:
Tabela 1 - Requisitos Funcionais
	[RF - 01]
	Controlar Usuário
	[RF - 02]
	Manter Paciente
	[RF - 03]
	Realizar login
	[RF - 04]
	Encaminhar para fila atendimento
	[RF - 05]
	Atender Paciente
	[RF - 06]
	Emitir receita médica
	[RF - 07]
	Emitir Atestado
	[RF - 08]
	Solicitar Exame Covid-19
Fonte: O autor, 2021.
4.2 Requisitos Não Funcionais
“Requisitos não funcionais. São restrições aos serviços ou funções oferecidos pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas.” (SOMMERVILLE, 2011, p. 59).
Especificação de uma restrição ou de um comportamento esperado que se aplica ao sistema. Essa restrição pode se referir às propriedades vitais do software que está sendo desenvolvido ou ao processo de desenvolvimento. Conforme identificado na Tabela 2 abaixo usando as siglas [RNF-XX], veremos as declarações dos requisitos não funcionais do sistema.
Tabela 2 - Requisitos Não Funcionais
	Identificador
	Categoria
	Nome
	Descrição Técnica
	[RNF-01]
	Eficiência
	Comportamento
	O tempo de execução dos processos do sistema deve ser curto.
	[RNF-02]
	Eficiência
	Atualização do Banco de Dados
	O banco de dados deve ser atualizado em tempo real quando um cliente efetuar a solicitação de atendimento na plataforma.
	[RNF-03]
	Eficiência
	Volume de utilização
	O sistema deve ser capaz de suportar um número alto de pacientes em atendimento ativos ao mesmo tempo.
	[RNF-04]
	Funcionalidade
	Autenticação de usuário
	Todos os clientes devem ser cadastrados para uso da plataforma, em caso de primeiro acesso, o cliente deve ser redirecionado para efetuar o cadastramento de seus dados.
	[RNF-05]
	Confiabilidade
	Criptografia de senhas
	Todas as senhas de usuário devem ser criptografadas ao serem armazenadas ao banco de dados.
	[RNF-06]
	Portabilidade
	Implantação
	O sistema deve rodar em todo sistema operacional.
	[RNF-07]
	Confiabilidade
	Certificação de segurança
	Os dados do paciente não serão compartilhados para usuários não autorizados.
	[RNF-08]
	Usabilidade
	Operacionalidade
	Um novo usuário deve ser capaz de efetuar o uso da plataforma sem a necessidade de muitas orientações.
	[RNF-09]
	Confiabilidade
	Recuperabilidade
	Usuário quando em preenchimento de formulários dentro da plataforma será salvo automaticamente pelo sistema em caso de queda de conectividade.
	[RNF-10]
	Portabilidade
	Adaptabilidade
	O sistema deverá ser responsivo se ajustando instantaneamente seu layout e suas funcionalidades ao dispositivo a qual está sendo acessado.
	[RNF-11]
	Usabilidade
	Operacionalidade
	Beneficiário tem a opção de acessar a tele consulta através da Web ou pelo app.
	[RNF-12]
	Funcionalidade
	Interoperabilidade
	O sistema se comunicará com o sistema Google Meet para efetuar o atendimento do paciente por vídeo.
	[RNF-13]
	Confiabilidade
	Validação
	O sistema deve verificar a autenticidade o CPF do usuário no cadastramento.
Fonte: O autor, 2021.
4.3 Regras de Negócios
“Regras de negócios e fluxos de trabalho, em que cada organização define suas próprias regras para regerem o uso do serviço e seus dados.” (SOMMERVILLE, 2011, p. 351).
 Definindo a regras de negócios dentro de um sistema são políticas e normas que devem ser seguidas ao se usar o sistema. Usaremos as a siglas [RN-XX], para identificar essas regras e informando a descrição de cada umas delas, conforme Tabela 3 abaixo:
Tabela 3 - Regras de Negócios
	[RN - 01]
	Usuários com perfil administrativo e assistencial devem ser cadastrados no sistema pelo departamento de (suporte de tecnologia).
	[RN - 02]
	O sistema identificará e validará o paciente pelo CPF cadastrado pelo usuário da empresa e o paciente quando for efetuar o cadastro na plataforma será validado o CPF com o cadastro que a empresa efetuou.
	[RN - 03]
	Paciente deve ser elegível no cadastro para usar a plataforma de atendimento.
	[RN - 04]
	O sistema deve validar o paciente e irá vincular o cadastro que o usuário da empresa fez pelo CPF, assim se tornando elegível. Caso o paciente não tiver cadastro pela empresa se tornará não elegível não sendo possível atendimento de telemedicina.
	[RN - 05]
	O usuário cadastrado pelo suporte de tecnologia recebe um e-mail com o usuário e senha temporária (a senha terá que ser mudada pelo usuário no primeiro acesso a plataforma e o usuário login não pode ser alterado, receberá um link para acessar a URL que é direcionado a plataforma (portal empresa).
	[RN - 06]
	Documentos emitidos dentro da plataforma portal empresa (receita, atestado, solicitação de exame), devem ser enviados por e-mail ao paciente.
Fonte: O autor, 2021.
5. CASOS DE USO
Nesta sessão iremos descrever o fluxo de interação através do caso de uso.
 Em sua forma mais simples, um caso de uso identifica os atores envolvidos em uma interação e dá nome ao tipo de interação. Essa é, então, suplementada por informações adicionais que descrevem a interação com o sistema. A informação adicional pode ser uma descrição textual ou um ou mais modelos gráficos, como diagrama de sequência ou de estados da UML. (SOMMERVILLE, 2011, p. 74). 
Conforme veremos abaixo nas tabelas abaixo:
5.1 Descrição Casos de Uso – Controlar Usuário
 Tabela 4 - Descrição de Casos de Uso - Controlar Usuário
	Identificação:
	Controlar Usuário
	Descrição:
	Esse caso de uso permite ao suporte de tecnologia efetuar o controle do usuário em sistema
	Ator Relacionado:
	Suporte de tecnologia
	Interessados:
	Suporte de tecnologia e Usuário
	Pré-condições:
	O usuário deve possuir e-mail e CPF válidos.
	Pós-condições:
	O usuário é cadastrado no sistema e poderá ter acesso a plataforma.
	Fluxo normal:
	1.    O suporte acessa a URL do sistema.
	2.    O sistema exibe a tela de login do sistema, contendo o campo de login e senha.
	3.    O suporte informa os dados de acesso.
	4.    O sistema redireciona o suporte para a "tela menu do sistema".
	5. O suporte cadastra o usuário para uso da plataforma portal empresas.
	6. O suporte salva o cadastramento do usuário.
	7. O usuário recebe o login e senha por e-mail.
	Fluxo Alternativo:
	3.1 Caso o suporte digite login ou senha inválido o sistema irá exibir uma mensagem de erro de login.
	5.1 O sistema deve validar o CPF no cadastramento.
	5.2 Caso o usuário já tenha cadastro o suporte pode efetuar alteração, exclusão e alteração do cadastro.
	Regras de Negócio Relacionado:
	[RN-01], [RN-05]
 Fonte: O autor, 2021.
5.2 Descrição Casos de Uso – Manter Paciente
 Tabela 5 - Descrição de Casos de Uso - Manter Paciente
	Identificação:
	Manter Paciente
	Descrição:
	Esse caso de uso permite ao usuário da empresa efetuar o controle do paciente
	Ator Relacionado:
	Usuário e Paciente
	Interessados:
	Usuário, Recepção e Paciente
	Pré-condições:
	O usuário devepossuir e-mail e CPF válidos.
	Pós-condições:
	O paciente é cadastrado no sistema se tornando elegível para uso da plataforma.
	Fluxo normal:
	1.    O usuário da empresa acessa a URL do sistema.
	2.    O sistema exibe a tela de login do sistema, contendo o campo de login e senha.
	3.    O usuário informa os dados de acesso.
	4.    O sistema redireciona o usuário para a "tela menu do sistema".
	5. O usuário cadastra o paciente para uso da plataforma de atendimento.
	6. O usuário salva o cadastramento do paciente.
	7. O paciente recebe o link por e-mail para acessar a plataforma e criar seu login e senha.
	Fluxo Alternativo:
	3.1 Caso o usuário digite login ou senha inválido o sistema irá exibir uma mensagem de erro de login.
	5.1 O sistema deve validar o CPF no cadastramento.
	5.2 Caso o usuário já tenha cadastro o suporte pode efetuar alteração, exclusão e alteração do cadastro.
	Regras de Negócio Relacionado:
	[RN-02], [RN-03] e [RN-04]
 Fonte: O autor, 2021.
5.3 Descrição Casos de Uso – Realizar Login
 Tabela 6 - Descrição de Casos de Uso - Realizar Login
	Identificação:
	Realizar Login
	Descrição:
	Esse caso de uso permite ao usuário/paciente efetuar o login em sua conta.
	Ator Relacionado:
	Recepção, Suporte, Paciente, Médico, Usuário da Empresa
	Interessados:
	Todos que utilizam o sistema
	Pré-condições:
	O usuário deve possuir um login e senha.
	Pós-condições:
	O usuário realiza o login assim sendo redirecionado para o menu do sistema.
	Fluxo normal:
	1.    O usuário acessa a URL do sistema.
	2.    O sistema exibe a tela de login do sistema, contendo o campo de login e senha.
	3.    O usuário informa os dados de acesso.
	4.    O sistema redireciona o usuário para a "tela menu do sistema".
	Fluxo Alternativo:
	2.1 Caso o usuário seja um usuário empresa sem cadastrado, irá apresentar a mensagem de erro de login.
	3.1 Caso o usuário digite login ou senha inválido o sistema irá exibir uma mensagem de erro de login.
	Regras de Negócio Relacionado:
	[RN-01], [RN-04] e [RN-05]
 Fonte: O autor, 2021.
5.4 Descrição Casos de Uso – Encaminhar Para Fila Atendimento
 Tabela 7 - Descrição de Casos de Uso - Encaminhar para fila de atendimento
	Identificação:
	Encaminhar para fila de atendimento
	Descrição:
	Esse caso de uso permite a Recepção encaminhar ao atendimento médico
	Ator Relacionado:
	Recepção e Paciente
	Interessados:
	Médico, Recepção e Paciente
	Pré-condições:
	O usuário deve ser elegível para uso da plataforma.
	Pós-condições:
	O paciente é encaminhado a fila de atendimento.
	Fluxo normal:
	1.    O usuário da recepção recebe a solicitação de atendimento.
	2.    Recepção verifica se o paciente é elegível pelo cadastro.
	3.    A recepção encaminha o paciente para fila de atendimento.
	Fluxo Alternativo:
	2.1 Caso o paciente não ser elegível, não poderá efetuar atendimento médico, terá que entrar em contato com a empresa.
	Regras de Negócio Relacionado:
	[RN-02], [RN-03] e [RN-04]
 Fonte: O autor, 2021.
5.5 Descrição Casos de Uso – Atender Paciente
 Tabela 8 - Descrição de Casos de Uso - Atender Paciente
	Identificação:
	Atender Paciente
	Descrição:
	Esse caso de uso permite ao médico atender o paciente.
	Ator Relacionado:
	Paciente e Médico
	Interessados:
	Médico, Recepção e Paciente
	Pré-condições:
	O sistema deve ter acesso a câmera e voz do acesso dos envolvidos.
	Pós-condições:
	O paciente é atendido pelo médico.
	Fluxo normal:
	1.    O médico recebe a solicitação de atendimento da fila.
	2.    O médico aceita o paciente que está na fila de atendimento.
	3.    Realiza o atendimento do paciente.
	4. Conclui o atendimento do paciente.
	Fluxo Alternativo:
	2.1 Caso o paciente tiver queda de conexão a recepção entrará em contato com o paciente por telefone.
	Regras de Negócio Relacionado:
	[RN-03]
 Fonte: O autor, 2021.
5.6 Descrição Casos de Uso – Emitir Receita Médica
 Tabela 9 - Descrição de Casos de Uso - Emitir receita médica
	Identificação:
	Emitir receita médica
	Descrição:
	Esse caso de uso permite ao médico emitir a receita médica ao paciente.
	Ator Relacionado:
	Paciente e Médico
	Interessados:
	Médico e Paciente
	Pré-condições:
	O Paciente deve ter sido atendido pelo médico
	Pós-condições:
	A receita é envia por e-mail ao paciente.
	Fluxo normal:
	1.    O médico informa o diagnóstico.
	2.    O médico informa ao paciente sobre a receita que será emitida.
	3.    O médico conclui o atendimento.
	4. Emiti a receita que é enviada para o e-mail do paciente.
	Fluxo Alternativo:
	4.1 Caso o paciente tiver com alguma inconsistência no meio e-mail cadastrado terá que entrar em contato com a recepção.
	Regras de Negócio Relacionado:
	[RN-06]
 Fonte: O autor, 2021.
5.7 Descrição Casos de Uso – Emitir Atestado
 Tabela 10 - Descrição de Casos de Uso - Emitir Atestado
	Identificação:
	Emitir Atestado
	Descrição:
	Esse caso de uso permite ao médico emitir o atestado ao paciente.
	Ator Relacionado:
	Paciente e Médico
	Interessados:
	Médico e Paciente
	Pré-condições:
	O Paciente deve ter sido atendido pelo médico
	Pós-condições:
	O atestado é enviado por e-mail ao paciente.
	Fluxo normal:
	1.    O médico informa o diagnóstico.
	2.    O médico informa ao paciente sobre o atestado que será emitido.
	3.    O médico conclui o atendimento.
	4. Emiti o atestado que é enviado para o e-mail do paciente.
	Fluxo Alternativo:
	4.1 Caso o paciente tiver com alguma inconsistência no meio e-mail cadastrado terá que entrar em contato com a recepção.
	Regras de Negócio Relacionado:
	[RN-06]
 Fonte: O autor, 2021.
5.8 Descrição Casos de Uso – Solicitar Exame Covid-19
 Tabela 11 - Descrição de Casos de Uso - Solicitar Exame Covid-19
	Identificação:
	Solicitar Exame Covid-19
	Descrição:
	Esse caso de uso permite ao médico emitir a solicitação do exame Covid-19 para o paciente.
	Ator Relacionado:
	Paciente e Médico
	Interessados:
	Médico e Paciente
	Pré-condições:
	O Paciente deve ter sido atendido pelo médico
	Pós-condições:
	A solicitação do exame é enviada por e-mail ao paciente.
	Fluxo normal:
	1.    O médico informa o diagnóstico.
	2.    O médico informa ao paciente sobre a solicitação do exame para constatar sobre o vírus Covid-19 que será emitido.
	3.    O médico conclui o atendimento.
	4. Emiti a solicitação de exame do vírus Covid-19 que é enviado para o e-mail do paciente.
	Fluxo Alternativo:
	4.1 Caso o paciente tiver com alguma inconsistência no meio e-mail cadastrado terá que entrar em contato com a recepção.
	Regras de Negócio Relacionado:
	[RN-06]
 Fonte: O autor, 2021.
5.9 Diagrama de Casos de Uso
Conforme informado na Figura 1 e na Figura 2 abaixo, os Diagramas dos Casos de Uso do sistema de teleatendimento. 
 Figura 1 - Diagrama de Casos de Uso - Controle de Usuários
 Fonte: O autor, 2021.
 Figura 2 - Diagrama de Casos de Uso - Atendimento
 Fonte: O autor, 2021.
6. DIAGRAMA DE CLASSES 
Segundo PRESSMAN (2021, p. 140): “Para criarmos um conjunto de atributos que fazem sentido para uma classe de análise, devemos estudar cada caso de uso e escolher as “coisas” que “pertencem” àquela classe.”
Conforme estudo e identificação dos casos de uso, criamos o diagrama de classes, que estão identificados a relação das atividades das classes do sistema de teleatendimento, conforme a Figura 3 abaixo:
 Figura 3 - Diagrama de Classes
 Fonte: O autor, 2021.
7. DIAGRAMA DE ATIVIDADES
Para representação do diagrama de atividades, identificamos como:
 Um diagrama de atividades da UML complementa o caso de uso por meio de uma representação gráfica do fluxo de interação em um cenário específico. Muitos engenheiros de software gostam de descrever os diagramas de atividade como uma forma de representar como o sistema reage a eventos internos. (PRESSMAN, 2021, p. 151).
O Diagrama de atividades é efetivo para representar fluxos de processos, conforme estará demonstrado nas figuras seguintes dessa sessão.
7.1 Diagrama de Atividades – Cadastro de Usuário
 Figura 4- Diagrama de Atividades - Cadastro de Usuário
 Fonte: O autor, 2021.
7.2 Diagrama de Atividades – Cadastro de Usuário
 Figura 5 - Diagrama de Atividades - Cadastro de Paciente
 Fonte: O autor, 2021.
7.3 Diagrama de Atividades – Login no Sistema
 Figura 6 - Diagrama de Atividades - Login no Sistema
 Fonte: O autor, 2021.
7.4 Diagrama de Atividades – Atendimento
 Figura 7 - Diagrama de Atividades - Atendimento
 Fonte: O autor, 2021.
8. DIAGRAMA DE SEQUÊNCIA
Observando o diagrama de sequência podemos identificar:
 O diagrama de sequência da UML pode ser usado para modelagem comportamental. Os diagramas de sequência também podem ser usados para mostrar como os eventos provocam transições de objeto para objeto. Uma vez que os eventos tenham sido identificados pelo exame de um caso de uso, o modelador cria um diagrama de sequência – uma representação de como os eventos provocam o fluxo de um objeto para outro em função do tempo. Em resumo, o diagrama de sequência é uma forma abreviada do caso de uso. Ele representa classes-chave e os eventos que fazem o comportamento fluir de classe para classe. (PRESSMAN, 2021, p. 148).
Para descrever os principais eventos gerados no sistema usaremos o diagrama de sequência usando o padrão MVC (Model – View – Controller) que mostra o fluxo de interações, conforme as Figuras das sessões posteriores.
8. 
8.1 Diagrama de Sequência – Cadastro de Usuário
 Figura 8 - Diagrama de Sequência - Cadastro de Usuário
 Fonte: O autor, 2021.
8.2 Diagrama de Sequência – Alterar Usuário
 Figura 9 - Diagrama de Sequência - Alterar Usuário
 Fonte: O autor, 2021.
8.3 Diagrama de Sequência – Excluir Usuário
 Figura 10 - Diagrama de Sequência - Excluir Usuário
 Fonte: O autor, 2021.
8.4 Diagrama de Sequência – Consultar Usuário
 Figura 11 - Diagrama de Sequência - Consultar Usuário
 Fonte: O autor, 2021.
8.5 Diagrama de Sequência – Cadastro de Paciente
 Figura 12 - Diagrama de Sequência - Cadastro de Paciente
 Fonte: O autor, 2021.
8.6 Diagrama de Sequência – Alterar Paciente
 Figura 13 - Diagrama de Sequência - Alterar Paciente
 Fonte: O autor, 2021.
8.7 Diagrama de Sequência – Excluir Paciente
 Figura 14 - Diagrama de Sequência - Excluir Paciente
 Fonte: O autor, 2021.
8.8 Diagrama de Sequência – Consultar Paciente
 Figura 15 - Diagrama de Sequência - Consultar Paciente
 Fonte: O autor, 2021.
8.9 Diagrama de Sequência – Efetuar Login
 Figura 16 - Diagrama de Sequência - Efetuar Login
 Fonte: O autor, 2021.
8.10 Diagrama de Sequência – Atendimento Paciente
Figura 17 - Diagrama de Sequência - Atendimento Paciente
Fonte: O autor, 2021.
9. DIAGRAMA DE COMPONENTES
Sobre o diagrama de componentes podemos afirmar que:
 (...) os componentes preenchem a arquitetura de software e desempenham um papel para alcançar os objetivos e requisitos do sistema a ser construído. Pelo fato de os componentes residirem na arquitetura de software, devem se comunicar e colaborar com outros componentes e entidades (p. ex., outros sistemas, dispositivos, pessoas) existentes fora dos limites do software. (PRESSMAN, 2021, p. 206).
Analisando os conceitos dos componentes foi elaborado os diagramas descrevendo as atividades dos processos principais do sistema “Portal Empresas Telemedicina”.
1. 
2. 
3. 
4. 
5. 
6. 
7. 
8. 
9. 
9.1 Diagrama de Componentes – Controle de Usuário
 Figura 18 - Diagrama de Componentes - Controle de Usuário
 Fonte: O autor, 2021.
9.2 Diagrama de Componentes – Atendimento
 Figura 19 - Diagrama de Componentes - Atendimento
 Fonte: O autor, 2021.
10. DIAGRAMA DE IMPLANTAÇÃO
Para mostrar arquitetura do sistema usaremos o diagrama de implantação, que identifica a comunicação por meio de nós e defini como as máquinas estarão conectadas e a execução de hardware e software do meio físico de um sistema.
Segundo Pressman (2021, p. 615): “Diagramas de implantação focalizam a estrutura do sistema de software e são úteis para mostrar a distribuição física de um sistema de software entre plataformas de hardware e ambientes de execução.”
Na Figura 20, veremos a distribuição no diagrama de implantação do sistema de Portal Empresas Telemedicina, conforme abaixo:
 Figura 20 - Diagrama de Implantação - Sistema Portal Empresas Telemedicina
 Fonte: O autor, 2021.
11. METODOLOGIA APLICADA AO SISTEMA - NBR ISO/IEC 9126-1
O modelo de qualidade dos produtos de software está dividido em duas partes sendo eles:
· Qualidade Interna e Qualidade Externa.
· Qualidade em Uso.
A necessidade do usuário por qualidade integra de requisitos de qualidade em uso e em condições próprias de uso. Essas exigências podem ser usadas para especificar a qualidade externa e interna, fazendo uso das características e subcaracterísticas da qualidade de produtos de software. A análise de produtos de software de forma a satisfazer as necessidades de qualidade do software é um dos métodos no ciclo de vida de desenvolvimento de software.
A qualidade do produto de software pode ser avaliada pela medição de: 
· Atributos externos (característica pela medição do comportamento do código quando executado).
· Atributos internos (tradicionalmente de medidas estáticas de produtos intermediários).
· Atributos de qualidade em uso.
A Qualidade do processo que contribui para a melhoria da qualidade do produto, a qualidade do produto que auxilia para melhorar a qualidade em uso. Desta maneira, avaliar e melhorar um processo é um meio para melhorar a qualidade do projeto. Por meio da avaliação da qualidade em uso por fornecer o feedback para aperfeiçoar o produto, bem como a avaliação do produto pode fornecer o feedback para aperfeiçoar o processo.
10. 
11. 
11.1 Modelo de Qualidade
A qualidade do produto de software deve ser avaliada fazendo uso de um modelo de qualidade, o modelo de qualidade deve ser usado ao especificar objetivos de qualidade para os produtos de software. A qualidade do produto de software pode ser organizada em características e subcaracterísticas, que podem ser utilizadas como um checklist de problemas relacionados a qualidade. 
No modelo de qualidade externa e interna, atributos de qualidade de software são divididos em seis características (funcionalidade, usabilidade, confiabilidade, manutenibilidade, eficiência e portabilidade). Cada características ainda podem ser dívidas em subcaracterísticas para avaliações internas e externas.
Figura 21 - Modelo de Qualidade - Externa e Interna
Fonte: NBR ISO/IEC 9126-1, 2003.
Definindo as características de qualidade e as subcaracterísticas de software que impactam na qualidade a capacidade do software é determinada por um agrupamento de atributos que podem ser examinados conforme abaixo:
•Funcionalidade: é a capacidade do produto de software de fornecer funções que atinjam as necessidades declaradas e essenciais quando o software é usado em condições específicas.
•Confiabilidade: A capacidade do produto de software de manter um nível definido de performance quando usado em condições específicas. Desgaste ou envelhecimento não ocorrem em software. Limitações em confiabilidade ocorrem devido a faltas em requisitos, implementação e design. Falhas devido a esses problemas dependem de forma como o produto de software é usado e as opções acessadas, e não devido à ao tempo do software.
•Usabilidade: A capacidade do produto de software de ser entendido, compreendido, usado e atrair o usuário, quando usado em condições específicas. Usabilidade deve direcionar todos os diferentes ambientes de usuários que o software pode afetar.
•Eficiência: A capacidade do produto de software prover performance apropriada, relativa à quantidade de recursos usados, dentro de condições específicas.
•Manutenibilidade: A capacidade do produto de software de ser modificado. Alterações podem incluir correções, melhorias ou adaptações do software a mudanças no ambiente, requisitos e especificações funcionais.
•Portabilidade: A capacidade do produto de software de ser mudado de um ambiente para outro.O ambiente pode ser organizacional, software ou hardware.
11.2 Aplicação da Metodologia no Projeto
Conforme explicado pelos motivos informados nesta sessão usando também os quatros pilares da qualidade em uso, efetividade, produtividade, satisfação e segurança. Integramos a metodologia da ISO 9126-1, no projeto proposto de teleatendimento, buscando a qualidade do software que integra qualidade externa, qualidade interna e qualidade em uso para o usuário ter a visão sobre a qualidade do software. Para alcançar a qualidade desejada depende da qualidade externa que por sua vez depende da qualidade interna, e finaliza com a avaliação da qualidade em uso. Por meio da qualidade em uso do produto de software possibilita que os usuários específicos cheguem nos objetivos específicos com efetividade, produtividade, satisfação e segurança, assim tendo a visão sobre a qualidade de um ambiente contendo o software, e é analisado o resultado do uso de software neste ambiente proposto.
12. TERMO DE ABERTURA DE PROJETO
Para iniciar o TAP (termo de abertura de projeto), iniciaremos com o objetivo do projeto que é o sistema de teleatendimento de saúde, que será para atendimento de paciente de determinados hospitais e clínicas privadas, para ser realizado em seis meses a missão do projeto proposto é um sistema de telemedicina para consulta de pacientes, através da plataforma virtual, tendo a justificativa a redução do estado atual que presenciamos hoje de pandemia do COVID-19, com foco a redução de contaminação da população, que por muitas vezes se dão no caminho dos hospitais, nos hospitais em vias públicas circuladas e afins. 
A descrição preliminar do projeto proposto será uma plataforma de telemedicina através de vídeo conferência, entre o paciente e o médico, que após a consulta o médico poderá efetuar a emissão de solicitação de exame, atestado e receita. O paciente inicialmente será atendido pela recepção dentro da plataforma portal empresas telemedicina e será encaminhado a fila de atendimento para ser atendido em consulta pelo médico disponível. 
A restrição do ambiente do referido projeto será a empresa onde o sistema será implantado. Só podendo ser acessado pelos funcionários da empresa cliente, funcionário do suporte, recepção e o médico no ambiente de instalação do software, o paciente por sua vez pode acessar de qualquer local, sendo obrigatório o dispositivo com câmera para o teleatendimento em consulta com o médico. 
Após todo levantamento será encaminhado o termo de abertura de projeto para o aceite do patrocinador e definição da escolha do gerente de projeto, assim dando progresso no planejamento do projeto e passando para próxima etapa do escopo.
1.1 
2.1 
3.1 
4.1 
5.1 
6.1 
7.1 
8.1 
9.1 
10.1 
11.1 
Matriz de Responsabilidades – RACI
 Algumas vezes, na hora de definir um processo ou um projeto, nos perdemos em alguns detalhes e acabamos não definindo claramente as responsabilidades.
Para facilitar esse processo de definição de papéis e responsabilidades em uma organização ou em processos, existe a Matriz RACI.
Trata-se de uma matriz de responsabilidades que determina o papel de cada profissional ligado ao projeto ao longo de cada atividade de um processo ou projeto.
Quando esses papéis são efetivamente distribuídos e bem definidos, as decisões são tomadas mais efetivamente, a prestação de contas é mais transparente e o fluxo de trabalho torna-se muito mais organizado e detalhado.
Essa ferramenta consiste na criação de uma tabela simples, na qual são colocados os colaboradores e as atividades.
No cruzamento entre as linhas e as colunas, é colocada uma letra correspondente à responsabilidade daquela pessoa naquela etapa do projeto ou processo essas letras representadas pela RACI.
· R – Responsável pela atividade
· A – Accountable é a pessoa que é responsabilizada pela qualidade ou fracasso da atividade. 
· C – Consultado é a pessoa que em determinado momento podem fornecer uma informação ou podem dar autorização para o prosseguimento de determinada atividade.
· I – Informado é a pessoa quem em algum momento de execução de determinada atividade vão receber informações sobre o andamento da atividade ou sobre seus resultados.
Como veremos na Tabela 12 abaixo o modelo da definição de papéis e responsabilidades – RACI, do proposto projeto de telemedicina deste trabalho.
Tabela 12 - Matriz de Responsabilidades – RACI
	 
	GERENTE DE TI
	ANALISTA DE SISTEMA 
	ANALISTA DE REQUISITOS 
	PROGRAMADOR
	ANALISTA DE TESTES
	Levantamento de requisitos
	A
	C
	R
	I
	I
	Mapeamento dos processos 
	C
	R
	A
	I
	I
	Programação do Sistema
	C
	A
	C
	R
	I
	Fase de testes
	A
	I
	I
	I
	R
	Implantação
	A
	R
	C
	C
	C
Fonte: O autor, 2021.
 CRONOGRAMA DE ATIVIDADES
No projeto proposto para identificarmos as atividades do projeto portal empresas telemedicina, utilizaremos o gráfico de Gantt ou como diagrama de Gantt, de maneira geral seria uma ferramenta visual de controle de cronograma de um determinado projeto, ajudando a análise dos prazos de entrega e os recursos importantes. Conforme veremos na Figura 22, o gráfico mostra as tarefas que precisam ser realizadas e a sua duração. Desta forma simplifica a informação do papel de toda equipe e de suas responsabilidades a um melhor acompanhamento.
 Figura 22 - Diagrama de Atividades – Gráfico de Gantt
 Fonte: O autor, 2021.
GERENCIAMENTO DE CUSTOS
Nesta sessão iremos estimar os custos das tarefas e informar o valor monetário tirando por base o cronograma de atividades da sessão passada. O valor dos custos informados pode ser alterado no decorrer do desenvolvimento do fluxo do projeto ou por mudança de atividades se solicitado pelo cliente/patrocinador. Inclui os processos envolvidos em planejar o gerenciamento de custos, estimando os custos, especificando o orçamento e controlando os custos, de modo que o projeto proposto pode ser finalizado dentro do orçamento aprovado e os custos de estrutura (aluguel, materiais), custos de equipamento (computadores, retroprojetor, cliente servidor, assinatura Google Meet, etc). Conforme veremos na Tabela 13 abaixo:
Tabela 13 - Gerenciamento de Custos
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	ATIVIDADES
	DURAÇÃO/ DIAS
	CUSTOS
	 
	Equipe
	Sálarios
	Dia/8hr
	 
	 
	Reunião Inicial do Projeto
	21
	 R$ 21.840 
	 
	GERENTE DE PROJETOS
	 R$ 11.000 
	 R$ 366,67 
	 
	 
	Revisão da Documentação
	7
	 R$ 7.280 
	 
	ANALISTA DE SISTEMA
	 R$ 5.000 
	 R$ 166,67 
	 
	 
	Levantamento de Requisitos
	14
	 R$ 14.560 
	 
	ANALISTA DE REQUISITOS
	 R$ 5.200 
	 R$ 173,33 
	 
	 
	Desing/Prototipo
	7
	 R$ 7.280 
	 
	PROGRAMADOR 
	 R$ 7.000 
	 R$ 233,33 
	 
	 
	Modulos Básicos
	28
	 R$ 29.120 
	 
	ANALISTA DE TESTES
	 R$ 3.000 
	 R$ 100,00 
	 
	 
	Modelo de Dados
	7
	 R$ 7.280 
	 
	 
	 
	 
	 
	 
	User Case
	14
	 R$ 14.560 
	 
	TOTAL
	 R$ 31.200 
	 R$ 1.040 
	 
	 
	Testes Iniciais 
	7
	 R$ 7.280 
	 
	 
	 
	 
	 
	 
	Elaboração de Relatório de Processos
	7
	 R$ 7.280 
	 
	 
	 
	 
	 
	 
	Validação dos Relatórios
	7
	 R$ 7.280 
	 
	 
	 
	 
	 
	 
	Testes 1
	7
	 R$ 7.280 
	 
	 
	 
	 
	 
	 
	Testes 2
	7
	 R$ 7.280 
	 
	 
	 
	 
	 
	 
	Entrega do Projeto
	1
	 R$ 1.040 
	 
	 
	 
	 
	 
	 
	Custos de Estrutura98
	 R$ 32.634 
	 
	 
	 
	 
	 
	 
	Custos de Equipamentos
	 
	 R$ 15.000 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	TOTAL
	 
	 R$ 186.994 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 
Fonte: O autor, 2021.
ANÁLISE DE RISCOS
Sobre os riscos do projeto eles podem ser positivos ou negativos, exemplo de riscos positivos são oportunidades para acelerar o projeto e ter alguma economia e os riscos negativos quem em geral são aqueles que mais trazem a preocupação em um projeto, que temos o foco de nos proteger a esses riscos negativos. Os riscos sempre são futuros e que não temos o resultado do acontecimento outras características dos riscos eles são incertos, risco também pode ser pensado quando impacta o projeto. Levantado a base sobre os riscos faremos um registro de riscos, conforme elaborado abaixo sobre o projeto proposto de telemedicina.
1.	Falha de Monitoramento e Controle.
2.	Falta de Planejamento com a Equipe.
3.	Falta de Liderança pela Gerência.
4.	Falta de Apoio do Cliente/Patrocinador.
5.	Nenhuma Gestão de Riscos.
6.	Estimativas Sem Fundamentos.
7.	Falta de Comunicação.
8.	Sobrecarga de Trabalho dos Envolvidos com o Projeto.
9.	Falta de Escopo.
LIÇÕES APRENDIDAS
Para finalização do projeto, terminaremos com um processo interno de reflexão sobre o trabalho desenvolvido deste projeto, sobre os fluxos de atividades que foi elaborado assim melhorando e desenvolvendo-se para futuros trabalhos, aprendendo cada vez mais com acertos e erros repetitivos no decorrer do caminho trilhado. Assim se preparando melhor para futuros projetos e cada vez mais qualidades nas tarefas. Abaixo foi realizado algumas perguntas para determinar as lições aprendidas deste projeto.
•Escopo, o produto entregue corresponde aos descritos na declaração do escopo? Sim, feito a declaração conforme levantamento de requisitos.
•Tempo, entre os prazos planejados e realizados teve atraso? Não, o prazo foi reduzido mesmo tendo tempo mais longo.
•Qualidade, o projeto foi satisfatório para os usuários/clientes? Sim, mesmo com a dificuldade de saber pouco do ambiente de saúde podemos chegar a um software com qualidade aceitável para o cliente.
•Equipe, os colaboradores que participaram do time foram adequados? Sim. Mesmo não tendo um orçamento imenso para determinar mais mão de obra para o projeto, foi satisfatório a entrega com o empenho da equipe formada.
•Melhoramento, pode ser melhorado a construção do projeto? Sim, mesmo com o resultado satisfatório pode ser melhorados os processos para uma entrega sempre melhor ao cliente/patrocinador.
CONCLUSÃO
O proposto projeto do PIM VII, foi desenvolvido para solução do problema atual que vivemos hoje de pandemia, tratando diretamente na redução de contaminação com o sistema de telemedicina para tratamento de pacientes remoto, desestabilizando o contágio do COVID-19. 
Usando as lições aprendidas nas matérias Empreendedorismo, Gerenciamento de Projeto de Software, Gestão de Qualidade e Projeto de Sistemas Orientado a Objetos, foi possível a criação de planos de negócio da empresa startup e o desenvolvimento da ideia do projeto, descrição dos requisitos em detalhes técnicos conforme requerimento do proposto projeto, a criação de diversos diagramas pertinentes aos seus processos e importâncias, aplicação da NBR - ISO escolhida para representação de qualidade deste trabalho e também a elaboração do termo de abertura de projeto, definição da matriz de papéis de responsabilidades o cronograma de atividades, gerenciamento de custos, a análise de riscos e por fim as declaração das lições aprendidas.
Ressaltamos a ideia principal do projeto o cuidado da saúde e a proteção da vida com a solução do proposto PIM VII, o software projetado e desenvolvido de inibir a contaminação do vírus e com resultado a diminuir da curva de contágio.
REFERÊNCIAS
	
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software. 9. ed. Porto Alegre: AMGH, 2021.
UNIP INTERATIVA. Manual PIM VII. Disponível em: https://ava.ead.unip.br. Acesso em 09/09/2021.
SEBRAE. Inovação de impacto para Startups. Disponível em: https://www.sebrae.com.br/sites/PortalSebrae/cursosonline/inovacao-de-impacto-para-startups. Acesso em 12/09/2021.
GUEDES, Gilleanes. UML 2 Uma Abordagem Prática. 3. ed. São Paulo: Novatec, 2018.
REINEHR, Sheila. Engenharia de Requisitos. Revisão Técnica Marco Antônio Paludo. 1. Ed. Porto Alegre: SAGAH, 2020.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011. 
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 9126-1: Engenharia de software: Qualidade de produto. Rio de Janeiro. 2003.