PIM IV

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
Rafael Vitor Ferreira - 0431782
Sistema em C para cadastrar pacientes diagnosticados com covid-19.
Jundiaí-SP
2021
Rafael Vitor Ferreira - 0431782
Projeto Integrado Multidisciplinar para
obtenção do título de tecnólogo em (nome do curso),
apresentado à Universidade Paulista – UNIP EaD.
Orientador(a): Diego dias Rocha
Jundiaí-SP
2021
Resumo
A presente pesquisa tem como propósito o desenvolvimento de um sistema produzido em linguagem , bem como utilizar conhecimentos básicos de engenharia de software para gerenciar o ciclo de vida do projeto. O sistema será utilizado por hospitais para o cadastro e monitoramento de casos positivos de COVID-19, onde os dados dos pacientes cadastrados serão analisados pelo software e classificados como casos de risco ou não, para que sejam armazenados em arquivos externos possibilitando assim verificações futuras. O desenvolvimento foi dividido em três fases. Na primeira fase da pesquisa houve discussão a respeito do peso e classificação de cada requisito individualmente, onde estes tiveram seu “valor” contabilizado em pontos (métrica utilizada em algumas metodologias ágeis) e também elaborado um diagrama de caso de uso do software para documentar ilustrando minimamente a interação do mesmo com o usuário. Na segunda fase, foi definida como metodologia utilizada na gestão do ciclo de vida do software a XP (extreme Programming), esta que por sua vez se caracteriza por não possuir um Product Owner entre os clientes e desenvolvedores, possuir ciclos de vida rápidos e aplicabilidade especialmente em cenários onde o ciclo de vida do sistema é relativamente curto. Na terceira e última fase obteve-se o resultado final por meio da codificação, o software desenvolvido contou com as telas básicas de autenticação e controle de pacientes propostas no escopo geral do mesmo, além disto também fora elaborado um manual contendo os procedimentos de execução e testes do produto incorporados neste mesmo documento.
Palavras-chave: COVID-19, Ferramenta de Monitoramento, Software.
Abstract
The purpose of this research is to develop a system produced in language, as well as to use basic knowledge of software engineering to manage the project life cycle. The system will be used by hospitals for the registration and monitoring of positive cases of COVID-19, where the data of registered patients will be analyzed by the software and classified as risky or not, so that they are stored in external files, thus enabling future checks. The development was divided into three phases. In the first phase of the research, there was discussion about the weight and classification of each requirement individually, where these had their “value” counted in points (metric used in some agile methodologies) and also a software use case diagram to document illustrating minimally the same interaction with the user. In the second phase, XP (extreme Programming) was defined as the methodology used in software lifecycle management, which in turn is characterized by not having a Product Owner among customers and developers, having fast life cycles and applicability especially in scenarios where the life cycle of the system is relatively short. In the third and last phase, the final result was obtained through coding, the software developed had the basic authentication and patient control screens proposed in the general scope of the same, in addition to this a manual containing the execution procedures and product tests incorporated in this same document.
Keywords: COVID-19, Monitoring Tool, Software.
Sumário
Introdução	6
Desenvolvimento	7
ANÁLISE DE REQUISITOS Da ferramenta de monitoramento para casos de covid-19 (FFMC)	7
REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS	8
Requisitos Funcionais	8
Requisitos não Funcionais	8
Classificação dos requisitos do projeto	9
Diagrama de caso de uso do software	11
Aplicação de metodologias ágeis	12
Introdução às Metodologias Ágeis	12
Definição do extreme programming	14
Resumo de principais características	15
USO DO XP NO SOFTWARE FMCC	16
BENÉFICOS PARA USO DO XP NO PROJETO	17
Processo de Codificação e resultado final do software	17
Paradigma Procedural	18
Estrutura de Pastas do Projeto	18
Manual de Instalação e Uso	19
Telas Desenvolvidas para o Software	19
Autenticação do usuário	19
Menu de Opções	19
Inserção de Novo Registro	21
Listagem de dados	22
Procedimento de Testes	23
Conclusão	25
Referências	26
Introdução 
A pandemia do novo coronavírus estimulou diversas entidades públicas e privadas a alavancarem pesquisas relacionadas à inovação tecnológica em prol da saúde popular e no auxílio do monitoramento de casos e propagação do vírus. Tendo em vista que este se espalha de forma exponencial, a indústria de software tem papel importante em possibilitar que os profissionais de saúde e autoridades no geral estejam sempre um passo à frente do vírus para tomarem providências com antecedência.
A pesquisa a seguir tem como propósito o desenvolvimento de um sistema produzido em linguagem C. O sistema será utilizado por hospitais para o cadastro e monitoramento de casos positivos de COVID-19. Objetivando calcular e analisar se o paciente se encontra no grupo de risco, caso maior de 65 anos, nesses casos tendo os dados armazenados em arquivos externos que serão enviados para a Secretaria de Saúde da cidade visando registro e devido acompanhamento.
O planejamento atenderá a proposta do Projeto Integrado Multidisciplinar IV, utilizando-se das disciplinas e seus respectivos métodos, técnicas e ferramentas para exercer a prática do conteúdo abordado de forma teórica nas aulas bimestrais. Para tal execução será impregnado o uso do conhecimento nas disciplinas de “linguagem e técnicas de programação” e “engenharia de software I”. Com a disciplina “engenharia de software” elencou-se a análise de requisitos, sendo estes funcionais ou não funcionais, bem como a classificação dos requisitos do projeto, assunto abordado no capítulo dois; no capítulo três exibido o porquê da utilização de uma metodologia ágil no processo de desenvolvimento do software e suas vantagens com relação às metodologias tradicionais, apresentando a metodologia XP, explicando seus processos e como eles foram introduzidos no projeto; no quarto e último capítulo foi abordado o processo de codificação e o resultado final do software, manual de instalação e uso do sistema.
Sendo assim, espera-se que com a produção desse sistema, será possível obter mais uma ferramenta no controle do vírus.
Desenvolvimento
ANÁLISE DE REQUISITOS Da ferramenta de monitoramento para casos de covid-19 (FFMC)
Requisitos são solicitações, desejos e/ou necessidades dos interessados no projeto que será desenvolvido. Um requisito é a propriedade que um software exibe para solucionar problemas reais, é a conjuntura indispensável para satisfazer um objeto. Quando se trata de um software sob demanda, por exemplo, um requisito é uma maneira pelo qual o sistema oferecido deve fazer, ou um condicionamento no desenvolvimento do sistema, lembrando que, em ambas as ações, embora o programador ou o arquiteto de software tenha suas opiniões, é importante chegar em um consenso para resolver o problema do cliente.
 É importante frisar que manter uma concordância com os stakeholders é um dos principais objetivos dos requisitos. Sendo primordial para o sucesso dos softwares, os requisitos, fornecem a base para estimativas, modelagem, projeto, execução, testes e até mesmo para a manutenção dos mesmos. Assim, os requisitos estão presentes ao longo de todo o ciclo de vida de um software. 
Ao começar um projeto, os requisitos já devem ser levantados, entendidos e documentados. Bem como realizar atividades de controle de qualidade para verificar, validar e garantir a qualidade dos mesmos. Gerenciar a evolução dos requisitos é importante, estando cientesde que os negócios com sua dinâmica não garantem estabilidade e podem vir a sofrer alterações. Deste modo é necessário manter a rastreabilidade entre os requisitos e as outras peças do projeto. 
Podem ser distinguidos em 3 partes, sendo elas: Erro – Que corrige os bugs Bug é um termo comumente utilizado para se referir a comportamentos inesperados do software. do sistema, relatados por usuários. – Necessidade Customização – Que implementa algo a mais do que foi pedido no projeto inicial. Ex: uma integração com outro software. – Solicitações. Melhoria – São funcionalidades que podem incrementar algo a mais no sistema, como por exemplo uma coluna a mais em um relatório, um botão a mais e etc. – Desejos.
REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS 
Requisitos Funcionais 
 Dentro da engenharia de softwares podemos destacar o requisito funcional, onde há a materialização de uma necessidade ou solicitação realizada por um software. São variadas as funções e serviços que um sistema pode fornecer ao seu cliente, descrevemos abaixo algumas das inúmeras funções que os softwares podem executar:
· Incluir/Excluir/Alterar nome em uma tela de manutenção de funcionário
· Geração de relatório de determinado período de vendas
· Efetuar pagamentos de compra através de crédito ou débito
· Consulta e alterações de dados pessoais de clientes
· Emissão de relatórios de clientes ou vendas
· Consulta de saldo ou estoque
Basicamente o requisito funcional é o coração do projeto. Tudo que dá sentido ao mesmo e o torna relevante para os interessados.
Requisitos não Funcionais 
Os Requisitos não Funcionais não estão relacionados diretamente às funcionalidades de um sistema. Também chamado de atributos de qualidade, ainda assim são de grande importância no desenvolvimento do sistema. Tratados geralmente como premissas e restrições técnicas de um projeto os requisitos não funcionais são praticamente todas as necessidades que não podem ser atendidas através de funcionalidades. Geralmente mensurável, os requisitos não funcionais definem características e impõe limites do sistema como método de desenvolvimento, tempo, espaço, Sistema Operacional, dentre outros e cuja medida pode ser determinada é importante que se associe essa medida ou referência à cada requisito não funcional. Para ficar mais claro veja alguns exemplos de propriedades e suas métricas:
· O tamanho pode ser medido em bytes e número de Chip de RAM.
· A velocidade está ligada ao tempo de utilização da tela, ou transações processadas por segundos.
· A métrica da portabilidade é o número de sistema-alvo.
· A facilidade de uso pode ser medida pelo número de janelas ou o tempo de treino
· A confiabilidade tem ligação com o tempo médio que o sistema pode vir a falhar, a disponibilidade ou até mesmo a taxa de ocorrência de falhas.
São pontos que não necessariamente estão associadas ao objetivo do software, no entanto, trazem qualidades significativas para o mesmo.
Classificação dos requisitos do projeto
Os requisitos foram retratados sendo ilustrados com pontos de 0 a 10 que delimitam valor/importância bem como dificuldade de implementação, logo em seguida a definição de cada requisito (funcional/Não funcional):
 Requisitos do Software:
	Requisito
	Importância/Valor (Em Pontos)
	Classificação
	Ao receber o diagnóstico positivo os profissionais da saúde devem realizar o login no sistema (informando o usuário e a senha).
	9
	Funcional
	Informar os dados pessoais do paciente, como Nome, CPF, Telefone, Endereço (Rua, Número, Bairro, Cidade, Estado e CEP), Data de Nascimento e E-mail, data do diagnóstico e informar alguma morbidade do paciente (diabetes, obesidade, hipertensão, tuberculose, outros) .
	8
	Funcional
	As informações serão salvas em um Arquivo (a principal vantagem de um arquivo é que as informações armazenadas podem ser consultadas a qualquer momento). 
	7
	Não funcional
	 Após o cadastro, o sistema deverá calcular a idade e verificar se o paciente possui alguma morbidade e se pertence ao grupo de risco (maiores de 65 anos). Caso o paciente pertença ao grupo de risco, o sistema deverá salvar em um arquivo de texto o CEP e a idade do paciente para que essa informação possa ser enviada para a central da Secretaria de Saúde da cidade. 
	10
	Funcional
Diagrama de caso de uso do software 
Abaixo, uma representação do funcionamento do software por meio de diagramação, visando simplificar em ilustração as interações entre o usuário e o sistema. Vale ressaltar que para compreender o fluxo do mesmo não é necessário conhecimento técnico prévio, portanto os interessados no resultado final podem facilmente compreendê-lo.
Diagrama de caso de uso do FMCC
Aplicação de metodologias ágeis 
Introdução às Metodologias Ágeis
A engenharia de software, bem como qualquer outra engenharia, é um estudo de ordem técnica onde são desenvolvidos conceitos por um especialista em determinada área. O software em sua estrutura de dados permite a quem o manipula o controle e o desenvolvimento para solução de problemas.
A partir desse desenvolvimento foram construídos métodos para organizar e administrar de forma mais eficiente e eficaz a sua estrutura. Estes são conhecidos como Metodologias de desenvolvimento de software.
Com o passar do tempo, na busca pelo aprimoramento, redução de custos e por aproveitar cada instante do tempo da melhor forma, as metodologias foram se aprimorando. Até que em 2001, com a criação do Manifesto Ágil (e-Architects Inc, 2001) , a área da Tecnologia da Informação passou a ter maior adaptabilidade visando a real necessidade do cliente. No método ágil o desenvolvimento ganhou uma abordagem em que softwares são criados de uma forma colaborativa, com equipes multidisciplinares e que têm bom nível de autonomia na execução do trabalho. A grande e básica diferença entre a metodologia tradicional e o método ágil se encontra na questão burocrática do mesmo. A metodologia tradicional em cascata se tornou um tanto quanto pesada, em contraste com as metodologias emergentes que foram chamadas de metodologias leves ou “em cascata”. Veja abaixo um diagrama que demonstra a forma sequencial como esta opera
Ciclo de vida de um software no modelo cascata.
 Concomitantemente ao desenvolvimento, no método cascata era desenvolvido o trabalho fase a fase, para que um passo adiante seja dado, o passo anterior precisa ser concluído. Progredindo linearmente seja no planejamento ou no desenvolvimento, chegando no review quando notavam-se pontos de melhoria a serem trabalhados, o que resultava em um grande período de “retrabalho”, gerando orçamento maior e um tempo de serviço mais denso.
Comparação entre metodologias tradicionais e metodologias ágeis :
	Categorias
	Tradicional
	Ágil
	Modelo de desenvolvimento
	Tradicional (Uma etapa após outra)
	Interativa (Reforça a revisão e testes do escopo flexibilizando as etapas)
	Foco
	Processos
	Pessoas
	Eixo do Gerenciamento
	Controle
	Facilidade
	Participação dos stakeholders
	Apenas durante o levantamento de requisitos
	Envolvido durante todo o ciclo de vida do software
	Desenvolvedores
	Colaboram individualmente
	Trabalham geralmente em pares
	Características do produto
	Software desenvolvido como um todo, e entregue em unidade única
	Módulos mais importantes priorizados nas entregas.
	Testes
	Somente ao final do ciclo de desenvolvimento
	Presente em todo o projeto, é incentivado inclusive ao final das etapas de planejamento
	Documentação
	Completa e descritiva
	Somente o necessário
Definição do extreme programming
Quase intrinsecamente ao manifesto ágil, surgiram diversos frameworks que utilizam-se de seus pilares, conhecidos também como metodologias ágeis. Uma das mais simples e cotidianas especialmente em projetos rápidos ou relativamente pequenos é o XP (Extreme Programming).
De acordo com Beck (2002), considerado o “pai” ou criador da metodologia XP, o sucesso estrutural da XP vem do esforço pela satisfação do cliente. O método ágil XP, quando desenvolvido por Beck, tinha como objetivos: a satisfação do cliente,o atendimento aos requisitos do cliente, ser fortemente focado em trabalho em times, manter todos voltados para criar software com qualidade. É um método que se utiliza de padrões de boas práticas por meio da programação extrema.
Ciclo eXtreme Programming:
A imagem acima representa o ciclo de iterações durante as etapas de vida do software que destacam os aspectos mais notórios do XP. É iminente a figura de que todos os procedimentos executados passam por validação e feedback diretos do cliente, não carecendo necessariamente uma figura de negócios intermediária entre a equipe de desenvolvimento e os stakeholders como no Scrum por exemplo. Desta forma, é um recurso identificável com aplicações que disponham de requisitos em constante mudança por exigência do cliente, e em detrimento disto, passam por uma triagem inicial bem menos meticulosa no levantamento destes, onde a arquitetura comumente não visa escalabilidade mas primordialmente resolver problemas momentâneo.
A XP foi desenvolvida para ser aplicada em projetos com times de dois a dez programadores que não sejam severamente restringidos pelo ambiente computacional existente e no qual boa parte da execução de testes possa ser feita em pouco tempo no dia (BECK, 2002). Através do método, é possível criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver e criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual (BECK, 2002). É possível alcançar estes objetivos através de um pequeno conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver softwares (FARIAS; PATRONI; PASCUTTI).
Resumo de principais características 
· Ciclo de vida curto do software (Projetos rápidos)
· Pouca ênfase em escalabilidade da aplicação (Tanto em infraestrutura quanto arquitetura do código)
· Ideal para resolver problemas diretos e momentâneos
· Não possui necessariamente uma figura de negócios intermediando a comunicação entre o cliente e a equipe de desenvolvimento.
· Pouca burocracia e ênfase em documentação
· Requisitos que mudam constantemente por exigência do cliente
Exemplos comuns de aplicação do XP são trabalhos informais como os conhecidos freelancer.
USO DO XP NO SOFTWARE FMCC 
Para o desenvolvimento do projeto a equipe contou com seis integrantes em três pares de programadores, separando assim um grupo de tarefas por meio de um quadro Kanban na ferramenta Trello para serem pesquisados e adicionados ao projeto antes da escrita do código.
 A codificação e os testes ficaram a cargo de uma dupla específica que, no decorrer da codificação repassou o código para que as demais duplas analisassem e incrementem durante a realização de testes, sendo assim feitos novos testes cada vez que um novo código ia sendo integrado ao sistema.
“O uso de programação em pares tem várias vantagens:
· Apoia a ideia de propriedade e responsabilidade comuns para software. Isso reflete a ideia de Weinberg sobre programação sem egoísmo, na qual o software é de propriedade da equipe como um todo e as pessoas não são responsabilizadas por problemas com o código. 
· Em vez disso, a equipe tem responsabilidade coletiva na resolução desses problemas.Atua como um processo informal de revisão porque cada linha de código é vista por pelo menos duas pessoas…” (Sommerville, 2007, com adaptações).
A citação de Sommerville salienta que o desenvolvimento em pares enfatiza a propriedade coletiva do código, a melhor interação entre os indivíduos que partilham soluções complementares e a supervisão mútua de tarefas realizadas.
BENÉFICOS PARA USO DO XP NO PROJETO 
Optou-se pela utilização do método XP, por ser um método “leve” de desenvolvimento, trabalhando com equipes pequenas, visando a produção de um software de forma rápida, todos dedicados a entregar um software de qualidade e objetivo. Tornando assim o método ideal para a obtenção de um resultado satisfatório tendo em vista um grupo de seis pessoas com um curto prazo de entrega ideal para a proposta do Projeto Integrado Multidisciplinar IV (PIM IV). 
Comparação entre algumas características do XP e o escopo do projeto:
	Característica do XP
	Corresponde ao cenário do projeto (Sim/Não)
	Explicação Básica
	Ciclo de vida curto de software
	Sim
	O software possui um prazo curto para ser entregue
	Menor ênfase em escalabilidade
	Sim
	O código não foi elaborado visando boas práticas de arquitetura que possibilitem uma expansão ou reutilização do mesmo futuramente
	Resolução objetiva de problemas momentâneos
	Sim
	O software foi desenvolvido para o problema específico ao qual foi proposto
	Ausência de um intermediário com o cliente
	Sim
	Não há nada semelhante a um P.O entre ambos
	Pouca ênfase em documentação
	Sim
	Não há uma documentação bem específica e elaborada, tendo em vista que o resultado não seria visto apenas ao término como nas metodologias tradicionais
	Requisitos que mudam constantemente
	Não
	Os requisitos do software são fixos, no entanto a ausência deste ponto não representa risco à aplicação do XP neste cenário.
Processo de Codificação e resultado final do software
O procedimento de codificação envolve “traduzir” os requisitos para o produto tangível (software), é onde todos os pontos levantados deixam de ser ideias abstratas e documentos passando a se materializar em protótipos ou módulos utilizados pelo cliente. Vale ressaltar que é impossível descrever fidedignamente toda a atividade envolvida, tendo em vista que apesar de ferramentas e metodologias utilizadas para a gestão e que visam prever e reagir de antemão aos imprevistos, este processo envolve resolver problemas a grosso modo, especialmente problemas técnicos relacionados ao conhecimento da equipe e comportamentos inesperados do resultado. A seguir, será discorrido a respeito do paradigma abordado, como estão divididos os arquivos e pastas do projeto e como utilizar o software da maneira mais simples possível
Paradigma Procedural
O a codificação do software foi feita por meio do padrão procedural, que pode ser caracterizado como a forma mais simplista de programação, onde cada verificação, iteração e entrada de usuário são executadas uma após outra sucessivamente e de maneira síncrona.
Estrutura de Pastas do Projeto 
A estrutura básica de pastas:
· data – Nela ficarão contidos os arquivos CSV que armazenam os dados tanto de usuários que podem efetuar login quanto das ocorrências de COVID-19 e casos de risco.
· bin – Arquivos binários gerados na compilação à partir do CodeBlocks, podem ser gerados binários de Debug, para testes e arquivos de Release para versões estáveis.
· main.c – Arquivo principal onde está centrado o código.
Manual de Instalação e Uso
O software em questão não requer instalação por parte do usuário, para utilizá-lo basta navegar até utilizando o explorador de arquivos até o diretório bin/Release onde se encontram os executáveis instáveis, os mesmos podem ser copiados para uma localização de preferência, contanto que incluam a pasta data em que estão localizados os arquivos CSV que manipulam os dados armazenados.
Telas Desenvolvidas para o Software 
Autenticação do usuário 
Ao iniciar o software, o usuário se deparará com a tela de autenticação, que verificará se o mesmo pode ou não acessar o software. Os usuários e senhas autorizados estão armazenados no arquivo Users.csv, e novos usuários podem ser acrescentados manualmente a este.
 Tela de autenticação do usuário:
Menu de Opções 
Logo após a tela de Login, serão exibidos no menu as possíveis opções presentes no sistema que devem ser escolhidas por meio de seu número indicado, bem como uma notificação em cor vermelha que será exibida apenas quando houver casos de risco registrados.
Tela de seleção de opções:
Inserção de Novo Registro
As informações decada paciente são inseridas sequencialmente, e podem seguir dois fluxos alternativos. 
O primeiro fluxo é caracterizado quando a idade do usuário ou sua comorbidade pertence a um grupo de risco portador do vírus (mais de sessenta e cinco anos). Neste caso é exibida uma mensagem em vermelho notificando a ocorrência e após isto o nome, CEP e idade do indivíduo são armazenados em um arquivo separado chamado Risk Cases.csv que pode ser consultado posteriormente por meio do software ou algum outro programa capaz de exibir planilhas, como o Excel.
 Inserindo Novos Registros – Exemplo paciente em grupos de risco por idade avançada:
O segundo fluxo é quando o paciente diagnosticado não possui comorbidade alguma ou idade que se enquadre em casos de risco, nesta situação os dados em geral do paciente são salvos no arquivo Occurrences.csv que também pode ser consultado posteriormente.
Inserindo Novos Registros – Exemplo paciente que não se enquadra em grupos de risco:
Listagem de dados
Tanto pacientes de risco quanto pacientes comuns, podem ser listados por meio das opções presentes no menu.
 Exemplo de listagem de pacientes gerais (Fora de situação de risco):
Procedimento de Testes
Não foram integrados ao projeto quaisquer frameworks que visem a automatização de testes, portanto os únicos testes possíveis são os manuais. Abaixo, um guia básico de como compilar e depurar o projeto. Este pode ser testado por meio de quaisquer editores e compiladores, no entanto recomenda-se o uso do Codeblocks que será exemplificado.
Com o editor aberto, selecionar as opções “arquivo” e “abrir”; Localizar o arquivo “covid-monitoring-tool.cbp” e abri-lo com o Code Blocks.
Projeto aberto no CodeBlocks:
Pressionando o atalho F9, o programa pode ser compilado e logo após executado, além disto. Podem ser adicionados pontos de interrupção nas linhas do código (representados por um ponto vermelho na linha correspondente), utilizados para depurar o software passo a passo, desta forma será mais simples encontrar problemas de lógica conforme o fluxo do código é executado.
Código sendo compilado e executado com pontos de interrupção:
Conclusão
Por meio desta pesquisa foi possível atingir o objetivo da aplicação prática de conhecimento básico a respeito de programação e engenharia de software em prol do bem popular na saúde pública, em um sistema capaz de autenticar usuários e permiti-los inserir registros de pacientes com casos positivos de COVID-19, realizando a separação e notificação de casos de risco para auxiliar no monitoramento. Inicialmente, foram discutidos e classificados os requisitos que estavam devidamente pré-especificados no escopo da pesquisa, onde foi tomada como decisão de arquitetura o uso de arquivos CSV para armazenar os dados dos pacientes em geral, esta visualização facilita o controle destes dados como exportação, sendo estes facilmente legíveis via Microsoft Excel ou outros grandes sistemas externos que suportem serialização de dados neste formato. A partir deste ponto fora discorrido os benefícios da utilização de metodologias ágeis de maneira geral, suplantando a maneira trivial de gestão de projetos que fora utilizada no passado, bem como escolhida como ideal para o projeto a metodologia conhecida por Extreme Programming. O código foi versionado utilizando as ferramentas Git e GithubCódigo disponível em: https://github.com/MiqueiasGFernandes/covid-monitoring/tree/windows, a aplicação desenvolvida por meio de exibição em linha de comandos e tendo como base a Linguagem C. Ao final, os resultados do software e procedimento para testes manuais foram exemplificados por meio de um guia presente neste documento. 
Referências
Beck, Kent. Extreme Programming: die revolutionäre Methode für Softwareentwicklung in kleinen Teams ; [das Manifest]. Pearson Deutschland GmbH, v. 1, f. 93, 2002. 186 p.
e-Architects Inc. Manifesto para Agile Software Development. Agile Manifesto. 2001. Disponível em: https://agilemanifesto.org/. Acesso em: 22 nov. 2020.
Farias, Douglas; Patroni, Robinson; Pascutti, Márcia. CRIANDO SOFTWARE COM METODOLOGIA XP(EXTREME PROGRAMMING) E DOCUMENTAÇÃO JAVADOC . In: Encontro Internacional de Produção Científica Cesumar . 2009, Maringá – Paraná – Brasil: VI EPCC . Disponível em: https://www.unicesumar.edu.br/epcc-2009/wp-content/uploads/sites/77/2016/07/douglas_lopes_farias.pdf. Acesso em: 22 nov. 2020.
Hoda, Rashina; Noble, James; Marshal, Stuart. Agile Project Management. In: International Conference on Extreme Programming and Agile Processes in Software Engineering. 2008.
Pressman, Roger S.. Engenharia de Software – 7.ed.. AMGH Editora, f. 1006, 2008. 2011 p.
Sommerville, Ian. Engenharia de software (8a. ed.)., f. 286. 2007. 572 p.