|
|
|
Cornu: Software-Engineering
Wir bieten Dienstleistungen im Bereich Software-Engineering an. Das ist die ingenieursmäßige, also idealerweise planvolle, technisch fundierte und nachvollziehbare Erstellung von Software.
Unser Schwerpunkt liegt dabei nicht in der direkten Implementierung von C-Funktionen, sondern der Analyse und Lösung von Aufgaben im Bereich der Erzeugung von Software aus Spezifikationen.
Wesentlich bei der Softwareentwicklung ist das Verstehen und Umsetzen der Kundenanforderungen (neudeutsch: Requirements). Dazu gibt es verschiedene Ansätze wie z.B.
Automotive SPICE, ein an CMMI und V-Modell orientierter Entwicklungsprozeß aus der Autoindustrie
RUP, ein von Rational entwickelter Prozeß, der auf UML und sogenannten Use-Cases basiert und sich besonders für die Entwicklung objektorientiertes Software eignet
TDD – Testbasierte Entwicklung, hier werden die Tests etwas vor der Software entwickelt. Bei sehr zeitkritischen Projekten ist diese Methode unbedingt empfehlenswert.
Diese Verfahren lassen sich mit gutem Erfolg kombinieren. Unsere besonder Expertise ist die Erstellung von Use-Cases in DOORs. Diese sind im Vergleich zu Einzelrequirements kompakt und gut testbar. Außerdem geben sie einen einheitlichen Rahmen vor für
Eingangsgrößen
Ausgangsgrößen
Verhalten im Fehlerfall
Erwartete Ablaufsequenzen in der Software
Darüber hinaus bringen moderne Modellierungswerkzeuge wie ASCET-SD und MATLAB/Simulink eigene Entwurfsmethoden mit und erlauben zusätzlich, Entwurfsmethoden aus den klassischen Ingenieursdisziplinen wie z.B. Regelungstechnik einzusetzen.
Unabhängig von der Entwurfsmethode ist es unabdingbar, nachzuweisen, daß die Software die Kundenanforderungen erfüllt. Dazu ist die Entwurfsmethode so auszugestalten, daß jeder Prozeßschritt nachvollziehbar mit den Anforderungen benachbarter Prozeßschritte verknüpft wird.
Dabei helfen Werkzeuge (wie z.B. DOORs), die prüfen, ob die Anforderungen in den jeweiligen Prozeßschritten berücksichtigt wurden („Traceability“). Diese Werkzeuge erstellen typischerweise Berichte über den Erfüllungsgrad von Anforderungen aus den jeweils benachbarten Prozeßschritten.
Wir bieten hier Erfahrung, wie man Probleme beim Übergang von DOORs zur SW vermeidet.
Wesentliche Eigenschaft einer Anforderung ist ihre Testbarkeit. Im Idealfall gibt es also zu jeder Anforderung mindestens einen Testfall, der die Einhaltung dieser Anforderung prüft.
Je nach gewähltem Entwicklungsprozeß wird man solche Tests durchführen für
Funktionen im Sinne von Programmcode eines SW-Moduls (Modultest)
Integration von SW-Modulen in ein Laufzeitsystem (Integrationstest)
Funktionen im Sinne des von außen beobachtbaren funktionalen Verhaltens, wie z.B. „Licht an“ (Softwaretest)
Systemverhalten wie z.B. Reaktion eines im Fahrzeug eingebauten Steuergerätes auf Kommunikationsanforderungen anderer Steuergeräte (Systemtest). Hier ist z.B. die Flashbarkeit und Diagnosefähigkeit wesentlich.
Wir haben ein effizientes System zur Erstellung von Modultests entwickelt und in etlichen Projekten eingesetzt.
Kaum etwas wird sosehr unterschätzt wie die Bedeutung einer funktionierenden Versionshandhabung in einem Entwicklerteam. Hier gibt es eine weite Spanne zwischen ineffizientem, fristierten Team mit Verlusten funktionierender Software und effektivem und störungsarmen Neben- und Miteinander der Kollegen.
Wir haben Erfahrung mit
git – effektiv und transparent, aber eher für erfahrene Entwickler
Subversion – dank komfortabler clients auch für Anfänger geeignet, aber viele Fehlermöglichkeiten bei der Konfiguration
MKS – ordentlicher Klassiker, mittlerweile etwas aufgebläht und teils merkwürdige Funktionen
Dimensions – Theoretisch das Tool für alle Anforderungen, aber in der Praxis teils ineffektiv und ohne Schulung kaum benutzbar
Subversion und git lassen sich auch kombinieren, git als lokales Repository und Subversion auf dem Server. Das funktioniert überraschend gut und ermöglicht z.B. das Weiterarbeiten an Software auch offline.
Je nach Versionskontrollsystem werden Branches unterschiedlich gehandhabt. Branches sind sinnvoll, um
Ausgelieferte Stände festzuhalten und weiterzupflegen
Funktionserweiterungen („Features“) zu realisieren
Umfangreiche Änderungen mit Auswirkungen auf das Team (z.B. Integration neuer ECU-Extract) fertigzuentwickeln, ohne das restliche Team zu stören
Entwickler in frühen Phasen eines Projektes (vor der Integration) voneinader zu entkoppeln
Die wesentliche Schwierigkeit ist dabei die Integration von Branches auf den Hauptzeig, den „trunk“.
Im AutoSAR-Umfeld ist die Versionierung von Konfigurationsdateien („ARXML“) besonders schwierig, da ARXML nicht besonders gut lesbar ist und es darüberhinaus proprietäre Formate wie z.B. das Binärformat von Vector DaVinci gibt, bei denen Versionsvergleiche nur in bestimmten Tools möglich sind. Hier ist der Ansatz von ARTOP und PRAGMA, die ARXML in eine lesbare und vergleichbare DSL (domain specific language) transformieren.