Tool Support for Decision and Usage Knowledge in Continuous Software Engineering

Continuous software engineering copes with frequent changes and quickly evolving development projects while maintaining a high software quality. Developers require knowledge about former and ongoing decisions as well as about the users' needs to evolve software. Thus, decision and usage knowledge are two important knowledge types in continuous software engineering. Issue tracking and version control systems are widely used in continuous software engineering but lack a structured approach to integrate decision and usage knowledge. In this paper, we present ideas and requirements for a tool support to manage decision and usage knowledge in continuous software engineering. As a first step, we introduce the JIRA DecDoc plug-in for documenting decision knowledge

Architectural reflection for software evolution

Software evolution is expensive. Lehman identifies several problems associated with it: Continuous adaptation, increasing complexity, continuing growth, and declining quality. This paper proposes that a reflective software engineering environment will address these problems by employing languages and techniques from the software architecture community. Creating a software system will involve manipulating a collection of views, including low-level code views and high-level architectural views which will be tied together using reflection. This coupling will allow the development environment to automatically identify inconsistencies between the views, and support software engineers in managing architectures during evolution. This paper proposes a research programme which will result in a software engineering environment which addresses problems of software evolution and the maintenance of consistency between architectural views of a software system

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

Large scale continuous integration and delivery:Making great software better and faster

Since the inception of continuous integration, and later continuous delivery, the methods of producing software in the industry have changed dramatically over the last two decades. Automated, rapid and frequent compilation, integration, testing, analysis, packaging and delivery of new software versions have become commonplace. This change has had significant impact not only on software engineering practice, but on the way we as consumers and indeed as a society relate to software. Moreover, as we live in an increasingly software-intensive and software-dependent world, the quality and reliability of the systems we use to build, test and deliver that software is a crucial concern. At the same time, it is repeatedly shown that the successful and effective implementation of continuous engineering practices is far from trivial, particularly in a large scale context. This thesis approaches the software engineering practices of continuous integration and delivery from multiple points of view, and is split into three parts, accordingly. Part I focuses on understanding the nature of continuous integration and differences in its interpretation and implementation. In order to address this divergence and provide practitioners and researchers alike with better and less ambiguous methods for describing and designing continuous integration and delivery systems, Part II applies the paradigm of system modeling to continuous integration and delivery. Meanwhile, Part III addresses the problem of traceability. Unique challenges to traceability in the context of continuous practices are highlighted, and possible solutions are presented and evaluated

Nmag micromagnetic simulation tool - software engineering lessons learned

We review design and development decisions and their impact for the open source code Nmag from a software engineering in computational science point of view. We summarise lessons learned and recommendations for future computational science projects. Key lessons include that encapsulating the simulation functionality in a library of a general purpose language, here Python, provides great flexibility in using the software. The choice of Python for the top-level user interface was very well received by users from the science and engineering community. The from-source installation in which required external libraries and dependencies are compiled from a tarball was remarkably robust. In places, the code is a lot more ambitious than necessary, which introduces unnecessary complexity and reduces main- tainability. Tests distributed with the package are useful, although more unit tests and continuous integration would have been desirable. The detailed documentation, together with a tutorial for the usage of the system, was perceived as one of its main strengths by the community.Comment: 7 pages, 5 figures, Software Engineering for Science, ICSE201

Parameter estimation for Boolean models of biological networks

Boolean networks have long been used as models of molecular networks and play an increasingly important role in systems biology. This paper describes a software package, Polynome, offered as a web service, that helps users construct Boolean network models based on experimental data and biological input. The key feature is a discrete analog of parameter estimation for continuous models. With only experimental data as input, the software can be used as a tool for reverse-engineering of Boolean network models from experimental time course data.Comment: Web interface of the software is available at http://polymath.vbi.vt.edu/polynome