UNIVERSIDADE PAULISTA - UNID EAD

DESENVOLVIMENTO E GESTÃO DE CICLO DE VIDA DE SOFTWARE PARA

MONITORAMENTO DE CASOS DE CORONAVÍRUS EM LINGUAGEM C

BRUNO AMAZONAS ESPINACE - 2085684

CARLOS ANTÔNIO GOMES SILVA - 2094058

DIEGO ARAÚJO SÃO BENTO - 0572299

JOÃO VICTOR RIBEIRO - 2089912

MIQUÉIAS GOMES FERNANDES - 2093954

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
(eXtremme Programmin), 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 (eXtremme Programmin)
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.

INTRODUÇÃO
A pandemia do novo coronavírus estimulou diversas entidades públicas e privadas a
alavancarem pesquisas relacionadas a 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 a 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 capitulo 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 as
metodologias tradicionais, apresentando a metodologia XP, explicando seus processos e como
eles foram introduzidos no projeto; no quarto e ultimo 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.

ANÁLISE DE REQUISITOS DA FERRAMENTA DE

MONITORAMENTO PARA CASOS DE COVID-19 (FMCC)  
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
cientes de 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 bugsBug é um
termo comumento 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 kbytes 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):

Importância/Valor
Requisito Classificação
(Em Pontos)

Ao receber o diagnóstico positivo os profissionais da saúde devem realizar o login no sistema (informando 9 Funcional
o usuário e a senha).

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 8 Funcional
do paciente (diabetes, obesidade, hipertensão, tuberculose, outros) .

As informações serão salvas em um Arquivo (a principal vantagem de um arquivo é que as informações Não
7
armazenadas podem ser consultadas a qualquer momento).  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
10 Funcional
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. 

Tabela 1 — Requisitos do Software

Elaborada pelos autores

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 1 — Diagrama de caso de uso do FMCC

Elaborada pelos
autores

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 pesado, 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.
 Figura 1 — Ciclo de vida de um software no modelo cascata

Pressman (2008,
p. 60)

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.

Tabela 2 — Comparação entre metodologias tradicionais e metodologias ágeis

Categorias Tradicional Ágil

Modelo de Interativa (Reforça a revisão e testes do escopo flexibilizando as

Tradicional (Uma etapa após outra)
desenvolvimento etapas)

Foco Processos Pessoas

Eixo do Gerenciamento Controle Facilidade

Participação
Apenas durante o levantamento de requisitos  Envolvido durante todo o clico de vida do software
dos stakeholders

Desenvolvedores Colaboram individualmente Trabalham geralmente em pares

Características do Software desenvolvido como um todo, e entregue

Módulos mais importantes priorizados nas entregas.
produto em unidade única

Presente em todo o projeto, e incentivado inclusive ao final das

Testes Somente ao final do ciclo de desenvolvimento
etapas de planejamento

Documentação Completa e descritiva Somente o necessário

   

Adaptado de Hoda, Noble e Marshal
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.

Figura 2 — Ciclo eXtreme Programming

Pressman (2008)

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. É eminente na 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.

Imagem 1 — Quadro Kanban utilizado para gerenciar tarefas do projeto

Printscreen
capturado pelos autores. A ferramenta está disponível em: https://trello.com

 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 incrementassem
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. Esta abordagem para delegar
tarefas é utilizada em diversas outras metodologias ágeis.

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).   

Tabela 3 — Comparação entre algumas características do XP e o escopo do projeto

Corresponde ao cenário do
Característica do XP Explicação Básica
projeto (Sim/Não)

Ciclo de vida curto de

Sim O software possui um prazo curto para ser entregue
software

Menor ênfase em O código não foi elaborado visando boas práticas de arquitetura que possibilitem
Sim
escalabilidade uma expansão ou reutilização do mesmo futuramente

Resolução objetiva de
Sim O software foi desenvolvido para o problema específico ao qual foi proposto
problemas momentâneos

Ausência de um intermediário
Sim Não há nada semelhante a um P.O entre ambos
com o cliente

Pouca ênfase em Não há uma documentação bem específica e elaborada, tendo em vista que o
Sim
documentação resultado não seria visto apenas ao término como nas metodologias tradicionais

Requisitos que mudam Os requisitos do software são fixos, no entanto a ausência deste ponto não
Não
constantemente representa risco á aplicação do XP neste cenário.

Elaborada pelos autores

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 utilizáveis 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.
Imagem 2 — Estrutura de pastas

Elaborada pelos
autores

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.

Imagem 3 — Tela de autenticação do usuário

Elaborada pelos
autores
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 houverem casos de risco registrados.

Imagem 4 — Tela de seleção de opções

Elaborada pelos
autores

Inserção de Novo Registro

As informações de cada 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 RiskCases.csv que pode ser consultado
posteriormente por meio do software ou algum outro programa capaz de exibir planilhas, como o
Excel.

Imagem 5 — Inserindo Novos Registros - Exemplo paciente em grupos de risco por idade
avançada
 Elaborada pelos
autores

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 Ocurrences.csv que também pode ser consultado posteriormente.

Imagem 6 — Inserindo Novos Registros - Exemplo paciente que não se enquadra em grupos de
risco

Elaborada pelos
autores

Listagem de dados

Tanto pacientes de risco quanto pacientes comuns, podem ser listados por meio das
opções presentes no menu.

Imagem 7 — Exemplo de listagem de pacientes gerais (Fora de situação de risco)

Elaborada pelos
autores

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 CodeBlocks.

Imagem 8 — Projeto aberto no CodeBlocks

Elaborada pelos
autores

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.

Imagem 9 — Código sendo compilado e executado com pontos de interrupção

0 Elaborada pelos
autores

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 eXtremme 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 for 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.