Embedded GUI Best Practices der toolgestützten Entwicklung

Schwachstellen im Prototyping

Auf Hardware-Seite

  • Die Initial-Hardware ist zu teuer, zu alt, zu langsam oder bietet nicht die notwendige Funktionalität.
  • Bei einem Hardware-Wechsel (im Projekt oder mit der nächsten Produktversion), können die verwendeten Software-Komponenten eine zu große Abhängigkeit zur Hardware aufweisen. Die Portierung gestaltet sich dann schwierig, ein großer Software-Teil bedarf einer Neuentwicklung.
  • Die finale Hardware ist zum Start der Software-Entwicklung noch nicht verfügbar. Die Parallelisierung der Entwicklungsprozesse ist allerdings zwingend notwendig, um einen straffen Zeitplan einhalten zu können.
  • In einigen Fällen sind zwei oder mehrere, unterschiedliche Plattformen mit der gleichen Software zu versorgen. Zum Beispiel soll für den Showcase das GUI nur auf einem Tablet oder Smartphone die Bedienbarkeit und Funktion der Maschine, ohne den potenziell tonnenschweren Maschinenkorpus, demonstrieren.

Plattformunabhängige Software-Komponenten lösen diese Probleme grundsätzlich. Diese Plattformunabhängigkeit muss von der Entwicklungsumgebung gewährleistet werden. Beim toolbasierten Entwicklungsprozess sollte daher das Tool selbst die Möglichkeit bieten,
GUIs unabhängig von der späteren Zielplattform zu entwickeln.

Eine abstrakte Zwischenschicht leistet dabei Hilfe.

Im Funktionsumfang

  • Der Softwarestand des realisierten Prototyps zeigt offensichtlich nur einen Ausschnitt der Funktionalität des späteren Endprodukts. Für weitere, erst im späterem Projektverlauf spezifizierte Funktionalität, kann die Initial-Hardware schlecht erweiterbar ausfallen: das gestaltet die Software schwer pflegbar und kompliziert.
  • Ein zeitkritischer Prototyp könnte auch nur als Mock-Up bzw. Click-Dummy implementiert sein. Dann wurden Hardware und/oder Middleware nicht angebunden und die etwaige Anbindung ist nicht kanonisch.
  • Ein ähnliches Problem zeigt der Ort der implementierten Logik: Gibt es eine klare Trennung von GUI und Logik oder wurde ein Großteil der Logik innerhalb der graphischen Benutzeroberfläche umgesetzt?
  • Aber auch nicht-funktionale Anforderungen können die GUI-Entwicklung behindern. Beispielsweise wenn eine neue Applikation für ein Produkt eine zusätzliche Spracherweiterung fordert. Die schnellste Umsetzung mit der bestehenden Software-Struktur ist dann fragwürdig.

Solche Hindernisse, die während oder nach der Entwicklung auf den Software-Entwickler zukommen, können gut eliminiert werden, sofern bereits zu Beginn eines Projekts ausreichend Zeit für die Konzeptarbeit eingeräumt wird. Die Architektur und Struktur der neu zu implementierenden Software sollte klar sein, bevor mit der eigentlichen Implementierung begonnen wird. Dazu ist es notwendig, Dinge, die sich logisch voneinander trennen lassen, zu identifizieren und entsprechend zu separieren: Das Aussehen, die Geschäftslogik, die einzelnen UI Komponenten (Buttons, Listen, Menüs, Dialoge, ...), String-Literale (für die Unterstützung von mehreren Sprachen), etc.