Unsere Methodik

der Entwicklungsprozesse sind fallbasiert

Denn ICONPARC ist Hersteller (Independent Software Vendor) und Integrator. Die ICONPARC B2X E-Business Suite basiert auf einer Multi-Layer Architektur:

Daraus ergeben sich unterschiedliche Entwicklungsmethoden nach Layern:

Theoretisch schützt die Multi-Layer Architektur einer Basistechnologie davor, dass deren Integratoren (Agenturen, IT Dienstleister, …) am selben Code arbeiten, wie der Hersteller der Basis-Software, bestehend aus Applikationsserver sowie Entwicklungs-Framework mit Bibliothek und Anwendungsmodulen. In der Praxis sorgen hingegen die nachfolgend beschriebenen Aspekte dafür, dass sich das Zusammenspiel getrennter Hersteller und Integratoren problematisch gestaltet.

 

Auch wenn die verschiedenen Ebenen einer Multi-Layer Architektur größtenteils für eine saubere Trennung der Zuständigkeitsbereiche (von Hersteller und Integrator) sorgen, gibt es Bereiche des Codes, die von beiden Seiten - mit unterschiedlichen Zielsetzungen - bearbeitet werden: Genau hier liegt ein erster Gefahrenherd für die langfristige Stabilität einer Anwendung.

 

Die zweite Art gefährlicher Stellen für die Kooperation von Herstellern und Integratoren besteht in all denjenigen Situationen, wo zwar nicht überlappend am selben Code gearbeitet wird, wo aber Übergabeschnittstellen zwischen den beteiligten Parteien liegen. Das sind einerseits explizite APIs, andererseits Design Patterns im Code, die als etabliert gelten – bis sie der Hersteller (i.d.R. ohne Ankündigung) in einem Release verändert. Diese Vorgehensweise führt mit an Sicherheit grenzender Wahrscheinlichkeit dazu, dass vom Hersteller entwickelte Basis-Software und vom Integrator beigesteuerte Anwendungsindividualisierung nicht dauerhaft zusammenpassen.

 

Genau diese Sollbruchstellen weist die Software und Umsetzungsmethodik von ICONPARC nicht auf, weil wir als Hersteller und Integrator im Interesse größtmöglicher Kompatibilität agieren: Daher sind unsere Lösungen auch langfristig stabil, insbesondere was das Zusammenwirken von Basistechnologie, Framework und hochgradig individualisierten Anwendungsbestandteilen anbelangt.

Entwicklungsmethodik nach der Stacey Matrix

One Size fits all? Jeder Modefan weiß, dass nur die richtige Größe eines Kleidungsstücks wirklich Freude bereitet. Ähnlich verhält es sich in der Software-Entwicklung: Herausforderungen auf verschiedenen Ebenen lassen sich am besten mit passend darauf abgestimmten Entwicklungsmethoden bewältigen. Neben den einzelnen Ebenen der MultiLayer-Architektur unserer Technologie (mit jeweils standardisiertem Leistungsumfang) erfordert insbesondere auch das Projektgeschäft (mit kundenspezifisch individualisiertem Ansatz) jeweils eine andere Herangehensweise, um beste Ergebnisse sicherzustellen. In diesem Abschnitt stellen wir Ihnen die von uns eingesetzten Entwicklungsmethoden vor – und erläutern, warum sich welche Methodik für die jeweilige Aufgabe besonders eignet.

 

Die Abbildung zeigt, wie sich aus dem Grad der Klarheit der Anforderungen einerseits und der technischen Umsetzung andererseits die jeweils optimal passende Entwicklungsmethodik ableiten lässt. In dieser sogenannten Stacey Matrix sind alle für uns relevanten Methoden dargestellt – diese erläutern wir in den folgenden Abschnitten. Allgemein gilt: Je unklarer Anforderungen und Umsetzungswege sind, desto besser sind agile Methoden geeignet.

Design Thinking

Gleichermaßen unklare Anforderungen und Umsetzungswege bedeuten, dass wir uns in einem unstrukturierten Umfeld bewegen. Was für Informatiker furchteinflößend klingt, ist für kreative Menschen und Entwurfsphasen durchaus ein gängiges Szenario. Erst schrittweise entsteht aus dem anfänglichen Chaos neue Ordnung. Mithilfe von Design Thinking lassen sich insbesondere FRONTENDs erschaffen, die die beste Anwendererfahrung (UX := User Experience) bieten und diese den Nutzern auf allen gängigen Endgeräten zur Verfügung stellen – unter Einsatz von Full Responsive Design. Ist ein FRONTEND erst einmal mittels Photoshop entworfen worden, entwickeln wir auf dieser Basis einen Prototyp in HTML/CSS/JS, der das Bedienkonzept erlebbar macht und im Dialog mit dem Kunden iterativ verfeinert wird.

 

Waterfall

Anforderungen und technische Umsetzung sind relativ klar: Hier geht es um Prozesse - ganz gleich, ob im FRONTEND oder im BACKEND - welche in einer technischen Spezifikation bereits strukturiert beschrieben worden sind. Bei der Umsetzung werden bewährte Wege beschritten, sodass mit wenig Überraschungen zu rechnen ist.

 

CIP – Continuous Improvement Process

In kleinen Schritten werden stetige Verbesserungen innerhalb eines klar definierten Rahmens erzielt. Diese Vorgehensweise eignet sich vor allem für die Optimierung der Applikationsserver-Ebene (IPACT), wobei Abwärtskompatibilität eine entscheidende Rolle spielt.

 

Kanban

Nun bewegen wir uns auf dem Library Layer, welcher den weitaus größten Teil des ICONPARC E-Business Frameworks darstellt. Hier geht es darum, Durchlaufzeiten zu optimieren und Engpässe schnell zu erkennen. Insbesondere soll verhindert werden, dass mehrere Entwickler an derselben Stelle innerhalb der großen Bibliothek Hand anlegen, damit sie sich nicht ins Gehege kommen bzw. um möglichst viel Fläche parallel bearbeiten zu können.
Weil es sich nie 100%ig ausschließen lässt, dass verschiedene Entwickler (mit unterschiedlichen Zielsetzungen) an ein- und derselben Stelle in der Library tätig werden, hilft eine weiter Methode, die sich gut mit dem Kanban-Ansatz kombinieren lässt, parallel stattfindende Arbeiten voneinander zu entkoppeln: Komplexe Erweiterungen, die potentiell viele Rückwirkungen auf andere Stellen im Code haben, lassen sich in einen sogenannten Branch auslagern. Dort können Funktionalitäten in Ruhe gebaut und getestet werden - auch von mehreren Entwicklern - bevor diese massiven Änderungen schließlich wieder mit dem Hauptentwicklungspfad (Trunk) verschmolzen werden.

 

Scrum

Bei der vielleicht populärsten agilen Methode ist der Kunde kaum involviert. Vielmehr handelt es sich um einen integrativen Prozess zwischen Entwicklern. Das von ICONPARC seit rund 26 Jahren weiterentwickelte E-Business Framework unterliegt einem Prozess ständiger Optimierungen und Erweiterungen, ohne dass vollkommen klar wäre, wohin die Reise geht. Mit jedem Schritt wird ein neues Zwischenergebnis geschaffen: Anhand dieser Zwischenergebnisse lassen sich fehlende Anforderungen und technische Lösungswege effizienter finden, als durch eine abstrakte Klärungsphase. Bei Scrum entwickelt sich die Planung iterativ und inkrementell. Die empirische Verbesserung fußt auf drei Säulen:

  1. Transparenz: Fortschritte eines Projekts werden regelmäßig und für alle Beteiligten transparent beschrieben.

  2. Überprüfung: Projektergebnisse und Funktionalitäten werden regelmäßig geliefert und bewertet.

  3. Anpassung: Anforderungen an das Projekt, Pläne und Vorgehensweisen werden kontinuierlich und im Detail angepasst. Durch die Anwendung von Scrum reduziert sich die Komplexität der Aufgabe nicht. Durch Strukturierung in Form kleinerer und weniger komplexer Inkremente lässt sich die mit der gegebenen Aufgabe einhergehende Komplexität dennoch leichter handhaben.

 

Achtung: Agile Vorgehensweisen erfordern ein ebenso „agiles“ Budget!

 

Bei der iterativen Entwicklung steht zu Beginn nur ein grober Rahmen mit Anforderungen bzw. Zielsetzungen. Eine belastbare Spezifikation fehlt hingegen - und damit die Grundlage für eine Vorab-Ermittlung des zu erwartenden Umsetzungsaufwands bzw. der voraussichtlich anfallenden Kosten. Dabei ist Scrum nur vordergründig auch für weniger erfahrene Entwicklerteams geeignet: Zwar entfällt insbesondere die anspruchsvolle Erarbeitung eines aussagekräftigen Lasten- und Pflichtenhefts, jedoch werden nur sehr erfahrene Entwickler auf eine Weise mit den entstehenden Freiheitsgraden umgehen können, die nicht in ausufernde Projektlaufzeiten, enttäuschte Erwartungen und dauerüberzogene Budgets mündet.

Die Basis-Layer sind auf allen Entwicklungs-, Tests- & Produktiv-Systemen identisch - die Updates erfolgen im wöchentlichen Turnus 

  • Framework
  • Library
  • ICONPARC Application-Server IPACT (Aufbauend auf JAVA V21 64-Bit)

 

Die verschiedenen Software-Layer sind

  • FRONTEND
  • BACKEND
  • Modul-Layer
  • Framework
  • Library
  • ICONPARC Application-Server IPACT (Aufbauend auf JAVA V21 64-Bit)

 

Die Layer, die in Kundenprojekte customized und damit integriert werden sind

  • FRONTEND
  • BACKEND
  • Modul-Layer

 

Daraus abgeleitet arbeiten wir mit zwei konzeptionell unterschiedlichen Ticket-Systemen, welche ebenfalls von uns entwickelt worden sind und ständig mit neuen Features angereichert werden.

Ticket System

Welches für Kunden und Entwickler zugänglich ist

Progress Tracker

Welches nur für Entwickler zugänglich ist.