Search

Artefacts play a vital role in software and systems development processes. Other terms like documents, deliverables, or work products are widely used in software development communities instead of the term artefact. In the following, we use the term 'artefact' including all these other terms. Despite its relevance, the exact denotation of the term 'artefact' is still not clear due to a variety of different understandings of the term and to a careless negligent usage. This often leads to approaches being grounded in a fuzzy, unclear understanding of the essential concepts involved. In fact, there does not exist a common terminology. Therefore, it is our goal that the term artefact be standardised so that researchers and practitioners have a common understanding for discussions and contributions. In this position paper, we provide a positioning and critical reflection upon the notion of artefacts in software engineering at different levels of perception and how these relate to each other. We further contribute a metamodel that provides a description of an artefact that is independent from any underlying process model. This metamodel defines artefacts at three levels. Abstraction and refinement relations between these levels allow correlating artefacts to each other and defining the notion of related, refined, and equivalent artefacts. Our contribution shall foster the long overdue and too often underestimated terminological discussion on what artefacts are to provide a common ground with clearer concepts and principles for future software engineering contributions, such as the design of artefact-oriented development processes and tools. [ABSTRACT FROM AUTHOR]

In 1997, Heinrich Hussmann accepted a professorship for software technology at the Institute for Software and Multimedia Technology at the Technical University of Dresden. Heinrich Hussmann studied informatics at the Technical University of Munich. In the year 2002 Heinrich Hussmann returned to Munich to start the media informatics program at the Ludwig-Maximilians-Universität (LMU). [Extracted from the article]

Not only system assurance drives a need for semantically richer relationships across various artifacts, work products, and items of information than are implied in the terms “trace and traceability” as used in current standards and textbooks. This paper deals with the task of working out artifacts in software and system development, their representation, and the analysis and documentation of the relationships between their logical contents—herein referred to as tracing and traceability; this is a richer meaning of traceability than in standards like IEEE STD 830. Among others, key tasks in system development are as follows: capturing, analyzing, and documenting system-level requirements, the step to functional system specifications, the step to architectures given by the decomposition of systems into subsystems with their connections and behavioral interactions. Each of these steps produces artifacts for documenting the development, as a basis for a specification and a design rationale, for documentation, for verification, and impact analysis of change requests. Crucial questions are how to represent and formalize the content of these artifacts and how to relate their content to support, in particular, system assurance. When designing multi-functional systems, key artifacts are system-level requirements, functional specifications, and architectures in terms of their subsystem specifications. Links and traces between these artifacts are introduced to relate their contents. Traceability has the goal to relate artifacts. It is required for instance in standards for functional system safety such as the ISO 26262. An approach to specifying semantic relationships is shown, such that the activity of creating and using (navigating through) these relationships can be supported with automation. [ABSTRACT FROM AUTHOR]

This paper addresses the specification of and reasoning about interactive real-time systems, their interfaces, and architectures as well as their properties in terms of assumptions and commitments. Specifications are structured into assumptions restricting the behavior of the operational context of systems and commitments about the system behavior (also called rely/guarantee or assumption/promise specification patterns in the literature). A logical approach to assumption/commitment contracts is worked out based on a mathematical system model: Based on the theoretical foundation architectural issues are considered for a systematic use of assumption/commitment patterns in system specification and architecture design. [ABSTRACT FROM AUTHOR]

Copyright of Informatik Spektrum is the property of Springer Nature and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)

Copyright of Informatik Spektrum is the property of Springer Nature and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)