<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Web-based Tool to Facilitate Resilience-related Information Management

Hoang Long Nguyen<fnref n="1" />, Salvatore Antonio Marchese<fnref n="2" />, Valentino Gandolfo<fnref n="2" />, Leonardo Luca Trombetta<fnref n="2" />, Massimo Cristaldi<fnref n="2" />, Uberto Delprato<fnref n="2" />, and Rajendra Akerkar<fnref n="1" />*

**Abstract.** This paper provides a comprehensive design of an inventory to gather and manage resilience-related information. A conceptual architecture is introduced followed by an Agile approach by breaking the development task into four sprints, which involves constant collaboration with community users, offering continuous improvement, and getting approval from stakeholders at every stage. By facilitating an agile implementation process, we ensure that the inventory development is highly dynamic, flexible, and collaborative.

**Keywords:** Community resilience · Resilience-related inventory · AGILE development.

## 1 Introduction

The concept of community resilience [11] is now used widely in often quite different contexts [1]. This speaks to a shift from traditional risk management and purely technical approaches towards a more positive concept of resilience as a strategic approach to be integrated with developmental goals representing a pro-active and essentially positive societal response [2] to adversity. A number of prominent policies, strategies and initiatives exist, but it is the Sendai Framework for Disaster Risk Reduction 2015-2030 that represents a transition from understanding the interactions between hazard, exposure and vulnerability [6] to a greater concern with how to act upon these risk factors [9] through prospective, corrective and compensatory measures [22].

The aim of this paper is to support local communities to increase their resilience by developing a web-based tool to help them gather and organise their resilience-related information. Compared to a desktop application, a web-based tool can provide a whole range of advantages by *i*) allowing access from any computer as long as there is the internet and *ii*), supporting different individuals to collaborate effectively and efficiently. It is seen predominantly as a strategic tool

<footnote n="1">¹ Big Data Research Group, Western Norway Research Institute, Sogndal, Norway
{hln, rak}@vestforsk.no</footnote>

<footnote n="2">² IES Solutions, Italy
{s.marchese, v.gandolfo, l.trombetta, m.cristaldi, u.delprato}@i4es.it</footnote>

<footnote>* Corresponding author.</footnote>
for assessment and planning [7], with the aim of increasing resilience in local com-
munities [3], and focus on supporting the mitigation and preparedness phases
of Disaster Risk Management [21]. As a result, the web-based tool should not
be limited by pre-determined weights or data combinations but should instead
be adapted to the specific context of local communities and different hazards
[4]. For the sake of convenience, we name our Web-based tool as the RESILOC
Inventory.

The RESILOC Inventory responds to the need to have a useful tool that
allows to collect a large amount of structured and functional data [5] that is
necessary in order to perform resilience study. The innovation inherent in the
tool is to give all actors the opportunity to identify and assess the validity of
actions to increase resilience in their communities; in particular, local managers,
citizens and resilience experts have been targeted as end users. The inventory
will also have a value in itself for all researchers and commercial companies (e.g.,
insurance and reinsurance companies) who may be interested in the RESILOC
Inventory as a stand-alone tool.

The RESILOC Inventory is a functional digital container that defines and
classifies basic information about communities (including the level of risk percep-
tion by citizens) and stores all that information through a living data structure
that represents the relevant traits of a local community. Based on the literature
review [11] about resilience and the need to help local communities increase their
resilience, our database design [12], our developers' experience and end-users'
recommendations, the inventory is developed targeting the following goals.

- To support local managers and resilience experts of a specific community to collect and consult a large amount of data about the community, it will be useful to get the community basic info related to resilience assessment represented by the values of a predefined set of Proxies identified during the local community definition. Every community will be defined by a simple set of basic attributes (i.e., textual metadata) and a set of Proxies that will be relevant to describe the community in relation to resilience.

- To provide the data structure allowing the creation (by end users defined below) of relationships between Scenarios, Proxies, Indicators and Dimensions.

- To allow policy makers (public administrations of cities and regions, civil protection organisations, etc.), first responders, civil society (citizens, volunteers, NGOs...) and technical services (consultants, urban planners, experts etc.) to access a large amount of useful information to draw inspiration from it including resilience assessment and dimensions, using it to create local projects increasing resilience and contribute with local insights and success stories.

- To be used in all phases of Disaster Risk Reduction (DRR), being the “Mitigation” and “Preparedness” activities where it will bring the most added value.

From our definition, Proxy is an indirect data source contributing to the as-
sessment of an Indicator. Respectively, Indicator is a variable which provides
an operational representation of a characteristic of a community and Dimension
is a synthetic representation of resilience under a specific topic. The RESILOC
Inventory will, thus, store all the information needed to assess resilience, consid-
ering social [14], economic [16], governance [13], environment [10], infrastructure
[15], and DRR dimensions.

Through validation meetings with end-users (i.e., local civil protection de-
partment members), they have also brought valuable contribution to the RE-
SILOC Inventory core architecture design which delivers performance and user-
tailored functionalities. Several European projects and products (i.e., SmartRe-
silience [8], DRIVER+ [18], EmerGent [19], EPISECC [20]) have been analysed
and, although a ready solution for the task at hand was not found, these studies
have been proven effective as source of inspiration to forge the core aspects of
the RESILOC Inventory.

The collection of the requirements followed a Spring-based method. The re-
quirements have been collected during the various spring meeting and end-user
workshops and the contributions gathered through/by interaction paved the way
and the direction for the next sprint until the end of the project. A Sprint pays
a lot of attention to the definition of a plan for the implementation of each iter-
ation of the products; it consists in organising a discussion between all involved
actors, from the analyst to the developer, from the testers to the product owner.
The objective of the sprint is to check if users' needs and expectations have
been met or it is desirable/recommended to adopt some changes; gathering and
translating these comments as new requirements for developers. Each Sprint has
been taken as an opportunity to remind the users about the RESILOC scientific
timeline, the sprint series, the RESILOC vision, and what RESILOC will make
available relevant to the subsequent Sprints.

In this section, our target is to introduce the problem and emphasize our
motivation to conduct this resilience-related database. The rest of the paper is
organized as follows. In Section 2, we mention important scopes of the inven-
tory for the sake of simplicity in further sections. Further, Section 3 propose a
conceptual design of the database. Then, we come up with the AGILE approach
to develop the inventory in Section 4. Finally, we mention user validation in
Section 5 and conclude this work and state some future work in Section 6.

## 2 Scope of the Inventory

The RESILOC Inventory will store data related to disasters. Analysing them
and then making them available to the main stakeholders after the event, it
will be possible to learn from the experience: this part of the recovery phase
will be another important aspect of the data stored in the RESILOC Inventory.
In this way, local communities will be able to use the relevant information to
assess local resilience dimensions and the best approaches to improve it through
a combination of institutional and technological solutions.

The inventory will be able to support the community definition operations
by providing specific features to import Proxies already defined for other local
communities that, by a local manager point of view, matches with the target one.

The inventory will be populated by the local managers, resilience experts and local communities' citizens across Europe using data on specific characteristics of the area (e.g., environment, natural hazards, infrastructure, man-made or industrial hazards, etc.), social aspects of the community (e.g., age and census population distribution, social cohesion, risk awareness, institutional trust, local knowledge) and human factors, such as risk perception and awareness, coordination and leadership. It will also accommodate raw (or refined data) data acquired through sensors and/or information collected from Social Media and Crowdsourcing. The data in the RESILOC Inventory will be always available as open data.

The users of the RESILOC Inventory will have different permissions and abilities in accordance with the role they are given for a particular community. The roles currently defined in the platform are listed below:

- RESILOC admin: users who come from the RESILOC consortium responsible for the management and configuration of the RESILOC entities mentioned above and guarantee the inventory's performance, integrity, and security.

- Community side: Below are defined roles for community users. There are five different roles:

* Community admin: the users who are responsible for managing and assigning roles for other community users. Community admins are set by RESILOC admins to generate a working environment for different communities.

* Local manager: the users who have control over community settings (such as community description, metadata, or privacy settings) and can create, view, edit, and remove community entities, i.e., community Proxies, Indicators, and Scenarios.

* Resilience expert: the users who own in-depth knowledge about resilience. They can assist local managers in organising community entities for resilience assessment.

* Local Resilience Team (LRT): the members of LRTs that have full access to view all the community configurations that resilience assessment results.

* Citizen: this is the lowest-level role that is automatically given to a user when he/she starts following a community. This user will have the ability to view public community configuration and resilience assessment information only.

## 3 Conceptual Architecture

All the data in the RESILOC Inventory, which will be filled in by users manually, must belong to particular communities pre-defined by stakeholders. As in Fig. 1,
<figure><img src="image_2.png" /><figcaption>Fig. 1. Overview of the RESILOC Inventory.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 2. Example of a Scenario.</figcaption></figure>
each area contains “Community Metadata”, along with other information such as
Scenario, which is shown in Fig.2, and Timelines.

Each Timeline related to a specific Scenario, as shown in Fig. 3, contains one or more Snapshot Datasets added at a specific point in time, each of which is organised as Indicators and Proxies.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Snapshot of a Scenario.</figcaption></figure>

These Proxies come with important attributes with different scales for a
defined Community as shown in Fig. 4; therefore, the use of some attributes is
crucial to ensure that all the necessary information is adequate for calculating
Indicators as shown in Fig. 5.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Examples of a Proxy.</figcaption></figure>
<figure><img src="image_6.png" /><figcaption>Fig. 5. Examples of an Indicator and its Proxies.</figcaption></figure>

Then, professionals and experts can leverage the stored data to conduct various resilience assessments based on their experience. Each assessment needs a list of relevant Proxies (coming from a specific Snapshot Dataset) along with their attributes. These assessments give the first insights and ideas into practical strategies for making communities resilient; however, they have the possibility to submit an undefined number of Snapshot. Regarding the Dataset, the RESILOC users will need to populate the section with past/present/future hazards and capacities.

Users with the appropriate capabilities are allowed to access the RESILOC proxy, indicator and scenario lists, so that these can be imported into their community lists; in this way proxies, indicators and scenarios can be easily retrieved and used to conduct a community resilience assessment. An editing feature is also available to allow the customisation of proxies, indicators and scenarios imported from RESILOC lists, facilitating their adaptation to suit the community context in which they are used. Professional and experts can make use of other sources, as depicted in Fig. 6, for conducting the study of the resilience, and then the RESILOC project provides a number of tools that they can involve in their job:

- The Survey Platform for creating and dispatching questionnaires all over the citizens;

- The BLE sensors for tracking people's proximity;
- The Raspberry PI gateways for analyse Wi-Fi networks,

- The mobile APP for submitting answers to questionnaires and interacting with BLE sensors distributed all over the territory;

- The Social Media Analysis which the aim is to scan the common Social Media.

In addition, we gather appropriate information about users, communities, and risks from various applications to complete a full picture of the required elements for further calculating Indicators and building resilience dimensions.

<figure><img src="image_7.png" /><figcaption>Fig. 6. The use of designed RESILOC Inventory.</figcaption></figure>

For a specific community it will be needed to define and store at least one Scenario configuration that will be used to calculate resilience assessments, for one or more resilience dimensions, using Snapshot Datasets.

Each resilience dimension, together with its mandatory information (i.e., relevant Indicators and Proxies), will be stored as Snapshots for later recall and retrieval as well. By selecting a specific Scenario, it will be possible to make several resilience assessments and analyse them (i.e., comparing outcomes after adding a new Snapshot Dataset triggered by a hypothetical action defined by the resilience expert).

Regarding the Indicators, each one will be defined through the identification of the Proxies participating in the calculation.

Each Proxy will also be assigned two crucial attributes that state the impact in the resilience calculation for a specific Indicator, which are the relevance and the direction. The relevance and direction of each Proxy in the calculation of an Indicator will depend on the characteristics of the community involved and the specific Scenario considered.

This conceptual architecture has been designed keeping in mind the following requirements:

1. The ability to receive a large and heterogeneous amount of data provided from different communities, and to collect it in a functional structure and
with a homogeneous format, easing the sharing and comparing of the RE-SILOC Inventory's data by end users.

2. The level of performance and reliability needed to make the cloud platform able to perform complex queries and fetch well-structured data in order to elaborate the resilience assessment operations.

## 4 AGILE Implementation of the RESILOC Inventory

This section describes the usage of Agile software development [17] to develop the RESILOC Inventory. It is open to changing requirements over time and encourages regular feedback from the end-users. The Agile implementation guarantees that the inventory is iterative, incremental, evolutionary, and adaptive through continuous delivery, integration, and collaboration. The agile methodology aims to shorten the time between the decision-making process and the feedback gained from the community users. This is a software development model used to build complex software and product development with iterations that are of definite duration, known as “sprints”.

During the development process, we always categorise the tasks into different groups based on their complexity for the purpose of better management and a more organised workflow. We prioritise to develop baseline features or the ones having strong associations with other services (i.e., open data service, semantic layer, or survey tool) in the initial versions, while more complicated ones are implemented in subsequent releases.

<figure><img src="image_8.png" /><figcaption>Fig. 7. The RESILOC Inventory development process.</figcaption></figure>

To make the inventory development effective, some essential stages need to be taken into account as in Fig. 7 including development, integration, and production stages. As sketched already, the general idea in the development of the inventory is to follow a circle of very small via the communication among members in our team and verification steps through different sprints with all community users. This enables the desired feedback loop, in which inputs from the community users lead to new functionality and changes of existing features or the implementation of new functionalities according to users' needs.
- **Development:** the team organised meetings at the beginning to identify, discuss, and analyse overall requirements of users to make adjustments and to ensure that system functions appropriately at the end. At this stage, the development teams also set standards and stick to it to avoid possible flaws later on. After guaranteeing that all components and functionalities were considered, developers begin the actual implementation process thoroughly. The backend in this stage uses WM3 as the development environment.

- **Integration:** the objective of the stage is to perform integration of the RE-SILOC Inventory frontend and backend. Before starting the integration, our team must ensure that both the frontend and backend are error-free and fit the designs. Each function on the UI is mapped precisely to developed end-points given by the inventory backend. Communications between frontend and backend will be done using Hypertext Transfer Protocol (HTTP) using a REST architectural style. A number of assessments including security, accessibility, performance, stress, and compatibility tests are conducted to make sure that systems meet all the technical requirements with the components integrated.

- **Production:** this is where the community end-users access and actually use the latest version of the inventory after all of the updates and testing from the integration stage. The time to release the inventory to production is several weeks before each sprint. This is to help our team having adequate time for final checks and verification to certify that the system is up and running and all functionalities operate fine with this latest and updated version before giving it to users during the sprints.

- **Sprint:** this stage aims at removing any gaps between community users and our team. To plan and execute sprints productively and correctly, we articulate the sprint goals, inform these objectives to end-users, and provide them with well-prepared documentations. Each sprint is divided into two sessions separated by a week to allow users to interact and experience new components. The first session is dedicated to the presentation and real-time usage of the latest developed features while the second one includes an in-depth exchange of ideas on the functionalities shown and tried by the users during previous days, aimed at investigating their impression, collecting comments and judgements to revise and/or validate what has been developed. Between the two sessions, the development team is always available to assist users if requested.

During all phases of the development lifecycle, API documentation and observability are developed to turn the lights on, see, and understand details and states of components of the inventory.

# 5 User Validation and Discussion

The development of the RESILOC Inventory was characterised by an AGILE implementation process including interaction phases with the other consortium partners as well as with the end-user representative communities. Sprint aims
to update users on the implementation progress, presenting the solutions and
discussing its usability through the developed user interface (UI); the users have
the opportunity of real-time interaction (when scheduled) and provide feedback
and suggestions for the improvement. Last but not least, get approval by users
to continue the implementation of the solutions proposed. In addition to that,
the directions for the resilience assessment Framework, the connections with
the trials, and the inclusion of the LRTs in various Sprints are additional topics
included as well. These RESILOC Sprints are usually carried out in two separate
sessions; realise a 2-day Sprint helping to provide an overall picture, giving time
to assimilate and metabolise the information transmitted and provide sufficient
time to return more thoughtful feedback and suggestions. Day 1 usually focuses
on the contents scheduled for the Sprint. On the other hand, Day 2 aims to receive
and discuss user feedback as well as side topics and next Sprint preparation.

Specifically, the RESILOC Inventory was presented during the 1st Sprint
(December 4, 2020), introducing a first mock-up and describing its earliest func-
tionalities. From it the RESILOC Inventory was further developed and repre-
sented the main focus of the 2nd Sprint (April 26-27, 2021), and partially rein-
troduced in the 3rd Sprint (September 10 and September 17, 2021). During these
Sprints, the inventory was presented, users were updated on the progress of the
implementation and its usability was discussed in detail via the developed user
interface. In addition, the users were allowed to interact with the inventory in
real time (interactive session between developers, researchers, and users), in or-
der to give feedback and suggestions on the functionalities offered and exchange
thoughts on their use and effectiveness; such information was useful for improve-
ment but above all to obtain the users' approval to continue the implementation.
Lastly, the end-users have been invited to evaluate some additional inventory's
functionalities including sorting and filtering features, as well as the duplication
function during the 4th Sprint (November 26 and December 3, 2021).

During Sprints, community representatives have raised questions or com-
ments and to share their experience on the inventory usage; the highlights and
key points for the improvement of the RESILOC Inventory, grouped by topics,
are presented below.

- **Usability:** researchers and community representatives gave a positive response, expressing appreciation for the current version, reporting a simple and user-friendly environment to enter the data required. However, they reserve the opportunity to raise some remarks once intensive use of the system begins, so that some features could be identified to be optimised in order to improve usability. The usability of the application on mobile devices was another topic raised by the representatives of the communities; however, the layouts used are responsive (i.e., the contents are automatically organised and modelled) so all pages can be used on mobile devices as they are automatically adapted (some specific pages may be more difficult to use due to their higher complexity).

- **Accessibility:** role management and role assignment were discussed exten-
sively; in particular, the conversations involved the way in which roles are
managed and assigned to inventory users, focusing on the possibility of hav-
ing multiple roles assignable to each user and the minimum number of roles
required to have a community capable of operating the inventory compre-
hensively. The accepted solution envisages that each user has a unique ac-
count, whereby he/she can login to the inventory and have access to different
communities; in each community, a user may have different roles properly as-
signed according to his/her expertise and responsibilities, wherein each role
provides different capabilities to interact with the system. In addition, every
community needs to have users holding the role of local manager, resilience
expert and community admin, even if assigned to the same person and thus
to a single user. It was also strongly suggested to make visible on the screen
the roles played by the user for the community selected; the development
team proposed a possible solution, consisting in displaying the roles played
by the user next to the name of the community he/she is operating into.

- **Possible corrections/changes to be done:** users pointed out a very short autosave time delay (introduced to avoid data loss in case of connection drop) when entering certain values, e.g., min and max target, causing trouble in filling in the form. In reply, the delay time of the autosave function has already been modified, extending it by an appropriate amount of time to make the required operation easier and more fluent. Regarding the roles management and assignment, it was suggested to make the users' roles management layout as compact as possible, aiming to facilitate the users' identification in case there are several registered.

The execution of the Sprints allowed not only the collection of productive
feedback and suggestions for the inventory improvement, but also stimulated
the users to identify beneficial/useful features. During the interactive phase, the
users came up with a requirement to include a filter feature in the Proxy, Indi-
cator, and Scenario lists layout; so that they could be easily retrieved by typing
their names into a search box. Likewise, introducing the import and manage-
ment functionalities for Proxies, Indicators and Scenarios, some users expressed
the interest in having a feature that allows the duplication of these elements.
In addition to what has already been stated, users manifested the necessity of a
widespread use of tooltips, transversal to all the sections composing the inven-
tory; their implementation is aimed at favouring an exhaustive understanding of
the items and terminologies presented on screen.

In addition to what has already been stated, users manifested the necessity of
a widespread use of tooltips, transversal to all the sections composing the inven-
tory; their implementation is aimed at favouring an exhaustive understanding
of the items and terminologies presented on screen. The implementation of a
notification system within the inventory was also suggested, in order to notify
designated users on the execution of certain operations involving their commu-
nity (e.g., if a user follows his community).

The requests and suggestions collected have been evaluated and prioritised;
some of the previously mentioned functionalities have already been developed
and are currently available in the inventory, such as some tooltips and the filter-
ing and duplication features, while the implementation of the notification system
has not been released yet.

During the presentation of the latest implementations, which included the
language settings component, the new sorting and searching functionalities, and
the duplication functionality; the users showed appreciation for the accomplish-
ment of their previous requests, stating also that the tooltips integrated and
deployed are easy to understand. The users provided comments on the utility to
have a what-if tool, suggesting some functionality in this respect, like a sort of
versioning tool for the Proxies.

According to the discussions on the inventory emerged during the sprints,
users appreciated and approved what has been developed in the inventory so
far, states that the inventory does not have components that needs to be redone
or replaced and says that the system is flexible for further small adaptations.

6 Conclusions

The RESILOC Inventory is developed as a web-based set of interfaces, services, and datastores, providing end-users and researchers the possibility to populate and make use of the RESILOC Inventory SaaS. The tool is developed on top of Open Source based technologies (e.g., JavaScript, PostgreSQL, and MongoDB) and run on a Cloud infrastructure to be easily scaled and maintained. The approach to follow is distributed, and the inventory itself is highly customisable for future evolution and future-proof capabilities.

In general, the inventory provides an effective UI to help users manage their
data. The RESILOC Inventory UI also offers the user varied features for collect-
ing and organising data through numerous functions at hand such as template
inheritance, data duplication, event notification, and searching, sorting & fil-
tering options. Running in parallel and handling requests from the UI is the
inventory backend that aims at processing all heavy tasks in the background.
It ensures performing all the required actions in the most efficient and logical
manner, spending as little time and resources as possible.

In our future work, we will continue expanding Inventory features to better
adapt to different users' requirements. For instance, a semantic layer will be
implemented to suggest proxies and indicators already used by existing commu-
nities to newcomers (new communities) or to be able to provide a list of "similar"
communities. Moreover, it will be connected with other tools (e.g., social media
analysis and survey tools) to gather more information from various sources.

**Acknowledgements** This work has been supported by the RESILOC project. RESILOC has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No 833671.

References

1. Bodin, P., Wiman, B.: Resilience and other stability concepts in ecology: Notes on their origin, validity, and usefulness. ESS Bulletin **2**(2), 33–43 (2004)
2. Coles, E., Buckle, P.: Developing community resilience as a foundation for effective disaster recovery. Australian Journal of Emergency Management **19**(4), 6–15 (2004)

3. Crowe, P.R., Foley, K., Collier, M.J.: Operationalizing urban resilience through a framework for adaptive co-management and design: Five experiments in urban planning practice and policy. Environmental Science & Policy **62**, 112–119 (2016)

4. Cutter, S.L., Barnes, L., Berry, M., Burton, C., Evans, E., Tate, E., Webb, J.: Community and regional resilience: Perspectives from hazards, disasters, and emergency management. Geography **1**(7), 2301–2306 (2008)

5. Garvin, S., Hunter, K., McNally, D., Barnett, D., Dakin, R.: Property flood resilience database: an innovative response for the insurance market. In: E3S Web of Conferences. vol. 7, p. 22002. EDP Sciences (2016)

6. Hosseini, S., Barker, K., Ramirez-Marquez, J.E.: A review of definitions and measures of system resilience. Reliability Engineering & System Safety **145**, 47–61 (2016)

7. Jabareen Y.: Planning the resilient city: Concepts and strategies for coping with climate change and environmental risk. Cities **31**, 220–229 (2013)

8. Jovanović, A., Auerkari, P.: Eu project smartresilience: The concept and its application on critical energy infrastructure in finland. In: BALTICA X – International Conference on Life Management and Maintenance for Power Plants (June 07-09, 2016)

9. Kuhlicke, C.: Embracing community resilience in ecosystem management and research. In: Schröter, M., Bonn, A., Klotz, S., Seppelt, R., Baessler, C. (eds.) Atlas of Ecosystem Services, pp. 17–20. Springer, Cham, Switzerland (2019)

10. Longstaff, P.H.: Security, resilience, and communication in unpredictable environments such as terrorism, natural disasters, and complex technology. Center for Information Policy Research, Harvard University (2005)

11. Nguyen, H.L., Akerkar, R.: Modelling, measuring, and visualising community resilience: A systematic review. Sustainability **12**(19), 7896 (2020)

12. Nguyen, H.L., Senarath, Y., Purohit, H., Akerkar, R.: Towards a design of resilience data repository for community resilience. In: Proceedings of the 18th International Conference on Information Systems for Crisis Response and Management (ISCRAM 2021), Blacksburg, Virginia, USA, May 23-26, 2021. pp. 271–281 (2021)

13. Osman, I.H., Anouze, A.L., Irani, Z., Al-Ayoubi, B., Lee, H., Balcı, A., Medeni, T.D., Weerakkody, V.: Cobra framework to evaluate e-government services: A citizen-centric perspective. Government Information Quarterly **31**(2), 243–256 (2014)

14. Rahman, M.S., Kausel, T.: Coastal community resilience to tsunami: A study on planning capacity and social capacity, dichato, chile. IOSR Journal of Humanities and Social Science **12**(6), 55–63 (2013)

15. Reiner, M., McElvaney, L.: Foundational infrastructure framework for city resilience. Sustainable and Resilient Infrastructure **2**(1), 1–7 (2017)

16. Rose, A.: Defining and measuring economic resilience to disasters. Disaster Prevention and Management **13**(4), 307–314 (2004)

17. Schwaber, K., Beedle, M.: Agile software development with scrum. Series in agile software development, vol. 1. Prentice Hall Upper Saddle River (2002)

18. The DRIVER+ project for crisis management: https://www driver-project eu/, last accessed on 10.11.2022

19. The EmerGent project: https://www fp7-emergent eu/, last accessed on 10.11.2022

20. The EPIS.EC project: https://www episecc eu/, last accessed on 10.11.2022
21. United Nations Office for Disaster Risk Reduction (UNDRR): Disaster resilience scorecard for cities, https://www.unisdr.org/campaign/resilientcities/toolkit/article/disaster-resilience-scorecard-for-cities, last accessed on 16.11.2022

22. Yoon, D.K., Kang, J.E., Brody, S.D.: A measurement of community disaster resilience in korea. Journal of Environmental Planning and Management 59(3), 436–460 (2016)