Busch, AxelKoziolek, AnneTichy, MatthiasBodden, EricKuhrmann, MarcoWagner, StefanSteghöfer, Jan-Philipp2019-03-292019-03-292018978-3-88579-673-2https://dl.gi.de/handle/20.500.12116/21182Die Qualität eines Software-Systems hängt zum großen Teil von der Güte seiner zugrundeliegenden Software-Architektur ab. Während des Software-Entwicklungsprozesses müssen Entwickler häufig Kompromisse zwischen verschiedenen Qualitätsattributen eingehen. In aller Regel stehen einige dieser Qualitätsattribute miteinander in Konflikt. Beispielsweise kann häufig ein besseres Antwortzeitverhalten des Systems nur mit höheren Kosten bei der Entwicklung oder bei der verwendeten Hardware erreicht werden. Entwickler können sich bei Abwägungsentscheidungen dieser Art bereits von verschiedenen Lösungen unterstützen lassen und so ihre Software-Architektur optimieren. Dabei besteht die Möglichkeit entweder quantifizierte oder nicht-quantifizierte Qualitätsattribute auszuwerten. Sollen gut automatisierbare Ansätze verwendet werden ist es in aller Regel nötig alle Qualitätsattribute zu quantifizieren. Die hohen Kosten dieses Ansatzes zur Anwendung der dafür nötigen Metriken machen eine vollständige Quantifizierung aller nötigen Qualitätsattribute allerdings häufig nicht möglich. Der Ansatz dieser Arbeit kombiniert daher Methoden, die quantifizierte Qualitätsattribute voraussetzen, mit qualitativen Ansätzen, um den Aufwand zu reduzieren alle tatsächlich nötigen Qualitätsattribute bei der Entscheidungsunterstützung berücksichtigen zu können. Dabei kann der Entwickler entscheiden welche Qualitätsattribute sich im Einzelfall lohnen (aufwendig) zu quantifizieren und bei welchen eine qualitative Abschätzung ausreichend ist. Der genannte Ansatz erlaubt es anschließend sowohl quantifizierte, als auch nicht-quantifizierte Qualitätsattribute in Kombination zu verarbeiten und Entwurfsenscheidungen zu unterstützen. Der Ansatz wurde an zwei Systemen demonstriert und das Laufzeitverhalten als quantifizierte Qualität zusammen mit Sicherheit und Bedienbarkeit als nicht-quantifizierte Qualität betrachtet. Publiziert auf QoSA 2016 (http://ieeexplore.ieee.org/document/7515435/)enNot-quantifiedRequirementsDesign DecisionArchitecture Trade-offAutomatedArchitecture KnowledgeText/Conference Paper1617-5468