Marine in-situ data is collected by sensors mounted on fixed or mobile systems deployed into the ocean. This type of data is crucial both for the ocean industries and public authorities, e.g., for monitoring and forecasting the state of marine ecosystems and/or climate changes. Various public organizations have collected, managed, and openly shared in-situ marine data in the past decade. Recently, initiatives like the Ocean Decade Corporate Data Group have incentivized the sharing of marine data of public interest from private companies aiding in ocean management. However, there is no clear understanding of the impact of data quality in the engineering of systems, as well as on how to manage and exploit the collected data. In this paper, we propose main architectural decisions and a data flow-oriented component and connector view for marine in-situ data streams. Our results are based on a longitudinal empirical software engineering process, and driven by knowledge extracted from the experts in the marine domain from public and private organizations, and challenges identified in the literature. The proposed software architecture is instantiated and exemplified in a prototype implementation.

Background: In-situ marine data has a low reusability rate, primarily due to differences in data usage objectives among stakeholders in data ecosystems. The extreme cost of collecting and maintaining in-situ marine data threatens the sustainable usage of the ocean. Aims: This paper provides an overview of current data and data quality (DQ) requirements. We also investigate limitations in the current practices that obstruct data reusability. The ultimate objective is to improve data requirements elicitation, leading to enhanced data reusability. Method: We interviewed 14 marine practitioners and researchers from 7 organizations with extensive experience in collecting, managing, and utilizing in-situ marine data. Results: We identify 9 representative use cases in the fishery, energy, and marine sciences industries, as well as their data and DQ requirements. The results give guidance to data producers to produce data meeting demands of a wider range of data consumers. At the same time, data consumers can refer to the compilation to identify existing data suiting their needs. Furthermore, we recommend a roadmap taken into account during requirements elicitation to improve 6 limitations in the current practices that obstruct data reusability.

The ocean is vital for humankind but may cause catastrophes when unhealthy. Although there have been efforts to build ocean monitoring systems, the understanding of the underwater environment is limited due to the cost and challenges of obtaining real-time marine data. One potential solution is to build stationary ocean observation systems based on wireless communication due to its affordable cost. In this study, we divide these systems into three components: 1) underwater data acquisition; 2) network communication; and 3) data management. We investigate the engineering challenges associated with each component, the causes, and how they relate. The literature has not discussed the technical issues of building stationary smart ocean monitoring systems entirely based on wireless communication yet. This article fills that research gap by conducting semi-structured interviews with 17 experts knowledgeable about underwater sensors, underwater acoustic communication, offshore network communication, and underwater data usage. The identified challenges are compared with the literature to assess whether our findings are novel or are a confirmation of what have been already found in prior publications. The Internet of Things (IoT) used in smart city platforms is quite advanced, but the Internet of Underwater Things (IoUT) employed in smart ocean monitoring systems has several unresolved issues; although IoT is viewed as a foundation for IoUT. Therefore, we compare fundamental differences between the technologies used in the smart city and the smart ocean domains, explaining why some of our identified challenges are unique in the marine context.

Abstract Security remains under-addressed in many organisations, illustrated by the number of large-scale software security breaches. Preventing breaches can begin during software development if attention is paid to security during the software’s design and implementation. One approach to security assurance during software development is to examine communications between developers as a means of studying the security concerns of the project. Prior research has investigated models for classifying project communication messages (e.g., issues or commits) as security related or not. A known problem is that these models are project-specific, limiting their use by other projects or organisations. We investigate whether we can build a generic classification model that can generalise across projects. We define a set of security keywords by extracting them from relevant security sources, dividing them into four categories: asset, attack/threat, control/mitigation, and implicit. Using different combinations of these categories and including them in the training dataset, we built a classification model and evaluated it on industrial, open-source, and research-based datasets containing over 45 different products. Our model based on harvested security keywords as a feature set shows average recall from 55 to 86%, minimum recall from 43 to 71% and maximum recall from 60 to 100%. An average f-score between 3.4 and 88%, an average g-measure of at least 66% across all the dataset, and an average AUC of ROC from 69 to 89%. In addition, models that use externally sourced features outperformed models that use project-specific features on average by a margin of 26–44% in recall, 22–50% in g-measure, 0.4–28% in f-score, and 15–19% in AUC of ROC. Further, our results outperform a state-of-the-art prediction model for security bug reports in all cases. We find using sound statistical and effect size tests that (1) using harvested security keywords as features to train a text classification model improve classification models and generalise to other projects significantly. (2) Including features in the training dataset before model construction improve classification models significantly. (3) Different security categories represent predictors for different projects. Finally, we introduce new and promising approaches to construct models that can generalise across different independent projects.

Security testing can broadly be described as (1) the testing of security requirements that concerns confidentiality, integrity, availability, authentication, authorization, nonrepudiation and (2) the testing of the software to validate how much it can withstand an attack. Agile testing involves immediately integrating changes into the main system, continuously testing all changes and updating test cases to be able to run a regression test at any time to verify that changes have not broken existing functionality. Software companies have a challenge to systematically apply security testing in their processes nowadays. There is a lack of guidelines in practice as well as empirical studies in real-world projects on agile security testing; industry in general needs a more systematic approach to security. The findings of this research are not surprising, but at the same time are alarming. The lack of knowledge on security by agile teams in general, the large dependency on incidental pen-testers, and the ignorance in static testing for security are indicators that security testing is highly under addressed and that more efforts should be addressed to security testing in agile teams.

Organizations recognize that protecting their assets against attacks is an important business. However, achieving what is adequate security requires taking bold steps to address security practices within the organization. In the Agile software development world, security engineering process is unacceptable as it runs counter to the agile values. Agile teams have thus approached software security activities in their own way. To improve security within agile settings requires that management understands the current practices of software security activities within their agile teams. In this study, we use survey to investigate software security usage, competence, and training needs in two agile organizations. We find that (1) The two organizations perform differently in core software security activities but are similar when activities that could be leveraged for security are considered (2) regardless of cost or benefit, skill drives the kind of activities that are performed (3) Secure design is expressed as the most important training need by all groups in both organizations (4) Effective software security adoption in agile setting is not automatic, it requires a driver.

Many studies show that real-world systems are riddled with large dependency cycles among software classes. Dependency cycles are claimed to affect quality factors such as testability, extensibility, modifiability, and reusability. Recent studies reveal that most defects are concentrated in classes that are in and near cycles. In this paper, we (1) propose a new metric: IRCRSS based on the Class Reachability Set Size (CRSS) to identify the reduction ratio between the CRSS of a class and its interfaces, and (2) presents a cycle-breaking decision support system (CB-DSS) that implements existing design approaches in combination with class edge contextual data. Evaluations of multiple systems show that (1) the IRCRSS metric can be used to identify fewer classes as candidates for breaking large cycles, thus reducing refactoring effort, and (2) the CB-DSS can assist software engineers to plan restructuring of classes involved in complex dependency cycles.

Advice that circular dependencies between programming artefacts should be avoided goes back to the earliest work on software design, and is well-established and rarely questioned. However, empirical studies have shown that real-world (Java) programs are riddled with circular dependencies between artefacts on different levels of abstraction and aggregation. It has been suggested that additional heuristics could be used to distinguish between bad and harmless cycles, for instances by relating them to the hierarchical structure of the packages within a program, or to violations of additional design principles. In this study, we try to explore this question further by analysing the relationship between different kinds of circular dependencies between Java classes, and their change frequency. We find that (1) the presence of cycles can have a significant impact on the change proneness of the classes near these cycles and (2) neither subtype knowledge nor the location of the cycle within the package containment tree are suitable criteria to distinguish between critical and harmless cycles.

Previous studies have shown that dependency cycles contain significant number of defects, defect-prone components and account for the most critical defects. Thereby, demonstrating the impacts of cycles on software reliability. This preliminary study investigates the variables in a cyclic dependency graph that relate most with the number of defect-prone components in such graphs so as to motivate and guide decisions for possible system refactoring. By using network analysis and statistical methods on cyclic graphs of Eclipse and Apache-Active MQ, we have examined the relationships between the size and distance measures of cyclic dependency graphs. The size of the cyclic graphs consistently correlates more with the defect-proneness of components in these systems than other measures. Showing that adding new components to and/or creating new dependencies within an existing cyclic dependency structures are stronger in increasing the likelihood of defect-proneness. Our next study will investigate whether there is a cause and effect between refactoring (breaking) cyclic dependencies and defect-proneness of affected components.

(Background) Defect distribution in software systems has been shown to follow the Pareto rule of 20-80. This motivates the prioritization of components with the majority of defects for testing activities. (Research goal) Are there significant variations between defective components and architectural hotspots identified by other defect measures? (Approach) We have performed a study using post-release data of an industrial Smart Grid application with a well-maintained defect tracking system. Using the Pareto principle, we identify and compare defect-prone and hotspots components based on four defect metrics. Furthermore, we validated the quantitative results against qualitative data from the developers. (Results) Our results show that at the top 25% of the measures 1) significant variations exist between the defective components identified by the different defect metrics and that some of the components persist as defective across releases 2) the top defective components based on number of defects could only identify about 40% of critical components in this system 3) other defect metrics identify about 30% additional critical components 4) additional quality challenges of a component could be identified by considering the pair wise intersection of the defect metrics. (Discussion and Conclusion) Since a set of critical components in the system is missed by using largest-first or smallest-first prioritization approaches, this study, therefore, makes a case for an all-inclusive metrics during defect model construction such as number of defects, defect density, defect severity and defect correction effort to make us better understand what comprises defect-prone components and architectural hotspots, especially in critical applications.

(Background) Software defects that most likely will turn into system and/or business failures are termed critical by most stakeholders. Thus, having some warnings of the most probable location of such critical defects in a software system is crucial. Software complexity (e.g. coupling) has long been established to be associated with the number of defects. However, what is really challenging is not in the number but identifying the most severe defects that impact reliability. (Research Goal) Do cyclic related components account for a clear majority of the critical defects in software systems? (Approach) We have empirically evaluated two non-trivial systems. One commercial Smart Grid system developed with C# and an open source messaging and integrated pattern server developed with Java. By using cycle metrics, we mined the components into cyclic-related and non-cyclic related groups. Lastly, we evaluated the statistical significance of critical defects and severe defect-prone components (SDCs) in both groups. (Results) In these two systems, results demonstrated convincingly, that components in cyclic relationships account for a significant and the most critical defects and SDCs. (Discussion and Conclusion) We further identified a segment of a system with cyclic complexity that consist almost all of the critical defects and SDCs that impact on system's reliability. Such critical defects and the affected components should be focused for increased testing and refactoring possibilities.

The prediction of fill levels in stormwater tanks is an important practical problem in water resource management. In this study state-of-the-art CI methods, i.e., Neural Networks (NN) and Genetic Programming (GP), are compared with respect to their applicability to this problem. The performance of both methods crucially depends on their parametrization. We compare different parameter tuning approaches, e.g. neuro-evolution and Sequential Parameter Optimization (SPO). In comparison to NN, GP yields superior results. By optimizing GP parameters, GP runtime can be significantly reduced without degrading result quality. The SPO-based parameter tuning leads to results with significantly lower standard deviation as compared to the GA based parameter tuning. Our methodology can be transferred to other optimization and simulation problems, where complex models have to be tuned.