05 Fakultät Informatik, Elektrotechnik und Informationstechnik
Permanent URI for this collectionhttps://elib.uni-stuttgart.de/handle/11682/6
Browse
20 results
Search Results
Item Open Access Software Engineering und CASE - Begriffserklärung und Standortbestimmung(1991) Ludewig, JochenCASE-Tools werden heute als wichtige Mittel der Leistungs- und Qualitätssteigerung im Software Engineering betrachtet. Diese Einschätzung ist richtig, wenn sie mittel- und langfristig verstanden wird; sie ist falsch, wenn man erwartet, rasche Hilfe zu bekommen, die Versäumnisse in der Methodik und Schulung ausgleicht. Die heute angebotenen Werkzeuge weisen charakteristische Mängel auf, die - entgegen den Ankündigungen - ihren durchgehenden Einsatz sehr schwer machen. Trotzdem kann unter bestimmten Voraussetzungen, auch organisatorischen, die Qualität des Entwicklungsprozesses tatsächlich erhöht werden. Diese Verbesserung wirkt sich auch auf die Produktivität aus.Item Open Access On the impact of service-oriented patterns on software evolvability: a controlled experiment and metric-based analysis(2019) Bogner, Justus; Wagner, Stefan; Zimmermann, AlfredBackground: Design patterns are supposed to improve various quality attributes of software systems. However, there is controversial quantitative evidence of this impact. Especially for younger paradigms such as service- and Microservice-based systems, there is a lack of empirical studies. Objective: In this study, we focused on the effect of four service-based patterns - namely Process Abstraction, Service Façade, Decomposed Capability, and Event-Driven Messaging - on the evolvability of a system from the viewpoint of inexperienced developers. Method: We conducted a controlled experiment with Bachelor students (N = 69). Two functionally equivalent versions of a service-based web shop - one with patterns (treatment group), one without (control group) - had to be changed and extended in three tasks. We measured evolvability by the effectiveness and efficiency of the participants in these tasks. Additionally, we compared both system versions with nine structural maintainability metrics for size, granularity, complexity, cohesion, and coupling. Results: Both experiment groups were able to complete a similar number of tasks within the allowed 90 min. Median effectiveness was 1/3. Mean efficiency was 12% higher in the treatment group, but this difference was not statistically significant. Only for the third task, we found statistical support for accepting the alternative hypothesis that the pattern version led to higher efficiency. In the metric analysis, the pattern version had worse measurements for size and granularity while simultaneously having slightly better values for coupling metrics. Complexity and cohesion were not impacted. Interpretation: For the experiment, our analysis suggests that the difference in efficiency is stronger with more experienced participants and increased from task to task. With respect to the metrics, the patterns introduce additional volume in the system, but also seem to decrease coupling in some areas. Conclusions: Overall, there was no clear evidence for a decisive positive effect of using service-based patterns, neither for the student experiment nor for the metric analysis. This effect might only be visible in an experiment setting with higher initial effort to understand the system or with more experienced developers.Item Open Access CASE: tools, lies, and video games(1989) Ludewig, JochenCASE, Computer Aided Software Engineering - für die einen die Wunderwaffe im Kampf gegen alle Probleme mit der Software, für die anderen eine leere Worthülse aus dem Arsenal der Verkäufer - für alle aber ein schwammiger Begriff. Im nachfolgenden Artikel soll versucht werden, ihn auszuloten und auf das Gesicherte zu begrenzen.Item Open Access Field study on requirements engineering: investigation of artefacts, project parameters, and execution strategies(2012) Méndez Fernández, Daniel; Wagner, Stefan; Lochmann, Klaus; Baumann, Andrea; Carne, Holger deContext Requirements Engineering (RE) is a critical discipline mostly driven by uncertainty, since it is influenced by the customer domain or by the development process model used. Volatile project environments restrict the choice of methods and the decision about which artefacts to produce in RE. Objective We aim to investigate RE processes in successful project environments to discover characteristics and strategies that allow us to elaborate RE tailoring approaches in the future. Method We perform a field study on a set of projects at one company. First, we investigate by content analysis which RE artefacts were produced in each project and to what extent they were produced. Second, we perform qualitative analysis of semi-structured interviews to discover project parameters that relate to the produced artefacts. Third, we use cluster analysis to infer artefact patterns and probable RE execution strategies, which are the responses to specific project parameters. Fourth, we investigate by statistical tests the effort spent in each strategy in relation to the effort spent in change requests to evaluate the efficiency of execution strategies. Results We identified three artefact patterns and corresponding execution strategies. Each strategy covers different project parameters that impact the creation of certain artefacts. The effort analysis shows that the strategies have no significant differences in their effort and efficiency. Conclusions In contrast to our initial assumption that an increased effort in requirements engineering lowers the probability of change requests or project failures in general, our results show no statistically significant difference between the efficiency of the strategies. In addition, it turned out that many parameters considered as the main causes for project failures can be successfully handled. Hence, practitioners can apply the artefact patterns and related project parameters to tailor the RE process according to individual project characteristics.Item Open Access Wie gut ist die Software? : Qualitäts- und Komplexitätsmetriken, subjektive Schätzungen(1991) Ludewig, JochenMetriken sollen durch Zählung und Rechnung quantitative Aussagen über Software liefern. In den siebziger Jahren wurden zum Teil hochgesteckte algorithmische Metriken vorgeschlagen. Sie haben sich in der Praxis eigentlich nicht bewährt. Die simplen Metriken sind nach wie vor die wichtigsten. Verschiedene Qualitätsaspekte werden sich wohl nie objektiv quantifizieren lassen. Das soll aber nicht davon abhalten, wenigstens geeignete subjektive Verfahren, also Schätzungen, anzuwenden.Item Open Access Software-Prozesse und Software-Qualität(2006) Ludewig, JochenEin Software-Entwickler sorgt für gute Software-Qualität, weil das praktisch ist, weil gute Software die billigste Lösung ist, also nicht, weil das in irgendwelchen Vorschriften gefordert wird oder ihm durch Drill in der Ausbildung anerzogen wurde. Aber was ist gute Software-Qualität? Zunächst erwarten wir, dass die Anforderungen erfüllt sind, dass also die Software (Programme und Dokumente) leistet, was sie leisten soll (Brauchbarkeit).Das reicht aber nicht aus; da sich die Anforderungen immer wieder ändern, muss es möglich sein, die Änderungen auch umzusetzen. Die Software muss also wartbar sein (Wartbarkeit). Andernfalls erstarrt sie und verliert ihren Nutzen.Item Open Access Software Engineering: die wichtigsten Grundlagen(1992) Ludewig, JochenDer folgende Artikel - nach einem Referat in der "TR-Werkstatt '91" - fasst einige Grundlagen und Ausgangspunkte des Software Engineerings in sehr knapper Form zusammen; jeder der Punkte könnte und sollte näher erläutert werden. Es handelt sich hier also quasi um das kommentierte Inhaltsverzeichnis des einführenden Kapitels einer Vorlesung über Software Engineering, wie sie etwa an der Universität Stuttgart angeboten wird.Item Open Access Wiederverwendung als Wunderwaffe?(1993) Plödereder, ErhardDie Wiederverwendung von Software wird derzeit als geeignete Methode angesehen, dem Anstieg der Komplexität und der Entwicklungskosten entgegenzuwirken. Eine erfolgreiche Wiederverwendung verspricht klare Vorteile. Wiederverwendung ist keine Wunderwaffe. Sie ist aber Bestandteil einer umfassenden Strategie für das Software-Engineering, mit der Qualität und Produktivität schrittweise verbessert werden können.Item Open Access Sprachen für das Software-Engineering(1993) Ludewig, JochenDieser Beitrag diskutiert Sprachen und Notationen aus der Sicht des Software Engineerings, also nicht wie sonst üblich aus der Perspektive der Codierer oder der Sprachschöpfer und Übersetzerbauer. Natürlich ist Vollständigkeit auf diesem weiten Feld weder erreichbar noch angestrebt. Nach der Klärung einiger Grundbegriffe wird die Situation vor 25 Jahren der heutigen gegenübergestellt; einzelne Aspekte der modernen Sprachen werden näher betrachtet. Schließlich wird der Zusammenhang der Sprachen mit Werkzeugen und Methoden angesprochen. Thesen am Schluß des Artikels fassen die wichtigsten Aussagen und Folgerungen pointiert zusammen.Item Open Access Too trivial to test? An inverse view on defect prediction to identify methods with low fault risk(2019) Niedermayr, Rainer; Röhm, Tobias; Wagner, StefanBackground: Test resources are usually limited and therefore it is often not possible to completely test an application before a release. To cope with the problem of scarce resources, development teams can apply defect prediction to identify fault-prone code regions. However, defect prediction tends to low precision in cross-project prediction scenarios. Aims: We take an inverse view on defect prediction and aim to identify methods that can be deferred when testing because they contain hardly any faults due to their code being “trivial”. We expect that characteristics of such methods might be project-independent, so that our approach could improve cross-project predictions. Method: We compute code metrics and apply association rule mining to create rules for identifying methods with low fault risk (LFR). We conduct an empirical study to assess our approach with six Java open-source projects containing precise fault data at the method level. Results: Our results show that inverse defect prediction can identify approx. 32–44% of the methods of a project to have a LFR; on average, they are about six times less likely to contain a fault than other methods. In cross-project predictions with larger, more diversified training sets, identified methods are even 11 times less likely to contain a fault. Conclusions: Inverse defect prediction supports the efficient allocation of test resources by identifying methods that can be treated with less priority in testing activities and is well applicable in cross-project prediction scenarios.