Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen

Variante 4: Viel IP im Spiel, komplexe Anforderungen, Dokumentation existenziell – das ganz große Paket

Diese Variante basiert auf folgenden Anforderungen:

• Hardware Architektur: Für das Projekt sind in mittelgroße Stückzahlen (ca. 1000 pro Jahr) geplant, der Endpreis liegt bei ca. 5000 €. Damit fallen die Kosten für die Rechner-Architektur nur schwach ins Gewicht und sind gegenüber anderen Kosten (z.B. Personalaufwand) zu vernachlässigen. Speicher und Rechenleistung stehen in ausreichendem Umfang zur Verfügung.
• Echtzeitanforderungen: Es gibt Nebenläufigkeiten mit hohen Echtzeitanforderungen. Der Hauptanteil der Applikation hat jedoch vernachlässigbare Echtzeitanforderungen.
• Intellectual Property (IP): In dem bisherigen und zukünftigen Produkt steckt ein großer Anteil an IP. In der Unternehmensgeschichte haben die direkte Zusammenarbeit mit Kunden und das Design der Funktionalität dicht an deren Bedürfnissen zur Marktführerschaft verholfen. Die Informationen über viele Lösungsansätze und Funktionen stecken überwiegend in den Köpfen der Entwickler. Das macht es immer wieder schwierig, neue Mitarbeiter in die Entwicklung zu integrieren. Aus demselben Grund scheuten die Verantwortlichen bisher den Schritt einer Neuentwicklung immer wieder, da Umfang und Risiko eines neuen Ansatzes schlecht abzuschätzen sind. Zukünftig sollen diese Informationen daher besser dokumentiert werden. Inzwischen lässt sich die alte, sehr wenig strukturierte Software nicht mehr effizient warten und ändern. Die Problematik liegt nicht so sehr darin, dass ein komplett neues Produkt benötigt wird, sondern darin, dass die Entwicklungsabteilung die permanente Weiterentwicklung auf Basis der existierenden Software nicht mehr gewährleisten kann. Daher fiel die Entscheidung, parallel zum alten Produkt mit einer Neuentwicklung zu starten.

• Lebensdauer des Produktes: Für das Produkt setzen die Verantwortlichen eine Lebensdauer von zehn Jahren an, das aktuelle Produkt ist seit 17 Jahren auf dem Markt. Erfahrungsgemäß steigen die Anforderungen in dieser Zeit kontinuierlich. Weiterentwicklungen müssen auf Basis von ausgelieferten Produkten geschehen, Wartbarkeit und Erweiterbarkeit müssen über den ganzen Lebenszyklus gesichert sein.
• Time To Market: Es gibt keinen konkreten Zeitplan. Eher ist zu überlegen, wie Neuentwicklung und Pflege des aktuellen Produktes ineinander überfließen können und wie viel Sinn es hat, alte Sourcen wiederzuverwenden.
• Qualität: Ausfälle des Systems können zu Regressansprüchen in großer Höhe führen. In der Vergangenheit gab es immer wieder Qualitätsprobleme, die aber immer glimpflich verlaufen sind. Dieser Zustand ist künftig zu verbessern. Ebenso ist in Bezug auf eine mögliche anstehende Zertifizierung gegen die IEC 61508 Vorsorge zu treffen.
• Erfahrung: Mit der Anwendung der Hochsprache ANSI-C auf verschiedenen Hardwareplattformen ist Erfahrung vorhanden, jedoch nicht mit der ARM-Architektur. Es gibt keine Erfahrung mit dem Einsatz eines RTOS oder anderer Werkzeuge zum Architekturdesign. Für das Konfigurationsmanagement ist »Telelogic Synergy« im Einsatz, es wurde bereits entschieden, »Telelogic Doors« als Requirement-Engineering-Tool einzuführen.
• Budget: Das Management ist sich dessen bewusst, dass das Software Engineering existentiell für das Unternehmen ist. Es ist bereit für größere Investitionen, wenn sich IP und Qualität damit sichern lassen.

Und so sieht der Vorschlag einer Entwicklungsumgebung aus, welche sich an den obigen Anforderungen orientiert:

Diese Umgebung, die den derzeitigen Stand der Technik abdeckt, umfasst alle Komponenten der Variante 3. Aufgrund der noch höheren Qualitätsansprüche wird die Umgebung um die Automatisierung von Tests auf Modellebene erweitert, so genannte Regression Tests. In einem weiteren Schritt lässt sich schon in einer sehr frühen Projektphase die Simulation der Architektur auf Basis eines Web Interfaces durchführen. Bereits nach kurzer Zeit kann der Entwickler auf Basis des so genannten MDD-Ansatzes (Model Driven Development) ein ausführbares Modell erstellen, auf dem sich erste Acceptance Tests beispielsweise mit Anwendern oder dem Produktmarketing durchführen lassen. Ebenso eignet sich das Modell für Schulungen des Technischen Personals, um den Umstieg von alten System zum neuen vorzubereiten.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

---

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

1. Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen
2. Andreas Willert
3. Diese Tools sind immer ratsam
4. Variante 4: Viel IP im Spiel, komplexe Anforderungen, Dokumentation existenziell – das ganz große Paket
5. Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen
6. Variante 3: Große Komplexität, viele Änderungen – Hier kommt die UML ins Spiel
7. Variante 2: Viele Tasks, hoher Qualitätsanspruch – C reicht gerade noch aus, aber ein RTOS muss sein