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

HAL
open science

# On Challenges in Engineering IoT Software Systems

Rebeca Campos Motta, Káthia Marçal de Oliveira, Guilherme Horta
Travassos

► To cite this version:

Rebeca Campos Motta, Káthia Marçal de Oliveira, Guilherme Horta Travassos. On Challenges in Engineering IoT Software Systems. Journal of Software Engineering Research and Development, 2019, 7, pp.5. 10.5753/jserd.2019.15. hal-03400380

HAL Id: hal-03400380

https://uphf.hal.science/hal-03400380

Submitted on 26 Apr 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

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

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_3.png" /></figure>

# On Challenges in Engineering IoT Software Systems

Rebeca Campos Motta | Universidade Federal do Rio de Janeiro and LAMIH CNRS UMR 8201 | rmotta@cos.ufrj.br]

Káthia Marçal de Oliveira [Université Polytechnique Hauts-de-France LAMIH CNRS UMR 8201 | kathia.oliveira@uphf.fr]

Guilherme Horta Travassos [Universidade Federal do Rio de Janeiro | ght@cos.ufrj.br]

## Abstract

Contemporary software systems, such as the Internet of Things (IoT), Industry 4.0, and Smart Cities represent a technology changing that offer challenges for their construction since they are calling into question our traditional form of developing software. They are a promising paradigm for the integration of devices and communications technologies. It is leading to a shift in the classical monolithic view of development where stakeholders used to receive a software product at the end (that we have been doing for decades), to software systems incrementally materialized through physical objects interconnected by networks and with embedded software to support daily activities. Therefore, we need to revisit the traditional way of developing software and start to consider the particularities required by these new sorts of applications. Since such software systems involve different concerns, this paper presents the results of an investigation towards defining a framework to support the software systems engineering of IoT applications. To support its representation, we evolved the Zachman's Framework as an alternative to the organization of the framework architecture. The filling of such a framework is supported by a) 14 significant concerns of IoT applications, recovered from the technical literature, practitioner's workshops and a Government Report; b) seven structured facets emerged from IoT data analysis, that together represent the engineering challenges to be faced both by researchers and practitioners towards the advancement of IoT in practice.

**Keywords:** Internet of things, IoT, Contemporary Software Systems Engineering, Empirical Software Engineering

## 1 Introduction

The Internet of Things (IoT) contributes to a new technological revolution affecting society. IoT is a paradigm that allows composing systems from uniquely addressable objects (things) equipped with identifying, sensing, or acting behaviors and processing capabilities that can communicate and cooperate to reach a goal. From primary devices with simple software solutions to the large-scale, high-performance software systems producing and analyzing massive amounts of data, IoT is going to reach all areas of interest (Jacobson et al. 2017). Due to its far-reaching potential, IoT can use all kinds of technologies available today and will drive the development of new software systems to solve new problems, some still unknown (Atzori et al. 2010; Jacobson et al. 2017).

Software Engineering, as a discipline, has gone through constant changes since its conception. Several concepts, methods, tools, and standards have been proposed to support the development of software (IEEE 2004; Trappey et al. 2017), and the Internet has given a significant shift in the area. It makes more explicit the need to evolve the software technologies previously proposed to support the building of systems fitting new features.

Systems engineering is a research area embracing multidisciplinarity, integrating different disciplines to reach successful systems according to their purposes, including software, which is essential for IoT materialization. Therefore, IoT leads to an era where, rather than developing software, practitioners are going to engineer systems embedding much software into the system's parts. In this scenery, the initial problem of our research is to identify the concerns regarding the development of IoT software systems, and whether the existing software technologies

within the areas (facets) related to engineering such systems are enough for supporting their development. Overall, this paper describes the results of investigations dealing with the road ahead on IoT development. The concerns captured through observations in the technical literature, from practitioners in specific workshops and a national initiative regarding IoT in Brazil pave this road.

The filling of IoT facets combined with the concerns is what we call engineering challenges, capturing knowledge necessary to support a specific activity. The conceptual framework aims to contemplate all facets involved in IoT and present the recovered concerns, by simplifying and organizing their presentation. The Zachman's proposition for information systems architecture (Zachman 1987) (Subsection 2.2) was borrowed and tailored to compose such a framework.

Our motivation to investigate and contribute to the IoT paradigm is therefore supported by its relevance (CNI 2016; Lu 2017) and the need for a holistic approach and multidisciplinary view for the development of new software solutions (Bauer and Dey 2016; Aniculaesci et al. 2018). This reflects in a demand for technical competencies and skills detained by different practitioners to engineer such software systems (Desolda et al. 2017; de Farias et al. 2017) and the lack of specific software engineering methodologies to support IoT (Zambonelli 2016; Larrucea et al. 2017; Jacobson et al. 2017). Some of the challenges are focused on interaction issues, whether it is between humans or things, which is essential for the complete establishment of the paradigm (Motta et al.). In our proposal, we introduce a multifaceted conceptual framework as a step towards addressing some of these issues.

This paper extends (Motta et al. 2018), including more details of the studies, deepen the discussions and providing a usage example of the proposed framework. The paper is
organized as follows: Section 2 presents the context of this research and the Zachman's framework. Section 3 presents the research strategy followed by the primary results: the IoT concerns (section 4), IoT facets (section 5) and the definition of the framework (section 6) with an example of use. Section 7 concludes the paper with final remarks regarding threats to validity and ongoing works.

# 2 Conceptual Background

This section starts by presenting the source of motivation for this research, the CACTUS Project. Next, it presents some basic concepts related to the Zachman's Framework, which is the ground for the proposed Conceptual Framework organizing the results presented in this paper.

## 2.1 The CACTUS Project

The CNPq CACTUS research project was performed based on the aim of understanding test strategies for quality assessment of actor-computer interaction in context-aware systems, as one of the chief characteristics of ubiquitous systems (Spínola and Travassos 2012; Santos et al. 2017; Matalonga et al. 2017). Research teams from two Brazilian universities (Federal University of Rio de Janeiro and Federal University of Ceará) and one French university (Université Polytechnique Hauts-de-France) worked together in the project.

It started with the assumption that interaction is not limited to human and computers in ubiquitous systems. It encompasses the interaction among different devices, such as sensors, actuators, as well as other systems, which we consider the term actor-computer interaction as more adequate. From the results achieved in the project and the technological evolution of the area, we look IoT as related to Ubiquitous Systems, sharing some characteristics and challenges (Andrade et al. 2017). This work is one of the results of this change of perspective.

## 2.2 Zachman's Framework

The Zachman's Framework (Zachman 1987) was introduced in 1987 to comprehend the scope of control within an enterprise and to provide a holistic view of the enterprise architecture that may be used as a base for its management. It still is an essential reference for enterprise architecture and supported by many types of modeling tools and languages (Goethals et al. 2006).

Zachman's motivation to develop the framework was that "with increasing size and complexity of the implementation of information systems, it is necessary to use some logical construct for defining and controlling the interfaces and the integration of all of the components of the system" (Zachman 1987). The framework is suitable for working with complex systems, and despite its original purpose, its use is not limited to enterprise architecture. Alongside with that, it has been used to assess the development process (de Villiers 2001), for requirement engineering (de Villiers 2001; Technology 2015), business process modeling (Sousa et al. 2007), to instantiate an IEC standard (Panetto et al. 2007), and applied to Systems of Systems (Bondar et al. 2017). Also, Zhang et al. used this framework for safety analysis in Avionics Systems (Zhang et al. 2014). More framework evidence use can be observed in different case studies (Panetto et al. 2007; Nogueira et al. 2013; Aginsa et al. 2016), the latter claiming that "Zachman's framework continues to represent a modeling tool of great utility and value since it can integrate and align the IT infrastructure and business goals."

From the data recovered in our research, we realize that concepts and properties related to IoT change according to the context and actors involved. This multifaceted view of IoT shows once again that it is a multidisciplinary paradigm. For this reason, a representation of the concepts should be as comprehensive as possible to represent all aspects involved. This framework is primarily defined considering a table, crossing perspectives, and interrogative questions as presented in Table 1 (Zachman 1987; Sowa and Zachman 1992).

<table><caption>Table 1. Zachman Framework with cells filled showing examples of description (Sowa and Zachman 1992).</caption><caption>INTERROGATIVE QUESTIONS</caption><thead><tr><th></th><th>What</th><th>How</th><th>Where</th><th>When</th><th>Who</th><th>Why</th></tr></thead><tbody><tr><th scope="row">Planner</th><td>Things important to the business</td><td>Process performed</td><td>Business locations of operations</td><td>Events and Cycles important to the business</td><td>Organizations and Agents important to the business</td><td>Business goals and strategies</td></tr><tr><th scope="row">Owner</th><td>Semantic Model</td><td>Business Process Model</td><td>Business Logistic System</td><td>Master Schedule</td><td>Workflow Model</td><td>Business Plan</td></tr><tr><th scope="row">Designer</th><td>Logic Data Model</td><td>Application Architecture</td><td>Distributed System Architecture</td><td>Process Structure</td><td>Human Interface Architecture</td><td>Knowledge Architecture</td></tr><tr><th scope="row">Builder</th><td>Physical Data Model</td><td>System Design</td><td>Technology Architecture</td><td>Control Structure</td><td>Presentation Architecture</td><td>Knowledge Design</td></tr><tr><th scope="row">Implementer</th><td>Data Definition</td><td>Program</td><td>Network Architecture</td><td>Timing Definition</td><td>Security Architecture</td><td>Knowledge Definition</td></tr><tr><th scope="row">User</th><td>Data</td><td>Function</td><td>Network</td><td>Schedule</td><td>Organization</td><td>Strategy</td></tr></tbody></table>
The framework formalization and its conception were presented as a metaphor from the building architecture to system architecture. The perspectives are therefore described as (Sowa and Zachman 1992):

* **Planner** - It corresponds to an executive summary for a planner or investor who wants a system scope estimate, what it would cost, and how it would perform.

* **Owner** – It relates to the enterprise business model, which constitutes the business design and shows the business entities and processes, and how they interact.

* **Designer** – It corresponds to the system model designed by a systems analyst who must determine the data elements and functions representing business entities and processes.

* **Builder** – It refers to the technology model, which must tailor the information system model to the details of the programming languages, I/O devices, or other technologies.

* **Implementer** – It relates to the detailed specifications that are given to programmers who code individual modules without being concerned with the overall context or system structure.

* **User** - The user perspective was added in a later version and represents the view of the functioning building, or system, in its operational environment.

The framework presents six fundamental questions in the columns to outline each perspective and support the answering to the questions regarding:

* **What:** some entity (that can be real-world objects, logical or physical data types).

* **How:** some process.

* **Where:** some location.

* **Who:** some role played by a person or a computational agent.

* **When:** time, a subtype such as a date, or time that is coincident with some event.

* **Why:** some goal or subgoal that provides the reason that motivates the model for that row.

Considering the extensive use of the Zachman Framework for representing different domains and technologies and its flexibility of being customized to represent the complexity in each context, we decided to take it as a basis of our work. To that end, we analyzed concerns and facets related to the multidisciplinarity of IoT applications to be used as inputs of information and requirements for its first organization.

## 2.3 Related Work

In this work, we propose a holistic engineering view, based on the principles of Systems Engineering. In the search, we came across the work of Patel and Cassou that propose a development methodology and framework to support the implementation of IoT applications. Their approach is designed to address essential challenges (lack of division of roles, heterogeneity, scale, different lifecycle phases) that differentiate IoT applications from others (Patel and Cassou

2015). The proposal of their methodology is based on the separation of concerns: domain, functional, deployment, and platform. Each concern has specific steps to guide the development, implemented in a defined process. There are some similarities to our proposal. We highlight their strategy to attack multidisciplinarity by using four concerns with a diverse set of skills performed by five different roles. However, our proposal differentiates from that because it offers a broader view of the concerns and focuses more on supporting the development team to move out of the problem domain with an action plan stepping into the solution domain.

Two other works (Alegre et al. 2016) and (Sánchez Guinea et al. 2016) are literature reviews, focusing on engineering strategies to develop Context-Aware Software Systems (CASS) and Ubiquitous Systems, respectively. In (Alegre et al. 2016), the results are based on a literature review, and a survey carried out with specialists in CASS. It presents an extensive work in the CASS area, analyzing and characterizing the concept of context as well as their interaction types and main features. The most exciting part for the perspective of our work is that they search the literature for developing techniques and methods that have been adapted from conventional systems to CASS throughout the most common stages of a development process: Requirements Elicitation, Analysis & Design, Implementation, and Deployment & Maintenance.

None of the techniques presented fully meets the CASS requirements, and the authors conclude the work by recommending a more holistic and unified approach for the development of CASS, arguing that it should be different from the conventional software engineering approach for creating these systems (Alegre et al. 2016).

Another work is from Costa et al. (Costa et al. 2017). It presents more than just the requirements and needs of an IoT application, focusing on its challenges and proposing an approach to support the requirements specification of IoT systems named IoT Requirements Modeling Language (IoT-RML). We share some of the motivations with this work since it states that different perspectives and the heterogeneous nature of IoT should be considered in the development of such software systems. The Domain Model composes their proposal for the abstraction and a SysML profile for the specification. In their model, a stakeholder expresses a requirement as a proposition, and the requirement may influence or conflict with other requirements. Their approach supports both functional and nonfunctional requirements, which is crucial in this scenario. Through their solution, four requirements specification activities are supported: elicitation of system's requirements from the stakeholders that will generate an initial model in their tool, the analysis to identify influences and conflicts among requirements updating the model representing them, resolution of conflicts, and the last activity, to decide on a candidate solution containing the requirements to be addressed. A proof of concept is presented to illustrate the approach used in the context of a smart building, focusing on employees' safety and energy efficiency.
Our proposal can somehow be related to the IoT-RML approach (Costa et al. 2017). However, we aim to address the problem understanding in the conceptual phase, which focuses on a step before the specification requirements considering a multi-perspective and multidisciplinary strategy.

Another related work is from Aniculaesei et al., which argues that conventional engineering methods are not adequate for providing guarantees to some of the challenges specific of autonomous systems, such as dependability, the focus of their work (Aniculaesei et al. 2018). Some of the main points discussed is the possibility of adaptive behavior present in IoT, as they adapt their behavior to better interact with other systems and people or to solve problems more effectively, and variations in the context, the formerly closed and valid development artifacts may not capture the changes and be inadequate since the environment and the system behavior can no longer be fully predicted or described in advance (Aniculaesei et al. 2018). In response to these challenges and gaps, the authors propose an approach based on the notion of Dependability Cages. Their approach deals with external risks (uncertainties in the environment) and internal risks (system changing behavior), both at the development and the operation.

At the moment of preparing this manuscript, we observed a lack of more concrete proposals for the materialization of the IoT paradigm. We aim to address the challenges presented in (Alegre et al. 2016) and (Sánchez Guinea et al. 2016), filling the gaps from (Patel and Cassou 2015), (Costa et al. 2017) and (Aniculaesei et al. 2018) focusing on the issue of multidisciplinarity and providing support to decision-making in the initial development phase of problem understanding.

## 3 Research Strategy

Figure 1 presents our investigation strategy. It is composed of three parts and involves performing different lines of investigation and studies. The first part of our investigation regards IoT Concerns. It aims at presenting concerns, issues, and difficulties frequently reported regarding the development of IoT applications. To recover such concerns, we collected data from different sources of information considering a literature review (Subsection 4.1), discussion with practitioners (Subsection 4.2) and reading a Brazilian Government report (Subsection 4.3). Based on the identified concerns, it was possible to observe research gaps and main IoT development issues that need effort in their understanding and evolution. These intermediate results can be useful to researchers looking for research opportunities and practitioners planning the construction of IoT applications.

The literature review also supported the identification of 29 IoT definitions. From this set, we conducted a textual analysis, using **coding** procedures, from Grounded Theory (see section 3.1), to assign concepts to a portion of data (Strauss and Corbin 1990). The result was the identification of **IoT Facets** (Section 4) necessary for IoT materialization, in the sense of being the set of parts composing an IoT

software system. We understand facets as “one side of something many-sided” (Oxford Dictionary), “one part of a subject, a situation that has many parts” (Cambridge Dictionary). These facets are the basis for tailoring the 6x6 matrix of the Zachman’s framework (Zachman 1987).

<figure><img src="image_4.png" /><figcaption>Figure 1: Research Strategy.</figcaption></figure>

The idea of investigating the facets from IoT definitions came in the sense of finding a set of parts composing an IoT software system. It does not try to be exhausting because due to its far-reaching potential, we do not know to what extent IoT will meet or drive the development of new software technologies to solve new problems. We wanted to differentiate concerns from challenges. Each application alone has a set of concerns that must be addressed with software technologies and other solutions for the software system development or construction. In the case of IoT, we understand that it is a multidisciplinary, multidimensional, and multifaceted paradigm (Gluhak et al. 2011; Gubbi et al. 2013; Jacobson et al. 2017). In this sense, this work presents the IoT facets that must meet the concerns, this being the real engineering challenge (to fill a cell in the framework). The procedures and activities performed for each part are detailed, together with a broader discussion of the results.

However, the **concerns** are somewhat related to the **facets**, and our next activity was to find a way to represent all the concepts that transparently emerged from the sources of information, and that could guide the next research activities. Thus, the last step of our research, as a result of the studies, we introduce a **Conceptual Framework** to organize the challenges of engineering IoT software systems (Section 5).

Our work focusses on discussing the IoT perception and its central issues from three perspectives: technical literature, practitioners, and government, using data collected with different studies. We briefly present the studies and dive into the analyzed challenges, from which we propose a conceptual framework to support the development of such software systems by considering different and complementary facets. This paper presents the research path that led us to the framework, not detailing each study, but instead informing how they inspired a structure composed of six questions, six perspectives and seven facets aiming to define an engineering strategy for IoT development.
## 3.1 Grounded Theory (GT)

The GT methodology comes as a mechanism to deal with and understand research data and how they relate to each other, considering the IoT domain and features. We rely on these procedures to analyze the recovered data from each study. The principles and procedures of GT according to (STRAUSS; CORBIN, 1998) were used to assist us in developing and analyzing the concepts in this research, as presented below:

* **Planning:** Initially, it identifies the area of interest and the process to be followed inside the GT paths. In our case, each study was planned individually, with the execution and analysis performed by the researchers.

* **Data Collection:** Initially, GT resorted to interviews. However, any method can be used, like focus groups, observations, artifacts, or texts. In our case, we rely on the data extracted from the articles resulting from the literature review, the data recovered from the discussions with practitioners and all the textual documents from the Brazilian government.

* **Coding:** At this step, the researcher should work their sensibility to identify significant data and use the constant comparative analysis method: through iteration, going back and forth in the codes generated observing and comparing to find adequacy, conformity, and coherence among the codes. In our case, the QDA Miner Lite ¹tool was used to support this part. All the matching from text to code was performed by one researcher and then revised by another. The procedure followed was to review each extraction and the respective code, contributing to the constant comparison until reaching an agreement on the coding.

* **Reporting:** Writing memos, comments, and decision points during the coding phase can enhance the report. Being able to narrate the process of abstraction and describing the rationale behind the codes is the last challenge to sound analysis. In our case, this article comes as the report for the result, from where portions of the extracted data lead to the coding that represents concerns for IoT development.

This approach has been used in Software Engineering research (Seaman 1999; Carver 2007; Badreddin 2013) and was selected since GT provides reference support for the procedures and is adequate to work with a large amount of information. Considering that some concepts have different meanings, this methodology is suitable to establish the similarities and differences among them. The same analysis strategy was used throughout the study.

## 4 IoT Concerns

Being a multidisciplinary domain, IoT covers many topics from socio-technical to business. We conducted different studies to recover IoT concerns. Each study was planned, considering a specific perspective on the subject. Initially,

we contemplate the academy perspective, recovered through a literature review. Then we decided to broaden the range to represent two other perspectives collected from practitioners and a government report, contributing to a more comprehensive representation. Although they represent different visions, they discuss the same topic. Thus they become complementary, giving us a more comprehensive view of the area.

### 4.1 Inputs

#### 4.1.1 From the Literature Review

The concerns presented in the technical literature were extracted from a Literature Review (our first empirical study). For the review, we followed the recommendations well established in the literature (Biolchini et al. 2008) focusing on secondary studies since there were already reviews on IoT. The goal of this GQM-based (Basili et al.

1994) review was defined as: *Analyze* the Internet of Things domain *with the purpose* of characterization *with respect to* definitions, characteristics and application areas *from the point of view of* software engineering researchers *in the context* of the available technical literature.

The selected articles were secondary studies as they rely on primary studies and survey other sources of information to present a bigger picture. presents a research protocol summary. The search engine was Scopus since it indexes several peer-reviewed databases, and is well-balanced regarding coverage and relevance.

Snowballing procedures can mitigate the lack of other search engines and complements the search strategy (Motta et al. 2016; Matalonga et al. 2017). To reduce bias, three researchers executed the review. The process was carried between March and May 2017. Eighty-one articles resulted in the search in Scopus. After the execution of four trials, a selection from title and abstract according to the established criteria, and one level backward/forward snowballing (Wohlin 2014), 12 secondary studies compose the final set. The reviewers read the articles and extracted relevant information according to an extraction form.

We used an extraction form to retrieve the following information from the secondary sources: Reference information, Abstract, IoT definition, IoT related terms, IoT application features, IoT application domain, Development Strategies for IoT, Study Type, Study Properties, Challenges and Article focus. From the discussion of RQ1, we extracted 34 IoT definitions that lead us to understand that IoT is a paradigm allowing the composition of software systems from uniquely addressable objects equipped with identifying, sensing or actuation behaviors and processing capabilities that can communicate and cooperate to reach a goal. Regarding RQ2, we recovered 29 different attributes, where nine of them are discussed with clear evidence from the sources of information. Considering that the results retrieved are from secondary studies, the characteristics

<footnote n="1">¹provalisresearch.com/products/qualitative-data-analysis-software/</footnote>
<table><caption>**Table 2. Protocol Summary.**</caption><thead><tr><th>Research questions</th><th colspan="2">(RQ1) What is Internet of Things?<br>(RQ2) Which characteristics define IoT applications?<br>(RQ3) Which are the applications for IoT?</th></tr></thead><tbody><tr><td rowspan="2">Search string</td><td>Population</td><td>("systematic literature review" OR "systematic* review*" OR "mapping study" OR "systematic mapping" OR "structured review" OR "secondary study" OR "literature survey" OR "survey of technologies" OR "driver technologies" OR "review of survey*" OR "technolog* review*" OR "state of research") AND</td></tr><tr><td>Intervention</td><td>("internet of things" OR "iot")</td></tr><tr><td>Search Strategy</td><td colspan="2">SCOPUS (www.scopus.com) + Snowballing (backward and forward)</td></tr><tr><td>Inclusion Criteria</td><td colspan="2">- To provide an IoT definition; OR to provide IoT properties; OR to provide applications for IoT.</td></tr><tr><td>Exclusion Criteria</td><td colspan="2">- Not provides an IoT definition; AND not provides IoT properties; AND not provides applications for IoT; AND studies in duplicity; AND register of proceedings.</td></tr><tr><td>Study type</td><td colspan="2">Secondary Studies</td></tr><tr><td>Acceptance Criteria</td><td colspan="2">Three distinct readers:<br>- all readers accept => paper is accepted<br>- all readers exclude => paper is excluded<br>- the majority of accept, others in doubt => paper is accepted<br>- else => discuss and consensus</td></tr><tr><td>Technical Report</td><td colspan="2">Detailed information about the planning and execution - https://goo.gl/cZVVDc</td></tr></tbody></table>

represented reflect more than just the selected set, but rather the whole set of primary studies involved in them, which can strengthen these results. One contribution of the review is to present an organized perspective regarding IoT state-of-the-art. Besides, it allows observing which areas of application are making use of IoT (RQ3).

All of these findings were related and summarized in a report to enrich the IoT paradigm comprehension (see link Table 2). IoT related concepts such as cyber-physical systems (Khaitan and McCalley 2015) and systems of systems (Nielsen et al. 2015) are also discussed in the final report of the review.

The data for discussions and analysis came from part what was extracted from the form, which we treat in this section as concerns. We based our analysis procedure on textual analysis, using codes to assign concepts to a portion of data, identifying patterns from similarities and differences emergent from the extracted data, based on the GT procedures (Strauss and Corbin 1990). It was conducted by two researchers, with crosschecking to achieve a consensus with the analysis to decrease potential misinterpretation and bias. The 12 papers provided 38 excerpts regarding IoT challenges that were organized into seven categories: **Architecture**, **Data**, **Interoperability**, **Management**, **Network**, **Security**, and **Social**.

### 4.1.2 From Practitioners

Another perspective used to recover IoT concerns was the practitioners' opinion. We performed qualitative studies during two scientific events from which all the participants were developers and/or researchers in the IoT domain. For this reason, we considered them representative, insightful, and experienced in the topic. The following questions guided the discussions in both studies:

a) Regarding product quality between conventional software and IoT: What is similar? What is different? What needs to be investigated?

b) Regarding the software technologies between conventional software and IoT: What do we have that can be used directly? What do we have that needs adaptation to be used? What don't we have but need?

The first event (in August 2017) was the 1st *QualityIot* at the Brazilian Symposium on Software Quality (SBQS). The 21 participants were divided by convenience into groups to deal with the mentioned questions in the following perspectives:

* **People** - Focused on the human end-user. Challenges and impact of this technology in our daily lives, such as social, legal, and ethical. Group of five (5) participants.

* **Product** - Focused on IoT products that can be generated, considering the inclusion of software and "smartness" in general objects and the possibilities of new products in this scenario. Group of nine (9) participants.

* **Process** - Focused on the software development process that should be included in the *things* and consider the big picture of organizing the *things* together. Group of seven (7) participants.

The groups had one hour for discussion. A representative of each group wrote down the main points identified and later presented the ideas for all the workshop participants.

The second event (carried out in September 2017) was a panel in the Brazilian Congress on Software: Theory and Practice (CBSOFT) conducted by the same first event moderator. In this panel, five (5) IoT domain practitioners (experts from academy and industry) and audience were motivated to discuss the same previous study questions. The moderator acted as the reporter in the panel discussion, gathering the central issues, and producing a document reporting the notes.

Next, the notes from both events were collected and analyzed. Besides, open coding procedures based on GT
(Strauss and Corbin 1990) were used and allowed the identification of nine categories of IoT concerns: **Architecture**, **Interoperability**, **Professional Quality Properties**, **Requirements**, **Scale**, **Social**, **Security**, and **Testing**.

### 4.1.3 From the Governmental Report

Many initiatives from governments and organizations have demonstrated a growing interested in IoT. In this context, the Brazilian National Bank of Economic Development (BNDES), organized a study to promote economic and social development by analyzing and proposing public policies for IoT. The idea is to obtain an overview of the impact of IoT in Brazil, understanding the country competencies and defining initial aspirations for promoting IoT in Brazil, as it had been documented in a plan of action.

The research is being conducted since the beginning of 2017, and the material<fnref n="2" /> available was used to recover IoT concerns. These results were based on registered initiatives developed by 11 countries and the European Union on IoT, initiatives developed in global scope and interviews with experts to the implementation of the area in Brazil. It was also based on textual analysis on 28 textual documents available. Reading the material allowed extracting information focusing on the presented concerns, analyzing, and similarly organizing them as the two previous information sources (the literature and practitioners). From this, seven categories of IoT concerns emerged: **Data**, **Interoperability**, **Network**, **Professionals**, **Regulation**, **Security**, and **Things**.

## 4.2 Output: Putting all together

Extracting the perception and concerns regarding IoT from different points of view was essential for the strengthening and direction of our research. For instance, it is possible to observe that, although there are different perspectives, they become complementary to represent the concerns to produce quality software systems. Together, the three sources provided 14 different concerns, which must be met in favor of higher quality IoT software systems (Figure 2).

We present each of the 14 categories with a definition and some example from the input source to support its comprehension:

* **Architecture** - Issues and concerns regarding design decisions, styles, and the structure of IoT systems. Excerpt example: "Finding a scalable, flexible, secure and cost-efficient architecture, able to cope with the complex IoT scenario, is one of the main goals for the IoT adoption." (Borgia 2014);

* **Data** - It refers to the management of a large amount of data, and how to recover, represent, store, interconnect, search, and organize data generated by IoT from so many different users and devices. Excerpt example: "This new field offers many research challenges, but the main goal of this line of research is to make sense of data in any IoT environment. It has been pointed out

that it is always much easier to create data than to analyze them." (Gil et al. 2016);

* **Interoperability** - Related to the challenge of making different systems, software, and things to interact for a purpose. Standards and protocols are also included as issues. Excerpt example: "The end goal is to have Plug n' Play smart objects which can be deployed in any environment with an interoperable backbone allowing them to blend with other smart objects around them." (Gubbi et al. 2013);

* **Management** - The application of management activities, such as planning, monitoring, and controlling, in the IoT system will raise the interaction of different things. Excerpt example: "IoT is a very complex heterogeneous network, which includes the connections among various types of networks through various communication technologies [...]. Addressing things management is still a challenge." (Xu et al. 2014);

* **Network** - Technical challenges related to communication technologies, routing, access, and addressing schemes considering the different characteristics of the devices. Excerpt example: "Designing an appropriate topology, routing, and MAC layer is critical for scalability and longevity of the deployed network" (Gubbi et al. 2013);

* **Professionals** - To invest resources in the training of engineers and other professionals can result in the creation of a strategic differential. However, the scenario is different, so more than proficiency in programming languages of lower level; the professional who develops software for IoT should be able to carry out the customization of solutions already developed for specific demands;

* **Quality Properties** - Although some specific properties such as interoperability, privacy, and security are primarily discussed, several other quality attributes are considered different in the IoT domain such as capacity (device and network), installation difficulty, responsiveness, context awareness. Contemplate non-functional requirements by considering what the individual sees, feels and how the things can contribute to that;

* **Regulation** - Governments are working on crucial issues that require significant investment and coordination between the public and private sectors. Within regulatory issues, standardization is one of the most critical, and there is no single strategy to follow. In some cases, it is necessary for the creation of specific laws and institutions regulate privacy and security issues, a topic that is debated today by all the countries mentioned in the report;

* **Requirements** - Considering the IoT nature, with a tendency for more innovation, mainly based on ideas, the requirements can be presented in a less structured

<footnote n="2">² https://goo.gl/nmFece</footnote>
form. Another concern is that the user can also be a developer since the solutions reach different types of individuals and devices and new features can be attached;

*   **Scale** - To develop, manage, and maintain a large-scale software system is a concern. As the number of devices in the software system increases along with the number of relationships, new technologies are needed to maintain a software system with the quality level required.

*   **Security** - Issues related to several aspects to ensure data security in IoT systems. For that, a series of properties, such as confidentiality, integrity, authentication, authorization, non-repudiation, availability, and privacy, should be investigated. Excerpt example: "*Security issues are central in IoT as they may occur at various levels, investing technology as well as ethical and privacy issues [...] This is extremely challenging due to the IoT characteristics.*" (Borgia 2014);

*   **Social** - Concerns related to human end-user to understand the situation of its users and their appliances. Excerpt example: "*For a lay person to fully benefit from the IoT revolution, attractive and easy to understand visualization have to be created.*" (Gubbi et al. 2013);

*   **Testing** - IoT will provide unprecedented universal access to connected devices. Testbed and acceptance tests are sophisticated, and there is a greater need for other types of tests, for example, usability, integrity, security, performance;

*   **Things** - For the devices, which includes their access and gateways, there are several non-functional restrictions inherent to IoT that should be present in the products. These restrictions increase the total cost of the objects, such as an energy consumption alternative when it is not possible to connect to the power grid.

It is interesting to notice that the concerns are usually interrelated, confirming the multidisciplinary nature of IoT. For example: "*For technology to disappear from the consciousness of the user, the Internet of Things demands software architectures and pervasive communication networks to process and convey the contextual information to where it is relevant*" (Gubbi et al. 2013), this excerpt is coded for an architectural issue and network as well.

Another example is "*Central issues are making full interoperability of interconnected devices possible, providing them with an always higher degree of smartness by enabling their adaptation and autonomous behavior, while guaranteeing trust, privacy, and security.*" (Atzori et al. 2010), which was coded both for interoperability and for security issues. Provide solutions to the issues presented here can be tricky to achieve due to the diversity of concerns, a variety of devices

We can see that each source has its particularities, and some are consistent with its origin. It is expected that practitioners have a more technical and in-depth view presenting more individual and software-oriented issues regarding IoT software systems. The concerns with **management** and **quality** are transversal to the implementation of such software systems and can be observed in any point of view, but the practitioners have specific concerns of quality, such as meeting non-functional requirements, which bring more specificity and definition to this issue. Also, **requirements** and **testing** issues are still somewhat open on how to represent, describe, and integrate software systems. These three aspects must be met in the software systems regardless of their scale, which in IoT software systems can reach the ultra-large-scale, bringing their associated problems. These three concerns are affected by one aspect that we observed in the literature review. From the characteristics extracted, we could observe that IoT properties and its characterization are not explicit, neither the characteristics that can affect the development process of such applications. Unclear characteristics can impair requirements, which in turn affects the testing, hindering the overall system quality. We consider that this difficulty is partially due to conceptual aspects, since IoT and the related concepts are not yet established and not enclosed by a single definition, being the concept still under discussion (Shang et al. 2016).

Considering the increasing number of interconnected devices, the size or **scale** of IoT software systems can grow consistently. The systems can achieve a more wide-scale coupled with complicated structure-controlling techniques, which brings new challenges to their design and deployment (Huang et al. 2017). New solutions for architectural foundations, orchestration, and management are essential for dealing with scale issues, especially for Ultra Large Scale Systems such as Smart Cities and autonomous vehicles (Roca et al. 2018).

Concerning **regulation**, some actions are being made, from governments<fnref n="3" /> and other institutions<fnref n="4" />, to form an adequate legal framework. It is necessary to prompt action to provide guidance and decisions regarding governance and how to operate IoT applications in a lawful, ethical, socially and politically acceptable way, respecting the right to privacy and ensuring the protection of personal data (Caron et al. 2016; Almeida et al. 2018).

For the devices, sensors, actuators, tags, smart objects and all the **things** in the Internet of Things, or of Everything, these are some of the aspects that should be taken into consideration: a) resources and energy consumption, since intelligent devices should be designed to minimize required resources as well as costs; b) Deployment since they can be deployed one-time, or incrementally, or randomly depending on the requirements of applications; c) Heterogeneity and Communication: different things interacting with others, they must be available, able to communicate and accessible (Madakam et al. 2015; Li et al. 2015).

<footnote n="3">³ https://aioti.eu/ and
https://ec.europa.eu/commission/priorities/digital-single-market_en</footnote>

<footnote n="4">⁴ https://www.kiot.or.kr/main/index.nx and
https://www.digicatapult.org.uk/</footnote>
<figure><img src="image_5.png" /><figcaption>**Figure 2.** IoT Concerns.</figcaption></figure>

At the intersection between Industry and Literature, we have **architectural** and **social** issues. Both concerns are open due to the area novelty in which there is still an uncovering of how to deal and what to expect. **Architecture** is a recurrent issue in the literature being pointed out by (Liao et al. 2017) as one of the priority areas for action and reported by (Trappey et al. 2017) to be one of the official objectives of ISO/IEC JTC1. In general, the status is that there still no consolidated standard nor well-established terminologies to uniform advancements for architecture in IoT.

Regarding **social** concerns, given that the objects, devices and a myriad of *things* are likely to be connected to many others, being people one of the actors as well (Matalonga et al. 2017), it is necessary to explore the potential sociotechnical impacts of these technologies (Whitmore et al. 2015). Using such devices to provide information *about* and *for* people are one of the applications. Many challenges and concerns should be addressed to achieve the benefits aimed with IoT. In facilitating the development is required the design of data dissemination protocols, and evolve the solutions for privacy, security, trust maintenance, and effective economic models (Guo et al. 2012). As affirmed by (Dutton 2014), if not designed, implemented, and governed in an appropriate way, these new IoT could undermine such core values as equality and individual choice.

At the intersection between Industry and Government, we have the concern of **professionals**, which is represented by the preparation of their skills and knowledge as for the teams that should be multidisciplinary to meet IoT premises. If requirements, testing, and other technical activities are under discussion, we need to think about the professional who will satisfy and perform such activities (Yan Yu et al. 2010). With the development of IoT, different people, systems, and parties will have a variety of requirements; one of the abilities required is how to translate these requirements into new technologies and products. Other skills are related to manage the frequency of information generated, manage the ubiquity and actors involved in interactions, develop and maintain privacy and security

policies (Tian et al. 2018). As the area is new and it is defining the professionals and teams that will work on it too, so it is essential to discuss the professional, develop skills and knowledge necessary for this new generation of innovators, decision-makers and engineers (Kusmin et al. 2017).

Connectivity, Communication, **Network**, and the multiple related concepts that enable the evolution of interconnected objects is a critical point for the materialization of IoT (Gubbi et al. 2013). One of the main challenges of this scenario is a vast amount of information identified, sensed and act upon that must be processed mostly in real- or near-real time with an unobtrusive delivery of personalized manner, ensuring data availability and reliability, the channel between devices, and between the human and devices (Mihovska and Sarkar 2018). Many open challenges require new approaches to a quality network in this scenario. Therefore research should progress into practice to ensure the benefits for the users. Together with Network concerns, we have **Data** issues. In a world with “anytime, anyplace connectivity for anyone and connectivity for anything” (Conti 2006), we can see how quickly data can be generated and how vast amounts of information are created. Some of the challenges are related to the continuous and unstructured creation of connection points (devices, things); the persistence of data objects, unknown scale, and data quality (Uncertainty, Redundancy, Ambiguity, Inconsistency, Incompleteness) (Gil et al. 2016).

However, above these, **security** and **interoperability** concerns are at the center of all IoT related discussions. For IoT, for example, it enables computing capabilities in *things* around us and interoperability is the attribute that enables the interaction among heterogeneous devices, with varied requirements of different applications. Interoperability can range from different levels like technical, syntactical, semantic, and organizational, which varies according to the software system needs. Complete interoperability is an open question for current software and essential for IoT due to its comprehensive nature. Issues like encryption, trust, privacy, and any security-related concerns are of utmost importance since IoT are inserted in someone's personal life or into the industry. High coverage procedures should guarantee software system security and trustworthiness.

## 5 IoT Facets

IoT leads to an era where, rather than developing software, we need to engineer software systems embracing multidisciplinarity, integrating different areas for the realization of successful products according to their purposes. It means that Software is one of the IoT facets, which, together with others, are necessary for IoT materialization. Aiming at identifying those different facets that characterize this multidisciplinarity, we performed an analysis of the IoT definitions identified in the literature review (section 3.1). This analysis was based on GT procedures (Strauss and Corbin, 1990). The 29 extracted IoT definitions were organized in a table with one field of “code” to assign an area, topic, discipline (named here as a facet)
related to a definition excerpt. This coding process was executed by three researchers separately, using separate and independent documents. An example of the document is presented in Figure 3. It is composed of three columns: a) Index: with the definition number; b) Definition: where each definition is presented as extracted from the paper; c) Code: with the codes associated with portions of the definition, with a color scheme to help their identification.

<figure><img src="image_6.png" /><figcaption>**Figure 3.** Example of a document filed with the definitions and marked with coding.</figcaption></figure>

There were two rounds of discussions, first with two, then with all the three researchers. It was done to discuss the similarity and differences in the coding, support the concepts, and reduce bias, until reaching a consensus. From this analysis, we would like to have a set of facets, based on the data we had so far, and be able to sort among the most used to present a minimal set of areas that must be considered when building an IoT software system. After the documents merge, meetings for discussions were held, some of the discussion was regarding the coding granularity level. For example, *network* and *telecommunication* can all be part of a single facet called *connectivity*, aiming to encompass several concepts and keep the same level of abstraction. As a result of this process, we came to the consensus that an IoT software system should consider seven different facets that are defined below including some examples related to the identified challenges and some potentially used technologies:

* **Connectivity** – the Internet is a relevant concept naturally involved in the IoT paradigm. We argue that it is necessary to have available a medium by which *things* can connect to materialize the IoT paradigm. It is essential some form of connection, a network for the development of solutions, and our idea is not to limit Internet-only connectivity but to be able to cover other media.

* **Related challenges example:** One of the concerns for connectivity is the traffic management and control to deal with the enormous data generated by these devices and guarantee the quality of service (Bera et al. 2017; Li et al. 2018).

* **Related technologies example:** It uses specific solutions according to the application domain and tries to re-use legacy cellular infrastructure and invest in novel communication solutions. It is mostly based on wireless communication technologies that could be divided into Short-Range, Long-Range, and Cellular-based.

* **Things** - In this sense, it means the *things* by themselves in IoT. Tags, sensors, actuators, and all hardware that can replace the computer, expanding the connectivity reach.

* **Related challenges example:** To deal with *heterogeneity and scale* (Rojas et al. 2017), *distribution* -geographically distributed and sometimes, in inaccessible and critical regions (Chen et al. 2018) as well as **mobility** – IoT devices are not static they tend to move between different coverage areas (Bera et al. 2017), are issues related to requirements to be covered in IoT.

* **Related technologies example:** Many solutions were combined to build devices like sensors, actuators, smartphones, microcontrollers, interactables, cameras, communication and network enablers, and others. Some systems treat *things* giving a virtual representation of these devices enabling remote access, and control of them.

* **Behavior** - The existence of *things* is not new nor their intrinsic capacities. What IoT provides is the chance of enhancements in the *things*, extending their behaviors. In the beginning, the *things* in IoT systems were objects attached to electronic tags, so these systems present the behavior of Identification. Subsequently, sensors and actuators composing the software systems enabled the Sensing and Actuation behaviors, respectively. It can be necessary the use of software solutions, semantic technologies, data analytics, and other areas to enhance the behavior of *things*.

* **Related challenges example:** Some emerged behavior cannot be attributed to a single system but results from the interplay of some or all systems in the network. Therefore, each system involved must adjust its behavior according to the common goal, which is an open issue (Brings 2017).

* **Related technologies example:** The first and most common way to treat behavior is in stages, where the more significant behaviors are constituted by, the smaller ones, with this it is possible to reduce the complexity of taking care of the behaviors. Another way to manage behavior is through the use of state machines (Jackson, 2015; Giammarco, 2017).

* **Smartness** - Smartness or Intelligence is related to Behavior but as to managing or organizing it. It is more referring to orchestration associated with *things* and to
what level of intelligence technology can evolve their initial behavior.

○ **Related challenges example:** What makes in many cases a system smart is not only the devices that are used and the decision-making process but the whole solution architecture as well (Atabekov et al. 2015), which leads to an architectural challenge in order to achieve smartness.

○ **Related technologies example:** It uses actuators, decision-makers, and acting according to the data autonomously collected and treated to perform some activity in the environment. It uses techniques from artificial intelligence, machine learning, neural networking, and fuzzy logic to deal with the data.

* **Problem Domain** - A problem domain is the area of expertise or application that needs to be examined to solve a problem. IoT software systems are developed to reach a goal for a specific purpose. At this point, we are starting from a goal (problem domain) to reach a solution (software system). Focusing on a problem domain is merely looking at only the topics of interest and excluding everything else. It, in general, directs the objective of that solution.

○ **Related challenges example:** IoT applications development is a multi-disciplined process where knowledge from many concerns intersects. This development assumes that the individuals involved in the application development have similar skills. It is in apparent conflict with the varied set of skills required during the overall process involving this engineering (Patel and Cassou 2015)

○ **Related technologies example:** It varies, but the majority deals with software activities related to analysis, design, and activities to understand the problem domain.

* **Interactivity** - It refers to the involvement of actors in the exchange of information with *things* and the degree to which it happens. The actors engaged with IoT applications are not limited to humans. Therefore, beyond the sociotechnical concerns surrounding the human actors, we also have concerns with other actors like animals and the interactions thing-thing. The degree to which it happens works together with the medium through which *things* can connect (connectivity) so that in addition to being connected, they can understand (interoperability).

○ **Related challenges example:** The wide range of heterogeneity issues introduced by among different IoT devices. Standardization, therefore, is a must but is not enough as no single standard can cover everything, as well as some organizations (manufacturers, software companies), would like to follow different

standards or even proprietary protocols (Dalli and Bri 2016).

○ **Related technologies example:** To guarantee communication: HTTP, XMPP, TCP, UDP, CoAP, MQTT, and others. To guarantee to understand: JSON, XML, OWL, SSN Ontology, COCI, and others.

* **Environment** - The problem and the solution are embedded in a domain, an environment, or a context. This facet seeks to represent such an environment and how the context information can influence its use.

○ **Related challenges example:** *Things* can be created, adapted, personalized, and rely on contextual data. The integration of *things* with the social and natural environment can contribute to improving this contextual data and is both a challenge and a research opportunity (Davoudpour et al. 2015).

○ **Related technologies example:** In general, the environments are composed of sensors and actuators to sense and change an ambient state. Technologies like IoT, cloud, smart objects, middleware's, Wireless Sensor Networks, Vehicular Ad-hoc Networks, edge computing, artificial intelligence, machine learning, data mining can be employed on these systems.

Section 6.1 presents the facets regarding an example of a specific IoT application. From the data recovered in our research, we realize that concepts and properties related to IoT change according to the context and actors involved. For this reason, the representation should be as comprehensive as possible to represent all aspects involved, motivating the IoT facets proposition.

# 6 Defining the Framework

As observed in our investigations, the IoT scenario is covered by **concerns** (discussed in Section 4.4) that are seen and treated according to **facets** (detailed in Section), which leads to challenges for its development. In this context, strategic decisions are essential to the development and need to handle all factors involved in IoT without prejudice to the original software life-cycle concerns with deadlines, costs and quality levels of products and processes (Pfleeger and Atlee 1998; Fitzgerald and Stol 2017). In our proposal, we consider both concerns and facets of IoT development.

In the latest technologies, the software is only one of the components since further development is necessary for requirements representation, data infrastructure, network configuration, and others (Tang et al. 2004). Our aim is regarding the conceptual organization of the recovered data that should consider the requirements of different stakeholders and the activities in the different IoT facets. Having such a conceptual structure, we do not aim that it will guide the software system development but rather to organize the concepts more explicitly and support the decision making when engineering IoT software systems. With this goal in mind, we have identified the Zachman's
Framework (Zachman 1987) as the structure that could support the organization of the concepts. For this reason, we tailored the framework, presented in Section 2, as in Figure 4. There are several definitions for IoT, but the concept refers to a paradigm that allows composing software systems from uniquely addressable objects (*things*) equipped with identification, sensing or action behaviors and processing capabilities that can communicate and cooperate to reach a goal. This understanding encompasses the definitions recovered from the literature review and states the composing and characteristic of IoT. The main difference between traditional software systems regards heterogeneity, scale, and the possibilities inherent to the IoT paradigm.

The Zachman's Framework is generic and flexible enough to be used in different scenarios embedding different points of view, so our choice to use it to organize the information we gathered. Because of the meaning of IoT, we will have the following demands to develop an IoT software system:

*   **A paradigm that allows composing systems:** IoT is not just the *things* by themselves. It represents a more substantial aggregate consisting of several parts. It implies that there is not a single IoT solution, but a myriad of options that can derive from the *things* and other systems available. It will require some domain and business-specific strategies.

*   **From uniquely addressable objects (things):** *Things* should be able to be distinguished using unique IDs, a unique identification for every physical object. It concerns the network solutions and hardware technologies required to devise the composing parts of the IoT paradigm.

*   **Equipped with identifying, sensing or acting behaviors and processing capabilities:** Once the object is identified, it is possible to enhance it with personalities and other information and enable it to connect, monitor, manage and control *things*. This understanding implies that depending on the “smartness” degree required for a setting,” a software solution can be more robust and involve other technical arrangements, such as artificial intelligence.

*   **That can communicate and cooperate:** The other part of the paradigm, alongside with the *things*, is the Internet. The Internet (in a broader sense) is the connection channel of the available *things*. Together with this network solution, *things* should be able to communicate, interchange, share, and other issues. For this, a set of characteristics, such as interoperability, should also be present in the *things*.

*   **To reach a goal:** This whole scenario is set for a purpose, for a reason, motivated by something. This primary goal is what will guide the development.

This description leads us to tailor the Zachman's Framework in a faceted scheme; each one represents a facet required for an IoT software system (see Figure 4). We argue that a solution for IoT cannot be done without considering all fundamental paradigm aspects, requiring

multidisciplinary technologies and a diverse team to meet them. We consider the IoT facets to address this multidisciplinarity. They were extracted from the literature review and cover a set of dimensions needed to be present, in different degrees, in an IoT software system. This initial set can be extended if needed, as we progressed in the research since it limited to the set of sources dealt with in this research.

Alongside with the facets we have: Perspectives and Communication Interrogatives evolved both from the Zachman Framework (Sowa and Zachman, 1992). The perspectives were divided as control (Business, Executive and User), who support the definition of the problem domain, and construction (Architect, Engineer, Technician, and User) parts, that will specialize the facets to solve the problem. We are considering the user perspective as a hybrid because the future vision is that users have active participation in the construction of IoT solutions (Singh and Kapoor, 2017).

The framework considers all the perspectives involved in the planning, conception, building, usage, and maintaining activities of IoT software systems:

*   **Executive Perspective** - It focuses on the system scope and management plans, and how it would relate to a particular context.

*   **Business Perspective** - It is concerned with the business models, which constitute business design, how they relate, and how the system will be used.

*   **Architect Perspective** - This perspective translates the system model designed and determines the logic behind a system considering data elements, process flows, and functions are representing the business entities and processes.

*   **Engineer Perspective** - It corresponds to the technology models, which must tailor the model to the programming languages details, devices, or other required supporting technology.

*   **Technician Perspective** - The developer follows detailed specifications to build modules, sometimes without being concerned with the overall context or structure of the system.

*   **User Perspective** - It concerns the functioning system in use.

From the guidelines provided in the Zachman's framework, we consider the questions as communication interrogatives for our context since the answer to each question in each perspective, and each facet will give us more direct information leading an engineer closer to the solution specification. These are fundamental questions to outline each perspective:

*   **What** - Referring to the information required for the understanding and management of a system. It begins at a high level, and as it advances in the perspectives, the data description becomes more detailed;

*   **How** - It relates to translating abstract goals into the definition of its operations using software technologies (techniques, technologies, methods, and solutions);
* **Where** - It concerns the activities location; it can be a geographical distribution or something external to the system;

* **Who** - It describes the roles involved with the systems to deal with the facet development, detailing the representation of each one as it advances;

* **When** - It concerns the effects of time over the system, such as the life cycles, describing the transformations and states of the systems;

* **Why** - It concerns to translate the motivation, goals, and strategies going to what is implemented in the facet.

The *perspectives* in the framework should be mapped and updated according to each IoT facet since different stakeholders are concerned with each area. In the questions part, we seek to keep the original questions and adapt the definitions to be clear and cut for the use of IoT. For instance, the “what” is the final product to be delivered by each facet, which in turn can be composed of what each perspective delivers. In software, for example, we have the model built by the software architect, the code made by the developer. They are all part of the final product, the software product. The framework structure will be the combination of these concepts filled in as in Figure 4. Each facet aggregates different knowledge areas, such as software and network. With the simple framework structure, we can organize existing knowledge of software technologies, observing gaps for possible research and development opportunities.

<figure><img src="image_7.png" /><figcaption>**Figure 4.** A Framework for engineering IoT applications.</figcaption></figure>

The framework can be filled with knowledge using a bottom-up approach with studies from the technical literature, practitioners, and real cases. We aim to achieve a complete solution on a small scale, to be evolved incrementally. If any adjustment is necessary, we sought to make available the protocols at Delfos<fnref n="5" /> (The Observatory of the Engineering of Contemporary Software Systems) to facilitate access, dissemination, re-execution, and evolution of the findings in order to keep the body of knowledge updated.

The existing knowledge may or may not be enough to cover the IoT paradigm demands, and this must be

investigated from each facet to develop high-quality software systems. Also, each facet will be responsible not only to meet its original premises but to cover the concerns and essential needs of IoT related to that area, such as those presented in this paper. For instance, security and interoperability (the common concerns from the sources) are transversal concerns and must be addressed in the IoT facets related to *things*, behavior, and connectivity. As we evolve the framework structure and deepen our IoT facets of knowledge, we will seek to provide software technologies to meet the concerns as well. The use of the framework can be performed in three steps. By aligning different stakeholders’ perspectives, we want to characterize the problem domain (Step 1). Then, using the framework structure (Figure 4), we aim to extract relevant information for the project (Step 2), that support the definition of decision-making strategy (Step 3). An example of use detailing the steps is presented in the following section.

## 6.1 Exemplifying the usage of the Framework

Once we have filled the framework with relevant information regarding practices and technologies, considering the different facets and perspectives, we will use it as the basis to support a development strategy. Project information is used to direct and specialize in the framework, to present the concerns that should be taken into account and be used in the strategy to decision making for the specific project.

With this proposal, the goal is not to replace defined activities that are common in the development of traditional software projects. Instead, we hope to address the particularities of IoT projects since they present different and additional characteristics that can bring challenges to its engineering.

This section aims to exemplify the use of the proposed framework. For this, we rely on the results of an IoT software project carried out in the context of an undergraduate software engineering last year discipline of the Computer and Information Engineering course at the Federal University of Rio de Janeiro. Five last periods bachelors’ students with previous knowledge in engineering conventional software systems formed the development team. The course is regularly offered to support the students to work in real problem domain demand and tool-based software engineering environment.

As a case for practice, the development team should provide a software system solution to support the creation of freshwater shrimp in farms. A SEBRAE (Brazilian Service to Support Micro and Small Enterprises)’s claim motivated it: “*Due to the complexity of the production process, and a large number of variables that must be constantly monitored, we suggest the acquisition of software of management, which was not found on the market with enough to be indicated here. Most companies that produce software can provide such a solution, provided that there is a customization of the software.*” A professor (the last author of this paper) and members of the Experimental Software Engineering Group

<footnote n="5">⁵ http://146.164.35.157/</footnote>
mentored the developers. The software project was executed in the first semester of 2018 and the product (Camarão IoT) deployed in July of 2018. Therefore, the proposal was to idealize and to build an IoT software system to support freshwater carniculture in Brazil.

Based on the described motivation, we present a proof of concept of a solution organized in the structure of the proposed framework. This example enables us to show different facets of arrangements in a basic solution. Because the software system had been implemented and design decisions were taken, we mapped the results to exemplify the use of the framework.

### 6.1.1 STEP 1 - Define Problem Characterization:

Given the lack of software solutions and the market opportunity for this product, the proposal was to idealize and to build an IoT software system to support freshwater carniculture in Brazil. Our intention with this exemplification was to take what they accomplished and translate it into the proposed framework.

In this characterization step, from the project context, the Executive, Business and User perspectives proposed in the framework are used to support the identification of different concerns and relevant information that must be considered in the solution to be developed. Different roles expressed their expectations regarding the system in the 5W1H structure. The information was condensed and mapped below:

**Executive Perspective** - The owner represents this perspective and desires a solution that will enable remote and real-time business management. Also, to be able to monitor the overall state of production. Wants to receive notifications of critical conditions and current status, receive periodic reports and estimations, anywhere.

**Business Perspective** - The manager represents this perspective and wants to receive quick and easy information at any time through the used technologies. Modernize production and have greater control to meet the foreign market. Need to define deadlines and demands, receive information about the water tank, consult stock and production, notifications of critical conditions and current status, receive periodic reports, and estimations in real-time.

**User Perspective** - Different personas were established for the user perspective, representing the following roles:

* **Installation oversees** - S/He takes care of the installation and stock, reporting back to the manager when it is necessary. S/He needs something that can help the work with clear and direct visual information of when and what actions to take. The system can help to check stock status, receive notification of demands, and notify manager about the need for purchases.

* **Shrimp keeper** - S/He is responsible for preparing the ration and feeding the shrimps. Wants a system that can make the tanks documentation and their characteristics simpler and easier to understand, that would make the job less stressful. Another point that would help in the day-to-day professional life would be to facilitate the feeding process to avoid repetitive strain injuries. It will be useful to receive feeding schedule, notify biologist shrimp status, visualize tank and shrimp status.

* **Tank keeper** - S/He monitors the tank status, perform measures, and adjust tank conditions. S/He would like to control the tanks more accurately and with a better frequency, without the need to always be running between different tanks. He wants the peace of mind that work is according to the need of the business. Wants to monitor tank status, generate reports, notify critical conditions, secure tank to return to normal conditions, biologist shrimp status, check environmental conditions that can affect the tank and visualize tank and shrimp status.

* **Biologist** - S/He sets the conditions and is responsible for the production health. S/He would like to have past information to be able to perform more precise analyzes and to minimize the error of his estimates, besides being able to compare the evolution of the production in addition to obtaining information about the shrimps in a more accurate and faster way. Wants to update production demand required, update tank conditions to achieve the production demand, define and monitor shrimp health parameters, define and monitor feeding schedule, visualize tank and shrimp status, and generate reports.

As described above, from this step with the framework structure, it is possible to contemplate the different goals for the same solution, thus enriching the initial characterization of the project. Due to the full range of perspectives and goals, the team organizes and prioritizes the primary needs. From this initial part, we defined the primary needs of a system that (1) allows the clear visualization of information regarding the whole process in real-time; (2) support the feeding of shrimp; (3) assist in estimating production and (4) monitor the tank status (Figure 5).

<figure><img src="image_8.png" /><figcaption>Figure 5. System's needs.</figcaption></figure>

Alongside with the needs presented by the control perspectives, it is required to identify which information can indicate a match with facets, which will support the analysis of the body of knowledge to identify relevant knowledge to engineer a solution to that context.

The Problem Characterization template (used in step 1) will be defined to map the identified system needs with each facet of the body of knowledge in a way that could support the identification of the relevant knowledge. The next
activity of this research in this step is the design of this template. It will comprise the investigation of the concerns defining the facets. A preliminary example of the Problem Characterization artifact for this case study is presented in Figure 6. The idea is to capture the need using questions and perspectives; then we want to map them throughout the artifact, enlightening which concerns should be considered in a given context. It aims to bridge the problem to the facets.

<table><caption>**Figure 6.** A preliminary view of the Problem Characterization for this project.</caption><thead><tr><th>Facet</th><th>Concerns</th><th>Status</th></tr></thead><tbody><tr><td rowspan="3">Connectivity</td><td>Mobility required</td><td>✓</td></tr><tr><td>Short-range communication only</td><td>x</td></tr><tr><td>Limited bandwidth</td><td>x</td></tr><tr><td rowspan="3">Things</td><td>Heterogeneous devices</td><td>✓</td></tr><tr><td>Limited battery and memory resources</td><td>✓</td></tr><tr><td>Remote control required</td><td>x</td></tr><tr><td rowspan="3">Behavior</td><td>Traceability of the device is required</td><td>x</td></tr><tr><td>Capture context information</td><td>✓</td></tr><tr><td>Behavior composition</td><td>x</td></tr><tr><td rowspan="3">Smartness</td><td>Self-adaptation property is required</td><td>x</td></tr><tr><td>Decision-making trigger an action</td><td>✓</td></tr><tr><td>Evaluate relevant context information</td><td>✓</td></tr><tr><td rowspan="3">Interactivity</td><td>Semantics influences the interpretation of information</td><td>x</td></tr><tr><td>Cooperation is required</td><td>x</td></tr><tr><td>Seamlessly interaction</td><td>x</td></tr><tr><td rowspan="3">Environment</td><td>Context influences the solution</td><td>✓</td></tr><tr><td>Critical environmental conditions</td><td>x</td></tr><tr><td>Limited infrastructure</td><td>x</td></tr></tbody></table>

## 6.1.2 STEP 2 - Analyzing the Framework

### Structure for decision making

After characterizing the problem domain with the characterization artifact, the next step is to analyze the body of knowledge.

In the context of this proposal, the Framework Structure can be seen as a **Body of Knowledge**. This structure was a body of knowledge, has been proposed at a conceptual level, but it has not yet been wholly populated for the IoT systems. Hence, it is one of the next proposed activities, in which we plan to conduct studies to provide evidence-based findings to fill in the Body of Knowledge. Once Body of Knowledge is organized, it can be specialized to the problem context.

For instance, as presented in Figure 5, one of the needs refers to **(4) monitor the tank status**. This feature represents goals from the owner (Executive perspective), manager (Business Perspective), tank keeper, and biologist (User Perspective) and can be developed by different solutions (Table 3). The body of knowledge specialization should assist in the decision-making to implement the desired solution considering this feature's properties.

<table><caption>**Table 3.** Possible solutions to monitor tank status.</caption><thead><tr><th>Solution Option</th><th>Description</th></tr></thead><tbody><tr><td>Manually</td><td>The manager defines the required shrimp production and requests production report; he communicates verbally to the biologist. The biologist sets new parameters for the tank and goes to the tank keeper to inform him. The tank keeper manually adjusts tank conditions to meet</td></tr></tbody></table>

<table><tr><td></td><td>demand. He also manually collects information for the production report and deliver the report to the manager. There is no technical support in the process.</td></tr><tr><td>Communication Support</td><td>The manager defines the required shrimp production and requests production report; he uses a communication system to inform the biologist. The biologist defines new parameters for the tank and uses the communication system to inform the tank keeper. The tank keeper manually adjusts tank conditions to meet demand. He also manually collects information for the production report and deliver the report to the manager. There is technical support for communication in the process.</td></tr><tr><td>Control Support</td><td>The manager defines the required shrimp production and requests a production report; he uses a control system. The system notifies the biologist that defines new parameters for the tank. The system notifies the tank keeper that manually adjusts tank conditions to meet demand. He also manually collects information for the production report and makes the report available in the system. There is technical support for control in the process.</td></tr><tr><td>Sensing Support</td><td>The manager defines the required shrimp production and requests a production report using the system. The system notifies the biologist that defines new parameters for the tank. The system notifies the tank keeper that manually adjusts tank conditions to meet demand. He automatically collects information from the sensors for the production report and makes the report available in the system. There is technical support for sensing in the process.</td></tr><tr><td>Actuation Support</td><td>The manager defines the required shrimp production and requests a production report using the system. The system notifies the biologist that defines new parameters for the tank. The system notifies the tank keeper that uses the system actuators to adjust the tank conditions to meet demand. He automatically collects information from the sensors for the production report and makes the report available in the system. There is technical support for actuation in the process.</td></tr></table>

The solutions presented are simplified in high-level but are only to exemplify the variety of options dependent on technology, to a greater or lesser degree. For example, if we choose the Sensor Support solution, exemplified in Table 7, it can analyze which relevant knowledge from the body of knowledge should be taken into account, as shown in Table 4. In order to support decision-making to guide the choice and development of the proposed solution, the body of knowledge aims to present the practices and technologies that allow engineers to develop the chosen solution.

<table><caption>**Table 4.** Some examples of possible practices and technologies from the body of knowledge.</caption><tr><td rowspan="2">Sensing Support</td><td>Connectivity</td><td>Bluetooth Low Energy, ZigBee, Z-Wave, NFC (Near Field Communication), RFID (Radio-Frequency Identification), Wi-Fi as enabling technologies, Low-Power Wide-Area technologies, SigFox, Ingenu-RPMA (Random Phase Multiple Access), 2G, 3G, 4G, Software-Defined Network (SDN) and Network Function Virtualization (NFV) and others.</td></tr><tr><td>Things</td><td>Temperature sensor TTC104, temperature sensor DS18B20, luminosity sensor LDR 5mm, rain sensor FC37, rain sensor GROVE, humidity and temperature sensor RHT03, Gravity pH Sensor, and others.</td></tr></table>
<table><tr><td></td><td>Behavior</td><td>Collect water ph-value, water level, water turbidity, water oxygenation, water salinity, water temperature.</td></tr></table>

### 6.1.3 STEP 3 – Generate decision-making Strategy

The output from the previous step (Table 4) should be presented as a set of software practices and technologies, with options of the body of knowledge specialization, and will compose the strategy to support decision-making to drive the solution.

From the problem domain established (the context), the team started the solution engineering. The project was conducted with the team working together. Therefore, there was no formal division of work for construction roles such as Architect, Engineer, and Technician perspectives. They worked as a group to achieve the expected results. For this reason, in this exemplification, we cannot represent different perspectives. It is for illustration purposes and does not allow to demonstrate the full framework potential yet, which is a crucial issue in the continuity of this research.

The solution implemented for the problem (4) monitor the status of the tank is presented in Figure 7 and was implemented in a floater. The floater collects data from the water tank where it was deployed, and it works at each determined interval of time. An operator can adjust the frequency in which the dashboard will update the information received from the sensors, implemented in the floater. A dashboard panel was implemented to enable the visualization of the data collected by the floater and attends the problem stated in (1) allows the clear visualization of information regarding the whole process in real-time. In this context, it is a technological arrangement for data exhibition, where the data producers are the sensors in the floater, which through the connectivity with Wi-Fi can share data with the dashboard to exhibit the data. The overall Floater solution encompasses (Figure 7):

* **Behaviors:** sensing and data collection to collect water level, water turbidity, and water temperature as well as processing, to provide data for the dashboard.

* **Things:** the water level sensor, water turbidity sensor, water temperature sensor, and water salinity were implemented in an Arduino board that worked as the processing unit.

* **Interactivity:** interacts with the dashboard to provide data.

* **Connectivity:** supports the provision of data for the dashboard, implemented by a Wi-fi module in the Arduino.

* **Environment:** the water tank was the environment settled for the sensors to collect data and the network layer used for connectivity.

<table><caption>Figure 7. Floater solution implemented for the need (4).</caption><thead><tr><th>FLOATER</th><th>What</th><th>How</th><th>Where</th><th>Who</th><th>When</th><th>Why</th></tr></thead><tbody><tr><td></td><td>Collect water level</td><td>Water level sensor</td><td>Water tank</td><td>Arduino</td><td>Schedule time</td><td>Monitor tank status</td></tr><tr><td></td><td>Collect water turbidity</td><td>Turbidity sensor</td><td>Water tank</td><td>Arduino</td><td>Schedule time</td><td>Monitor tank status</td></tr><tr><td></td><td>Collect water temperature</td><td>Temperature sensor</td><td>Water tank</td><td>Arduino</td><td>Schedule time</td><td>Monitor tank status</td></tr><tr><td></td><td>Collect water salinity</td><td>Salinity sensor</td><td>Water tank</td><td>Arduino</td><td>Schedule time</td><td>Monitor tank status</td></tr><tr><td></td><td>Provide data</td><td>Dashboard</td><td>Network Layer</td><td>Arduino</td><td>Anytime</td><td>Enable status visualization</td></tr></tbody></table>

It is necessary to emphasize that the previously described context is only a simplified example of using the framework and does not represent its full use. It was used for illustrating, in a real case scenario, how the different facets overlap and impact each other. It requires a multidisciplinary view of the problem and an adequate development strategy to embrace different disciplines and skills for the accomplishment of successful IoT software systems. We understand that more research is needed to address the open points and to evolve the proposal in general. It represents future tasks to be conducted throughout the continuity of this research.

## 7 Final Remarks

The emergence of IoT software systems brings new challenges in software engineering. To address these challenges, we should change our way of developing a software system from a monolithic structure to a broader multidisciplinary approach. This paper has presented the results obtained by analyzing data acquired through different strategies, which identified challenges in engineering IoT software systems and the initial results of a conceptual framework to support its development. First, we identified concerns from the technical literature, practitioners, and a government report. Next, we presented the facets that compose IoT software systems, derived from a qualitative study. These results can support practitioners in evaluating risks to construct IoT applications and highlight some research opportunities for researchers. Then we presented a conceptual framework, a way of summarizing the results of the executed studies and structurally present the multidisciplinarity of IoT. This structure shall be filled with the existing knowledge of software technologies. Empty cells can identify current technology gaps to engineer IoT software systems. The contribution of this work explains a set of concerns that need to be investigated, showing that it is necessary to distinguish this new software system from traditional ones. Also, the work evolves the Zachman's framework, to allow the necessary multi-facets representation.

### 7.1 Threats to validity

The literature review used only Scopus as a search engine so that it may be missing some relevant studies. However, from our experience, it can give reasonable coverage when performing together snowballing procedures - backward and forward (Matalonga et al. 2015; Motta et al. 2016). Data extraction and interpretation biases were mitigated with crosschecking between two researchers and by having a third researcher to revise the results. All phases of this review were peer-revised; any doubt was discussed
among the readers, to reduce selection bias. We have not
performed a Quality Assessment regarding the research
methodology of the selected studies due to the lack of
information in the secondary reports. Therefore, it is a threat
to this study validity. However, the triangulation with data
acquired of practitioners and information extracted from the
government report strengthened the representativeness of
data and reduced the researchers' bias, powering the results.

From both the data collected from **practitioners** and the **government**, the interpretation of data was supported by the practices of GT, which allowed to get consistency among researchers and shared an understanding of the central concepts. However, other perspectives could be used for data interpretation, imposing a risk of changing the results. It represents a threat to any qualitative study and constitutes a menace that we cannot completely mitigate.

## 7.2 Ongoing works

We foresee some scenarios of proposed framework utilization. As envisioned contributions of its use, initially, we expect the production of scientific research which considers essential knowledge to practitioners concerning the problem domain. Such knowledge will compose the body of knowledge, which can be useful for both researchers and practitioners sharing and exchanging it. We consider that the evidence-based facets and perspectives have the potential to support the collection of various practices and technologies that can be used in IoT. We expect that the more a facet is filled in a given perspective in response to a question (for example, response to the how, in the engineering perspective, in the behavior facet) more evidence of information will exist about it, which aids the decision-making in practice. In turn, the lack of answers (for example, an empty cell in the body of knowledge) may represent a research opportunity for the academy. In this sense, opportunities and risks are opposites, since an opportunity for researchers is a risk for practitioners.

Once we have filled the cells, it is possible that some will continue empty, since current technologies do not meet IoT needs, representing research opportunities; and both practice and research can get a better observation of what we know and do not know regarding development, since it will allow visualizing where the engineering stands regarding IoT.

Our next steps include the filling of the facets in the manner proposed by Zachman (Sowa and Zachman 1992). However, our primary research aims to fill the cells in the matrix. We conjecture that some of the slots will be empty or partially filled, which means the available software technologies will not support such activity in the way required for IoT. Therefore, it can represent research and development opportunities, which are necessary for the establishment of IoT as a reality. Another conjecture is that some of the concerns can repeat themselves in different slots and different facets, what we call transversal challenges. These cross-sectional slots represent broader concerns that should cover the IoT software system as a whole, for example, security and interoperability issues. We aim to investigate transversal challenges in the nearest future. After

that, we plan to evaluate and refine this conceptual
framework.

# 8 Declarations

**Availability of data and materials**

Details of the protocol are available in
https://goo.gl/cZVVDc.

**Competing interests**

The authors declare that they have no competing
interests.

**Funding**

We thank CNPq for the grant. Professor Travassos is a CNPq Researcher. This study was financed in part by the Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - Brasil (CAPES) - Finance Code 001.

**Consent for participation and publication**

Not applicable.

**Acknowledgments**

Not applicable.

# References

Agina A, Matheus Edward IY, Shalannanda W (2016) Enhanced information security management system framework design using ISO 27001 and Zachman framework - A study case of XYZ company. In: 2016 2nd International Conference on Wireless and Telematics (ICWT). IEEE, pp 62–66

Alegre U, Augusto JC, Clark T (2016) Engineering context-aware systems and applications: A survey. J Syst Softw 117:55–83. doi: 10.1016/j.jss.2016.02.010

Almeida VAF, Doneda D, Moreira da Costa E (2018) Humane Smart Cities: The Need for Governance. IEEE Internet Comput 22:91–95. doi: 10.1109/MIC.2018.022021671

Andrade RMC, Carvalho RM, de Araújo IL, et al. (2017) What Changes from Ubiquitous Computing to Internet of Things in Interaction Evaluation? In: International Conference on Distributed, Ambient, and Pervasive Interactions. pp 3–21

Aniculaesei A, Grieser J, Rausch A, et al. (2018) Towards a holistic software systems engineering approach for dependable autonomous systems. In: Proceedings of the 1st International Workshop on Software Engineering for AI in Autonomous Systems - SEFAIS ’18. ACM Press, New York, New York, USA, pp 23–30

Atabekov A, Starosielsky M, Lo DC-T, He JS (2015) Internet of Things-Based Temperature Tracking System. In: 2015 IEEE 39th Annual Computer Software and Applications Conference. IEEE, pp 493–498

Atzori L, Iera A, Morabito G (2010) The Internet of Things: A survey. Comput Netw 54:2787–2805. doi: 10.1016/j.comnet.2010.05.010
Badreddin O (2013) Thematic Review and Analysis of Grounded Theory Application in Software Engineering. Adv Softw Eng 2013:1–9. doi: 10.1155/2013/468021

Basili VR, Caldeira G, Rombach HD (1994) Goal Question Metric Paradigm

Bauer C, Dey AK (2016) Considering the context in the design of intelligent systems: Current practices and suggestions for improvement. J Syst Softw 112:26–47. doi: 10.1016/j.jss.2015.10.041

Bera S, Misra S, Vasilakos A V. (2017) Software-Defined Networking for the Internet of Things: A Survey. IEEE Internet Things J 4:1994–2008. doi: 10.1109/JIOT.2017.2746186

Biolchini J, Mian PG, Candida A, Natali C (2008) Software and Data Technologies. Springer Berlin Heidelberg, Berlin, Heidelberg

Bondar S, Hsu JC, Pfouga A, Stjepandić J (2017) Agile digital transformation of System-of-Systems architecture models using the Zachman framework. J Ind Inf Integr 7:33–43. doi: 10.1016/j.jii.2017.03.001

Borgia E (2014) The Internet of Things vision: Key features, application, and open issues. Comput Commun 54:1–31. doi: 10.1016/j.comcom.2014.09.008

Brings J (2017) Verifying Cyber-Physical System Behavior in the Context of Cyber-Physical System-Networks. In: 2017, IEEE 25th International Requirements Engineering Conference (RE). IEEE, pp 556–561

Caron X, Bosua R, Maynard SB, Ahmad A (2016) The Internet of Things (IoT) and its impact on individual privacy: An Australian perspective. Comput Law Secure Rev 32:4–15. doi: 10.1016/j.clsr.2015.12.001

Carver J (2007) The Use of Grounded Theory in Empirical Software Engineering. In: Empirical Software Engineering Issues. Critical Assessment and Future Directions. Springer Berlin Heidelberg, Berlin, Heidelberg, pp 42–42

Chen G, Tang J, Coon JP (2018) Optimal Routing for Multihop Social-Based D2D Communications in the Internet of Things. IEEE Internet Things J 5:1880–1889. doi: 10.1109/JIOT.2018.2817024

CNI CN da I (2016) Indústria 4.0: novo Desafio para an indústria Brasileira. Indicadores CNI 17:13

Conti JP (2006) ITU Internet Reports 2005: The Internet of Things. Commun Eng 4:20. doi: 10.1049/ce:20060603

Costa B, Pires PF, Delicato FC (2017) Specifying Functional Requirements and QoS Parameters for IoT Systems. In: 2017 IEEE 15th Intl Conf on Dependable, Autonomic and Secure Computing, 15th Intl Conf on Pervasive Intelligence and Computing, 3rd Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress(DASC/PiCom/DataCom/CyberSciTech). IEEE, pp 407–414

Dalli A, Bri S (2016) Acquisition devices in the internet of things: RFID and sensors. J Theor Appl Inf Technol 90:194–200

Davoudpour M, Sadeghian A, Rahnama H (2015) Synthesizing social context for making the Internet of Things environments more immersive. In: 2015 6th

International Conference on the Network of the Future (NOF). IEEE, pp 1–5

de Farias CM, Brito IC, Pirmez L, et al. (2017) COMFIT: A development environment for the Internet of Things. Future Gener Comput Syst 75:128–144. doi: 10.1016/j.future.2016.06.031

de Villiers D (2001) Using the Zachman Framework to Assess the Rational Unified Process Overview of the Zachman Framework. Ration Edge

Desolda G, Ardito C, Matera M (2017) Empowering End Users to Customize their Smart Environments. ACM Trans Comput-Hum Interact 24:1–52. doi: 10.1145/3057859

Dutton WH (2014) Putting things to work: Social and policy challenges for the Internet of things. Info 16:1–21. doi: 10.1108/info-09-2013-0047

Fitzgerald B, Stol K-J (2017) Continuous software engineering: A roadmap and agenda. J Syst Softw 123:176–189. doi: 10.1016/j.jss.2015.06.063

Gil D, Ferrández A, Mora-Mora H, Peral J (2016) Internet of Things: A Review of Surveys Based on Context-Aware Intelligent Services. Sensors 16:1069. doi: 10.3390/s16071069

Gluhak A, Krco S, Nati M, et al. (2011) A survey on facilities for experimental internet of things research. IEEE Commun Mag 49:58–67. doi: 10.1109/MCOM.2011.6069710

Goethals FG, Snoeck M, Lemahieu W, Vandenbulcke J (2006) Management and enterprise architecture clic The FAD(E)E framework. Inf Syst Front 8:67–79. doi: 10.1007/s10796-006-7971-1

Gubbi J, Buyya R, Marusic S, Palaniswami M (2013) Internet of Things (IoT): A vision, architectural elements, and future directions. Future Gener Comput Syst 29:1645–1660. doi: 10.1016/j.future.2013.01.010

Guo B, Yu Z, Zhou X, Zhang D (2012) Opportunistic IoT: Exploring the social side of the internet of things. In: Proceedings of the 2012 IEEE 16th International Conference on Computer Supported Cooperative Work in Design (CSCWD). IEEE, pp 925–929

Huang J, Duan Q, Xing C-C, Wang H (2017) Topology Control for Building a Large-Scale and Energy-Efficient Internet of Things. IEEE Wirel Commun 24:67–73. doi: 10.1109/MWC.2017.1600193WC

IEEE (2004) Guide to the Software Engineering Body of Knowledge. IEEE Computer Society Press

Jacobson I, Spence I, Ng P-W (2017) Is there a single method for the internet of things? Commun ACM 60:46–53. doi: 10.1145/3106637

Khaitan SK, McCalley JD (2015) Design Techniques and Applications of Cyberphysical Systems: A Survey. IEEE Syst J 9:350–365. doi: 10.1109/JSYST.2014.2322503

Kusmin M, Saar M, Laanpere M, Rodriguez-Triana MJ (2017) Work in progress — Smart schoolhouse as a data-driven inquiry learning space for the next generation of engineers. In: 2017 IEEE Global Engineering Education Conference (EDUCON). IEEE, pp 1667–1670
Larrucea X, Combelles A, Favaro J, Taneja K (2017) Software Engineering for the Internet of Things. IEEE Softw 34:24-28. doi: 10.1109/MS.2017.28

Li S, Xu L Da, Zhao S (2015) The internet of things: a survey. Inf Syst, Front 17:243-259. doi: 10.1007/s10796-014-9492-7

Li S, Xu L Da, Zhao S (2018) 5G Internet of Things: A survey. J Ind Inf Integr 10:1-9. doi: 10.1016/j.jii.2018.01.005

Liao Y, Deschamps F, Loures E de FR, Ramos LFP (2017) Past, present, and future of Industry 4.0 - a systematic literature review and research agenda proposal. Int J Prod Res 55:3609-3629. doi: 10.1080/00207543.2017.1308576

Lu Y (2017) Industry 4.0: A survey on technologies, applications, and open research issues. J Ind Inf Integr 6:1-10. doi: 10.1016/j.jii.2017.04.005

Madakam S, Ramaswamy R, Tripathi S (2015) Internet of Things (IoT): A Literature Review. J Comput Commun 03:164-173. doi: 10.4236/jcc.2015.35021

Matalonga S, Rodrigues F, Travassos G (2015) Challenges in Testing Context-Aware Software Systems. In: 9th Workshop on Systematic and Automated Software Testing 2015. Belo Horizonte, Brazil, pp 51-60

Matalonga S, Rodrigues F, Travassos GH (2017) Characterizing testing methods for context-aware software systems: Results from a quasi-systematic literature review. J Syst Softw 131:1-21. doi: 10.1016/j.jss.2017.05.048

Mihovska A, Sarkar M (2018) New Advances in the Internet of Things. Springer International Publishing, Cham

Motta RC, de Oliveira KM, Travassos GH (2018) On challenges in engineering IoT software systems. In: Proceedings of the XXXII Brazilian Symposium on Software Engineering - SBES '18. ACM Press, New York, New York, USA, pp 42-51

Motta RC, de Oliveira KM, Travassos GH A Framework to Support the Engineering of Internet of Things Software Systems. EICS 19 June 18-21 2019 Valencia Spain 6. doi: 10.1145/3319499.3328239

Motta RC, Oliveira KM de, Travassos GH (2016) Characterizing Interoperability in Context-Aware Software Systems. In: 2016 VI Brazilian Symposium on Computing Systems Engineering (SBESC). IEEE, pp 203-208

Nielsen CB, Larsen PG, Fitzgerald J, et al. (2015) Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions. ACM Comput Surv 48:1-41. doi: 10.1145/2794381

Nogueira JM, Romero D, Espadas J, Molina A (2013) Leveraging the Zachman framework implementation using the action-research methodology-a case study: aligning the enterprise architecture and the business goals. Enterp Inf Syst 7:100-132. doi: 10.1080/17517575.2012.678387

Panetto H, Baïna S, Morel G (2007) Mapping the IEC 62264 models onto the Zachman framework for analyzing products information traceability: A case study. J Intell Manuf 18:679-698. doi: 10.1007/s10845-007-0040-x

Patel P, Cassou D (2015) Enabling high-level application development for the Internet of Things. J Syst Softw 103:62-84. doi: 10.1016/j.jss.2015.01.027

Pfleeger SL, Atlee JM (1998) Software engineering: theory and practice. Pearson Education India

Roca D, Milito R, Nemirovsky M, Valero M (2018) Fog Computing in the Internet of Things. Springer International Publishing, Cham

Rojas RA, Rauch E, Vidoni R, Matt DT (2017) Enabling Connectivity of Cyber-physical Production Systems: A Conceptual Framework. Procedia Manuf 11:822-829. doi: 10.1016/j.promfg.2017.07.184

Sánchez Guinea A, Nain G, Le Traon Y (2016) A systematic review on the engineering of software for ubiquitous systems. J Syst Softw 118:251-276. doi: 10.1016/j.jss.2016.05.024

Santos I de S, Andrade RM de C, Rocha LS, et al. (2017) Test case design for context-aware applications: Are we there yet? Inf Softw Technol 88:1-16. doi: 10.1016/j.infsof.2017.03.008

Seaman CB (1999) Qualitative methods in empirical studies of software engineering. IEEE Trans Softw Eng 25:557-572. doi: 10.1109/32.799955

Shang X, Zhang R, Zhu X, Zhou Q (2016) Design theory, modeling, and the application for the Internet of Things service. Enterp Inf Syst 10:249-267. doi: 10.1080/17517575.2015.1075592

Sousa P, Pereira C, Vendeirinho R, et al. (2007) Applying the Zachman Framework Dimensions to Support Business Process Modeling. In: Digital Enterprise Technology. Springer US, Boston, MA, pp 359-366

Sowa JF, Zachman JA (1992) Extending and formalizing the framework for information systems architecture. IBM Syst J 31:590-616. doi: 10.1147/sj.313.0590

Spínola RO, Travassos GH (2012) Towards a framework to characterize ubiquitous software projects. Inf Softw Technol 54:759-785. doi: 10.1016/j.infsof.2012.01.009

Strauss A, Corbin J (1990) Basics of qualitative research: Techniques and procedures for developing grounded theory. Sage Publications, Inc, Newbury Park

Tang A, Jun Han, Pin Chen (2004) A Comparative Analysis of Architecture Frameworks. In: 11th Asia-Pacific Software Engineering Conference. IEEE, pp 640-647

Technology I (2015) Requirement Formalization using OWL Ontology-based Zachman Framework

Tian B, Yu S, Chu J, Li W (2018) Analysis of Direction on Product Design in the Era of the Internet of Things. MATEC Web Conf 176:01002. doi: 10.1051/matecconf/201817601002

Trappey AJC, Trappey C V., Hareesh Govindarajan U, et al. (2017) A review of essential standards and patent landscapes for the Internet of Things: A key enabler for Industry 4.0. Adv Eng Inform 33:208-229. doi: 10.1016/j.aei.2016.11.007

Whitmore A, Agarwal A, Da Xu L (2015) The Internet of Things—A survey of topics and trends. Inf Syst, Front 17:261-274. doi: 10.1007/s10796-014-9489-2
Wohlin C (2014) Guidelines for snowballing in systematic literature studies and a replication in software engineering. Proc 18th Int Conf Eval Assess Softw Eng - EASE 14 1-10. doi: 10.1145/2601248.2601268

Xu L Da, He W, Li S (2014) Internet of Things in Industries: A Survey. IEEE Trans Ind Inform 10:2233-2243. doi: 10.1109/TII.2014.2300753

Yan Yu, Jianhua Wang, Guohui Zhou (2010) The exploration in the education of professionals in applied Internet of Things Engineering. In: 2010 4th International Conference on Distance Learning and Education. IEEE, pp 74-77

Zachman JA (1987) A framework for information systems architecture. IBM Syst J 26:276-292. doi: 10.1147/sj.263.0276

Zambonelli F (2016) Towards a General Software Engineering Methodology for the Internet of Things

Zhang C, Shi X, Chen D (2014) Safety analysis and optimization for networked avionics system. In: 2014, IEEE/AIAA 33rd Digital Avionics Systems Conference (DASC). IEEE, pp 4C1-1-4C1-12