Wissen Fundiert &
praxiserprobt

Die grundsätzliche Idee hinter Agilität im Softwareengineering ist die Fähigkeit, sich flexibel, schnell und effektiv an Veränderungen anzupassen. Dies ist auch bei Software im Produkt eine wichtige Eigenschaft.

Jedoch lassen sich viele agile Praktiken, die ihren Ursprung in der IT haben, bei der Entwicklung von Embedded Software nicht eins zu eins umsetzen. Vor allem die Langlebigkeit der Produkte muss berücksichtigt werden. Nichtsdestotrotz sind die Prinzipien hinter dem agilen Manifest wie enge Zusammenarbeit, iterativ-inkrementelles Vorgehen oder ein Augenmerk auf gutes Design auch hier gewinnbringend umsetzbar.

Eine bewährte agile Methode ist Scrum.

Dokumentation ist bei Entwicklern ein eher ungeliebtes Thema. Dokumentation muss Teil der aktiven Projektkommunikation sein, sonst wird sie nur geschrieben, aber nicht gelesen. Aktualität geht im Zweifel vor Vollständigkeit. Bei den gängigen Gliederungen besteht immer die Gefahr, dass man in die Dogmenfalle tappt und meint, alle Punkte ausfüllen zu müssen, die das Template vorgibt.

Wichtig ist daher ein auf das jeweilige Projekt angepasstes Vorgehen mit einer maßgeschneiderten Struktur. Etabliert man Dokumentationsaufgaben im Prozess (z.B. in der DoD), so ist sie Teil der regelmäßigen Arbeit und wird zu einem wichtigen Baustein bei der Weiterentwicklung der Software.

Nearshoring bezieht sich in unserem Verständnis auf Dienstleistungsunternehmen im europäischen Ausland. Bei Unternehmen innerhalb der EU ist der Rechtsrahmen gegeben und kulturelle Gemeinsamkeiten erleichtern die Zusammenarbeit. Wenn man diesen Weg konsequent und mit den richtigen Methoden geht, kann man auch größere Projekte wie Modernisierungsprojekte, bei denen für einen begrenzten Zeitraum zusätzliche Entwicklungskapazität gefordert ist, gezielt umsetzen (Outsourcing).

Software im Produkt wird jahrelang weiterentwickelt und wächst mit jedem Produkt und jeder Produktvariante. Dabei werden jedoch oft Architektur und Dokumentation (= Wissensspeicher) nicht in genügendem Maße nachgezogen.

Ziel einer Modernisierung einer solchen Software muss also sein, die Zukunftsfähigkeit des Produkts wieder herzustellen um mit einer neuen Softwaregeneration neuen Anforderungen genügen zu können.

Auf dem Weg zur neuen Software muss eine Vielzahl von Einflussfaktoren wie Produktlebenszyklen, Auf-/Abwärtskompatibilität, Feature-Umfang, Skalierung, Security u.v.m. kontinuierlich berücksichtigt werden. Dies erfordert ein kompetentes, interdisziplinäres Team mit viel Erfahrung. 

Zahlreiche Unternehmen nutzen bereits zur Erhöhung der Flexibilität externe Entwicklungspartner oder holen sich einzelnen Entwickler – mit gemischtem Erfolg.

In Zeiten von Fachkräftemangel und höheren Anforderungen an Time-to-Market und Qualität favorisieren wir einen strukturierten Weg, den Unternehmen bereits mit Erfolg gegangen sind: Konsequente Nutzung externer Dienstleister im europäischen Ausland (Nearshoring) mit Umsetzungserfahrung und Kenntnis der Technologien, kombiniert mit einem kompetenten Team im Unternehmen, das die Vorgaben macht, die Qualität sichert und die externen Partner steuert.

Das Ergebnis ist eine höhere Flexibilität und Skalierbarkeit bei gleichzeitig höherer Qualität der Software.  

Produktlinien erweitern den Plattformgedanken (Softwareplattform), in dem sie die Wiederverwendung von Komponenten auf die produktspezifischen Funktionen erweitern: Wenn Produkte einer Produktlinie hohe Gemeinsamkeiten haben, lohnt sich ein Extrahieren der gemeinsamen Funktion in zentrale Komponenten. Da aber trotz der Gemeinsamkeiten auch Unterschiede bestehen, tritt der Umgang mit Varianten dieser Komponenten mittels Feature-Modellen in den Vordergrund.

Requirements Engineering (RE) umfasst das systematische Ermitteln, Abstimmen, Dokumentieren und Verwalten von Anforderungen. Ziel des RE ist die Minimierung des Risikos, dass ein System nicht den Bedürfnissen der Stakeholder entspricht. Im Produktgeschäft (siehe auch Software im Produkt) findet oftmals ein planbasiertes Requirements Engineering statt. Es werden abgestimmte Spezifikationen auf verschiedenen Abstraktionsebenen benötigt. Dies muss nicht automatisch die klassische Kombination aus Lasten- und Pflichtenheft sein. Auch bei agiler Produktentwicklung ist ein nachhaltiges Requirements Engineering erforderlich, das über transiente Artefakte wie User Stories hinausgeht

Scrum ist ein agiles Rahmenwerk für die Durchführung von Projekten. Es zeichnet sich durch ein iterativ-inkrementelles Vorgehen aus: Product Owner und Entwicklungsteam vereinbaren, welche Aufgaben aus dem Product Backlog im nächsten zwei bis vier Wochen andauernden Sprint umgesetzt werden sollen. Im Sprint Review wird das Inkrement präsentiert.

Über diese Rollen, Artefakte und Ereignisse hinaus gibt es im klassischen Scrum wenig Festlegungen. Jedoch haben sich in Zusammenhang mit diesem Begriff viele Praktiken etabliert. Einige sind auch bei der Entwicklung von Software im Produkt überaus nützlich, beispielsweise Akzeptanzkriterien, die Definition-of-Ready für Anforderungen oder die Definition-of-Done (natürlich inklusive Qualitätskriterien) für die Programmierung.

Die Sicherheit von Daten und Funktionen gegen unbefugten Zugriff ist bisher vor allem in der IT und dem KRITIS-Bereich bearbeitet worden. Mit der Verabschiedung des Cyber Resilience Acts müssen nun auch die meisten Produkthersteller ihre Produkte gegen Angriffe schützen und dies nachweisen. Dies betrifft die Prozesse im Unternehmen (Meldepflichten, Regulatorik), aber vor allem auch zusätzliche Prozessschritte in der (Produkt)Softwareentwicklung (Stichwort: Secure Development Life Cycle) mit weitreichenden Auswirkungen auf System- und Softwarearchitektur.

Wir verwenden diesen Begriff für Software, die direkt mit dem Lebenszyklus eines physischen Produkts in Verbindung steht: Embedded Software, Firmware, aber auch technische Software im direkten Produktumfeld wie Messauswertesoftware, Parametriersoftware o.ä.

Da diese Produkte sich in vielerlei Hinsicht von klassischen IT-Lösungen im Rechenzentrum (oder in der Cloud) unterscheiden, fokussieren wir unsere Beratungsleistungen auf die Verbesserung dieser Software und der Prozesse, die zu Ihrer Entstehung führen.

Für den Begriff Softwarearchitektur gibt es zahlreiche Definitionen. In unserem Verständnis ist Softwarearchitektur die Summe wichtiger Entscheidungen. Softwarearchitektur beschreibt vor allem die Strukturen und Konzepte, die nicht einfach änderbar sind. Wir grenzen Softwarearchitektur damit vom Code Design ab, bei dem es eher um Klassen, Packages u.v.m. geht. In der Dokumentation von Softwarearchitektur finden sich daher eher beschreibender Text, wenige High-Level-Diagramme und nur wenige detailreiche UML-Diagramme.

Die Produkte unserer Kunden sind üblicherweise sehr langlebig (vgl. Software im Produkt), daher kommt es auf eine belastbare und zukunftsfähige Softwarearchitektur an, die alle Änderungen im Lebenszyklus des Produkts mitgehen kann. Wenn im Laufe der Zeit die Softwarearchitektur nicht mehr hinreichend an die Zukunftsanforderungen angepasst wird oder werden kann, benötigt die Software eine Modernisierung.

Der Begriff Softwareengineering meint lt. Helmut Balzert, die „Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.“ Softwareengineering umfasst zwar die Softwareentwicklung, fokussiert aber vor allem die für große Projekte notwendigen Disziplinen

• Projektmanagement
• Risikomanagement
• Qualitätsmanagement
• Requirements Engineering = Fachliche Konzeption
• Softwarearchitektur / Systemdesign / Technische Konzeption
• Softwaretest
• Softwareeinführung
• Softwarewartung und -pflege

Das Beherrschen der entsprechenden Methoden ist für jede Software entwickelnde Organisation essenziell. Für den Produkthersteller kommen durch den anders gelagerten Lebenszyklus und die typischerweise mangelnde digitale Verbindung zum Gerät neue Herausforderungen hinzu, die mit den aus der klassischen IT entstandenen, gängigen Lehrbuch-Methoden nicht 1:1 abgeleitet werden können.

Eine Softwareplattform ist ein zentraler Mechanismus der Softwarewiederverwendung. Eine Softwareplattform enthält typischerweise wiederverwendbare und konfigurierbare Komponenten in den unteren Schichten einer Schichtenarchitektur und kann für verschiedene Produkte eingesetzt werden. Auf der Plattform wird die jeweilige Software für die Produkte aufgesetzt und die Plattform. Vorteil der Plattform ist die Wiederverwendung einer aufeinander abgestimmten Menge von generischen Komponenten.