Michael Anders

Context and Motivation: In software development, user feedback plays a pivotal role in advancing applications to meet evolving user expectations. Managing diverse feedback sources poses a challenge in filtering and processing this abundance of information. Current approaches aim to for example automate the identification of relevant user feedback but often overlook the aspect of the relationship between feedback and existing software requirements. This is crucial to understanding the impact of feedback on requirements and implementing changes effectively. This approach enables contextual analysis and contributes to the further development and improvement of software applications. Given the inherent challenge of directly establishing relationships of feedback to requirements, where developers and users may use different terminology due to disparate knowledge levels, the TORE framework could prove to be a valuable tool. By pre-classifying feedback and reducing the number of potential requirements, TORE can help bridge the semantic gap between developers and users.

Contributions: This Master’s thesis addresses this gap by proposing a solution that automatically establishes a relationship between user feedback and existing requirements. The primary objective is to develop a algorithm leveraging pretrained large language models, specifically integrating a BERT classifier and refining the classification process using the TORE framework. Feedback and requirements should be managed in a dashboard in order to establish the relationships. The relationships are then evaluated. Results: The outcome of this work includes the implementation of the dashboard into the Feed.UVL project, where feedback and existing requirements are imported. Their semantic similarity is classified and subsequently calculated with the assistance of a BERT model. Furthermore, the classification process is refined by integrating the TORE framework to assess whether it enhances the quality of automation. For the similarity calculation, a threshold of 85% match was set, achieving a recall of 47%, a precision of 40%, and an f1-score of 38%. Through pre-classification with TORE, at the same threshold, a recall of 47%, a precision of 39%, and an f1-score of 37% were also achieved.

Michael Anders

Context & Motivation: User feedback from app store reviews and forum comments can be used to evaluate software requirements and implementation. A potential method for correlating feedback with requirements is the Task-Oriented Requirements Engineering- Framework(TORE). However, the amount of work required by developers to extract the information in user feedback from public sources makes this prohibitive. Previous efforts to automate information identification by classifying user feedback using a taxonomy derived from TORE did not perform adequately, which is attributed to the available training dataset size and a large number of categories in the taxonomy. A potential offset could be to leverage the structure of the taxonomy, which groups categories into groups called levels. A classifier system capable of assigning levels in the first categories in the subsequent step while using the level labels from the first stage could improve performance. Contributions: This thesis makes four major contributions. Firstly, a user feedback dataset based on Komoot Android app reviews is annotated. Secondly, a literature search is conducted, compiling research regarding multi-stage classifier systems used to classify natural language user feedback in the context of software-related taxonomies. Thirdly, an experiment and model management tool is integrated into the Feed.UVL infrastructure to support many experiments and large language models. Lastly, a set of TORE classifiers are implemented and evaluated, including a single-stage BERT classifier and combinations of SNER, Bi-LSTM, and BERT classifiers for two-stage classification.

Results: MLflow, an existing experiment and model management tool, is integrated into Feed.UVL. The implemented BERT-based classifiers outperformed the existing SNER and Bi-LSTM classifiers both in the single-stage and first-stage level classification setting. The single-stage classifier achieved a precision of 0.659, recall of 0.636, and F1 of 0.647, while the first-stage classifier achieved a precision of 0.776, recall of 0.784, and F1 of 0.78. The two-stage classification did not realize any performance gains in comparison to the single-stage BERT classifier.

Leon Radeck

Leon Radeck

Leon Radeck

Sperrvermerk

Context and Motivation: Users give natural language feedback for software in online forums, which can be used by developers to create requirements. In order to categorize user feedback into categories which are relevant for requirements engineering, feedback can be classified into different categories. One such approach is the classification into dif- ferent software aspects. The TORE framework provides a basis for such a classification. The classification can be done manually by creating codes containing TORE categories for tokens, which can be done by one or multiple raters on the same documents. In order to limit mistakes stemming from the raters, the classifications can be compared by creating inter-rater agreements. This comparison can be supported by tools, which can simplify the process of resolving disagreements. However, manual classification is cost- and time-intensive. Therefore an algorithm is needed for the automatic classification of natural language user feedback into TORE-categories. Contributions: This thesis contains three major contributions. Firstly, a tool support is provided for the comparison of an arbitrary number of annotations of the same dataset. Disagreements can be resolved by accepting or declining codes assigned to words. Ad- ditionally, agreement overviews as well as statistics are provided. Secondly, a literature review is conducted on automatic deep-learning-based classification of natural language user feedback from online forums. The review shows that many approaches use binary classification as a basis, although some use multi-class classification. Most of them use some kind of pre-processing, Word2Vec for word embeddings, and a neural network for the classification. Lastly, a classifier is implemented, based on a Bi-LSTM model for the automatic classification of natural language texts into TORE-categories. The classifier is trained on a manual annotation of forum data, and subsequently evaluated. Results: A tool for the comparison of annotations is developed and implemented in Feed.UVL, and the quality is assured through extensive system tests and an informal usability test. The tool reuses existing views and functionalities, and is user-friendly in design, due to the use of multiple tool-tips and standardized icons. The underlying microservice architecture simplifies possible future extension of the algorithm. The automatic classification tool, based on a deep learning algorithm, is also implemented into Feed.UVL, and reuses the existing views and functionalities for the classification results. The accuracy achieved over all classes is about 52.74%, with a recall of 53.47%, precision of 54.59% and F1-score of 53.78%, which is mainly due to the small amount of training data, as well as a poorly chosen test dataset.

[Context & Motivation] Users of software express feedback in online forums. Forums such as the Reddit forum are well suited as sources for large datasets of user feedback. Among other things, researchers in requirements engineering use this data to analyze what software aspects users refer to when giving feedback on software. For this analysis, the annotation of datasets is a suitable technique to extract information. However, the manual generation and annotation of such datasets is immensely time-consuming. Researchers greatly benefit from the automation of dataset generation and analysis. [Contributions] A method for the automation of the generation and classification of software aspects in forum datasets is provided in this thesis. This is done in the context of the Feed.UVL web application that is used for research on user feedback. The contribution of this work to Feed.UVL is the automation of the dataset generation from the Reddit online forums and the automation of the processing of software aspects in natural-language datasets. The automatic dataset generation is implemented as a forum crawler for the Reddit online forum. To make the generated datasets as relevant as possible, several options for filtering and pre-processing are provided. To get an overview of the contemporary research in this field, a literature research has been conducted as part of this work. The automatic processing of datasets is based on a machine learning classifier that augments natural-language datasets with semantic information using named-entity-recognition. As part of this work, the classifier has been trained and evaluated. For each added service, steps for quality assurance were performed and documented. [Conclusions] The scope of this work was twofold: First, tool support for the auto- matic generation of natural-language datasets in short time periods was created in the form of a Reddit forum crawler. Second, a classifier for the automatic software aspect classification of natural-language data has been implemented and evaluated. With this classifier, it is possible to analyze large datasets with significantly less time and effort. The classifier uses Stanford NER, which is a state-of-the-art machine learning algo- rithm for named-entity-recognition. The average performance of the classifier could be improved with an F1-score of 0.636 which could be improved with more training data. This proves the general suitability of the selected algorithm for the task. Both services were tested during development and in the final stage of the project.

[Kontext und Motivation] Eine weit verbreitete Methode zur Dokumentation von Anforderungen in der Softwareentwicklung sind User Stories. Eine Erwei- terung dieser Form ist durch Akzeptanzkriterien gegeben. Sie erweitern und verfeinern User Stories um konkrete Bedingungen, die nach der Umsetzung der User Story erfüllt sein müssen. Um den zusätzlichen Aufwand der Formu- lierung von Akzeptanzkriterien zu verringern, ist es Ziel dieser Arbeit, einen Algorithmus zur automatisierten Generierung von Akzeptanzkriterien zu konzi- pieren, implementieren und evaluieren. [Beiträge] Als erster Schritt in die Richtung zu automatisiert generierten Ak- zeptanzkriterien wird ein Werkzeug entwickelt, das mithilfe eines regelbasier- ten Ansatzes und unter Anwendung verschiedener NLP-Technologien zu User Stories ein Akzeptanzkriterium aus Vorbedingungen, Aktionen und erwarteten Ergebnissen in Gherkin-Notation erstellt. Dabei werden Informationen zur Rol- le sowie zur aktiven Benutzeroberfläche als Vorbedingung sowie kausale Zu- sammenhänge als Aktion mit zugehörigem erwarteten Ergebnis formuliert. Das Werkzeug ist Teil von „Feed.UVL“, einemTool zur automatisierten Sprachverar- beitung. Anhand eines Datensatzes an User Stories der Firma andrena objects ag wird die Qualität der Implementierung evaluiert und mit einer zuvor manu- ell erstellten Ground Truth verglichen. Eine Befragung von Mitarbeiter:innen der andrena objects ag ermöglicht die Beurteilung eines zukünftigen Einsatzes des Werkzeugs im Produktivbetrieb und zeigt zukünftige Erweiterungen und Verbesserungen auf. [Schlussfolgerungen] Das entwickelte Werkzeug erlaubt es Entwickler:in- nen, zu einer User Story ein Gherkin-Akzeptanzkriterium zu erzeugen, und nimmt ihnen die Arbeit ab, dieses selbst zu formulieren. Nutzer:innen desWerk- zeugs werden außerdem auf eine fehlerhaft eingesetzte Syntax in User Stories hingewiesen, die zu Problemen bei der Akzeptanzkriteriums-Generierung füh- ren kann, und erhalten Hinweise zur Verbesserung. Die jeweiligen Teile der generierten Akzeptanzkriterien erzielen im Vergleich zur manuell definierten Ground Truth Werte für Precision und Recall zwischen 87,6 und 99,9 Prozent. In der Befragung von andrena-Mitarbeiter:innen konnte festgestellt werden, dass ein Einsatz des Werkzeugs in dortigen Projekten grundsätzlich möglich scheint, jedoch teilweise Anpassungen an der Art undWeise der Anforderungs- dokumentation erfordert. Weitere Erkenntnisse aus der Befragung zeigen Mög- lichkeiten zur zukünftigen Verbesserung und Erweiterung von Werkzeug sowie Algorithmus auf.

The demographic change is in full progress. The society is getting increasingly older which poses many threats. One of those threats is social isolation. Especially older adults who live alone are facing this issue. Social isolation in most cases leads to a poorer quality of life. Further consequences might be the development of psychical and physical problems, cognitive decline and even increasing mortality. Hence, this development must be counteracted. A solution to this problem might be given through the usage of technology. Technology o ers to inform about various topics, connect people who life far apart and help organising daily lives. Subsequently, technology can be a substantial part of improving the quality of life for older adults. To prove if this is the case, the Heidelberg University conducts the SMART-AGE study which investigates how technology can improve the quality of life for older adults. As part of this study the Personal Reminder Information and Social Management (PRISM) application is to be developed. This application focuses on improving social participation, information providing, self-organisation and entertainment for older adults. As a rst goal of this thesis a systematic literature search is conducted to answer the research question of how to motivate people to give feedback. This literature search revealed several factors which have a motivating e ect on the user. Subsequently, requirements for the PRISM application are elicited by conducting interviews with four members of the SMART-AGE project. Based on the interview answers, concrete requirements are extracted and presented. For the requirements extraction the task and object-oriented requirements engineering (TORE) framework is applied. The gained results are used in order to design and implement the PRISM application. Moreover, the quality of the application is assured with the implementation of several tests. The implementation resulted in three frontend and two backend applications. Following on, the implemented applications are evaluated. For this evaluation ve participants worked through de ned scenarios and answered a questionnaire which was developed on the basis of the Technology Acceptance Model (TAM). The overall positive results suggest that the requirements are satisfactorily covered. Besides that, interesting enhancement and improvement ideas were posed, which are in turn to be evaluated and eventually implemented in future research. These results lead to the assumption that the PRISM application is successfully implemented.

The demographic change is confronting society with growing challenges. Elderly people are affected by this development in particular, due to the consistent increase in life expectancy in recent decades. More and more of them require support in their daily lives. Many also experience loneliness more frequently—especially during the COVID-19 pandemic. This specifically affects their quality of life in many regards. However, given the technological advances of our time, this group of people could be helped. The SMART-AGE project—a collaboration by the Heidelberg University and other institutions— targets these tensions by linking multiple software and hardware solutions together to improve the life-quality and overall well-being of older adults. As part of the project, this thesis presents a solution called SmartImpuls, a web-platform which is available to older adults via tablets. It aims to provide suitable health-recommendations based on a person’s physical- and psychological condition to prevent critical health-situations and improve their overall well-being. To achieve this goal, this thesis features a systematic literature review to investigate the effects of gamification in software applications with regards to increased usage. Furthermore, a requirement analysis together with members of the project was performed to define the solution’s scope in form of TORE specifications. By incorporating the insights of the literature review and the collected requirements, a JavaScript application on Kubernetes was developed. To increase the usage of the application, it features several gamification elements like a progress-bar, badges and feedback. Finally, the implemented solution was evaluated with members of the project. During the evaluation, they independently worked on predefined usage scenarios, which cover the usual tasks that should be carried out inside the application. Afterwards, the participants answered a questionnaire that was created based on the Technology Acceptance Model. It resulted in 65% positive answers, 20% neutral and 15% negative ones. The ratings were commented by the participants with numerous extensions to further optimize the application, which can be addressed in future development efforts.

[Kontext und Motivation] Entwickler müssen die Anforderungen von Software-Nutzern, die
ihr Feedback meist in Form von Aussagen in natürlicher Sprache geben, kennenlernen. Die Verarbeitung
dieser Aussagen durch manuelle Kodierung ist jedoch eine aufwändige Aufgabe und
für große Datenmengen ungeeignet. Durch die Extraktion von Konzepten aus diesen Aussagen
können Entwickler Einblicke in die Sichtweise der Software-Nutzer gewinnen. Ein Software-
Werkzeug, das eine automatische Verarbeitung ermöglicht, kann bei diesem Prozess helfen.
[Beiträge] Diese Arbeit untersucht den Stand der Technik von Methoden zur Themenmodellierung
für Benutzerforen und wendet geeignete Methoden im Kontext der Konzepterkennung
auf einen manuell erhobenen und annotierten Interviewdatensatz an. Es wird ein Software-
Werkzeug zur automatischen Sprachverarbeitung mit dem Namen "Feed.UVL" erstellt und die
ausgewählten Methoden in dieses Werkzeug integriert. Das erstellte Software-Werkzeug bietet
eine Datensatzverwaltung, d. h. Datensätze können mit der Software gespeichert, überprüft
und gelöscht werden. Mit den implementierten Methoden können diese Datensätze auf
Konzepte hin analysiert werden. Mit der Ergebnisvisualisierung können die Analyseergebnisse
überprüft und die Leistung über den F1-Score auf einer Ground Truth bewertet werden.
Feed.UVL verwendet eine Microservice-Architektur, d. h. es kann leicht um neue Methoden
oder Funktionen erweitert werden. Die integrierten Methoden werden dann für die Aufgabe der
Konzepterkennung evaluiert. Eine Reihe von Qualitätssicherungsmaßnahmen, einschließlich
statischer Code-Analyse, Komponenten- und Systemtests, wurden ebenfalls mit dem erstellten
Werkzeug durchgeführt.
[Schlussfolgerung] Der Hauptteil der Arbeit war die Entwicklung eines neuartigenWerkzeugs
für die Verarbeitung natürlicher Sprache. DasWerkzeug hat ein klares und benutzerfreundliches
Design und unterstützt Forscher bei ihrer Analyse. Es können automatische Analyseaufgaben
durchgeführt werden, und die Benutzeroberfläche bietet eine umfangreiche Ergebnisanzeige,
einschließlich der Metriken false positives, false-negatives, Precision, Recall und F1-Score. Das
aktuelle Design und die Microservice-Architektur stellen sicher, dass das Werkzeug leicht für
weitere Analysemethoden und zukünftige Forschungsziele erweitert werden kann. Derzeit sind
zwei moderne Methoden zur Themenmodellierung (LDA und SeaNMF) integriert, die für die
Verwendung in der Konzepterkennung angepasst wurden. Die Evaluierung hat gezeigt, dass
ihre Präzision zwar relativ hoch ist (0,84 für LDA und 0,83 für SeaNMF), ihr Recall im Vergleich
zu einer manuell annotierten Ground Truth für den Einsatz in der Konzepterkennung
jedoch eher gering ist, was Raum für Verbesserungen und zukünftige Arbeiten lässt.

[Kontext und Motivation] Während des Software-Entwicklungsprozesses treffen die Beteiligten zahlreiche Entscheidungen und eignen sich wichtiges Entscheidungswissen an, das neben den Entscheidungen unter anderem auch die Entscheidungsprobleme, Alternativen und Argumente umfasst. Diese Entscheidungen sind nicht unveränderlich. Neue Anforderungen oder das Betrachten neuer Alternativen für bereits getroffene Entscheidungen z.B. durch neue Technologien führen zu Änderungsanfragen und zu sich kontinuierlich ändernden Softwareartefakten wie Code, Architekturmodellen, dokumentiertem Entscheidungswissen und anderer Softwaredokumentation. Je größer ein Softwaresystem wird, desto schwieriger ist es Änderungsauswirkungen vollständig zu erfassen. Eine Änderung kann zu einer inkonsistenten und unvollständigen Dokumentation führen, wenn nicht alle von der Änderung betroffenen Softwareartefakte überarbeitet bzw. neu dokumentiert werden. Dieser Prozess setzt sich mit jeder Änderungsanfrage fort. Da für die korrekte Abschätzung von Änderungsauswirkungen eine hohe Dokumentationsqualität nötig ist, führen inkonsistent durchgeführte bzw. unvollständig dokumentierte Änderungen zu immer schlechter abschätzbaren Änderungsauswirkungen. Es ist daher wichtig, das dokumentierte Wissen konsistent und vollständig zu halten, um die Ermittlung von Änderungsauswirkungen besser zu unterstützen.
[Beiträge] Diese Arbeit beschäftigt sich mit Methoden, die die am Entwicklungsprozess beteiligte Personen unterstützen, Änderungsauswirkungen zu ermitteln. Eine systematische Literaturrecherche beantwortet die Frage, wie sich die Analyse von Änderungsauswirkungen, im Hinblick auf Graphen von Softwareartefakten, algorithmisch unterstützen lässt. Es wird weiterhin betrachtet, welcher Visualisierungsmöglichkeiten für Änderungsauswirkungen auf Graphen angewendet werden können. Es werden systematisch Änderungsszenarien abgeleitet. Die Arbeit erweitert die Werkzeugunterstützung ConDec, die dem Verwalten und Visualisieren von Entscheidungswissen im Kontext zu anderen Softwareartefakten dient und einen Wissensgraphen aus Softwareartefakten aufbaut. Softwareartefakte werden in dieser Arbeit auch als Wissenselemente bezeichnet. Aus den Erkenntnissen der systematische Literaturrecherche (SLR) werden Anforderungen an neue Funktionalität für ConDec abgeleitet und umgesetzt, um von einem Softwareartefakt ausgehend Änderungsauswirkungen auf andere Softwareartefakte zu ermitteln und anzuzeigen und so die Änderungsszenarien zu unterstützen. Die Erweiterung wurde qualitätsgesichert und mithilfe einer Umfrage mit NutzerInnen sowie der Anwendung auf die Änderungsszenarien evaluiert.
[Schlussfolgerung] Die in dieser Arbeit umgesetzte Erweiterung von ConDec unterstützt den/die AnwenderIn darin die Konsistenz und Vollständigkeit der Softwareartefakte, durch das Ermitteln und Visualisieren von Änderungsauswirkungen, zu erhalten. Dies verbessert die Qualität der dokumentierten Wissenselemente und ermöglicht die Abschätzung von Änderungsauswirkungen bei zukünftigen Änderungsanfragen.

Bei der Softwareentwicklung treffen EntwicklerInnen kontinuierlich Entscheidungen, die sie dokumentieren und kommunizieren müssen, um sie anderen SoftwareentwicklerInnen zugänglich zu machen. Dadurch lässt sich die Software besser weiterentwickeln und instand halten. Mithilfe eines Entscheidungsdokumentationsmodells können Entscheidungsprobleme mit verschiedenen Lösungsoptionen und Argumenten dokumentiert werden. Ein Problem ist, dass EntwicklerInnen z.B. aufgrund kognitiver Verzerrungen wie dem Ankereffekt alternative Lösungsoptionen außer Acht lassen. Das hat zur Folge, dass sie 1) Entscheidungen nicht optimal treffen, weil sie die falsche Lösungsoption wählen oder/und 2) die Dokumentation unvollständig ist, weil nur die Lösung beschrieben wurde und keine Alternativen. Dadurch können Entscheidungen für andere EntwicklerInnen nicht nachvollziehbar sein. In dieser Arbeit wird daher ein Vorschlagsmechanismus für Lösungsoptionen zu Entscheidungsproblemen entwickelt, welcher EntwicklerInnen in der Entscheidungsfindung und Dokumentation unterstützen soll. Der Vorschlagsmechanismus bezieht seine Daten dabei aus verschiedenen Wissensquellen wie der DBPedia-Ontologie und anderen Softwareprojekten. Zunächst wird eine systematische Literaturrecherche durchgeführt, um herauszufinden, welche bekannten Mechanismen zur Unterstützung der Entscheidungsfindung existieren. Die Ergebnisse der Recherche fließen mit in die Anforderungsanalyse und den Entwurf des Vorschlagsmechanismus ein. Der Vorschlagsmechanismus wird in das bestehende ConDec-Jira-Plugin integriert und die dadurch entstandene Erweiterung des Plugins durch eine NutzerInnenumfrage evaluiert. Die Wissensquellen für Lösungsoptionen werden ebenfalls auf ihre Güte geprüft. Insbesondere werden Vorschläge aus der DBPedia-Ontologie hinsichtlich ihrer Qualität und Nützlichkeit evaluiert. Ebenso wird eine Methode zur Evaluation von Wissensquellen in das Plugin integriert. Somit können anhand bestehender Entscheidungsprobleme verschiedene Wissensquellen verglichen werden. Die Ergebnisse der NutzerInnenakzeptanz durch eine NutzerInnenumfrage ergaben, dass es nützlich ist, Vorschläge aus verschiedenen Wissensquellen zu erhalten, da so unbekannte Lösungsoptionen gefunden oder bekannte Lösungsoptionen einfacher dokumentiert werden können. Der Vorschlagsmechanismus unterstützt v.a. bestimmte Entscheidungsprobleme, insbesondere Fragen nach Werkzeugen, Infrastruktur und Architekturentscheidungen. Um die Ergebnisse des Vorschlagsmechanismus weiter zu verbessern, könnten andere Wissensquellen evaluiert sowie noch mehr Kontextinformationen zu dem Entscheidungsproblem zur Berechnung eines Vorschlags mit einbezogen werden.

Sperrvermerk

The use of machine learning (ML) as a key technology in artificial intelligence (AI) is becoming more and more important in the increasing digitalization of business processes. However, the majority of the development effort of ML applications is not related to the programming of the ML model, but to the creation of the server structure, which is responsible for a highly available and error-free productive operation of the ML application. The creation of such a server structure by the developers is time-consuming and complicated, because extensive configurations have to be made. Besides the creation of the server structure, it is also useful not to put new ML application versions directly into production, but to observe the behavior of the ML application with respect to unknown data for quality assurance. For example, the error rate as well as the CPU and RAM consumption should be checked. The goal of this thesis is to collect requirements for a suitable server structure and an automation mechanism that generates this server structure, deploys the ML application and allows to observe the behavior of a new ML application version based on real-time user data. For this purpose, a systematic literature review is conducted to investigate how the behavior of ML applications can be analyzed under the influence of real-time user data before their productive operation. Subsequently, in the context of the requirements analysis, a target-performance analysis is carried out in the department of a management consulting company in the automotive sector. Together with the results of the literature research, a list of user stories for the automation tool is determined and prioritized. The automation tool is implemented in the form of a Python console application that enables the desired functionality by using IaC (Infrastructure as code) and the AWS (Amazon Web Services) SDK in the cloud. The automation tool is finally evaluated in the department. The ten participants independently carry out predefined usage scenarios and then evaluate the tool using a questionnaire developed on the basis of the TAM model. The results of the evaluation are predominantly positive and the constructive feedback of the participants includes numerous interesting comments on possible adaptions and extensions of the automation tool.

Routenplanung kann herausfordernd sein. Dies ist insbesondere der Fall, wenn an die Routenplanung besondere Anforderungen gestellt werden und zusätzliche, neue Informationen berücksichtigt werden sollen, z. B. Überflutungsgebiete. NutzerInnen wie Disponenten des DRK oder Tourenplaner, die Routen mit zusätzlichen, oft individuell vorliegenden Informationen finden wollen, haben bspw. hochaktuelle Informationen über Katastrophengebiete oder detailliertere Informationen über touristische Wege. Diese Informationen sind meist aktueller oder genauer als Informationen, die in einem Routenplanungsdienst vorhanden sind. Der Openrouteservice (ORS), ein auf OpenStreetMap-Daten basierender Routenplanungsdienst, bietet bereits viele Möglichkeiten die Routenplanung zu beeinflussen. Beispielsweise besteht die Möglichkeit eine Höchstgeschwindigkeit anzugeben. Derzeit existiert keine Möglichkeit das Routing flexibel mit individuellen Daten zu beeinflussen.

Diese Arbeit hat zum Ziel eine Erweiterung des ORS zu implementieren, die es NutzerInnen erlaubt das Routing auf die zuvor beschriebene Art und Weise anzupassen. Die systematische Literaturrecherche beschäftigt sich mit personalisierter Routenplanung und mit Schnittstellen um benutzerdefinierte Daten zu übergeben. Des Weiteren werden die Anforderungen an die ORS-Erweiterung definiert. Diese spezifizieren die funktionalen, modularen Teile der Erweiterung und die nicht-funktionalen Anforderungen. Benutzerdefinierte Daten können als neuer Parameter an die existierende API übergeben werden. Ein standardisiertes Eingabeformat wird von einem neu implementierten Parser genutzt, der NutzerInnen bei der Verwendung unterstützt. Die Implementation umfasst einen Polygon- Matcher, der alle Kanten im Routing-Graphen findet, die von einem der Erweiterung übergebenen Polygon überdeckt werden. Die Implementation wird mittels statischer Codeanalyse, Komponenten- und Systemtests getestet. Diese decken mindestens alle definierten Systemfunktionen sowie die Methoden der neu implementierten Klassen ab. Um sicherzustellen, dass die Implementation alle Leistungsanforderungen erfüllt und die Erweiterung durch NutzerInnen verwendet werden kann, wird eine Evaluation durchgeführt, auf Basis derer (iterativ) Optimierungen durchgeführt wurden.

Der implementierte Prototyp erlaubt NutzerInnen das Routing auf flexible Art und Weise zu beeinflussen. Sie können benutzerdefinierte Geometrien mit einem Gewichtsfaktor an die API übergeben, um eine auf ihre Bedürfnisse angepasstere Route zu erhalten. Mögliche Leistungsverbesserungen werden am Ende der Arbeit erörtert.

[Kontext und Motivation] Während der Softwareentwicklung bauen die Beteiligten kontinuierlich Wissen auf. Dieses Wissen ist in Wissenselementen wie Anforderungen, Codeartefakten und Entscheidungen dokumentiert. Um die Software weiterzuentwickeln, benötigen EntwicklerInnen das in den Wissenselementen enthaltene Wissen. Dafür müssen diese eine hohe Qualität besitzen und leicht zugänglich sein. Einzelne Elemente sind einfacher zugänglich, wenn sie untereinander verknüpft sind. In den dokumentierten Wissenselementen können sich Duplikate verbergen. Es ist notwendig Duplikate zu finden und aufzulösen, da es ansonsten zu Inkonsistenzen kommen kann, was einen Qualitätsmangel darstellt. Inkonsistenzen in Wissenselementen können bei EntwicklerInnen zu Missverständnissen und damit in der Software zu Fehlern führen.
[Beiträge] Die Arbeit entwickelt Methoden, um EntwicklerInnen bei der Verknüpfung von verwandten Wissenselementen und dem Auffinden von Duplikaten zu unterstützen. Eine Methode zum Auffinden von verwandtem Wissen wird bereits in einem Artikel von Miesbauer und Weinreich behandelt. Da keine Methoden zur Erkennung von Duplikaten in Wissenselementen bekannt sind, wird zu diesem Thema eine Literaturrecherche durchgeführt. In dieser werden passende Methoden gesucht und untereinander verglichen. Die am besten geeignete Methode wird dann umgesetzt. Die Umsetzung findet im Jira-ConDec-Plug-In statt. Dabei handelt es sich um ein Werkzeug zur Visualisierung und Verwaltung von Entscheidungswissen im Kontext zu anderen Wissenselementen. Eine Befragung zur Nutzerfahrung zeigt die Eignung der umgesetzten Software. Zur Evaluation der umgesetzten Methoden werden diese auf Wissenselemente im ConDec-Projekt angewandt und die Güte überprüft. Dabei wird ein Goldstandard aufgebaut und analysiert.
[Schlussfolgerung] Diese Arbeit unterstützt EntwicklerInnen und Rationale-ManagerInnen bei der konsistenten Dokumentation von Wissenselementen. Die Unterstützung ist als Plug-In in dem Issue Management System Jira umgesetzt, um sich gut in den Softwareentwicklungsprozess zu integrieren. Mit einer Visualisierung als Wissensgraph werden Zusammenhänge zwischen Elementen gut sichtbar.

n.a.

Sperrvermerk

[Context and Motivation] Developers need to document decisions and related decision knowledge during the software development process. This ensures that future decisions can be assessed in the right context and past decisions can be retraced and understood. The documentation of decision knowledge encompasses all aspects that comprise a decision, including the problem, alternatives, arguments for and against these alternatives, and the selected solution. Since the value of the documentation is not immediately apparent, it is important to provide tools that allow easy documentation and coherent visualization of the documented knowledge. It also demands maintenance of the documentation to ensure consistency and completeness.

[Contributions] This thesis provides a problem investigation, a treatment design, and an evaluation concerning the management and visualization of documented decision knowledge. The problem investigation was done in the form of a literature review on current approaches towards the grouping of decision knowledge. The results of the review show that decision grouping is often merely a small part of larger frameworks. These frameworks either use predefined labels for their groups or allow the users to freely select group names. The practical contributions in this thesis are the extension of the Jira ConDec plug-in, which provides features for the documentation and visualization of decision knowledge within Jira. In particular, a grouping possibility for decisions as well as respective views and filters were added to this plug-in. To keep the necessary time spent on the documentation process as low as possible, it was decided to use a mix of fixed groups, in the form of different decision levels and custom groups, which the user is free to assign. New views were implemented which allow users to see relationships between source code and Jira issues and a dashboard is built, which can be used to assess the completeness of decision knowledge within a Jira project. The implementation was preceded by a specification of requirements and a design phase. Extensive testing, including system and component tests, were part of the quality assurance phase. Lastly, an evaluation was done by creating and analysing a gold standard of decision knowledge documentation and a survey with developers who provided feedback on the plug-in extension.

[Conclusions] The main focus of the thesis was to improve the visualization of relationships between knowledge elements. The evaluation showed that especially those views, creating connections between Jira elements and code classes were highly anticipated by ConDec users, as support for this form of visualization did not exist. The newly implemented features were almost uniformly evaluated positively. Some concerns were expressed about a need for even more information to be displayed within the views. This was a result of the compromise between a wealth of information and a possible overload in individual views. Evaluation of the responsiveness and time behaviour of the newly implemented features also showed that loading times were passable but require more focus in future works to improve the user experience thoroughly.

[Kontext und Motivation] Während der Implementierung von Software werden zahlreiche Entscheidungen getroffen. Diese Entscheidungen gehen aus einem Entscheidungsproblem hervor und basieren auf einer Gegenüberstellung verschiedener Alternativen, die es zu bewerten gilt. In der Praxis werden Entscheidungen oft unzureichend dokumentiert. Dies führt zu inkonsistenten Entscheidungen im späteren Entwicklungs- und Änderungsverlauf, woraus wiederum Qualitätsprobleme resultieren. Es ist also wichtig, das dokumentierte Wissen konsistent zu halten, um widersprüchliche Entscheidungen und Informationen zu vermeiden.

[Beiträge] Diese Arbeit beschäftigt sich mit Methoden, die den/die Rationale ManagerIn unterstützen, diese Konsistenz aufrecht zu erhalten. Hierfür ist es sinnvoll, dass der/die Rationale ManagerIn bereits dokumentiertes Entscheidungswissen anschauen kann, um zu überprüfen, ob es konsistent und vollständig dokumentiert ist. Um mögliche Inkonsistenzen in der Dokumentation zu erkennen, sollte er/sie alle getroffenen Entscheidungen einsehen und verwalten können, wie diese zueinander in Beziehung stehen. Die Masterarbeit umfasst eine systematische Literaturrecherche, die die Forschungsfrage, wie Abhängigkeiten zwischen Entscheidungen modelliert werden, beantwortet. Das Jira ConDec Plug-In ist eine Werkzeugunterstützung zum Visualisieren und Verwalten von Entscheidungswissen. Diese Werkzeugunterstützung wird um eine Entscheidungsgraphen- und eine Entscheidungsmatrix-Ansicht erweitert, die Abhängigkeiten zwischen Entscheidungen visualisieren. Eine Befragung von EntwicklerInnen, die ebenfalls am ConDec-Projekt beteiligt sind sowie weiteren fachfremden Teilnehmern zeigt die Eignung der entwickelten Ansichten. Zur Evaluation werden außerdem Beziehungen zwischen den bereits existierenden Entscheidungen in ConDec gepflegt und dabei ein Goldstandard aufgebaut. Dieser Goldstandard wird analysiert und beschrieben.

[Schlussfolgerung] Die Arbeit unterstützt die Konsistenz der Entscheidungsdokumentation durch das Visualisieren und Verwalten von Beziehungen zwischen Entscheidungen. Der/die Rationale ManagerIn kann mit Hilfe der Entscheidungsgraphen- und Entscheidungsmatrix-Ansicht Entscheidungen und deren Beziehungen analysieren und dabei die Konsistenz zwischen Entscheidungen prüfen und verbessern. Dies verbessert die Qualität des dokumentierten Entscheidungswissens.

[Context and Motivation] Documentation of software artifacts plays an essential role in the development of software systems. Developers need to have access to the knowledge about the evolution of software artifacts they will work with. In particular, they must understand the reasons behind the decisions made in the past, i.e., they need decision knowledge. Therefore, it is important that the stakeholders of a software project document the decision knowledge. This knowledge is captured in different types of documents and less formally in locations like chat messages, ITS ticket comments and commit-messages. Most of their time, developers work with the source code, which might be the most important source of system and project knowledge. For developers, it will be natural to document decision knowledge in source code.

[Contributions] This master thesis presents a systematic literature review, the extension of the ConDec JIRA plug-in, the improvements of its development process, and a first evaluation. The systematic literature review attempts to answer the question of how decision knowledge quality can be measured and assured. It provides simple metrics, which are aggregated with some utility function. This allows to visualize the quality of documented decision knowledge. Based on these insights, the ConDec JIRA plug-in is extended with a dashboard, i.e. a statistic report view, to visualize the overall quality in the project and also with a detailed quality view for single feature tasks. To make decision knowledge in code explicit and of high quality, a quality gate for pull requests of feature branches is added. Feature branches should be integrated into the baseline branch only if they pass the quality check of documented decision knowledge. Code reviewers can check the overall quality of the decision knowledge documentation for a feature branch. Both code reviewers and the author are supported in identifying the cause of problems with the documented decision knowledge in a feature branch. To continuously improve the documentation in code, a defined process must be lived by the development team. No code change should ever be integrated into the baseline branch unless it passed all quality checks during pull requests. Feature tasks should be reasonably small to make the code reviews a welcome activity to the developers and not a burden. The suitability of the presented addition to the ConDec JIRA plug-in was evaluated with the developers of the ConDec project.

[Results] This increment of the ConDec JIRA plug-in contributes to the continuous improvement of documented decision knowledge in source code and commit messages. Developers can identify quality problems in the documentation of the decision knowledge and correct it. The ConDec statistic report view for the documented decision knowledge of the project's feature branches gives an overview of the momentary amount of decision problems in development and quality concerns in the documentation. The development team can use this information to improve both the software under development and their development process.

In recent years, clinical data scientists achieved major breakthroughs advancing machine learning models for the medical domain, which have great potential assisting medical experts. Machine learning models can be leveraged to assist medical experts in tasks such as analyzing and diagnosing patient data, for example, from computed tomography scans. However, it is a challenge to translate the latest advancements in academic research fields such as computer sciences and physics into clinical practice. For this purpose, clinical data scientists and medical experts need to closely collaborate. This thesis tackles challenges of accessibility and usability of state-of-the-art machine learning models as well as designing a scalable computing architecture. Hence, conceptual ideas of possible strategies, as well as a prototype of such a machine learning platform, are presented. A systematic literature review was conducted on the current approaches to create medical machine learning platforms, the management of machine learning models, and the version management of large data sets. Afterward, the functional and nonfunctional requirements of the new machine learning platform were elicited as part of the requirements analysis. Two streamlined workflows for clinical data scientists and medical experts were derived from the requirement analysis. The workflow for the clinical data scientists includes steps to define, train, and share machine learning methods, including pre- and postprocessing modules, and management of data sets. Medical experts are able to analyze patient data using pre-defined machine learning methods. Building on the result of these analyses, the architecture of the platform was derived. The architecture consists of a scalable infrastructure stack, a lightweight and easy-to-use web interface, as well as a backend component to provide the required functionalities. The final design decisions solve the issue of efficiently standardizing, parallelizing, and applying machine learning workflows within a scalable computing infrastructure. The proposed platform was evaluated with 22 participants, consisting of clinical data scientists (N=12) and medical experts (N=10). Both groups were asked to rate specific workflows of the platform, as well as the platform as a whole, and to provide additional ideas and feedback. 92% of the medical experts and 90% of the clinical data scientists rated their overall impression of the platform as very good. Furthermore, medical experts and clinical data scientists strongly agreed that the platform facilitates method development and collaborations with 92% and 90%, respectively. The conducted expert survey suggests that the here proposed platform could be used to develop, optimize, and apply machine learning methods in the medical domain and beyond, thereby easing the collaboration between medical experts and clinical data scientists.

[Kontext und Motivation] Zur Entwicklung eines Softwaresystems benötigen EntwicklerInnen Wissen über die Evolution der zugehörigen Softwareartefakte. EntwicklerInnen müssen beispielsweise vorangegangene Quellcodeänderungen verstehen, um eine neue Anforderung bzw. eine Änderung an einer bestehenden Anforderung zu implementieren. Dabei spielt Entscheidungswissen eine zentrale Rolle für die erfolgreiche Evolution eines Softwaresystems: EntwicklerInnen benötigen Wissen zu bereits getroffenen Entscheidungen, um eigene Entscheidungen zu treffen. Um neuen EntwicklerInnen in einem Softwareprojekt den Zugriff auf dieses Entscheidungswissen zu ermöglichen, ist es wichtig, dass Projektbeteiligte Entscheidungen dokumentieren. Dafür nutzen sie verschiedene Dokumentationsmöglichkeiten und halten Entscheidungswissen häufig informell in Commitnachrichten, Chatnachrichten oder Kommentaren fest.

[Beiträge] Diese Masterarbeit umfasst eine systematische Literaturrecherche, die Entwicklung des JIRA-Plug-Ins DecXtract sowie einen Datensatz als Goldstandard zur Evaluation. Die systematische Literaturrecherche beantwortet die Frage, welches Wissen EntwicklerInnen für das Verständnis von Quellcodeänderungen benötigen und welche Rolle Entscheidungswissen dafür spielt. Neben einer Liste mit konkreten Fragen, die EntwicklerInnen zu einer Quellcodeänderung stellen, zeigt die Literaturrecherche, dass EntwicklerInnen explizites Entscheidungswissen benötigen, dieses aber nicht dokumentiert oder auffindbar ist. Um Entscheidungswissen in Kommentaren explizit zu machen und seine Auffindbarkeit zu verbessern, wird das Entscheidungsdokumentationstool ConDec für JIRA um die Komponente DecXtract erweitert. DecXtract ermöglicht EntwicklerInnen, Text in Kommentaren von JIRA-Issues automatisch als Entscheidungswissen zu klassifizieren sowie eigene Kommentare manuell als explizites, klassifiziertes Entscheidungswissen zu dokumentieren. EntwicklerInnen können Entscheidungswissen in Kommentaren zu bestehenden Softwareartefakten wie Anforderungen, Entwicklungsaufgaben oder anderem Entscheidungswissen verlinken. So entsteht ein integriertes Wissensmodell mit explizit dokumentiertem Entscheidungswissen. Dieses integrierte Modell wird als Graph visualisiert und bietet NutzerInnen verschiedene Möglichkeiten zur Verwaltung. Eine Befragung von EntwicklerInnen, die ebenfalls am ConDec-Projekt beteiligt sind, zeigt die Eignung von DecXtract zur Dokumentation von Entscheidungswissen. Zur Evaluation wird ein JIRA-Projekt mit 90 JIRA-Issues des Apache LUCENE Projektes erzeugt. Mit Hilfe von DecXtract wird informelles Entscheidungswissen aus den JIRA-Issue-Kommentaren explizit angelegt und miteinander verlinkt. Anhand der identifizierten Fragen von EntwicklerInnen an eine Quellcodeänderung wird das von DecXtract bereitgestellte Wissen genutzt um das Verständnis von Quellcodeänderungen zu evaluieren.

[Schlussfolgerung] DecXtract verbessert die Entscheidungsdokumentation durch die Klassifikation von Entscheidungselementen in JIRA-Issue-Kommentaren. Durch das präsentierte Entscheidungswissen können EntwicklerInnen immer den aktuellen Stand einer Diskussion und des dazugehörigen Entscheidungsproblems beobachten. Wenn eine Quellcodeänderung mit einem JIRA-Issue verlinkt ist, können EntwicklerInnen das Entscheidungswissen zu einer Quellcodeänderung betrachtet. Dieses Wissen unterstützt EntwicklerInnen beim Verständnis der Quellcodeänderung.

Software-Features spielen eine essenzielle Rolle in vielen Aspekten der Software- Entwicklung. Die während des Release-Planning ausgewählten Features legen den Funktionsumfang der nächsten Version einer Software fest. Im Software- Product-Line-Engineering werden komplette Software-Produktfamilien um zentrale Features herum aufgebaut. Die Analyse der Verwendung von Features erlaubt wertvolle Einsichten beim Erkennen von Mustern innerhalb des Nutzerverhaltens.
Trotz ihrer Wichtigkeit werden Software-Features häufig nicht systematisch verwaltet. In vielen Fällen sind explizite Informationen über Features daher nicht leicht verfügbar. Oft sind diese nur implizit in den verschiedenen Artefakten der Software- Entwicklung enthalten und über diese verteilt. In der Literatur wurde angemerkt, dass die Vergabe von Feature-Labels für Artefakte helfen kann, die Verwaltung von Features zu erleichtern und der Fragmentierung von Feature-Wissen entgegen zu wirken. User Stories sind kurze, in natürlicher Sprache verfasste Artefakte, die häufig verwendet werden, um Anforderungen an eine Software festzuhalten. User Stories werden oft in Issue-Tracking-Systemen verwaltet.
In dieser Arbeit wird ein (semi-)automatisches Modell für die Vergabe von Feature- Labels für User Stories vorgestellt. Das Modell erreicht dies durch 1) die Extraktion und Bündelung feature-relevanter Informationen aus User Stories und 2) dem Vorschlagen von passenden Feature-Labels anhand bereits vergebener Labels. Feature-relevante Informationen werden durch das Anwenden von Part-Of-Speech- Mustern auf den Syntaxbäumen von User Stories extrahiert. Das Vorschlagen von Feature-Labels wird mithilfe eines künstlichen neuronalen Netzes erreicht. Die Evaluation anhand zweier Datensätze von User Stories aus studentischen Projekten zeigt, dass das vorgestellte Modell im Stande ist, aussagekräftige feature-relevante Informationen zu extrahieren und treffende Feature-Labels vorzuschlagen.

Das Ziel dieser Arbeit ist es, eine Software zu entwickeln, die das Navigieren und Auffinden von Pfaden in einer Ontologie ermöglicht. Die Klassen und Relationen der gefundenen Pfade müssen mit Realdaten verknüpft werden. Dadurch beinhalten die gefundenen Pfade auch Informationen zu tatsächlichen Daten. Das Ziel der Software ist es, mit dem Auffinden von Pfaden mögliche Fragestellungen zu beantworten. Diese Software soll einen CIO (ein Verantwortlicher des Informationsmanagements) beim Entscheiden und Begründen von Projekten unterstützen.

Dazu wird eine Strukturierte Anforderungserhebung nach der Methode des Aufgabenorientierten Requirements Engineering (TORE) durchgeführt. Auf den definierten Anforderungen wird mittels einer Snowballing Literaturrecherche nach Ansätzen und Lösungsideen für das Navigieren in Ontologien und für Kriterien zur Pfadbestimmung gesucht. Darauf aufbauend erfolgt die Konzeption eines Lösungsentwurfes für die Implementierung des Prototypen CIONw. Der Prototyp wurde als eine App für die Anwendung Cytoscape entwickelt. Dabei wird die Navigation in der Ontologie durch einen Ontologiebrowser in Cytoscape umgesetzt. Die Umsetzung der Pfadfindung erfolgt durch die Anwendung vom Dijkstra und Yen Algorithmus. Die gefundenen Pfade können durch die Anbindung von Instanzdaten mit Realdaten verknüpft werden. Am Ende wird der Entwickelte Prototyp durch einen System- und Akzeptanztest validiert.

Das DFG geförderte Projekt Semantisches Netz des Informationsmanagements im Krankenhaus (SNIK) erstellt unter anderem eine Ontologie der Informationsmanagement-Domäne in Krankenhäusern. Eines der Ergebnisse von SNIK ist der CIO-Navigator. Dieser erlaubt, insbesondere dem Chief Information Officer als LeiterIn des Informationsmanagements, die bedarfsgerechte Darstellung von Informationen beispielsweise zum Change- und Projektmanagement. Auf deren Grundlage werden dort Entscheidungen, beispielsweise zur Projektpriorisierung, getroffen. Der aktuelle Stand der Forschung zeigt, dass die Umsetzung des CIO-Navigators als webbasiertes System als gute Entscheidung zu bewerten ist. Um eine Anforderungs- und Architekturanalyse des CIO-Navigators durchzuführen, wird zunächst ein geeignetes Architekturbewertungsverfahren ausgewählt. Dazu werden die Verfahren architecture tradeoff analysis method (ATAM) und software architecture analysis method (SAAM) gegenübergestellt und die Auswahl von SAAM begründet. In SAAM wird zur Vorbereitung eine Dokumentation der bestehenden Softwarearchitektur, basierend auf dem Quellcode und Interviews mit den Entwicklern, erstellt. Bei der Analyse der vorliegenden Softwarearchitektur werden hier Vereinfachungen vorgeschlagen sowie Auffälligkeiten aufgedeckt. Dabei zeigt sich, dass die Werkzeuge CodeMap, Codemetrik sowie CodeCity wertvolle Einblicke in die Struktur der Software geben. Im Anschluss werden die bestehenden Anforderungen zusammengefasst und im Bereich der nichtfunktionalen Anforderungen weiter verfeinert. Daraufhin wird die Softwarearchitektur in Bezug auf die Unterstützung der Anforderungen evaluiert. Dabei zeigt sich, dass die zentrale Komponente für den Datenzugriff zu viele Funktionalitäten beherbergt. Auf Grundlage der Ergebnisse kann die Struktur des Quellcodes des CIO-Navigators in Zukunft weiter verbessert werden. Die vorgeschlagenen Verbesserungen werden nach Abschluss des SAAM-Verfahrens im Detail diskutiert.Dabei wird beim CIO-Navigator der Einsatz des Frameworks ASP.NET MVC empfohlen. Ein Anliegen dieser Arbeit ist außerdem, eine fundierte Grundlage für Softwareprojekte der gleichen oder ähnlicher Ausrichtung bereitzustellen.

Traceability can provide many benefits, including improved documentation, more
reusable system components, and support for more precise and effective analysis of
changes occurring in the systems in which it is implemented. Despite these benefits,
traceability concepts have only had limited integration in software development and
issue tracking systems (ITSs) and bug reports in particular. This thesis aims to change
that and explores traceability within ITSs by utilizing the Bugzilla and Jira implementations.
It provides a literature review of link implementations in ITSs, develops the first known
coding scheme of traceability in ITSs, derives a traceability information model encompassing
all of the important links and relationships between artifacts in ITSs, and ultimately
uses qualitative content analysis and basic statistical methods to help analyze
and assess traceability in ITSs. These elements themselves can help improve traceability
by contributing the foundation for future research in a relatively new area of study;
however, this thesis also proposes a specific set of improvements.
Despite the presence of a large number of artifacts and links, the results of this thesis
show that consistent traceability is lacking in two major implementations of ITSs,
Bugzilla and Jira, and a number of important factors hindering traceability are identified,
including the prevalence of implicit links between artifacts. In conclusion this
thesis proposes a number of improvements, including a greater focus on artifacts in
the header of bug reports, better integration of artifacts such as patches, the use of
high-traceability elements such as flags, and the overall minimization of implicit links
in ITSs. Through implementing these suggestions, it is believed that both traceability
and overall usability of Bugzilla and Jira will be improved, and the suggestions can be
further generalized to ITSs as a whole.

Die Aufwandsschätzung ist zentraler Bestandteil einer Angebotserstellung in Softwareentwicklungsunternehmen. Um Aufwände zu schätzen, können verschiedene Methoden angewendet werden - bspw. Function Point Analyse, CoCoMo oder eine Schätzung anhand von Software-Features. Da für die Aufwandsschätzung basierend auf Software-Features das gesamte Anforderungsdokument des Kunden manuell auf Feature-relevante Informationen untersucht werden muss, ist der Prozess zeit- und kostenintensiv. Im Rahmen dieser Arbeit wird ein Ansatz für die teilautomatisierte Identifikation von Software-Features entwickelt. Für die Identifikation von Feature-Kandidaten werden syntaktische Muster bestimmt. Mit Hilfe von Natural Language Processing Methoden wird das Anforderungsdokument vorverarbeitet und so für die Anwendung der syntaktischen Muster vorbereitet. Im Anschluss werden die Feature-Kandidaten mittels lexikalischer und semantischer Ähnlichkeitsmessung validiert, um die tatsächlichen Feature zu identifizieren. Die Evaluation einer prototypischen Implementierung dieses Ansatzes zeigt, dass der Einsatz syntaktischer Muster und der lexikalischen bzw. semantischen Ähnlichkeitsmessung die Identifikation von Features ermöglichen.

Bei der Softwareentwicklung wird die Struktur und Umsetzung eines Systems ebenso
wie der Verlauf des zugehörigen Entwicklungsprojektes maßgeblich von einer Vielzahl
an Entscheidungen bestimmt. Gleichzeitig ist jedes Softwareentwicklungsprojekt Risiken
ausgesetzt, die es zu kontrollieren gilt. Durch mangelnden Umgang mit den Risiken
kann ein Großteil aller Projekte nicht erfolgreich abgeschlossen werden. Innerhalb eines
Projektes können die Entscheidungen und Risiken auf unterschiedliche Weise miteinander
verknüpft sein. So kann eine Alternative zur Lösung eines Problems beispielsweise
mit neuen Risiken verbunden sein. Obwohl die möglichen Auswirkungen von Risiken
bekannt sind, wird das notwendige Risikomanagement in der Praxis gar nicht oder nur
mangelhaft durchgeführt. Ein wichtiger Grund dafür ist, dass das Risikomanagement
nicht hinreichend in das Wissensmanagement der Projektbeteiligten integriert ist und
viel zusätzlichen Arbeitsaufwand erzeugt.

Im Rahmen dieser Arbeit wird ein Modell vorgestellt mit dem Risiken als Teil der Dokumentation
von Entscheidungswissen integriert werden können. Das Modell ermöglicht
es dabei, dass Vor- und Nachteile verschiedener Alternativen und einzelner Entscheidungen
für unterschiedliche Projektbereiche sowie für das Gesamtprojekt sichtbar und
abschätzbar werden. Weiterhin wird das entwickelte Modell prototypisch auf Basis eines
quelloffenen Werkzeuges zur rechnergestützten Softwareentwicklung implementiert.
Insbesondere wird dabei gezeigt, wie vorhandenes Wissen über typische Risiken in Verbindung
mit Entscheidungswissen genutzt werden kann, um sowohl bei der Identifikation
als auch bei der Analyse von Risiken eine systemgestützte Hilfe zu leisten.

Architectural Design Decisions haben entscheidenden Einfluss auf den Erfolg von Softwareprojekten. Es existieren bereits viele Ansätze zur Dokumentation von Architecural Design Decisions im Rahmen eines isolierten Softwareprojekts. Allerdings behandeln nur wenige Ansätze die Dokumentation zusammenhangender projektübergreifende Entscheidungen. Das Ziel dieser Arbeit ist die Identifikation von Entscheidungsmustern, welche in verschiedenen Softwareprojekten innerhalb der gleichen Softwaredomäne auftreten.

Teil dieser Arbeit ist es ein Wissensmodell für Architectural Design Decisions zu entwickeln.
Um festzustellen, wie Architectural Decision Points einer Softwaredomäne erfasst werden können, wurde eine Literatursuche duchgefuhrt. Als Ergebnis wurden relevante Forschungsergebnisse festgehalten, die sich auf den Rahmen dieser Arbeit beziehen. Basierend auf diesen Ergebnissen wurden Anforderungen fur das Wissensmodell für Architectural Design Decisions entwickelt.
Die Vollständigkeit der Entscheidungserfassung soll mit diesen Anforderungen überprüft werden.
Anschließend wurde das Wissensmodell entwickelt und dessen Elemente und Beziehungen so festgelegt, um die Identifikation von Entscheidungsmustern zu ermöglichen. Um die Entscheidungsfindung zu unterstützen, werden Visualisierungsmethoden angewendet. Im Anschluss wurde das Wissensmodell fur Entscheidungsmuster in einer Softwaredomäne angewendet, um die Praxistauglichkeit zu testen. Als Ergebnis wurde ein Katalog von Entscheidungsmustern festgehalten, die im Rahmen dieser Softwaredomäne gelten. Abschließend wurde das Wissensmodell evaluiert. Dabei wurden zwei Aspekte behandelt: (i) die Sicherstellung der Vollständigkeit der Entscheidungserfassung anhand der definierten Anforderungen und (ii) die Anwendbarkeit des Wissensmodell auf eine generische Softwaredomäne.

Der Bereich des Informationsmanagements (IM) im Krankenhaus ist zentral für die Unterstützung
der Aufgaben eines Krankenhauses. IM stellt die Erbringung von IT-Services
sicher und orientiert sich dabei an drei Managementebenen: der strategischen, der administrativen
und der operativen Ebene. Es weist somit eine hohe Komplexität für ein
umfassendes Informationssystem des IT-Bereichs auf. Dadurch kann der Istzustand über
die Struktur dieser Aufgaben, der verwendeten Anwendungssysteme und Informationsartefakte
häufig unklar sein. In diesem Zusammenhang sind standardisierte Prozesse erstrebenswert,
die eine effektive Aufgabenbearbeitung und Nutzerzufriedenheit im Rahmen
von IT-Services gewährleisten können. Ein bedeutendes Konzept bietet hierbei das Framework
IT Infrastructure Library (ITIL), eine Sammlung von Best Practices für den
IT-Betrieb. Im IM von mehreren Krankenhäusern sind ITIL-Prozesse bereits eingeführt,
um die Leistung ihrer IT-Services auf der operativen Ebene zu optimieren. Diese Arbeit
beschreibt den Istzustand sowie den Einsatz von ITIL in dem jeweiligen IT-Bereich
zweier Krankenhäuser. Hierfür wird eine Systemanalyse mithilfe von Interviews mit den
Mitarbeiterinnen und Mitarbeitern aus dem IM-Bereich durchgeführt. Die identifizierten
Aufgaben, Anwendungssysteme, deren Schnittstellen und verarbeitete Daten werden mit
dem Werkzeug 3LGM2 modelliert. Auf den Ergebnissen der Analyse aufbauend werden im
Rahmen einer Systembewertung umgesetzte ITIL-Prozesse mithilfe eines Referenzmodells
untersucht. Zudem werden Probleme und Auffälligkeiten aufgedeckt, die eine Beurteilung
über die aktuelle Situation in den IT-Bereichen der Krankenhäuser zulassen. In dieser
zeigt sich, dass zwar gewisse ITIL-Prozesse in den Krankenhäusern unterstützt werden,
ITIL jedoch nicht flächendeckend im IT-Betrieb verwendet wird.

Two major research streams on decision making exist: naturalistic decision making (NDM) and rational decision making (RDM). Especially in the domain of software development the question emerged which decision type might be the dominant approach utilized by software developers. This is relevant in regard to decision support systems which are more effective the better they fit to human decision making styles. Considering the consequences decisions can have in huge software projects this question is of major importance. Despite this relevance, little research exists on these two decision types and their role in software development. This study investigated the role of NDM and RDM in software development via an issue tracker analysis. Therefore, issues from a Firefox release cycle were taken and analyzed via a theoretically well-grounded coding table. This coding table is transparently designed and can be utilized in further studies. The main hypotheses of this thesis were that a) more naturalistic than rational elements could be exhibited throughout this software release cycle and that b) time pressure should increase NDM elements. The results show that more naturalistic than rational elements can be exhibited within the observed release cycle. Time did not appear to influence the amount of NDM elements. An explorative analysis showed an interaction between task characteristics and decision type which specified the results of the confirmed hypothesis. Closing, possible applications for decision support systems are discussed and promising avenues for future research are depicted.

Das CASE Werkzeug UNICASE umfasst seit einiger Zeit eine Komponente zur Geschäftsprozessmodellierung. Die Komponente ermöglicht die Erstellung von Geschäftsprozessmodellen in der Business Process Modelling Notation (BPMN) und das Verknüpfen der Modellelemente mit anderen Elementen in UNICASE. Mithilfe dieser Komponente können bequem funktionale Anforderungen dokumentiert werden, jedoch fehlt zurzeit noch die Möglichkeit Qualitätsinformationen (QI) im Geschäftsprozessmodell zu modellieren.
In dieser Master Thesis soll ein Konzept zur Modellierung von QI in Geschäftsprozessmodellen erstellt und prototypisch in dem bereits in UNICASE vorhandenen Editor umgesetzt werden (der Begriff Modellierung umfasst die Erfassung und Auswertung von QI in einem Modell). Zuvor soll der aktuelle Stand der Literatur zur Modellierung von QI in Geschäftsprozessmodellen untersucht werden, sowie die QI aus Geschäftsprozessen eines aktuellen Forschungsprojekts ausgewertet und auf die Möglichkeit geprüft werden diese in Geschäftsprozessmodellen darzustellen. Im Rahmen der Arbeit ist eine Erweiterung des Werkzeugs UNICASE zur Modellierung von Geschäftsprozessen in der Business Process Modeling Notation (BPMN) zu entwickeln. Darüber hinaus soll ein Konzept für die Verknüpfung der Elemente in einem BPMN-Modell mit anderen Anforderungselementen in UNICASE entwickelt werden.

HeiDOK

• die Grundlagen für die weiteren Ausführungen zu schaffen und auf Basis dieser Grundlagen eine Anwendung zu diskutieren,
• dem interessierten Leser aus der industriellen Praxis die Ideen und Intentionen von Rationale Management näher zu bringen, um diese mit deren Erfahrung und Expertise anwenden zu können und
• die Konzepte dann auf das Umfeld des Softwareprozessmodells übertragen zu können.

Michael Anders

Context & Motivation: User feedback from different sources, i.e. online forums or app stores, enables Requirements Engineers to analyze how well the software product is perceived by the public or if current requirements were implemented correctly. This means that user feedback relates to the current requirements of a software product. The amount of work required for this task, however, poses a great hindrance to making use of user feedback because manually relating feedback to requirements would take too much time. For this reason, the task must be automated to reduce the time needed for the work. Previous efforts towards automation using word embeddings have shown that automation is possible but requires further improvement to be used reliably. With the release of ChatGPT by OpenAI and its consecutive success in the public eye, a chance was seen here to automate relating feedback and requirements through this GPT model which was trained with a larger set of parameters compared to previous attempts using BERT coupled with the intuitive usage, where simple prompts, instructions constructed through natural human language, are needed, could offer desired improvements. Furthermore, requirements documented using the Task-Orientated Requirements Engineering framework could offer a further avenue for improvement by leveraging the framework’s levels to relate feedback to requirements in multiple stages. With this approach, feedback is first assigned to Subtasks and then to the System Functions and Workspaces that are associated with the Subtask. Contributions: This thesis makes four major contributions. Firstly, a Systematic Literature Review was conducted to map the current state of research regarding Prompt Engineering.
Secondly, a user feedback dataset was annotated with new review data of the Komoot Android app. Thirdly, the existing issue descriptions of Komoot’s requirements were revised. Lastly, a set of prompts was developed to examine ChatGPT’s capability for the automatic relation of feedback and requirements. The foundation for the development of these prompts was the result of the Systematic Literature Review. ChatGPT’s capability was examined by applying two kinds of processes to relate feedback and requirements together; a direct process and a multistage process. Results: A total of 9 prompts were developed to interact with ChatGPT to accomplish the task of relating feedback and requirements together for both evaluated processes. The direct process showed that the best achievable Recall is 40% and the best achievable Precision is 33%. The multistage process showed that none of the patterns were able to draw out a Recall higher than 20% and the Precision was always higher than the Recall value. The best Precision achievable in this multistage process was 40%. These results indicate that ChatGPT is less suited for the relation task than previously used BERT models.

Leon Radeck

[Context & Motivation] Models and other visual media are processed faster and easier by humans than tables or textual representations. But the process of creating and maintaining such visualizations is often very time consuming. So by automatically generating a visualization based on pre-existing data, this process can be expedited. Researchers and Requirements Engineers often use manual coding to extract relevant information from data sets. They assign certain codes to specific passages in the data in order to categorize them. This results in an annotation of a data set. But it is difficult to quickly understand large annotations, so the visualization of an annotation can help a researcher to more quickly get an overview over a given annotation. The addition of filters and display modes like a heatmap and custom coloring further helps to get an overview of data.

[Contributions] This thesis explores the state-of-the-art in model generation for requirements and other natural language documents aswell as commonly used features and techniques to better visualize models. The already existing annotation tool Feed.UVL is extended by the posibility to visualize an annotation model. The created extension provides interactivity by offering options to organize, and customize the visualization and offering a heatmap, which displays the occurences or appearances of elements of the visualization, to further emphasize the important elements of a data set. A set of quality assurance measures have also been performed on the tool, namely static code reviews, system tests and an evaluation.

[Conclusion] The systematic literature research revealed, which features are mainly used in creating and maintaining a visualization, aswell as the requirements to automate this process. The main part of this thesis was the creation of a tool for the automatic generation of a visualization of an annotation model. The tool has a user-friendly design in line with Feed.UVL in which it is integrated. The automatic visualization can be manually refined, and always displays the current status of an annotation. The tool was also created in a modular fashion with an extensible framework, so it can be easily extended for future research goals. The evaluation has shown that most of the functionalities are considered easy-to-use and useful and would be used in the future.

Our society is constantly getting older. This process is called demographic change, and it is in full progress. As the population ages, new problems arise, such as loneliness and social isola- tion in old age, which need to be addressed. The SMART-AGE study deals with precisely such problems and investigates to what extent intelligent assistance systems can provide a remedy for these problems. In order to continuously improve the assistance systems provided during the study and to add new desired functionalities, it is essential to collect feedback from the users. With the help of this feedback, already existing functionalities can be improved, extended, or new requirements can be identified. Due to the large number of study participants, collecting feedback individu- ally is not an option, therefore, a chatbot should be provided for this purpose. This also enables the submission of feedback at any given time, and makes it as easy as possible. This thesis focuses on designing and implementing such a chatbot for collecting feedback. There- fore, the first step is to perform an analysis of several chatbot frameworks, with the goal to identify a suitable one to implement the chatbot in. Subsequently, requirements are identified based on given requirements and material, as well as insights obtained from the framework analysis. For the extraction and presentation of the requirements, the task and object-oriented requirements engineering (TORE) method is applied. The gained requirements are then used to design and implement the chatbot, using the framework identified during the analysis. To ensure the quality of the application, system tests are conducted and captured using the tool Selenium IDE. Afterwards, the application is evaluated. Therefore, usage scenarios have been created, which are then executed by the evaluation participant alone. Subsequently, the par- ticipant has to answer a questionnaire, which has been developed following the Technology Acceptance Model (TAM). The results of the evaluation are throughout positive, and the com- ments of the participant includes interesting adaptations and improvement, which eventually will be implemented in the future.

Patrick Pollok

Das Testen von Software ist ein wichtiger Bestandteil der Softwareentwicklung, welches sicher- stellt, dass die Software alle vorher definierten Anforderungen erf ̈ullt. Im Anforderungsprozess werden aus den, meistens groben Anforderungen an ein Softwaresystem, spezifischere System- funktionsbeschreibungen abgeleitet. Systemfunktionsbeschreibungen definieren dabei einzelne Aufgaben des Softwaresystems. Aus den Systemfunktionsbeschreibungen werden dann in der Testphase Systemtests generiert. Die Systemtests stellen dabei sicher, dass die Implementierung der Systemfunktionsbeschreibung, die Systemfunktion, ihre Beschreibung erf ̈ullt. Das Erstellen von Systemtests ist arbeitsintensiv und wenig automatisiert. Systemfunktionsbeschreibungen und Systemtests k ̈onnen mit Softwareentwicklung-Tools, wie das Issue-Tracking-System Jira, dokumentiert und verwaltet werden. Im Rahmen dieser Bachelorarbeit wird ein Plugin Proto- typ zur Generierung eines Testplans mit Systemtests aus Systemfunktionsbeschreibungen vor- gestellt. Der Nutzer1 kann sich aus einer beliebigen Anzahl an Systemfunktionsbeschreibungen einen Testplan mit vorgefertigten Systemtests generieren lassen. Der Nutzer kann die vorgefer- tigten Systemtests dann bearbeiten, l ̈oschen, oder weitere Systemtests hinzuf ̈ugen. Abschließend kann der Nutzer eine Auswahl der Systemtests zu einem Jira-Projekt hinzuf ̈ugen lassen. Dabei werden die Systemtests mit den Systemfunktionsbeschreibungen verlinkt.

Robin Alter

[Context & Motivation] Models and other visual media are processed faster and easier by humans than tables or textual representations. But the process of creating and maintaining such visualizations is often very time consuming. So by automatically generating a visualization based on pre-existing data, this process can be expedited. Researchers and Requirements Engineers often use manual coding to extract relevant information from data sets. They assign certain codes to specific passages in the data in order to categorize them. This results in an annotation of a data set. But it is difficult to quickly understand large annotations, so the visualization of an annotation can help a researcher to more quickly get an overview over a given annotation. The addition of filters and display modes like a heatmap and custom coloring further helps to get an overview of data. [Contributions] This thesis explores the state-of-the-art in model generation for re- quirements and other natural language documents aswell as commonly used features and techniques to better visualize models. The already existing annotation tool Feed.UVL is extended by the posibility to visualize an annotation model. The created extension provides interactivity by offering options to organize, and customize the visualization and offering a heatmap, which displays the occurences or appearances of elements of the visualization, to further emphasize the important elements of a data set. A set of quality assurance measures have also been performed on the tool, namely static code reviews, system tests and an evaluation. [Conclusion] The systematic literature research revealed, which features are mainly used in creating and maintaining a visualization, aswell as the requirements to automate this process. The main part of this thesis was the creation of a tool for the automatic generation of a visualization of an annotation model. The tool has a user-friendly design in line with Feed.UVL in which it is integrated. The automatic visualization can be manually refined, and always displays the current status of an annotation. The tool was also created in a modular fashion with an extensible framework, so it can be easily extended for future research goals. The evaluation has shown that most of the functionalities are considered easy-to-use and useful and would be used in the future.

Lukas Bendl

Developers continuously make decisions during the software development process. These decisions have a large impact on future changes that are applied to the software. However, developers often only document parts of the decision-making process or do not document anything at all. The ConDec project aims to support developers in capturing and exploiting decision knowledge. It introduces a set of plugins that are integrated into existing development tools, thereby aiding developers in documenting and analyzing decision knowledge. This work aims to improve the change impact analysis (CIA) of the ConDec Jira plugin, a feature using traceability and explicit rules to detect and visualize the consequences of a change. For this purpose, a systematic literature synthesis is conducted to review existing literature on this topic. Based on this research, we systematically elicit requirements for a prototype that extends ConDec Jira. We improve the existing CIA implementation by adding additional rules and configuration options. We improve traceability by adding more options for developers to manually edit links. Additionally, developers can choose to include not explicitly linked elements to the change impact calculation. We ensure the quality of the implementation by using a continuous integration workflow. Furthermore, we evaluate the prototype by conducting an experiment, in order to measure the effectiveness of our CIA implementation. The results indicate that including not explicitly linked elements is especially useful for finding non-code software artifacts, such as decision knowledge, that are affected by a change, thereby increasing the effectiveness of CIA. Furthermore, using a finetuned ruleset additionally increases the number of impacted artifacts that are found. In the future, it should be investigated how further configuration options for individual rules could improve CIA.

Jasmin Sebastian

In einer zunehmend alternden Gesellschaft stehen wir vor neuen Herausforderungen im Ge- sundheitssektor und im Sozialleben älterer Menschen. Software spielt hierbei eine zentrale Rolle. Eine weitere große Herausforderung der heutigen Zeit ist das Thema Nachhaltigkeit. Wegen der zunehmend wichtiger werdenden Rolle von Software im gesellschaftlichen Leben, ist es essentiell, dass auch im Bereich der Digitalisierung auf eine nachhaltige Entwicklung geachtet wird. Daher ist es Ziel dieser Arbeit einerseits Nachhaltigkeits- anforderungen an intelligente Assistenzsysteme im Alltag (IASA), die ältere Menschen unterstützen sollen, zu definieren. Andererseits ist es das Ziel, die Anwendung PRISM, um Funktionalitäten im Sinne dieser Nachhaltigkeitsanforderungen zu erweitern. PRISM ist eine Webanwendung, die die Verbesserung der sozialen Interaktion, der Informationsbeschaffung, der Selbstorganisation und der Unterhaltung ältere Erwachsener erreichen soll. Um PRISM weiter zu entwickeln, wurde verschiedene Literatur sowohl im Bereich der nachhaltigen Softwareentwicklung als auch zu Anforderungen an Gesundheitsanwendungen betrachtet. Auf Basis der gefundenen Erkenntnisse wurde das Framework SINS entwickelt, welches Nachhaltigkeitskriterien für Gesundheitsanwendungen definiert. Schließlich wurde die An- wendung PRISM entsprechend dieser Anforderungen erweitert. Um eine qualitätsgesicherte Software zu garantieren wurden mit Hilfe verschiedener Frameworks Tests durchgeführt und die Anwendung anhand der Nachhaltigkeitskriterien evaluiert.

Daniela Tratz-Weinmann

Feedback ist eine wichtige Grundlage, um Software weiterzuentwickeln und Fehler finden zu können. Im Rahmen des SMARTAGE-Projektes, dessen Ziel es ist, innerhalb einer Studie zu untersuchen, welche Lebensqualitätsverbesserungen der Einsatz von intelligenten Assistenzsystemen (IAS) erbringen kann, ist es daher notwendig, einen Weg zu finden, sinnvoll Feedback der StudienpartnerInnen zu diesen Systemen einzuholen. Dabei muss darauf geachtet werden, dass die StudienpartnerInnen nicht durch die Einholung gestört werden, die gewählte Methode mit einer großen Anzahl an Personen umgehen kann und die Nutzungsdaten der StudienpartnerInnen berücksichtigt werden. Ziel der Arbeit ist daher, eine Anwendung zu entwickeln, die in der Lage ist, verschiedene Arten von Feedback einzuholen, um verschiedene Aspekte der Nutzungserfahrung zu sammeln, sich an die Nutzungsdaten anpasst und sich gleichzeitig nicht störend auf die StudienpartnerInnen auswirkt. Dafür wird zunächst eine Literaturrecherche durchgeführt, um mögliche Störfaktoren zu identifizieren und allgemeine Hinweise für die Einholung von Feedback zu sammeln. Anschließend werden die vorgegebenen Grobanforderungen zu Detailanforderungen verfeinert und mithilfe von Java EE implementiert. Danach wird die Qualitätssicherung mithilfe von Systemtests und Komponententests durchgeführt und die entwickelte Anwendung evaluiert.

In order to evolve software, developers need to make decisions. These should be based on previous decisions to support a consistent process and high software maintainability. However, the decisions might not be available because they were not captured, or because their documentation is of poor quality. The ConDec Jira plugin assists the stakeholders of software projects, by enabling the creation, improvement, and use of rationale documentation within the issue tracking system Jira. In this work, we examine how changing the presentation of choices, so-called nudging, can be used in the plugin. The goal is to better engage the ConDec users in the rationale management process. We perform a literature search on nudging, examining various nudges in the field of human-computer interaction. We analyze which of the nudges from literature could make sense to be implemented in the ConDec Jira plugin. We add appropriate nudges to the user interface, changing the coloring of the ConDec view items and intervening on status changes using just-in-time prompts. We also increase the configurability of the plugin by providing new configuration options, and promote usability by setting reasonable default options and opt-out policies. The quality of the implementation is assured using a test concept and continuous integration workflow. In addition, the implementation was evaluated in a survey of other Jira users. The results indicate high ratings in the categories ease of use and usefulness. The plugin should be further developed in response to the results of our survey. In the future, we suggest performing an experiment to gain insight on the effectiveness of the nudging in the context of ConDec.

Bei der Entwicklung von Software müssen die Beteiligten kontinuierlich Entscheidungsprobleme lösen, d.h. Entscheidungen treffen. Dabei wägen sie Pro- und Contra-Argumente der alternativen Lösungen gegeneinander ab. Bei diesem Prozess entsteht Entscheidungswissen, auch Rationale genannt. Für die Evolution der Software und die Wiederverwendung von Problemlösungen ist die Dokumentation des Entscheidungswissen von großer Bedeutung. Es ist wichtig, dass offene Entscheidungsprobleme und Lösungsmöglichkeiten innerhalb des Teams bzw. zwischen allen Stakeholdern kommuniziert werden, damit die bestmöglichen Entscheidungen getroffen werden. Weiterhin ist eine hohe Qualität der Dokumentation bedeutsam, damit diese zukünftigen EntwicklerInnen verständlich und nützlich ist. In dieser Arbeit wird dafür ein Rationale Backlog entwickelt. Dieses bietet einen guten Überblick über Punkte, die eine Entscheidung erfordern und zu verbesserungswürdiger Dokumentation von Entscheidungswissen. Damit unterstützt das Rationale Backlog die EntwicklerInnen sowohl bei der Entscheidungsfindung als auch bei Verbesserung der Dokumentationsqualität. In einer systematischen Literaturrecherche wird dafür untersucht, welche Ansätze es dazu bereits gibt. Daraus werden verschiedene Anforderungen an die Umsetzung des Rationale Backlog abgeleitet. Anschließend werden Anforderungen, Entwurf, Implementierung und Qualitätssicherung des Rationale- Backlogs beschrieben sowie die Durchführung und Ergebnisse einer Akzeptanzevaluation. Die positiven Rückmeldungen aus der Evaluation bezüglich der einfachen Benutzbarkeit und hohen Nützlichkeit des Prototyp, bieten eine Basis für den Einsatz des Rationale Backlog in zukünftigen Projekten. Besonders in agilen Projekten, in denen neben der kontinuierlichen Implementierung neuer Features eine qualitativ hochwertige Dokumentation der getroffenen Entscheidungen erreicht werden soll, ist dies vorstellbar. Um die Nützlichkeit und Benutzbarkeit des Prototyp weiter zu verbessern, werden im letzten Kapitel Vorschläge zu Änderungen und neuen Features diskutiert.

Das Dokumentieren ist und sollte ein wichtiger Bestandteil während der Entwicklung von Software sein. Während der Entwicklung treffen die Beteiligten ständig Entscheidungen. Damit generieren sie neues Wissen über Entscheidungen. Dieses Wissen über Entscheidungen wird Entscheidungswissen genannt. Damit Entscheidungswissen nicht verloren geht und alle Projektteilnehmer von diesem Wissen profitieren können, muss es eine einfache Möglichkeit geben dieses Wissen zu dokumentieren und zu visualisieren. Das ConDec-Jira-Plug-In bietet eine solche Möglichkeit. Damit Entscheidungen nicht nur zu funktionalen, sondern auch zu nicht-funktionalen Anforderungen dokumentiert werden, wird in dieser Arbeit eine Möglichkeit geschaffen, den Bezug von Entscheidungen zu Qualitätsattributen wie z.B. Perfomanz und Sicherheit deutlich zu machen und nachvollziehen zu können. Dafür wird eine systematische Literaturrechere durchgeführt. Die daraus gewonnenen Erkenntnisse fließen anschließend in einen Prototyp, der eine Dokumentations- und Visualisierungsmöglichkeit bietet, Entscheidungswissen bezügliche Entscheidungen zu Qualitätsattributen zu dokumentieren und nachzuvollziehen.

In order to comprehend the evolution of a software system and the rationale behind the decisions, it is essential to identify and understand the features of the software. Thus, including management tasks and development tasks, software features play an essential role in many software engineering activities.
However, managing feature knowledge is extremely challenging and time consuming, as features continuously change over time and most software companies and open source projects use a combination of an Issue Tracking System (ITS) such as Jira and a Version Control Systems (VCS) such as git. Thus, the information is usually distributed across both systems, e.g., requirements are documented in ITS and code is stored in VCS. Often, this results in lacking traceability between features and their refining artifacts.
Therefore, TAFT, the tagging approach to support feature management across ITS and VCS was developed by Seiler and Paech. TAFT provides a tool support that enables to document, maintain, and exploit feature knowledge in ITS and integrated development environments (IDE) consistently and eÖciently. Instead of creating traces between feature knowledge, feature knowledge is tagged with the same keyword that precisely summarizes the functionality of the feature. TAFT^R indicates that the approach TAFT is applied retrospectively. The aim of using TAFT^R is to subsequently and systematically develop feature knowledge for a software project.
In this work, we first carried out a systematic literature search in order to find and analyze the existing approaches for identifying software features. We then applied TAFT^R on the open source project ConDec and evaluated it by calculating inter-rater reliability. Consequently, we reported our experience and shared our suggestions for the improvement of TAFT^R.

[Kontext und Motivation] Featurewissen, wie z.B. das Wissen darüber welche Features eine Software enthält, oder welche Anforderung oder Code ein bestimmtes Feature implementiert, liefert Entwicklern wertvolle Informationen, die für verschiedene Software- Engineering Aktivitäten nützlich sein können wie z.B. Releaseplanung. Dafür werden Feature-Tags an Code-Abschnitte vergeben, um so die Nachverfolgbarkeit zwischen Softwareartefakten zu verbessern. Eine Studie zeigt auf, dass Entwickler zwar in der Lage sind, richtige Feature-Tags an ihren Code zu vergeben, hierbei allerdings nur 65% des Codes überhaupt getaggt wird. Um Entwickler bei der Vergabe von Feature-Tags zu unterstützen, wird ein (semi-) automatisches Feature-Vergabesystem entwickelt, das basierend auf einer textuellen und strukturellen Codeanalyse die fehlenden Feature-Tags im Code einer Software vervollständigt. [Fragestellung] Diese Bachelorarbeit analysiert zunächst verschiedene Ansätze zur textuellen und strukturellen Codeanalyse, erarbeitet welche Techniken und Ähnlichkeitsmaße die Ansätze dafür verwenden und welche Güte in Form der Metriken Precision und Recall diese dabei erreichen. [Ansatz] Mit dem Ansatz der Feature-Regionen wird ein Eclipse Plug-In implementiert. Dabei gibt es die Möglichkeit die vorgeschlagene Vergabe manuell anzupassen, bevor diese für das Tagging übernommen wird. [Ergebnis] Das Plug-In wird durch ein Studentenprojekt mit existierendem Goldstandard durch einen IST-SOLL-Vergleich auf seine Qualität bzgl. der Metriken Precision und Recall evaluiert. Die Ergebnisse mit durchschnittlich 84,83% Precision und 82,85% Recall zeigen, dass das entwickelte Plug-In gute Werte für eine (semi-)automatische Vergabe von Feature-Tags im Code liefert. Es konnte gezeigt werden, dass ein (semi-)automatisches Feature-Vergabesystem Entwicklern dabei hilft, ihren Code mit Feature-Tags zu vervollständigen.

Bei der Entwicklung eines Softwaresystems benötigen EntwicklerInnen Wissen über die getroffenen Entscheidungen, um während der Softwareentwicklung auftretende Entscheidungsprobleme zu beheben. EntwicklerInnen müssen ihr Entscheidungswissen teilen, da die getroffenen Entscheidungen beispielsweise für die Umsetzung zukünftiger Anforderungen besonders wichtig sind. Um EntwicklerInnen, die neu an einem Projekt beteiligt werden, den Zugriff auf dieses Entscheidungswissen zu ermöglichen, ist es wichtig, Entscheidungen zu dokumentieren. Jedoch werden Entscheidungen von EntwicklerInnen sehr wenig dokumentiert und es ist ein Problem, dass EntwicklerInnen Entscheidungswissen benötigen, dieses aber nicht dokumentieren und es somit nicht auffindbar ist. Die mangelnde Dokumentation an Entscheidungen stellen somit ein großes Problem bei der Entscheidungsfindung dar. Eine Lösung für das Festhalten von Entscheidungswissen bietet das Issue-Tracking-System Jira. EntwicklerInnen können dort beispielsweise Entscheidungswissen in der Beschreibung und den Kommentaren von Jira-Issues festhalten. Ein Ziel dieser Arbeit war es eine systematische Literaturrecherche durchzuführen, um die Fragen zu beantworten, welche Kategorien beziehungsweise Taxonomien für Entscheidungen es gibt, wofür diese eingesetzt werden und was die Erkenntnisse aus der Nutzung der Taxonomien sind. Um das Entscheidungswissen zu klassifizieren wurde durch die Literaturrecherche eine Taxonomie gefunden, die vier Kategorien von Entscheidungen unterscheidet. Diese Taxonomie wurde beispielsweise eingesetzt, um Entscheidungen in dem Issue-Tracking-System Jira automatisch mittels eines Ansatzes des maschinellen Lernens zu identifizieren. Das Ergebnis aus der Literaturrecherche zeigte, dass dabei die meisten Entscheidungen Existenzentscheidungen waren und mit Hilfe der automatischen Klassifizierung Entscheidungen identifiziert werden können. Ein weiteres Ziel dieser Arbeit war es selbst eine empirische Analyse des in Jira-Issues dokumentierten Entscheidungswissens durchzuführen. Zur Analyse wurde ein Jira-Projekt mit 108 Jira-Issues aus dem Lucene-Projekt importiert. Bei der empirischen Analyse werden Antworten auf die Forschungs- und Analysefragen gesucht, welches Entscheidungswissen EntwicklerInnen dokumentieren, wie vollständig die Dokumentation ist, ob Entwickler Entscheidungen in der Zeit ablehnen und - wenn ja - wie oft und warum? Mit Hilfe des ConDec Jira Plug-Ins wurde eine manuelle Klassifikation von Jira-Issues durchgeführt. Die Ergebnisse der Analyse zeigen, dass in den meisten Fällen für dokumentierte Entscheidungsprobleme Entscheidungen dokumentiert werden und durch die explizite Dokumentation verworfene Entscheidungen verfolgt werden können.

Dokumentation ist ein wichtiger Bestandteil der Software-Entwicklung. Während der Entwicklung fertigen die Beteiligten auf verschiedenen Ebenen Dokumentation an. Beispielweise dokumentieren Entwickler im Programmcode, während Projektmanager in Issue-Tracking-Systemen und anderen Projektmanagement-Tools dokumentieren. Ein Teil dieser Dokumentation sind Release-Notes. Diese werden am Ende des Release-Zyklus entweder manuell oder (semi-) automatisch mithilfe von Werkzeugen erstellt. Während der Software-Entwicklung lösen die Beteiligten Entscheidungsprobleme, finden alternative Lösungsmöglichkeiten, wägen die Vor- und Nachteile ab und treffen Entscheidungen. Das Wissen, das sie darüber besitzen, wird als Entscheidungswissen bezeichnet. Die Dokumentation von Entscheidungswissen wird durch das ConDec-Jira-Plugin unterstützt. In dieser Arbeit wird dieses Plugin um die Funktion erweitert, Release-Notes zu erstellen, die Entscheidungswissen beinhalten. Dafür gibt es verschiedene Konfigurationsmöglichkeiten und ein Algorithmus zur Relevanzbewertung kann bei der Entscheidung, welcher Inhalt in die Release-Notes einfließen soll, helfen. Die Erweiterung wird durch eine Umfrage mit Entwicklern des ConDec-Jira Plugins und einem Vergleich mit bestehenden ähnlichen Werkzeugen evaluiert.

Entscheidungen, die während der Entwicklung getroffen werden, werden meist nicht dokumentiert und auch nicht an andere Projektmitglieder weitergegeben. Im späteren Verlauf können diese fehlenden Informationen zu Arbeitsverzögerungen durch doppelte Arbeit führen. Das ConDec Werkzeug befasst sich mit dieser Problematik. Es ermöglicht das Erfassen von Entscheidungsproblemen, die während der Softwareentwicklung auftreten, die Diskussion von Alternativen zu einem Entscheidungsproblem und das Festlegen sowie die Dokumentation von Entscheidungen. Im Verlauf eines Projekts können Entscheidungen durch neue ersetzt werden oder neue Argumente entstehen. Aus diesem Grund müssen auch die Entscheidungen, die vor langer Zeit getroffen wurden, immer wieder neu betrachtet werden. Die Neubetrachtung im Rahmen einer Besprechung bleibt jedoch meist aus, da keine zeitliche Einordnung möglich ist. Neue EntwicklerInnen haben oft das Problem sich in ein neues Projekt einzuarbeiten und die Entscheidungen nachvollziehen zu können. Ziel dieser Arbeit ist es, diese Probleme anzugehen. Im Umfang dieser Arbeit wird durch eine Literaturrecherche herausgefunden, was EntwicklerInnen und ProjektmanagerInnen wissen wollen, um die Evolution von Entscheidungswissen verwalten und bearbeiten zu können und welche Unterstützung sie dafür benötigen. Der Status von Entscheidungswissen wird zu dem bereits vorhandenen ConDec Werkzeug hinzugefügt. Außerdem werden Evolutionsansichten hinzugefügt, die es ermöglichen, den zeitlichen Verlauf und eine Gegenüberstellung anzuzeigen, die die Einarbeitung und das Überarbeiten von Entscheidungswissen erleichtert. Filter ermöglichen den NutzerInnen dabei, essenzielles Wissen zu visualisieren. Die Erweiterungen werden im Arbeitsumfeld des ConDec Werkzeugs evaluiert und die Qualität wird sichergestellt. Als Abschluss werden die Ergebnisse dargestellt und mit einer Aussicht auf die Zukunft beschrieben.

[Motivation] Bei SAP HANA gibt es zahlreiche Tools zur Qualitätssicherung des Softwareentwicklungsprozesses. Oftmals ist die Sicht solcher Tools eher auf die Bedürfnisse der Produktmanager und Qualitätsmanagementbeauftragten zugeschnitten. Die Ergebnisse sind oft zusammengefasst und nicht aktuell, weil die Datenerhebung der Qualitätsmetriken vom Release-Zeitpunkt abhängig ist. Diese Sicht auf die Qualitätssicherung erfüllt aber nicht immer die Informationsbedürfnisse eines Softwareentwicklers bzw. einer Softwareentwicklerin.

[Ziele] Das Hauptziel dieser Arbeit ist der Entwurf und die Implementierung einer Webanwendung, die die Qualitätsmetriken anzeigt, die aus Entwicklersicht nützlich sind. Diese Metriken sollen sich direkt in konkrete Aufgaben übersetzen lassen. Um dieses Ziel umzusetzen, wurde eine Literaturrecherche zum Thema entwickler-zentrierte Qualitätssicherung durchgeführt und anschließend wurden die potenziellen NutzerInnen einer solchen Webanwendung in Einzelinterviews zu den Metriken befragt.

[Ergebnisse] Die Hauptergebnisse dieser Arbeit sind zum einen eine Liste von Metriken, die sich bei den Interviews als nützlich herausgestellt haben und zum anderen ein Prototyp der Webanwendung (Quality Page), der zwei dieser Metriken anzeigt. Die implementierte Quality Page wurde von den Teilnehmern der Interviewstudie bewertet und im Allgemeinen für nützlich befunden. Während der Evaluation wurden zudem Ideen genannt, wie die Quality Page weiter ausgebaut werden kann, um EntwicklerInnen täglich bei der Qualitätssicherung ihres Codes unterstützen zu können.

Software development usually involves the creation of source code and requirement specifications. Information about which source code entities were based on a specific requirement, or were influential during the implementation, is frequently incomplete.

This thesis investigates how interaction data can be used to create trace links between source code entities and requirement specifications, as well as possible applications for those trace links. Interaction data is gathered in the integrated development environment, transmitted to an issue tracking system and assigned to an issue chosen by the developer as changes to the source code are committed to the version control system. The prototype developed to showcase this functionality contains an extension to the Eclipse plug-in Mylyn, which minimizes the user interactions required to record and upload the interaction data to the issue tracking system. A Jira plug-in displays the trace links created based on the gathered data in the issue view of the relevant requirement specification. It also provides hyperlinks to the source code in a repository browser.

Ontologien enthalten eine semantische Beschreibung von Konzepten und deren Relationen aus der realen Welt und liegen in maschinenlesbarer Form vor. Im Rahmen des DFG geförderten Projekts SNIK (Semantisches Netz des Informationsmanagement im Krankenhaus) wird eine Ontologie erstellt, die Aufgaben, Rollen und Objekttypen des Informationsmanagements abbildet.In der IT Umgebung des Krankenhauses fallen unzählige Daten an, die für Entscheidungen des IT-Leiters oder auch Chief Information Officer (CIO) relevant sind. Um den CIO bei seinen Entscheidungen zu unterstützen, wird der CIO-Navigator (CION)im SNIK Projekt entwickelt. Der fertige CION unterstützt den CIO durch die Erstellung, Aggregation und Darstellung von relevanten Informationen aus der IT-Abteilung im Krankenhaus, und ermöglicht so das Treffen objektiver Entscheidungen. So entstand die Idee, die Ontologie als Datenmodell mit semantischer Beschreibung zur Datenaggregation zu verwenden. Dieser Ansatz wird in der wissenschaftlichen Literatur als Ontology Based Data Access (OBDA) bezeichnet und lässt sich unter anderem in Frameworks wiederfinden.

Diese Bachelorarbeit zeigt den aktuellen Forschungsstand des Einsatzes einer Ontologie als Datenmodell und zum Zugriff auf Daten im Bereich OBDA. Verschiedene Ansätze und Frameworks werden gegenübergestellt und hinsichtlich der Anforderungen an eine an das Projekt angepasste Lösung, in Form eines Prototyps, verglichen.

Der in dieser Arbeit entstandene Prototyp zeigt auf, wie die vorhandene Ontologie mit den verschiedenen Datenquellen (z.B. Excel) verknüpft und so als eine semantische Beschreibung der Daten verwendet werden kann. Für die Entwicklung werden dessen Anforderungen erhoben und dann im Prototyp umgesetzt. Der Prototyp baut auf einem in der Literaturrecherche evaluierten Framework namens Ontop auf und greift über dieses auf die Daten zu. Die Daten werden über einen Föderationsserver (Teiid) als eine virtuelle Datenbank an Ontop exponiert. Um sicher zu stellen, dass der Prototyp den Anforderungen gerecht wird, werden manuelle- und Unit-Tests eingesetzt. Zur Dokumentation der Anforderungen wird UNICASE verwendet.

Im Zuge der Softwareentwicklung entsteht eine Vielzahl von unterschiedlichen Dokumenten. Dies gilt auch für die Dokumentation von Anforderungen. Die Rückverfolgbarkeit (Traceability) von einem Anforderungsdokument zur Umsetzung in der Implementierung wird durch Trace Links sichergestellt. Trace Links für Dokumente in Software Entwicklungsprojekten werden jedoch oftmals nur teilweise oder gar nicht umgesetzt. Der Hauptgrund dafür ist der hohe Aufwand der manuellen Erstellung von Trace Links.

Diese Arbeit beschäftigt sich daher mit dem Vergleich von zwei unterschiedlichen Verfahren zur automatisierten Trace Link Erstellung. Hierbei werden Trace Links, die durch Interaktionen von Entwicklern mit Ihrer Entwicklungsumgebung erzeugt wurden, verwendet, um diese mit Trace Links, die durch Information Retrieval (IR) erzeugt werden, zu vergleichen. Dazu wird ein Werkzeug entworfen, welches sowohl bei der Erstellung von IR Trace Link Datensätzen als auch der weiteren Verarbeitung von Trace Link Datensätze unterstützt.

In Software Projekten werden sehr viele Dokumente angelegt, um Anforderungen und Entscheidungen zu dokumentieren. In dieser Dokumentation werden alle wichtigen Informationen zu einem Projekt hinterlegt. Viele dieser Informationen sind wichtig für die Implementation einer Software, sind aber im Arbeitsbereich des Software Entwicklers, der die Implementation vornimmt, nicht mühelos und nachvollziehbar erreichbar.

Diese Arbeit versucht diese Lücke zwischen der Dokumentation im CASE-Tool UNICASE und der Implementierung zu schließen. Dazu wird eine Methode zur Verlinkung von Quelltext und Anforderungsdokumenten entwickelt und prototypisch als Eclipse Plug-In umgesetzt.

Many decisions which are made during the implemetation phase of software projects are documented either not at all or through unstructured comments within the source code. This makes the rationale, i.e. the underlying issue with its context, alternative solutions and criteria behind the decision implicit. As a consequence, reproducing the decision later on becomes very difficult. It is thus necessary to make as much of this decision knowledge as possible explicit, since decisions made during the earlier stages are frequently reevaluated, changed or discarded during the evolution of a software project.
This thesis investigates the possibilities and limitations of documenting decision knowledge through annotations in the source code within the Eclipse IDE. For this, an annotation schema is developed and implemented as an Eclipse plug-in. It is investigated, how this schema can be made flexible in the sense that project-specific adjustments to the structure of the decision knowledge should be possible with as less time and effort as possible. Also, annotated decisions are mapped to and kept consistent with an external
UNICASE documentation.

Barbara Paech

Thomas Hahn

Die vorliegende Arbeit thematisiert und erschließt den an der Universität Heidelberg gelehrten Software Engineering Prozess (TRAIN Prozess) im praktischen Einsatz.
Nach einer Einführung erfolgt eine detaillierte Durchführung des Prozesses anhand eines Internet Portalprojektes aus dem Bereich Sport. Als Resultat entsteht eine multi-Tier Anwendungskomponente, die das Registrierungsmanagement für Sportveranstaltungen bereitstellt. Nach einer kritischen Betrachtung des durchgeführten Prozesses werden Vorschläge zur Modifikation von TRAIN für den schulischen Einsatz erarbeitet. Darauf aufbauend wird der Prozess in einer angepassten Version anhand einem thematisch verwandten aber technisch völlig unterschiedlichen Projekt erneut bis zur Implementierungsphase durchlaufen. Das Ergebnis dient als Grundlage für weitergehende Vorschläge, die besonders den Einsatz von Szenarien und systematischen Test berücksichtigen. Das Ergebnis stützt die These, dass ein umfassendes Software Engineering an allgemeinbildenden Gymnasien realisierbar ist.

Barbara Paech

David Grünbeck

Ziel dieses Praktikums war die Entwicklung mehrerer Lehreinheiten zur Vermittlung von Programmierkompetenz, die statt einer konkreten Programmiersprache das Programm Game Maker (YoYo Games) verwenden. Dazu wurde zunächst in einer Literaturrecherche zusammengestellt, was wichtige Programmierkonzepte sind und wie sie typischerweise vermittelt werden. Daraufhin wurde eine Auswahl einiger Konzepte, auf denen die Lehreinheiten basieren sollen, getroffen. Schließlich wurde die Klassenstufe festgelegt, in der diese Konzepte vermittelt werden sollen. Die Ergebnisse dieser Recherche- und Auswahltätigkeit finden sich im ersten Teil der Arbeit.
Im weiteren Verlauf des Praktikums wurde dann ein Vorschlag für mehrere aufeinander abgestimmte Lehreinheiten erarbeitet, die die zuvor ausgewählten Programmierkonzepte mithilfe von Game Maker vermitteln sollen. Diese finden sich im zweiten Teil der Arbeit. Bei der Ausarbeitung wurde darauf geachtet, die Darstellung des Vorgehens im Unterricht detailliert zu gestalten, um auch Lehrern mit einem geringen Einarbeitungsgrad in die Entwicklungsumgebung Game Maker die Durchführung des hier vorgestellten Konzepts zu ermöglichen. Um dies weiterhin zu unterstützen, finden sich zudem zwei Anhänge: Der erste Anhang beschreibt mögliche technische Stolperfallen in der Benutzung von Game Maker und wie diese umgangen werden können. Der zweite Anhang beschreibt die im Zuge dieses Praktikums erstellten und gesammelten Materialen, die Schülern wie Lehrern sowohl das Verständnis des hier vorgestellten Konzepts als auch die Erweiterung ihrer eigenen Projekte erleichtern sollen.

Context and Motivation: Software users naturally make statements about new software and existing software on online platforms. Developers need to analyze these statements to better understand the users’ requirements, needs and frustrations. For this, the TORE-Framework can be used. Developers can thus better respond to the requirements of users. Based on TORE, certain text segments of the statements are classified into various software aspects. To facilitate this analysis of statements, tools developed for natural language coding can be used. A tool specially developed for this encoding with TORE is Feed.UVL. Feed.UVL is a coding tool, that allows coders to manually code text segments with word- and TORE-codes. This manual approach is very fine-grained and can therefor result in a time-consuming process. To speed up and improve the coding process in Feed.UVL, targeted functionalities, specifically for this very fine grained coding, need to be developed.
Contributions: This work contains three main contributions. Firstly, Feed.UVL is extended with new functionalities. These functionalities accelerate the code assignment process, create a better overview in the underlying dataset, and improve the administration of TORE-codes. Secondly, existing functionalities in Feed.UVL are adjusted. This improves performance in terms of the code assignment process and ensures an improved overview of possible TOREcodes during the code assignment process. Thirdly, errors and potential sources of errors are fixed, making certain functions reusable and protecting users from making mistakes. Results: The coders now have the option to receive recommendations for category-codes during the code assignment process for a code, which significantly speeds up the process and is based
on experiences from past code assignments. The recommendations can be updated as desired. Additionally, Feed.UVL now has the function to highlight tokens, that have been assigned to certain category-codes. Each annotation now has its own list of category-codes, ensuring that coders are not shown irrelevant category-codes during the code assignment process. The category-codes in the list can now also be renamed, in addition to being deleted or created. In addition to these new functions, the performance when opening the code assignment dialog is improved, and the category-code list in the dialog now shows all possible category-codes. The quality of the described functionalities has been ensured through intensive testing. Additionally, the new functionalities were evaluated with a survey based on the Technology Acceptance Model (TAM).

Es fehlt eine gemeinsame Sprache von NutzerInnen, EntwicklerInnen und Herstellern für die Außensicht auf Software, die beschreibt was die Software für NutzerInnen leistet. Dies beeinträchtigt letztendlich die Herstellung von Nutzer-gerechter Software und die Effektivität der Nutzung von Software. Es ist deshalb wichtig, die Konzepte dieser Außensicht zu erforschen, in einer Ontologie zu bündeln, und diese zur Unterstützung der NutzerInnen einzusetzen. Zur Analyse solcher Konzepte in großen Datensätzen, wie sie zum Beispiel beim Crowd-Sourcing oder größeren Interviewstudien erzeugt werden, bedarf es technologischer Unterstützung. Ein Weg der Konzept-Gewinnung aus größeren Datensätzen ist beispielsweise die Verwendung von NLP-Methoden wie POS-Tagging in Kombination mit unter anderem Frequency Analysis. Ob sich diese Methoden für die Gewinnung von UVL-Relevanten Konzepten anwenden lassen, soll dieses Praktikum herausfinden.

Zur Dokumentation und Verwaltung von Entscheidungswissen stehen die am Lehrstuhl für Software Engineering entwickelten ConDec-Plug-ins für das Issue Tracking System Atlassian Jira, die Entwicklungsumgebung (IDE) Eclipse sowie weitere bei der Entwicklung von Software häufig verwendete Tools (Atlassian Confluence, Slack, Atlassian Bitbucket ) zur Verfügung. Sie erlauben die Dokumentation von Entscheidungswissen an verschiedenen Orten wie in eigenständigen Issues oder in Beschreibungstexten oder Kommentaren anderer Issues in Jira, aber auch in Code-Kommentaren oder Commit-Nachrichten des Versionskontrollsystems git. Das auf diese Weise dokumentierte Entscheidungswissen kann gemeinsam mit anderen Wissenselementen wie Anforderungen, Entwicklungsaufgaben oder Code auf verschiedene Arten visualisiert werden, wozu alle Wissenselemente in eine Graphstruktur innerhalb des ConDec-Jira-Plug-ins eingelesen und dort geeignet verlinkt werden. Jedoch ist das Auslesen und Verlinken von Codedateien sowie dem Entscheidungswissen aus Code-Kommentaren bisher nur ansatzweise implementiert und bietet Raum für Verbesserungen und Erweiterungen. In diesem Praktikum wurden die ConDec-Plug-ins in diesem Bereich um Funktionalitäten erweitert.

Developing high-quality software in an agile setting presents many challenges. One of them is how a system testing process can be implemented so it is not an impediment to developers’ progress, but rather a helpful tool in the development process. In this project, we present a system testing strategy for the ConDec Jira plugin project. A test plan was created on the basis of the IEEE-829 standard, and adapted for the agile nature of the project. An approach favoring test automation, but also allowing manual test execution was used. A repository of automated tests was created, and is kept separate from the plugin code. This gives the developers testing their software a high degree of flexibility in test execution, and enables them to extend the tests easily when new features are implemented. Documentation of test specifications and executions are managed in Jira using a plugin called XRay. This enables non-intrusive documentation of testing activities, by integrating with existing documentation processes in Jira.

Das Praktikum beschäftigte sich mit der Frage, wie EntwicklerInnen und Rationale- ManagerInnen besser bei Ihrer Arbeit, mithilfe des ConDec-Confluence Plugins, unterstützt werden können. Auf der Grundlage der in der Ausschreibung beschriebenen Grobanforderungen, sowie aus eigenen Überlegungen, wurde das ConDec-Confluence Plugin dahingehend verbessert, dass es die Rationale-ManagerInnen beim Import von Entscheidungswissen besser unterstützt dasjenige Entscheidungswissen zu importieren, das für ein Meeting relevant ist. Umgesetzt wurde dies durch die Implementierung weiterer Filteroptionen für den Import. Die EntwicklerInnen werden bei der gemeinsamen Entscheidungsfindung sowie bei der Präsentation der getroffenen Entscheidungen durch eine verbesserte Oberfläche der Stand-Up-Tabelle unterstützt. Diese Verbesserung des Plugins wurde dadurch umgesetzt, dass die importierten Entscheidungswissens-Elemente nach ihrem Zustand eingefärbt werden und weitere Eigenschaften dieser Elemente dargestellt werden. Darüber hinaus wurde das weiterentwickelte Plugin mithilfe eines Fragebogens, der von EntwicklerInnen, die im Umgang mit dem Plugin vertraut sind, beantwortet wurde, evaluiert.

Um Entscheidungen während der Softwareentwicklung systematisch zu dokumentieren, unterstützt das Jira-ConDec-Plug-In EntwicklerInnen bei der Verwaltung von Entscheidungswissen. Damit EntwicklerInnen in Slack über Entscheidungen automatisch informiert werden können, erweitert diese Arbeit das Jira-ConDec-Plug-In und die Slack-ConDec-App um einen Webhook. Der Webhook gibt neu dokumentiertes Entscheidungswissen oder Änderungen an bereits dokumentiertem Entscheidungswissen an Slack weiter. In Slack wird das neue oder geänderte Entscheidungswissen in einem Slack-Channel angezeigt und EntwicklerInnen können nach Jira navigieren. So werden EntwicklerInnen über Entscheidungen und offene Entscheidungsprobleme auf dem Laufendem gehalten.

Um Code verstehen und evolvieren zu können, benötigen EntwicklerInnen Entscheidungswissen über diesen Code sowie Wissen zu den dazugehörigen Anforderungen. Dabei kann kann die Visualisierung des Wissens zu Code hilfreich sein. Das am Lehrstuhl entwickelte ConDec-Eclipse-Plug-In soll es EntwicklerInnen ermöglichen, sich Entscheidungswissen, Commits und Jira-Issues wie Anforderungen und Entwicklungsaufgaben im Zusammenhang zu Code ansehen zu können und die Dokumentation zu verwalten. Das Ziel dieses Praktikums ist die Erweiterung des ConDec-Eclipse-Plug-Ins zur verbesserten Visualisierung von Wissen zu Code, insbesondere auch zu Code-Änderungen, sowie zur Schaffung von Verwaltungsmöglichkeiten des dokumentierten Wissens.

Zur Unterstützung von Software-Engineering-Aktivitäten verwenden die meisten Softwareunternehmen und Open-Source-Projekte eine Kombination aus Issue-Tracking-System (ITS) wie beispielsweise Jira, sowie ein Versionskontrollsystem (VCS) wie etwa git. Entsprechend sind auch die Informationen zu Features einer Software über beide Systeme verteilt. Deshalb werden Artefakte, die zu einem Feature gehören, in beiden Systemen mit demselben Feature-Tag gekennzeichnet. Jedoch vergeben Entwickler:innen Feature-Tags nicht immer vollständig oder korrekt. Dies kann dazu führen, dass relevantes Featurewissen für weitere Tätigkeiten innerhalb der Softwareentwicklung nicht genutzt werden kann. Die bisherige Werkzeugunterstützung zeigt für jede Codedatei, in der Featurewissen fehlt, eine Meldung mithilfe eines „Markers“ an. Es enthält außerdem ein Empfehlungssystem, das auf der Grundlage der Ähnlichkeit zwischen Codedateien Feature-Tags für eine Codedatei vorschlägt. Im Praktikum wurde die bestehende Werkzeugunterstützung um Misleading Feature Tag Marker erweitert, die einen möglicherweise irreführenden Feature-Tag markieren, wenn dieser von dem Vorschlag des Empfehlungssystems abweicht. Die verschiedenen Feature-Tag-Marker wurden um Quick-Fixes ergänzt, die in einem Codeartefakt neue Feature-Tags hinzufügen sowie bestehende Feature-Tags entfernen oder ersetzen. Mithilfe von Komponenten- und Systemtests wurde die Korrektheit der Implementierung untersucht. Auch die Erfüllung nichtfunktionaler Anforderungen wurde geprüft. Das Empfehlungssystem wurde dahingehend erweitert, dass auch die Ähnlichkeit zwischen Featurebeschreibungen und Codeartefakten in die Generierung von Vorschlägen für Feature-Tags einfließt. Zur Bestimmung der Ähnlichkeit wurde das Tf-Idf-Maß verwendet. Die Erweiterung des Empfehlungssystems wurde anhand eines Beispielprojekts evaluiert. Hierbei wurden die Verbesserungen im Vergleich zum bisherigen System deutlich.

Während des Softwareenwicklungsprozesses müssen EntwicklerInnen eine Vielzahl an Entscheidungen treffen. Diese Entscheidungen können sich auf verschiedenste Teile des Prozesses beziehen. Das hierbei erzeugte Wissen wird Entscheidungswissen genannt. Neben der Entscheidung ist es für EntwicklerInnen auch wichtig das Entscheidungsproblem, das hinter der Entscheidung steht, sowie alternative Lösungsmöglichkeiten und Argumente bzw. Begründungen zu kennen. Studien haben gezeigt, dass EntwicklerInnen Entscheidungswissen häufig nicht explizit dokumentieren. Es ist stattdessen nur implizit in Kommunikationsartefakten vorhanden. Als Grund für dieses Phänomen gilt das capture problem. Das Problem beschreibt, dass der kurzfristige Nutzen, den einE EntwicklerIn aus der expliziten Dokumentation zieht gering, der Aufwand jedoch relativ dazu gesehen hoch ist. Um implizites Entscheidungswissen explizit zu machen wird maschinelles Lernen genutzt. Durch eine Literaturrecherche werden verschiedene Ansätze der automatischen Klassifizierung von Entscheidungswissen verglichen. Die Erkenntnisse werden dann in Experimenten geprüft und erweitert. Die Erkenntnisse aus den Experimenten fließen dann in die programmatische Umsetzung in dem Entscheidungsdokumentationstool ConDec für JIRA ein. Zusätzlich werden Git-Commit-Nachrichten als weitere mögliche Quelle für Entscheidungswissen in das Tool integriert. Die Umsetzung wird nach dem Technology-Acceptance-Model durch ConDec-EntwicklerInnen evaluiert. Die Entscheidungsdokumentation kann durch die automatische Klassifizierung von Entscheidungselementen verbessert werden. Implizites Wissen wird explizit und kann somit genutzt werden. Die Integration von Git-Commit-Nachrichten als weitere Wissensquelle erlaubt EntwicklerInnen die Dokumentation von Entscheidungswissen ohne einen Kontextwechsel und senkt somit den Aufwand der Dokumentation.

Zur Unterstützung von Software Engineering Aktivitäten verwenden die meisten Softwareunternehmen und Open-Source Projekte eine Kombination aus Issue-Tracking System (ITS) wie z.B. Jira1 und ein Versionskontrollsystem (VCS) z.B. git2 Da die Informationen über beide Systeme verteilt sind, z.B. Anforderungsdokumente im ITS und Code im VCS, sind die Features einer Software nicht mehr gut nachvollziehbar. Im Kontext dieses Praktikums ist ein Feature eine Bündelung von Software Engineering Artefakten (Requirements, Design, Work-Items und Code), die zusammengenommen eine Funktionalität spezifizieren und implementieren. Artefakte, die zu einem Feature gehören, werden mit demselben Feature-Tag gekennzeichnet. In Jira werden die Feature-Tags in Form von Labels vergeben. Im Code werden die Feature-Tags in Form von Annotationen vergeben.
Jedoch dokumentieren EntwicklerInnen das Feature-Wissen in Issues und Code nicht immer konsequent und kontinuierlich. Dies kann dazu führen, dass relevantes Feature-Wissen für weitere Tätigkeiten innerhalb der Softwareentwicklung nicht genutzt werden kann. Im Rahmen dieses Praktikums wird daher sowohl ein Plug-In für Jira als auch ein Plug-In für Eclipse umgesetzt, dass die EntwicklerInnen bei der kontinuierlichen Dokumentation von Feature-Wissen möglichst gut unterstützt.

Zur Unterstützung von Software Engineering Aktivitäten verwenden die meisten Softwareunternehmen und Open-Source Projekte eine Kombination aus Issue-Tracking System (ITS) wie z.B. Jira1 und ein Versionskontrollsystem (VCS) z.B. git2 Da die Informationen über beide Systeme verteilt sind, z.B. Anforderungsdokumente im ITS und Code im VCS, sind die Features einer Software nicht mehr gut nachvollziehbar. Im Kontext dieses Praktikums ist ein Feature eine Bündelung von Software Engineering Artefakten (Requirements, Design, Work-Items und Code), die zusammengenommen eine Funktionalität spezifizieren und implementieren. Artefakte, die zu einem Feature gehören, werden mit demselben Feature-Tag gekennzeichnet. In Jira werden die Feature-Tags in Form von Labels vergeben. Im Code werden die Feature-Tags in Form von Annotationen vergeben.
Jedoch dokumentieren EntwicklerInnen das Feature-Wissen im Code nicht immer konsequent. Dies kann dazu führen, dass relevantes Feature-Wissen für weitere Tätigkeiten innerhalb der Softwareentwicklung nicht genutzt werden kann, z.B. beim Beheben von Fehlern. Im Rahmen dieses Praktikums wird daher ein Plug-In für Eclipse umgesetzt, um Feature-Wissen im Code gezielt aufzufinden.

Ein Problem ist, dass eine strukturierte Dokumentation von wertvollem Entscheidungswissen (EW) häufig nicht in den Prozess der Software Entwicklung integriert ist. Entwickler sehen die Dokumentation von EW als Mehraufwand an und erkennen keine kurzfristigen Nutzen. Daher wird EW häufig nur informell und in natürlicher Sprache diskutiert. Dies geschieht z.B. in Chat-Systemen, in welchem Entscheidungsprobleme gemeinsam diskutiert und gelöst werden. Diese Chat-Systeme wie z.B. Slack sind praktisch, da sie eine einfache Kommunikation ermöglichen und werden auch in Software-Projekten immer beliebter. Dort enthalten Chat-Nachrichten wichtiges EW. Da diese Nachrichten aber in der Regel von kurzlebiger Natur sind, geht dieses Wissen schnell wieder verloren. Ziel dieses Praktikums ist es, Unterstützungen für die Dokumentation und Nutzung von Entscheidungswissen in Slack zu schaffen. Dafür wird eine Slack App namens Slack ConDec entwickelt.

In vielen Software-Entwicklungsprojekten wird der Code in einem Versionskontrollsystem (VCS) wie Git und Anforderungen sowie Entwicklungsaufgaben in einem Issue-Tracking-System (ITS) wie Jira verwaltet. Während EntwicklerInnen an einer Aufgabe arbeiten, fassen sie Änderungen am Code von Zeit zu Zeit zu Commits zusammen. In Commit-Nachrichten ist es üblich Jira-Issue-Keys aus dem ITS anzugeben. Dieser Jira-Issue-Key kann zur Verknüpfung von Anforderungen und Entwicklungsaufgaben im ITS mit dem Code im VCS verwendet werden, d.h. es können Trace Links zwischen Anforderungen und Code hergestellt werden. Ein Problem der Verknüpfung über Commits sind tangled changes. Als tangled changes werden in der Vergangenheit eingebrachte Änderungen im Code bezeichnet, die nicht zu dem in der Commit-Nachricht angegebenen Jira-Issue gehören. Das Ziel dieses Praktikums ist die Erweiterung des ConDec-Jira-Plug-Ins zur Unterstützung der Erkennung von tangled changes, d.h. zur Beurteilung der zu Entwicklungsaufgaben verlinkten Klassen auf Korrektheit der Links.

Zur Unterstützung von Software Engineering Aktivitäten verwenden die meisten Softwareunternehmen und Open-Source Projekte eine Kombination aus Issue-Tracking System (ITS) wie z.B. Jira und ein Versionskontrollsystem (VCS) z.B. git Da die Informationen über beide Systeme verteilt sind, z.B. Anforderungsdokumente im ITS und Code im VCS, sind die Features einer Software nicht mehr gut nachvollziehbar. Im Kontext dieses Praktikums ist ein Feature eine Bündelung von Software Engineering Artefakten (Requirements, Design, Work-Items und Code), die zusammengenommen eine Funktionalität spezifizieren und implementieren. Artefakte, die zu einem Feature gehören, werden mit demselben Feature-Tag gekennzeichnet.
Jira bietet mit der Jira Query Language (JQL) bereits eine mächtige Abfragesprache für Issues. Mit Hilfe von JQL können Abfragen bzgl. der Features allerdings nur sehr umständlich formuliert und durchgeführt werden. Zur leichteren Durchführung von Abfragen bzgl. Features wurde im Rahmen dieses Praktikums eine Feature-Abfragesprache für das Issue Tracking System Jira umgesetzt.

Ein Problem in der Software-Entwicklung ist, dass Entscheidungen und das für ihr Verständnis benötigte Wissen (Entscheidungswissen) nicht allen Projektbeteiligten zugänglich sind. Beispielsweise dokumentieren Entwickler Entscheidungen im Code, aber dieses Wissen ist dann nur ihnen zugänglich. Dies ist in der heutzutage stark verbreiteten agilen Entwicklung kontraproduktiv, da ja auch die Kunden, Architekten und Produkt/ Projekt-Manager die Entscheidungen nachvollziehen wollen. Das ConDec Jira Plugin versucht dieses Problem zu lösen, indem Entscheidungen direkt in Jira dokumentiert und zu Work-Items verlinkt werden. Um dieses dokumentierte Wissen besser zu nutzen, wäre es zum Beispiel hilfreich, wenn das Entscheidungswissen oder (Decision Knowledge, DK) aus Jira in Besprechungen und in Pull-Requests, d.h. bei der Umsetzung von Entwicklungsaufgaben, für die Entwickler einsehbar wäre. Dafür fehlt bisher noch die Anbindung an einige der bekannteren Software-Entwicklungs-Tools wie das WiKi-System Confluence oder das webbasierte Versionsmanagement-Tool BitBucket.

Während der Entwicklung von Software treffen EntwicklerInnen viele Entscheidungen, z.B. hinsichtlich der umzusetzenden Features der Software, den verfeinerten Anforderungen, der Software-Architektur, Implementierung und Qualitätssicherung. Es ist wichtig, dass EntwicklerInnen solche Entscheidungen kommunizieren und dokumentieren, damit (dieselben aber auch zukünftige) EntwicklerInnen die Software gut evolvieren bzw. instand halten können. In vielen Software-Entwicklungsprojekten wird der Code in einem Versionskontrollsystem (VCS) wie Git und Anforderungen sowie Entwicklungsaufgaben in einem Issue-Tracking-System (ITS) wie JIRA verwaltet. Dabei halten EntwicklerInnen auch Informationen über die Features der Software sowie Entscheidungen in diesen beiden Systemen fest. Entscheidungen werden beispielsweise in Issue-Kommentaren und Commit-Nachrichten festgehalten. Die Features werden mit Hilfe von Feature-Tags dokumentiert und nachverfolgt. Anforderungen, Entwicklungsaufgaben und Code, die zu einem Feature gehören, werden mit demselben Feature-Tag gekennzeichnet. Der zugehörige Code und die Feature-Dokumentation werden als Featurewissen bezeichnet.
Um Code verstehen und evolvieren zu können, benötigen EntwicklerInnen somit Feature- und Entscheidungswissen über diesen Code. Insbesondere benötigen sie eine geeignete Visualisierung des Wissens im Zusammenhang zum Code sowie Möglichkeiten diese Visualisierung je nach Anwendungsfall anzupassen. Beispielsweise möchten EntwicklerInnen (in der Rolle einer Feature-ManagerIn) die Features einer Software im Code einsehen können, um Codeteile, die viele Feature umsetzen zu identifizieren. EntwicklerInnen (in der Rolle einer Rationale-ManagerIn) möchten die Entscheidungen, die für die Umsetzung eines Features getroffen wurden, code-nah einsehen können, um zu prüfen, ob diese konsistent mit dem Code sind. Das Ziel dieser Arbeit war es EntwicklerInnen zu ermöglichen, im VCS und ITS festgehaltenes Feature- und Entscheidungswissen ausgehend vom Code zu visualisieren. Dafür wurde ein Prototyp namens „FlAVOreD“ als Eclipse-Plug-In entwickelt.

Während der Implementierung von Software werden zahlreiche Entscheidungen getroffen, beispielsweise dazu, wie ein Algorithmus am effizientesten implementiert werden kann oder wie die Nutzereingabe bestmöglich verarbeitet werden soll. Diese Entscheidungen basieren meist auf einer Gegenüberstellung verschiedener Alternativen, die es anhand unterschiedlicher Kriterien zu bewerten gilt. Für diese Gegenüberstellung sind Expertenmeinungen, persönliche Erfahrungen und der Kontext der Entscheidung wichtig. Das bedeutet, dass komplexes und umfangreiches Wissen notwendig ist, um eine Entscheidung im Nachhinein nachvollziehen zu können. In der Praxis werden Entscheidungen, die während der Implementierung getroffen werden, oft unstrukturiert, gar nicht oder in externen Dokumenten, ohne Verbindung zum Code, dokumentiert. Dies führt zu inkonsistenten Entscheidungen im späteren Entwicklungs- oder Änderungsverlauf, woraus wiederum Qualitätsprobleme resultieren. Es ist also wichtig, dass Entscheidungen während der Implementierung strukturiert und in Verbindung zum Code dokumentiert werden. Eine Möglichkeit dies zu tun, ist es, die Entscheidungen in Commit-Nachrichten in einem Versionskontrollsystem festzuhalten. Um EntwicklerInnen zu motivieren, dies umzusetzen, muss ihnen der Nutzen dahinter klar sein. Das Ziel dieses Projekts ist der Entwurf und die Implementierung eines JIRA-Plug-Ins, das Entscheidungswissen aus Commit-Nachrichten anzeigt, um Entscheidungen, die während der Entwicklung getroffen werden, besser nachvollziehen zu können. Hierzu werden Entscheidungen und die zugehörigen Entscheidungskomponenten mittels Annotationen in Commit-Nachrichten angelegt und anschließend in JIRA visualisiert. Das DecXplore Plug-in zeigt also den Nutzen davon auf, Entscheidungen in Commit-Nachrichten festzuhalten und bietet EntwicklerInnen einen Anreiz diese zu dokumentieren.

Software Development is a delicate process that often requires the use of additional techniques in order to improve development efficiency, quality and maintainability. An example for such a technique is the use of annotations as a form of Feature Tag for different code artefacts. By using a standardized annotation which contains key words that describe the implemented feature for each code file we allow the use of software tools as support during the development process and later maintenance of the source code. The plug-in FEliPE developed during this internship offers such tool support in the form of a new perspective for the integrated development environment (IDE) Eclipse. The perspective offers multiple views that allow the management of artefacts that are equipped with such Feature Tags. Additional capabilities are offered that allow the user to apply Tags to code artefacts for example by using drag and drop functionalities and manage the code files that have not been categorized by Feature Tags. The plug-in thus tackles the problem of the separation of code version control and documentation within a software project. It establishes a clearer bond between the written code and its implemented functionality, which can then be traced back to the design documents thus reducing the distribution of information among the used version control and issue tracking system.

Mobilgeräte wie Smartphones und Tablets sind aus unserem Alltag kaum mehr wegzudenken und ermöglichen es, Anwendungssoftware (Apps) überall einzusetzen. Mit Apps wie Duolingo oder Rosetta Stone kann man so zu jeder Zeit Sprachen lernen. Der Lernende wird bei der Verwendung dieser Apps ständig korrigiert und kann seinen Erfolg selbst evaluieren. Sprachlern-Apps können aber nicht nur von Individuallernenden, sondern auch im Unterricht eingesetzt werden. Dabei kann der Lernerfolg jedes Schülers/jeder Schülerin zentral von dem/der LehrerIn eingesehen und ausgewertet werden, wodurch der Unterricht interaktiv gestaltet werden kann. Darüber hinaus können Sprachlern-Apps Methoden wie den „Flipped Classroom“ bzw. „Flipped Learning“ unterstützen, bei denen die SchülerInnen Lerninhalte zuhause erarbeiten und der Unterricht v.a. dem Anwenden des Gelernten dient.

Das heiEDUCATION Projekt ist ein gemeinsames Projekt der Universität Heidelberg und der Pädagogischen Hochschule Heidelberg. Im Rahmen dieses Projekts soll das Erlernen von Sprache im naturwissenschaftlichen Kontext untersucht werden. Dafür wird im Rahmen dieses Praktikums eine Android App entwickelt, die es ermöglicht naturwissenschaftliche Fachsprache ohne Verwendung der Muttersprache des Lernenden zu vermitteln. Die App soll im Unterricht eingesetzt werden und eine zentrale Auswertungsmöglichkeit durch die Lehrperson unterstützen.

Bei der Entwicklung der App werden Methoden kontinuierlicher Softwareentwicklung eingesetzt, die im Rahmen des DFG-Projekts „Continuous Usage- and Rationale-based Evolution Decision Support“ (CURES) untersucht werden. Dazu zählen u.a. die Entscheidungsdokumentation während der Software-Entwicklung, die Verwendung kleinteiliger „Branches“ beim Einbringen neuer „Features“ im Versionsverwaltungstool, die kontinuierliche Veröffentlichung neuer Software-Versionen sowie das Auswerten von Nutzermeinung bzw. –erfahrung im Umgang mit der Software. Diese Methoden sollen zur kontinuierlichen Weiterentwicklung und Verbesserung der Software beitragen.

Zur Unterstützung von Software Engineering Aktivitäten verwenden die meisten Softwareunternehmen und Open-Source Projekte eine Kombination aus Issue-Tracking System (ITS) wie z.B. JIRA und ein Versionskontrollsystem (VCS) z.B. git. Da die Informationen über beide Systeme verteilt sind, z.B. Anforderungsdokumente im ITS und Code im VCS, sind die Features einer Software nicht mehr gut nachvollziehbar. Im Kontext dieses Praktikums ist ein Feature eine Bündelung von Software Engineering Artefakten (Requirements, Design, Work-Items und Code), die zusammengenommen eine Funktionalität spezifizieren und implementieren. Artefakte, die zu einem Feature gehören, werden mit demselben Feature-Tag gekennzeichnet. EntwicklerInnen müssen den Feature-Tag kennen um den Code dem/n relevanten Feature/s zuordnen zu können. Um die Vergabe von Feature-Tags im Code zu vereinfachen, wurden im Rahmen dieses Praktikums Feature-Tag-Vorschläge in Abhängigkeit des Kontexts generiert und den EntwicklerInnen in der Entwicklungsumgebung Eclipse angeboten werden (ähnlich zur Java-Codevervollständigung).

Das Dokumentations-Tool Confluence wird in vielen Software-Entwicklungspro-jekten eingesetzt um das Design sowie Projektspezifikation und -dokumentation festzuhalten.
Entscheidungen die während des Design- und Spezifikationsprozesses getroffen werden sind ein enorm wichtiger Bestandteil eines jeden Projekts und werden oft nicht ausreichend dokumentiert, da der zusätzliche Aufwand als verhältnismäßig zu hoch erachtet wird.
Um den Dokumentationsaufwand solcher Entscheidungen in Confluence zu min-imieren soll die Dokumentation von Entscheidungen in Confluence durch ein Plugin unterstützt werden.
Ziel dieses Fortgeschrittenenpraktikums war es ein Software-Plugin für Confluence zu entwickeln, welches dem Nutzer eine inkrementelle Bearbeitung, verteilte Doku-mentation von Entscheidungen, sowie eine Verbindung von Anforderungs- bzw. Implementierungsentscheidungen zum Fehlerverwaltungs- und Projektmanagementtool JIRA ermöglicht.

Das Fehlerverwaltungs- und Projektmanagementtool JIRA wird vermehrt in Software-Entwicklungsprojekten eingesetzt um die Entwicklungsarbeit durch Issues zu planen und zu dokumentieren. Ein bedeutender Teil der Arbeit an solch einem Projekt ist die Dokumentation von Entscheidungen. Der zusätzliche Aufwand der durch die Dokumentation entsteht, soll so gering wie möglich gehalten werden. Um dies zu erreichen soll die Dokumentation von Entscheidungen in JIRA integriert und durch ein Plugin unterstütz werden.
Im Rahmen dieses Fortgeschrittenenpraktikums wird ein Software-Plugin für JIRA entwickelt, welches den Nutzer der Software bei der Dokumentierung von Entscheidungen unterstützen soll. Dies geschieht auf Basis der Literatur zum Management von Entscheidungswissen und der Analyse der bestehenden Dokumentationsmodelle von JIRA und UNICASE DecDoc.

Interaction data created during software development contains information about a developers workflow. The Eclipse plug-in Mylyn records interaction data between code and documented tasks to optimize the User Interface. Extending this functionality to also record interactions between parts of the documentation may lead to a better understanding of the projects structure and further optimizations. The plug-in Mytrace, which was developed over the course of this internship, records this information for all parts of the documentation available as Mylyn issues.

Zur Unterstützung von Software Engineering Aktivitäten verwenden die meisten Softwareunternehmen und Open-Source Projekte eine Kombination aus Issue-Tracking System (ITS) wie z.B. Jira1 und Versionskontrollsystem (VCS) z.B. git2. Da die Informationen über beide Systeme verteilt sind, z.B. Anforderungsdokumente im ITS und Code im Versionskontrollsystemen (VCS), sind die Features einer Software nicht mehr gut nachvollziehbar. Um einen Überblick über die Features im ITS und im VCS zu bekommen und um die Suche nach bestimmten Features zu vereinfachen, sind eine Visualisierung von Feature-relevanten Informationen und eine Navigation zwischen den Artefakten eines Features erforderlich. Zur Visualisierung und Navigation kann ein Dashboard verwendet werden. Ein Dashboard ist eine Software zur Visualisierung von Informationen in verdichteter Form. Es existieren bereits Frameworks, die bei der Erstellung von Dashboards helfen. Ziel dieses Praktikums war es, einen Dashboard-Prototyp namens FloRIDA für das ITS Jira umzusetzen. FloRIDA dient zum Darstellen von Feature-relevanten Informationen und zur Navigation zwischen den Artefakten innerhalb einzelner Features.

Das Strukturieren und Festhalten von Entscheidungswissen ist bei der Durchführung
von Softwareprojekten äußerst lohnenswert. Unter anderem muss dieses Wissen durch die Entwickler dafür in geeigneter Form dokumentiert und zugeordnet werden. Wichtig ist hierbei, diese Anfangsinvestitionen zu verringern.

Dabei ist der Einsatz von angepassten Werkzeugen äußerst hilfreich. Ein solches wurde im Rahmen des Praktikums erstellt. Es stellt eine grafische Oberfläche mit genau definierten Modellierungs-Elementen bereit, welche das Festhalten des Entscheidungswissens vereinfachen und dabei Fehler verhindern.

Dieser Bericht enthält die Konzeption und Realisierung einer domänenspezifischen Sprache, die hilft das oben genannte Ziel zu erreichen. Weiter wird die Umsetzung der Sprache mit Verwendung der ADOxx-Plattform unter Berücksichtigung deren Besonderheiten beschrieben. Die Tests der Funktionalitäten und der Modellierungsfähigkeiten
des Werkzeugs werden offengelegt. Abschließend werden die wichtigsten Erkenntnisse zusammengefasst und ein Ausblick gegeben, sowie Erfahrungen aus dem Praktikum dargelegt.

Steigende Komplexität in der Entwicklung von Software sowie häufige Änderungsbedürfnisse verlangen nach der Möglichkeit, alle anfallenden Projekt-Artefakte wie Anforderungen, Software-Architektur-Modelle, Quellcode und Testfälle verfolgen zu können. Die Methoden der Nachverfolgbarkeit (Traceability) stellen Verfahren zur Verfügung, Relationen (Trace-Links) zwischen Artefakten über den gesamten Entwicklungsprozess hin zu erzeugen.Das auf dem Eclipse Modeling Framework (EMF) basierende CASE-Tool UNICASE unterstützt die Nachverfolgbarkeit von Softwareprojekt-Artefakten. Dabei sind die Trace-Links über fest definierte Assoziationen in das zugrundeliegende Modell von UNICASE integriert. Jedoch ist es bisher weder möglich Artefakte flexibel miteinander zu verlinken (generisch) wenn diese nicht durch vorher definierte Assoziation miteinander verbunden sind, noch können die Trace-Links mit weiteren Informationen wie z.B. Status oder Version angereichert werden.Zum Darstellen und Modifizieren von Artefakten und deren Trace-Links nutzt UNICASE die EMF Client Platform (ECP). ECP ist ein Framework zum Erstellen von EMF-basierten Client-Anwendungen. Ziel des ECP Frameworks ist es, wiederverwendbare, anpassungsfähige und erweiterbare Komponenten für die Benutzeroberfläche, die auf einem zuvor festgelegten EMF-Modell basieren, zu entwickeln. Um generische Trace-Links in UNICASE mit Hinblick auf Benutzbarkeit unterstützen zu können, müssen entweder relevante Teile von ECP selbst oder deren Oberflächenkomponenten angepasst werden.

Steigende Komplexität in der Entwicklung von Software sowie häufige Änderungsbedürfnisse verlangen nach der Möglichkeit, alle anfallenden Projekt-Artefakte wie Anforderungen, Software-Architektur-Modelle, Quellcode und Testfälle verfolgen zu können. Die Methoden der Nachverfolgbarkeit (Traceability) stellen Verfahren zur Verfügung, Beziehungen (Trace-Links) zwischen Artefakten über den gesamten Entwicklungsprozess hin zu erzeugen. Das auf dem Eclipse Modeling Framework (EMF) basierende CASE-Tool UNICASE unterstützt die Nachverfolgbarkeit zwischen allen Softwareprojekt-Artefakten. Zum Darstellen und Modifizieren von Artefakten und deren Trace-Links nutzt UNICASE die EMF Client Platform (ECP). ECP ist ein Framework zum Erstellen von EMF-basierten Client-Anwendungen. Ziel des ECP Frameworks ist es, wiederverwendbare, anpassungsfähige und erweiterbare Komponenten für die Benutzeroberfläche, die auf einem zuvor festgelegten EMF-Modell basieren, zu entwickeln. Um die Nachverfolgbarkeit zwischen Artefakten besser verstehen zu können, könnten Schlagwörter (Tags) an den Artefakten und den Trace-Links versehen und analysiert werden. Beim Tagging reichern NutzerInnen die Artefakte mit selbstgewählten Wörtern an um letztendlich eigene Kategorien von Artefakten bzw. Beziehungen zu bilden. Wurden Artefakte und Trace-Links mit Tags versehen, können der NutzerIn mit Hilfe eines Empfehlungssystems vorhandene Tags vorgeschlagen werden. Jedoch bietet UNICASE bislang weder die Möglichkeit Tags zu vergeben noch vorhandene Tags vorzuschlagen.

Innerhalb des DFG-Projektes Semantisches Netz des Informationsmanagements im Krankenhaus (SNIK) wird unter anderem eine auf einem semantischen Netz basierende entscheidungsunterstützende Software CIO-Navigator (CION) für Krankenhaus-CIOs entwickelt. Erste Anforderungen sind unter anderem als Virtual Windows nach Lauesen dokumentiert, die für die Bearbeitung von Aufgaben relevanten und zusammenhängenden Daten darstellt. Ausgehend von Virtual Windows können UI Prototypen erstellt werden.
Bei einer bereits durchgeführten Systemanalyse eines großen Klinikums, wurden die im IM existierenden Aufgaben, Objekttypen und Werkzeuge identifiziert. Dabei zeigt sich, dass Microsoft SharePoint Server ein häufig verwendetes Werkzeug ist und zahlreiche relevante Informationen enthält.

Das Ziel dieses Praktikums ist es, das Virtual Window Projektstatus und Krankenhausziele als Erweiterung des Microsoft SharePoint Servers zu implementieren. Das Virtual Window zeigt den Beitrag einzelner Projekte zu strategischen Krankenhauszielen und den Projektfortschritt bzw. Status. Die dazu notwendigen Daten sollen aus zwei unterschiedlichen Datenquellen entnommen werden. Die strategischen Datenquellen liegen in einem Dokument (z.B. Word oder OpenOffice Format) und die Informationen über Projekte stammen aus einer einfachen Datenbank. Der Zugriff auf Daten muss so gekapselt sein, dass ein Austausch der Quellen nur Anpassungen in der Zugriffsschicht (DataAccess Layer) nach sich zieht.

Steigende Komplexität in Software und häufige Änderungsbedürfnisse verlangen nach der Möglichkeit, Anforderungen zu Entwicklungsartefakten wie Dokumente, Software-Architektur-Modelle, Quellcode und Testfälle verfolgen zu können. Die Methoden der Verfolgbarkeit (Traceability) stellen Verfahren zur Verfügung, Relationen zwischen Artefakten durch den gesamten Entwicklungsprozess hin zu erzeugen.
Gängige CASE-Tools (Computer Aided Software Engineering) unterstützen diese Verlinkung mehr oder weniger gut. Insbesondere im Bereich von UML-Modellen gibt es abseits der modellgetriebenen Architektur (MDA) wenig bis keine Unterstützung.
Das Ziel dieses Praktikums ist die Beschreibung der gängigen Verfahren zur Herstellung von Verfolgbarkeit zu Architektur-Elementen in Form von UML Modellen und einen Vergleich der Unterstützung für Traceability bei UML Modellen durch gängige CASE-Tools.

Der/die PraktikantIn hat dabei folgende Aufgaben:
-    Grundlagen und Literaturrecherche zur Identifikation von bestehenden Studien und Werkzeugvergleichen. Insbesondere kann der Incose-Vergleich relevant sein.
-    Definition der Kriterien zum Werkzeugvergleich ausgehend von der gefundenen Literatur in Abstimmung mit der BetreuerIn
-    Definition der zu untersuchende Werkzeuge in Abstimmung mit der BetreuerIn
-    Durchführung des Werkzeugvergleichs und Dokumentation der Ergebnisse
-    Erstellung eines Berichts und Präsentation der Ergebnisse
Die erwarteten Ergebnisse können in 3 Arbeitspakete (AP) eingeteilt werden. Eine Projektplanung ist von der/dem Studierenden zu Beginn der Arbeit vorzunehmen und im Laufe des Projekts aktuell zu halten (siehe Abschnitt "Arbeitsaufwand und Zeitplan").
 

In einem Software-Projekt werden zwecks der Dokumentation eine große Anzahl von Daten archiviert. Während des Entwicklungsprozesses werden Versionierungsprogramme genutzt, um diese Daten zu speichern. Diese Daten können gezielt mit Analysetechniken ausgewertet werden, um Aufälligkeiten, insbesondere Features, eines Software-Projektes zu erkennen. Das Ermitteln von Features ist hilfreich, um sich eine Übersicht über die Funktionalitäten einer Software zu verschaffen. Dazu zählen bereits vorhandene Features, die Beziehungen verschiedener Features zueinander, in welcher Vielfalt und Anzahl sie eventuell vorkommen, oder ob Features fehlen.
Das Ziel des Praktikums ist hierbei das Erstellen einer API, zum Einlesen und Analysieren von Crawl-Daten, die zur Ermittelung von relevanten Feature-Daten dient.

Das CASE-Werkzeug UNICASE integriert modellbasiert die Daten von unterschiedlichen Aktivitäten der Softwareentwicklung. UNICASE ermöglicht u.a. das Erfassen von Anforderungen, das Erstellen von UML-Modellen und unterstützt das Projektmanagement. Neben den klassischen Vorgehensmodellen wie dem V-Modell oder dem Rational Unified Process erfreuen sich agile Vorgehensmethoden in der Softwareentwicklung immer größerer Beliebtheit. Zu den bekanntesten Vertretern zählt unter anderem Scrum. Scrum ist ein Vorgehens-Framework für das Projektmanagement im agilen Umfeld. Scrum wird als Framework und bewusst nicht als Vorgehensmodell bezeichnet, da es nur aus wenigen Regeln besteht. Diese Regeln definieren fünf Aktivitäten, drei Artefakte und drei Rollen, die den Kern von Scrum ausmachen und sind im ScrumGuide von Ken Schwaber und Jeff Sutherland - den Erfindern von Scrum - hinterlegt.Mit der bisherigen Funktionalität des Projektmanagements lässt sich jedoch nur bedingt Scrum betreiben, da es UNICASE an entsprechenden Modellelementen wie beispielsweise dem ProductBackLog, den entsprechenden Rollen und Aktivitäten etc. fehlt. Scrum-Elemente werden in UNICASE nur teilweise in Form von Sprints bereitgestellt. Ziel dieses Praktikums ist daher die Konzeption und Entwicklung eines Scrum-Plug-Ins für UNICASE.

Entscheidungen sind im Entwicklungsprozess einer Software tagtäglich anzutreffen. Besonders Requirements Engineers und Softarearchitekten treffen im Softwareentwurf früh Entscheidungen, die sich massiv auf das spätere Produkt auswirken. Damit dieses Entscheidungswissen nicht im Laufe der Zeit verloren geht, stellt dieser Bericht eine Möglichkeit vor, das Wissen einfach und ohne Unterbrechung während des Softwareentwurfs strukturiert zu erfassen und zu überblicken.

Das Ziel des Praktikums ist eine integrierte Werkzeugunterstützung für das CASE-basierte Werkzeug UNICASE, da dieser Arbeitsablauf bisher in UNICASE nur über den Standardeditor möglich ist. Der Umweg Entscheidungen über den Standardeditor zu erfassen stellt eine erhebliche Unterbrechung des Arbeitsablaufs dar und bedarf somit weiterer Überarbeitung.

Das Ziel dieses Projekts ist es, eine erweiterte View des Decision Editors für die Visualisierung der Historie und damit den Änderungsverlauf von Attributen und Wissenselementen dokumentierter Entscheidungen in UNICASE und der basierenden Eclipse Modeling Framework (EMF) zu entwickeln. Hierzu sollen die ausgewählten Attribute aus dem ChangeSet des EMFStore extrahiert und grafisch in geeigneten Diagrammen aufbereitet werden.

Im Zuge dieses Projekts wurde ein UNICASE Plugin entwickelt, welches bereits dokumentierte Entscheidungen eines Projektes rekursiv bestimmt und anschließend deren Änderungsverlauf mithilfe von Tabellen, Balken- und Kuchendiagramme sowie Zeitdiagramme für den Status der Implementierung und des Fortschritts visualisiert. Mithilfe von Filter- und Auswahlfunktionen können die BenutzerInnen die erwünschten Attribute selektieren und somit einen spezifischen Überblick der Historie einer dokumentierten Entscheidung erhalten.

In diesem Bericht werden die Vorgehensweise der Planung als auch die Implementierung sowie die Evaluationsergebnisse vorgestellt.

Barbara Paech

Alexander Brändlein, Christiane Smandzik

Ziel dieses Projektes ist die Nutzbarmachung des vergleichsweise kostengünstigen Nintendo-Wii Spielkonsolencontrollers für den Einsatz im Unterricht. Die interessante Fragestellung und die Gelegenheit direkt für den praktischen Einsatz im Schulbetrieb verwendbare Software zu entwickeln gab bei uns den Ausschlag, sich diesem Projekt anzunehmen.
Die Aufgabe des zu entwickelnden Programmes ist die Erfassung, Aufarbeitung und Darstellung von Beschleunigungsdaten, die mit Hilfe der Wii-Remote ermittelt werden. Im Weiteren soll die Software den Export der Daten in ein beliebiges gängiges Tabellenkalkulationsprogramm anbieten. Dabei war darauf zu achten, dass das Programm plattformunabhängig, Modular erweiterbar und klar strukturiert ist.
Im Anhang dieses Berichtes befinden sich Entwürfe, die die Einsatzmöglichkeiten dieses Programmes beispielhaft darstellen. Primäres Ziel ist der Einsatz im Physikunterricht, die Verwendung in anderen Fächern ist ebenso möglich. Um dies zu verdeutlichen haben wir im Anhang neben zwei Versuche für das Fach Physik, einen weiteres Beispiel für den Einsatz der Wii-Remote im Sportunterricht beschrieben.
Um den zukünftigen Nutzern den Einstieg in die Thematik zu erleichtern, haben wir ein Tutorial verfasst, in dem wir auf die Funktion der Wii-Remote und die Benutzung des Programmes eingehen. Im Weiteren bietet das Tutorial auch tiefergehende Informationen zu der Wii-Remote an sich und zu der Kommunikation zwischen Wii-Remote und PC, sodass hiermit eine Weiterentwicklung des Programmes erleichtert wird.
In diesem Bericht beschreiben wir unser Herangehen an die Problematik und den Entwurf unseres Programmes.

UNICASE ist ein CASE-Tool, mit welchem die TeilnehmerInnen eines Softwareentwicklungsprozesses die entstehenden Artefakte dokumentieren können, wie z.B. Anforderungen oder Projektplanung. UNICASE ist der Nachfolger von Sysiphus. Das CASE-Tool basiert auf der Eclipse-Plattform und nutzt viele seiner Konzepte, wie z.B. das Plug-In-Konzept.

Es bestand bereits eine einfache Benutzeroberfläche für die Spezifikation von Testfällen in UNICASE. Bisher wurden alle notwendigen Informationen zu einem Testfall in einfachen Textfeldern gespeichert, wie z.B. die Input- bzw. Outputparameter. Dies hatte erhebliche Nachteile, z.B. in der Benutzbarkeit.

Ziel dieser Arbeit war es, die bestehende Benutzeroberfläche für die Spezifikation von Testfällen zu erweitern. Es sollte möglich sein, komplexere Elemente darzustellen, wie z.B. Tabellen. Hierfür mussten neue Komponenten erstellt werden, um diese Elemente in die Benutzeroberfläche von UNICASE zu integrieren.

1. dass bestehende Ansätze kein Dialogmodell verwenden.
2. dass es möglich ist mit einem einzigen Dialogmodell mehrere Benutzungs-schnittstellen für verschiedene Plattformen (Desktop und Handy) zu entwickeln.

• Spezifikation der Anforderungen an diese Sysiphus-Erweiterung
• Entwurf und Implementierung
• Test und Dokumentation dieser Tests
• Erstellen eines kurzen Benutzerhandbuch

Das Ziel des Praktikums ist eine Untersuchung des Einflusses  von „Bad Smells“, die auf einer Kombination von Metriken basieren, auf die Fehleranfälligkeit mit Hilfe eines Open-Source-Werkzeug zur strukturellen Untersuchung und Bewertung der inneren Qualität von Software-Systemen (SISSY). Während des Projektes sollen sowohl neue „Detection Strategies“, als auch neue „Bad Smells“ ausgewählt und in SISSY implementiert werden. Dann sollen die Zusammenhänge zu den Korrelationen zwischen „Bad Smells“ und Fehlern in der SW analysiert werden.
Durch die statistische Analyse unterschiedlicher Open-Source-Programme sollen folgende Hypothesen geprüft werden:

• H1: „Bad Smells“ wirken sich positiv auf die Fehleranfälligkeit eines Files aus
• H2: Es gibt eine Teilmenge von Bad Smells, die sich über mehrere Versionen hinweg auf die Fehleranfälligkeit auswirken. (Z.B. Über mehrere Versionen hinweg sind Files, die zyklische Abhängigkeiten aufweisen fehleranfälliger als andere)
• H3: Bad Smells sind bessere Indikatoren für Fehleranfälligkeit als Komplexitätsmetriken

• die Analyse der möglichen Such- und Filterkriterien und die entsprechende Kombination aus den entsprechenden Kriterien durch eigene Überlegungen und durch Befragung der Benutzer des Systems
• die Spezifikation der zu implementierenden Such- und Filterfunktionalität und deren Einbettung in das bestehende System
• Erstellung und Realisierung des Entwurfs
• Ausführen der notwendigen QS-Maßnahmen