More Accurate Cost Estimation for Internet of Things Projects by Adaptation of Use Case Points Methodology

This article adapts the use case points (UCPs) method to estimate the size and development effort (DE) required for the Internet of Things systems. Despite the extensive use of UCP in software engineering, it has yet to be adapted for IoT systems, which is essential for project management and resource planning. Our proposed adaptation, UCP for IoT, is based on a four-layer IoT architecture and tailors the standard software UCP to the specifications of IoT systems. It was validated using a case study of three IoT systems, demonstrating its applicability and effectiveness in estimating the DE required for IoT projects. However, the results also highlight the need for further improvements, particularly given the absence of historical data sets for IoT projects. Our future work will focus on gathering such data sets and further refining the proposed model.

modeling in functional design [3], [4].These studies allow the design of high-level functional models of IoT systems.
For example, Martins and Domingos [5] discussed adaptation business process modeling (BPMN) for modeling IoT systems' behavior and later using it to generate a platform neural code.Batool and Niazi [6] proposed a methodology for modeling complex scenarios in the IoT domain using a combination of complex networks and agent-based modeling.Suri [7] discussed allocating IoT resources in configurable business process models, which act as an extension of BPMN.Korkan et al. [8] extended the Thing Description standard proposal into sequential behavioral modeling.da Silva Fonseca et al. [9] proposed behavioral modeling based on Petri nets, while Song et al. [10] discussed a formal method for behavioral modeling of Smart IoT Systems using a combination of process algebra and lattice structures.Finally, Moghaddan et al. [11] discussed the Internet of Behaviors (IoB) concept, which focuses on connecting the digital world with human behavior to create intelligent connected systems that are human-driven in design, development, and adaptation.
While these studies have made significant contributions to IoT modeling, none of them discusses behavioral modeling as a baseline for the development effort (DE) estimation nor discusses a use case model as a functional description for IoT systems.The system size, DE, or cost estimation differs from behavioral modeling.
Our contribution is motivated by the growing potential for model-driven development (MDD), which brings visual languages such as the unified modeling language (UML) or system modeling language (SysML) to the IoT community.The use case modeling is well established in modern software and system engineering; therefore, the size estimation method, UCPs, can be introduced and used in the IoT domain.This article introduces the UCPs method to estimate software or system size and DE in IoT systems.By leveraging the well-established use case modeling approach in software and system engineering and the potential of MDD in the IoT domain, we provide a practical and effective solution for estimating the size of IoT systems, which can aid in project planning, resource allocation, and cost estimation.
This article discusses use case modeling for IoT systems and furt on the IoT-specific system size and DE method based on the UCPs approach.The following two research questions were investigated.
RQ1: What are the use case model design rules of IoT systems?RQ2: How should the software UCP methodology be adapted for IoT systems size/DE estimation to reflect the specifics of these systems?This study contributes to the size and effort estimation methods related to the development of IoT systems.It introduces the adaptation of the UCP method, which is mainly studied and used in software engineering for IoT systems [12].This UCP adaptation describes how a four-layer IoT architecture can be mapped to a size estimation model and tailors the standard software UCP to the specifications of IoT systems.The proposal was verified using a case study of a smart hydroponic system.

A. Research Highlights and Contribution
Although UCP is well-known, frequently adopted, and widely studied in software engineering, it has not yet been adapted for IoT systems.However, it is valuable as a size and DE estimator in IoT systems project management.It enables IoT project planning and can be used for updates and new function cost evaluations.The main highlights can be summarized as follows.
1) This study introduces the adaptation of the UCP method for estimating the size and effort required for developing IoT systems.
2) The UCP adaptation is based on a four-layer IoT architecture, and it tailors the standard software UCP to the specifications of IoT systems.
3) The proposal was validated using a case study of three IoT systems, demonstrating the applicability of the UCP method for estimating the DE required for IoT projects.4) The study presents rules and recommendations for creating use case models for IoT systems and suggests that use case modeling can be adapted to fit the scope of IoT. 5) The study highlights the importance of system size estimation for project management and resource planning in IoT systems and suggests that existing effort estimation methods for software systems can be adapted for specific IoT environments.The remainder of this article is organized as follows.Section II discusses related work.In Section III, the IoT specifications are discussed.Section IV discusses UCP adaptation, which discusses use case modeling and UCPs within the scope of IoT.Section V presents case studies.The results, discussion, and future directions are discussed in Section VI.Threats to validity are presented in Section VII.Finally, Section VIII concludes this article.

II. RELATED WORKS
Karner proposed the UCP method in 1993 [12], which is often proposed based on an analogy between projects [13], [14].Generally, in cases where the focus is not on the scope of the proposed software system but on its implementation time, the DE must be calculated [15], which is the ratio between the UCP and the number of person-hours (PHs) required for its implementation.For large-scale applications, both the project and a corresponding IoT adaption [16] are created based on the assumption that, in the first iteration, all actors are considered moderately complex, whereas all use cases are considered complex.Ochodek et al. [17] recommended omitting actors entirely as model attributes.He also proposed another modification called scenario decomposition [17], which entails dividing scenarios into smaller ones with fewer steps.The necessity for UCP implementation is the significance of the UCP components [18], which was previously studied.
Several modifications have been proposed to improve the UCP method, including the use of extension associations to improve calculation accuracy [19] and the calculation of subcomponents using the Extended UCP and Modified UCP methods [15], [20], [21].Other modifications focus on scenario decomposition and the identification of transactions and events within scenarios [22], [23], [24].The internal structure of scenarios is also considered a key factor in the accuracy of UCP estimation [20].
Alternative approaches to modifying UCP methods include using Bayesian networks and fuzzy sets to create a probability estimation model [15] and adapting UCP for large-scale projects [16].Some authors recommend to propose using linear regression models [25], [26] or neural network models [27], [28] for size estimation.
Overall, the ongoing efforts to modify and extend UCP methods reflect the importance of accurately estimating software system size in software engineering.The significance of UCP components, the methods used to calculate subcomponents, and the effects of scenario processing and transaction identification continue to be the subject of research and development in this field.
In the broader context of IoT project cost estimation, a contribution has been made by Evdokimov et al. [29].Their work primarily estimates total costs and identifies cost-influencing factors in IoT projects.They contend that to implement and leverage IoT effectively in software engineering, it is crucial to resolve these cost estimation issues.Their study examines the aspects of IoT technology that impact costs, with the ultimate goal of providing clients with accurate project cost estimates before completion.Interestingly, Evdokimov et al. concluded that the program evaluation and review technique (PERT) offers a distinct advantage in accurately estimating IoT project costs.This finding aligns with us and highlighting the importance of considering diverse cost estimation techniques in IoT project management planning.
IoT system development methodologies contain effort estimation activities as their natural part.In this sense, the UCP DE estimation method is independent on particular development methodology.The ability to formulate a UML use case model is the only prerequisite for adopting UCP for an IoT project.In IoT system development, there are methodologies in which adoption of the UCP method may be complicated due to the lack of a requirements-gathering phase.To give a few examples, Ciccozzi and Spalazzese [30] introduced the MDE4IoT methodology, in which the requirements engineering phase is omitted.Similarly, the methodology presented by Khaleel et al. [31] also lacks a documented functional gathering phase.On the contrary, several other methodologies assume that functional requirements are already known in advance, which enables the possibility of UCP adoption.Lekidis et al. [32] presented a model-driven approach based on a priority component network.Brambilla et al. [33] introduced MDD for IoT, with a focus on the user interface.Ito et al. [34] demonstrated the MDD approach with an example and show the effectiveness of use case modeling.The UML compliance of development methodologies has been studied by Guerro-Ulloa et al. [35], resulting in a proposal for a methodology that heavily focuses on requirements gathering and analysis.Harbouche et al. [36] presented a model-driven methodology with a documented requirements derivation process.Usländer and Batz [37] discussed an agile methodology for IoT that incorporates requirements and use cases.
As observed, MDD is a prerequisite for implementing UML/SysML in IoT development.Furthermore, it is also essential to utilize the UCP method in IoT projects.The MDD approach is usually understood as automation of development [38].Pramudianto et al. [39] discussed an MDD in IoT software parts.Similarly, Conzon et al. [40] discussed MDD as automation.Brambilla et al. [33] introduced MDD for an IoT graphical interface design.However, when using an MDD, the model is typically not visualized.UML is used to model software solutions [41], [42] or systems in the UML profile, which are called SysML [43].UML is the industry standard for visual modeling in MDE; it offers graphical description tools and diagrams illustrating various system properties.UML has several well-defined extension artifacts, such as stereotypes, constraints, values, and tags.These primary extension techniques enable designers to construct customized models for specific areas such as modeling system security issues or profiles representing IoT systems.The OMG systems modeling language (OMG SysML) [43] is a UML profile that enables system modeling.It is an extended subset of UML that facilitates the definition, analysis, design, verification, and validation of systems comprising hardware, software, data, persons, processes, and facilities.It also enables model and data transfer using XML metadata interchange (XMI).SysML is a visual modeling language that offers semantics and notation; it is not a technique or technology.SysML has also been extended to represent IoT systems.IoT systems with basic blocks such as sensors, actuators, and communication systems are software-intensive.Therefore, UML can effectively represent IoT systems because its graphical approach supports the interpretability of designed systems.Consequently, UML was proposed as an option for IoT systems modeling by [2] when a new profile for IoT system design and wrapper generator was presented.

III. IOT DEVELOPMENT SPECIFICS
IoT systems typically differ from ordinary software and systems in terms of complexity and heterogeneity, which naturally affects the accuracy of effort estimation methods.Software parts in IoT systems may differ from public software systems for a variety of reasons.Individual reasons, as listed below, are based on Fahmideh's review, which discusses software engineering perspectives for IoT [44].
1) Several programming languages can be used to implement the software components of an IoT system.A mix of OOP-based back-end languages with low-level languages used to implement firmware in devices can be present in the system [45], [46], [47], [48].2) A wider spectrum of communication protocols can be employed in IoT systems.In addition, the employment of proprietary protocols is much more probable than that in the case of a purely software system.Furthermore, the level of standardization in the field of IoT is currently lower than that in software systems [47], [49].3) In IoT systems, a mixture of different languages and programming styles combined with proprietary communication protocols makes the integration of individual system parts more challenging and prone to defects [47], [49].4) In an IoT project, electronics and software specialists must collaborate.This heterogeneity, combined with insufficient knowledge of the technologies used, may prolong the actual implementation time [50], [51].5) The nature of IoT systems generally implies a greater complexity and level of interconnection of their parts, which might impact the estimation process [52].6) In some projects, IoT hardware is being developed concurrently with software.Thus, prolonging individual deadlines might impact the overall schedule more extensively than in a purely software-oriented project [53], [54].Not every reason might impact every IoT project.However, all of these can significantly influence the accuracy of estimations, especially if the estimation method is developed and balanced for public software projects.

IV. UCP IoT : UCP ADAPTATION FOR IOT SYSTEMS
For the UC model and UCP methodology, we consider IoT systems as systems comprising the following four layers.
1) The sensing layer contains sensors, actuators, or other devices for gathering, emitting, or processing data.
2) The network layer comprises network connectors and data gathering, including analog-to-digital (A/D) converters, data filters, and processing services.
3) The data processing layer is software-oriented, where data are preprocessed, and some fundamental analysis is performed.This layer is also a connector for clouds, business applications, and other systems that consume data.

4) The application layer comprises data management data;
it is the layer of end-user application in all problem domains.IoT use case modeling covers the sensing, network, and data-processing layers.The data-processing layer is not included into the use case modeling.In the UC model, actors trigger an activity, which can be considered as a conversation with a system.In the case of IoT systems, all members of the sensing, network, and data processing layers must be included as actors.Furthermore, in a typical UC model, actors may represent multiple entities.For modeling, we consider all actors Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
as external to the modeled system.Use cases represent highlevel (textual) descriptions of the IoT functions.Each use case is represented by a primary scenario, and, whenever applicable, by several alternate methods.For the IoT, as a use case, all functions of the proposed systems need to be captured, and the behavior of the system includes the behavior of the actors.Both actors and use cases should follow the UML/SysML naming convention.Typically, actors are named using singular nouns in uppercase.Furthermore, the name of the sensor or actuator can be used; in any case, all actor names must be unique.In contrast, use cases are in verb form to emphasize an activity or process.

A. Use Case Model Design Approach for IoT
Use case diagrams (UC) are vital for describing IoT systems at a high level in terms of system goals and are identical for UML and SysML.System behavior is elaborated using system actors and described in detailed scenarios.A sample model is shown in (Fig. 1).
The UC model is defined by a diagram frame that represents the border of the system.In the diagram frame, a system boundary is used to illustrate the edge of the modeled system or package if the system decomposition is used.One way to determine this is to find actors.Subsequently, use cases were identified when searching for actors.The preparation of the UC was based on the following.
1) A business process model, user goals.
2) Documentation of requirements or their model.
3) Domain model, user needs.The diagram construction approaches can be summarized as follows.
1) Actor-based approach [55]: The System Actors are identified.For instance, who uses the system and why; whether the system is in a relationship with another system, who performs the installation etc. Actors can also be understood as time in situations where an activity occurs at a particular time.2) Use Case Determination From Business Processes: Use case can be understood as a link-up to the business process.The use case models for IoT contain the following elements.1) System boundary is the formal capture of the enclosure of the application before the surrounding environment.In IoT, sensing, network, and data processing layers functions should be modeled as part of described systems.2) Primary actors are entities related to the sensing or network layers, which represent all sensors, actuators, data gathering, emitting, or signal processing.3) Secondary actors are entities related to the data processing and application layers or connectors to external systems (cloud, external software).4) Use cases are a textual description of the activity and interaction between the actor and the system.The primary actor is identified for each use case, and primary and alternative scenarios are created.Scenarios that describe the interaction between the actor and the system are mandatory.Primary actors are placed outside the system boundary on the left side, and secondary actors are placed on the right side.The use cases are placed inside the system boundary.The use case model is not a process diagram.Therefore, the use case process lacks support for queueing.In IoT use-case models, the following relationships are recommended.
1) Association-the relationship between the actor and the use case.2) Include-the relationship between two use cases; one needs another.3) Extend-the relationship between two use cases; one needs another under specific conditions.4) Generalization-relationship that can be used between two actors or two use cases.The association is only used to emphasize the connection between actors and use cases (system functionality).These relationships are essential for the modularity principle.For instance, a use case, which is included in another use case, necessitates the completion of a parent use case.Typically, the sensor use case can be included in the data processing use case.Extend indicates a similar situation, but with a condition that must be fulfilled.If a condition is true, the use case behavior is included in the parent use case.Similarly, a generalization is applied to actors when standard functions are available for more than one actor.Generalization is applied to use cases when a group of similar use cases exists, which are identical in implementation despite slight differences.

B. Summary of UC Model Creation
The following steps can be used for IoT systems.In the formulation of these steps, a SysML approach is considered, which is the same as the basis for MDD.The necessary steps are as follows.
1) Definition of system boundary-based on IoT system goals.2) Identify primary actors (sensing layer and network layer).3) Identify secondary actors (data processing and application layer).4) Identify use cases for primary and secondary actors.5) Elaborate relationships-include and extend for use cases.6) Implement generalization for actors and use cases.Applying these steps is essential for creating a good use case model that can be used in MDD and for developing effort estimation methods.Moreover, the identification of actors should correlate with the IoT system structure, respecting the four-layer approach.However, these actors have different complexities.Therefore, these steps should be carefully carried out based on technical complexity, number of actors, or technology (high-versus low-level programming language).In IoT, the problem domain use cases differ from those in "classical" software.In software, practitioners prefer high-level descriptions of use-case scenarios.IoT prefers the low-level approach,  which enables of scenarios to be described in great detail.However, the same writing style must be used with the same level of detail in each use case.Mixing high-and low-level scenarios can lead to issues.An example of the use case scenario is presented in Table I.Full use case models scenarios are available as auxiliary material. 1

C. Process of Use Case Points Estimation for IoT
The proposed size and DE estimation were adapted from a software engineering size estimation called UCPs [12].Actors and use cases are connected in the UML [42], [56] use-case models.The UCP technique assumes that the number of actors and use cases can be utilized to establish the size of the suggested software system.
The UCP methodology is based on eliciting four components, which create a size estimation that can be used to estimate DE in PHs.Later, it can even be used to estimate In UCP, actors and use cases are categorized into classes based on the complexity of the implementation.In this study, the implementation complexity categories (AC) of three actors were identified (Table II).
The UAW value is determined using (2) as a weighted sum of the actors' complexity groups Simple actors represent sensors, actuators, application interfaces, or Web services.Average actors are actors with straightforward interfaces (data gathering and emitting) or actors that require more complex processing (e.g., A/D converters) or communication and require more implementation Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.effort.The third group, complex actors, represents data processing layer members or actors using a graphical user interface for their activities [12].
A similar approach is used to determine UUCW.The number of steps in the use case scenarios is used to distinguish the complexity (Table III).The number of steps is calculated based on the primary and alternate scenarios.Finally, the value of UUCW is determined using (3).
However, the step-by-step approach ignores the interrelationships of the use cases (generalization, includes, and extends).The resulting size estimation (UUCW) is determined from (3), where the UCC complexity group of the implementation of the use case (Table IV) and WFb are the weighting factors for the selected group After determining UAW and UUCW, the essential characteristics of the proposed IoT system, development team, and environment must be determined.For this purpose, two correction mechanisms are proposed in the UCP methodology.
The first correction mechanism is TCF, which enables us to determine the influence of the essential technical attributes on the system (system characteristics).The influence factor value determines how essential an item is to IoT.The TCF correction is performed according to (4).WFc is the weighting factor, and SIa is the influence of the factor on the IoT project.In other words, the TCF correction mechanism ensures that the weight of each factor and its influence on the project is determined.The TCF are defined according to the original design of the UCP method [12], where the further examination was presented by Nhung et al. [57]

TABLE V ENVIRONMENTAL FACTORS FOR UCP IoT
A list of technical factors is adopted as follows.T1 (Decentralization): It specifies the complexity of the architecture in general.A higher significance value indicates a need for a more complex solution architecture (for example, multitier or decentralized architecture).T2 (Responsibility): It specifies how vital the system response speed is.It is also related to the expected load on the system.A higher significance value indicates that a faster system response or higher load is required.T3 (Efficiency): It specifies whether the goal is to increase the overall efficiency or to merely achieve a specific functionality.If a higher significance value is chosen, the goal is higher efficiency in running the system.T4 (Processing Complexity): It specifies whether the system internally processes complex data.A higher value means that the complexity of algorithms and internal data processing is significant, i.e., a higher range of the system.T5 (Reusability): If higher code reuse and redemption are expected, then the significance value of the parameter can be set to a lower value.T6 (User Experiences): The significance value of this parameter can be set low if users can be assumed to be highly competent at using the system.T7 (Usability): If the goal is to achieve higher usability, the significance of this parameter must be set higher.T8 (Development Complexity): It determines whether multiple platforms are required during development.If so, then the significance is higher.T9 (Maintenance): If the goal is to develop a system that is easy to maintain and expand, the significance of this parameter must be set to a higher value.T10 (Security): It determines whether an existing security design can be used.A higher significance value represents a need for better security.T11 (Third-Party Solutions): If the finished components of suppliers can be directly integrated into the system, then the significance of this parameter is set to a smaller value.T12 (Deployment): If the system is complex and requires advanced deployment, significance is set to a higher value.Environmental factors are used to adjust the resulting number of UCPs describing the capabilities of the development team and the development environment.Eight environmental factors are considered, each of which had a weight attributed to it (Table V).Environmental factors can be characterized based on the following parameters.the complexity of the language and its combination; a higher significance value is chosen for more complex languages.The settings depend on the specific development team and their previous experience.The value of the environmental factors of the ECF is determined using the relation (5), where WFd is the weighting factor, and SIb is the influence of the factor on the project being solved.The constants given in the relation are taken from the original design of the UCP method [12]

E1 (Methodology and
Both SIa values (significance of technical factors) and SIb (significance of environmental factors) are determined in the interval 0-5, where 0 indicates that no given factor has an effect, 3 indicates an average level of influence, and 5 indicates a significant influence on the scope of the IoT.The resulting value of UCP IoT describes the size of the proposed IoT system based on the UC model.The IoT system size in UCP points can be used to estimate the DE or cost.It can also be used for project development and resource planning.
When the number of UCPs is estimated, DE in PHs can be determined.Transforming the estimated size in the UCP into PHs is based on the productivity factor (PF).The PF is categorized as fair (20), low (28), and very low (36) by Schneider and Winters [58].These parameters were further discussed and analyzed by Azzeh and Nassif [59].
PF is based on environmental factor count (ECFc).Table VI summarizes count intervals for ECFc (6).If E1-E6 are less than 3, then the counted is increased by 1; if E7 and E8 are higher than 3, the count is again increased by 1.When the ECF count is less than or equal to 2, fair productivity is used (20).If the ECF count is between 3 and 4, low productivity (28) is used.Finally, when the ECF count is 5 or more, very low productivity is used (36) The DE is calculated using the PF, which is determined based on ECFc value using the following formula: The DE is obtained in PHs; if an estimation in person-days (PDs) is needed, then PHs can be divided by 8 The difference between UCP IoT and the established UCP software is discussed in the following section.

D. Difference of the UCP IoT to Standard Software UCP
The effort-determination process is specifically designed for IoT systems in this UCP IoT adaptation.Compared with the established classical software-based UCP, the following changes were made.
1) The actors were divided into primary and secondary groups, enabling better control over the estimation process and for situations requiring calibration.Certain IoT systems may contain only primary actors; secondary actors are not mandatory.Standard UCP methods assign only two complexity levels to actors: application interface or human.Primary and secondary actors are also known to form a use-case scenario when the secondary actors are involved in use-case processing.
2) The estimation was based on an adapted use case modeling approach, which describes all items related to the four-layer IoT architecture as actors.This approach helps to create a use case model in a specific way, which is the origin and beneficial for IoT systems, similar to the MDD design approach for IoT.The four-layer approach for use case modeling helps create a more consistent and descriptive use case model, which enables us to develop better UCPs components, such as actors and use case scenarios.3) Use cases were counted by the number of steps; independently for both actor groups.Typically, use case scenarios are all counted together to complex groups.
If they are counted separately as primary and secondary actors, then the UCP method can be more easily tuned.Further investigation shows that each group adds a different complexity level to the system.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
4) Use cases were described for actor/system interaction and data/signal processing.In typical software engineering projects, only use cases describing the interaction between actors and systems are used.In the proposed UCP IoT adaptation, actors can also be data processors.The interaction description is, therefore, more detailed.Consequently, the UCP method is more accurate, despite being a basic adaption without any tuning.5) TCF and ECF were partly modified for IoT specifics.
Both attributes were adopted in a majority of the system components, as they are used in the UCP method.All the attributes were evaluated for IoT projects, although only a few of them were rephrased.6) The calculation formula was redesigned for typical fourlayer IoT architecture related to two groups of actors.Estimation formulas were updated to adopt the concept of primary and secondary actors and use cases.This modification is beneficial for future method tuning and further adaptation.7) All factors and complexity weights were assumed to be coded numerically.In the UCP method, calculations are generally performed by combining numeric and scale variables.Conversely, in our method, all the variables are assumed to be weighted coefficients.These changes make UCP IoT an original contribution with significantly different characteristics when compared to the established UCP as described in [12].
The UCP IoT method implements the following revised formula: V. CASE STUDY

A. Smart Farming
The UCP calculation method is illustrated below for a smart agriculture project, which was originally designed by Alipio et al. [60].The project was implementing the IoT infrastructure at Yoki's Farm in Tagaytay City, Philippines and was conducted between January 2016 and March 2017, with four team members participating in the development of hardware and software parts.
The hardware includes a hydroponic farm built with a sensor network to monitor and control the system.The software comprises data analytics and a cloud server for data storage and predictive analyses.The Web interface serves as a graphical interface for any user to remotely access the farm.The complete process of the system is shown in the IoT-based hydroponics system, designed to create a closed feedback loop that monitors and controls the farm based on the parameters required by a specific variety of plants.
The project is detailed in [60], and the full use case model, including scenarios, is available as auxiliary material. 1 The estimated system is described by the use case model, which displays a functional design (Fig. 2).The system comprises several actors and use cases.VIII).UAW represents ten points of size in total.UUCW consists of UUCW P (Table IX) and UUCW S (Table X).UUCW represents a total of 180 points.The factors TCF and ECF (Table XI) were calculated as follows: The total number of UCPs (size points) was estimated using the following formula: UCP IoT (13) calculated using (9) illustrates the relative size of the system.It can be used to compare various system sizes and as the basis for estimating DE.

TABLE X SECONDARY USE CASE SIZE CONTRIBUTION FOR SMART HYDROPONICS FARM SYSTEMS
The next step was to estimate the DE.In the case study, ECFc (6) was equal to 5, which indicates very low productivity The estimated DE in PHs was calculated to be 5040.360,which is 630 PDs.
The known (recorded) developmental effort (DE) was 5560 PHs (695 PDs), which was recorded during the development of Alipio et al. [60].The DE recorded is detailed in Table XII.

B. Agrinex-Smart Irrigation System
The UCP calculation method is illustrated below for an Agrinex project, which was originally designed by Tiglao et al. [61].Agrinex is an agricultural WSAN that uses multiple sensors to gather soil data and employs drip irrigation for actuation.It utilizes a dynamic mesh network for flexible  node integration and a Web application for remote control.The sensor and actuator node (SAN) combines sensor and actuator functions, saving power and enabling localized decision making.The system includes microcontrollers, transceivers, Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.and sensors, with a servo motor and valve for irrigation.Overall, Agrinex optimizes agricultural monitoring and control for efficient water usage and improved crop yield.Full use case model, including scenarios, is available as auxiliary material. 1The estimated system is described by the use case model, which displays a functional design (Fig. 3).
The actors were identified as follows.The total number of UCPs (size points) was estimated using the following formula: The next step was to estimate the DE.In the case study, ECFc (6) was equal to 5, which indicates very low productivity The estimated DE in PHs was calculated to be 3291.408,which is 411 PDs.
The known (recorded) developmental effort (DE) was 3880 PHs (485 PDs), which was recorded during the development of the project.The DE recorded is detailed in Table XVIII.

C. Water Quality Monitoring
In the third case study, we are using a system originally designed by Alipio [62].The system is composed of three main components: 1) hardware; 2) software; and 3) a Web interface.The hardware includes sensor devices and a microcontroller for collecting water quality data.The software incorporates data analytics, machine learning, and a cloud server for storage and predictive analysis.The Web interface allows remote access to the system, while mobile technology sends SMS messages to inform residents about water source conditions.The sensor node devices consist of sensors, a microcontroller, and wireless modules.ZigBee is used for wireless transmission to a local server.The system is deployed in rural areas, specifically in the CALABARZON region of the Philippines, to monitor water quality.The estimated system is described by the use case model, which displays a functional design (Fig. 4).Use case model, including scenarios, is available as auxiliary material. 1 The actors were identified as follows.
The total number of UCPs (size points) was estimated using the following formula: UCP IoT = (7 + 6 + 90 + 45) × 0.90 × 0.755 (24) UCP IoT = 102.604.( 25) The proposed estimation methodology has been applied to three diverse projects, demonstrating its potential in predicting Authorized licensed use limited to the terms of applicable license agreement with IEEE.Restrictions apply.
where y is the known DE and ŷ is the predicted DE.
As shown, the predicted DE using UCP IoT is comparable to the known DE.Typically, the UCP method is relatively less accurate because RE depends on PF.Previous research related to software engineering DE has yielded predictions that are significantly less accurate.The promising results are limited by the lack of empirical evidence and historical data sets specifically tailored for IoT systems, which should be used for further testing.The UCP method, commonly used in software engineering, relies on historical data for accurate results, which are not readily accessible for IoT projects.Consequently, the absence of project-specific data hampers the estimation process.In the presented case studies, the UCP-IoT approach yielded relatively accurate predictions, but the mean percentage error highlighted the need for further improvement.However, to enhance the precision of estimation models for IoT projects, there is a pressing need for empirical evidence derived from a wider range of projects.Such empirical evidence would help refine and enhance the estimation methodologies, ensuring more reliable predictions for the developmental effort required in IoT endeavors.
The case study shows that the proposed UCP IoT approach can be used for IoT DE estimation.However, identifying the actors in IoT systems remains challenging because it typically involves more hardware than software systems.
Although the UCP method is widely adopted in software engineering, it requires historical data sets to provide accurate results.However, such data sets, i.e., those describing system DE or system sizing, are not available for IoT systems.
The objective of this study is to promote discussions in the IoT community about applying UML/SysML and functional modeling based on use case models.In functional modeling, entities can be based on a four-layer architecture and mapped as actors in the use-case model.In addition, high-level and low-level use-case scenarios must be further investigated to obtain a functional description of IoT.For instance, a low-level scenario may be better to establish a detailed description of communication protocols or software-hardware interaction.
In this study, use case model associations are used as a common interpretation of IoT system interactions.However, in systems that are heavily dependent on hardware and have limited software interactions, the relationships between elements, such as actors, should be emphasized to better reflect the structure of IoT systems.
The UCP IoT in this study was proposed using standard constants and formulas.Although this standard adaptation provided accurate predictions for a specific case study, a research data set that contains project descriptions must be built for further adjustments.In addition, the estimation formula can be modified further using various prediction algorithms (machine learning or statistical learning).
Further research on cost or DE drivers for IoT systems is essential to obtain more accurate estimations and improve IoT project planning and management.Furthermore, a solution must be provided for transforming the IoT system size in UCP to PHs.Typically, PF is used for this conversion.However, it depends on many factors, such as the programming language, problem domain, and application domain; it is, therefore, difficult to determine.Thus, PF must be set correctly to effectively apply an estimation approach, which is challenging.This adaptation of the UCP method for IoT systems demonstrates its practical applicability, as confirmed by the presented case study.

VII. THREATS TO VALIDITY
The proposed UCP IoT adaptation was verified using an individual case study.However to enhance its credibility, data must be gathered from more IoT projects.
This method was adopted from UCP, which is based on a software-specific functional point approach.The proposed UCP adaptation was correctly designed and verified in the case study; however, future studies should focus on obtaining more relevant information from various case studies.Considering the heterogeneity of IoT systems, new factors may emerge depending on the type of IoT system.Therefore, the methods for IoT system size estimation should be sufficiently flexible to integrate new influencing factors that may arise in the future.Furthermore, TCF and ECF factors should be tested to ensure if they are appropriate for the specific systems.
UCP IoT method itself can be discussed further.Several studies have been conducted on map size and effort estimation methods in software engineering, including UCP and UCP modification.Additionally, the inspiration of potential further modification can be seen in studies on software DE estimation and related topics, including comparative analysis of soft computing techniques [63], MDD of user interfaces for IoT systems [33], systematic mapping study on the employment of neural networks [64], middleware for Internet distribution in the context of cloud computing and the Internet of Things [38], and in review of ensemble effort estimation [65].These studies may provide additional context and related work for the article's discussion of effort estimation using use cases.
Because the original UCP was inspired by the functional points method [66], it also includes several design issues discussed by Ouwerkerk and Abran [67].UCP design flaws are primarily based on scale transformation when the values of Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
the UCP components are calculated [68].These design issues require immediate attention; however, more relevant case studies or IoT project repositories must be gathered before they can be solved.

VIII. CONCLUSION
In conclusion, this article addresses the adaptation of the UCP methodology for estimating the size and effort required in developing IoT systems.The study demonstrates the potential of UCP as a valuable size and DE estimator in IoT project management.
This article presents a case study involving three diverse IoT projects, showcasing the applicability of the UCP method in estimating the DE for IoT projects.The results indicate that the predicted developmental effort using the UCP-IoT approach is comparable to the known effort, despite the limitations imposed by the lack of empirical evidence and historical data sets specifically tailored for IoT systems.
Additionally, the study provides rules and recommendations for creating use case models for IoT systems.It emphasizes the inclusion of actors from the sensing, network, and data processing layers in the use case models and highlights the importance of system size estimation for project management and resource planning in IoT systems.This article suggests that existing effort estimation methods for software systems can be adapted to address the specific characteristics of IoT environments.
However, this study also suggests the need for further research to improve the accuracy of the proposed UCP adaptation.It suggests exploring UCP factors in more detail, gathering research data sets comprising IoT project descriptions, and fine-tuning the proposed model to enhance its accuracy.The authors intend to focus on these areas in future studies.
In response to RQ1 (What are the use case model design rules of IoT systems?), this article provides guidelines for designing use case models for IoT systems.It suggests including actors from the sensing, network, and data processing layers in the models and following the UML/SysML naming convention for actors and use cases.It emphasizes the highlevel and low-level use case scenarios to obtain a functional description of IoT systems.
Regarding RQ2 (How should the software UCP methodology be adapted for IoT systems size/DE estimation to reflect the specifics of these systems?), this article proposes an adaptation of the UCP methodology for IoT systems.It considers the four-layer architecture of IoT systems and tailors the UCP to accommodate the unique characteristics of IoT projects.The study demonstrates the practical applicability of the proposed adaptation through the case study results.
Overall, this research contributes to the field by providing insights into the estimation of size and DE in IoT systems using the UCP methodology.It highlights the importance of further research, empirical evidence, and tailored data sets for improving the accuracy of estimation models for IoT projects.The guidelines and adaptations proposed in this study pave the way for more effective project planning and resource management in the rapidly evolving field of IoT.
In future work, we intend to further explore the UCP factors to improve the accuracy of UCP IoT .For this purpose, our future studies will focus on gathering research data sets comprising IoT project descriptions, which are essential for empirical studies, UCP IoT model tuning, and model accuracy evaluation.

Fig. 4 .
Fig. 4. Use case model of water quality monitoring.

TABLE I USE
CASE SCENARIO SAMPLE As shown, the UAW value is based on UAW P (TableVII) and UAW S (Table

TABLE XI TCF
FACTORS AND ECF FACTORS FOR SMART FARMING IOT SYSTEM The UAW value is based on UAW P (Table XIII) and UAW S (Table XIV).UAW represents nine points of size in total.UUCW consists of UUCW P (Table XV) and UUCW S (Table XVI).UUCW represents a total of 115 points.The factors TCF and ECF (Table XVII) were calculated as follows: ECF = 1.4 + (−0.03 × 22.50).(17)

TABLE XVII TCF
FACTORS AND ECF FACTORS FOR AGRINEX TABLE XVIII RECORDED DE IN PDS FOR AGRITEX SYSTEM 1) Primary actors-pH Sensor, TDS Sensor, Turbidity Sensor, and Temperature Sensor.2) Secondary actors-User, Time, and SMS Module.Use cases were identified as follows.1) Primary UC-Reads pH Level, Reads TDS Level, Reads Turbidity Intensity, and Reads Temperature Level.2) Secondary UC-Login, Monitoring systems parameters, and Generate Predictive Model.The UAW value is based on UAW P (Table XIX) and UAW S (Table XX).UAW represents 13 points of size in total.UUCW consists of UUCW P (Table XXI) and UUCW S (Table XXII).UUCW represents a total of 135 points.The factors TCF and ECF (Table XXIII) were calculated as follows:

TABLE XX
DE) was 3880 PHs, and the predicted PD is 3291.408,resulting in an error of 588.592PHs (15.2%).

TABLE XXIII TCF
FACTORS AND ECF FACTORS FOR WATER QUALITY MONITORING SYSTEM Finally, for a Water Quality monitoring project, the known (recorded) developmental effort (DE) was 4120 PHs and the estimated DE in PHs was calculated to be 2872.912.It shows

TABLE XXIV RECORDED
DE IN PDS FOR WATER QUALITY MONITORING SYSTEM an error of 1247.088PHs (30.3%)