© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: Knigge für Softwarearchitekten

Kolumne: Knigge für Softwarearchitekten

Willkommen zu einer neuen Serie unserer Kolumne für Softwarearchitekten. Wir beleuchten in dieser neuen Staffel das Thema „Ändern bestehender Software“ aus architektonischer Sicht.

Peter Hruschka, Gernot Starke


Warum ändern wir Software?Unsere Software enthält Fehler, die Einsatz oder Benutzung der Software verhindern oder erschweren. Es gibt neue oder geänderte Anforderungen an unsere Software. Dies umfasst sowohl funktionale Erweiterungen (sprich: die Software soll zukünftig neue Aufgaben lösen) wie auch nicht funktionale Merkmale (landläufig auch Qualitätsmerkmale genannt).Änderungen in Ablauf-/Betriebsumgebung: Technische Änderungen an der Infrastruktur (Hardware, Betriebssystem oder irgendwelche Basissoftware) erfordern Änderungen an der Software.Relevante externe Systeme ändern ihre Schnittstellen – unsere Software ist davon betroffen.Änderungen im organisatorischen Umfeld: Neue Anwender, Manager, Sponsoren – ein Spezialfall von Punkt 2 (neue Anforderungen).Hohe Betriebskosten: Betrieb und Administration der Software sind zu teuer.Hohe Änderungs- oder Reparaturkosten: Bugfixing, Weiterentwicklung, Erweiterung oder Änderung der Software (aus den Gründen 1–6) ist zu teuer. Intrinsische Motivation der Entwickler: Die innere Struktur oder der Quellcode der Software entsprechen nicht den Zielvorstellungen der Entwickler.Theoretisch ist Änderung leichtIn über zwanzig Jahren Berufspraxis haben wir dieses Software-Schlaraffenland selten angetroffen. Entweder wir sind vom Pech verfolgt oder in der Praxis funktioniert Softwareentwicklung suboptimal – mit dem Resultat suboptimaler, schlecht strukturierter, übermäßig komplexer und unverständlicher Systeme, deren Wartung und Pflege sehr viel Mühe bereitet. Personalwechsel, fehlende oder inkonsistente Dokumentation, fehlende Testautomatisierung, mangelnde Modularisierung und Entkopplung, übermäßiger Zeitdruck, ignorierte Komplexität, Vermischung von Technik und Fachlichkeit ... Sie kennen das. Aus den oben genannten Gründen (zumindest den ersten sieben) werden große Teile bestehender Software ständig geändert – und das über viele Jahre lang. Unserer Erfahrung in unterschiedlichen Branchen nach bleibt Individualsoftware zwischen fünf und 25 Jahre in Betrieb, und wird meistens über so lange Zeit kontinuierlich verändert. Größere Systeme benötigen teilweise mehrere Jahre an „Reifungszeit“, bevor sie überhaupt sinnvoll einsetzbar sind (Joel Spolsky belegt an einigen Beispielen: „Good Software Takes 10 Years.“ [1] – bei kleinen bis mittleren Systemen geht’s sicherlich auch kürzer.)Daher wagen wir die These, dass für Entwickler und Architekten die Fähigkeit, Software zu ändern, langfristig wichtiger ist, als Software kom...

Java Magazin
Kolumne: Knigge für Softwarearchitekten

Kolumne: Knigge für Softwarearchitekten

Willkommen zu einer neuen Serie unserer Kolumne für Softwarearchitekten. Wir beleuchten in dieser neuen Staffel das Thema „Ändern bestehender Software“ aus architektonischer Sicht.

Peter Hruschka, Gernot Starke


Warum ändern wir Software?Unsere Software enthält Fehler, die Einsatz oder Benutzung der Software verhindern oder erschweren. Es gibt neue oder geänderte Anforderungen an unsere Software. Dies umfasst sowohl funktionale Erweiterungen (sprich: die Software soll zukünftig neue Aufgaben lösen) wie auch nicht funktionale Merkmale (landläufig auch Qualitätsmerkmale genannt).Änderungen in Ablauf-/Betriebsumgebung: Technische Änderungen an der Infrastruktur (Hardware, Betriebssystem oder irgendwelche Basissoftware) erfordern Änderungen an der Software.Relevante externe Systeme ändern ihre Schnittstellen – unsere Software ist davon betroffen.Änderungen im organisatorischen Umfeld: Neue Anwender, Manager, Sponsoren – ein Spezialfall von Punkt 2 (neue Anforderungen).Hohe Betriebskosten: Betrieb und Administration der Software sind zu teuer.Hohe Änderungs- oder Reparaturkosten: Bugfixing, Weiterentwicklung, Erweiterung oder Änderung der Software (aus den Gründen 1–6) ist zu teuer. Intrinsische Motivation der Entwickler: Die innere Struktur oder der Quellcode der Software entsprechen nicht den Zielvorstellungen der Entwickler.Theoretisch ist Änderung leichtIn über zwanzig Jahren Berufspraxis haben wir dieses Software-Schlaraffenland selten angetroffen. Entweder wir sind vom Pech verfolgt oder in der Praxis funktioniert Softwareentwicklung suboptimal – mit dem Resultat suboptimaler, schlecht strukturierter, übermäßig komplexer und unverständlicher Systeme, deren Wartung und Pflege sehr viel Mühe bereitet. Personalwechsel, fehlende oder inkonsistente Dokumentation, fehlende Testautomatisierung, mangelnde Modularisierung und Entkopplung, übermäßiger Zeitdruck, ignorierte Komplexität, Vermischung von Technik und Fachlichkeit ... Sie kennen das. Aus den oben genannten Gründen (zumindest den ersten sieben) werden große Teile bestehender Software ständig geändert – und das über viele Jahre lang. Unserer Erfahrung in unterschiedlichen Branchen nach bleibt Individualsoftware zwischen fünf und 25 Jahre in Betrieb, und wird meistens über so lange Zeit kontinuierlich verändert. Größere Systeme benötigen teilweise mehrere Jahre an „Reifungszeit“, bevor sie überhaupt sinnvoll einsetzbar sind (Joel Spolsky belegt an einigen Beispielen: „Good Software Takes 10 Years.“ [1] – bei kleinen bis mittleren Systemen geht’s sicherlich auch kürzer.)Daher wagen wir die These, dass für Entwickler und Architekten die Fähigkeit, Software zu ändern, langfristig wichtiger ist, als Software kom...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang