@phdthesis{Dietze2004, author = {Dietze, Stefan}, title = {Modell und Optimierungsansatz f{\"u}r Open Source Softwareentwicklungsprozesse}, url = {http://nbn-resolving.de/urn:nbn:de:kobv:517-0001594}, school = {Universit{\"a}t Potsdam}, year = {2004}, abstract = {Gerade in den letzten Jahren erfuhr Open Source Software (OSS) eine zunehmende Verbreitung und Popularit{\"a}t und hat sich in verschiedenen Anwendungsdom{\"a}nen etabliert. Die Prozesse, welche sich im Kontext der OSS-Entwicklung (auch: OSSD \– Open Source Software-Development) evolution{\"a}r herausgebildet haben, weisen in den verschiedenen OSS-Entwicklungsprojekten z.T. {\"a}hnliche Eigenschaften und Strukturen auf und auch die involvierten Entit{\"a}ten, wie z.B. Artefakte, Rollen oder Software-Werkzeuge sind weitgehend miteinander vergleichbar. Dies motiviert den Gedanken, ein verallgemeinerbares Modell zu entwickeln, welches die generalisierbaren Entwicklungsprozesse im Kontext von OSS zu einem {\"u}bertragbaren Modell abstrahiert. Auch in der Wissenschaftsdisziplin des Software Engineering (SE) wurde bereits erkannt, dass sich der OSSD-Ansatz in verschiedenen Aspekten erheblich von klassischen (propriet{\"a}ren) Modellen des SE unterscheidet und daher diese Methoden einer eigenen wissenschaftlichen Betrachtung bed{\"u}rfen. In verschiedenen Publikationen wurden zwar bereits einzelne Aspekte der OSS-Entwicklung analysiert und Theorien {\"u}ber die zugrundeliegenden Entwicklungsmethoden formuliert, aber es existiert noch keine umfassende Beschreibung der typischen Prozesse der OSSD-Methodik, die auf einer empirischen Untersuchung existierender OSS-Entwicklungsprojekte basiert. Da dies eine Voraussetzung f{\"u}r die weitere wissenschaftliche Auseinandersetzung mit OSSD-Prozessen darstellt, wird im Rahmen dieser Arbeit auf der Basis vergleichender Fallstudien ein deskriptives Modell der OSSD-Prozesse hergeleitet und mit Modellierungselementen der UML formalisiert beschrieben. Das Modell generalisiert die identifizierten Prozesse, Prozessentit{\"a}ten und Software-Infrastrukturen der untersuchten OSSD-Projekte. Es basiert auf einem eigens entwickelten Metamodell, welches die zu analysierenden Entit{\"a}ten identifiziert und die Modellierungssichten und -elemente beschreibt, die zur UML-basierten Beschreibung der Entwicklungsprozesse verwendet werden. In einem weiteren Arbeitsschritt wird eine weiterf{\"u}hrende Analyse des identifizierten Modells durchgef{\"u}hrt, um Implikationen, und Optimierungspotentiale aufzuzeigen. Diese umfassen beispielsweise die ungen{\"u}gende Plan- und Terminierbarkeit von Prozessen oder die beobachtete Tendenz von OSSD-Akteuren, verschiedene Aktivit{\"a}ten mit unterschiedlicher Intensit{\"a}t entsprechend der subjektiv wahrgenommenen Anreize auszu{\"u}ben, was zur Vernachl{\"a}ssigung einiger Prozesse f{\"u}hrt. Anschließend werden Optimierungszielstellungen dargestellt, die diese Unzul{\"a}nglichkeiten adressieren, und ein Optimierungsansatz zur Verbesserung des OSSD-Modells wird beschrieben. Dieser Ansatz umfasst die Erweiterung der identifizierten Rollen, die Einf{\"u}hrung neuer oder die Erweiterung bereits identifizierter Prozesse und die Modifikation oder Erweiterung der Artefakte des generalisierten OSS-Entwicklungsmodells. Die vorgestellten Modellerweiterungen dienen vor allem einer gesteigerten Qualit{\"a}tssicherung und der Kompensation von vernachl{\"a}ssigten Prozessen, um sowohl die entwickelte Software- als auch die Prozessqualit{\"a}t im OSSD-Kontext zu verbessern. Desweiteren werden Softwarefunktionalit{\"a}ten beschrieben, welche die identifizierte bestehende Software-Infrastruktur erweitern und eine gesamtheitlichere, softwaretechnische Unterst{\"u}tzung der OSSD-Prozesse erm{\"o}glichen sollen. Abschließend werden verschiedene Anwendungsszenarien der Methoden des OSS-Entwicklungsmodells, u.a. auch im kommerziellen SE, identifiziert und ein Implementierungsansatz basierend auf der OSS GENESIS vorgestellt, der zur Implementierung und Unterst{\"u}tzung des OSSD-Modells verwendet werden kann.}, language = {de} } @phdthesis{Hebig2014, author = {Hebig, Regina}, title = {Evolution of model-driven engineering settings in practice}, url = {http://nbn-resolving.de/urn:nbn:de:kobv:517-opus-70761}, school = {Universit{\"a}t Potsdam}, year = {2014}, abstract = {Nowadays, software systems are getting more and more complex. To tackle this challenge most diverse techniques, such as design patterns, service oriented architectures (SOA), software development processes, and model-driven engineering (MDE), are used to improve productivity, while time to market and quality of the products stay stable. Multiple of these techniques are used in parallel to profit from their benefits. While the use of sophisticated software development processes is standard, today, MDE is just adopted in practice. However, research has shown that the application of MDE is not always successful. It is not fully understood when advantages of MDE can be used and to what degree MDE can also be disadvantageous for productivity. Further, when combining different techniques that aim to affect the same factor (e.g. productivity) the question arises whether these techniques really complement each other or, in contrast, compensate their effects. Due to that, there is the concrete question how MDE and other techniques, such as software development process, are interrelated. Both aspects (advantages and disadvantages for productivity as well as the interrelation to other techniques) need to be understood to identify risks relating to the productivity impact of MDE. Before studying MDE's impact on productivity, it is necessary to investigate the range of validity that can be reached for the results. This includes two questions. First, there is the question whether MDE's impact on productivity is similar for all approaches of adopting MDE in practice. Second, there is the question whether MDE's impact on productivity for an approach of using MDE in practice remains stable over time. The answers for both questions are crucial for handling risks of MDE, but also for the design of future studies on MDE success. This thesis addresses these questions with the goal to support adoption of MDE in future. To enable a differentiated discussion about MDE, the term MDE setting'' is introduced. MDE setting refers to the applied technical setting, i.e. the employed manual and automated activities, artifacts, languages, and tools. An MDE setting's possible impact on productivity is studied with a focus on changeability and the interrelation to software development processes. This is done by introducing a taxonomy of changeability concerns that might be affected by an MDE setting. Further, three MDE traits are identified and it is studied for which manifestations of these MDE traits software development processes are impacted. To enable the assessment and evaluation of an MDE setting's impacts, the Software Manufacture Model language is introduced. This is a process modeling language that allows to reason about how relations between (modeling) artifacts (e.g. models or code files) change during application of manual or automated development activities. On that basis, risk analysis techniques are provided. These techniques allow identifying changeability risks and assessing the manifestations of the MDE traits (and with it an MDE setting's impact on software development processes). To address the range of validity, MDE settings from practice and their evolution histories were capture in context of this thesis. First, this data is used to show that MDE settings cover the whole spectrum concerning their impact on changeability or interrelation to software development processes. Neither it is seldom that MDE settings are neutral for processes nor is it seldom that MDE settings have impact on processes. Similarly, the impact on changeability differs relevantly. Second, a taxonomy of evolution of MDE settings is introduced. In that context it is discussed to what extent different types of changes on an MDE setting can influence this MDE setting's impact on changeability and the interrelation to processes. The category of structural evolution, which can change these characteristics of an MDE setting, is identified. The captured MDE settings from practice are used to show that structural evolution exists and is common. In addition, some examples of structural evolution steps are collected that actually led to a change in the characteristics of the respective MDE settings. Two implications are: First, the assessed diversity of MDE settings evaluates the need for the analysis techniques that shall be presented in this thesis. Second, evolution is one explanation for the diversity of MDE settings in practice. To summarize, this thesis studies the nature and evolution of MDE settings in practice. As a result support for the adoption of MDE settings is provided in form of techniques for the identification of risks relating to productivity impacts.}, language = {en} } @article{LeopoldMendlingGuenther2016, author = {Leopold, Henrik and Mendling, Jan and Guenther, Oliver}, title = {Learning from Quality Issues of BPMN Models from Industry}, series = {IEEE software}, volume = {33}, journal = {IEEE software}, publisher = {Inst. of Electr. and Electronics Engineers}, address = {Los Alamitos}, issn = {0740-7459}, doi = {10.1109/MS.2015.81}, pages = {26 -- 33}, year = {2016}, abstract = {Many organizations use business process models to document business operations and formalize business requirements in software-engineering projects. The Business Process Model and Notation (BPMN), a specification by the Object Management Group, has evolved into the leading standard for process modeling. One challenge is BPMN's complexity: it offers a huge variety of elements and often several representational choices for the same semantics. This raises the question of how well modelers can deal with these choices. Empirical insights into BPMN use from the practitioners' perspective are still missing. To close this gap, researchers analyzed 585 BPMN 2.0 process models from six companies. They found that split and join representations, message flow, the lack of proper model decomposition, and labeling related to quality issues. They give five specific recommendations on how to avoid these issues.}, language = {en} } @misc{Matthies2019, author = {Matthies, Christoph}, title = {Feedback in Scrum}, series = {2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)}, journal = {2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)}, publisher = {IEEE}, address = {New York}, isbn = {978-1-7281-1764-5}, issn = {2574-1934}, doi = {10.1109/ICSE-Companion.2019.00081}, pages = {198 -- 201}, year = {2019}, abstract = {Improving the way that teams work together by reflecting and improving the executed process is at the heart of agile processes. The idea of iterative process improvement takes various forms in different agile development methodologies, e.g. Scrum Retrospectives. However, these methods do not prescribe how improvement steps should be conducted in detail. In this research we investigate how agile software teams can use their development data, such as commits or tickets, created during regular development activities, to drive and track process improvement steps. Our previous research focused on data-informed process improvement in the context of student teams, where controlled circumstances and deep domain knowledge allowed creation and usage of specific process measures. Encouraged by positive results in this area, we investigate the process improvement approaches employed in industry teams. Researching how the vital mechanism of process improvement is implemented and how development data is already being used in practice in modern software development leads to a more complete picture of agile process improvement. It is the first step in enabling a data-informed feedback and improvement process, tailored to a team's context and based on the development data of individual teams.}, language = {en} } @article{ReinRamsonLinckeetal.2017, author = {Rein, Patrick and Ramson, Stefan and Lincke, Jens and Felgentreff, Tim and Hirschfeld, Robert}, title = {Group-Based Behavior Adaptation Mechanisms in Object-Oriented Systems}, series = {IEEE software}, volume = {34}, journal = {IEEE software}, number = {6}, publisher = {Inst. of Electr. and Electronics Engineers}, address = {Los Alamitos}, issn = {0740-7459}, doi = {10.1109/MS.2017.4121224}, pages = {78 -- 82}, year = {2017}, abstract = {Dynamic and distributed systems require behavior adaptations for groups of objects. Group-based behavior adaptation mechanisms scope adaptations to objects matching conditions beyond class membership. The specification of groups can be explicit or implicit.}, language = {en} } @misc{Schroeter2024, type = {Master Thesis}, author = {Schr{\"o}ter, Alexander}, title = {Erstellung und Evaluation eines Fragebogens zur Erfassung von komplexen Interaktionssituationen in Software-Entwicklungsprojekten}, doi = {10.25932/publishup-63187}, url = {http://nbn-resolving.de/urn:nbn:de:kobv:517-opus4-631873}, school = {Universit{\"a}t Potsdam}, pages = {75}, year = {2024}, abstract = {Die fortschreitende Digitalisierung durchzieht immer mehr Lebensbereiche und f{\"u}hrt zu immer komplexeren sozio-technischen Systemen. Obwohl diese Systeme zur Lebenserleichterung entwickelt werden, k{\"o}nnen auch unerw{\"u}nschte Nebeneffekte entstehen. Ein solcher Nebeneffekt k{\"o}nnte z.B. die Datennutzung aus Fitness-Apps f{\"u}r nachteilige Versicherungsentscheidungen sein. Diese Nebeneffekte manifestieren sich auf allen Ebenen zwischen Individuum und Gesellschaft. Systeme mit zuvor unerwarteten Nebeneffekten k{\"o}nnen zu sinkender Akzeptanz oder einem Verlust von Vertrauen f{\"u}hren. Da solche Nebeneffekte oft erst im Gebrauch in Erscheinung treten, bedarf es einer besonderen Betrachtung bereits im Konstruktionsprozess. Mit dieser Arbeit soll ein Beitrag geleistet werden, um den Konstruktionsprozess um ein geeignetes Hilfsmittel zur systematischen Reflexion zu erg{\"a}nzen. In vorliegender Arbeit wurde ein Analysetool zur Identifikation und Analyse komplexer Interaktionssituationen in Software-Entwicklungsprojekten entwickelt. Komplexe Interaktionssituationen sind von hoher Dynamik gepr{\"a}gt, aus der eine Unvorhersehbarkeit der Ursache-Wirkungs-Beziehungen folgt. Hierdurch k{\"o}nnen die Akteur*innen die Auswirkungen der eigenen Handlungen nicht mehr {\"u}berblicken, sondern lediglich im Nachhinein rekonstruieren. Hieraus k{\"o}nnen sich fehlerhafte Interaktionsverl{\"a}ufe auf vielf{\"a}ltigen Ebenen ergeben und oben genannte Nebeneffekte entstehen. Das Analysetool unterst{\"u}tzt die Konstrukteur*innen in jeder Phase der Entwicklung durch eine angeleitete Reflexion, um potenziell komplexe Interaktionssituationen zu antizipieren und ihnen durch Analyse der m{\"o}glichen Ursachen der Komplexit{\"a}tswahrnehmung zu begegnen. Ausgehend von der Definition f{\"u}r Interaktionskomplexit{\"a}t wurden Item-Indikatoren zur Erfassung komplexer Interaktionssituationen entwickelt, die dann anhand von geeigneten Kriterien f{\"u}r Komplexit{\"a}t analysiert werden. Das Analysetool ist als „Do-It-Yourself" Fragebogen mit eigenst{\"a}ndiger Auswertung aufgebaut. Die Genese des Fragebogens und die Ergebnisse der durchgef{\"u}hrten Evaluation an f{\"u}nf Softwarentwickler*innen werden dargestellt. Es konnte festgestellt werden, dass das Analysetool bei den Befragten als anwendbar, effektiv und hilfreich wahrgenommen wurde und damit eine hohe Akzeptanz bei der Zielgruppe genießt. Dieser Befund unterst{\"u}tzt die gute Einbindung des Analysetools in den Software-Entwicklungsprozess.}, language = {de} }