<?xml version="1.0" encoding="UTF-8"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
<title>P209 - Nachhaltiges Software Management</title>
<link href="http://dl.gi.de/handle/20.500.12116/17919" rel="alternate"/>
<subtitle/>
<id>http://dl.gi.de/handle/20.500.12116/17919</id>
<updated>2026-07-22T22:14:09Z</updated>
<dc:date>2026-07-22T22:14:09Z</dc:date>
<entry>
<title>Nachhaltigkeit durch gesteuerte Software-Evolution</title>
<link href="http://dl.gi.de/handle/20.500.12116/17934" rel="alternate"/>
<author>
<name>Sneed, Harry M.</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/17934</id>
<updated>2018-11-06T11:35:14Z</updated>
<published>2012-01-01T00:00:00Z</published>
<summary type="text">Nachhaltigkeit durch gesteuerte Software-Evolution
Sneed, Harry M.
Brandt-Pook, Hans; Fleer, André; Spitta, Thorsten; Wattenberg, Malte
In diesem Beitrag zur Förderung der Softwarenachhaltigkeit wird der herkömmliche Begriff des Projektes in Frage gestellt. Es komme weniger darauf an, Softwareprojekte auszuführen als vielmehr, Softwareprodukte zu bauen und über die Zeit ständig auszubauen und nachzubessern. Ein Softwareprodukt ist nie fertig bzw. „Done“, es wird so lange weiterentwickelt, bis keiner mehr daran Interesse hat. Ergo kann ein Projekt niemals abgeschlossen sein. Der Beitrag beschreibt, wie Softwareprodukte entstehen und über viele aufeinander folgende Releases immer reifer und nützlicher werden. Der Anwender arbeitet stets mit einem vorübergehenden Zustand, nie mit einem endgültigen. Da die IT-Welt immer im Wandel begriffen ist, kann es keinen Endzustand geben. Dieser Ansatz wird von einer Service-orientierten Architektur sowie von der aufsteigenden Cloud- Technologie geradezu gefördert. In einer betrieblichen SOA werden die angebotenen Services fortlaufend erneuert. Da diese unfertigen Teile in die eigene Anwendungssoftware eingebaut sind, kann auch die eigene Software nie fertig werden. Sie hat immer nur einen Stand erreicht. Dies gilt umso mehr für Services aus der Cloud, wo der Anwender noch weniger Einfluss auf die Weiterentwicklung seiner Komponente hat. Das ändert wie unsere Systeme geplant und finanziert werden. Die Planung und Kostenkalkulation beschränkt sich auf ein Release, bzw. auf einen Zeitrahmen von maximal drei Monaten. Das Budget für ein Produkt muss offen bleiben und nach jedem Release neu aufgestellt werden. Die IT ist in einer dynamischen Umwelt eingebettet und muss sich dieser anpassen. Dennoch darf diese Anpassung nicht in Chaos ausarten. Die Antwort ist eine gesteuerte Evolution im Einklang mit den wandelnden Anforderungen und den neuesten Serviceangeboten.
</summary>
<dc:date>2012-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Kontinuierliche Prozessverbesserung durch Testautomatisierung</title>
<link href="http://dl.gi.de/handle/20.500.12116/17935" rel="alternate"/>
<author>
<name>Heidt, Andre</name>
</author>
<author>
<name>Kleuker, Stephan</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/17935</id>
<updated>2018-11-06T11:35:14Z</updated>
<published>2012-01-01T00:00:00Z</published>
<summary type="text">Kontinuierliche Prozessverbesserung durch Testautomatisierung
Heidt, Andre; Kleuker, Stephan
Brandt-Pook, Hans; Fleer, André; Spitta, Thorsten; Wattenberg, Malte
Für kleine und mittelständische Unternehmen (KMU), die Software- Produkte herstellen, stellt sich kontinuierlich die Herausforderung, die Software wart- und erweiterbar zu halten. Dabei müssen die Maßnahmen meist im laufenden Betrieb eingeführt werden und der Return of Investment (ROI) möglichst garantiert sein. Dieser Bericht beschreibt, mit welchen Schritten eine Testautomatisierung zu einer kontinuierlichen Softwareentwicklungsprozessverbesserung bei einem KMU geführt hat. Weiterhin wird andiskutiert, welche Rahmenbedingungen analysiert werden müssen, um die unternehmensindividuell passendsten Maßnahmen zur Prozessverbesserung zu bestimmen, die auch unmittelbaren Einfluss auf die Nachhaltigkeit der Produkte haben.
</summary>
<dc:date>2012-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Entwurf eines Quellcode basierten Qualitätsmodells für die Softwarewartung</title>
<link href="http://dl.gi.de/handle/20.500.12116/17936" rel="alternate"/>
<author>
<name>Teßmer, Meik</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/17936</id>
<updated>2018-11-06T11:35:14Z</updated>
<published>2012-01-01T00:00:00Z</published>
<summary type="text">Entwurf eines Quellcode basierten Qualitätsmodells für die Softwarewartung
Teßmer, Meik
Brandt-Pook, Hans; Fleer, André; Spitta, Thorsten; Wattenberg, Malte
Die Wartbarkeit eines Softwaresystems ist ein wichtiger Faktor für seinen langfristigen Einsatz. In diesem Beitrag wird ein Qualitätsmodell auf Quellcode-Basis entworfen, das den Wartbarkeitsbegriff konkretisiert und messbar macht. Ziel ist die Untersuchung der Qualität eines an der Universität entwickelten großen Systems zur Prüfungsverwaltung.
</summary>
<dc:date>2012-01-01T00:00:00Z</dc:date>
</entry>
<entry>
<title>Same procedure as</title>
<link href="http://dl.gi.de/handle/20.500.12116/17930" rel="alternate"/>
<author>
<name>Vosseberg, Karin</name>
</author>
<author>
<name>Spillner, Andreas</name>
</author>
<id>http://dl.gi.de/handle/20.500.12116/17930</id>
<updated>2018-11-06T11:35:13Z</updated>
<published>2012-01-01T00:00:00Z</published>
<summary type="text">Same procedure as
Vosseberg, Karin; Spillner, Andreas
Brandt-Pook, Hans; Fleer, André; Spitta, Thorsten; Wattenberg, Malte
Bei der Entwicklung von Softwaresystemen ist agiles Vorgehen derzeit angesagt. In vielen Softwarefirmen wird bereits agil entwickelt oder darüber nachgedacht agil zu werden. Scrum ist dabei das bevorzugte Vorgehen. Kernstück der agilen Entwicklung ist die Umsetzung von kleinen Aufgaben, die innerhalb eines Sprints (in der Regel max. 4 Wochen) vollständig zu erledigen sind. Das Gesamtsystem entsteht in iterativen Schritten. Als in den 90er Jahren die Objektorientierung Einzug in die softwareentwickelnden Firmen genommen hat, ist die Wiederverwendung von Softwareteilen als ein großer Vorteil der Objektorientierung propagiert worden. Wiederverwendung »innerhalb« des Systems über die Vererbung ist umgesetzt worden; systemübergreifende Wiederverwendung von Klassen eher weniger. Wiederverwendung von ganzen Systemteilen (Komponenten) ist selten in der Praxis anzutreffen. Cloud Services stellen Dienste zur Verfügung, die in Kombination ganze Anwendungen (oder Teile davon) realisieren. Hier ist Wiederverwendung umgesetzt. Services werden von Dienstleistern zur Nutzung angeboten und Softwaresysteme werden aus unterschiedlichen Diensten »kombiniert« (und nicht mehr programmiert). Im Vortrag werden unter anderen folgende Fragen diskutiert: Wie kann bei agilem Vorgehen mehr Wiederverwendung betrieben werden?, Welche Anknüpfungspunkte bestehen zwischen Cloud Services und agiler Entwicklung?, In welche Richtung muss sich die Softwareentwicklung bewegen, um Wiederverwendung besser zu ermöglichen? Wir werden eher Fragen aufwerfen, ohne Antworten oder Lösungen parat zu haben, hoffen aber damit eine intensive Diskussion mit den Zuhörern und nach der Tagung auch in den Firmen zu initiieren.
</summary>
<dc:date>2012-01-01T00:00:00Z</dc:date>
</entry>
</feed>
