Artefacts play a vital role in today's software and systems development processes. The notion of artefacts is widely used in software development communities. Despite the relevance and frequent use of the term artefact', the exact denotation of this term is still not clear, due to a variety of different understandings of the term and to a careless negligent usage. This often leads to conceptual and formal results being grounded in a fuzzy, unclear understanding of the essential concepts involved. In fact, there does not exist a common terminology. Other terms like documents, deliverables, or work products are used instead of the term artefact. 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 critical reflection upon the notion of artefact in software engineering at different levels of perception and how these relate to each other. We further contribute a meta model that provides a description of an artefact that is independent from any underlying process. The meta model defines an artefact at three levels. Abstraction and refinement relations between these levels allow correlating artefacts to each other and defining the notion of 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.
One exemplary instantiation of the meta model forms REMsES @cite_8 , which provides a process guide for supporting requirements engineering processes in the automotive industry. There, the artefact model provides a basic structure for the definition of the artefacts, their assignment to abstraction levels and content categories, and the relations between the artefacts. It further defines general control flow dependencies within requirements engineering processes. Further fields of applications can be found in the broader field of software engineering process modelling, e.g. for synchronising various software process models via artefacts as interfaces @cite_16 or for modelling artefact-focused method-neutral software process improvement models @cite_1 .
@cite_16 @cite_1 @cite_8
2257347947 1843968717
Software processes improvement (SPI) is a challenging task, as many different stakeholders, project settings and contexts and goals need to be considered. SPI projects are often operated in a complex and volatile environment and, thus, require a sound management that is resource-intensive requiring many stakeholders to contribute to the process assessment, analysis, design, realisation and deployment. Although there exist many valuable SPI approaches, none address the needs of both process engineers and project managers. This article presents an artefact-based software process improvement and management approach (ArSPI) that closes this gap. ArSPI was developed and tested across several SPI projects in large organisations in Germany and Eastern Europe. The approach further encompasses a template for initiating, performing and managing SPI projects by defining a set of five key artefacts and 24 support artefacts. The authors present ArSPI and discus results of its validation indicating ArSPI to be a helpful instrument to set up and steer SPI projects. Over the past decade, a dramatic increase of functionality, quantity, size, and complexity of software-intensive embedded systems in the automotive industry can be observed. In particular, the growing complexity drives current requirements engineering practices to the limits. In close cooperation between partners from industry and academia, the recently completed REMsES (Requirements Engineering and Management for software-intensive Embedded Systems) project has developed a guideline to support requirements engineering processes in the automotive industry. The guideline enables the requirements engineers to cope with the challenges that arise due to quantity, size and complexity of software-intensive systems. This article presents the major results of the project, namely, the fundamental principles of the approach, the guideline itself, the tool support, and the major findings obtained during the evaluation of the approach.