• Nenhum resultado encontrado

Funcionalidades de um software aplicado ao gerenciamento de desastres – um mapeamento sistemático

N/A
N/A
Protected

Academic year: 2021

Share "Funcionalidades de um software aplicado ao gerenciamento de desastres – um mapeamento sistemático"

Copied!
24
0
0

Texto

(1)

FUNCIONALIDADES DE UM SOFTWARE APLICADO AO GERENCIAMENTO DE DESASTRES – UM MAPEAMENTO SISTEMÁTICO

FUNCTIONALITIES OF A DISASTER MANAGEMENT SOFTWARE - A SYSTEMATIC MAPPING

Roberto Salviano da Silva*

Resumo

Desastres têm sido cada vez mais frequentes no mundo, atingindo populações residentes de áreas urbanas e rurais e provocando danos de ordem material e imaterial. Com isso, conseguir identificar requisitos no tempo certo para gerenciar tais desastres tem sido uma tarefa cada vez mais difícil e complicada. Como não existe muita informação sobre características dos requisitos aplicados à gestão de desastres, foi proposto um mapeamento sistemático da literatura para encontrar maneiras de identificar os requisitos. Esse mapeamento visa responder essas questões com base na literatura atual, onde percebeu-se que é preciso verificar abordagens para facilitar a comunicação em todas as diferentes etapas do desastre e como é importante que um sistema de apoio à gestão de desastres seja confiável e que as informações disponibilizadas sejam precisas, em suma, os resultados não fornecem características especiais, mas mostram o quão confiável e preciso ela tenha que ser.

Palavras-chave: gestão de desastres, requisitos e mapeamento sistemático. Abstract

Disasters have been often happening in the world, thus affecting urban and agricultural residents and causing material and immaterial damages. Therefore, identifying requirements for managing such disasters has been an increasingly complicated task. As there is not much information about characteristics of the requirements applied to disaster management, a systematic literature mapping was proposed to find ways to identify these requirements. This literature mapping aims to answer these questions based on current literature, where it has been realized that approaches need to be verified to facilitate communication at all different stages of the disaster and how important it is for a disaster management support system to be reliable and to the information provided is accurate, in short, the results do not provide special characteristics, but show how reliable and accurate it has to be.

Keywords: disaster management, requirement and systematic mapping. Aprovado em: 19/12/2019 Versão Final em: 08/01/2020*

*Trabalho de conclusão de curso apresentado ao curso de Bacharelado em Sistemas de Informação da

Universidade Federal Fluminense como requisito parcial para conclusão do curso. Graduando do Curso de Sistemas de Informação-UFF; <robertosalviano@id.uff.br>

(2)

1 INTRODUÇÃO

A intensidade de ocorrência de desastres naturais no mundo tem aumentado nas últimas décadas e tende a continuar aumentando de forma considerável, como consequência de fatores como o aumento populacional e a ocupação do solo, associados ao processo de urbanização e industrialização. Nas áreas rurais, esses fatores se devem a desmatamentos, queimadas, compactação dos solos e assoreamento dos rios. Nas áreas urbanas, se devem à impermeabilização dos solos, adensamento das construções, conservação de calor e poluição do ar (KOBIYAMA et al., 2006).

Segundo Natarajarathinam et al. (2009), os desastres são eventos súbitos e inesperados ou lentos, caracterizados por atingir uma determinada região causando danos econômicos, sociais e ambientais e podendo resultar em mortos e feridos. Por tratar-se de eventos não facilmente administráveis por procedimentos rotineiros, verifica-se a necessidade de atuação conjunta de entidades como, órgãos governamentais, setores privados, agências humanitárias e comunidades, em ações preventivas de regiões vulneráveis a desastres. Os desastres podem ser derivados de causas naturais (inundações, secas, terremotos, furacões e fome) ou podem ser provocados pelo homem (como guerras, conflitos e crise de refugiados), impactando comunidades e nações ao redor do mundo (EM-DAT, 2012).

Nos últimos anos, as organizações voltadas ao desenvolvimento de software têm procurado por melhores práticas em engenharia de requisitos (YOUNG, 2004; WIEGERS, 2006; ROBERTSON; ROBERTSON, 2006; DAVEY; COPE, 2008; TAMAI; KAMATA, 2009; LIU et al., 2010). Essa busca por novas práticas ocorreu porque as organizações perceberam que o êxito no projeto está cada vez mais relacionado a um melhor entendimento dos requisitos (WIEGERS, 2006; ROBERTSON; ROBERTSON, 2006).

Neste sentido, a definição correta dos requisitos é um fator crucial para reduzir custos e riscos no projeto de software (GOTTESDIENER, 2008), pois a falta de um bom trabalho na atividade de elicitação de requisitos leva ao insucesso ou abandono de projetos (DAVEY; COPE, 2008). Problemas na elicitação de requisitos estão relacionados a escopo, compreensão e volatilidade (CHISTEL; KANG, 1992), esses problemas são decorrentes da dificuldade em se extrair ou identificar as necessidades de seus usuários (HOOD et al., 2008).

Nesse contexto, o presente artigo apresenta um mapeamento sistemático de literatura (MSL) sobre como identificar requisitos aplicados a gestão de desastre, buscando na base IEEE Xplore, estudos que respondessem três questões de pesquisas: “Como identificar os requisitos aplicados à gestão de desastres/emergências?”, “Quais são as características dos

(3)

requisitos aplicados à gestão de desastres?” e “Quais funcionalidades os softwares sobre gestão de desastres precisam ter?”. Essas análises obtidas a partir do mapeamento podem ser usadas como parâmetro para identificação de oportunidades de estudos e pesquisas, contribuindo para trabalhos futuros.

Este trabalho está dividido da seguinte maneira: No capítulo 2, está a fundamentação teórica sobre a gestão de desastres e a engenharia de requisitos. No capítulo 3, estão os detalhes de como o mapeamento sistemático foi usado neste estudo. O capítulo 4, apresenta os resultados e discussões provenientes do MSL e no capítulo 5, apresenta as conclusões do trabalho e possíveis recomendações para estudos futuros.

2 REFERENCIAL TEÓRICO

Nesta seção falaremos sobre a gestão de desastres, seus conceitos e todo o seu processo e a engenharia de requisitos, o que é a engenharia de requisitos e suas definições. 2.1 GESTÃO DE DESASTRES

Os desastres podem ser classificados em naturais ou causados pelo homem e podem ser repentinos (como terremotos, tsunamis, ataques terroristas e vazamentos de óleo) ou perenes (como fome, estiagem, pobreza ou crises políticas e de refugiados) (VAN WASSENHOVE, 2006).

Segundo o Escritório das Nações Unidas para a Redução de Desastres (UNISDR) e o Centro de Pesquisas de Epidemiologia em Desastres (CRED), o Brasil é o único país das Américas que está na lista dos 10 países com maior número de pessoas afetadas entre os anos de 1995 e 2015 (ONU, 2015). Nas últimas duas décadas, 51 milhões de brasileiros foram impactados por catástrofes. Estados Unidos, China, Índia, Filipinas e Indonésia aparecem como os cinco países com maior número de desastres relacionados ao clima durante esse período (ONU, 2015).

Em uma escala global, cerca de três quartos da população do planeta vivem em áreas afetadas por desastres (terremotos, ciclones tropicais, inundações, seca, dentre outros). Dessa fração, 85% das pessoas expostas a desastres de origem natural vivem em países de médio a baixo desenvolvimento. Por tratar-se de fenômenos complexos, muitas vezes imprevisíveis e não antecipados, torna-se mais desafiador e complicado conseguir efetuar a redução de seus danos (HUALOU, 2011). Assim, apesar de não podermos prevenir os seus impactos de forma

(4)

precisa, gerenciando seu processo poderemos minimizar o impacto negativo causado em meio ao desastre (DIIRR, 2016).

O desastre afeta negativamente o desenvolvimento e consequentemente o crescimento econômico, na medida em que causa perda de vidas humanas, danos às pessoas, destruição total ou parcial a moradias, fontes de sustento, de subsistência, a infraestrutura produtiva e de serviços, e meio ambiente, entre outros (LOPES, 2017).

Podemos considerar as seguintes fases (Figura 2.1.1) para gerenciamento de desastre:

Figura 2.1.1: Fases para gerenciamento de desastres (DIIRR, 2016)

Pré-desastre: Inicia antes da ocorrência de um desastre. São desenvolvidas ações a fim de contribuir para as reduções dos riscos. As equipes de planejamento começam a criar ações de longo prazo, de forma a evitar a ocorrência de grandes desastres, e a obtenção de equipamentos e recursos financeiros necessários para o seu desenvolvimento. Essas equipes são responsáveis por identificar e priorizar os riscos evidenciados. Como os recursos disponibilizados para o desastre são limitados, surge daí a necessidade de filtrar e priorizar os riscos identificados. (HADDOW et al., 2011; KHAN et al., 2008; PENADÉS et al., 2011).

Resposta: Esta fase compreende atividades de treinamento, que tem como objetivo avaliar como os recursos, procedimentos e equipes planejados devem responder às situações de desastre. São tomadas medidas para reduzir os efeitos negativos a fim de não evoluir para uma fase crítica. Também compreende uma fase de alerta com ações preventivas como, por exemplo, cobertura de janela em furacões, ativações de sirenes em áreas de risco durante tempestade, interdição de estradas em caso de chuva de tempestade, etc. E

(5)

quando a emergência evolui para uma situação mais crítica, a resposta vem de imediato. Há o envolvimento de organizações governamentais, organizações não-governamentais, setor privado e sociedade. (HADDOW et al., 2011; PADILHA et al., 2010).

Pós-desastre: Inicia quando a equipe de resposta se propõe a recuperar o que foi afetado, analisando as condições que possuía antes da ocorrência do desastre e avaliar as ações tomadas durante a resposta, tomando ações para a recuperação e o replanejamento. (HADDOW et al., 2011; KHAN et al., 2008; PENADÉS et al., 2011). Não é possível afirmar o tempo necessário para a recuperação de um desastre, vide que pode levar apenas semanas, ou perdurar por diversos meses e até anos, como podemos observar no exemplo de Mariana, o maior desastre natural do Brasil, que ocorreu em 2011 e, até hoje, podemos verificar seus danos e seu processo de recuperação. Ao término do desastre é efetuado o replanejamento onde a equipe tem o objetivo de identificar as possibilidades de melhoria em emergências semelhantes futuras. 2.2 ENGENHARIA DE REQUISITOS

De acordo com Sommerville (2007), a engenharia de requisitos tem como objetivo definir o que o sistema deve fazer, quais as necessidades reais do usuário e identificar quais são limitações que existem para que o software seja desenvolvido. Ela engloba todas as atividades relacionadas à descoberta, documentação e manutenção do conjunto de requisitos de um sistema (KOTONIA e SOMMERVILLE, 1998).

A norma IEEE 24765(IEEE, 1990), define os requisitos como:

1) Uma condição ou capacidade necessária por um usuário para resolver um problema ou atingir objetivos;

2) Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto;

3) Uma documentação que represente uma condição ou capacidade como em (1) ou (2).

Os requisitos de software são classificados em funcionais, não funcionais e de domínio. Os requisitos funcionais descrevem o que o software deve fazer, quais serviços devem fornecer ao usuário e como deve reagir a entradas específicas (SOMMERVILLE, 2007). Qualquer ação ou verbo ativo são considerados requisitos funcionais, como por

(6)

exemplo, calcular, inspecionar, publicar, processar, imprimir, listar e etc. (ROBERTSON e ROBERTSON, 2006)

Já os requisitos não funcionais não estão ligados diretamente às funcionalidades do software e sim às restrições sobre os serviços e funções oferecidas por ele. Eles especificam o comportamento do produto, são derivados de políticas e procedimentos da organização do cliente e do desenvolvedor e também são derivados de fatores externos ao software e seu processo de desenvolvimento (SOMMERVILLE, 2007). Ou seja, são descrições ou atribuições de qualidade que o sistema deve possuir (ROBERTSON e ROBERTSON, 2006). São exemplos requisitos ligados à segurança, desempenho, usabilidade, portabilidade e etc.

Os requisitos de domínio são derivados do domínio da aplicação e usam terminologia específica. Podem ser novos requisitos funcionais, podem restringir os requisitos funcionais existentes ou estabelecer como cálculos específicos devem ser realizados. Esses requisitos são muito importantes por refletirem os fundamentos do domínio da aplicação (SOMMERVILLE, 2007). A diferença entre esse tipo de requisito e os requisitos funcionais e os não funcionais, é que requisitos de domínio normalmente têm uma existência fora dos limites de qualquer sistema de software (WIEGERS, 2006). Isso quer dizer que, uma regra de negócio não é propriamente um requisito de domínio, ela existe independentemente de um sistema computacional, e muitas vezes ela será aplicada para garantir que o sistema imponha esta regra.

3 MATERIAS E MÉTODOS

Para poder responder as questões de pesquisas levantadas é necessário fazer um levantamento bibliográfico. Pode-se fazer um levantamento de forma ad hoc, onde não se segue nenhum processo prévio ou um processo formal e sistemático, onde temos todo um processo a ser seguindo, como a definição de um protocolo, definição de questões de pesquisa, etc.

O principal método de síntese é uma revisão sistemática da literatura (RSL). Em contraste com uma revisão especializada usando seleção ad hoc da literatura, uma RSL é uma revisão metodologicamente rigorosa dos resultados da pesquisa. O objetivo de uma RSL não é apenas agregar todas as evidências existentes em uma questão de pesquisa mas também se destinar a apoiar o desenvolvimento de diretrizes baseadas em evidências para os profissionais (KITCHENHAM; CHARTERS, 2007; PETERSEN et al., 2015).

(7)

O Mapeamento Sistemático da Literatura (MSL) e a Revisão Sistemática da Literatura (RSL) são tipos de estudos secundários que seguem um processo de pesquisa metodologicamente bem definido para identificar, analisar e interpretar as evidências disponíveis relacionadas a um conjunto de questões de pesquisa, tópico ou fenômeno de interesse, de uma maneira não tendenciosa e, até certo grau, repetível (KITCHENHAM; CHARTERS, 2007; PETERSEN et al., 2015).

Optamos pelo mapeamento sistemático, que é um procedimento formal para revisão da literatura, por prover uma visão mais ampla do tópico de pesquisa e por ajudar a identificar lacunas na presente pesquisa e que são capazes de sugerir pesquisas futuras e prover um guia para posicionar adequadamente novas atividades de pesquisa

Nesta seção falaremos sobre o processo usado para o Mapeamento Sistemático da Literatura (MSL) proposta e apresentar a MSL executada para a presente pesquisa.

3.1 MAPEAMENTO SISTEMÁTICO DA LITERATURA (MSL)

Um Mapeamento Sistemático da Literatura (MSL) tem como objetivo identificar e classificar, com uma visão mais ampla, dado tópico de pesquisa de modo a estabelecer se há evidência de pesquisa nesse tópico (KITCHENHAM; CHARTERS, 2007; PETERSEN et al., 2015). Já, uma Revisão Sistemática da Literatura (RSL) tem como objetivo identificar, selecionar, avaliar, interpretar e sumarizar estudos disponíveis considerados relevantes para um tópico de pesquisa ou fenômeno de interesse, fazendo uso de uma metodologia de revisão que seja confiável, rigorosa e que permita auditagem (KITCHENHAM et al., 2004; BIOLCHINI et al., 2005).

Uma das principais diferenças entre MSL e RSL está no escopo e nos procedimentos de análise. O escopo de uma MSL é geralmente mais amplo e a análise e síntese mais superficiais do que em uma RSL (WHOLIN et al., 2013). Com isso, a estratégia de busca deve ser menos restritiva, de modo permitir recuperar mais estudos (KITCHENHAM et al., 2011; PETERSEN et al., 2015). Assim, de maneira geral, MSLs envolvem mais trabalhos, a serem analisados mais superficialmente, enquanto RSLs envolvem menos trabalhos, mas que devem ser analisados com maior profundidade.

Vale a pena destacar que MSLs e RSLs são abordagens complementares. Primeiro, um MSL pode ser conduzido, visando prover uma visão geral de um tópico de pesquisa. Ele pode identificar grupos (clusters) de estudos que são adequados para estudos mais detalhados e aprofundados, os quais podem ser feitos por meio de RSLs (KITCHENHAM et al., 2011; PETERSEN et al., 2015).

(8)

O processo de condução da RSL/MSL é realizado por meio de um processo composto por uma sequência de fases bem definidas, envolvendo três etapas: o Planejamento, a Execução e a Análise dos Resultados (BIOLCHINI et al. 2005), apresentando desta forma uma avaliação justa e rigorosa sobre um determinado tópico de pesquisa, conforme figura 3.1.1.

Figura 3.1.1-Processo do Mapeamento Sistemático

Durante a etapa de Planejamento, os objetivos da pesquisa são definidos e é criado o protocolo, que é o elemento essencial para sua execução e tem como objetivo reduzir a possibilidade da ocorrência de vieses (KITCHENHAM et al., 2004). Esta fase contém itens como a seleção de fontes, métodos de busca e palavras-chave, critérios de inclusão, exclusão, qualidade dos estudos primários e como serão sintetizados (BIOLCHINI et al. 2005), de forma que outros pesquisadores possam reproduzir a RSL/MSL usando tal protocolo.

A etapa de Execução tem como objetivo a obtenção e análise dos estudos primários, os estudos são identificados, coletados e organizados em uma lista. Então os critérios de inclusão e exclusão definidos no protocolo são aplicados nos estudos da lista em duas etapas, inicialmente por meio da leitura do título, resumo e conclusões, seguido pela leitura do texto completo. Ao final dessa atividade, as informações são extraídas dos estudos identificados como incluídos (FELIZARDO et al., 2003; LIMA et al., 2012).

A última fase do processo, que é a etapa de Análise dos Resultados, os resultados dos estudos primários que atendem ao propósito da revisão são sintetizados. Essa síntese pode ser descritiva, mas um sumário quantitativo obtido por meio de um cálculo estatístico pode complementar a descrição (SANTOS et al., 2018).

3.2 MSL SOBRE AS CARACTERÍSTICAS EM GESTÃO DE DESASTRES

O aumento do número de desastres que estão acontecendo nos últimos anos e as dificuldades que se enfrenta para fazer o levantamento de requisitos de forma precisa e assertiva, mostra a necessidade de investigar e entender as características dos requisitos

(9)

aplicados em gestão de desastres. Além disso, os requisitos precisam ser definidos de maneira rápida e, como não há muito tempo para escrevê-los de maneira estruturada, existe a necessidade de se realizar um estudo para entender essas características e como colaborar na construção de um sistema que seja útil, confiável e que possa, de alguma forma, prevenir e minimizar o impacto negativo causado em meio aos desastres.

Assim, o primeiro passo foi a definição do protocolo da revisão, bem como a elaboração das questões de pesquisas relacionadas ao objetivo deste MSL. Levantamos três questões de pesquisa:

QP1: Como identificar os requisitos aplicados à gestão de desastres/emergências?

QP2: Quais são as características dos requisitos aplicados à gestão de desastres?

QP3: Quais funcionalidades os softwares sobre gestão de desastres precisam ter?

A abordagem PICO (Population, Intervention, Comparison, Outcome) foi utilizada para derivar os termos para a busca nas bases de dados (FELIZARDO et al, 2003). Além da Medicina, esta abordagem também é muito utilizada pela Engenharia de Software. A abordagem PICO é considerada adequada se a mesma pode ser estruturada em:

 População (P): grupo da população que será observada pela intervenção;

 Intervenção (I): Normalmente, na medicina, é uma comparação entre tratamentos alternativos, pode indicar qual o fator prognóstico e o que se pretende fazer parta o paciente. No caso da Engenharia de Software, seriam os métodos, procedimentos ou tecnologias que serão estudados;

 Comparação (C): Procura mencionar as principais alternativas para comparar com a intervenção. Em alguns casos, esse critério pode ser omitido, pois nem sempre é necessário haver uma comparação específica.

 Resultados (O): Fatores considerados importantes para caracterizar o que está sendo investigado.

Assim, para o presente MSL, como população foram utilizados: gestão de desastres (disaster management) e gestão de emergências (emergency management). Como intervenção foram utilizados: requisitos (requirement) e funcionalidades (functionalities). Comparação não foi utilizado na busca, por não ser necessário neste cenário. E como resultados, foi

(10)

utilizado características (characteristics), elementos (elements), particularidades (particularities), demanda (demands), exigência (exigency) e desafios (challenges).

Dessa forma, com o uso de conectores OR e AND, foi definida a string de busca para ser usada nas pesquisas junto às bases de dados:

(("disaster management" OR "emergency management") AND (requirement OR functionalities) AND (characteristics OR elements OR particularity OR demand OR exigency OR challenges))

A base escolhida para realizar as buscas foi a IEEEXplore (http://ieeexplore.ieee.org), por se tratar de um poderoso recurso para acesso de conteúdos científicos e de autores relevantes para fim de estudos.

Os critérios utilizados para a inclusão dos estudos (CI) foram:

 CI1: Podem ser selecionadas publicações que tratem das características dos requisitos em gestão de desastres/emergências;

 CI2: Podem ser selecionados publicações que tragam os desafios de requisitos em gestão de desastres/emergências;

 CI3: Podem ser selecionados publicações que descrevam abordagens, estratégias, práticas que possam auxiliar na obtenção de requisitos;

 CI4: Podem ser selecionados publicações que descrevam requisitos de um sistema de desastres específico.

Os critérios para exclusão de estudos (CE) foram:

 CE1: Não serão selecionadas publicações em que as palavras-chave da busca não apareçam no título, resumo e/ou texto da publicação (exclui-se daí o campo “palavra-chave”, as seções agradecimentos, biografia dos autores, referências bibliográficas e anexos) e não há variações destas palavras-chave (exceto plural).

 CE2: Não serão selecionadas publicações em que o contexto não trate de desastres;

 CE3: Não serão selecionadas publicações em que o contexto não trate de requisitos de software;

 CE4: Não serão selecionados artigos similares (mesmo autor e temática semelhante) a outros artigos encontrados.

(11)

O processo de seleção dos estudos primários teve como passo inicial a busca na base selecionada. Os resultados dessas buscas foram importados e trabalhados na StArt†, ferramenta desenvolvida pelo Laboratório de Pesquisa em Engenharia de Software (LAPES) da Universidade Federal de São Carlos (UFSCar), que visa apoiar o planejamento e execução de MSLs/RSLs. Após as buscas, o próximo passo foi a primeira seleção dos estudos, realizado através da leitura dos títulos, resumos e palavras-chave, conforme figura 3.2.1, sendo sinalizados na ferramenta StArt* quais são os estudos não relevantes após cada fase.

Esses estudos foram lidos por todos os envolvidos no MSL e, quando conflitos foram identificados (selecionado por uma pessoa e rejeitado por outra), relemos o abstract e, se o conflito se mantivesse, foi necessário ler a introdução e conclusão do artigo para a tomada da decisão. Os estudos que passaram pela primeira seleção foram submetidos a uma nova seleção, onde foram lidos na íntegra, conforme figura 3.2.2. A Tabela 3.1 resume os quantitativos de estudos resultantes após cada uma das fases:

Figura 3.2.1-Quantidade de artigos aceitos e rejeitados, após a extração dos estudos

Figura 3.2.2-Quantidade de artigos aceitos e rejeitados, após a leitura completa dos estudos

Tabela 3.1: Retorno das buscas e análises dos estudos.

DADOS DO RETORNO DAS BUSCAS E ANÁLISES DOS RESULTADOS

Retorno das Buscas 257 estudos

Após a remoção dos duplicados 255 estudos

Lidos títulos, resumos e palavras chaves 255 estudos

Estudos selecionados por meio da leitura dos títulos, resumos e palavras-chave

23 estudos

Leitura completa dos estudos 23 estudos

Estudos aceitos após leitura completa 9 estudos

Estudos rejeitados após leitura completa 14

Os Apêndices A e B trazem a lista dos estudos aceitos após leitura completa e rejeitados após leitura completa, respectivamente.

(12)

4 RESULTADOS E DISCUSSÕES

Nesta seção apresentaremos os resultados obtidos da análise de 23 artigos selecionados. A pesquisa foi realizada em novembro de 2019, obtendo estudos compreendidos entre 2002 e 2018, conforme gráfico 4.1.

Gráfico 4.1: Frequência de estudos por ano de publicação

Como não era previsto filtrar os estudos por ano de publicação, foram obtidos estudos dentro de um período de aproximadamente 17 anos, o que, em termos de tecnologia, é um tempo considerável para mudanças e aprendizados. Para as respostas às questões de pesquisa, somente foram considerados 9 estudos, nos quais foi exposto pelos autores sobre o conhecimento e as características sobre a gestão de desastre, os demais estudos foram excluídos pelos critérios de exclusão, conforme gráfico 4.2.

(13)

4.1 RESPOSTAS ÀS QUESTÕES DE PESQUISA

QP1: Como identificar os requisitos aplicados à gestão de desastres/emergências? Com base nos estudos, não conseguimos encontrar maneiras específicas de como identificar os requisitos aplicados à gestão de desastres. Entretanto os estudos relatam que é necessário verificar abordagens para facilitar o intercâmbio de informações e comunicações em todas as diferentes etapas e operações e que é preciso verificar que tipos de informações e parâmetros estão constantemente sendo monitorados, bem como a frequência que são atualizados investigar a importância de fatores como confiabilidade, taxa de confidencialidade, natureza atualizada e a extensão das informações disponíveis.

QP2: Quais são as características dos requisitos aplicados à gestão de desastres? Com base nos estudos selecionados, não foi identificado nenhuma característica que fosse específica para um sistema de gestão de desastres, pois geração de relatórios, comunicação entre usuários, alertas, etc., são características aplicadas em qualquer tipo de sistema, não sendo apenas sobre desastre.

QP3: Quais funcionalidades o software sobre gestão de desastres precisa ter?

RF1. Emitir Alerta – Permite emitir alertas para a população sobre perigos e potenciais eventos indesejáveis através de servidores SMS ou meios de comunicação (BENSSAM et al., 2014; LEPPÄNIEMI et al., 2009).

RF2. Analisar Riscos – Permite analisar violações de atualizações periódicas de dados relacionados a diferentes riscos, como riscos de cartografia de cada localidade, atividades de preparação sazonal (BENSSAM et al., 2014).

RF3. Verificar Riscos - Permite verificar violações de atualizações periódicas de dados relacionados a diferentes riscos, como riscos de cartografia de cada localidade, atividades de preparação sazonal (BENSSAM et al., 2014).

RF4. Realizar backup de dados – Permite realizar um backup contra a perda de dados do processo de desastre (BENSSAM et al., 2014).

RF5. Coletar Informações sobre o desastre – Permite coletar informações entre comunidades e organizações envolvidas no processo de desastre (BENSSAM et al., 2014).

RF6. Processar Informações sobre o desastre – Permite processar informações entre comunidades e organizações envolvidas no processo de desastre (BENSSAM et al., 2014).

(14)

RF7. Compartilhar informações sobre o desastre – Permite compartilhar informações entre comunidades e organizações envolvidas no processo de desastre (BENSSAM et al., 2014).

RF8. Realizar fusão de dados – Permite apoiar o processo na recuperação de desastre, utilizando os dados antes da ocorrência, junto com os dados após a ocorrência do desastre.

RF9. Consultar fusão de dados – Permite consultar as informações após a fusão dos dados (SINGH, V. K.; 2011).

Os requisitos RF1, RF2 e RF3 correspondem as funcionalidades necessárias para a fase de preparação. Para a fase de resposta são necessários os requisitos RF4, RF5, RF6 e RF7. E para a fase de recuperação de desastres, o software precisa ter as funcionalidades descritas nos requisitos RF8 e RF9.

4.2 DISCUSSÃO

Os estudos não foram claros e objetivos no sentido de responderem as questões solicitadas. Não foram encontrados trabalhos que discutam de maneira clara quais são as funcionalidades que o software aplicado a gestão de desastre precisa ter.

A comunicação entre os envolvidos foi a principal característica encontrada na maioria dos estudos selecionados. Eles dissertam que para conseguir gerir um desastre, saber do ocorrido, dos fatos verídicos, saber onde as pessoas que se encontram na situação do desastre se encontram, conseguir se comunicar com as pessoas que estejam apoiando ao resgate, enfim, todo o tipo de comunicação é primordial para poder conseguir gerir um desastre.

Muitos estudos também falaram sobre as características dos requisitos não funcionais de um software aplicado a gestão de desastres. Um dos requisitos mais citados foram: interoperabilidade, disponibilidade e escalabilidade. Segundo alguns estudos, esses três requisitos não funcionais são primordiais para facilitar o planejamento estratégico, operacional e tático do software.

Alguns estudos abordados sugeriam o uso de softwares próprios e como esses softwares foram criados. Alguns deles dissertavam sobre a abordagem arquitetônica para integrar sistemas do tipo SOA e muitos deles falavam sobre tecnologias que eles mesmos criaram, apresentando conceitos, a estratégia de design e testes relacionados.

(15)

Com isso se chegou à conclusão que identificar requisitos aplicados à desastre não é uma tarefa fácil, muito pelo contrário, conseguir identificar quais são estes requisitos é uma tarefa difícil e complexa.

5 CONCLUSÃO

O principal objetivo desse trabalho foi compreender, através de um Mapeamento Sistemático da Literatura, as características dos requisitos aplicados à gestão de desastres e maneiras de realizar a identificação destas características.

O mapeamento foi feito dentro dos parâmetros do protocolo (tratado no capítulo 3), obtendo um total de nove estudos relevantes ao tema da pesquisa. A extração dos dados foi feita visando responder às questões de pesquisas propostas, porém, nem todos os estudos conseguiam respondê-las de maneira clara.

É possível perceber, com esse mapeamento, que ainda não foram abordadas maneiras de se identificar requisitos aplicados à gestão de desastres de forma clara e assertiva, pois não foi possível responder de forma clara duas das questões propostas mas foi possível perceber que o quão é importante a disseminação de informações precisas em todo o processo de gerenciamento de desastres e como o software precisa ser preciso e confiável em toda sua informação. Com isso, se chega à conclusão de que ainda há muito que se explorar no contexto de identificação e levantamento de requisitos aplicados a gestão de desastres, pois como se trata de um meio complexo e como não há muito tempo para se fazer esse levantamento, necessita-se cada vez mais de recursos para poder facilitar a identificação destes requisitos.

Uma ameaça a validade é o uso de apenas uma base, por isso, como sugestão para trabalho futuro, pesquisas em outras bases, realização de snowballing, que consiste na análise das referências contidas em cada estudo selecionado, bem como na análise dos estudos que citam os mesmos. Esse processo é usado, recursivamente, a fim de obter novos estudos que, por algum motivo, possam não ter sido retornados pelas buscas (WHOLIN, 2014), automatizar a identificação dos requisitos relacionados à comunicação e confidencialidade, reuso de requisitos, dariam respostas mais precisas acerca da identificação e características aplicadas a gestão de desastres.

(16)

REFERÊNCIAS

BENSSAM, A.; NOUALI-TABOUDJEMAT, N.; NOUALI, O. Requirements for an IT Based Platform for Disaster Management, 1st International Conference on Information and Communication Technologies for Disaster Management (ICT-DM), 2014

BIOLCHINI, J.; MIAN, P.G.; NATALI, A.C.C.; TRAVASSOS, G.H. Systematic Review in Software Engineering, Programa de Engenharia de Sistemas e Computação, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005

CHRISTEL, M. G., KANG, K. C. Issues in Requirements Elicitation, Technical Report Software Engineering Institute CMU/SEI-92-TR-12.7, September 1992. Disponível em:http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf. Acessado em 15 de dez. de 2019.

DAVEY, B; COPE, C. Requirements Elicitation – What’s Missing?, Issues in Informing Science and Information Technology, Issues in Informing Science and Information Technology Volume 5, 2008

DIMITROV, V.; VAZQUEZ, J.; PADIR, T. LocATER: Localization and Accountability Technologies for Emergency Responders, IEEE International Symposium on Technologies for Homeland Security (HST), 2017

DIIRR, B. G. S. Support for Plan Adaptation in Unforeseen Complex Situations, Programa de Pós Graduação em Informática – Universidade Federal do Rio de Janeiro, 2016 EM-DAT - Emergency Events Database. What’s new. Disponível em:<www.emdat.be/>. Acesso em 16 de dez. de 2019.

FELIZARDO, K. R.; NAKAGAWA, E. Y.; FABBRI, S. C. P. F.; FERRARI, F. C. Revisão Sistemática da Literatura em Engenharia De Software - Teoria e Prática, 1ª Edição. Rio de Janeiro: Elsevier, 2003

GOTTESDIENER, E. Good Practices for Developing User Requirements, Crosstalk - The Journal of Defense Software Engineering, March, 2008

HADDOW, G.; BULLOCK, J.; COPPOLA, D. Introduction to Emergency Management. 4. ed. Burlington: Butterworth Heinemann, 2011.

HOOD, C., WIEDEMANN, S., FICHTINGER, S., PAUTZ, U. Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes. Springer-Verlag Berlin Heidelberg, 2008. ISBN 978-3-540-47689-4

HUALOU, L. Disaster Prevention and Management: A Geographical Perspective, Our editor from Institute of Geographic Sciences and Natural Resources Research, Chinese Academy of Sciences, Beijing 100101, CHINA, 2011

(17)

HUANG, Y.; HE, W.; NAHRSTEDT, K.; LEE, W. C. Requirements and System Architecture Design Consideration for First Responder Systems, IEEE Conference on Technologies for Homeland Security, 2007

IEEE, IEEE standard Glossary of Software Engineering Terminology. IEE Standard, New York, 1990

KHAN, H.; VASILESCU, L.; KHAN, A. Disaster Management Cycle: A Theoretical Approach. Management and Marketing Journal, [S.l.], v. 6, n. 1, p. 43-50, 2008.

KITCHENHAM, B.A., BRERETON, O.P., BUDGEN, D., Using Mapping Studies as the Basis for Further Research – A Participant-Observer Case Study. Information and Software Technology, vol. 53, 2011.

KITCHENHAM, B.A., CHARTERS, S., Guidelines for Performing Systematic Literature Reviews in Software Engineering, EBSE 2007-001. Keele University and Durham University Joint Report, 2007.

KOBIYAMA, M. M., M. D. A. MORENO e PENA, I., Prevenção de desastres naturais: conceitos básicos, Florianópolis: Ed. Organic Trading. 109p., 2006

KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and Techniques, Editora John Wiley and Sons, 1998

LEPPÄNIEMI, J.; LINNA, P.; SOINI, J.; JAAKKOLA, H. Toward a Flexible Service-Oriented Reference Architecture for Situational Awareness Systems in Distributed Disaster Knowledge Management, PICMET '09 - 2009 Portland International Conference on Management of Engineering Technology, 2009

LICHTENEGGER, G.; VORRABER, W.; GOJMERAC, I.; SPORER, A.; BRUGGER, J.; EXNER, E.; ASCHBACHER, H.; CHRISTIAN, M.; VOESSNER, S. Identification of Information Gaps in Civil-Military Cooperation in Disaster Management, 2nd International Conference on Information and Communication Technologies for Disaster Management (ICT-DM), 2015

LIMA, M. M.; LIMA, A. R.; MONTEIRO, A. C. C.; JUNIOR, E. H. C.; GOMES, L. Q. L. Uma Revisão Sistemática da Literatura dos Processos de Desenvolvimento de Software Educativo, 2012

LOPES, I. T. P., Gestâo de Riscos de Desastres: Integrando os Riscos de Acidentes Industriais à Gestão Territorial, Dissertação (Mestrado) – UFRJ/ COPPE/ Programa de Planejamento Energético, 2017

LYNHAM, T. J.; DULL, C. W.; SINGH, A. Requirements for Space-based Observations in Fire Management: A report by the Wildland Fire Hazard Team, Committee on Earth Observation Satellites (CEOS) Disaster Management Support Group (DMSG), IEEE International Geoscience and Remote Sensing Symposium, 2002

LIU, L., LI, T., PENG, F. Why Requirements Engineering Fails: A Survey Report from China, Requirements Engineering Conference (RE), 2010 18th IEEE International, 2010

(18)

NATARAJARATHINAM, M., CAPAR, I., NARAYANAN. A., Managing Supply Chains in Times of Crisis: A Review of Literature and Insights, 2009. International Journal of Physical Distribution and Logistics Management. p. 535–573. DOI: 10.1108/09600030910996251.

ONU: Brasil está entre os 10 países com maior número de afetados por desastres nos últimos 20 anos. Nações Unidas Brasil, Brasil, 25 de jun. de 2015. Disponível em: <https://nacoesunidas.org/onu-brasil-esta-entre-os-10-paises-com-maior-numero-de-afetados-por-desastres-nos-ultimos-20-anos/>. Acesso em 14 de nov. de 2019.

PADILHA, R.; BORGES, M.; GOMES, J. O.; CANÓS, J. The Design of Collaboration Support Between Command and Operation Teams During Emergency Response. In: INTERNATIONAL CONFERENCE ON COMPUTER SUPPORTED COOPERATIVE WORK IN DESIGN, 14., 2010, Shanghai. Proceedings... New York: IEEE, 2010. p. 759-763. PENADÉS, M. C.; BORGES, M.; VIVACQUA, A.; CANÓS, J.; SOLIS, C. Collaborative refinement of emergency plans through public engagement. In: INTERNATIONAL

CONFERENCE ON COLLABORATIVE COMPUTING: NETWORKING,

APPLICATIONS AND WORKSHARING, 7., 2011, Orlando. Proceedings... New York: IEEE, 2011. p. 524-527.

PETERSEN, K.; VAKKALANKA, S.; KUZNIARZ, L. Guidelines for Conducting Systematic Mapping Studies in Software Engineering: An Update, Elsevier Volume 64, August 2015, Pages 1-18, 2015

ROBERTSON, S. ROBERTSON, J. Mastering the Requirements Process, Second Edition. Addision Wesley Professional, 2006

SANTOS, L. C.; LUGÃO, M. L. S. Levantamento sobre o Apoio das Ferramentas de Colaboração em Equipes que Adotam Métodos Ágeis – Uma Revisão Sistemática da Literatura – Monografia – Universidade Federal Fluminense, 2018

SIMONETTE, M. J.; Engenharia de Sistemas em Sistemas Sociotécnicos, Dissertação (Mestrado) - Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Computação e Sistemas Digitais, 2010

SINGH, V. K.; MODANWAL, N.; BASAK, S. MAS Coordination Strategies and their Application in Disaster Management Domain, 2nd International Conference on Intelligent Agent Multi-Agent Systems, 2011

SOMMERVILLE, I. Software Engineering, 8ª edição. São Paulo: Pearson Addison Wesley, 2007

SURI, N.; ZIELINSKI, Z.; TORTONESI, M.; FUCHS, C.; PRADHAN, M.; WRONA, K.; FURTAK, J.; VASILACHE, D. B.; STREET, M.; PELLEGRINI, V.; BENINCASA, G.; MORELLI, A.; STEFANELLI, C.; CASINI, E.; DYK, M. Exploiting Smart City IoT for Disaster Recovery Operations, IEEE 4th World Forum on Internet of Things (WF-IoT), 2018

(19)

TAMAI, T., KAMATA, M. L. Impact of Requirements Quality on Project Success or Failure, Design Requirements Engineering: A Ten-Year Persperctive, Lecture Notes in Business Information Processing, 14, 258-275, 2009

VAN WASSENHOVE, L.V., Blackett Memorial Lecture Humanitarian aid logistics: supply chain management in high gear, Journal of the Operational Research Society (2006) 57, 475–48, 2006

WIEGERS, K. E. More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, ISBN: 0735622671, 2006

WHOLIN, C. Guidelines for Snowballing in Sistematic Literature Studies and a Replication in Software Engineering. 18th International Conference on Evaluation and Assessment in Software Engineering (EASE 2014) – London, England, 2014.

WOHLIN, C., RUNESON, P., SILVEIRA NETO, P.A.M., ENGSTRÖM, E., MACHADO, I.C., ALMEIDA, E.A., On the Reliability of Mapping Studies in Software Engineering, Journal of Systems and Software, 2013

(20)

APÊNDICE A – Estudos Selecionados Incluídos

ESI01 - BENSSAM, A.; NOUALI-TABOUDJEMAT, N.; NOUALI, O. Requirements for an IT Based Platform for Disaster Management, 1st International Conference on Information and Communication Technologies for Disaster Management (ICT-DM), 2014 ESI02 - DIMITROV, V.; VAZQUEZ, J.; PADIR, T. LocATER: Localization and Accountability Technologies for Emergency Responders, IEEE International Symposium on Technologies for Homeland Security (HST), 2017

ESI03 - HUANG, Y.; HE, W.; NAHRSTEDT, K.; LEE, W. C. Requirements and System Architecture Design Consideration for First Responder Systems, IEEE Conference on Technologies for Homeland Security, 2007

ESI04 - LEPPÄNIEMI, J.; LINNA, P.; SOINI, J.; JAAKKOLA, H. Toward a Flexible Service-Oriented Reference Architecture for Situational Awareness Systems in Distributed Disaster Knowledge Management, PICMET '09 - 2009 Portland International Conference on Management of Engineering Technology, 2009

ESI05 - LICHTENEGGER, G.; VORRABER, W.; GOJMERAC, I.; SPORER, A.; BRUGGER, J.; EXNER, E.; ASCHBACHER, H.; CHRISTIAN, M.; VOESSNER, S. Identification of Information Gaps in Civil-Military Cooperation in Disaster Management, 2nd International Conference on Information and Communication Technologies for Disaster Management (ICT-DM), 2015

ESI06 - LYNHAM, T. J.; DULL, C. W.; SINGH, A. Requirements for Space-based Observations in Fire Management: A Report by the Wildland Fire Hazard Team, Committee on Earth Observation Satellites (CEOS) Disaster Management Support Group (DMSG), IEEE International Geoscience and Remote Sensing Symposium, 2002 ESI07 - SINGH, V. K.; MODANWAL, N.; BASAK, S. MAS Coordination Strategies and their Application in Disaster Management Domain, 2nd International Conference on Intelligent Agent Multi-Agent Systems, 2011

ESI08 - SURI, N.; ZIELINSKI, Z.; TORTONESI, M.; FUCHS, C.; PRADHAN, M.; WRONA, K.; FURTAK, J.; VASILACHE, D. B.; STREET, M.; PELLEGRINI, V.; BENINCASA, G.; MORELLI, A.; STEFANELLI, C.; CASINI, E.; DYK, M. Exploiting Smart City IoT for Disaster Recovery Operations, IEEE 4th World Forum on Internet of Things (WF-IoT), 2018

ESI09 - WANG, F.; WEN, R.; ZHONG, S. Key Issues in Mapping Technologies for Disaster Management, 2nd International Conference on Information Engineering and Computer Science, 2010

(21)

APÊNDICE B – Estudos Selecionados Excluídos

ESE01 - BALOGH, Z.; GATIAL, E.; HLUCHY, L. Use of Polls to Seamlessly Collect and Aggregate Semi-Structured Information For Crisis Response, IEEE 13th International Symposium on Intelligent Systems and Informatics (SISY), 2015

ESE02 - BASAK, S.; MAZUMDAR, D. On Agent Mediated Coordination Strategies and its Application in Disaster Management System, 1st International Conference on Recent Advances in Information Technology (RAIT), 2012

ESE03 - CHAVES, J. M.; DONNER, A.; TANG, C.; ADLER, C.; KRUSMANN, M.; VIA ESTREAM, À.; GREINER-MAI, T. An Interdisciplinary Approach to Designing a Mass Casualty Incident Management System, The 14th International Symposium on Wireless Personal Multimedia Communications (WPMC), 2011

ESE04 - CHENG, Z.; WANG, J.; YEN, N.; WU, Y. Allocation of Resources after Disaster Based on Big Data from SNS and Spatial Scan, International Conference on Advanced Cloud and Big Data (CBD), 2016

ESE05 - DOMDOUZIS, K.; ANDREWS, S.; GIBSON, H.; AKHGAR, B.; HIRSCH, L. Service-Oriented Design of a Command and Control Intelligence Dashboard for Crisis Management, IEEE/ACM 7th International Conference on Utility and Cloud Computing, 2014

EES06 - DOMINICI, F.; MARUCCO, G.; MULASSANO, P.; DEFINA, A.; CHARQANE, K. Navigation in Case of Emergency (NICE): An Integrated NAV/COM Technology for Emergency Management, 5th IEEE Consumer Communications and Networking

Conference, 2008

ESE07 - GOJMERAC, I.; RUGGENTHALER, C.; EGLY, M.; VORRABER, W.; BRUGGER, J.; ASCHBACHER, H.; PANZENBOCK, K.; CHRISTIAN, M. Advanced Information Systems for Enhanced Civil-Military Interoperability in Austria, 3rd International Conference on Information and Communication Technologies for Disaster Management (ICT-DM), 2016

ESE08 - MEISSEN, U.; VOISARD, A. Towards a Reference Architecture for Early Warning Systems, International Conference on Intelligent Networking and Collaborative Systems, 2010

ESE09 - MENDES, C. C. S.; DE ALMEIDA, L. B.; MORO, C.; QUISEN, R. Parana Fire Department System - Mobile Application for Agile Communication with the Seaside Vacationers, XLIV Latin American Computer Conference (CLEI), 2018

ESE10 ROSSI, C.; STEMBERGER, W.; BIELSKI, C.; ZEUG, G.; COSTA, N.; POLETTO, D.; SPALTRO, E.; DOMINICI, F. Coupling Crowdsourcing, Earth Observations, and E-GNSS in a Novel Flood Emergency Service in the Cloud, IEEE International Geoscience and Remote Sensing Symposium (IGARSS), 2015

(22)

ESE11 - SOJEVA, B.; XIE, J. Spatial-Aware Iterative Integration of Crisis Management Information Systems, 3rd International Conference on Information and Communication Technologies for Disaster Management (ICT-DM), 2016

ESE12 - TAN, X.; REN, Y. Study on the Emergency Rescue VRP Based on Ant Colony Optimization and Generalized Distance, Fourth Global Congress on Intelligent Systems, 2013

ESE13 - YANG, Y.; PRASANNA, R.; YANG, L.; MAY, A. Opportunities for WSN for Facilitating Fire Emergency Response, Fifth International Conference on Information and Automation for Sustainability, 2010

ESE14 - ZHAO, Q.; ZHENG, X.; LI, W.; WANG, C.; ZHANG, X. Framework Design of Natural Disasters and Emergency Management System Oriented to Region, Fifth

International Conference on Geo-Information Technologies for Natural Disaster Management, 2013

(23)

APÊNDICE C – Lista de Ilustrações

Figura 2.1.1 Fases para gerenciamento de desastres – DIIRR (2016) ... 04

Figura 3.1.1 Processo do Mapeamento Sistemático ... 08

Figura 3.2.1 Quantidade de artigos aceitos após extração dos estudos ... 11

Figura 3.2.2 Quantidade de artigos aceitos após a leitura completa dos estudos ... 11

Gráfico 4.1 Estudos selecionados por ano de publicação ... 12

(24)

APÊNDICE D – Lista de Tabelas

Referências

Documentos relacionados

Talvez por desconhecimento sobre a história da ciência, talvez por não achar necessária a ferramenta, mas o fato é que não são especialistas da área do ensino da

Poderá não ser possível fotografar nas seguintes condições: logo após mudar para o modo de disparo (como imediatamente após ligar a câmara) ou logo após ter tirado

Note on the occurrence of the crebeater seal, Lobodon carcinophagus (Hombron &amp; Jacquinot, 1842) (Mammalia: Pinnipedia), in Rio de Janeiro State, Brazil.. On May 12, 2003,

Assim como ocorreu na União Europeia, com o estabelecimento de autoridades nacionais de proteção de dados em cada Estado Membro, a estruturação da

[40] Desenvolvimento Jogos como Fator Motivacional em disciplinas de Interação Humano-Computador V/A/C/M N Martoni et al (2018) [41] Desenvolvimento de um bot de apoio

Esse foi um dos fatores que le- vou à extinção das Rodas de Expostos, que acabaram por desaparecer definitivamente da paisagem europeia em fins do século XIX (MARCÍLIO, 1998, p..

Para a definição da questão de pesquisa utilizada no mapeamento sistemático deste estudo, definiu-se o escopo como: identificar e apresentar quais temas da computação

Este mapeamento sistemático tem como objetivo identificar e mapear em quais países existem iniciativas de adoção de Gerenciamento de Riscos aplicadas a Gestão de Requisitos em