No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Experiences with Technical Debt and Management Strategies in Production Systems Engineering
Abstract
Technical Debt (TD) has proven to be a suitable communication concept for software-intensive contexts to raise awareness regarding longterm negative effects of deviations from standards and guidelines. TD has also been introduced to systems engineering domain, to communicate design shortcomings in long-running, software-assisted systems. We analysed potential TD in the engineering data exchange for production system engineering. Similar to requirements engineering in software-intensive systems, data exchange in the design phase plays an integral part in Software Engineering (SE) for Production Systems Engineering: Specifications, and physical logic have to be derived from heterogeneous plant models or parameter tables designed by different stakeholders. However, traditional procedures and inadequate tool support lead to inefficient data extraction and integration. We identified debt arising from knowledge representation, data model and the exchange process. The refinement validation of identified TD was achieved through semi-structured interviews with representatives in two analysed companies. In an online survey with ten participants from an industrial consortium we evaluated whether the identified TD concepts also applied to other companies, which is true for the majority of TD. Furthermore, we discuss promising TD management strategies to repay and manage negative effects and the accumulation of additional debt, such as improved communication, test-driven model engineering and visualisation of engineering models.
... However, the lifecycle states of the assets represented in an engineering artifact may differ, e.g., due to changes, requiring domain experts to keep track of asset states for coordination. Hence, the representation of coordination knowledge at an engineering artifact level increases the risk of late changes, rework, and project delay [8]. The same applies to implicit knowledge representations on PPR dependencies, e.g., the screwdriver torque depending on the screw's material. ...
... Challenge 1. Coarse-grained representation of coordination states. Coordination states, like engineering, design, validation, or update states, have been traditionally documented for engineering artifacts, but may include several assets with various states due to parallel and iterative engineering [8]. Challenge 2. Scattered and heterogeneous domain knowledge required for coordination. ...
... The distribution of coordination knowledge, e.g., PPR asset states and dependencies between assets, on several engineering artifacts and information systems makes coordination harder and less efficient. Often coordination knowledge on assets and discipline-specific artifacts is informal domain knowledge, e.g., documented in private work spaces or e-mail discussions [8]. Some engineering tools consider detailed update states, but only in their scope, leading to diverse representations of coordination knowledge. ...
... Information System Engineering (ISE) for CPPS use cases, like digital shadows, require techniques for (i) automated aggregation and reduction of data, (ii) data analysis methods, (iii) data accessibility to stakeholder and systems and (iv) feedback for decision support and system controlling [14]. Therefore, the integration and harmonisation of all this data is an essential task in CPPS engineering to increase to overall data quality [28]. ...
... We will build on recent research of the Christian Doppler Laboratory on Security and Quality Improvement in the Production System Lifecycle [3,4,15,18,19,28], resulting from a technical debt analysis [28], which highlighted the gaps between established practices and state of the art. ...
... We will build on recent research of the Christian Doppler Laboratory on Security and Quality Improvement in the Production System Lifecycle [3,4,15,18,19,28], resulting from a technical debt analysis [28], which highlighted the gaps between established practices and state of the art. ...
Background. Consistent cross-disciplinary engineering data models have become increasingly important for engineers and project managers to validate system designs or implement new features in existing systems. However, discipline-specific designs (mechanical, electrical, automation engineering etc.) in isolated data models and proprietary software tools often create information silos. Similar to information systems, the challenges in Cyber-Physical Production System (CPPS) are a high amount of heterogeneous data that needs to be analysed and accessible for stakeholders and systems. Aim. The goal of the Flexible Multi-aspect Model Integration project is to support the integration of local engineering views and artefacts using the definition of common concepts across different disciplines. Therefore, the thesis project will provide capabilities to integrate and validate multi-aspect models more efficiently to increase the data quality. Method. The project will follow Design Science methodology to design and evaluate i) a method for collecting and defining common concepts across engineering disciplines, ii) a modularised software system design that enables flexible model integration processes in a CPPS context, and iii) an exemplary model integration process that supports data integration needs in the planning, operation, and analytics phase. The model integration processes are evaluated with real-world uses cases from industry. Conclusion. The information systems community will gain insight into the requirements in engineering and a method for agreeing on an inter-disciplinary common understanding from this research.
... Biffl et al. [19] studied the risks of TD in engineering artefacts related to data exchange (e.g., process documentation and configuration management). Waltersdorfer et al. [20] reported two types of documentation debt: Insufficient Data Model and Insufficient Product Process Resources Model. However, the code comment was not considered in the above studies. ...
This paper first examines the current state of industrial practice of documentation in automated production systems based on a large-scale survey in machine and plant manufacturing proving that companies still face major challenges in documentation. However, insufficient documentation creates friction since it may increase the risk of malfunction and high costs, and impede system development due to lack of traceability, especially for control software being one of the main functionality carriers. Therefore, secondly, a risk priority indicator RPI4DD is proposed to systematically capture the lack of control code documentation to avoid undesired costs due to inadequate documentation.
... Thus, interchanging information via common formats, such as AutomationML, can only be the first step. Also, despite tooling, proper (cross-disciplinary) stakeholder interaction is hard to realize in practice [1], [54]. ...
Cyber-Physical Production Systems (CPPSs) are envisioned as next-generation adaptive production systems combining modern production techniques with the latest information technology. A CPPS creates a complex environment between different domains (mechanical, electrical, software engineering), requiring multidisciplinary solutions to tackle growing complexity issues and reduce (maintenance) effort. Software plays an increasingly important role in assuring an effective and efficient operation of CPPSs. However, software engineering methods applied for CPPSs seem to lag behind modern software engineering methods, where tremendous progress has been made in the last years. We initiated the Software Engineering in Cyber-Physical Production Systems Workshop (SECPPS-WS) to analyze and overcome this gap. After two instances with mostly academic participants, we conducted a full-day workshop with nine industry representatives from eight companies that develop and maintain CPPSs. Each industry representative presented their current work and challenges. We collected these challenges and condensed a categorized list of challenges backed by industry statements and literature. This paper presents the resulting list and pointers to (partial) solutions to offer guidance for academia and identify promising research opportunities in this area.
... Therefore, domain experts can benefit from a reference model for categorizing and eliciting reusable assets in a selected scope [9]. Further, for PSE engineers, it is often unclear which engineers from other disciplines would benefit from their knowledge [47] and what model elements enable the identification of reusable assets. ...
In Production Systems Engineering (PSE), domain experts aim at reusing partial system designs implemented as Industry 4.0 assets and software. However, the knowledge on assets is often scattered across engineering artifacts from multiple disciplines and domain experts, making it difficult to find reusable assets and map them to requirements. In this paper, we (i) identify challenges and requirements for the representation of reuse knowledge in PSE, based on the results of a domain analysis in automotive manufacturing; (ii) refine the Industry 4.0 Asset Network (I4AN) meta-model that integrates multi-disciplinary dependencies between the assets; (iii) introduce the I4AN reference model that exposes recurring patterns; and (iv) present basic and applied patterns for reuse in PSE that aim at improving reuse efficiency and lowering risks. We evaluate the I4AN reference model and patterns with reuse scenarios in a feasibility study in automotive manufacturing. The study results indicate that the I4AN reference model and patterns satisfy the elicited requirements and enable PSE domain experts to identify patterns for reuse and sufficiently complete sets of reusable assets in their contexts.
... Views on data and local concepts are not visible to other stakeholders because of the discipline-specific focus [14]. A technical debt analysis highlights issues in Production Systems Engineering (PSE), like missing common identifiers, that can have a negative effect on effort and data quality for data integration [15]. ...
Industry 4.0 envisions adaptive production systems,i.e.,Cyber-Physical Production Systems (CPPSs), to manufacture products from a product line. Product-Process-Resource modeling represents the essential aspects of a CPPS. However,due to discipline-specific models, e.g., mechanical, electrical, and automation models, it is often unclear how to integrate the proprietary data into an integrated model due to missing common understanding. This paper investigates (i) how to integrate local engineering views with Common Concepts (CCs) and using them as a defined taxonomy for modeling a network of engineering concepts; (ii) how to build an engineering network graph for visualisation and analysis considering discipline-specific needs. We motivate a method to support CPPS engineering organisations to integrate their heterogeneous data using CCs. This builds the basis for defining multi-domain engineering graphs for visualisation and analysis aspects. In this paper, we present a research agenda discussing open issues and expected results.
... Some studies such as [20] characterise the current state of practices related to TD payment from the point of view of software practitioners. Other experiences such as [21] analysed potential TD in the engineering data exchange for production system engineering. Recent research studies, such as [22], are focussed on analysing whether TDs are self-fixed or are propagated to other developers who fix them. ...
Abstract This study argues the difference between security and privacy and outlines the concept of Privacy Debt as a new Technical Debt. Privacy is gaining momentum in any software system due to mandatory compliance with respect to laws and regulations. There are several types of technical debts within the umbrella of software engineering, and most of them arise during different phases of software development. Several research studies have been focussed on highlighting different types of technical debts. However, authors introduce Privacy Debt as a particular technical debt focussed on privacy management and linked to a perturbative method. Privacy must be considered not only as technical debt requirements but also at design and deployment phases, among others. In addition, this method is illustrated with a use case.
... However, these scripts could break easily if essential parts are changed, such as model changes. Therefore, this approach is potentially error-prone and inflexible, possibly introducing faulty designs or inconsistencies (Waltersdorfer et al., 2020). ...
Background. Systems modeling in Production Systems Engineering (PSE) is complex: Multiple views from different disciplines have to be integrated, while semantic differences stemming from various descriptions must be bridged. Aim. This paper proposes the Multi-view Modeling Framework (MvMF) approach and architecture of a model transformation pipeline. The approach aims to ease setup and shorten configuration effort of multi-view modeling operations and support the reusability of modeling environments, like additional view integration. Method. We combine multi-view modeling with principles from distributed, agile workflows, i.e., Git and Continuous Integration. Results. The MvMF provides a lightweight modeling operation environment for AutomationML (AML) models. We show MvMF capabilities and demonstrate the feasibility of MvMF with a demonstrating use case including fundamental model operation features, such as compare and merge. Conclusion. Increasing requirements on the traceability of changes and validation of system designs require improved and extended model transformations and integration mechanisms. The proposed architecture and prototype design represents a first step towards an agile PSE modeling workflow.
Purpose
Agile Production Systems Engineering (PSE) is characterised by parallel and iterative engineering of several disciplines. This multi-view engineering requires capabilities for tracing changes to support configuration management of PSE assets. Yet, traditional model transformation approaches in PSE do not preserve local views and hierarchies on concepts of PSE assets, such as plans and configurations. Thus, tracing multi-view changes to PSE assets is challenging.
Method
Following the Design Science approach, we (i) elicit requirements for tracing multi-view changes to PSE assets from a domain analysis in automotive manufacturing; (ii) introduce and evaluate the Traceable Multi-view Model Transformation (TMvMT) process; and (iii) propose the TMvMT pipeline architecture to provide traceable model integration capabilities for agile PSE.
Results
In a feasibility study on robot cell models, we evaluate the TMvMT process and architecture regarding the requirements for traceability compared to traditional approaches.
Conclusion
The proposed TMvMT approach provides traceability of changes in multi-view modelling as a basis through the separation of modelling transformation steps and provision of clear input and output artefacts to achieve traceable configuration management and validation of system designs for production system assets in agile PSE.
With the advent of regulations protecting users such as the General Data Protection Regulation, security and privacy concerns are playing a new role in small settings such as in very small entities. Their relevance is increasing, and privacy is being considered a Troy horse in software developments. In fact, privacy is a part of software architectural decisions, and they must be considered as a technical debt. The contributions of this paper are the following: a privacy debt definition with a principal and an interest, privacy‐related activities to be considered within the ISO/IEC 29110 basic profile, and the use of the net present value within this context. All these contributions help us to integrate privacy debt and VSE's software developments. We have defined privacy debt metaphor along the ISO/IEC 29110 basic profile as a special case of technical debt. We can use the NIST or the ISO/IEC 29100:2011 privacy frameworks with the ISO/IEC29110 basic profile. As part of the financial calculations of the privacy debt, we consider the net present value.
Relocating manufacturing plants is a phenomenon nowadays due to increasing changes in markets, materials, and labour cost. Under business pressure, while transferring the manufacturing systems, some technical compromises might be taken to start the production as soon as possible. A technical shortcut can provide a short-term benefit but may introduce a long-term negative impact. This work reports an industrial use case at a world-leading electronics manufacturer during its plant relocations. The study employs the Business Process Model and Notation (BPMN) to visualize the use case. There, an enlargement of BPMN, namely BPMN+TD, is achieved to assist in modelling TD artifacts.
Automated production systems (aPS) have a long lifetime, which requires significant maintenance cost. During the commissioning phase of aPS, which often occurs at customer sites, the on-site engineers are always under high pressure because the customers would like to start the production at the earliest. There, some compromises, so-called technical debt (TD), might be chosen. A technical compromise taken in the commissioning phase can provide a short-term benefit, but could yield a long-term negative impact on the maintenance phase. This study aims to apply Causal Loop Diagram (CLD) to model technical compromises in the aPS domain. A concept, namely CLD+TD, is proposed. Application examples of CLD+TD on some technical compromises collected from an industrial company working in automation are reported. A loop dominance analysis on a CLD+TD model is performed to derive the circular trend of technical compromise over time; thus, relevant maintenance activities could be planned accordingly. In addition, challenges leading to the technical compromises addressed in the presented use cases can support practitioners in developing appropriate solutions to manage the reported technical compromises in the commissioning phase.
The correct representation of discipline-specific and cross-specific knowledge in manufacturing contexts is becoming more important due to inter-disciplinary dependencies and overall higher system complexity. How- ever, domain experts do seldom have sufficient technical and theoretical knowledge or adequate tool support required for productive and effective model engineering and validation. Furthermore, increasing competi- tion and faster product lifecycle require the need for parallel collaborative engineering efforts from different workgroups. Thus, test-driven modeling, similar to test-driven software engineering can support the model engineering process to produce high-quality meta and instance models by incorporating consistency and se- mantic checks during the model engineering. We present a conceptual framework for model transformation with testing and debugging capabilities for production system engineering use cases supporting the mod- eling of discipline-specific AutomationML instance models. An exemplary workflow is presented and dis- cussed. Debug output for the models is generated to support non-technical engineers in the error detection of discipline-specific models. For future work user-friendly test definition is in planning.
Technical approaches to effective technical debt management-metrics, descriptors, transformation tools, and the like-are necessary but insufficient. We must also address drivers of technical debt that lie in the realm of psychology, politics, finance, and policy. The open question is: Will organizations exploit the impressive technology-based advancements in technical debt management to make engineers more effective? Or will they do something else with the cost savings those technologies generate? Psychology, politics, finance, and policy play critical roles in determining whether we gain control of technical debt. For example, if engineering groups become more adept at managing and preventing technical debt, while marketing and sales groups do not improve their own processes, the demands of marketing and sales groups for new products and capabilities might be associated with even shorter timelines than they now are. Schedule pressure usually results. Consequently, enterprise agility and engineering productivity might not benefit from the new technology-based technical debt management capabilities, even though the burden of technical debt might be reduced. Absent a significant change in the behavior of non-technologists, we can expect the effects of nontechnical causes of technical debt to persist, and possibly even to increase in significance. In this paper we explore eleven nontechnical phenomena that contribute to technical debt formation and persistence. We describe each one, and recommend lines of inquiry that can suggest (a) the significance of the phenomenon's effects on technical debt, from an organizational behavior perspective; (b) technologies that could aid in assessing that significance, and which could eventually aid in mitigating the phenomenon's deleterious effects; or (c) changes to phenomenon-related policy or accounting methods that could reduce the rate of formation or the persistence of technical debt.
The concept of Technical Debt describes a situation in which a technical compromise is made despite better knowledge. The survey presented delivers insights on Technical Debt in 48 German companies supplying automated production systems. The participating companies do have some immediate benefits from taking Technical Debt under time pressure, but encounter a significant higher long-term additional effort to recover from technical debt. However, awareness for Technical Debt at these companies is low. Therefore, the automated production system manufacturers need to keep a closer eye on expenditure for Technical Debt. The developed survey can be used as a self-assessment method for other companies to compare their results with the average results from this survey.
The most common format to store and provide technical documentation is PDF. However, due to the unstructured nature of the format these documents are often excluded from a granular semantic access. While more and more companies are implementing XML-based component content management systems which can deliver annotated structured content, older legacy documents remain in their monolithic form.
We developed a new approach which segments PDF documents into semantically related sections via classification knowledge gained from structured training content. This approach based on machine learning is independent from any formatting information or visual clues.
In this paper, we take the results from multiple previous works and combine them into a holistic procedure model. We introduce a parameterizable range finding algorithm to refine segment detection and provide a RDF-based format to exchange the generated metadata which can then be used to improve information retrieval for users.
Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both the evolution and maintenance of existing systems are hampered by Technical Debt. Although a lot of theoretical work on Technical Debt has been produced recently, its practical management lacks empirical studies. In this paper, we investigate the state of practice in several companies to understand what the cost of managing TD is, what tools are used to track TD, and how a tracking process is introduced in practice. We combined two phases: a survey involving 226 respondents from 15 organizations and an in-depth multiple case study in three organizations including 13 interviews and 79 Technical Debt issues. We selected the organizations where Technical Debt was better tracked in order to distill best practices. We found that the development time dedicated to managing Technical Debt is substantial (an average of 25% of the overall development), but mostly not systematic: only a few participants (26%) use a tool, and only 7.2% methodically track Technical Debt. We found that the most used and effective tools are currently backlogs and static analyzers. By studying the approaches in the companies participating in the case study, we report how companies start tracking Technical Debt and what the initial benefits and challenges are. Finally, we propose a Strategic Adoption Model for the introduction of tracking Technical Debt in software organizations.
Machine learning offers a fantastically powerful toolkit for building useful com-plex prediction systems quickly. This paper argues it is dangerous to think of these quick wins as coming for free. Using the software engineering framework of technical debt, we find it is common to incur massive ongoing maintenance costs in real-world ML systems. We explore several ML-specific risk factors to account for in system design. These include boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, configuration issues, changes in the external world, and a variety of system-level anti-patterns.
Technical Debt is a recent concept, borrowed from the financial domain. It has been recently used in software development to describe technical sub-optimal solutions that have short-term benefits but long-term extra-costs. However, no body of literature investigates how Automatic Production Systems companies deal with Technical Debt. We investigated how Technical Debt is known, how much it hurts and how is managed in an automatic production systems company. Results from one in-depth investigation show that the automatic production systems company spend quite a lot of resources because of Technical Debt, both in the extra-costs (interest) and in its management. The company presents moderate awareness of what Technical Debt is and how much is present in its systems. However, the tracking level is quite low. We, therefore, claim that Technical Debt needs more research in this domain, as it is a source of substantial extracosts and the current practices to manage it are not suitable.
Growing information systems (IS) often come along with growing IT complexity, because of emerging rag rug landscapes [15]. This development causes rising IT costs and dependencies, which hinder the maintenance and expansion of the IS landscape. This article outlines the current research on published and presented methods to manage the rising IT complexity in a literature re-view. Because definitions of “IT complexity” vary a lot in literature, this paper also includes a definition of the term. In addition to that, it delivers a presentation of the used research methodology. Subsequently, it presents the findings in literature, highlights the research gap and – based on the literature analysis – presents, the steps that need to be taken. A discussion of the results and a summary complete the article.
Technical debt (TD) is a metaphor for taking shortcuts or workarounds in technical decisions to gain short-term benefit in time-to-market and earlier software release. In this study, one large software development organization is investigated to gather empirical evidence related to the concept of technical debt management (TDM). We used the exploratory case study method to collect and analyze empirical data in the case organization by interviewing a total of 25 persons in eight software development teams. We were able to identify teams where the current strategy for TDM was only to fix TD when necessary, when it started to cause too much trouble for development. We also identified teams where the management had a systematic strategy to identify, measure and monitor TD during the development process. It seems that TDM can be associated with a similar maturity concept as software development in general. Development teams may raise their maturity by increasing their awareness and applying more advanced processes, techniques and tools in TDM. TDM is an essential part of sustainable software development, and companies have to find right approaches to deal with TD to produce healthy software that can be developed and maintained in the future.
Coping with evolution in automated production systems implies a cross-disciplinary challenge along the system's life-cycle for variant-rich systems of high complexity. The authors from computer science and automation provide an interdisciplinary survey on challenges and state of the art in evolution of automated production systems. Selected challenges are illustrated on the case of a simple pick and place unit. In the first part of the paper, we discuss the development process of automated production systems as well as the different type of evolutions during the system's life-cycle on the case of a pick and place unit. In the second part, we survey the challenges associated with evolution in the different development phases and a couple of cross-cutting areas and review existing approaches addressing the challenges. We close with summarizing future research directions to address the challenges of evolution in automated production systems.
A known problem in large software companies is to balance the prioritization of short-term with long-term viability. Specifically, architecture violations (Architecture Technical Debt) taken to deliver fast might hinder future feature development. However, some technical debt requires more interest to be paid than other. We have investigated which Technical Debt items generate more effort and how this effort is manifested during software development. We conducted a multiple-case embedded case study comprehending 7 sites at 5 large international software companies. We found that some Technical Debt items are contagious, causing other parts of the system to be contaminated with the same problem, which may lead to non- linear growth of interest. We also identify another socio- technical phenomenon, for which a combination of weak awareness of debt, time pressure and refactoring creates Vicious Circles of events during the development. Such phenomena need to be identified and stopped before the development is led to a crisis point. Finally, this paper presents a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics.
Context: Technical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. Objective: This work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. Method: A systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. Results: Ninety-four studies were finally selected. TD was classified into ten types, eight TDM activities were identified, and twenty-nine tools for TDM were collected. Conclusions: The term “debt” has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
Context: Technical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. Objective: This work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. Method: A systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. Results: Ninety-four studies were finally selected. TD was classified into ten types, eight TDM activities were identified, and twenty-nine tools for TDM were collected. Conclusions: The term “debt” has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
The intensive use of models in model-driven engineering (MDE) raises the need to develop meta-models with different aims, such as the construction of textual and visual modelling languages and the specification of source and target ends of model-to-model transformations. While domain experts have the knowledge about the concepts of the domain, they usually lack the skills to build meta-models. Moreover, meta-models typically need to be tailored according to their future usage and specific implementation platform, which demands knowledge available only to engineers with great expertise in specific MDE platforms. These issues hinder a wider adoption of MDE both by domain experts and software engineers. In order to alleviate this situation, we propose an interactive, iterative approach to meta-model construction, enabling the specification of example model fragments by domain experts, with the possibility of using informal drawing tools like Dia or yED. These fragments can be annotated with hints about the intention or needs for certain elements. A meta-model is then automatically induced, which can be refactored in an interactive way, and then compiled into an implementation meta-model using profiles and patterns for different platforms and purposes. Our approach includes the use of a virtual assistant, which provides suggestions for improving the meta-model based on well-known refactorings, and a validation mode, enabling the validation of the meta-model by means of examples.
NB You can find the journal version of this article published as "investigating technical debt accumulation and refactoring over time: a multiple case study" also available in this website from the same authors.
Abstract
A known problem in large software companies is to balance the prioritization of short-term with long-term responsiveness. Specifically, architecture violations (Architecture Technical Debt) taken to deliver fast might hinder future feature development, which would hinder agility. We conducted a multiple-case embedded case study in 7 sites at 5 large companies in order to shed light on the current causes for the accumulation of Architectural Technical Debt that causes effort. We provide a taxonomy of the factors and their influence in the accumulation of debt, and we provide a qualitative model of how the debt is accumulated and recovered over time.
Abstract,Case study is a suitable research methodology,for software engineering,research since it studies contemporary phenomena in its natural context. However, the understanding of what constitutes a case study varies, and hence the quality of the resulting studies. This paper aims,at providing,an introduction to case study methodology,and,guidelines for researchers,conducting,case studies and,readers studying,reports of such,studies. The content is based on the authors’ own,experience from conducting,and reading case studies. The terminology,and,guidelines are compiled,from,different methodology,handbooks,in other research domains, in particular social science and information systems, and adapted to the needs,in software,engineering. We,present,recommended,practices for software engineering,case studies as well,as empirically,derived,and,evaluated,checklists for researchers and readers of case study research. Keywords,Casestudy.Research methodology.Checklists .Guidelines
Background. In Production Systems Engineering (PSE), the planning of production systems involves domain experts from various domains, such as mechanical, electrical and software engineering collaborating and modeling their specific views on the system. These models, describing entire plants, can reach a large size (up to several GBs) with complex relationships and dependencies. Due to the size, ambiguous semantics and diverging views, consistency of data and the awareness of changes are challenging to track. Aim. In this paper we explore visualizations mechanisms for a model inspection tool to support consistency checking and the awareness of changes in multi-disciplinary PSE environments, as well has more efficient handing of AutomationML (AML) files. Method. We explore various visualization capabilities that are suitable for hierarchical structures common in PSE and identified requirements for a model-inspection tool for PSE purposes based on workshops with our company partner. A pr oof-of concept software prototype is developed based on the elicited requirements. Results. We evaluate the effectiveness of our Information Visualisation (InfoVis) approach in comparison to a standard modeling tool in PSE, the AutomationML Editor. The evaluation showed promising results for handling large-scale engineering models based on AML for the selected scenarios, but also areas for future improvement, such as more advanced capabilities. Conclusion. Although InfoVis was found useful in the evaluation context, in-depth analysis with domain experts from industry regarding usability and features remain for future work.
In the parallel engineering of large and long-running automation systems, such as Production Systems Engineering (PSE) projects, engineering teams with different backgrounds work in a so-called Round-Trip Engineering (RTE) process to iteratively enrich and refine their engineering artifacts, and need to exchange data efficiently to prevent the divergence of local engineering models. Unfortunately, the heterogeneity of local engineering artifacts and data, coming from several engineering disciplines, makes it hard to integrate the discipline-specific views on the data for efficient synchronization.
In the parallel engineering of industrial production systems, domain experts from several disciplines need to exchange data efficiently to prevent the divergence of local engineering models. However, the data synchronization is hard (a) as it may be unclear what data consumers need and (b) due to the heterogeneity of local engineering artifacts. In this paper, we introduce use cases and a process for efficient Engineering Data Exchange (EDEx) that guides the definition and semantic mapping of data elements for exchange and facilitates the frequent synchronization between domain experts. We identify main elements of an EDEx information system to automate the EDEx process. We evaluate the effectiveness and effort of the EDEx process and concepts in a feasibility case study with requirements and data from real-world use cases at a large production system engineering company. The domain experts found the EDEx process more effective and the EDEx operation more efficient than the traditional point-to-point process, and providing insight for advanced analyses.
Dieses Buch ist eine Gemeinschaftsarbeit des AutomationML-Konsortiums. Es gibt erstmalig einen umfassenden Überblick über AutomationML und seine Integration von CAEX, COLLADA und PLCopen XML. AutomationML versteht sich als wegweisender Beitrag zur Förderung der Interoperabilität zwischen digitalen Werkzeugen für alle Teilschritte des Engineering-Prozesses in der Anlagenplanung. Das Datenformat wurde im Frühjahr 2008 auf der Hannovermesse der Öffentlichkeit vorgestellt und hat bei Anwendern und Toolherstellern deutliches Aufsehen erregt. AutomationML ist das erste kostenfrei zugängliche, offene und XML-basierte Format, das übergreifend eine Vielzahl von Planungsaspekten kombiniert. Das Buch ist als Kompendium für die Technologie „AutomationML“ und gleichzeitig als Entscheidungshilfe konzipiert. Es ist an Verantwortungsträger, Hersteller, Anbieter und Anwender von Planungswerkzeugen sowie an Entwicklungsingenieure und Systemintegratoren gerichtet. Für Studenten und Forscher in Hochschulen und Universitäten stellt dieses Buch eine Fundgrube dar, da AutomationML zur Anwendung und Entwicklung neuer Methoden und Ansätze anregt, die mit heutigen Werkzeugen (noch) nicht realisierbar sind.
„Allen, die wissen wollen, wie sie an dieser Entwicklung partizipieren können, sei dieses Buch sehr empfohlen." Prof. Dr.-Ing. Alexander Fay, Helmut Schmidt Universität Hamburg
„Das vorliegende Buch bietet sowohl Managern, Entwicklern als auch Anwendern einen Einblick in die Möglichkeiten und den Nutzen von AutomationML." Anton Hirzle, Daimler AG
Application fields of automated production systems are varied, e.g. automotive, aerospace and food industry, just to name a few. The complexity of such production systems has significantly been increased in the last years, (Koren et al., CIRP Ann Manuf Technol 48(2):527–540, 1999). This increase was a result of the increased complexity and variance of products. As a result of this, the engineering workflow of automated production system has continuously been adapted to new requirements. In this regards, this chapter shows and describes the current engineering workflow of automated production systems based on experience in the field of production system for the automotive industry. The main focus of this description is set on the established tool-chains and used tools to create engineering information as well as data formats to save and exchange information between tools and involved personnel. In the introduction of this chapter, differences between an automated production system and a cyber-physical system are given. Current production systems could be named CPPS but this term is not popular in the field of production system builder as well as production owners. But in spite of that the end of this chapter gives an outlook of the future of automated production systems in direction of CPPS.
During the early formulation stage of a mission concept, the multiple and frequent changes made to the system design present various systems engineering challenges, such as ensuring the internal consistency of multiple engineering reports describing distinct aspects of the same flight system, or minimizing the amount of rework needed when the design is modified. Such challenges have been partly addressed by the Model-Based Systems Engineering Team (MSET) on the Europa Project at the Jet Propulsion Laboratory (JPL), through the application of Model-Based Systems Engineering (MBSE) techniques. This presentation first discusses the principle of Single-Source-of-Truth (SSoT) and how it can be supported by the use of a well-structured system model relying on a rich vocabulary (e.g., based on the SysML language). The application of modeling patterns to organize the Flight System design information and make it queryable is then examined, with specific examples used on the Europa project. The benefits of checking formal rules to verify the correctness of the model and ensure that changes were properly incorporated are also discussed. The presentation also identifies model organization strategies that maximize the reuse of information across the multiple design architectures explored in early formulation, as well as various practices used to control the numerous changes made to the model as the design matures. This has proved to play a key role in delivering high-quality representations of the spacecraft design to a variety of stakeholders as well as demonstrating its viability.
This book provides guidelines for practicing design science in the fields of information systems and software engineering research. A design process usually iterates over two activities: first designing an artifact that improves something for stakeholders and subsequently empirically investigating the performance of that artifact in its context. This validation in context is a key feature of the book - since an artifact is designed for a context, it should also be validated in this context.
Technical debt is a metaphor for delayed software maintenance tasks. Incurring technical debt may bring short-term benefits to a project, but such benefits are often achieved at the cost of extra work in future, analogous to paying interest on the debt. Currently technical debt is managed implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact. Therefore, we have proposed a new approach to managing technical debt, which we believe to be helpful for software managers to make informed decisions. In this study we explored the costs of the new approach by tracking the technical debt management activities in an on-going software project. The results from the study provided insights into the impact of technical debt management on software projects. In particular, we found that there is a significant start-up cost when beginning to track and monitor technical debt, but the cost of ongoing management soon declines to very reasonable levels.
Building information modeling (BIM) is one of the most promising recent developments in the architecture, engineering, and construction (AEC) industry. With BIM technology, an accurate virtual model of a building is digitally constructed. This model, known as a building information model, can be used for planning, design, construction, and operation of the facility. It helps architects, engineers, and constructors visualize what is to be built in a simulated environment to identify any potential design, construction, or operational issues. BIM represents a new paradigm within AEC, one that encourages integration of the roles of all stakeholders on a project. In this paper, current trends, benefits, possible risks, and future challenges of BIM for the AEC industry are discussed. The findings of this study provide useful information for AEC industry practitioners considering implementing BIM technology in their projects.
To model increasingly adaptive production systems, skills are used to describe generic capabilities of the system components. In this paper, the authors extend the well-known division of production entities into product, process, and resource (PPR) with a skill definition. There are two main advantages for this approach: First, using the PPR entity concepts for the skill definition allows easy integration into existing models and tools. Second, there is a natural tendency to define very generic skills to capture all possible use cases. But at some point, skills have to be translated into precise instructions for execution. The model makes this dichotomy explicit and provides a common taxonomy for stakeholders concerned with skills on different abstraction levels.
ContextWhilst technical debt is considered to be detrimental to the long term success of software development, it appears to be poorly understood in academic literature. The absence of a clear definition and model for technical debt exacerbates the challenge of its identification and adequate management, thus preventing the realisation of technical debt's utility as a conceptual and technical communication device.Objective
To make a critical examination of technical debt and consolidate understanding of the nature of technical debt and its implications for software development.Method
An exploratory case study technique that involves multivocal literature review, supplemented by interviews with software practitioners and academics to establish the boundaries of the technical debt phenomenon.ResultA key outcome of this research is the creation of a theoretical framework that provides a holistic view of technical debt comprising a set of technical debts dimensions, attributes, precedents and outcomes, as well as the phenomenon itself and a taxonomy that describes and encompasses different forms of the technical debt phenomenon.Conclusion
The proposed framework provides a useful approach to understanding the overall phenomenon of technical debt for practical purposes. Future research should incorporate empirical studies to validate heuristics and techniques that will assist practitioners in their management of technical debt.
With a large and rapidly changing codebase, Google software engineers are constantly paying interest on various forms of technical debt. Google engineers also make efforts to pay down that debt, whether through special Fixit days, or via dedicated teams, variously known as janitors, cultivators, or demolition experts. We describe several related efforts to measure and pay down technical debt found in Google's BUILD files and associated dead code. We address debt found in dependency specifications, unbuildable targets, and unnecessary command line flags. These efforts often expose other forms of technical debt that must first be managed.
The growing number of computer programs used to model different aspects of railway operations has created the need for a simple and efficient way to transfer data between applications. In the past, specialized interface programs have been developed to transfer data but this is an inefficient and time-consuming process. As the number of different railway simulation and operations programs increases, developing and maintaining individual interfaces will become impractical. RailML has been developed using the XML (eXtensible Markup Language) to simplify data transfer through the use of a common data structure. Programs using the RailML language produce export files with the RailML structure, these files can then be used directly by other RailML compatible programs. RailML is an open source project being supported and developed by a growing list of partners. The paper presents a more detailed description of RailML, outlines the application's current status, and invites new partners to join the consortium.
Test-Driven Development: A Practical Guide presents TDD from the perspective of the working programmer: real projects, real challenges, real solutions, ...real code. Dave Astels explains TDD through a start-to-finish project written in Java and using JUnit. He introduces powerful TDD tools and techniques; shows how to utilize refactoring, mock objects, and "programming by intention"; even introduces TDD frameworks for C++, C#/.NET, Python, VB6, Ruby, and Smalltalk. Invaluable for anyone who wants to write better code... and have more fun doing it!
This contribution presents the basic architecture of the neutral data format AutomationML developed by the companies Daimler, ABB, Siemens, Rockwell, Kuka, Zuhlke, netAllied and the universities of Magdeburg and Karlsruhe. AutomationML serves for the data exchange between manufacturing engineering tools and therefore supports the interoperability between them. It covers information about the plant structure (topology and geometry) and the plant behaviour (logic and kinematics). The first version of AutomationML has been presented at the Hannover fair in 2008.
Within the engineering of automated systems, different engineering disciplines are involved. Typically intermediate results from one discipline are handed over to another discipline. These results are refined throughout domain specific activities, and then handed over to other disciplines, incl. the originating one. This results in hidden dependencies between the involved disciplines, the planning assumptions as well as results, and the technical artefacts. This paper shows a method, proven in the engineering of automated plants in the metal industry, to gain explicit knowledge about the technical dependencies within the engineering of automated systems. Therefore the typical characteristics of the engineering process are described first, followed by a description how to capture the engineering process and a systematic approach to make these dependencies visible.
Information Visualization is a relatively young field that is acquiring more and more consensus in both academic and industrial environments. This concise introduction to the subject explores the use of computer-supported interactive graphical representations to explain data and amplify cognition. Written in a lively, yet rigorous, style the book explores ways of communicating ideas or facts about data, and shows how to validate hypotheses, and facilitate the discovery of new facts via exploration. The concepts outlined in the book are illustrated in a simple and thorough manner, building a reference for those situations in which graphic representation of information, generated and assisted by the use of computer tools, can help in visualizing ideas, data and concepts. With suggestions for setting communications systems based on, or availing of, graphic representations, this textbook illustrates cases, situations, tools and methods which help make the graphic representations of information effective and efficient.
Semantic integration is an active area of research in several disciplines, such as databases, information-integration, and ontologies. This paper provides a brief survey of the approaches to semantic integration developed by researchers in the ontology community. We focus on the approaches that differentiate the ontology research from other related areas. The goal of the paper is to provide a reader who may not be very familiar with ontology research with introduction to major themes in this research and with pointers to different research projects. We discuss techniques for finding correspondences between ontologies, declarative ways of representing these correspondences, and use of these correspondences in various semantic-integration tasks.
Seamless automation engineering with AutomationML®
- Lorenz Hundt
- Rainer Drath
- Arndt Lüder
- Jörn Peschke
Lorenz Hundt, Rainer Drath, Arndt Lüder, and Jörn Peschke. 2008. Seamless
automation engineering with AutomationML®. In 2008 IEEE International Technology Management Conference (ICE). IEEE, 1-8.
Prentice Hall Upper Saddle River . Ken Schwaber and Mike Beedle
- Ken Schwaber
- Mike Beedle
- Schwaber Ken
Richtlinie 3695: Engineering von Anlagen - Evaluieren und Optimieren des Engineerings
- Verein Deutscher Ingenieure
- Ingenieure Verein Deutscher
Prentice Hall Professional Technical Reference . Dave Astels
- Dave Astels
- Astels Dave
Technical Debt Quadrant. Martin Fowler
- Martin Fowler
Per Runeson and Martin Höst. 2009. Guidelines for conducting and reporting case study research in software engineering
- Per Runeson
- Martin Höst
- Runeson Per