Ein Ansatz zur Qualitätsbewertung von modellbasierten Entwicklungsprojekten eingebetteter Software

Transkript

1 Ein Ansatz zur sbewertung von modellbasierten Entwicklungsprojekten eingebetteter Software H. Pohlheim, I. Stürmer, E.Salecker Model Engineering Solutions GmbH Friedrichstr Berlin {pohlheim stuermer Abstract: Im Automobilbereich hat sich die modellbasierte Entwicklung eingebetteter Software industriell etabliert. Bei der herkömmlichen, d.h. codebasierten Softwareentwicklung, ist es üblich die und Indikatoren für den Erfolg des Projekts anhand der und des Umfangs des erzeugten Codes zu messen und zu bewerten. Bei der modellbasierten Entwicklung bietet es sich an, auch die Modelle in die sbewertung mit einzubeziehen. In diesem Paper diskutieren wir Vorgehensweisen und Metriken, die in die sbewertung von Software- Modellen und des daraus generierten Codes mit einbezogen werden sollten. Das hierfür benötigte smodell und die daraus sich ableitenden soperationen werden erläutert. Wir zeigen die Vorgehensweise anhand des Tools MQAC (Model Quality Assessment Center), das wir für die sbewertung von modellbasierten Software-Projekten entwickelt haben und zeigen prototypische Anwendungsbeispiele aus der Praxis. 1 Einleitung Die modellbasierte Entwicklung eingebetteter Steuerungs- und Regelungssoftware für das Automobil ist durch den durchgehenden Einsatz ausführbarer Modelle in allen Entwicklungsphasen charakterisiert. Modellierungs- und Simulationswerkzeuge, die hier weite Verbreitung gefunden haben, sind z.b. die datenfluss-orientierte Modellierungssprache Simulink und die zur Modellierung von Zustandsautomaten verfügbare Erweiterung Stateflow von The MathWorks [1]. Codegeneratoren wie TargetLink von dspace [2] erlauben es, automatisch effizienten C Code direkt aus diesen Modellen zu generieren. Immer häufiger wird der generierte Code in sicherheitsrelevanten Systemen im Automobil eingesetzt. Die des generierten Codes ist mittlerweile ein wesentlicher Erfolgsfaktor für Software-Projekte geworden, da Software-Fehler schwerwiegende finanzielle als auch körperliche Schäden verursachen können. Die des generierten Codes resultiert unmittelbar aus der der Modelle, die für die Codegenerierung verwendet werden. Daher ist es wichtig, qualitätssichernde Maßnahmen möglichst früh im Entwicklungsprozess, d.h. bereits auf Modellebene durchzuführen.

2 Die Absicherung der zu entwickelnden Funktion bereits auf Modellebene ermöglicht es systematisch Fehler frühzeitig aufzudecken und führt zur signifikanten Kostenreduzierung der ssicherung, insb. bei der Fehlerfindung und beseitigung [3]. Die wichtigsten qualitätssichernden Maßnahmen, die Anwendung bei der modell-basierten Entwicklung und automatischen Codegenerierung von Software im Automobil finden, werden in [4] erläutert und hier nicht weiter vertieft. Ansätze zur Messung der Modellkomplexität, die in diesem Beitrag zur Anwendung kommen sind in [5] beschrieben. Abbildung 1: Modell- und Code-Absicherung in der modellbasierten Entwicklung Das Grundprinzip der Modell- und Codeabsicherung bei der modellbasierten Entwicklung ist in Abb. 1 gezeigt. In einer frühen Entwicklungsphase werden die aus den funktionalen Anforderungen abgeleiteten Modelle dahingehend überprüft, ob diese den Anforderungen entsprechen (Modell-Absicherung). Dies erfolgt bereits, bevor der generierte Code vorliegt. Es werden hier konstruktive und analytische smaßnahmen angewendet wie z.b. (1) Anwendung von Modellierungsrichtlinien; (2) Reviews der Anforderungen und des Modells; (3) Simulation bzw. dynamisches Testen des Modells. In einer späteren Entwicklungsphase wird das Anforderungsmodell in ein Implementierungsmodell überführt, d.h. um Informationen für die Codegenerierung angereichert, wie z.b. Datentypen, Auflösung/Skalierungen, Funktionsaufteilung. Aus dem Implementierungsmodell wird anschließend Code generiert, der auf unterschiedlichen Teststufen abgesichert wird (Modultest, Integrationstest, Systemtest, usw.). Mit den ssicherungsmaßnahmen auf Codeebene (Code-Absicherung) wird festgestellt, ob (1) der Code dem Verhalten des Modells entspricht und; (2) ob der Code den Anforderungen an die Implementierung, wie z.b. max. Ausführungsgeschwindigkeit, entspricht. Im Laufe der Modell-/Code-Entwicklung und deren Absicherung entstehen unterschiedliche Artefakte, die für die sbewertung des Modells, des Codes bzw. des gesamten Entwicklungsprojektes relevant sind. Wichtige Artefakte sind z.b.: (1) Textuelle Anforderungen (2) die Modelle selbst (Anforderungs- und Implementierungsmodell), (3) Testspezifikation, -implementierung und -berichte; (4) Review-Berichte für Anforderungen, Modell, Code; (5) Issue- bzw. Bug-Reports; usw. Hinzu kommen Berichte unterschiedlicher Werkzeuge, die Metriken bzw. Kennzahlen liefern. Beispiele solcher Berichte sind z.b. solche über (1) Einhaltung von Modellierungsrichtlinien; (2) Modell- und Code-

3 Coverage; (3) Testabdeckung der Anforderungen; (4) Komplexitätsmessung des Modells und des Codes; usw. Für die sbewertung von modellbasiert entwickelten Software-Produkten hat sich noch keine einheitliche Vorgehensweise etabliert. Wir haben dabei mehrere Probleme identifiziert. (1) Die sbewertung ist oftmals fokussiert auf einzelne smaßnahmen z.b. Tests im Fahrzeug, d.h. das Spektrum an verfügbaren ssicherungs-methoden wird nur unzureichend oder sehr unsystematisch genutzt. (2) Die erhobenen Daten sind verteilt vorhanden. So dokumentiert z.b. der Modellierer die Durchführung von Richtlinien-Überprüfungen, während der Tester die Testberichte erstellt. (3) Die Zusammenführung, Aggregation und Dokumentation der Ergebnisse muss manuell vorgenommen werden und erfolgt oftmals nur punktuell. (4) Eine systematische Verfolgung von Entwicklungstendenzen und ein Vergleich über verschiedene Projekte hinweg sind aufgrund der zuvor genannten Punkte schwierig. (5) Vorhandenes Erfahrungswissen, das von Praktikern in erfolgreichen Projekten eingesetzt wird, wird nur unzureichend kommuniziert. Um die genannten Probleme zu lösen, haben wir (1) die aus der klassischen Software-Entwicklung bekannte Vorgehensweise für die Bewertung und Kontrolle eines entstehenden Produktes für die modellbasierte Entwicklung adaptiert und (2) ein smodell für die modellbasierte Entwicklung entwickelt. Der von uns adaptierte Prozess der sbewertung wird durch das von uns entwickelten Model Quality Assessment Center (MQAC) implementiert, in welches das von uns vorgeschlagene smodell integriert ist. In die Entwicklung der adaptierten Vorgehensweise für die sbewertung und das smodell sind unsere Erfahrungen aus zahlreichen Projekten eingeflossen. In den folgenden Kapiteln werden wir zeigen, wie sich Aussagen über die aktuelle der zu entwickelnden Software treffen lassen, welche Rolle die Wahl geeigneter soperationen dabei spielen und welchen Einfluss der Umsetzungsgrad bzw. Abdeckung der Anforderungen durch bestimmte soperationen auf die Gesamtqualität hat. 2 sbewertung in Software-Projekten Die prinzipielle Vorgehensweise zur sbewertung ist in Abb. 2 gezeigt. Als Basis der Bewertung werden Artefakte, die im Laufe des Entwicklungsprozesses entstehen, nach bestimmten Kriterien kategorisiert. Die Artefakte sind typischerweise Quellcode, Anforderungsdokumente und Modelle. Ein mögliches Kriterium für die Strukturierung der Artefakte ist z.b. der Automatisierungsgrad der anzuwendenden soperationen. Im zweiten Schritt wird das smodell für das Projekt festgelegt, auf dessen Basis die Artefakte analysiert und bewertet werden. Hier werden die anzuwendenden soperationen und die jeweils zugehörigen Metriken definiert. Ein Ansatz, wie ein smodell für Simulink Modelle entwickelt und angewendet werden kann, ist in [6] beschrieben. Bekannte smodelle (vgl. Kapitel 3) unterscheiden sich von unserer Vorgehensweise dadurch, dass diese einzelne Aspekte wie z.b. Wartbarkeit, Testbarkeit, Lesbarkeit, in den Vordergrund stellen und nur die für diesen Aspekt relevanten Metriken berücksichtigen. Unser smodell ist flexibel, so dass der Anwender die Möglichkeit hat, eine projektspezifische Adaptierung vorzunehmen. Diese Adaptierung erfolgt durch

4 die Integration der im jeweiligen Projektkontext benötigten soperationen. soperationen sind alle Tätigkeiten, die zur Bewertung der eines entstehenden Produktes angewendet werden wie z.b. Reviews der Anforderungsdokumente oder der Testspezifikation, Prüfung der Einhaltung von Modellierungsrichtlinien, Durchführung von Modellreviews und -tests. Beispielsweise fassen wir auch die Traceability der Safety Requirements von den Anforderungen zum Modell und zum Test als soperation auf. Projekt sbewertung Bewertung der Artefakte aus saktionen und Metriken Aggregation aller Werte zu einem Gesamtbild Bewertung der Abdeckung (Coverage) Bewertung Artefakte Modell Dokument Metriken Metrik 1 Metrik 2 soperationen Aktion A Aktion B s-modell Quantitative Erhebung von skennzahlen aus den Artefakten Messung der Abdeckung (Coverage) Artefakte Modell Dokument Projekt Auswahl und Strukturierung der Artefakte Abbildung 2: Prinzip der sbewertung von Software-Projekten Die modellbasiert entwickelter Software-Produkte unterliegt vielen Einflussfaktoren die sich anhand typischer Fragen, die im Rahmen der sbewertung aufkommen, identifizieren lassen. Zu diesen Fragen gehören die nachstehend aufgezählten. Wie viele Tests sind spezifiziert? Wie viele der spezifizierten Tests sind implementiert? Wie viele der Tests laufen fehlerfrei (passed/failed Verhältnis) Wie viele der Anforderungen sind durch Tests abgedeckt? Wie viele der Anforderungen sind im Modell umgesetzt? Wie viele Safety-Anforderungen sind umgesetzt / getestet? Wie viele der Modellierungsrichtlinien sind im Modell eingehalten? Wie viele Modellteile sind leicht erweiterbar und nicht zu komplex? Wie viele Modellteile sind durch Tests abgedeckt? Wie viele Anmerkungen (Issues) aus dem Modell-Review liegen vor? Abb. 3 zeigt die Faktoren, die wir aufgrund unserer Erfahrungen als die wichtigsten ansehen. Die eines Modells, das zum SW-Design und zur Codegenerierung verwendet wird, durch vier wesentliche Faktoren beeinflusst: (1) Der Umfang und die der Anforderungen, (2) der Umfang und die Intensität der Modellanalyse; (3)

5 der Umfang und die Intensität bzw. Tiefe des Testens; sowie (4) die Aufzeichnung und Nachverfolgung aufgekommener Anmerkungen (Issues) und Fehler (Bugs). Abbildung 3: Einflussfaktoren auf die Modellqualität Diese Faktoren müssen einerseits alleinstehend bewertet werden, andererseits aber auch im Zusammenhang betrachtet werden. 1. Requirementsanalyse: Es ist zunächst wichtig zu wissen, in welchem Umfang die Anforderungen im Modell umgesetzt wurden. Ziel ist es, 100% der Anforderungen im Modell umzusetzen. Eine Aussage, dass 80% der textuellen Anforderungen bereits umgesetzt sind, mag einen Projektleiter beruhigen. Aber man sollte im Hinterkopf behalten, dass oftmals aus Zeitgründen zuerst die einfachen Anforderungen umgesetzt, bevor komplexere Probleme gelöst werden. Somit ist die einer Anforderung ein entscheidender Faktor, um einen aussagekräftigen Umsetzungsgrad zu erhalten. Eine einfache Methode, um dies zu berücksichtigen ist z.b. die zahlenmäßig Gewichtung der Anforderungen oder eine Einteilung in Kategorien wie z.b. leicht, mittel und schwer implementierbar. 2. Modellanalyse: Die Modellanalyse umfasst Komplexitätsmessungen und Überprüfung von Modellierungsrichtlinien. Ersteres beinhaltet die zahlenmäßige Erhebung der Komplexität und Modellierungstiefe (Subsystemhierarchie) über Metriken Eine Erweiterung hierzu ist die Gewichtung der Subsysteme über die Komplexität. Vorgehensweisen hierzu werden in [5] erläutert. Letzteres dient der Überprüfung, in welchem Umfang das Modell gängigen sowie firmen- oder projektspezifischen Modellierungsrichtlinien entspricht. Zusätzlich kann die Anzahl der Verletzungen pro Subsystem in Verbindung mit der Komplexität des jeweiligen Subsystems betrachtet werden. 3. Testmanagement: Das Testmanagement muss unterschiedliche Fragen beantworten können, beispielsweise (1) wie viele Tests sind spezifiziert; (2) wie viele Tests wurden implementiert; (3) wie viele der Tests wurden erfolgreich ausgeführt (Ziel:

6 100% passed); (4) wie viele haben einen Fehler erzeugt (fail); (5) wie viele Testfälle decken bzw. testen wie viele Anforderungen ab. Um eine effiziente Bewertung der zu ermöglichen, sollten insbesondere Methoden eingesetzt werden, für die Werkzeugunterstützung vorhanden ist. In Abb. 4 sind Beispiele von Werkzeugen gezeigt, die für die identifizierten Einflussfaktoren eingesetzt werden. Die Werkzeuge stehen hier stellvertretend für die zahlreichen auf dem Markt für die unterschiedlichen Aufgaben verfügbaren. Gezeigt sind die Werkzeuge, die unserer Erfahrung nach im Rahmen der modellbasierten Entwicklung auf Basis von Simulink in Verbindung mit TargetLink [2] am häufigsten bei den OEMs und Zulieferern der Automobilindustrie eingesetzt werden. Ausgenommen von dieser Betrachtung sind firmenspezifische Werkzeuge, die nicht frei auf dem Markt verfügbar sind. Abbildung 4: Werkzeuge zur sermittlung Zur Verwaltung der textuellen Anforderungen werden häufig komplexe Werkzeuge wie IBM Rational DOORS 1 oder MKS 2 eingesetzt, aber auch der Einsatz von MS Word oder MS Excel sind üblich. Zur Modellanalyse werden auf die Toolkette zugeschnittene Werkzeuge zur Modellanalyse eingesetzt. Die Komplexitätsmessung erfolgt entweder über die Simulink V&V Toolbox [1], welche die Anzahl der im Modell verwendeten Blöcke sowie die zyklomatische Komplexität auf Modellebene berechnet, oder M-XRAY 3 [5] welches darüber hinaus das Modellvolumen sowohl des Gesamtmodells als auch individuell für.jedes Subsystem berechnet. Bei der Überprüfung der Modellierungsrichtlinien werden schwerpunktmäßig für Serienprojekte: (1) für reine Simulink Modelle, aus denen Seriencode mit dem Real-Time Workshop/Embedded Coder erzeugt werden soll, der Simulink Model Advisor [1]; (2) für TargetLink Modelle der Model Examiner 4 [7] eingesetzt. Zur Analyse des generierten Codes oder der manuell imple

7 mentierten Codeanteile wird insbesondere in sicherheitsrelevanten Projekten der Polyspace Design Verifier eingesetzt. Die Einhaltung von Code-Richtlinien wie z.b. MISRA C werden meistens durch QAC 5 überprüft. Das Angebot von Testwerkzeugen für die hier betrachtete Toolkette ist umfangreich, jedoch überschaubar, wo diese Werkzeuge für Serienprojekte eingesetzt werden. Hier hat sich TPT 6, Embedded Tester 7, sowie MTest classic 8 bei den am Markt verfügbaren Werkzeugen durchgesetzt. Für das Issue- bzw. Bugtracking werden unterschiedlichste Lösungen eingesetzt, die häufig aus Open-Source Projekten stammen wie z.b. Bugzilla und Redmine. MQAC-smodell Eine umfangreiche sbewertung erfordert es, die sehr heterogenen Ergebnisse der unterschiedlichen Werkzeugen zu aggregieren, und zu einem Gesamtbild zu verdichten. Um dies zu ermöglichen, werden in unserem smodell die Bewertungssysteme der einzelnen soperationen auf ein vierstufiges Bewertungssystem abgebildet. Unser vierstufiges Bewertungssystem erweitert das in der Praxis verwendete dreistufige System mit den Werten gut-akzeptabel-ungenügend um den Wert unbekannt. Dieser vierte Wert ermöglicht es, bei der sbewertung auch zu berücksichtigen, ob geplante soperationen noch nicht durchgeführt wurden. Abbildung 5: Aggregation von Metrik(werten) einer soperation In Abb. 5 ist unser Verfahren zur Berechnung von swerten für die Anwendung einer soperation auf ein Artefakt gezeigt. Hier wird der swert eines Artefaktes über den Mittelwert der Ergebnisse berechnet, die durch die soperation erhoben wurden. Die Metrik kann hier Zahlenwerte für unterschiedliche Metrikwerte wie unknown, bad, acceptable oder good liefern. Die einzelnen Zahlen, die für diese Metrikwerte erhoben wurden, werden auf einen swert für den jeweiligen Metrikwert abgebildet. So werden beispielsweise den vier Metrikwerten die Werte unknown=0, bad=0.2, acceptable=0.8 und good=1 zugeordnet. Daraus ergibt sich der treppenstufige Verlauf des swerts, der als durchgängige Linie dargestellt ist. Konti

8 nuierliche Verläufe können bei Bedarf wie hier gezeigt durch die gestrichelte oder gepunktete Linie dargestellt werden. Die swerte für die einzelnen soperationen berechnen sich dann über den Mittelwert der einzelnen Metrikwerte (siehe Formel in Abb. 5). Die einzelnen Metrikwerte i können bei Bedarf noch unterschiedlich gewichtet werden, mit Werten weight i 0 und 1 und ergeben so einen gewichteten Mittelwert. swert Odometer (gesamt) = * * 0.74= 0.89 Bewertung Artefakt Gewicht = 0.8 Gewicht Guidelines= 0.2 Modell Odometer swert: = 0.93 (80 * * * 0) / 87 = 0.93 swert: Guidelines = 0.74 (68 * * * * 0) / 109 = 0.74 Metriken + Bewertung Odometer Ergebnis: Passed (good): 80 Failed (bad): 5 Unknown: 2 Guidelines Odometer Ergebnis: Passed (good): 68 Warning (acceptable): 7 Failed (bad): 34 Not executable (unknown): 0 soperationen Überprüfung Modellierungsrichtlinien Artefakt Modell Odometer Abbildung 6: Beispiel: Berechung des swerts für das Modell Odometer Diese Vorgehensweise zur Berechnung von swerten soll an einem Beispiel erläutert werden (siehe Abb. 6). Hier soll der swert für das Simulink Modell Odometer berechnet werden. Für das Modell wurden (1) der und (2) die Überprüfung von Modellierungsrichtlinien durchgeführt. Die Ergebnisse der beiden soperationen sind wie folgt: (1) : im Rahmen des s wurden insgesamt 87 Testfälle ausgeführt. 80 lieferten das Ergebnis passed, 5 den Wert failed und 2 lieferten ein ungeklärtes (unknown) Ergebnis. Um die Ergebnisse auf den Graphen in Abb. 5 abzubilden werden diese auf das MQAC-Ampelsystem zugeordnet und gewichtet: passed=good (1), failed=bad (0.2), unknown=unknown (0). Der swert von 0.93 für den wird mithilfe der Formel in Abb. 5 berechnet; (2) die Überprüfung der Modellierungsrichtlinien wurde äquivalent durchgeführt. Insgesamt wurden 109 Modellierungsrichtlinien am Modell überprüft. 68 lieferten das Ergebnis passed, 7 den Wert warning, 34 den Wert failed und 0 lieferten ein ungeklärtes (unknown) Ergebnis. Die Abbildung auf das MQAC-Ampelsystem ist wie folgt: passed=good (1), warning=0.8, failed=bad (0.2), unknown=unknown (0). Als Ergebnis wird die Überprüfung des Modells auf Richtlinienkonformität mit 0.74 bewertet. Für die Aggregation der Ergebnisse wird hier dem eine höhere Bedeutung bzw. Gewichtung als der Richtlinienprüfung beigemessen, d.h. der wird mit 0.8, die Richtlinienprüfung am Modell mit 0.2 gewichtet. Damit ergibt sich eine Gesamtqualität des Modells Odometer zum Zeitpunkt t i von Es ist durchaus üblich, alle soperationen gleichwertig zu gewichten. Durch die Gewichtung der soperationen ist es z.b. in sicherheitsrelevanten Projekten möglich die Abdeckung der Safety-Requirements besser zu berücksichtigen. Die am Beispiel gezeigte Methodik kann dahingehend erweitert

9 werden, dass die einzelner Artefakte (Modelle) bzw. Versionen eines Modells zu einer Gesamtbewertung des Projekts über die Zeit aggregiert werden. Modellkomplexität sbewertung (Aggregation) Projekt Bewertung soperationen Bewertung s-aktionen Bewertung Artefakte Modell 1 Modell n Guidelines Versionen Metriken Modell 1 Modell 2 Modell n Guidelines Modell 1 Guidelines Modell 2 Guidelines Modell n s- Modell soperationen Modellierungsrichtlinien (Guidelines) Artefakte Modell 1 Modell 2 Modell n Projekt Abbildung 7: Aggregation von swerten zur sbewertung Die allgemeine Vorgehensweise, wie swerte zur sbewertung eines Projektes aggregiert werden ist in Abb. 7 exemplarisch gezeigt (vgl. auch Abb. 2). Dabei kommen beispielhaft wieder der und die Richtlinienprüfung zum Einsatz, wobei alternative soperationen wie Reviews, Codeanalysen analog integriert werden. Ähnlich wie im Beispiel in Abb. 6 werden die Metriken der einzelnen soperationen zu einer Gesamtbewertung aggregiert. Die sbewertung ergibt sich auch hier aus dem gewichteten Mittelwert der einzelnen soperationen. Bei einer Betrachtung mehrerer Versionen der Artefakte über die Projektlaufzeit (vgl. Abb. 7, oben rechts) lässt sich der Verlauf der aufzeichnen und beobachten (hier: Projektversion v56... v67 mit den entsprechenden swerten). 3 Verwandte Arbeiten Ein generisches smodell stellt der Goal-Question-Metric-Ansatz (GQM) dar [8]. Hierbei wird wie bei der Verwendung eines FCM-Modells (Factors, Critera, Metrics) die von Software bzw. Modellen objektiv erfassbar. Weitere ähnliche Softwarequalitätsmodelle sind bspw. [9] und die ISO Allen gemeinsam sind Faktoren wie Zuverlässigkeit, Effizienz, Wartbarkeit und Portierbarkeit. Einen Ansatz zur sbewertung von UML-Modellen wird in [10] beschreiben in. Hier wird zwischen Entwicklung und Wartung unterschieden, da in den jeweiligen Phasen andere skriterien relevant sind.

10 4 Zusammenfassung Wir haben ein Verfahren zur sbewertung von modellbasiert entwickelten Software-Systemen vorgestellt. Unser Verfahren basiert darauf, dass die Ergebnisse unterschiedlicher ssicherungsmethoden einheitlich betrachtet werden. Neben der rein quantitativen Erhebung von soperationen werden auch Zusammenhänge zwischen Artefakten zur Bewertung herangezogen, wie z.b. der Umsetzungsgrad von Anforderungen im Modell oder deren Abdeckung durch den. Für die empirische Evaluierung unseres smodells gibt es aufgrund der im Kapitel 1 beschriebenen Probleme der sbewertung in der modellbasierten Entwicklung keine ausreichenden Daten. Unser Werkzeug MQAC, das bereits in Kundenprojekten eingesetzt wird, ermöglicht es, diese Daten systematisch zu erheben und zu verwalten. Dies wird eine umfassendere Evaluierung des von uns vorgeschlagenen smodells ermöglichen. Unser Verfahren lässt sich aus unserer Sicht zukünftig dahingehend erweitern, dass projektspezifische quantitative Kennzahlen wie z.b. Aufwandsabschätzungen, Speicherverbrauch, Objektcodegröße, in die Berechnungen mit einfließen können. Hierdurch lassen sich Aufwände für die Umsetzung von Anforderungen, für die Testimplementierung, Testdurchführung und die Einhaltung von Vorgaben für das Projekt abschätzen und kalkulieren. 5 Literaturverzeichnis [1] MathWorks, (product information) [2] dspace: TargetLink Production Code Generator at [3] Broy, M., Kirstan, S., Krcmar, H., Schätz, B.: What is the Benefit of a Model-Based Design of Embedded Software Systems in the Car Industry?, in Rech, J., and Bunse, C. (Hrsg.) Emerging Technologies for the Evolution and Maintenance of Software Models, pp , [4] Fey, I., and Stürmer, I.: Quality Assurance Methods for Model-based Development: A Survey and Assessment, SAE World Congress, SAE Doc. # , Detroit, Also appeared in SAE 2007 Transactions Journal of Passenger Cars: Mechanical Systems, V116-6, Aug [5] Stürmer, I., Pohlheim, H., Rogier, T.: Berechnung und Visualisierung der Modellkomplexität bei der modellbasierten Entwicklung sicherheitsrelevanter Software, in Keller, B. et. al. (Hrsg.), Automotive - Safety & Security, Shaker Verlag, S , [6] Scheible, J., Kreuz, I.: Ein smodell zur automatisierten Ermittlung der Modellqualität bei eingebetteten Systemen, in Proc. of the 8. GI Workshop, Automotive Software Engineering, Leipzig, Germany, [7] Stürmer, I., Stamatov, S., Eisemann, U.: Automated Checking of MISRA TargetLink and AUTOSAR Guidelines, Proc. of SAE World Congress 2009, SAE Doc. # , Detroit (USA), April, [8] V. Basili, G. Caldiera und H.D. Rombach. Encyclopedia of Software Engineering, Wiley & Sons., S , [9] B. W. Boehm, J. R. Brown und M. Lipow, Quantitative evaluation of software quality, In Proceedings of the 2nd International Conference on Software Engineering, IEEE Computer Society Press, pp , [10] C. F. J. Lange und M. R. V. Chaudron. Managing Model Quality in UML-Based Software Development. In Proc. of the 13th IEEE International Workshop on Software Technology and Engineering Practice, pp IEEE Computer Society, 2005.