Unsere Entwicklungsmethoden

sind fallbasiert

Denn IconParc ist Hersteller (Independent Software Vendor) und Integrator. Die IconParc B2B 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

In dieser Stacey Matrix sind die für uns relevanten Entwicklungsmethoden dargestellt und werden nachfolgend erläutert. 

 

Je unklarer die Anforderungen und die zu beschreitenden Wege, desto eher eignen sich agile Methoden.

Design Thinking

In der Stacey Matrix sind die Anforderungen sowie die Technik unklar – es herrscht Chaos. Das ist genau das „richtige“ Umfeld für eine agile Vorgehensweise.

 

Auch wenn der kleinste Layer unserer Multi-Layer Architektur das FRONTEND bildet, so ist dieser sehr wichtig, weil dieser die einzige Ebene ist, welche Kunden (und deren Kunden - weil B2B) sehen. Im Laufe der letzten 20 Jahre hat sich das extrem weiter entwickelt, insbesondere durch die explosionsartigen Verbreitung von Smartphones und Tablets. Daher muss die Benutzerführung Multi-Channel geeignet sein - auf einer Plattform mit denselben Prozessen.

 

Ziel ist dabei, Lösungen zu finden, die aus Anwendersicht (Nutzersicht) überzeugend sind.

 

Darüber hinaus spielt bei Individual-Plattformen das Branding, also die Fortführung in der Digitalisierung der Corporate Identity ebenfalls eine sehr große Rolle. Ein einzigartiges Design, ohne Medienbrüche.

 

Nachdem die technische Spezifikation (=das Pflichtenheft, wie Prozesse funktionieren müssen) von uns beschrieben wird, designen wir zuerst AreaLayouts in Photoshop als JPGs zusammen mit Kunden, entwickeln darauf einen Prototypen auf Basis von HTML/CSS/JS und drehen zahlreiche Runden mit dem Kunden auf allen Endgeräten mit iterativen Verfeinerungen.

 

Waterfall

In der Stacey Matrix sind die Anforderungen sowie die Technik relativ klar. Hier geht es um Prozesse, welche in einer technischen Spezifikation für den Kunden beschrieben sind. Unser Anteil an Customization von Modulen beträgt in der Regel zwischen 5-50%.

 

CIP

Continual Improvement Process ist eine Denkweise, mit stetigen Verbesserungen in kleinen Schritten. Hier spielt die Abwärtskompatibilität die größte Rolle, weil der IconParc Applikationsserver IPACT die Sprache und Syntax selbst beschreibt.

 

Scrum

Die vielleicht populärste agile Methode ist Scrum. Auf dieser Ebene ist der Kunde kaum involviert. Das ist ein integrativer Prozess zwischen Entwicklern. Das Framework unterliegt einem ständigen Prozess der Optimierungen und Erweiterungen, ohne das klar ist, wohin die Reise genau geht. Daher werden hier Zwischenergebnisse geschaffen. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird die Planung iterativ und inkrementell entwickelt. Die empirische Verbesserung fußt auf drei Säulen

  1. Transparenz: Fortschritt eines Projektes wird regelmäßig und für alle sichtbar beschrieben

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

  3. Anpassung: Anforderungen an das Produkt, Pläne und Vorgehen werden kontinuierlich und detailliert angepasst. Die Komplexität von Scrum reduziert Aufgaben nicht, strukturiert sie aber in kleinere und weniger komplexe Inkremente

 

Hochgradig agile Vorgehensweisen erfordern ein ebenso „agiles“ Budget:

Aufgrund 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 die Vorab-Ermittlung des zu erwartenden Umsetzungsaufwands bzw. der anfallenden Kosten. Vordergründig ist Scrum auch geeignet für weniger erfahrene Entwicklerteams, da insbesondere die anspruchsvolle Erarbeitung eines aussagekräftigen Lasten- und Pflichtenhefts entfällt. Andererseits werden nur sehr erfahrende Entwickler auf eine Weise damit umgehen können, die nicht in ausufernde Projektlaufzeiten, enttäuschte Erwartungen und dauerüberzogene Budgets mündet.

 

Kanban

Nun bewegen wir uns auf dem Library Layer. Hier geht es darum die Anzahl paralleler Arbeiten zu begrenzen und somit kürzere Durchlaufzeiten zu erreichen und Probleme – insbesondere Engpässe – schnell sichtbar gemacht werden sollen und ja von allen Kunden auf allen Systemen genutzt wird. Ausnahme bilden dabei gänzlich neue Library Funktionen, die entstehen anders und werden in einem Branch entwickelt. Ein Branch ist eine Verzweigung ab konfigurierten Break-Points, zu einer anderen Version, so dass unterschiedliche Versionen parallel im selben Projekt von mehreren Personen weiterentwickelt werden können. Sobald diese fertig entwickelt sind, werden diese gemergt (von Merging, Verschmelzen).

Die verschiedenen Software-Layer sind

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

 

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

  • FRONTEND
  • BACKEND
  • Modul-Layer

 

Die Basis-Layer sind auf allen Local-, Stage- & Live-System identisch - die Updates erfolgen im wöchentlichen Turnus 

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

Daraus abgeleitet arbeiten wir mit zwei konzeptionell unterschiedlichen

Ticketing-Systeme

welche ebenfalls von uns entwickelt worden sind und ständig mit neuen Features angereichert werden.

WOM

Welches für Kunden und Entwickler zugänglich ist

ProgressTracker

Welches nur für Entwickler zugänglich ist.

Ausgewählte Case Studies

Aktuelle Broschüren

IconParc Software Entwicklungsmethodik

Inhaltsverzeichnis
    Der Elevator Pitch:
    IconParc in zweieinhalb Minuten erklärt


    - oder -

    12 GRÜNDE
    Ihre digitale Lösung von IconParc entwerfen
    und bauen zu lassen
    Was auch immer Ihr Digitalisierungsvorhaben ist

    Sprechen Sie mit uns.