DESENVOLVIMENTO E GESTÃO DE CICLO DE VIDA DE SOFTWARE PARA MONITORAMENTO DE CASOS DE CORONAVÍRUS EM LINGUAGEM C

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

Tabela 1 — Requisitos do Software

RequisitoImportâ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).
9Funcional
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) .8Funcional
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). 7Nã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. 10Funcional

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
Diagrama de caso de uso do FMCCElaborada 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
Ciclo de vida de um software no modelo cascataPressman (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

CategoriasTradicionalÁgil
Modelo de desenvolvimentoTradicional (Uma etapa após outra)Interativa (Reforça a revisão e testes do escopo flexibilizando as etapas)
FocoProcessosPessoas
Eixo do GerenciamentoControleFacilidade
Participação dos stakeholdersApenas durante o levantamento de requisitos Envolvido durante todo o clico de vida do software
DesenvolvedoresColaboram individualmenteTrabalham geralmente em pares
Características do produtoSoftware desenvolvido como um todo, e entregue em unidade únicaMódulos mais importantes priorizados nas entregas.
TestesSomente ao final do ciclo de desenvolvimentoPresente em todo o projeto, e incentivado inclusive ao final das etapas de planejamento
DocumentaçãoCompleta e descritivaSomente 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
Ciclo eXtreme ProgrammingPressman (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 (BECK2002). 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 (BECK2002). É 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 (FARIASPATRONIPASCUTTI).

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
Quadro Kanban utilizado para gerenciar tarefas do projetoPrintscreen 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

Característica do XPCorresponde ao cenário do projeto (Sim/Não)Explicação Básica
Ciclo de vida curto de softwareSimO software possui um prazo curto para ser entregue
Menor ênfase em escalabilidadeSimO 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âneosSimO software foi desenvolvido para o problema específico ao qual foi proposto
Ausência de um intermediário com o clienteSimNão há nada semelhante a um P.O entre ambos
Pouca ênfase em documentaçãoSimNã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 constantementeNãoOs requisitos do software são fixos, no entanto a ausência deste ponto não 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
Estrutura de pastasElaborada 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
Tela de autenticação do usuárioElaborada 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
Tela de seleção de opçõesElaborada 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
Inserindo Novos Registros - Exemplo paciente em grupos de risco por idade avançadaElaborada 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
Inserindo Novos Registros - Exemplo paciente que não se enquadra em grupos de riscoElaborada 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)
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
Projeto aberto no CodeBlocksElaborada 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
Código sendo compilado e executado com pontos de interrupçãoElaborada 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

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

FariasDouglas; PatroniRobinson; PascuttiMá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.

HodaRashina; NobleJames; MarshalStuart. Agile Project Management. In: International Conference on Extreme Programming and Agile Processes in Software Engineering. 2008.

PressmanRoger S.. Engenharia de Software – 7.ed.. AMGH Editora, f. 1006, 2008. 2011 p.

SommervilleIan. Engenharia de software (8a. ed.)., f. 286. 2007. 572 p.

feito

Use agora o Mettzer em todos
os seus trabalhos acadêmicos

Economize 40% do seu tempo de produção científica