SIGS DATACOM Fachinformationen für IT-Professionals

SOFTWARE MEETS BUSINESS:
Die Konferenz für Software-Architektur
03. - 07. Februar 2020, München

Sessionsdetails

Vortrag: Mi 2.1
Datum: Mi, 05.02.2020
Uhrzeit: 09:00 - 10:30
cart

Täglich grüßt das Murmeltier: Wiederverwendung immer wieder neu

Uhrzeit: 09:00 - 09:45
Vortrag: Mi 2.1 1)

 

Wiederverwendung beziehungsweise Reuse macht viele Projekte überhaupt erst möglich.
Ihre Bedeutung ist Heiliger Gral und Fata Morgana zugleich: ewiges Ziel und nie erreicht.
Wiederverwendete Komponenten sollen perfekt und stabil sein. Aber unsere Software ändert sich, und der Reuse sich auch – nur anders. Was passiert in agilen Projekten und langlebigen Portfolios, wenn sich alle Rhythmen widersprechen?
Die Organisation von Reuse muss Kopplungen erkennen und gestalten: Wer verwendet was auf welche Weise? Wie wählen, organisieren und gestalten wir unser Portfolio?

Zielpublikum: Architekten und Projektleiter
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Wiederverwendung macht viele Projekte überhaupt erst möglich. Alle Räder selbst neu zu schnitzen, dauert lange und erzeugt nur einen geringen Gegenwert.
Wie gestalten wir Projekte und Organisationen, in denen sich vieles ändert – sowohl in den eigentlichen Applikationen als auch bei den wiederverwendeten Komponenten?
Architektur und Organisation von Wiederverwendung funktionieren, wenn die Lebenszyklen klar voneinander getrennt werden und wenn die gegenseitigen Kopplungen erkannt und gestaltet werden.
Themen dieser Session sind:
Was wird wiederverwendet? Wer trägt dazu bei, und wer verwendet es?
Unter welchen Bedingungen wird diese Software eingesetzt? Wie werden die Applikationen dadurch miteinander gekoppelt?
Wie können unterschiedliche Geschwindigkeiten getrennt werden?
Welche gegenseitigen Abhängigkeiten gibt es über die Technik hinaus, was muss die Organisation berücksichtigen?

 

NEU: Eine Balance von Features, Aufwänden und Qualität auf dem Weg ins Unbekannte

Uhrzeit: 09:45 - 10:30
Vortrag: Mi 2.1 2)

 

In “Into the Unknown” Projekten sind Features teilweise offen, der R&D effort kaum planbar und Software Wartbarkeit daher schwer zu erreichen. Wie bringt man dennoch Geschäftswert und Aufwände der Software in Einklang? Der Vortrag zeigt auf, wie der Spagat zu schaffen ist, sich auf die Entwicklung geschäftsrelevanter Features zu konzentrieren ohne auf effektive Qualitätsmaßnahmen bez.  dieser Features zu verzichten. Nutzen, Aufwände und Codequalität muss vielmehr entlang von Features gemessen und auf dieser Ebene überwacht und geschätzt werden.

Target Audience: Projektleiter, Architekten, Key Developers, Managers, Entscheider
Prerequisites: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In “Into the Unknown” Projekten sind Features teilweise offen, der R&D effort schwer planbar und Software Wartbarkeit daher schwer zu erreichen. Wie bringt man dennoch Geschäftswert und Aufwände der Features in Einklang? Der Vortrag zeigt auf, wie der Spagat zu schaffen ist, sich auf die Entwicklung geschäftsrelevanter Features zu konzentrieren ohne auf effektive Qualitätsmaßnahmen bez.  dieser Features zu verzichten. Nutzen, Aufwände und Codequalität muss vielmehr entlang Features gemessen und auf dieser Ebene überwacht und geschätzt werden.
Wir führen neue Konzepte und Analysemethoden vor und zeigen wie man Aufwand und Qualitätsverbesserungen entlang der Features ausrichtet. Wir sprechen von Feature-Modularität statt allein von Code-Modularität und von Feature Qualitätsschulden. Wir zeigen auf, wie man Geschäftsziele mit Qualitätszielen in Einklang bringt, indem man hitzige, subjektive Diskussionen durch datengetriebene und faktenbasierte Zusammenarbeit ersetzt.
Wir zeigen, wie Manager und Entwickler folgende Fragen beantworten können, um mit den Unknown Variablen in heutigen Projekten umzugehen:

  1. Für welche Funktionalität/Features und wo im Code werden die Entwicklungsaufwände aufgebracht? Ist das so beabsichtigt? Werden Aufwände hauptsächlich für Features mit hohem Geschäftsnutzen aufgebracht? Haben bestehende Features einen hohen Geschäftsnutzen?
  2. Wie gut können bestehende Features erweitert werden? Wie gut kann das System mit neuen Features weiterentwickelt werden? Welche Teile des Systems eignen sich dazu, welche nicht? Für welche Teile des Systems lohnt sich eine Verbesserung zur Erweiterbarkeit für Features?
  3. Wo im System können zuverlässig die meisten Fehler und ein hoher Wartungsaufwand basierend auf der Realisierung vorheriger Features prognostiziert werden? Wo muss man proaktiv etwas unternehmen, um spätere Wartungsaufwände zu vermeiden?
  4. Was ist ein belegbarer Aufwand diese Schwachstellen anzugehen?
  5. Was sind die Risiken der Wissensverteilung in Ihren Teams? Wo bestehen Wissensinseln und Wissensklumpen (die zu Folgebugs führen)?