PIM VIII

Prévia do material em texto

UNIVERSIDADE PAULISTA DEPARTAMENTO DE INFORMÁTICA 
FABIO MOREIRA BUENO 
DESENVOLVER O MECANISMO DE ACESSO A UM TRECHO DO BANCO DE DADOS DE UM SISTEMA EM C# E PROTÓTIPO EM ASP.NET ONDE USUÁRIO INTERAGI COM O BANCO DE DADOS
PROJETO INTEGRADO MULTIDISCIPLINAR 
Limeira 2022 
FABIO MOREIRA BUENO 
DESENVOLVER O MECANISMO DE ACESSO A UM TRECHO DO BANCO DE DADOS DE UM SISTEMA EM C# E PROTÓTIPO EM ASP.NET ONDE USUÁRIO INTERAGI COM O BANCO DE DADOS
Projeto Integrado Multidisciplinar apresentado ao curso de Análise e Sistema da Informação, como parte dos requisitos necessários à ob- tenção do título de Graduado em Análise e Desenvolvimento de Sistemas. 
Limeira 2022 
 (
2
 
) (
 
)
Resumo
Este trabalho apresenta uma solução digital que visa o desenvolvimento de uma codificação em C# do mecanismo de acesso a um trecho de banco de dados, assim como os protótipos de interface gráfica com o usuário em ASP .Net e Android. Seguindo o contexto de desenvolvimento, foi atribuído uma tarefa de desenvolver alguns aspectos de um sistema que já está em desenvolvimento, e a equipe foi responsabilizada pelos aspectos de desenvolver um estrutura responsável por possibilitar o acesso as informações do banco de informações, ou seja, do banco de dados, criando um protótipo de interface gráfica com o usuário em ASP .NET permitindo que o usuário tenha interação com os dados modelados, e levando em conta o desenvolvimento de outra interface gráfica com o usuário em Android. Para o desenvolvimento do projeto foram aplicados conceitos, conhecimentos e práticas adquiridos no curso, com complemento de pesquisas, de tal modo, possibilitando a aplicação e implantação da tecnologia back end. Contudo, para o desenvolvimento do projeto foi necessário analisar, desenvolver diagramas de funcionamento, instalação e estruturação do banco de dados e desenvolvimento das interfaces solicitadas, permitindo a finalização do primeiro versionamento do sistema de acesso ao banco de dados.
Abstract
Due to the COVID-19 pandemic, there was a need to avoid physical contact and agreat movement in favor of staying at home, aiming to reduce crowding in hospitals and the system to be presented will meet this demand, via the web, an intuitive and simple app where you will carry out procedures that can be avoided in a first analysis. All surveyprocesses, technical analysis, use cases, business rules and all other artifacts will be carried out to structure a consistent analysis in a clear and succinct manner where it can assist inthis purpose.
Keywords: Web, Analysis, Demand
Sumário
1	Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	6
2	Empreendedorismo	. . . . . . . . . . . . . . . . . . . . . . . . . . . .	7
2.1	Plano de negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	7
2.1.1	Panorama do mercado	. . . . . . . . . . . . . . . . . . . . . . . . . . .	8
2.1.2	Nome da empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	8
2.1.3	Negócio da empresa	. . . . . . . . . . . . . . . . . . . . . . . . . . . .	8
2.1.4	Missao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	8
2.1.5	Visão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	8
2.1.6	Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	9
2.1.7	Beneficios do aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . .	9
2.1.8	Publico Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	9
Gerenciamento de Projeto de Software	11
Requisitos Funcionais	11
Requisitos não funcionais	15
Regra de negócio	16
Gestão de Qualidade	19
Projeto de Sistema Orientado a Objetos	22
Objetos	22
Classes	22
Herança	23
Polimorfismo	23
UML	24
Termo de abertura de projeto	26
Conclusão	29
 
Referência	30
1 Introdução
Este trabalho apresenta um projeto de software de teleatendimento médico, que tem como propósito diminuir as visitas e agilizar os atendimentos médicos em época de pandemias nos hospitais. Com a nova Covid-19 devemos por segurança evitar qualquer tipo de aglomeração em hospitais para que a doença não continue se espalhando, logo o software de teleatendimento é essencial para este momento que estamos passando, pois os atendimentos remotos podem ajudar a diminuir a pressão nos sistemas de saúde,deixando assim os hospitais livres para quem, realmente, precisa de atendimento presencial. Apresenta-se um plano de negócio para a startup que realizará o projeto, além de termos extremamente técnicos envolvendo diagramas e todo o processo de gerenciamento do projeto de software. Buscamos analisar as estratégias para o desenvolvimento completo do software. Nessa análise será verificado o comprometimento de todos dentro da equipe na busca de um planejamento sem falhas.
O termo telemedicina tem origem na palavra grega ‘tele’, que significa distância, assim, a telemedicina abrange toda a prática médica realizada à distância, independente do instrumento utilizado para essa relação, computadores, tablets e smartphones facilitam as videoconferências e o avanço da Inteligência Artificial (IA) leva conhecimento ao alcance de todos. No Brasil, o serviço de telemedicina, principalmente aplicada na emissão de laudos online, está crescendo e se consolidando.
Nossa missão é desenvolver um sistema que garanta a integridade, a segurança e o sigilo de informações, bem como a necessidade de registro das consultas em prontuário clínico, seguindo à risca portaria do Ministério da Saúde. Apesar de ter sido regulamentada pela Lei 1.643 de 2002, a norma em questão não contempla os avanços tecnológicos e asnovas possibilidades desenvolvidas ao longo das quase duas décadas desde a publicação, o que poderá se tornar um entrave na hora de homologarmos nosso sistema.
2 Empreendedorismo
2.1 Plano de negócio
Por que elaborar um plano de negócios?
1. O processo de organizar um plano de negócios, nos obriga a assumir um posicionamento não emocional, crítico e objetivo em relação ao seu projeto como um todo.
2. O produto acabado – o seu plano de negócios – é um instrumento operacional que, se usado de forma apropriada irá auxiliá-lo a gerenciar o seu negócio e a trabalhar efetivamente para seu sucesso.
3. O plano de negócios concluído transmite suas ideias para outros e fornece a base para sua proposta de financiamento.
SEGMENTOS DE CLIENTES A Segmentação de clientes são divisões dos clientes de acordo suas necessidades e interesses, com intuito de melhorar o entendimento, alcançar e servir bem.
PROPOSTA DE VALOR Propostas de valor é o pacote de produtos e serviços que criam valor para um segmento de clientes específico. Esta etapa tem como objetivo o de proporcionar o valor percebido da marca para um determinado segmento de clientes se diferenciando da concorrência.
CANAIS Canais é a forma a qual as empresas comunicam-se e entregam aos seus clientes a sua proposta de valor para cada segmentação de clientes, atuando as áreas de marketing e logísticas das organizações.
RELACIONAMENTO COM CLIENTES Esta etapa proporciona a interação da empresa com a segmentação de clientes através de suas motivações: captura de clientes, retenção de clientes, incremento de vendas e fortalecimento da marca.
FONTES DE RECEITA Engloba o dinheiro que a empresa gera em cima de cada Segmento de Clientes previamente definido. Mas isso não significa o “lucro” ganho e, sim, o fluxo de receita envolvido.
RECURSOS PRINCIPAIS Os recursos principais são os principais recursos para que as empresas façam com que seu modelo de negócio funcione.
 (
1
0
 
) (
 
)
ATIVIDADES CHAVE Basicamente, das tarefas essenciais que a empresa precisa executar para atingir seu objetivo comercial, isto é, atender a Proposta de Valor, alcançar seus Segmentos de Clientes, sustentar um Relacionamento com os Clientes, para, por fim, criar Fontes de Receita de longo prazo.
PARCERIAS PRINCIPAIS Parceiros principais são as empresas ou pessoas que são importantespara o funcionamento do modelo de negócio das empresas.
ESTRUTURA DE CUSTOS A estrutura de custos envolve os principais custos decorrentes da operação do modelo de negócios das empresas
2.1.1 Panorama do mercado
A indústria da tecnologia está determinando a performance do mercado de ações, dos investimentos em novos empreendimentos e a forma como as empresas fazem negócios no Brasil.
Os fatores que m ais influenciam o crescimento do número de usuários na Internet são: a redução significativa dos custos de acesso a equipamentos de informática, o acesso grátis à Internet e a economia relativamente estável. Levantamento realizado pela SSCG Media Group no final de março indica que 53% dos clínicos especializados em pneumologia, doenças infecciosas, oncologia e cardiologia estavam usando soluções de telemedicina para atender seus pacientes.
Do lado dos pacientes, a tendência se confirma: relatório produzido pela Civic Science entre os dias 20 d e fevereiro e 20 de março mostra que aumentou de 18% para 30% a busca de serviços de telemedicina
2.1.2 Nome da empresa
Razão social: Fabtech Development System
2.1.3 Negócio da empresa
A FabTech será uma empresa de desenvolvimento de sistemas, mais especificamente para a definição de criar aplicativos para consultas médicas, sediada no município de São Paulo, São Paulo, Brasil. É previsto o início de suas atividades para abril de 2022, com o lançamento de seu produto o “Mais Saúde”, um software de consultas médicas online com o intuito de preservar o distanciamento social devido à pandemia.
2.1.4 Missão
Oferecer produtos com alta qualidade em todo o processo produtivo e valorização dos princípios éticos em todas as atividades operacionais com o propósito de promover confiança e privacidade que acreditamos serem imprescindíveis ao nosso ramo de atividade.
2.1.5 Visão
Ser uma empresa de referência no mercado nacional de software de telemedicina, gerando credibilidade em nossa marca através de nossos produtos de qualidade e uma linguagem com propósito.
2.1.6 Valores
Honestidade, transparência e ética profissional com clientes, fornecedores e todos aqueles envolvidos com nossa empresa. Valorizando sempre o fator-humano, com opiniões, para constantes melhorias, prezando os valores morais em nossas atividades.
2.1.7 Beneficios do aplicativo
Com base nas necessidades identificadas do público-alvo, tanto de pacientes quanto de clínicas, podemos destacar os benefícios que o Mais Saúde trará a seus clientes.
· Pode consultar preço para o procedimento;
· Define forma de pagamento;
· Só poderá ser identificado pelo Clinica quando aceitar a procedimento;
· Evitar aglomerações;
· Economizar o tempo de ir até a clínica.
· Clínicas
· Custo mensal baixo;
· Evitar aglomerações;
· Só precisa ter um endereço físico;
· Não precisa possuir ou desenvolver site ou homepage na Internet;
· Recebe ferramentas para processar pagamento;
· Recebe ferramentas para administrar suas consultas na Internet.
2.1.8 Publico Alvo
O consumidor primário serão pessoas jurídicas que prestam serviços de vendas de planos de saúde, bem como redes médico-hospitalares privadas e até mesmo o Governo, através do Ministério da Saúde.
Empresas de diversos setores;
· Microempreendedores;
· Órgãos públicos
O público-alvo final será casos de pessoas não urgentes em questão de saúde, que precisam de um atendimento primário e que em muitas vezes, o caso do paciente pode ser resolvido através apenas desse atendimento, sendo assim, este atendimento ocorreria através da telemedicina, com o uso do sistema proposto neste trabalho.
3 Gerenciamento de Projeto de Software
3.1 Requisitos Funcionais
Os requisitos funcionais são as especificações das funções (recursos) do produto. Simplificando, os requisitos funcionais definem exatamente o que um software deve fazer e como o sistema deve responder às entradas. Os requisitos funcionais definem os objetivos do software,
o que significa que o software não funcionará se esses requisitos não forem atendidos '.
Os requisitos, tanto funcionais quanto não funcionais, são elaborados por analistas de negócios. Cabe a eles se comunicar com os clientes, descobrir suas necessidades e desejos e traduzi-los em especificações.
Os requisitos funcionais podem incluir:
· requisitos de negócio
· requisitos de relatórios
· funções administrativas
· autenticação
· requisitos de certificação
Segue abaixo os requisitos funcionais aplicados no projeto:
	Requisito
	RF1
	Título
	Cadastrar Paciente
	Descrição
	Esse caso permite ao paciente atrelar seu perfil virtual ao seu cadastro no plano de saúde ou instituição que proverá o atendimento, bem como ao
código do seu cartão do SUS.
	Ator
	Paciente
	Entrada
	Paciente deve estar cadastrado em algum outro programa de atendimento de
saúde ou instituição/clínica particular participante.
	Processo
	O Paciente escolhe seu Plano ou Instituição e preenche as informações
solicitadas.
	Saída final
	1 - O sistema atrela as informações fornecidas ao cadastro já existente; 2- O
sistema mostra a confirmação do cadastro.
	Requisito
	RF2
	Título
	Agendar Consulta
	Descrição
	Esse caso de uso permite que o Paciente agende uma consulta a todos os médicos especialistas que fizerem parte do Plano, Instituição ou ao Posto de
Saúde do SUS escolhido.
	Ator
	Paciente
	Entrada
	Estar vinculado ao Plano de Saúde, Instituição Médica ou SUS
	Processo
	Agendar a Consulta
	Saída final
	1- O Paciente escolhe a especialidade; 2- Despois ele escolherá o
profissional que irá atendê-lo. 3- O sistema fará uma consulta com as datas e horas disponíveis; 4- O paciente escolhe e efetiva a marcação.
	Requisito
	RF3
	Título
	Receber Atendimento
	Descrição
	Esse caso permite ao paciente atender a chamada realizada pelo profissional
e ser atendido
	Ator
	Paciente
	Entrada
	Paciente estar autenticado no programa
	Processo
	O Paciente deverá atender a chamada
	Saída final
	1- O paciente deverá atender a ligação e seguir as orientações do profissional de saúde que irá atendê-lo; 2- Concluindo o atendimento, o paciente deverá desligar a chamada; 3- Após a chamada finalizada, será apresentado um questionário a ser respondido pelo paciente; 4- Preenchido o formulário, o
paciente dará OK.
	Requisito
	RF4
	Título
	Validar Cadastro Paciente
	Descrição
	Esse caso de uso permite que o Administrador valide os dados referente ao cadastro do usuario. Comparando uma foto do documento com os dados
digitados e os dados existentes no cadastro vinculado
	Ator
	Administrador
	Entrada
	Validar dados
	Processo
	Paciente ter realizado seu cadastro
	Saída final
	1- O administrador abre o cadastro e compara os dados; 2- Estando correto
formaliza o cadastro.
	Requisito
	RF5
	Título
	Confirmar Atendimento Médico
	Descrição
	Esse caso de uso permite que o Administrador efetive a data e o profissional
que atenderam a consulta.
	Ator
	Administrador/Profissional da Saúde
	Entrada
	Paciente ter realizado a marcação de alguma consulta
	Processo
	1. O Administrador confirma com o profissional sua agenda pré cadastrada;
2. Havendo conformidade entre o pré-agendado e o profissional é efetivada todas as consultas para o dia seguinte; 3. Não havendo conformidade, o Administrador deverá mandar mensagem para o Paciente avisando do
contratempo e oferecendo datas e horas alternativas
	Saída final
	Atendimento médico confirmado
	Requisito
	RF6
	Título
	Reagendar
	Descrição
	Esse caso permite ao Administrador sugerir data e horários distintos dos
escolhidos previamente pelo Paciente.
	Ator
	Administrador
	Entrada
	Ter uma consulta agenda pelo Paciente
	Processo
	1. O administrador de posse da informação do não atendimento, entra na consulta e escolhe a opção reagendar; 2. O sistema lhe mostrará outras datas e horários possíveis; 3. Ele escolhe as mesmas e clica em enviar sugestões;
4. O sistema irá enviar um email pré-formatado avisando dos empecilhos do
atendimento e sugerindo as datas e horários escolhidos pelo Administrador.
	Saída final
	Consultareagendada
	Requisito
	RF7
	Título
	Realizar Atendimento com Vídeo
	Descrição
	Esse caso de uso permite que o Profissional de Saúde faça a chamada para
realizar a consulta agendada
	Ator
	Profissional da Saúde
	Entrada
	Ter consulta agendada
	Processo
	O Paciente aceitar a chamada
	Saída final
	1. O Profissional de Saúde escolhe o proximo atendimento e clica em realizar a chamada; 2. O sistema automaticamente verifica as informações necessárias para o atendimento e as disponibiliza na tela enquanto realiza a
chamada de vídeo
	Requisito
	RF8
	Título
	Cadastrar Atendimento Médico Realizado
	Descrição
	Esse caso de uso permite que o Profissional de Saúde alimente o sistema
com os dados referente a consulta realizada ou em andamento
	Ator
	Profissional da Saúde
	Entrada
	Ter concluído a consulta
	Processo
	1. Após ou durante a consulta o Profissional de Saúde vai preenchendo os dados necessários referente aos problemas relatados pelo Paciente; 2.
Concluído o preenchimento o Profissional de Saúde clica em gravar
histórico clínico
	Saída final
	Atendimento médico realizado
	Requisito
	RF9
	Título
	Cadastro
	Descrição
	Esse caso de uso permite que o Administrador valide os dados referente ao cadastro do usuario. Comparando uma foto do documento com os dados
digitados e os dados existentes no cadastro vinculado
	Ator
	Profissional da Saúde
	Entrada
	Realizar a conclusão do histórico
	Processo
	1. Após gravar o Histórico Clínico o sistema perguntará se deseja fazer alguma prescrição; 2. O Profissional de Saúde dirá que Sim, caso seja
necessário; 3. Um novo formulário se abre para preencher a prescrição em si
4. Concluído o
	Saída final
	Finalizar atendimento
3.2 Requisitos não funcionais
Enquanto os requisitos funcionais definem o comportamento fundamental do sistema, os requisitos não funcionais estabelecem como o sistema executará essa função. Vamos voltar ao exemplo de notificação por email. O fato de o sistema enviar automaticamente uma notificação por email é um requisito funcional. Os requisitos não funcionais ditarão quando (5 segundos após a inscrição) o e-mail deve ser enviado.
A lista de requisitos não funcionais pode estar relacionada a:
· Usabilidade
· Confiabilidade
· Desempenho
Ao contrário dos requisitos funcionais, os requisitos não funcionais não formam a espinha dorsal do sistema. Isso significa que o sistema ainda funcionará se os requisitos não funcionais não forem atendidos.
No entanto, não se deve minimizar o papel dos requisitos não funcionais. Segue abaixo os requisitos não funcionas aplicados ao projeto:
3.3 Regra de negócio
As pessoas usam os termos "regra de negócios" e "lógica de negócios" para se referir à parte de seu aplicativo que é específica para seu aplicativo e representa o comportamento central de como as coisas deveriam funcionar, em oposição à funcionalidade genérica que poderia ser útil em software escrito para um cliente / negócio / base de clientes ou código diferente que existe para oferecer suporte à infraestrutura do aplicativo.
Frequentemente, a lógica de negócios está sujeita a alterações quando as necessidades do cliente mudam, então gostamos de colocá-la em um local / camada especial para que possamos modificá-la conforme necessário.
Embora o termo pareça sugerir o contrário, o software não comercial também possui lógica de negócios. Por exemplo, uma regra que afirma que "quando um usuário faz YZ, o aplicativo deve validar algo" pode ser classificada como uma regra de negócios.
O código do utilitário, como análise / processamento / acesso a dados e outros, não seria considerado lógica de negócios.
Ela costuma ser uma iniciativa central nas estratégias de transformação digital das organizações. Como parte desses esforços, as organizações devem aproveitar as vantagens dos recursos de modelagem de regras de negócios e evitar a codificação direta de regras de negócios como parte de seus designs de implementação.
As regras de negócios podem se aplicar a muitos aspectos de uma organização e podem ser expressas de várias maneiras. Em geral, as regras de negócios definem instruções ou restrições específicas sobre como certas ações do dia a dia devem ser executadas.
Por exemplo, as regras de negócios podem incluir:
Uma estrutura de aprovação de tomada de decisão para o processamento de faturas, onde apenas alguns gerentes podem assinar faturas totalizando um valor específico
Cálculos em que uma fórmula pode ser usada para calcular receitas ou despesas
Políticas em que uma organização exige que seus funcionários trabalhem com uma lista preferencial de fornecedores
Quando as regras de negócios são projetadas separadamente das implementações de processos, elas fornecem uma abordagem poderosa e flexível para ajudar as organizações a se moverem mais rapidamente no cumprimento de seus objetivos e responder melhor às necessidades de negócios em constante mudança.
Segue abaixo as regras de negócio aplicada ao projeto:
Regras de Negócio 1
Cadastro de paciente
O cadastro é premissa principal para ter acesso ao sistema e suas funcionalidades;
O cliente deverá preencher os dados solicitados nos respectivos campos, sendo preenchimento obrigatório de Nome, CPF, RG, cidade de nascimento, e-mail e telefone para contato;
O sistema deverá validar a autenticidade do CPF informado pelo paciente no site da receita federal ao ser solicitado efetivação do cadastro.
Regras de Negócio 2
Cadastro dos médicos
O cadastro dos médicos é importante para que o Sistema tenha sentido, pois o agendamento só será realizado se um médico estiver cadastrado;
O médico deverá preencher os dados solicitados nos respectivos campos, sendo preenchimento obrigatório de Nome, endereço, foto, CRM, especialização e disponibilidade;
O sistema deverá validar a autenticidade do CPF informado pelo médico no site da receita federal ao ser solicitado efetivação do cadastro.
Regras de Negócio 3
Agendamento
Cada agendamento deve usar 1h exatamente;
Os agendamentos devem estar disponíveis entre 8h às 18h (primeiro às 8, último as 17); O paciente não pode agendar um horário já agendado;
O paciente não pode agendar um horário que já passou; O paciente pode listar todos os médicos disponíveis; Regras de Negócio 4
Recuperação de senha
O link enviado por e-mail do paciente para resetar a senha, deve expirar em 2h; O usuário precisar confirmar sua nova senha para resetar sua antiga;
Regras de Negócio 5
Duplicidade de cadastro de paciente
Não pode haver duplicidade de cadastro dos pacientes, deve ser baseado no CPF como primary key.
4 Gestão de Qualidade
A metodologia de qualidade de software escolhida e aplicada na minha pequena empresa de software é a ISO NBR 9000:2015, lançada no Brasil pela Associação Brasileira de Normas Técnicas, conjuntando as normas 9000, 9001, 9004 e 19011 como principais normas da família.
Uma pequena empresa visa, com certeza, estágios mais altos no mercado, para que isso aconteça é preciso garantir espaço para “saltar”, e um dos passos iniciais para conquistar credibilidade frente aos seus concorrentes é a regulamentação de seus processos internos, pois a imagem de uma empresa é refletida na qualidade de seus produtos e/ou serviços oferecidos.
Pode-se fazer certo da primeira vez ou então fazer tudo de novo. Se uma equipe de software enfatizar a qualidade em todas as atividades de engenharia de software, ela reduzira a quantidade de reformulações que terá de fazer. Isso resulta em custos menores e, mais importante ainda, menor tempo para a colocação do produto no mercado. (Pressman, 2011, p.358). A ISO 9000:2015 é uma certificação que atesta o padrão de qualidade e gestão dentro das empresas, ela engloba pontos referentes à garantia da qualidade em projeto, desenvolvimento, produção, instalação e serviços associados; objetivando a satisfação do cliente pela prevenção de não conformidades em todos os estágios envolvidos no ciclo da qualidade da empresa, como resultado da implantação do modelo ISO temos uma maior capacidadeprodutiva e a geração de maior eficiência e qualidade e redução de custos.
Para implantação do citado modelo, a empresa deverá contratar uma consultoria especializada; auditores de um órgão certificador irão realizar uma auditoria, emitir um relatório e o órgão certificador irá analisar e emitir o certificado de acordo com os itens:
Responsabilidade da administração: requer que a política de qualidade seja definida, documentada, comunicada, implementada e mantida. Além disto, requer que se designe um representante da administração para coordenar e controlar o sistema da qualidade.
Sistema da qualidade: deve ser documentado na forma de um manual e implementado.
Análise crítica de contratos: os requisitos contratuais devem estar completos e bem definidos. A empresa deve assegurar que tenha todos os recursos necessários para atender às exigências contratuais.
Controle de projeto: todas as atividades referentes a projetos (planejamento, métodos para revisão, mudanças, verificações etc.) devem ser documentadas.
Controle de documentos: requer procedimentos para controlar a geração, distribuição, mudança e revisão em todos os documentos.
Aquisição: deve-se garantir que as matérias-primas atendam às exigências especificadas.
Deve haver procedimentos para a avaliação de fornecedores.
Produtos fornecidos pelo cliente: deve-se assegurar que estes produtos sejam adequados
ao uso.
Identificação e rastreabilidade do produto: requer a identificação do produto por item, série ou lote durante todos os estágios da produção, entrega e instalação.
Controle de processos: requer que todas as fases de processamento de um produto sejam controladas (por procedimentos, normas etc.) e documentados.
Inspeção e ensaios: requer que as matérias-primas sejam inspecionadas (por procedimentos documentados) antes de sua utilização.
Equipamentos de inspeção, medição e ensaios: requer procedimentos para a calibração/aferição, o controle e a manutenção destes equipamentos.
Situação da inspeção e ensaios: deve haver, no produto, algum indicador que demonstre por quais inspeções e ensaios ele passou e se foi aprovado ou não.
Controle de produto não-conforme: requer procedimentos para assegurar que o produto não conforme aos requisitos especificados é impedido de ser utilizado inadvertidamente.
Ação corretiva: exige a investigação e análise das causas de produtos não-conformes e adoção de medidas para prevenir a reincidência destas não conformidades.
Manuseio, armazenamento, embalagem e expedição: requer a existência de procedimentos para o manuseio, o armazenamento, a embalagem e a expedição dos produtos.
Registros da qualidade: devem ser mantidos registros da qualidade a longo de todo o processo de produção. Estes devem ser devidamente arquivados e protegidos contra danos e extravios.
Auditorias internas da qualidade: deve-se implantar um sistema de avaliação do programa da qualidade.
Treinamento: devem ser estabelecidos programas de treinamento para manter, atualizar e ampliar os conhecimentos e as habilidades dos funcionários.
Assistência técnica: requer procedimentos para garantir a assistência a clientes.
Técnicas estatísticas: devem ser utilizadas técnicas estatísticas adequadas para verificar a aceitabilidade da capacidade do processo e as características do produto.
Analisando estes critérios, nota-se que o ponto central de um sistema de gestão da qualidade baseada nas normas ISO 9000 é a apropriada documentação deste sistema.
5 Projeto de Sistema Orientado a Objetos
A programação orientada a objetos (POO) é um paradigma de programação fundamental usado por quase todos os desenvolvedores em algum momento. OOP é o paradigma de programação mais popular e é ensinado como a forma padrão de codificar para a maior parte da carreira educacional de programadores. É usado para estruturar um programa de software em pedaços simples e reutilizáveis de projetos de código (geralmente chamados de classes), que são usados para criar instâncias individuais de objetos. Existem muitas linguagens de programação orientadas a objetos, incluindo JavaScript, C++, JAVA, Python.
5.1 Objetos
Um objeto é um elemento computacional que representa, no domínio da solução, alguma entidade (abstrata ou concreta) do domínio de interesse do problema sob análise. Objetos similares são agrupados em classes.
No paradigma de orientação a objetos, tudo pode ser potencialmente representado como um objeto. Sob o ponto de vista da programação, um objeto não é muito diferente de uma variável no paradigma de programação convencional. Por exemplo, quando se define uma variável d o tipo int em C o u em Java, essa variável tem:
· Um espaço em memória para registrar o seu esta do atual (um valor);
· Um conjunto de operações associa das que podem ser aplicadas a ela, através dos operadores definidos na linguagem que podem ser aplicados a valores inteiros (soma, subtração, inversão de sinal, multiplicação, divisão inteira, resto da divisão inteira, incremento, decremento).
Da mesma forma, quando se cria um objeto, esse objeto adquire um espaço em memória para armazenar seu estado (os valores de seu conjunto de atributos, definidos pela classe) e um conjunto de operações que podem ser aplicadas ao objeto (o conjunto de métodos definidos pela classe).
5.2 Classes
Uma Classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.
Características:
Nome — a diferencie das outras classes.
Atributos—propriedades que descrevem um intervalo de Valores que as instâncias da classe podem apresentar. Abstraem os tipos de dados ou estados que os objetos de uma classe. Podem abranger.
Operações (métodos) — implementam serviços que podem Ser solicitados por algum objeto da classe para modificar o Comportamento. Abstraem algo que pode ser feito com um objeto. Algumas vezes, a chamada a uma operação de um objeto altera os Atributos ou o estado dele.
5.3 Herança
Uma característica bem pensada como uma família vamos imaginar: a criança, por exemplo, está herdando características de seus pais. Os pais, herdam algo dos avós, o que faz com que a criança também tem características de seus avos, e assim sucessivamente.
5.4 Polimorfismo
Se você pensar sobre as raízes gregas do termo, deve se tornar óbvio. Poli = muitos: polígono = muitos lados, poliestireno = muitos estirenos (a) , poliglota = muitos idiomas e assim por diante.
Morf = mudança ou forma: morfologia = estudo da forma biológica, Morpheus = o deus grego dos sonhos capaz de assumir qualquer forma.
Portanto, polimorfismo é a capacidade (na programação) de apresentar a mesma interface para diferentes formas subjacentes (tipos de dados).
Por exemplo, em muitas linguagens, inteiros e flutuantes são implicitamente polimórficos, pois você pode adicionar, subtrair, multiplicar e assim por diante, independentemente do fato de os tipos serem diferentes. Eles raramente são considerados como objetos no termo usual.
Polimorfismo é a capacidade de qualquer dado ser processado em mais de uma forma.
O polimorfismo é o principal poder da programação orientada a objetos. É muito importante que linguagens que não suportam polimorfismo não possam se anunciar como linguagens orientadas a objetos. As linguagens que possuem classes, mas não têm capacidade de polimorfismo, são chamadas de linguagens baseadas em objetos. Portanto, é muito vital para uma
linguagem de programação orientada a objetos. É a capacidade de um objeto ou referência assumir muitas formas em diferentes instâncias. Ele implementa o conceito de sobrecarga de função, sobreposição de função e funções virtuais.
5.5 UML
A Linguagem de modelagem unificada (UML) ajuda você a modelar sistemas de diversas maneiras. Um dos tipos mais populares na UML é o diagrama de classes. Bastante usado por engenheiros de software para documentar arquiteturas de software, os diagramas de classes são um tipo de diagrama da estrutura porque descrevem o que deve estar presente no sistema a ser modelado. Nãoimporta seu nível de familiaridade com diagramas UML ou de classe, nosso software de UML online foi concebido para ser simples e fácil de usar.
A UML foi criada como um modelo padronizado para descrever uma abordagem de programação orientada ao objeto. Como as classes são os componentes básicos dos objetos, diagramas de classes são os componentes básicos da UML. Os diversos componentes em um diagrama de classes podem representar as classes que serão realmente programadas, os principais objetos ou as interações entre classes e objetos.
A forma de classe em si consiste em um retângulo com três linhas. A linha superior contém o nome da classe, a linha do meio, os atributos da classe e a linha inferior expressa os métodos ou operações que a classe pode utilizar.
Classes e subclasses são agrupadas juntas para mostrar a relação estática entre cada
objeto.
6 Termo de abertura de projeto
I . Informações gerais:	Data: 15/10/2021
Nome do projeto: Sistema de teleatendimento médico para consulta de pacientes via
app/web
Nº do projeto: 32 Nome do patrocinador: Fabio Bueno
Origem: necessidade de melhoria no processo
II. Visão geral do projeto:
No fim de março, o Conselho Federal de Medicina (CFM) divulgou uma resolução que permite o trabalho remoto de médicos. O Ministério da Saúde ratificou a liberação do uso da telemedicina em uma portaria publicada dias depois no Diário Oficial da União. “Já não era sem tempo”, afirmou Renato Velloso, CEO da rede de centros médicos Dr. Consulta em artigo de opinião veiculado pelo Estadão.
III. Objetivos do Projeto:
A telemedicina inclui uma variedade de práticas relacionadas ao uso da tecnologia da informação na área da saúde para alcançar o tele-atendimento. Essa prática era um tema polêmico e pouco difundido entre os profissionais no Brasil e, devido ao aumento exponencial do número de casos covid-19 no país, essa prática tornou-se uma necessidade. O objetivo é propor um projeto de sistema para consulta médica e adequado acompanhamento clínico de pacientes por meio do APP / Web, contemplando os itens incluídos na seção requisitos.
IV. Cronograma
V. Custos
VI. Análise de riscos
7 Conclusão
O Projeto Integrado Multidisciplinar teve como objetivo realizar o desenvolvimento de um sistema usando métodos, técnicas e ferramentas de engenharia de software. O estudo de engenharia de requisitos permitiu entender o funcionamento futuro de um sistema de forma que atenda as solicitações do cliente e automatizar os atendimentos.
Quando a pandemia aconteceu, os humanos já tinham seu piloto automático está ligado, não prestando mais atenção ao futuro significado, e a relação entre as pessoas por muito tempo o segundo plano. Pare. pensar. Reflita e encontre uma solução para reorganizar a vida e o objetivo da humanidade é imperativo hoje chance A UNIP nos trouxe o PIM VII, um trabalho prático que traz desafios da atualidade. Com base em nossas necessidades reais diárias, não é apenas inspirador, como isso nos inspirará a continuar nossa pesquisa e desenvolvimento. A telemedicina é apenas a ponta do iceberg, existem muitas outras soluções e lugares que precisam de atenção. Este é o nosso dever como parte privilegiada e capacite nossa sociedade, conte com nosso conhecimento.
Referência
MENDES, Judas Tadeu Grassi. Economia Fundamentos e aplicações. 2. ed. São Paulo: Pearson	Prentice	Hall,	2004.	Disponível	em: https://plataforma.bvirtual.com.br/Leitor/Loader/1090/pdf. Acesso em: 01 abr. 2020.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e padrões.São Paulo: LTC, 2000.
PETERS, JAMES F. et al. Engenharia de Software, Rio de Janeiro, Ed. Campus,2002.
PMI. PMBOK - Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBoK®) /Project Management Institute - PMI. 5.ed. São Paulo: Saraiva, 2014.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. 7. ed.
Porto Alegre: Amgh, 2011