Component Integration Metrics and Their Evaluation

Software Engineering (SE) has been described as the discipline devoted to the design, development, and use of computer software, covering not only the technical aspects of building software systems, but also management issues develops highly complex software. The crisis in SE, due to the lack of well-defined formal processes, has led to poorly designed products with high maintenance costs and whose behavior becomes unpredictable. Component Based Software Engineering (CBSE) is currently a preferred approach to system design to overcome the crisis of SE, since it promotes software re-use, facilitates adaptability and faster system development. A component provides a function or a set of related functions, which forms a reusable program building block that can be combined with other components to form an application. A component with qualities such as, reusability, testability, modularity, complexity, proper to communicate and stability reduces maintenance costs. The components thus integrated, should be able to interoperate so that an operational application that results in reduced maintenance costs can be composed with minimal effort. Metrics are used to measure a component\u27s quality factor and there are no good metrics available to validate their effectiveness, when components are integrated. Currently, the success of projects based on the CBSE methodology relies on experts who assess software components; however, their evaluation process involves parameters that may not be measured in practice. Existing traditional metrics are inappropriate since CBSE is aimed at improving interoperability and re-usability. Size metrics based on lines of code are not applicable as component sizes may not be known a priori. Furthermore, complexities that arise due to varying nature of facets and interfaces are not addressed by traditional metrics. This thesis addresses the evaluation of a series of metrics based on complexity, criticality and dynamic behavior, in order that component integration performance can be assessed. Three suites of metrics defined by various authors have been considered for evaluation so that one could choose the best metrics to measure an integrated environment. A suite of metrics proposed by Narasimhan and Hendradjaya are classified based on the attributes of: complexity, criticality and dynamic aspects. These metrics use graph-based connectivity to represent a system of integrated components. While the complexity metrics consider the packing density of integrated components and the interaction density among the components, criticality metrics reveal the extent of binding within each component in the system. Dynamic metrics have also been collected during the execution of an application and aid the process involved in testing and maintenance. Metric related data sets have been from several benchmark programs using instrumentation programs and key inferences have been obtained; these inferences include a systematic evaluation of quality of the various metrics. Two new metrics have also been provided towards assessing the stability of the application: one metric, namely CRIT instability, calculates the instability of each component, while the second new metric, namely CRIT inheritance,counts the number of components whose children exceeds a threshold value. Both these metrics are useful to assess the stability of the application and, in addition, to determine the components in a given application that needs to be redesigned. Future work will focus on the development of a metric evaluation suite to assess the system\u27s stability as a whole, considering the role of each component in an application

The LOFAR Transients Pipeline

Current and future astronomical survey facilities provide a remarkably rich opportunity for transient astronomy, combining unprecedented fields of view with high sensitivity and the ability to access previously unexplored wavelength regimes. This is particularly true of LOFAR, a recently-commissioned, low-frequency radio interferometer, based in the Netherlands and with stations across Europe. The identification of and response to transients is one of LOFAR's key science goals. However, the large data volumes which LOFAR produces, combined with the scientific requirement for rapid response, make automation essential. To support this, we have developed the LOFAR Transients Pipeline, or TraP. The TraP ingests multi-frequency image data from LOFAR or other instruments and searches it for transients and variables, providing automatic alerts of significant detections and populating a lightcurve database for further analysis by astronomers. Here, we discuss the scientific goals of the TraP and how it has been designed to meet them. We describe its implementation, including both the algorithms adopted to maximize performance as well as the development methodology used to ensure it is robust and reliable, particularly in the presence of artefacts typical of radio astronomy imaging. Finally, we report on a series of tests of the pipeline carried out using simulated LOFAR observations with a known population of transients.Comment: 30 pages, 11 figures; Accepted for publication in Astronomy & Computing; Code at https://github.com/transientskp/tk

Design Criteria to Architect Continuous Experimentation for Self-Driving Vehicles

The software powering today's vehicles surpasses mechatronics as the dominating engineering challenge due to its fast evolving and innovative nature. In addition, the software and system architecture for upcoming vehicles with automated driving functionality is already processing ~750MB/s - corresponding to over 180 simultaneous 4K-video streams from popular video-on-demand services. Hence, self-driving cars will run so much software to resemble "small data centers on wheels" rather than just transportation vehicles. Continuous Integration, Deployment, and Experimentation have been successfully adopted for software-only products as enabling methodology for feedback-based software development. For example, a popular search engine conducts ~250 experiments each day to improve the software based on its users' behavior. This work investigates design criteria for the software architecture and the corresponding software development and deployment process for complex cyber-physical systems, with the goal of enabling Continuous Experimentation as a way to achieve continuous software evolution. Our research involved reviewing related literature on the topic to extract relevant design requirements. The study is concluded by describing the software development and deployment process and software architecture adopted by our self-driving vehicle laboratory, both based on the extracted criteria.Comment: Copyright 2017 IEEE. Paper submitted and accepted at the 2017 IEEE International Conference on Software Architecture. 8 pages, 2 figures. Published in IEEE Xplore Digital Library, URL: http://ieeexplore.ieee.org/abstract/document/7930218

Developing a distributed electronic health-record store for India

The DIGHT project is addressing the problem of building a scalable and highly available information store for the Electronic Health Records (EHRs) of the over one billion citizens of India

Guiding the development of a controlled ecological life support system

The workshop is reported which was held to establish guidelines for future development of ecological support systems, and to develop a group of researchers who understand the interdisciplinary requirements of the overall program