Schaffung einer Basis für die kontinuierliche Qualitätsanalyse

Die Qualität der Software ist ein wesentlicher Faktor für den wirtschaftlichen Erfolg von Softwaresystemen, die langlebig und erweiterbar sein sollen. Sie hat vor allem entscheidenden Einfluss auf die Effizienz der Wartung und Weiterentwicklung. Erfahrungsgemäß nimmt aber die Qualität der Software mit der Zeit ab. Die kontinuierlichen Änderungen und Erweiterungen des Quellcodes, sich ständig ändernde Anforderungen und die Anpassungen der Software an unterschiedliche technische Umgebungen können zum schleichenden Qualitätsverfall führen. Um diesem Verfall der Qualität entgegenzuwirken, ist es notwendig gewisse Regeln zu definieren und durch eine kontinuierliche Analyse die Einhaltung dieser Regeln zu kontrollieren. Dabei soll nicht nur der Entwicklungsprozess, sondern auch das Produkt selbst analysiert und verbessert werden. Auf Grund der Größe heutiger Softwaresysteme ist es empfehlenswert solch eine Qualitätsüberprüfung sowohl durch manuelle Inspektionen, als auch mittels dafür geeigneten Werkzeugen durchzuführen. Die Werkzeuge, die zur Operationalisierung der kontinuierlichen Softwarequalitätsanalyse dienen, werden Software Quality Dashboards genannt. Diese Werkzeuge sammeln und liefern Daten über den aktuellen Qualitätszustand eines Softwaresystems in Form von Tabellen, Trends- und Übersichtsgrafiken. Mit Hilfe dieser Daten können später Aussagen über die Qualität und die Weiterentwicklungsfähigkeit des Softwaresystems gemacht werden

Entwicklungsprozess für qualifizierbare Softwarewerkzeuge nach ISO 26262

Um die hohen Qualitätsanforderungen an Softwarewerkzeuge für die Entwicklung eingebetteter Systeme im Automobilumfeld zu gewährleisten, wurde in dieser Arbeit in Zusammenarbeit mit dem Unternehmen TWT ein Qualitätsprozess definiert, der die Nachweisbarkeit von Anforderungen sowie eine Qualifizierung nach dem Sicherheitsstandard ISO 26262 ermöglicht. Hierfür wurden zunächst die Vorgaben des Sicherheitsstandards zur Softwareentwicklung und zur Qualifizierung von Softwarewerkzeugen analysiert. Danach wurden die bestehenden Softwareentwicklungsprozesse bei der TWT untersucht. Aus beidem wurden anschließend Anforderungen an den Qualitätsprozess abgeleitet, so dass dieser sowohl die Anforderungen des Sicherheitsstandards erfüllt als auch sich in die bestehenden Entwicklungsprozesse bei TWT einfügt. Das Konzept des Qualitätsprozesses basiert auf dem im Sicherheitsstandard verwendeten V-Modell, erweitert dieses jedoch um den Einsatz eines kontinuierlichen, testorientierten Requirements Engineerings, einer kontinuierlichen Integration und um Quality Gates, die die Phasen des V-Modells voneinander trennen. Durch das Requirements Engineering und die Quality Gates werden sowohl die Softwareanforderungen validiert als auch die Anforderungen und Vorgaben des Sicherheitsstandards auf ihre Einhaltung überprüft. Durch den Einsatz einer kontinuierlichen Integration, fügt sich der Qualitätsprozess in die bestehenden Entwicklungsprozesse bei TWT ein. Abschließend wurde der ausgearbeitete Qualitätsprozess in einem Expertenreview evaluiert. Die Evaluation ergab, dass der Qualitätsprozess die Anforderungen erfüllt. Des Weiteren gab es Anregungen für eine Erweiterung des Qualitätsprozesses.In this work, a quality process was defined in close cooperation with the company TWT to ensure the high quality requirements of software tools used for developing embedded systems in the automobile environment. This process allows verifying these requirements as well as qualifying software tools based on the safety standard ISO 26262. For this purpose, the requirements of the safety standard for developing software and qualifying software tools were analyzed. Afterwards, the existing software development processes at TWT were examined. Based on both, requirements for the quality process were derived in order to comply with the requirements of the safety standard as well as to embed the process into the existing development processes at TWT. The concept of the quality process is based on the V-Model used in the safety standard. Additionally, the V-Model is extended with a continuous and test oriented requirements engineering, a continuous integration, and quality gates, which separate the phases of the V-Model. Requirements engineering and quality gates are used to validate software requirements as well as to ensure compliance with requirements of the safety standard. By using continuous integration, the quality process is embedded into the current development processes at TWT. Last, the quality process was evaluated in an expert review. The evaluation showed that the quality process meets all requirements. Furthermore, suggestions for extensions of the quality process were given

Ein Framework als Grundlage der Ausgestaltung von Quality-Gate-Referenzprozessen für die Software-Entwicklung

[no abstract

Attributbasierte Autorisierung im Grid Computing : vertrauenswürdige Architekturen und sichere Implementierung

[no abstract

Frühe informatische Bildung – Ziele und Gelingensbedingungen für den Elementar- und Primarbereich

Wie können Ziele und Gelingensbedingungen informatischer Bildung im Elementar- und Primarbereich aussehen? Mit Blick auf die pädagogisch-inhaltlichen Zieldimensionen informatischer Bildung geben Fachexpertinnen und -experten Empfehlungen für die Entwicklung der inhaltlichen Angebote der Stiftung „Haus der kleinen Forscher“ im Bereich Informatik. Zudem wird die Umsetzung dieser Empfehlungen in den Stiftungsangeboten veranschaulicht

Explainable software systems: from requirements analysis to system evaluation

The growing complexity of software systems and the influence of software-supported decisions in our society sparked the need for software that is transparent, accountable, and trustworthy. Explainability has been identified as a means to achieve these qualities. It is recognized as an emerging non-functional requirement (NFR) that has a significant impact on system quality. Accordingly, software engineers need means to assist them in incorporating this NFR into systems. This requires an early analysis of the benefits and possible design issues that arise from interrelationships between different quality aspects. However, explainability is currently under-researched in the domain of requirements engineering, and there is a lack of artifacts that support the requirements engineering process and system design. In this work, we remedy this deficit by proposing four artifacts: a definition of explainability, a conceptual model, a knowledge catalogue, and a reference model for explainable systems. These artifacts should support software and requirements engineers in understanding the definition of explainability and how it interacts with other quality aspects. Besides that, they may be considered a starting point to provide practical value in the refinement of explainability from high-level requirements to concrete design choices, as well as on the identification of methods and metrics for the evaluation of the implemented requirements

Explainable software systems: from requirements analysis to system evaluation

The growing complexity of software systems and the influence of software-supported decisions in our society sparked the need for software that is transparent, accountable, and trustworthy. Explainability has been identified as a means to achieve these qualities. It is recognized as an emerging non-functional requirement (NFR) that has a significant impact on system quality. Accordingly, software engineers need means to assist them in incorporating this NFR into systems. This requires an early analysis of the benefits and possible design issues that arise from interrelationships between different quality aspects. However, explainability is currently under-researched in the domain of requirements engineering, and there is a lack of artifacts that support the requirements engineering process and system design. In this work, we remedy this deficit by proposing four artifacts: a definition of explainability, a conceptual model, a knowledge catalogue, and a reference model for explainable systems. These artifacts should support software and requirements engineers in understanding the definition of explainability and how it interacts with other quality aspects. Besides that, they may be considered a starting point to provide practical value in the refinement of explainability from high-level requirements to concrete design choices, as well as on the identification of methods and metrics for the evaluation of the implemented requirements