close
AllgemeinDevelopment, CodingHow-To, Tutorial, SzenarioTool, Bot, App, Add-In

SharePoint Online Experience: Neue Paradigmen in der Softwareentwicklung

Heutige Softwareentwicklung ist von Begriffen wie agil und flexibel geprägt. Doch oft werden diese Begriffe in ihrer Bedeutung, in ihrer Gesamtheit nicht vollständig erfasst. Grundsätzlich wird agil mit der Möglichkeit der Redefinition des Featuresets einer Software Solution in Verbindung gebracht. Allerdings wird dabei vergessen, dass mit diesem Ansatz eine Abgrenzung der Features zu Beginn der Entwicklung einer Software nicht möglich ist. Was im Klartext bedeutet, dass die Kosten nicht mit einer Zahl festgenagelt werden können. Eines schließt hier das andere aus. Wie aber rechnet man bei moderner Softwareentwicklung mit den Kosten? Die Antwort darauf ist: agil und flexibel.

Kosten & Abgrenzung

Aber nicht nur die Denkweise im Bereich der Definition eines Softwareprojekts bezüglich Abgrenzung und Kosten müssen das Paradigma des agilen Entwickelns übernehmen. Auch die Erstellung der Software selbst muss sich dieser grundlegend geänderten Sichtweise anpassen. Wie aber sieht Software aus, die dieser Denkweise entspricht? Nun, wie auch bei den vorhergehenden Punkten: agil und flexibel. Und genau hier liegt ein großer Stolperstein begraben. Denn man erwartet, dass man bei agiler Programmierung schnell mit einfachen ersten Schritten startet und dann alle Features, die später benötigt werden, bei Bedarf an die Basis anbaut.

Gewachsene Lösungen

Und da kommen wir schon in die Untiefen, die oft nicht gesehen werden. Wie so oft in der Entwicklung von Software wird ein schnell entwickelter Prototyp herangezogen, um als Basis für die weiteren Schritte zu dienen. Es wird dazu gebaut, ohne ein Framework in diesem Prototyp zu haben, der die Zubauten entsprechend einbinden kann. Und schon treibt die Lösung ungewollte Blüten. Endstation: gewachsene Lösung. Langsam, fehlerhaft, instabil und kaum mehr zu erweitern oder upzudaten. Die Schuld liegt dann bei den Developern, die natürlich in ihrer Programmierung versagt haben.

Software-Architektur

Der Fehler liegt hier aber nicht in der Programmierung, sondern in der Architektur der Lösung. Und genau diese hätte zu Beginn des Projekts aufgebaut werden müssen. Ein Prototyp deckt nämlich meist nur eine grundsätzliche Funktionalität ab und ist absolut unbrauchbar, um eine flexible, agile Basis für eine skalierbare, erweiterbare Software zu bieten. Deshalb ist der Start eines agilen Softwareprojektes sehr viel Arbeit und erfordert tiefgreifendes Wissen darüber, wohin sich die Software entwickeln soll und was dafür strukturell sowie technologisch notwendig ist. Aber wie soll man dieses Wissen haben, ohne zu wissen, was man eigentlich will?

Moderne Softwaresysteme

Die Antwort darauf sind generische, modulare Softwaresysteme. Diese unterstützen die agile, flexible Entwicklung von Lösungen. Neue Features werden mit Hilfe von Modulen in das System eingebunden. Der generische Ansatz erlaubt es, so viel wie möglich zu ändern, ohne aus dem vorgegebenen Framework ausbrechen zu müssen. Und auch hier ist wieder Vorsicht geboten, denn ein generisches System für alles zu bauen ist nicht möglich. Es gilt hier der Grundsatz, je generischer desto schwieriger, desto länger, desto kostenintensiver.

HATAHET MasterTool

Und damit muss klar sein, dass eine agile, flexible Lösung nach der Prototyp- bzw. Machbarkeitsanalyse keinen schnellen Start haben kann, will man nicht in genau diese Falle tappen und mit gewachsener Software verzweifeln. Wie können wir dies verhindern? Nun eine Möglichkeit möchte ich kurz vorstellen, die wir in unserem Unternehmen seit einem Jahr entwickeln. Das HATAHET MasterTool. Ein Tool für Developer, nicht für Kunden, welches uns agiles Entwickeln ermöglicht.

Folgende Punkte hatten wir dabei im Fokus:

  • Zentrale Stelle für Updates
  • Definieren statt Programmieren
  • Applikation und Library in einem
  • Unabhängigkeit von anderen Systemen
  • Informationen an Ort und Stelle
  • Wiederverwendbarkeit

Zentrale Stelle für Updates

Änderungen von anderen Systemen, besonders jener, die online agieren, müssen oft nachgezogen werden. Fehler sind nicht die Ausnahme in der Softwareentwicklung, sie sind die Regel. Um den Aufwand für diese Änderungen so gering wie möglich zu halten, werden sie nur mehr in dem von uns gebauten Tool geändert und ausgerollt.

Modulbasierte Entwicklung

Die Zeiten, zu denen Systeme viele Jahre in gleicher Weise verfügbar waren, sind vorbei. Da immer wieder neue Produkte auf den Markt drängen und alte ersetzen, müssen alte Lösungen verworfen und neue integriert werden. Durch Module kann genau das mit minimalem Aufwand ermöglicht werden. Neue Produkte werden mit neuen Modulen eingebunden, alte Module verschwinden, sofern sie nicht mehr gebraucht werden.

Definieren statt Programmieren

Der generische Ansatz erlaubt es, Software in Definition und Programmierung zu teilen. Funktionen werden programmiert und mit Definition parametrisiert. Dadurch können Lösungen an individuelle Anforderungen angepasst werden, ohne einen Programmierungsaufwand zu erzeugen. Wiederverwendbarkeit ist hier das Schlagwort, das den anfänglich größeren Aufwand in diesem Bereich rechtfertigt.

Applikation und Library in einem

Durch eine grafische Oberfläche können Definitionen benutzerfreundlich in die Lösung eingebracht werden. Diese können getestet und in einem anderen Kontext mit Hilfe einer Library derselben Lösung verwendet werden. Die gemeinsame Basis bietet hier eine XML-Definitionsdatei, die mit Hilfe der Applikation erstellt wird.

Unabhängigkeit von anderen Systemen

Die Lösung fokussiert sich nicht auf ein System, sondern lässt den Zugriff auf multiple Systeme zu. Durch verschiedene Module können notwendige Authentifizierungen durchgeführt werden. Neue Authentifizierungsverfahren sind leicht als neue Module in die Lösung zu integrieren. Die Funktion eines Moduls wird dadurch nicht in dessen Möglichkeiten eingeschränkt.

Informationen an Ort und Stelle

Durch die grafische Oberfläche sind Erklärungen zu den Definitionsmöglichkeiten direkt integrierbar, wodurch zusätzliche Dokumentationen nicht mehr notwendig sind. Da diese mit der Entwicklung am gleichen Ort angepasst werden, hinken sie nicht der Lösung hinterher.

Wiederverwendbarkeit

Bestehende Definitionen können durch oft nur kleinere Anpassungen zum Teil oder zur Gänze wiederverwendet werden. Werden Definitionen modular angelegt, können so gesamte Lösungen individuell zusammengebaut werden.

Mit dieser Lösung sind wir in der Lage uns in die neue, agile und flexible Entwicklungswelt mit überschaubarem Aufwand einzubinden. Dieser Weg führt uns von Einzellösungen zu einer modularen Gesamtlösung, ohne die Möglichkeit der Individualisierung zu verlieren.

Tags : Software
Georg Selig

The author Georg Selig

Georg Selig hat sein Informatik-Studium an der TU-Wien im Jahr 2008 abgeschlossen und ist als SharePoint Senior Developer tätig. Georg bringt mehr als 10 Jahre Berufserfahrung im Bereich der Software-Entwicklung mit Fokus auf Microsoft .net-Sprachen mit. Heute arbeitet er in einem SharePoint Development Team im Bereich der SharePoint Add-On und SharePoint Produktentwicklung in einem Wiener SharePoint und Office 365 Beratungsunternehmen. Im Zuge seiner Arbeit wurden von ihm Produkte für SharePoint 2010, SharePoint 2013, SharePoint 2016 und Office 365 SharePoint Online ins Leben gerufen. Heute beschäftigt sich Georg mit der Erstellung von hybriden Softwareprodukten (Development) für SharePoint 2016, SharePoint Online mit und ohne Azure (PaaS).

Leave a Response