Large software development organizations put enormous amount of effort not only for responding to continuous requests of customers but also for reengineering and refactoring activities to keep their product maintainable. Often rapid and immature feature deliveries over long period of time gradually decrease the product quality, and therefore the refactoring activities become costly and effort-intensive. This situation is described by the concept of “technical debt”, which represents the accumulated rework that organization has to do in order to prevent the slowdown of the development. In this paper we report results of a case study at Ericsson on using software metrics for moving towards proactive management of technical debt. Our observations show that there are four distinguishable maturity phases of quality management over the eight years of development time of two large products: Start-n-stop, Reactive, Systematic, and Proactive quality management. Three sophisticated metrics are applied to help the organizations to move towards Proactive management of technical debt. These metrics are used on a systematic basis to provide information on the areas of the product that have tendency of accumulating technical debt. Software engineers use this information for making decisions on whether or not the pinpointed areas should be refactored.
This publication introduces a state space exploration tool that is based on representing the model under verification as a piece of C++ code that obeys certain conventions. This approach facilitates experimenting with many kinds of modelling ideas. On the other hand, the use of stubborn sets and symmetries requires that either the modeller or a preprocessor tool analyses the model at a syntactic level and expresses stubborn set obligation rules and the symmetry mapping as suitable C++ functions. The tool supports the detection of illegal deadlocks, safety errors, and may progress errors. It also partially supports the detection of must progress errors.
. Due to the limitations of anti-phishing software and limitations in creating such software, we propose the usage of metamodelling frameworks and software tools for implementing software systems where phishing prevention is already designed as a part of the system itself. An expressive computational, verifiable and validatable metamodel is created that captures user behaviour. Next it is shown through examples that the metamodel follows and describes reported phishing scams accurately. The model is then used to create specification in an executable formal specification tool. The formal specification, which can be executed to observe user behaviour, can be used as a building block in the specification of a larger software system, resulting in an inherently phish-ing-resilient software system design in the form of a formal specification.
. The present work describes a technology for developing software in unique and large projects. The present model-based technology supports the projects where a single software product is developed. This is different from the block languages and model-based software tools on the market, which provide a set of components where the reusability of the components is an important requirement. A distinguished feature of the technology is a support that it gives to the software design at an early stage of the design process. The design process begins on the architectural level where implementation details can be ignored. Components are introduced considering their functionality, but the implementability of a component is taken into account at the early stage of the design process only based on an experience of a designer.
. Continuous delivery is a software development practice where new features are made available to end users as soon as they have been implemented and tested. In such a setting, a key technical piece of in-frastructure is the development pipeline that consists of various tools and databases, where features flow from development to deployment and then further to use. Metrics, unlike those conventionally used in software development, are needed to help define the performance of the development pipeline. In this paper, we address metrics that are suited for supporting continuous delivery and deployment through a descriptive and exploratory single case study on a project of a mid-sized Finnish software company, Solita Plc. As concrete data, we use data from project ”Lupapiste”, a web site for managing municipal authorizations and permissions.
. Reuse is one of the classic ways to improve productivity in software development. Indeed, benefiting from software components, patterns, and solutions that have been developed in the company potentially leads to savings in all phases of software intensive work. However, putting such an approach to practice is far from being simple. In particular, when considering software companies that specialize in customer-specific software projects, it is common that similar designs and technology choices are made in parallel without project-crossing knowledge. In such settings, there is a lack of a systematic approach between projects to spread good practices or to eliminate bad ones. In this paper, we propose solving such problems with an information system that acts as a marketplace for promoting software reuse within a project organization, much to the same flavor as app stores are used to promote mobile applications. The paper provides insight to the design of our prototype system, as well as contains preliminary views from users in one organization.
. Reuse of analysis methods and tools for data from different issue management systems is challenging because there are differences in how the data is accessed and represented. While various approaches for collecting and analysing software engineering data have been developed, they do not generally pay so much attention into how to actually get the data from various sources. This paper presents a combined model for issue management data that is based on an investigation of four issue management systems. It also presents a proof of concept tool that can collect issue management data from different services into our analysis and visualization framework using an API description language that de-fines how to get the issue management data and how to convert it into our model. The aim of this approach is to allow the addition of new data sources by simply providing their API descriptions.
. Typical management strategies proven to work in already established businesses do not work as expected in startups. Startups do not yet have a business model and product that they could focus on, but are still looking for a working business model. Lean Startup is a method for startup management that focuses on quick iteration and on fast learning to find an iterable business model. As a method, Lean Startup is still quite novel. It does not have much scientific literature written about it, but it is used by startups. The two case study companies were both positive about Lean Startup and felt that the method had given them a helpful approach.
. Testing has become an integral part of most software projects. It ac-counts for even as high a share as 40% of the overall work effort. At the same time software projects are systematically exceeding their effort and schedule forecasts. Regardless of the overruns and big share of testing, there is very little advice for estimating testing activities. This case study research assesses the current practice of estimating testing activities, and the impact of these practices on estimation and project success. Based on the interviews with 11 stakeholders involved in two case projects and examination of project documentation, this study shows that companies easily deviate from their standard procedures, when estimating testing. This may even lead to severe estimation errors. The deviations can be explained by negative attitudes towards testing. Furthermore, this study shows that the extant literature has sparsely addressed estimation of software testing.
. In instruction set diversification, a ”language” used in a system is uniquely diversified in order to protect software against malicious attacks. In this paper, we apply diversification to Linux shell commands in order to prevent malware from taking advantage of the functionality they provide. When the Linux shell commands are diversified, malware no longer knows the correct commands and cannot use the shell to achieve its goals. We demonstrate this by using Shellshock as an example. This paper presents a scheme that diversifies the commands of Bash, the most widely used Linux shell and all the scripts in the system. The feasibility of our scheme is tested with a proof-of-concept implementation. We also present a study on the extent of changes required to make all the trusted scripts and applications in the system use the new diversified shell commands.
. Regression test suites of evolving software systems are often crucial to maintaining software quality in the long term. They have to be effective in terms of detecting faults and helping their localization. However, to gain knowledge of such capabilities of test suites is usually difficult. We propose a method for deeper understanding of a test suite and its relation to the program code it is intended to test. The basic idea is to decompose the test suite and the program code into coherent logical groups which are easier to analyze and understand. Coverage and partition metrics are then extracted directly from code coverage information to characterize a test suite and its constituents. We also use heat-map tables for test suite assessment both at the system level and at the level of logical groups. We employ these metrics to analyze and evaluate the regression test suite of the WebKit system, an industrial size browser engine with an extensive set of 27,000 tests.
. A limitation in the design of the interface of C++ standard priority queues is addressed. The use of priority queues in Dijkstra’s shortest path search algorithm is used as an example. Priority queues are often implemented using heaps. There is a problem, as it may be necessary to change the priority of an element while it is in the queue, but finding the element from within a heap is costly. The problem may be solved by keeping track, in a variable that is outside the heap, of the position of the element in the heap. Unfortunately, this is impossible with the template class interface used by the C++ standard library priority queue. In this research, the problem is analysed in detail. Four interface designs and corresponding implementations are suggested. They are compared experimentally to each other and the C++ design.
. This research is based on three drivers. Firstly, software development and deployment cycles are getting shorter and require automatic building and deployment processes. Secondly, elastic clouds are available for both hosting and development of applications. Thirdly, the increasingly popular DevOps introduces new organizational and business culture. This paper presents a research prototype and demonstrator of an integrated development tool. The tool is cloud based and thus accessible from any Web-enabled terminal. Automation is maximized so that deployment cycles can be as fast as possible. Since the aim is to use cloud resources as a utility in a flexible manner, cloud brokering – i.e. finding the most suitable provider – is included in the system. The contributions of the paper include: an idea of a new kind of DevOps tool, description on how it can be implemented on top of standard components and implications to software development processes.
. This paper presents parameter and expression editors of the design tool Kactus2. It is aimed at digital System-on-Chip (SoC) designs based on IEEE 1685 IP-XACT XML metadata standard. SoC’s are constructed by as-sembling parametrized components using generators for hardware language code and design configuration. The key challenges are the management of dependencies between thousands of parameters, as well as immediate validation and evaluation while editing. The expression editor in this paper has been designed to overcome these challenges. The editors include real-time syntax, semantic analysis and the use of UUIDs behind user displayed parameter names. The implementations for these have been published in Kactus2 v2.8 open source code, written in C++/Qt5, and consisting of 3000 LoC in the release. An independent industrial user on the SoC domain has verified the correctness, completeness and usability of the new solutions. The designed editors significantly improve the SoC parameter editing and design configuration.
GitHub is an online platform for hosting projects that use the Git revision control system to manage code. Its lightweight issue tracker helps to maintain lists of issues identified during the development process, including bugs, features, or other software artifacts. Although issue tracking software has been practically used in software industry, studies on using it to manage requirements remain insufficient. This paper tackles the issue by presenting a semi-formal guideline for managing requirements in agile software development projects using GitHub. The guideline is evaluated on a theoretical level by analyzing how well it guides to manage requirements and fits in an agile software development setting. It is compared against lean principles. In addition, the guideline is put into use in a case study. The studies indicate that the guideline and GitHub are well-suited for requirements management in an agile
. Software security is a combination of security methods, techniques and tools, aiming to promote data confidentiality, integrity, usability, availabil-ity and privacy. In order to achieve concrete and measurable levels of software security, several international, national and industry-level regulations have been established. Finnish governmental security standard collection, VAHTI, is one of the most extensive example of these standards. This paper presents a selection of methods, tools, techniques and modifications to Scrum software development method to achieve the levels of security compliant with VAHTI instructions for software development. These comprise of security-specific modifications and additions to Scrum roles, modifications to sprints, and inclusion of special hardening sprints and spikes to implement the security items in the product backlog. Security requirements are transformed to security stories, abuse cases and other security-related tasks. Definition of done regarding the VAHTI requirements on is established and the steps to achieve it are described.
. Log files are often the only way to identify and locate errors in a deployed system. This paper presents a new log file analyzing framework, LOGDIG, for checking expected system behavior from log files. LOGDIG is a generic framework, but it is motivated by logs that include temporal data (timestamps) and system-specific data (e.g. spatial data with coordinates of moving objects), which are present e.g. in Real Time Passenger Information Systems (RTPIS). The behavior mining in LOGDIG is state-machine-based, where a search algorithm in states tries to find desired events (by certain accuracy) from log files. That is different from related work, in which transitions are directly connected to lines of log files. LOGDIG reads any log files and uses metadata to interpret input data. The output is static behavioral knowledge and human friendly composite log for reporting results in legacy tools. Field data from a commercial RTPIS called ELMI is used as a proof-of-concept case study. LOGDIG can also be configured to analyze other systems log files by its flexible metadata formats and a new behavior mining language.
. We present and compare two different implementations of quotient types in Intensional Type Theory. We first introduce quotients as particular inductive-like types following Martin Hofmann’s extension of Calculus of Constructions with quotient types [6]. Then we give an impredicative encoding of quotients. This implementation is reminiscent of Church numerals and more generally of encodings of inductive types in Calculus of Constructions.
