- Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf -

Version: 1.0

Projektbezeichnung

SPES 2020

Verantwortlich

André Heuer, Bastian Tenbergen (Universtität Duisburg-Essen)

QS-Verantwortlich

Jessica Jung (Fraunhofer IESE)

Erstellt am

10.01.2012

Zuletzt geändert

25.01.2012 15:25 Vertraulich für Partner: ; ; …

Freigabestatus

Projektöffentlich X Bearbeitungszustand

Öffentlich in Bearbeitung vorgelegt

X

fertig gestellt

Weitere Produktinformationen Erzeugung

André Heuer (AH), Bastian Tenbergen (BT)

Mitwirkend

Mark Rzepka (MR), Sebastian Gabrisch (SG), Jessica Jung (JJ)

Änderungsverzeichnis Änderung

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Nr.

Datum

Version

1

10.01.12

0.1

Alle

Initiale Produkterstellung

SG

In Bearbeitung

2

11.01.12

0.2

2, 3

Weitere Ausarbeitung

BT

In Bearbeitung

3

13.01.12

0.3

3.1

Vervollständigung

BT

In Bearbeitung

4

17.01.12

0.4

4

Vervollständigung

AH

In Bearbeitung

5

19.01.12

0.5

3.2

Vervollständigung

BT

In Bearbeitung

6

20.01.12

0.6

7, 2.3.1

Vervollständigung

MR

In Bearbeitung

7

23.01.12

0.6

-

Externes Review

JJ

Vorgelegt

8

23.01.12

0.7

4

Überarbeitung nach Review

AH

In Bearbeitung

9

25.01.12

1.0

Alle

Überarbeitung nach Review

MR/AH/BT

Fertig gestellt

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

Kurzfassung Der Zweck dieses Dokumentes besteht darin, die im Rahmen von ZP-AP2 durchgeführten Evaluierungsaktivitäten darzustellen, zu erläutern und die Ergebnisse auszuwerten. Im Rahmen des Projektes wurden mehrere Evaluierungsaktivitäten durchgeführt. Zum einen wurde der Requirements-Engineering-Ansatz des ZP-AP2 durch Fallstudien evaluiert. Zum anderen wurden Benutzerstudien mit Praktikern aus der Industrie bzw. Software Engineering Studenten durchgeführt, die sowohl die Methodenakzeptanz bzw. Anwendbarkeit evaluieren. Die Evaluierungsaktivitäten haben eine Vielzahl von Verbesserung zur Folge gehabt. So haben die Ausarbeitungen der Fallstudien zu domänenspezifischen Anpassungen des Vorgehensmodells und der Artefakttypen des modellbasierten RE-Ansatzes geführt (siehe Anhang D). Ferner zeigt die Evaluierung zur Methodenakzeptanz ein tendenziell positives Bild. Insbesondere ist hervorzuheben, dass Praktiker den Ansatz als einfach anwendbar empfinden und der Ansicht sind, dass die richtigen notwendigen Artefakte durch den Ansatz zur Verfügung gestellt werden. Hinsichtlich der Hochwertigkeit der Ergebnisse evaluieren die Praktiker den RE-Ansatz ebenfalls positiv: der Ansatz erlaubt die Spezifikation von Artefakten mit hoher Qualität und Genauigkeit. Außerdem sind Praktiker tendenziell bereit, den RequirementsEngineering-Ansatz in ihrer täglichen Arbeit einzusetzen. Insgesamt lassen sich bzgl. der Methodenanwendbarkeit die folgenden Aussagen über den analysierten Ansatz festhalten:  Die Probanden haben das Gefühl, durch die Nutzung des Ansatzes das zu analysierende System besser verstanden zu haben  Die mit Hilfe des Ansatzes erstellte Dokumentation eines Systems ist nachvollziehbar  Durch die Abstraktionsebenen haben die Probanden die Spezifikation beim Review besser verstanden. Durch die Evaluierungen zeigt sich allerdings auch das Potential für weitere Verbesserungsmöglichkeiten. Beispielsweise ist der Ansatz ohne Schulung durch einen Experten nur bedingt von Praktikern einsetzbar. Die Erkenntnisse zur Verbesserung ist Gegenstand zukünftiger Arbeiten. Zudem bedarf es weiteren Beispielen zur Anwendbarkeit des Ansatzes in industrieller Praxis.

Zuletzt geändert: 27.04.2012 10:00

3/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

Inhalt 1

Einordnung und Kurzbeschreibung ..................................................................... 5 1.1 Motivation und Einordnung ............................................................................ 5 1.2 Management Summary ................................................................................. 5 1.3 Überblick ....................................................................................................... 6 2 Überblick über die Evaluierungsaktivitäten in ZP-AP2 ........................................ 7 2.1 Fragebogenstudie zur Erfassung der Methodenakzeptanz ........................... 7 2.2 Benutzerstudie zur Erfassung der Methodenanwendbarkeit ......................... 7 2.3 Weitere Evaluierungsaktivitäten .................................................................... 8 3 Fragebogenstudie zur Erfassung der Methodenakzeptanz ............................... 10 3.1 Planung der Evaluierung ............................................................................. 10 3.2 Ergebnisse der Evaluierung ........................................................................ 13 4 Benutzerstudie zur Erfassung der Methodenanwendbarkeit ............................. 17 4.1 Planung und Durchführung der Evaluierung ................................................ 17 4.2 Ergebnisse der Evaluierung ........................................................................ 20 5 Zusammenfassung ............................................................................................ 24 6 Literaturverzeichnis ........................................................................................... 26 7 Anhang A – Möglichkeiten zur domänenspezifischen Anpassung des REAnsatzes auf Basis der Ergebnisse von Fallbeispiel Flugsteuerungssystem ........... 29 7.1 Fallbeispiel Flugsteuerungssystem und die Herausforderungen der sicherheitskritischen Avionik-Domäne .................................................................. 29 7.2 Erkannte Problembereiche und Verbesserungsvorschläge ......................... 30 8 Anhang B – Fragebogen zur Methodenakzeptanz ............................................ 34 9 Anhang C – Fragebögen zur Methodenanwendbarkeit ..................................... 35 10 Anhang D – Ein Ansatz zur Spezifikation von Echtzeitanforderungen am Beispiel von Szenarien........................................................................................................... 36

Zuletzt geändert: 27.04.2012 10:00

4/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

1 Einordnung und Kurzbeschreibung In diesem Abschnitt wird der Zweck dieses Dokumentes kurz erläutert und in den Projektkontext eingeordnet.

1.1 Motivation und Einordnung Die Aufgabe von ZP-AP2 im Laufe des SPES 2020-Projektes war die Erforschung und Entwicklung eines durchgängigen, modellbasierten Requirements-EngineeringAnsatzes. Dieser Ansatz baut auf Vorarbeiten der Uni Duisburg-Essen (siehe [SPES09a] sowie [Pohl10]) sowie eines systematischen Erhebung des Standes der Praxis (siehe [SPES10a], [SPES10b], [SPES10c], [SPES10d], [SPES10e], sowie [STP10], [STP11b] und STP11a]) auf und führten im Zuge des Projektes zu diversen methodischen Weiterentwicklungen (siehe [SPES11a], [SPES11b], [SPES11c], [SPES11d], [SPES11e]). Zur Sicherstellung der Qualität dieser Weiterentwicklungen wurde ein umfangreiches Evaluierungskonzept entwickelt, das verschiedene Evaluierungsaktivitäten beinhaltet. Diese Evaluierungsaktivitäten wurden teilweise im Rahmen der Arbeiten in ZPAP2 und teilweise im Rahmen von Kooperationsarbeiten mit anderen ZP-APs und AWPs durchgeführt. Die im Rahmen von Kooperationsarbeiten entstandenen Evaluierungen wurden teilweise bereits veröffentlicht (siehe Abschnitt 2.3.1). Der Zweck dieses Dokumentes besteht darin, die im Rahmen von ZP-AP2 durchgeführten Evaluierungsaktivitäten darzustellen, zu erklären und die Ergebnisse zu erläutern.

1.2 Management Summary Der Zweck dieses Dokumentes besteht darin, die im Rahmen von ZP-AP2 durchgeführten Evaluierungsaktivitäten darzustellen, zu erklären und die Ergebnisse zu erläutern. Im Rahmen des Projektes wurden mehrere Evaluierungsaktivitäten durchgeführt. Zum einen wurde der Requirements-Engineering-Ansatz des ZP-AP2 durch Fallstudien evaluiert. Zum anderen wurden Benutzerstudien mit Praktikern aus der Industrie bzw. Software Engineering Studenten durchgeführt, die sowohl die Methodenakzeptanz bzw. Anwendbarkeit evaluieren. Die Evaluierungsaktivitäten haben eine Vielzahl von Verbesserung zur Folge gehabt. So haben die Ausarbeitungen der Fallstudien zu domänenspezifischen Anpassungen des Vorgehensmodells und der Artefakttypen des modellbasierten RE-Ansatzes geführt (siehe Anhang D). Ferner zeigt die Evaluierung zur Methodenakzeptanz ein tendenziell positives Bild. Insbesondere ist hervorzuheben, dass Praktiker den Ansatz als einfach anwendbar empfinden und der Ansicht sind, dass die richtigen notwendigen Artefakte durch den Ansatz zur Verfügung gestellt werden. Hinsichtlich der Hochwertigkeit der Ergebnisse evaluieren die Praktiker den RE-Ansatz ebenfalls positiv: der Ansatz erlaubt die Spezifikation von Artefakten mit hoher Qualität und Genauigkeit. Außerdem sind Praktiker tendenziell bereit, den RequirementsEngineering-Ansatz in ihrer täglichen Arbeit einzusetzen. Insgesamt lassen sich bzgl. der Methodenanwendbarkeit die folgenden Aussagen über den analysierten Ansatz festhalten:  Die Probanden haben das Gefühl, durch die Nutzung des Ansatzes das zu analysierende System besser verstanden zu haben  Die mit Hilfe des Ansatzes erstellte Dokumentation eines Systems ist nachvollziehbar Zuletzt geändert: 27.04.2012 10:00

5/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf 

Durch die Abstraktionsebenen haben die Probanden die Spezifikation beim Review besser verstanden. Durch die Evaluierungen zeigt sich allerdings auch das Potential für weitere Verbesserungsmöglichkeiten. Beispielsweise ist der Ansatz ohne Schulung durch einen Experten nur bedingt von Praktikern einsetzbar. Die Erkenntnisse zur Verbesserung ist Gegenstand zukünftiger Arbeiten. Zudem bedarf es weiteren Beispielen zur Anwendbarkeit des Ansatzes in industrieller Praxis.

1.3 Überblick In Abschnitt 2 wird ein Überblick über die in ZP-AP2 geleisteten Evaluierungsarbeiten gegeben. Abschnitte 3Fehler! Verweisquelle konnte nicht gefunden werden. und 4Fehler! Verweisquelle konnte nicht gefunden werden. stellen die wichtigsten im Rahmen von ZP-AP2 durchgeführten Aktivitäten vor und stellt die Ergebnisse dar. Abschnitt 5 fasst die Ergebnisse zusammen. Weiterführende Materialien können den Anhängen entnommen werden.

Zuletzt geändert: 27.04.2012 10:00

6/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

2 Überblick über die Evaluierungsaktivitäten in ZP-AP2 Im Rahmen der Forschung im ZP-AP2 wurden eine Reihe gezielter Evaluierungen des Requirements-Engineering-Ansatzes und seiner Ergebnisartefakte durchgeführt. Des Weiteren wurden Evaluierungen der Methodik von ZP-AP2 im Rahmen von Kooperationen mit Anwendungsprojekten sowie anderen ZP-APs durchgeführt. In diesem Abschnitt wird ein kurzer Überblick über alle Evaluierungsaktivitäten im ZP-AP2 gegeben und die Ziele jeder Evaluierungsaktivität vorgestellt. Die eingesetzten Methoden sowie die Ergebnisse der in Kooperationen durchgeführter Evaluierungsaktivitäten werden zusammengefasst und es wird auf das Ergebnisdokument der jeweiligen Evaluierungsaktivität verwiesen. Die folgenden Evaluierungsaktivitäten wurden im Rahmen von ZP-AP2 oder in Kooperation mit ZP-AP2 durchgeführt: - Fragebogenstudie zur Erfassung der Methodenakzeptanz - Benutzerstudie zur Erfassung der Methodenanwendbarkeit - Evaluierung anhand von Fallstudien - Anwendungsworkshops mit AWP-EN - Evaluierung der Integrierbarkeit mit AWP-AU-AP3 Die Fragebogenstudie zur Erfassung der Methodenakzeptanz und die Benutzerstudie zur Erfassung der Methodenanwendbarkeit wird in den Abschnitten 2.1 und 2.2 zunächst überblicksartig vorgestellt und dann in den Abschnitten 3 und 4 detailliert erläutert. Die restlichen Evaluierungsaktivitäten werden in Abschnitt 2.3 zusammengefasst, da sie in anderen Dokumenten bereits erläutert werden.

2.1 Fragebogenstudie zur Erfassung der Methodenakzeptanz Ziel dieser Evaluierungsaktivität war es, die Akzeptanz des modellbasierten Requirements-Engineering-Ansatzes in industrieller Praxis zu untersuchen, sowie die Fähigkeit des Ansatzes zu prüfen, industrielle Aufgaben bewältigen zu können. Dazu wurde ein auf dem Technology Acceptance Model (siehe [TAM1], [TAM2], [TAM3]) und Task-Technology Fit Model ([TTF]) basierender Fragebogen erstellt und von Praktikern aus der Industrie, die mit dem RE-Ansatz intensiv vertraut sind, ausgefüllt.

2.2 Benutzerstudie zur Erfassung der Methodenanwendbarkeit Die Anwendbarkeit des Ansatzes wurde in einer longitudinal angelegten Studie mit studentischen Probanden untersucht. Dazu wurde im Rahmen einer Lehrveranstaltung an der Universität Duisburg-Essen ein vereinfachter Ansatz der RE-Methode zur Entwicklung eines Systems genutzt. Die Spezifikation für das zu entwickelnde System wurde durch die Studenten entsprechend dokumentiert. Um die Verständlichkeit des spezifizierten Systems zu prüfen, hat eine andere Studentengruppe die Dokumentation ebenfalls auf Basis der RE-Methodik qualitätsgesichert. Das Ziel der Studie bestand darin zu untersuchen, wie sich die Aufwände für die Spezifikation des Systems und dem Review der Dokumentation über den Evaluationszeitraum hinweg verteilen. Des Weiteren wurde untersucht, ob der Ansatz die Analyse und die Modellierung des Systems erleichtert hat. Ebenso wurde untersucht, ob das Verständnis über und die Implementierung des geplanten Systems erleichtert wurde.

Zuletzt geändert: 27.04.2012 10:00

7/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

2.3 Weitere Evaluierungsaktivitäten Im Folgenden werden weitere Evaluierungsaktivitäten aufgeführt, die in Kooperationen zwischen ZP-AP2 und anderen ZP-APs und AWPs durchgeführt und bereits veröffentlicht wurden.

2.3.1 Evaluierung anhand von Fallbeispielen Die Evaluierungsaktivität anhand der Fallbeispiele hatte das Ziel, die Anwendbarkeit und die Industrietauglichkeit der Lösungskonzepte des Requirements-EngineeringAnsatzes zu evaluieren. In insgesamt fünf Fallbeispielen (siehe Tabelle 2-1) wurden vereinfachte Systeme anhand des Requirements-Engineering-Ansatzes von ZP-AP2 entwickelt und die Ausgabeartefakte durch Experten der Industriepartner begutachtet. Die Expertenmeinungen und Gutachten wurden im Rahmen von verschiedenen Workshops zu konkreten Verbesserungen für den Requirements-Engineering-Ansatz weiterentwickelt. Beispielsweise wurden spezielle Anpassungen des Ansatzes vorgenommen, um Echtzeiteigenschaften in Anforderungsmodellen zu berücksichtigen (siehe Anhang D). Des Weiteren wurde für jedes AWP Anpassungsmöglichkeiten und Ansätze zum domänenspezifischen Tailoring (siehe [SPES11a] und Anhang A) entwickelt. Eine Besonderheit stellt das Fallbeispiel „Motorsteuerung“ dar. Dieses wurde nach Absprache der Projektpartner durch ein weniger umfangreiches Fallbeispiel „Luftsystem“ ersetz, um konkretere Fragestellungen zu untersuchen. In Tabelle 2-1 ist eine Zusammenfassung aller Fallbeispiele durch Evaluierungsaktivitäten des Requirements-Engineering-Ansatzes mit ZP-AP2, deren Zugehörigkeit zu einem Anwendungsgebiet und das jeweils relevante SPES-Dokument gegeben. Fallbeispielname

Kurzbeschreibung

AWP

Ergebnis (-dokument)

ZylinderkopfFertigungsanlage

Entwicklung einer Fertigungsan- Automati[SPES11f] lage zur Produktion von Zylin- sierung derköpfen unter besonderer Berücksichtigung von Echtzeitaspekten sowie funktionaler, logischer und technischer Architektur. Motorsteuerung Entwicklung einer Motorsteue- Automotive [SiPo10], [SPES12d] rung für KFZ zur Regelung von Zündung, Einspritzung und Luftmasse. Luftsystem Entwicklung eines Steuergeräts Automotive [SPES12d] zur Regelung der Luftmasse innerhalb einer Motorsteuerung Klimaanlage Entwicklung eines Klimakontroll- Avionik [SPES12e] systems für die Fluggastkabine eines Passagierflugzeugs zur Regelung von Kabinendruck, Frischluftzufuhr und Innentemperatur. Flugsteuerungssystem Entwicklung eines Flugsteue- Avionik [SPES12b], [SPES12c], rungssystems zur Kontrolle der Anhang A Flughöhe eines Flugzeugs, inkl. der sicherheitskritischen Anforderungen und damit verbundenen Redundanzmaßnahmen. Tabelle 2-1 Zusammenfassung der Fallbeispiele mit Beteiligung von ZP-AP2

Zuletzt geändert: 27.04.2012 10:00

8/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

2.3.2 Anwendungsworkshops mit AWP-EN Im Anwendungsprojekt Energie wurde in drei aufeinander aufbauenden Workshops mit insgesamt ca. 30 Domänenexperten durchgeführt, in denen der RE-Ansatz angewandt wurde. Das Ziel der Evaluierung bestand darin, den Ansatz in Bezug auf die praktische Anwendbarkeit und den Nutzen für Projekte in der Domäne Energie zu prüfen. Zu diesem Zweck wurde ein Evaluierungskonzept entwickelt, welches die Anwendung des Ansatzes im Rahmen energiewirtschaftlicher Projekte untersucht. Zur Messung der Anwendbarkeit und des Nutzens wurde ein dreistufiges Fragebogenkonzept verfolgt, welches jeweils nach dem ersten, zweiten und dritten Workshop den Wissensgewinn mithilfe eine Meinungstests misst. Insgesamt zeigten die Ergebnisse eine positive Bewertung des Ansatzes. Dies blieb auch bei mehrfacher Anwendung des Ansatzes mit unterschiedlichen Teilnehmern konstant. Vor allem die verzahnte Entwicklung von Lösung und Anforderungen sowie die Einbeziehung der Ziel- und Szenarioanalyse überzeugten die Teilnehmer, dass die Methode im Rahmen der Anwendungsdomäne Energie zur Anwendung bei der Entwicklung der in dieser Domäne charakteristischen Systeme geeignet ist (siehe [SPES11g]. Allerdings zeigte sich, dass der Zusammenhang der Konzepte für die Befragten nicht immer direkt zu erkennen war. Probleme wurden vor allem in der Übertragbarkeit der Methodik auf andere Anwendungsfälle gesehen. So waren die Teilnehmer der Meinung, dass für die Anwendung der Methodik ein geschulter Moderator notwendig ist. Aus diesem Grunde erschien es den Befragten auch schwierig, den Ansatz aus deren aktuellem Kenntnisstand heraus Anderen zu vermitteln. Dies könnte jedoch auch in der relativ knappen Dauer für die Vermittlung und Anwendung der RE-Methode liegen, die in den einzelnen Workshops zur Verfügung stand. So entfiel relativ wenig Zeit auf den methodischen Schulungsteil im Verhältnis zum Anwendungsteil des Ansatzes. Eine tiefergehende Betrachtung der Ergebnisse lässt sich [SPES11g] und [SPES11h] entnehmen.

2.3.3 Evaluierung der Integrierbarkeit mit AWP-AU-AP3 Im Rahmen des SPES 2020-Projektes wurden zwei unterschiedliche Ansätze zur Erhebung und Dokumentation von Anforderungen für Eingebettete Systeme entwickelt. Neben dem Ansatz des ZP-AP2 gibt es auch einen Ansatz der Uni Paderborn und Hella, der im Rahmen von AWP-AU-AP3 entwickelt wurde. Der Ansatz aus AWP-AU-AP3 ist in der Lage, unter Verwendung von Satzmustern funktionale Architekturmodelle abzuleiten und zu validieren. Im Rahmen der Erhebung zum Stand der Praxis ([STP11a], [STP11b]) stellte sich heraus, dass die geringe Akzeptanz im industriellen Alltag modellbasierter RE-Ansätze sowie die Probleme, die im industriellen Alltag durch die Verwendung ausschließlich natürlichsprachlicher Anforderungen entstehen, durch eine geeignete Vereinigungen beider Dokumentationsformen in einem gemeinsamen RE-Ansatz überkommen werden können. Zu diesem Zweck wurde angestrebt, die RE-Ansätze des ZP-AP2 und des AWP-AUAP3 auf deren Integrierbarkeit zu überprüfen, sodass eine Methode für den nahtlosen Übergang modellbasierter und natürlichsprachlicher RE-Prozesse zur Verfügung gestellt werden kann. Ergebnis der Prüf- und Integrationsarbeiten ist ein gemeinsamer RE-Ansatz, der durch Satzmuster eingeschränkte, funktionale Anforderungen auf Basis von modellbasierten, lösungsneutralen Anforderungen entwickeln und hierarchische Funktionsmodelle generieren kann [SPES12a].

Zuletzt geändert: 27.04.2012 10:00

9/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

3 Fragebogenstudie zur Erfassung der Methodenakzeptanz In diesem Kapitel wird die Evaluierungsaktivität zur Evaluierung der Methodenakzeptanz des modellbasierten Requirements-Engineering-Ansatzes erläutert. Eine Zusammenfassung ist in Abschnitt 2.1 enthalten.

3.1 Planung der Evaluierung Die Evaluierung wurde als fragebogenbasierte Expertenbefragung durchgeführt. Um einen Fragebogen zu entwerfen, der das in Abschnitt 2.1 dargestellten Ziel der Bewertung der Nutzerakzeptanz und Anwendbarkeit des RE-Ansatzes im industriellen Kontext erreichen kann, wurden Evaluationsartefakte entwickelt, die im Folgenden kurz erläutert werden.

3.1.1 Forschungsfragen und Evaluationsziel Folgende Forschungsfragen lagen der Evaluationsaktivität zu Grunde: Frage 1:

Inwieweit wird der modellbasierte Requirements-Engineering-Ansatz von Praktikern in der Industrie akzeptiert?

Frage 2:

Inwieweit stellt der Ansatz richtige, hochqualitative und nützliche Informationen für die Arbeit der Praktiker in der Industrie bereit?

Frage 3:

Welche Bereitschaft existiert Praktikern in der Industrie, den Ansatz einzusetzen?

Ziel war es nun, die in den Forschungsfragen enthaltenen Inhalte messbar zu machen und ein geeignetes Erhebungsinstrument zu erstellen.

3.1.2 Variablen zur Messung der Forschungsfragen In nächsten Planungsschritt wurde eine strukturierte Literatursuche nach Möglichkeiten zum Messen dieser drei Forschungsfragen durchgeführt. Diese Suche ergab eine Vielzahl von Variablen, die über Items mit einer 7-stufigen Likert-Skalierung in einem Fragebogen messbar gemacht wurden. Variablen zu Forschungsfrage 1 Die Literatursuche ergab, dass es die Faktoren „Perceived Usefulness“ (deutsch: Wahrgenommene Nützlichkeit) sowie „Perceived Ease of Use“ (deutsch: Wahrgenommene Einfachheit der Nutzung) zur Messung von Akzeptanz einer Technologie durch Praktiker (siehe Frage 1, Abschnitt 3.1.1) einen hohen Stellenwert haben (vgl. [TAM1]). Der Faktor „Perceived Usefulness“ beschreibt den Grad, zu dem eine Person glaubt, dass das Verwenden einer Technologie seine Arbeitsleistung verbessert [TAM1]. Der Faktor „Perceived Ease of Use“ beschreibt den Grad, zu dem eine Person glaubt, dass die Verwendung einer Technologie frei von Aufwand ist [TAM1]. Beide Faktoren beschreiben die Einfachheit der Verwendung einer Technologie. Die Einfachheit der Verwendung ist somit ein Kernaspekt von Nutzerakzeptanz [DBW89], die in einem Akzeptanzmodell, dem Technology Acceptance Model (TAM, siehe [TAM1]), zusammengefasst und durch Verwendung eines Fragebogens gemessen wird. Ein weiterer, im Task-Technology-Fit Model betrachteter Faktor, der die EinZuletzt geändert: 27.04.2012 10:00

10/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf fachheit der Verwendung (als Voraussetzung für Akzeptanz) betrachtet, ist die Menge an formalem Training, welches für die Verwendung einer Technology notwendig ist [TTF]. Dieser Faktor ist Teil des Task-Technology-Fit (TTF) Modells, einem Akzeptanzmodell, welches die Eignung einer Technologie für einen bestimmten Zweck misst. Weitere Faktoren für Methodeneignung und Nutzerakzeptanz sind Lokalisierbarkeit der Artefakte, Zugreifbarkeit der Artefakte, Flexibilität der Repräsentation sowie Verständlichkeit der Präsentation aufgeführt [TTF]. Diese Faktoren zielen speziell auf die „Daten“ einer Technologie, bzw. im Falle des Requirements-EngineeringAnsatzes, auf die Artefakte ab und messen den Grad, wie einfach es ist, die Artefakte des Ansatzes im Vorgehensmodell zu finden, auf die darin enthaltenen Informationen zuzugreifen, deren Repräsentation anzupassen bzw. zu verstehen. Variablen zu Forschungsfrage 2 Weitere Variablen, die die Artefakte des RE-Ansatzes bewerten, befassen sich mit der Richtigkeit, Qualität, und dem Nutzen der darin enthaltenen Informationen (siehe Frage 2, Abschnitt 3.1.1) und stellen eine Erweiterung des ursprünglichen Technology Acceptance Model dar [TAM2]. Zu diesen Variablen gehört „Output Quality“, welche den Grad misst, zu dem eine Person glaubt, dass eine Technologie Artefakte in hoher Qualität produziert und somit seine Aufgabe gut verrichtet [TAM2]. Ferner gehört zu diesen Variablen „Result Demonstrability“, welche den Grad misst, zu dem eine Person glaubt, dass eine Technologie, greifbare, erlebbare und kommunizierbare Ausgaben liefert (siehe [MoBe91], [TAM2]). Das Task Technology Fit Model beinhaltet ebenfalls eine Reihe von Variablen zur Messung der Informationsqualität des RE-Ansatzes: „Right Data“, „Right Level of Detail“ und „Accuracy“. Die Variablen „Right Data“ bzw. „Right Level of Detail“ messen den Grad, zu dem die notwendigen grundlegenden Informationen der Technologie produziert werden [TTF] bzw. ob diese Informationen mit dem richtigen Detailgrad zur Verfügung gestellt werden [TTF]. Zudem misst „Accuracy“, den Grad, zu dem die produzierten Informationen korrekt sind [TTF]. Variablen zu Forschungsfrage 3 Frage 3 in Abschnitt 3.1.1 adressiert die Bereitschaft von Praktikern, den Ansatz für ihre Arbeit im industriellen Alltag einzusetzen. Dazu hat die Literaturrecherche ergeben, dass drei wesentliche Faktoren zu dieser Bereitschaft beitragen. Dies ist zum einen die Menge der Ressourcen, die die Verwendung einer Technologie fördern [VMDD03], zum anderen die Nutzerabsicht, eine Technologie einzusetzen [DBW89] sowie der Grad, zu dem die Verwendung einer Technologie freiwillig ist [MoBe91]. Diese Faktoren werden mit den Variablen „Perception of External Control“, „Behavioral Intention“ sowie „Voluntariness“ gemessen. Die der Literatur entnommenen Variablen und deren Zuordnung zu den Evaluierungsfragen aus Abschnitt 3.1.1 sind in Tabelle 3-1 zusammengefasst.

Zuletzt geändert: 27.04.2012 10:00

11/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf Variable

Abk.

Definition

Quelle

Eval.Frage

Perceived Usefulness

PU

[TAM1]

Frage 1

Perceived Eas of Use

PEOU

[TAM1]

Frage 1

Training

TRAIN

[TTF]

Frage 1

Lokalisierbarkeit

LOC

[TTF]

Frage 1

Zugreifbarkeit

ACC

[TTF]

Frage 1

Flexibilität

FLEX

[TTF]

Frage 1

Präsentation

PRES

[TTF]

Frage 1

Ouput Quality

OUT

[TAM2]

Frage 2

Result Demonstrability

RES

[MoBe91]

Frage 2

The Right Data

DATA

[TTF]

Frage 2

The Right Level of Detail

DET

[TTF]

Frage 2

Accuracy

ACCU

[TTF]

Frage 2

Perception of External Control

PEC

[VMDD03]

Frage 3

Behavioral Intention

BI

[DBW89]

Frage 3

Voluntariness

VOL

Der Grad, zu dem eine Person glaubt, dass das Verwenden einer Technologie die Arbeitsleistung verbessert. Der Grad, zu dem eine Person glaubt, dass die Verwendung einer Technologie frei von Aufwand ist. Die Menge an formalem Training, welches notwendig ist, um die Technologie verwenden zu können. Der Grad, wie einfach es ist, notwendige Artefakte einer Technologie zu finden. Der Grad, wie einfach es ist, auf notwendige Artefakte einer Technologie zuzufreifen. Der Grad, wie einfach es ist, die Repräsentation von Artefakten einer Technologie anzupassen. Der Grad, wie einfach es ist, die Artefakte der Technologie zu verstehen. Der Grad, zu dem eine Person glaubt, dass eine Technologie eine Aufgabe gut verrichtet. Der Grad, zu dem eine Person glaubt, dass eine Technologie greifbare, erlebbare und kommunizierbare Ausgaben liefert. Der Grad, zu dem die notwendigen und grundlegenden Artefakte von einer Technologie produziert werden. Der Grad, zu dem die Artefakte mit dem richtigen Detailgrad produziert werden. Der Grad, zu dem die von der Technologie produzierten Artefakte korrekt sind. Der Grad, zu dem eine Person glaubt, dass betriebliche und technische Ressourcen, die die Verwendung der Technologie unterstützen, verfügbar sind. Das Ausmaß der Absicht einer Person, die Technologie zu verwenden. Der Grad, zu dem die Verwendung der Technologie als freiwillig oder ohne Zwang eingeschätzt wird.

[MoBe91]

Frage 3

Tabelle 3-1

Zusammenfassung Variablen für jede Evaluierungsfrage.

3.1.3 Messinstrument Nachdem die Variablen für jede Evaluationsfrage festgelegt worden sind, wurde ein Fragebogen entwickelt (siehe Anhang B). Zu jeder Variable existieren in der Literatur (vgl. Tabelle 3-1) eine Menge von Fragen/Items, welche die Variable messen. Diese Fragen stellen Aussagen dar, die mit Hilfe einer Skala bewertet werden sollen und zu einem Fragebogen zusammengestellt werden. Dabei wurde darauf geachtet, dass die Definition der Variablen sowie die Fragen, die zu jeder Variable gehören, sinnerhaltend ins Deutsche übersetzt wurden, da die Fragen größtenteils aus englischer Literatur stammen. Um Homogenität im Fragebogen zu gewährleisten [CoSt08], wurde bei der Fragebogenerstellung auf Einheitlichkeit der Antwortskalen geachtet, und alle Skalen auf eine 7-Punkt-Likert-Skala (1: „trifft nie zu“; 2: „fast nie“; 3: „selten“; 4: „teils-teils“; 5: „oft“; 6: „häufig“; 7: „trifft immer zu“) umgestellt. Die verwendeten Variablen sind für die Anwendung auf ein konkretes Produkt, beispielsweise einer Softwarelösung, abgestimmt. Da in diesem Evaluierungsvorhaben eine Vorgehensweise anstelle einer konkreten Technologie Gegenstand der Evaluation war, war es notwendig, die zu den Variablen gehörenden Fragen für die VerZuletzt geändert: 27.04.2012 10:00

12/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf wendung um Evaluationsfragebogen anzupassen. Dabei wurde darauf geachtet, dass jede Frage sinnerhaltend angepasst wurde. Dies konnte im Großteil der Fälle durch einfaches Austauschen der Objektwörter in den Fragen erledigt werden 1.

3.1.4 Durchführung An der Evaluation nahmen Praktiker aus dem AWP-AU teil. Die Praktiker waren bereits durch die Kooperation mit dem ZP-AP2 und der Ausarbeitung der Fallstudien „Motorsteuerung“ und „Luftsystem“ (siehe Abschnitt 2.3.1) mit der Vorgehensweise im Requirements-Engineering-Ansatz des ZP-AP2 vertraut. Das in Abschnitt 3.1.3 beschriebene und in Anhang B gezeigte Messinstrument wurde im November 2011 an die Praktiker per E-Mail verteilt. Die Teilnehmer wurden gebeten, binnen einer Woche den ausgefüllten Fragebogen zurückzusenden. Als Unterstützungsmaterial wurden eine Kurzzusammenfassung der Lösungskonzepte des RE-Ansatzes sowie eine umfangreiche Methodenbeschreibung zusammen mit dem Fragebogen ausgeteilt. Dieses Material stand während der Bearbeitungszeit der Fragebögen uneingeschränkt zur Verfügung. Die Rücklaufquote betrug 100%.

3.2 Ergebnisse der Evaluierung In diesem Abschnitt werden die Ergebnisse der Evaluierung kurz zusammengefasst und mit den Ergebnissen der Studien zum Stand der Praxis im modellbasierten Requirements Engineering (siehe [STP11a] und [STP11b]) relationiert. Eine Liste der in Abbildung 3-1, Abbildung 3-2 und Abbildung 3-3 verwendeten Variablenabkürzungen sowie eine Erläuterung der Variablen kann Tabelle 3-1 entnommen werden. Die hier dargestellten Prozentwerte geben Grad der Erfüllung einer Variable an. Für jede Variable wird eine Menge von Fragen auf einer 7-Punkt-Likert-Skala (siehe Abschnitt 3.1.3) bewertet. Die „Zustimmung“ der Fragen der jeweiligen Variablen werden addiert. Der Maximalwert einer Variable (also die Beantwortung aller Fragen der Variable mit dem Maximalwert „7“) wird mit der Anzahl der Teilnehmer multipliziert und anschließend durch die erreichte Punktzahl aller Teilnehmer der jeweiligen Variable geteilt.

3.2.1 Ergebnisse zu Forschungsfrage 1 In Abbildung 3-1 sind die Zustimmungswerte für die Variablen Perceived Usefulness (PU), Perceived Ease of Use (PEOU), Training (TRAIN), Lokalisierbarkeit (LOC, Zugreifbarkeit (ACC), Flexibilität (FLEX) und Präsentation (PRES) dargestellt. Werte unterhalb 50% stellen eine Ablehnung dar, Werte über 50% sind als Zustimmung zu interpretieren.

1

Das Messinstrument sowie das unübersetzte Original werden von den Autoren auf Anfrage zur Verfügung gestellt. Zuletzt geändert: 27.04.2012 10:00

13/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf 0%

10%

20%

30%

40%

PU

50%

70%

80%

90%

100%

60,714%

PEOU

46,429%

TRAIN

57,143%

LOC

57,143%

ACC

42,857%

FLEX

66,667%

PRES Abbildung 3-1

60%

57,143% Auswertung der Antworten zu den Variablen zu Forschungsfrage 1

Die in Abbildung 3-1 dargestellten Ergebnisse zeigen, dass im Allgemeinen der Ansatz als tendenziell nützlich empfunden wird. Dies zeigt sich dadurch, dass die empfundene Nützlichkeit (PU), sowie Anpassbarkeit als der Repräsentationsform (FLEX) einen Zustimmungsgrad über 60% erhalten. Hinsichtlich der Verwendbarkeit der durch den Ansatz bereitgestellten Daten zeigt sich Potential zur Verbesserung. Sowohl die Variable hinsichtlich der guten bzw. einfachen Präsentation der Artefakte (PRES), sowie die Möglichkeit, notwendige Informationen schnell und einfach zu finden (LOC, ACC) erreichen lediglich einen Zustimmungsgrad von 57% bzw. 43%. Ebenfalls zeigt sich, dass die Verwendbarkeit des Ansatzes ohne Training eingeschränkt sein kann, da die entsprechende Variable lediglich eine Zustimmung von ebenfalls 57% erreicht. Dieses Ergebnis wird durch die Funde in [SPES11g] und [SPES11h] bestätigt: in der Evaluierung im Rahmen von AWP-EN zeigt sich, dass sich eine einführende Schulung durch einen Moderator positiv auf die Anwendbarkeit des Ansatzes auswirkt. Ferner wird dieses durch die empfundene Einfachheit der Nutzung des Ansatzes deutlich: in dieser VariableVariable wurde lediglich ein Zustimmungsgrad von 46% erreicht. Zusammenfassend kann gesagt werden, dass die Akzeptanz des Ansatzes durch Praktiker zwar überdurchschnittlich, jedoch keine herausragende Zustimmung erhält. Gründe hierfür liegen vor allem bei der Verwendbarkeit des Ansatzes. Weitere Evaluierungen [SPES11h] haben gezeigt, dass formales Training die Anwendbarkeit und Akzeptanz erhöhen.

3.2.2 Ergebnisse zu Forschungsfrage 2 In Abbildung 3-2 sind die Zustimmungswerte für die Variablen Output Quality (OUT), Result Demonstrability (RES), The Right Data (DATA), The Right Level of Detail (DET) und Accuracy (ACCU) dargestellt. Werte unterhalb 50% stellen eine Ablehnung dar, Werte über 50% sind als Zustimmung zu interpretieren.

Zuletzt geändert: 27.04.2012 10:00

14/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf 0%

10%

20%

30%

40%

OUT

50%

60%

70%

80%

90%

100%

57,143%

RES

75,00%

DATA

66,667%

DET

42,857%

ACCU

57,143%

Abbildung 3-2

Auswertung der Antworten zu den Variablen zu Forschungsfrage 2

Bezüglich der Qualität der durch den Ansatz bereitgestellten Artefakte zeigt sich ein größtenteils hoher Zustimmungsgrad zu den Fragen der einzelnen Variablen (siehe Abbildung 3-2). Insgesamt werden die Datengenauigkeit (ACCU) sowie die allgemeine Qualität der zur Verfügung gestellten Artefakte (OUT) mit 57% Zustimmungsgrad als hochwertig angesehen. Zudem sind die Teilnehmer tendenziell der Ansicht, dass die durch den Ansatz zur Verfügung gestellten Artefakte die grundlegendsten und notwendigsten Informationen bereitstellen (DATA, 67% Zustimmung). Ein hoher Grad an kommunizierbaren Ergebnissen (RES, 75% Zustimmung) zeigt sich ebenfalls aus den Ergebnissen. Ein tendenziell geringer Zustimmungsgrad (43%) zeigt sich im Hinblick auf den Detailgrad der durch den Ansatz produzierten Artefakte (DET). Dies wurde bereits in vergangenen Studien (vgl. [SiPo10] und [STP11b]) deutlich: aktuelle industrielle Praxis wendet keine klare Vorgehensweise an, um Anforderungen auf unterschiedlichen Abstraktionsebenen zu spezifizieren. Obwohl der RE-Ansatz von ZP-AP2 hier Abhilfe schafft, zeigen die Ergebnisse zu Forschungsfrage 1 (siehe Abschnitt 3.2.1), dass weitere Schulungen zum Umgang mit den Lösungskonzepten des Ansatzes notwendig wären (?). Aus den Daten kann geschlossen werden, dass hochqualitative und nützliche Informationen und die grundlegend richtigen Artefakte für den Benutzer vom Ansatz tendenziell bereitgestellt werden. Verbesserungspotential gibt es aus Sicht der Probanden bzgl. des Detailgrades, auf dem die Artefakte dargestellt werden.

3.2.3 Ergebnisse zu Forschungsfrage 3 In Abbildung 3-3 sind die Zustimmungswerte für die Variablen Perception of External Control (PEC), Behavioral Intention (BI) und Voluntariness (VOL) dargestellt. Werte unterhalb 50% stellen eine Ablehnung dar, Werte über 50% sind als Zustimmung zu interpretieren. 0%

10%

20%

PEC BI

40%

50%

60%

70%

80%

90%

100%

71,429% 23,810%

VOL Abbildung 3-3

30%

76,190% Auswertung der Antworten zu den Variablen zu Forschungsfrage 3

Zuletzt geändert: 27.04.2012 10:00

15/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf Aus den in Abbildung 3-3 dargestellten Daten zeigt sich, dass die Teilnehmer der Ansicht sind, dass sie alle notwendigen Ressourcen haben, den Ansatz problemlos einsetzen zu können (PEC, 71% Zustimmung). Des Weiteren wird die Verwendung des Ansatzes weitestgehend als freiwillig, d.h. ohne Zwang durch Vorgesetzte oder organisatorische Richtlinien durchgeführt, wie der Zustimmungsgrad von 76% zeigt (VOL). Im Widerspruch dazu sind die Ergebnisse bzgl. der Variable „Behavioral Intention“ (BI). Hier zeigt sich nur eine geringe Zustimmung (24%), was bedeutet, dass trotz der tendenziell positiven Evaluierung des Ansatzes (siehe Abschnitte 3.2.1 und 3.2.2) Praktiker in der absehbaren Zukunft den Ansatz nicht anwenden werden. Dies lässt sich dadurch erklären, dass Praktiker die Verwendung einer neuen, bisher nicht in der täglichen Praxis erprobten Methode als risikoreich ansehen [STP11b]. Es wäre daher vorteilhaft, praxisnahe Beispiele ähnlich den Fallbeispielen in Abschnitt 2.3.1 zur Förderung der Methodenakzeptanz auszuarbeiten. Die Ergebnisse zu dieser Evaluationsfrage zeigen, dass Praktiker tendenziell bereit sind, den Requirements-Engineering-Ansatz einzusetzen. Es bedarf allerdings weiteren Beispielen zur Anwendbarkeit des Ansatzes in industrieller Praxis.

Zuletzt geändert: 27.04.2012 10:00

16/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

4 Benutzerstudie zur Erfassung der Methodenanwendbarkeit Im Folgenden wird nun die Evaluation der Anwendbarkeit der RE Methodik beschrieben. Dazu wird zunächst beschrieben, wie die Evaluierung durchgeführt wurde. Darauf aufbauend werden die Ergebnisse der Evaluierung beschrieben und interpretiert.

4.1 Planung und Durchführung der Evaluierung Zur Evaluierung der Anwendbarkeit der Methodik wurde die Veranstaltung Software Entwicklung & Programmierung (SEP)2 an der Universität Duisburg-Essen genutzt. Die Veranstaltung wird in jedem Semester angeboten und hat einen Umfang von sechs ECTS Credit Points. Bei der Veranstaltung handelt es sich um ein Softwarepraktikum, welches im 2.Fachsemester der Bachelor Studiengänge Angewandte Informatik – Systems Engineering, Wirtschaftsinformatik und Lehramt Informatik liegt. Die Studierenden müssen in einer Neigungsgruppe von fünf Studierenden während des Semesters ein Software Projekt durchführen. Während dieses Projekts wird von den Studierenden entweder eine Anwendung, ein Spiel oder ein eingebettetes System mit Lego Mindstorms entwickelt. Begleitend finden zwei Mal pro Woche jeweils zweistündige Präsenzstunden statt, in der sich die Studenten mit dem Betreuer austauschen können, Feedback erhalten und neue Aufgaben bekommen. In der Veranstaltung wird ein auf dem V-Modell basierender Entwicklungsprozess genutzt, der auch eine umfangreiche Requirements Engineering Phase vorsieht (vgl. [LSP07]). Innerhalb dieser Requirements Engineering Phase wurde ein vereinfachter Ansatz der RE-Methode eingesetzt und evaluiert.

4.1.1 Evaluierungsziele Das Ziel dieser Evaluierung ist die Untersuchung der Anwendbarkeit des Ansatzes. Dazu wird die Evaluierung in zwei Teile aufgeteilt. Während das Ziel des ersten Teils ist, den Aufwand zur Anwendung der Methodik zu untersuchen, fokussiert der zweite Teil auf die Anwendbarkeit des Ansatzes hinsichtlich Analyse und Implementierung des Systems. Bei der Nutzung des Ansatzes wird zunächst davon ausgegangen, dass der Aufwand, der in den einzelnen Phasen des Ansatzes benötigt wird, konstant ist. Ist der Aufwand in einem Bereich stark unterschiedlich, könnte daraus geschlossen werden, dass es in dieser Phase möglicherweise Probleme mit dem Ansatz gibt. Daher wird die folgende Hypothese aufgestellt: H10 Die Aufwandsverteilung der Teilnehmer über den gesamten Veranstaltungszeitraum ist nicht konstant. H1 Die Aufwandsverteilung der Teilnehmer über den gesamten Veranstaltungszeitraum ist konstant. Der Ansatz nutzt zur Spezifikation von Software-intensiven eingebetteten Systemen Modelle. Die durch den Ansatz entstandene Spezifikation dient den Entwicklern als Basis zur Implementierung des Systems. Daher muss das Ergebnis der Methoden für die Entwickler verständlich sein. Daher wurde bei der Evaluierung einerseits untersucht, ob der vereinfachte Ansatz die Analyse des Systems erleichtert. Andererseits sollte durch die Evaluierung untersucht werden, ob der Ansatz das Verständnis und die Implementierung des geplanten Systems erleichtert. Dazu wurden folgende Hypothesen aufgestellt: 2

vgl. http://sep.icb.uni-due.de

Zuletzt geändert: 27.04.2012 10:00

17/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf H20 Der Ansatz unterstützt nicht die Analyse und Modellierung des Systems. H2 Der Ansatz unterstützt die Analyse und Modellierung des Systems. H30 Der Ansatz unterstützt nicht das Verständnis und die Implementierung des geplanten Systems. H3 Der Ansatz unterstützt das Verständnis und die Implementierung des geplanten Systems.

4.1.2 Vorgehensweise Die Veranstaltung SEP ist eine Pflichtveranstaltung welche Teil der Curricula der Studiengänge Angewandte Informatik – Systems Engineering, Wirtschaftsinformatik und Lehramt Informatik ist. In allen Studiengängen liegt die Veranstaltung im zweiten Fachsemester. Dementsprechend ist davon auszugehen, dass die teilnehmenden Studenten nur wenig bis keine Erfahrung in der Software Entwicklung haben. Daher wurden für die Evaluierung vereinfachende Annahmen getroffen. Der Ansatz wurde für die Teilnehmer der Veranstaltung in folgenden Punkten vereinfacht:  es wurden drei rigide Abstraktionsebenen zur Spezifikation genutzt, um den Studenten die Abstraktion zu erleichtern,  und es wurde eine grobe Reihenfolge zur Bearbeitung der Artefakte vorgegeben, um den Studierenden ein strukturiertes Vorgehen zu ermöglichen. Einen Überblick über die genutzten Artefakte findet sich Abbildung 4-1. Lösu n gsn e u t r a le Anfo r de r unge n

Lösungsbe z oge ne Anfor de r unge n

Lösungsk o nz e pt

Ge sa m t syst e m

• Prosaziele, die das System erfüllen soll

• Textuelle Szenarien, die die Erfüllung der Prosaziel beschreiben • Textuelle Anforderungen

• Kontextmodell

Logische s Sy st e m

• Zielbaum, enthält Prosaziele, definiert Ziele, die durch logische Komponenten erfüllt werden müssen • Verfeinert ggf. Prosaziele in Hard- und Softgoals

• Message Sequence Charts in Bezug auf das DFD und den Szenarien

• Funktionsmodell (DFD)

Te ch n isch e s Sy st e m

• Zielbaum, ergänzt um technische Ziele • Ggf. Verfeinerung logischer Ziele und Hard-/Softgoals

• Datenmodell der gespeicherten Daten • Zuordnung der Umsetzung der Funktionen auf technische Komponenten

• Technisches Konzept

Abbildung 4-1

Überblick über den vereinfachten Ansatz

3

8

© paluno

Übe r blick

Um den Studenten ein strukturiertes Vorgehen zu ermöglichen, wurde ein grober Prozess vorgegeben. Die Vorgabe der Reihenfolge beschränkte sich hierbei auf die Abstraktionsebenen. Diese wurden im top-down Verfahren bearbeitet. Dabei was es den Studierenden jedoch ausdrücklich möglich Artefakte in den anderen Ebenen zu ergänzen. 3

Hierbei handelt es sich um eine in der Veranstaltung genutzte Folie, die auch den Studenten zur Verfügung gestellt wurde. Zuletzt geändert: 27.04.2012 10:00

18/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf Auf Basis dieses vereinfachten Ansatzes wurde innerhalb der Veranstaltung SEP Methodenanwendbarkeit untersucht. Dazu ist im Folgenden das Evaluierungsvorgehen definiert. Zur Evaluation von H1 wurden Fragebögen und Protokolle genutzt, die im folgenden Abschnitt detailliert beschrieben werden. Zur Evaluierung von H2 und H3 wurden die Aufgaben jeder Gruppe zweigeteilt: Zunächst musste jede Gruppe ein System mit Hilfe des Ansatzes spezifizieren, womit H2 untersucht wird. Zur Untersuchung von H3 war es zudem die Aufgabe jeder Gruppe, die Spezifikation einer anderen Gruppe kontinuierlich zu prüfen, also ein Review vorzunehmen. Um eine gewissenhafte Prüfung der Spezifikation durch die Probanden zu gewährleisten, wurde zu Beginn des Praktikums kommuniziert, dass die prüfende Gruppe die geprüfte Spezifikation implementieren musste und die Spezifikation während der Implementierung nicht mehr geändert werden durfte. Bei der Vergabe der Programmieraufgaben wurde dementsprechend eine Überschneidung der gleichen Programmieraufgabe verhindert, so dass jeweils unterschiedliche Aufgaben spezifiziert und überprüft wurden.

4.1.3 Messinstrument Als Messinstrumente wurden zur Messung von H1 wöchentliche Fragebögen und Protokolle genutzt. In einem wöchentlichen Fragebogen sollten die Probanden ihre subjektive Arbeitsbelastung hinsichtlich der Entwicklung eines Systems und dem Review einer Dokumentation angeben. Dazu wurde den Probanden eine Vorlage (siehe Abbildung 4-2) zur Verfügung gestellt, in der sie ihren aktuellen Aufwand in Minuten der Woche eintragen konnten.

Abbildung 4-2

Vorlage für Protokoll zur Messung des Aufwands

Zusätzlich zur quantitativen Messung des Aufwands wurde mit Hilfe des Fragebogens (siehe Anhang C) auch die subjektive Belastung der Probanden abgefragt. Zur Messung von H2 und H3 wurde auf demselben wöchentlichen Fragebogen, der auch nach dem Aufwand zur Hypothese H1 genutzt wird, der subjektive Nutzen der jeweiligen Artefakte und Konzepte hinsichtlich der Aufgabe der Entwicklung und Prüfung der Spezifikation abgefragt. Die jeweiligen Fragebögen wurden wöchentlich um die neu vorgestellten Artefakte erweitert, wodurch nach drei Wochen der Fragebogen vollständig aufgebaut war. Um das Protokoll den jeweiligen Fragebögen der Probanden zuordnen zu können, sollten die Probanden einen Code definieren, mit der die Fragebögen und das Protokoll einander zugeordnet werden konnten. Die Fragen auf den Fragebögen wurden nach einer 5-stufigen Likert Skala abgefragt: - Sehr zutreffend  1 - Zutreffend  2 - Mittel  3 Zuletzt geändert: 27.04.2012 10:00

19/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf -

Unzutreffend  4 Sehr unzutreffend  5

Im Rahmen der Aufwandsbefragung wurden die Skala entsprechend angepasst von „sehr viel beschäftigt“ (1) bis „sehr wenig beschäftigt“ (5). Wobei noch die zusätzliche Antwortmöglichkeit „gar nicht beschäftigt“ hinzugefügt wurde.

4.1.4 Durchführung Die Evaluierung wurde im Sommersemester 2011 in einem Zeitraum über sieben Wochen durchgeführt. An der Evaluierung nahmen 57 Studierende teil, von denen sich ca. 52% Studierende (30) im zweiten Fachsemester befanden. Weitere 19% (11) befanden sich im vierten Fachsemester und 21% (12) im sechsten Fachsemester. Die verbleibenden Probanden befanden sich gleichverteilt im ersten, fünften, achten, zehnten oder zwölften Fachsemester. Von den Probanden studierten ca. 54% (31) den Studiengang Angewandte Informatik – Systems Engineering, ca. 28% (16) Wirtschaftsinformatik und ca. 16% (10) Lehramt Informatik. Im Rahmen der Veranstaltung fanden zwei Präsenztermine pro Woche statt. Der erste Termin fand an einem Montag oder Dienstag und der zweite Termin an einem Donnerstag oder Freitag statt, wobei der Fragebogen immer am Donnerstag oder Freitag bearbeitet wurde. Während die Probanden zu Beginn des Semesters Interesse an der Evaluierung und der dahinterstehenden Forschungsfrage zeigten, ist die Motivation im weiteren Verlauf der Befragung stark gesunken. Dies wurde z.B. durch Fragen der Probanden nach dem Sinn des Ausfüllens des immer gleichen Fragebogens deutlich. Trotzdem blieb die Teilnehmerzahl konstant.

4.2 Ergebnisse der Evaluierung In diesem Abschnitt werden die Ergebnisse der Evaluierung zusammenfassend dargestellt, beschrieben und interpretiert4. Zunächst werden dazu zu den in Abschnitt 4.1.1 beschriebenen Hypothesen die entsprechenden Fragen in den Fragebögen präsentiert.

4.2.1 Ergebnis und Interpretation zur Hypothese H1 Zur Messung der Hypothese H1 wurde in den wöchentlichen Fragebögen die Arbeitsbelastung der Probanden abgefragt. Tabelle 4-1 zeigt eine Übersicht über die Fragen und gibt die Anzahl der gültigen Messwerte über die gesamte Evaluationsdauer an. Der Median liegt bei beiden Fragen bei 3. Fragestellung

Die Arbeitsbelastung für die Entwicklung in dieser Woche empfand ich als... Die Arbeitsbelastung für das Review in dieser Woche empfand ich als... Tabelle 4-1

4

# Messwerte 332 316

Median 3

σ 3,64

3

2,91

Fragen bezogen auf Hypothese H1

Die Rohdaten werden von den Autoren auf Anfrage zur Verfügung gestellt.

Zuletzt geändert: 27.04.2012 10:00

20/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf Abbildung 4-3 zeigt den Mittelwert der Arbeitsbelastung der Probanden durch die Entwicklung (rote Kurve) und durch das Review (grüne Kurve) pro Woche. Die schwarzen Linien stellen lineare Trendlinien dar. 5

4

3

2

1 Woche 1

Abbildung 4-3

Woche 2

Woche 3

Woche 4

Woche 5

Woche 6

Arbeitsbelastung Entwicklung

Arbeitsbelastung Review

Linear (Arbeitsbelastung Entwicklung)

Linear (Arbeitsbelastung Review)

Woche 7

Diagramm über die Arbeitsbelastung pro Woche

Anhand der Trendlinie ist zu erkennen, dass sich die subjektive Arbeitsbelastung der Probanden für die Entwicklung und das Review über die Zeit hinweg unterschiedlich entwickeln. Bei der Interpretation des Diagramms in Abbildung 4-3 ist dabei zu berücksichtigen, dass eine sinkende Kurve eine Steigerung der Arbeitsbelastung darstellt, da eine 1 („sehr hoch“) eine Zustimmung zur Aussage darstellt. Dies bedeutet, dass die Arbeitsbelastung bei der Entwicklung über die sieben Wochen hinweg ansteigt, während die Arbeitsbelastung beim Review abnimmt. Die Steigerung der Arbeitsbelastung bei der Entwicklung hängt damit zusammen, dass die Probanden zusätzlich zur Spezifikation im Verlauf der Evaluationsphase auch mit der Implementierung begonnen haben. Somit spiegelt diese Kurve die kumulierte Arbeitsbelastung der Probanden durch die Spezifikation und der Implementierung dar. Dahingegen sinkt die Arbeitsbelastung durch das Review im Verlauf der Evaluierung. Dies ist als positiv zu bewerten. Eine Erklärungsmöglichkeit kann darin liegen, dass die Probanden sich möglicherweise an die Anwendung des Ansatzes gewöhnt haben und dadurch ein besseres Verständnis für den Ansatz und somit auch für das Review bekommen haben. Zur Validierung der Hypothese H1 wäre es wünschenswert, einen Signifkanztest, z.B. durch einen T-Test, durchzuführen. Die vorliegenden Daten sind jedoch nicht normalverteilt, was durch einen Kolmogorov-Smirnov- und Shapiro-Wilk-Test festgestellt wurde. Daher lassen sich die Daten nur qualitativ interpretieren. Die lineare Trendlinie der Arbeitsbelastung durch das Review weist nur eine minimale Steigung auf. Daher kann hier davon ausgegangen werden, dass die Arbeitsbelastung über die Zeit hinweg relativ konstant blieb. Wie schon oben beschrieben, steigt die Arbeitsbelastung aus o.g. Gründen jedoch bei der Entwicklung. Aufgrund der vorliegenden Daten ist jedoch keine Bereinigung dieses Einflusses an dieser Stelle möglich. Es wäre jedoch möglich, dass nach einer Bereinigung der Daten, eine ebenfalls nahezu konstante Arbeitsbelastung bei der Entwicklung entstehen würde. Insgesamt lässt sich somit sagen, dass die Hypothese H1 im Hinblick auf die Arbeitsbelastung beim Review gehalten werden kann. Zu der Arbeitsbelastung hinsichtZuletzt geändert: 27.04.2012 10:00

21/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf lich der Entwicklungsaktivitäten, ohne Berücksichtigung der Implementierung, kann keine definitive Aussage getroffen werden.

4.2.2 Ergebnis und Interpretation zur Hypothese H2 Zur Überprüfung der Hypothese H2 wurden die in Tabelle 4-2 gelisteten Fragen ebenfalls wöchentlich abgefragt. Für jedes Item sind die Anzahl der gültigen Messwerte, die Mittelwerte sowie die relative Zustimmung der Probanden zu der Frage angegeben. Als Zustimmung wird dabei ein Wert kleiner oder gleich 2 gewertet. Die Fragen adressieren die Diskussion und Kommunikation der Probanden untereinander. Eine Diskussion in der Gruppe deutet darauf hin, dass der Ansatz den Probanden hilft und unterstützt, das System zu analysieren und zu modellieren. Da die Stichproben nicht normalverteilt sind, ist eine Signifikanzanalyse auf den Ergebnissen nicht möglich. Alle Fragen aus Tabelle 4-2 erhalten etwa 50% Zustimmung, wobei der Median (bis auf Frage 4) bei 3 liegt. Das bedeutet, dass ca. die Hälfte der Probanden empfunden hat, dass sie durch den Ansatz überdurchschnittlich unterstützt wurden. Der Median bei den Fragen 1 bis 3 und 5 liegt bei 3. Dies bedeutet, dass die Probanden der Aussage weder zustimmen, noch die Aussage ablehnen. Lediglich Frage 4 hat einen Median 2. Auch hat diese Frage eine höhere Zustimmung. Dies deutet darauf hin, dass die Probanden das subjektive Gefühl haben, dass sie durch die Anwendung des Ansatzes das System besser verstanden haben. Zusammenfassend lässt sich aufgrund der vorliegenden Daten die Hypothese H2 weder annehmen noch verwerfen. Aufgrund der hohen Zustimmungswerte lässt sich jedoch eine Tendenz zur Zustimmung der Hypothese feststellen. Nr 1

Fragestellung # Messwerte Die Methodik hat eine zielgerichtete Diskussion 321 unterstützt. 2 Die Methodik hat mir geholfen meine Gedanken 319 über die Aufgabe zu kommunizieren. 3 Die Methodik hat mir geholfen, zielgerichtete 328 Fragen zu stellen. 4 Durch die Anwendung der Methodik habe ich 307 das Gefühl, das System besser verstanden zu haben. 5 Ich habe das Gefühl, dass ich mit der Methodik 302 Sicherheit im Umgang mit der Aufgabenstellung bekommen habe. Tabelle 4-2 Fragen zur Evaluierung von Hypothese H2

Median 3

σ 0,874

Zs 49,5%

3

0,873

48,6%

3

0,89

44,8%

2

0,933

54,1%

3

0,947

47,4%

4.2.3 Ergebnis und Interpretation zur Hypothese H3 Die Hypothese H3 untersucht, ähnlich wie die Hypothese H2, inwiefern der untersuchte Ansatz das Verständnis und die Implementierung des Systems unterstützt. Dazu wurden zum einen Fragen hinsichtlich der Diskussion innerhalb der Gruppe gestellt (Fragen 6-8). Zusätzlich wurde nach der Verständlichkeit der geprüften Spezifikation gefragt. Zunächst ist hier die geringere Anzahl an Messpunkten auffällig. Dies lässt sich jedoch damit erklären, dass ein Review der Spezifikation z.B. in der ersten Woche nicht möglich und nötig war, wodurch die entsprechenden Fragen nicht beantwortet werden konnten. Für die Fragen 6 bis 8 sowie 11 bis 14 haben die Probanden weder der Aussage zugestimmt, noch diese abgelehnt. Daher ist davon auszugehen, dass zwar der Ansatz das Verständnis und die Implementierung des Systems nicht zwangsläufig unterZuletzt geändert: 27.04.2012 10:00

22/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf stützt, aber das Verständnis als auch Implementierung nicht explizit negativ beeinflusst. Bezüglich der Hypothese 3 zeigt sich keine eindeutige Tendenz, sie kann nicht beibehalten aber auch nicht eindeutig abgelehnt werden. Im Unterschied dazu wird den Fragen 9 und 10 hingegen zugestimmt (63,8% bzw. 55,9%). Somit kann H3 beibehalten werden: die Spezifikation ist für Probanden nachvollziehbar. Die Spezifikation besteht aus den Modellen, die durch die Anwendung des Ansatzes entstanden sind. Daher ist davon auszugehen, dass durch die in der Spezifikation genutzten Modelle, das Verständnis der Spezifikation erhöht wurde. Daher hat die Nutzung des Ansatzes das Verständnis des Systems bzw. der Spezifikation erhöht. Frage 10 fokussiert auf die Nutzung der Abstraktionsebenen durch den Ansatz. Mit einer Zustimmung zu dieser Aussage bestätigten die Probanden, dass ihnen die Abstraktionsebenen aus der Sicht der Reviewer geholfen haben, das zu spezifizierte System zu verstehen. Dieser Aussage stimmen 63,8% der Probanden zu. Daher ist davon auszugehen, dass insbesondere die Nutzung von Abstraktionsebenen durch den Ansatz die Verständlichkeit hinsichtlich der Spezifikation erhöht. Dies wird auch durch Frage 14 gestützt, da nur wenige Probanden Rückfragen bzgl. der Spezifikation hatten. Zusammenfassend lässt sich allerdings nicht sagen, ob die Hypothese H3 bestätigt oder verworfen werden muss. Aufgrund der nicht vorliegenden Normalverteilung der Stichproben lässt sich kein aussagekräftiger Hypothesentest durchführen. Es lässt sich jedoch ein positiver Trend feststellen, der zu einer Bestätigung der Hypothese führen könnte. Nr 6

Fragestellung # Messwerte Die Methodik hat eine zielgerichtete Diskussion 286 unterstützt. 7 Die Methodik hat mir geholfen meine Gedanken 283 über die Aufgabe zu kommunizieren. 8 Die Methodik hat mir geholfen, zielgerichtete 276 Fragen zu stellen. 9 Die Spezifikation ist für mich als Reviewer nach278 vollziehbar. 10 Die Abstraktionsebenen haben mir als Reviewer 235 geholfen das zu entwickelnde System zu verstehen. 11 Die Einteilung in lösungsneutrale Anforderun276 gen, lösungsbezogene Anforderungen und Lösungskonzept haben für mich als Reviewer das Verständnis der Spezifikation erhöht. 12 Durch die Methodik war es mir möglich, ein 278 strukturiertes Review durchzuführen. 13 Durch die Methodik war es mir als Reviewer 273 möglich, ein strukturiertes Feedback an die andere Gruppe zu geben. 14 Ich hatte viele Rückfragen an die andere Gruppe 272 bezüglich ihrer Spezifikation. Tabelle 4-3 Fragen zur Evaluierung der Hypothese H3

Zuletzt geändert: 27.04.2012 10:00

Median 3

σ 0,866

Zs 45,4%

3

0,894

41,9%

3

0,895

39,2%

2

0,845

63,8%

2

0,894

55,9%

3

0,904

41,6%

3

0,866

43,1%

3

0,903

47,8%

3

1,008

27,5%

23/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

5 Zusammenfassung Im Rahmen von ZP-AP2 wurden mehere Evaluationsaktivitäten zur Prüfung der Akzeptanz und Anwendbarkeit des modellbasierten Requirements-Ansatzes durchgeführt. Diese Evaluationen entstanden durch Kooperationen mit Anwendungsprojekten, anhand von Fallstudien sowie durch eine Fragebogenstudie und eine Benutzerstudie. : In einer Fragebogenstudie zur Methodenakteptanz wurden Praktiker des AWP-AU befragt, inwiefern  der modellbasierte Requirements-Engineering-Ansatz von Praktikern in der Industrie akzeptiert wird;  der Ansatz richtige, hochqualitative und nützliche Informationen für die Arbeit der Praktiker in der Industrie bereitstellt; und  Welche Bereitschaft bei Praktikern in der Industrie existiert, den Ansatz einzusetzen. Die Ergebnisse der Fragebogenstudie zur Methodenakzeptanz hat ergeben, dass Praktiker den Ansatz tendenziell als positiv empfinden. Insbesondere ist hervorzuheben, dass Praktiker den Ansatz als einfach anwendbar empfinden und der Ansicht sind, dass die richtigen notwendigen Artefakte durch den Ansatz zur Verfügung gestellt werden. Allerdings zeigt die Evaluierung, dass zur Anwendung in der Praxis formales Training notwendig ist. Hinsichtlich der Qualität der Ergebnisse evaluieren die Teilnehmer den RE-Ansatz ebenfalls positiv: der Ansatz erlaubt die Spezifikation von Artefakten mit hoher Qualität und Genauigkeit. Allerdings gibt es Verbesserungspotential bei der Verwendung unterschiedlicher Abstraktionsstufen (vgl. [STP11b]). Ferner zeigt sich, dass Praktiker tendenziell bereit sind, den Requirements-Engineering-Ansatz einzusetzen. Es bedarf allerdings weiteren Beispielen zur Anwendbarkeit des Ansatzes in industrieller Praxis. Die Evaluation der Methodenanwendbarkeit erfolgte durch eine wöchentliche Befragung in einem Softwarepraktika an der Universität Duisburg-Essen, welches von Studierenden im zweiten Fachsemester besucht wurde. Innerhalb dieser Befragung wurden die Probanden regelmäßig nach ihrer aktuellen Arbeitsbelastung und der Verständlichkeit der Spezifikationen, die mit Hilfe des RE-Ansatzes erstellt worden sind, befragt. Aufgrund der vorliegenden Daten und den durchgeführten Analysen bei der Evaluierung zur Methodenanwendbarkeit lassen sich keine definitiven Aussagen über die Hypothesen treffen. Hypothese H1 kann hinsichtlich der Review Aktivitäten beibehalten werden. Das bedeutet, dass die Arbeitsbelastung der Probanden durch die Anwendung der Methode über den Entwicklungszeitraum konstant geblieben ist. Eine Aussage hinsichtlich der Arbeitsbelastung bei der Entwicklung kann jedoch gemacht werden, wobei es hier eine positive Tendenz hin zur konstanten Arbeitsbelastung gibt, womit die Hypothese H1 bestätigt werden würde. Die Hypothesen H2 und H3 konnten weder verworfen noch angenommen werden. Bei beiden Hypothesen konnte jedoch eine positive Tendenz festgestellt werden. Insgesamt lassen sich die folgenden Aussagen über den analysierten Ansatz festhalten:  Die Probanden haben das Gefühl, durch die Nutzung des Ansatzes das zu analysierende System besser verstanden zu haben.  Die mit Hilfe des Ansatzes erstellte Dokumentation eines Systems ist nachvollziehbar.  Durch die Abstraktionsebenen haben die Probanden die Spezifikation beim Review besser verstanden. Zuletzt geändert: 27.04.2012 10:00

24/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf Andere Aussagen können weder bestätigt noch wiederlegt werden. Aufgrund einer nicht vorliegenden Normalverteilung der Stichproben (festgestellt durch den Kolmogorov-Smirnov- und Shapiro-Wilk-Test), konnten die vorliegenden Daten nicht auf ihre Signifikanz getestet werden. Dies könnte daran liegen, dass die Fragebögen von den Probanden nicht gewissenhaft ausgefüllt worden sind. Dies wird auch von einigen Aussagen der Probanden unterstützt, die die Probanden in einem Freitextfeld auf den Fragebögen abgeben konnten. Die in diesem Dokument vorgestellten Evaluierungsarbeiten des RequirementsEngineering-Ansatzes des ZP-AP2 haben eine Vielzahl von Ergebnissen hervorgebracht, die zur Verbesserung des Ansatzes beigetragen haben bzw. in Zukunft zur Verbesserung beitragen werden. So haben die Ausarbeitungen der Fallstudien zu domänenspezifischen Anpassungen des Vorgehensmodells und der Artefakttypen des modellbasierten RE-Ansatzes geführt. Ein Beispiel für eine solche Anpassung ist in Anhang D gegeben. Ferner zeigen die Evaluierungen zur Methodenakzeptanz und Methodenanwendbarkeit ein tendenziell positives Bild. Allerdings bleiben weitere Verbesserungsmöglichkeiten bestehen. Um diese genauer zu untersuchen sind weitere, detailliertere Studien notwendig.

Zuletzt geändert: 27.04.2012 10:00

25/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

6 Literaturverzeichnis [CoSt08]

Corbin J, Strauss A (2008) Qualitative Research, 3rd Ed. Sage Publications, California, USA.

[DBW89]

Davis, F. D.; Bagozzi, R. P.; Warshaw, P. R. (1989). User acceptance of computer technology: A comparison of two theoretical models. Management Science 35:982-1002.

[LSP07]

Lauenroth, Kim; Sikora, Ernst; Pohl, Klaus. Positive Effekte von Szenarien und Features in einem Softwarepraktikum. In: Andreas Zeller, Marcus Deininger (Eds.): Software Engineering im Unterricht der Hochschulen, SEUH 10, Stuttgart, Germany, 22. und 23. Februar 2007. dpunkt 2007, ISBN 3-89864-458-8.

[MoBe91]

Moore, G. C.; Benbasat, I. (1991). Development of an instrument to measure the perceptions of adopting an information technology innovation. Information Systems Research 2:192-222.

[Moody2009]

Moody, Daniel. The “Physics” of Notations: Toward a Scientific Basic for Constructing Visual Notations in Software Engineering. In: IEEE Transactions on Software Engineering 35 (6). 2009.

[Pohl10]

Pohl, Klaus (2010). Requirements Engineering – Foundations, Principles, Techniques. Springer, Germany/USA.

[SiPo10]

Sikora, Ernst; Pohl, Klaus. Evaluation eines modellbasierten Requirements-Engineering-Ansatzes für den Einsatz in der Motorsteuerungs-Domäne. Proceedings of ENVISION2020 2010.

[SPES09a]

Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. Initialer modellbasierter Requirements Engineering Ansatz für Embedded Systems. SPES 2020 Teilergebnis, Version 0.92 vom 13.11.2009.

[SPES10a]

Lauenroth, Kim; Gabrisch, Sebastian; Sikora, Ernst; Tenbergen, Bastian. Beschreibung der Durchführung der Studie zum Stand der Praxis im Requirements Engineering für Embedded Systems. SPES 2020 Teilergebnis, Version 1.0 vom 16.07.2010.

[SPES10b]

Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im modellbasierten Requirements Engineering. SPES 2020 Deliverable D2.1.A, 2010.

[SPES10c]

Stallbaum, Heiko Sikora, Ernst; Lauenroth, Kim; Tenbergen, Bastian. Stand der Praxis zur Prüfungs von Anforderungen. SPES 2020 Deliverable D2.2.A, 2010.

[SPES10d]

Tenbergen, Bastian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis zur Spezifikation von Echtzeitanforderungen. SPES 2020 Deliverable D2.3.A, 2010.

[SPES10e]

Sikora, Ernst; Gabrisch, Sebastian: Stand der Praxis – Verzahnung von Requirements Engineering und Architekturentwurf von Embedded Systemen. SPES Deliverable D2.4.A, 2010.

Zuletzt geändert: 27.04.2012 10:00

26/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf [SPES11a]

Avramova, Nadezhda; Tenbergen, Bastian. Untersuchung des State-of-the-Art zur Erstellung von Domänenspezifischen Modellierungssprachen und UML/SysML-Profilen. SPES 2020 Teilergebnis des ZP-AP2, Version 1.0

[SPES11b]

Tenbergen, Bastian; Daun, Marian. UML/SysML-Profil und MDGPlug-In für Enterprise Architect zur Modellierung von KAOSZieldiagrammen auf Basis von UML/SysML. Version 1.2 vom 13.10.2010

[SPES11c]

Avramova, Nadezhda; Daun, Marian; Tenbergen, Bastian; Weyer, Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML. SPES 2020 Teilergebnis des ZP-AP2, Version 1.0 vom 02.03.2011

[SPES11d]

Daun, Marian; Gabrisch, Sebastian; Tenbergen, Bastian; Weyer, Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML. SPES 2020 Teilergebnis des ZP-AP2, Version 1.1 vom 12.04.2011

[SPES11e]

Tenbergen, Bastian; Daun, Marian; Bohn, Philipp. Leitfaden und Projektschablonenbeschreibung für die modellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs. SPES Deliverable D2.4B, Version 1.0 vom 29.04.2010.

[SPES11f]

Eder, Sebastian; Vogelsang, Andreas; Feilkas, Martin; Gezgin, Tayfun; Daun, Marian; Tenbergen, Bastian; Weyer, Thorsten. Seamless Modeling of an automation example using the SPES methodology. SPES Teilergebnis, Draft Version 0.3 vom 27.05.2011.

[SPES11g]

Fasse, Friedrich-W.; Lauenroth, Kim; Heuer, André: Durchführung der Evaluierung. SPES Deliverabe D-EN-2.1b, Version 1.0.

[SPES11h]

Laskowski, Michael; Fasse, Friedrich-W.; Heuer, André: Zusammenfassung der Evaluierung. SPES Deliverable D-EN-2.1c. Version 1.0.

[SPES12a]

Daun, Marian; Fockel, Markus; Holtmann, Jörg, Tenbergen, Bastian. Integration der Requirements-Engineering-Ansätze von ZP-AP2 und AWP-AU-AP3. SPES 2020 Teilergebnis, Januar 2012.

[SPES12b]

Rzepka, Mark; Bandyszak, Thorsten. Fallbeispiel Flugsteuerungssystem. SPES 2020 Teilergebnis v1.0 vom 11.01.2012.

[SPES12c]

Dieudonne, Laurent; Haider, Oliver. Fallbeispiel AV-FB1: Frühe Validierung der Anforderungen (Testbarkeit) Teil 2: Modellbasierte Anforderungen des Flugsteuerungssystems Bewertung. SPES 2020 Teilergebnis vom 16.01.2012 v1.0. Tenbergen, Bastian; Daun, Marian; Gabrisch, Sebastian: Fallbeispiel Luftsystem. SPES 2020 Teilergebnis v1.0 vom 19.01.2012. Daun, Marian; Föcker, Felix; Tenbergen, Bastian: Fallbeispiel Klimakontrollsystem. SPES 2020 Teilergebnis vom 20.01.2012 v1.0.

[SPES12d] [SPES12e]

Zuletzt geändert: 27.04.2012 10:00

27/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf [STP10]

[STP11a]

Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus (2010). Modellbasiertes Requirements Engineering – Eine Situationsanalyse zum Stand der Praxis. Softwaretechnik Trends 30(1). Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus (2011). Requirements Engineering – An Investigation of Industry Needs. Proceedings of Requirements Engineering: Foundations for Software Quality REFSQ 2011.

[STP11b]

Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus (2011). Industry Needs and Research Directions in Requirements Engineering for Embedded Systems. Requirements Engineering Journal. DOI: 10.1007_s00766-011-0144-x. 2011.

[TAM1]

Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly 13:319-340.

[TAM2]

Venkatesh, V.; Davis, F. D. (2000). A theoretical extension of the technology acceptance model: Four longitudinal field studies. Management Science 46:186-204.

[TAM3]

Venkatesh, V.; Bala, H. (2008). Technology Acceptance Model 3 and a Research Agenda on Interventions. Decision Sciences 39(2): 273-315.

[TTF]

Goodhue, D. (1998). Development and Measurement Validity of a Task-Technology Fit Instrument for User Evaluations or Information Systems. Decision Sciences 29(1):105-138

[VMDD03]

Venkatesh, V.; Morris, M. G.; Davis, G. B.; Davis, F. D. (2003). Use acceptance of information technology: Toward a unified view. MIS Quarterly 27:425-478.

Zuletzt geändert: 27.04.2012 10:00

28/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

7 Anhang A – Möglichkeiten zur domänenspezifischen Anpassung des RE-Ansatzes auf Basis der Ergebnisse von Fallbeispiel Flugsteuerungssystem In diesem Anhang werden Möglichkeiten zur domänenspezifischen Anpassung des Requirements Engineering-Ansatzes (im Folgenden RE-Ansatz genannt) aufgezeigt. Diese Anpassungsmöglichkeiten stellen keine Evaluation im eigentlichen Sinn dar, es sind generell Erkenntnisse die auf den gesammelten Erfahrungen bei der Modellierung eines Fallbeispiels basieren. Diese Erkenntnisse werden zusätzlich durch eine Bewertung von domänenerfahrenen Industriepartnern angereichert. Deswegen erschien es wertvoll die Anpassungsmöglichkeiten zusätzlich im Anhang zu beschrieben. Die vorgestellten Anpassungsmöglichkeiten sind das Ergebnis des Fallbeispiels Flugsteuerungssystem [SPES12b] und des das Fallbeispiel bewertenden Analysedokumentes [SPES12c]. Dieses Fallbeispiel ist eines der Fallbeispiele, die zur Evaluierung des RE-Ansatzes aufgesetzt wurden (siehe hierzu Abschnitt 2.3.1). Das Fallbeispiel Flugsteuerungssystem (auch „1-D Flight Control System Specification“ genannt) verfolgt das Ziel, Anforderungen an ein Avionik-System, ein beispielhaftes und in der Funktion reduziertes Flugsteuerungssystem, modellbasiert nach dem RE-Ansatz zu spezifizieren. Die speziellen Rahmenbedingungen der Avionik-Domäne stellen den als theoretische Grundlage dienenden RE-Ansatz vor neue Herausforderungen, da spezielle Sicherheitsanforderungen und darauf basierende Entwurfsentscheidungen bei der Modellierung berücksichtigt werden müssen. Nicht zuletzt spielen auch die umfangreichen Erfordernisse im Zusammenhang mit der Zertifizierung, entsprechend den in der Avionik vorgeschriebenen Sicherheitsstandards, eine wichtige Rolle. Die Erkenntnis, die aus der modellbasierten Spezifikation des Flugsteuerungssystems gewonnen wird, zeigt, dass der angewandte RE-Ansatz um einige domänenspezifische Aspekte der Avionik ergänzt bzw. angepasst werden sollte. Die Möglichkeiten zur Anpassung an domänenspezifische Avionikaspekte werden in diesem Anhang vorgestellt. Dieser Anhang ist folgenderweise aufgebaut: Im nächsten Abschnitt wird das Fallbeispiel Flugsteuerungssystem mit seinen Ergebnissen vorgestellt, wobei ein besonderes Augenmerk auf die Herausforderungen der sicherheitskritischen Avionik-Domäne gerichtet wird. Anschließend werden im Abschnitt 7.2 die Möglichkeiten zur Anpassung des RE-Ansatzes aufbauend auf den Ergebnissen und Erfahrungen, die im Fallbeispiel gesammelt worden sind, beschrieben.

7.1 Fallbeispiel Flugsteuerungssystem und die Herausforderungen der sicherheitskritischen Avionik-Domäne In diesem Abschnitt wird das Fallbeispiel Flugsteuerungssystem, sowie die mit der Domäne des Fallbeispiels verbundenen Herausforderungen beschrieben. Das Fallbeispiel ist Teil der übergeordneten Avionik-Fallstudie und gehört zum Teilbereich der Modellierung und frühen Validierung von Anforderungen. Das Fallbeispiel wurde von dem Unternehmen Liebherr Aerospace in Zusammenarbeit mit der Universität Duisburg-Essen getragen und ausgearbeitet. Das Fallbeispiel besteht aus folgenden vier Ergebnissen: (1) textuelle Spezifikation (2) modellbasierte Spezifikation (3) Beschreibung der modellbasierten Spezifikation [SPES12b] (4) Analyse der modellbasierten Spezifikation [SPES12c]. Das Fallbeispiel verfolgt das Ziel, Anforderungen an ein Avionik-System, hier ein beispielhaftes Flugsteuerungssystem, modellbasiert zu spezifizieren; dies bildet die Zuletzt geändert: 27.04.2012 10:00

29/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf Grundlage für die Betrachtung der übergeordneten Forschungsgegenstände Modellierung, Frühvalidierung und Testbarkeit von Anforderungen. Aus organisatorischer Sicht wurden die zur Ausarbeitung des Fallbeispiels notwendigen Aufgaben klar abgegrenzt und den beiden Partnern zugewiesen; die Firma Liebherr lieferte mit der textuellen Spezifikation des Flugsteuerungssystems den Input für die anschließende Modellierung der spezifizierten Anforderungen, welche von Mitarbeitern der Universität Duisburg-Essen durchgeführt wurde. Die Schritte wurden nicht einmalig, sondern in mehreren Iterationen und unter kontinuierlichem Austausch von Informationen zwischen beiden Seiten ausgeführt. Durch eine gegenseitige Qualitätssicherung der beiden Dokumente bzw. Artefakte wurde eine hohe Qualität der textuellen Anforderungen und der Modelle sichergestellt. Bei dem spezifizierten „1-D Flight Control System“ handelt es sich um ein hypothetisches Flugsteuerungssystem, das den Flug des Flugzeugs steuert und dazu keinerlei mechanische Verbindung zwischen den Eingaben des Piloten und den Steuerflächen benötigt („fly by wire“). Zur Komplexitätsreduktion dient das System lediglich der Steuerung des Flugzeugs entlang der Nickachse; die zwei weiteren Achsen des zugrunde liegenden Koordinatensystems, Roll- und Gierachse, werden nicht berücksichtigt. Außerdem konzentriert sich die Spezifikation des hypothetischen Flugsteuerungssystems auf die Steuerung des Flugzeugs in der Luft, d. h. Start und Landung des Flugzeuges werden nicht betrachtet. Eine Besonderheit der Avionik-Domäne stellen die Safety-Anforderungen dar. Aufgrund der erforderlichen Sicherheit aller am Fluge beteiligten Personen, der extremen physikalischen Rahmenbedingungen und der daraus resultierenden hohen Anforderungen, sowohl an Hard- und Software-Bauteile des Flugzeugs als auch an die Qualifikation und Aufmerksamkeit des Piloten, unterliegen Avionik-Systeme speziellen regulatorischen Rahmenbedingungen und Qualitätsanforderungen. Die Verlässlichkeit von Avionik-Systemen hat dabei eine vorrangige Bedeutung. Da besonders Flugsteuerungssysteme im Hinblick auf einen sicheren Flug als kritisch einzustufen sind, wird ebenfalls eine sehr hohe Integrität dieser Avionik-Systeme erwartet. Entsprechend muss die Eintrittswahrscheinlichkeit von Fehlern extrem gering sein, weswegen beispielsweise redundant ausgelegte Systemkomponenten oder redundante Informationsübertragungswege benötigt werden. An dieser Stelle wird auf den DO-178B-Standard verwiesen, der sich speziell auf die Entwicklung von AvionikSoftware bezieht. Um die Ursachen für die in den genannten Sicherheitsaspekten begründeten, speziellen Entwurfs-Entscheidungen nachvollziehbar zu machen, werden SafetyAnforderungen im Rahmen der modellbasierten Spezifikation [SPES12b] in dedizierten Diagrammen abgebildet. Die Modellierung von Redundanzen ist außerdem eine der größeren Herausforderungen der Fallstudie und wird entsprechend mittels erweiterten Modellierungstechniken behandelt. Die nach dem RE-Ansatz modellierten Anforderungen wurden abschließend vom SPES-Industriepartner Liebherr Aerospace auf die Eignung für den praktischen Einsatz in der sicherheitskritischen Avionik-Domäne bewertet. Das Ergebnis dieser Bewertung wird im Dokument [SPES12c] festgehalten. Diese Bewertung dient als Anregung für die Erarbeitung von Möglichkeiten zur Avionik-spezifischen Anpassung des RE-Ansatzes, die im nächsten Abschnitt vorgestellt werden.

7.2 Erkannte Problembereiche und Verbesserungsvorschläge In diesem Abschnitt werden die Möglichkeiten zur domänenspezifischen Anpassung des RE-Ansatzes auf Basis der Ergebnisse des oben beschriebenen Fallbeispiels Flugsteuerungssystem vorgestellt. Die Hauptmotivation hierfür liefert das AnalysedoZuletzt geändert: 27.04.2012 10:00

30/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf kument [SPES12c] in dem die in der Fallstudie erstellten Anforderungsmodelle auf Eignung für den Einsatz in der Avionik-Domäne bewertet worden sind. Dabei werden nur die Punkte aus dem Analysedokument berücksichtigt, die den RE-Ansatz vor neuen Herausforderungen stellen. Die meisten restlichen Punkte aus dem Analysedokument sind auf konkrete Modellierungsprobleme innerhalb der Fallstudie nur bezogen und lassen sich durch eine Korrektur der Fallstudienmodelle beheben. Im den folgenden Unterabschnitten werden die einzelnen Anpassungsmöglichkeiten geschildert, indem jeweils das erkannte Problembereich und dazu ein Verbesserungsvorschlag beschrieben werden.

7.2.1 Modellierung von Redundanzen Problem: Im Bereich der Avionik wird eine dedizierte Berücksichtigung von Redundanzen in den Anforderungs- und Entwurfsmodellen benötigt; der RE-Ansatz liefert hierfür keine konkreten Anweisungen. Im Rahmen der Fallstudie wurde eine initiale Technik zur Modellierung von Redundanzen prototypisch ausgearbeitet und eigesetzt. So hat es sich bezüglich der Lesbarkeit der Diagramme bewährt, Redundanzen zusätzlich zu einer redundanzfreien Perspektive zu modellieren und – falls möglich – von einer eindeutigen Identifikation redundanter Systembestandteile abzusehen, um den Diagrammen einen allgemeingültigen Charakter zu verleihen (für Einzelheiten über die prototypische Technik siehe [SPES12b] und dort insbesondere das Kapitel 18). Bei der Bewertung der Modelle hat sich jedoch herausgestellt, dass die prototypische Technik nicht ausreichend ist, und so ist die Redundanz immer noch „zu komplex dargestellt. Warum müssen die redundanten Elemente dupliziert werden? […] Nur in wenigen Fällen sollte eine Duplikation der grafischen Elemente erscheinen. Z.B. wenn ein Requirement die Herkunft von Signalen explizit benutzt. Dann müssen die Signalnamen eindeutig identifiziert werden.“ [SPES12c] Verbesserungsvorschlag: Es müssen noch konkrete Regeln oder Heuristiken zur Behandlung von Redundanzen als Anpassung/Ergänzung des Ansatzes definiert werden. Insbesondere wird vorgeschlagen Modellierungskonstrukte wie „SysML/UML-“{Constraint}“ oder ein “Tagged-Value {Redundant = xxx}““ [SPES12c] zu verwenden.

7.2.2 Modellierung von Safety-Anforderungen Problem: „Der verwendete RE-Ansatz sieht keine dedizierte Betrachtung von SafetyAnforderungen vor. Dies ist im Hinblick auf das spezifizierte Flugsteuerungssystem problematisch, da den Safety-Anforderungen, bei sicherheitskritischen AvionikSystemen eine besondere Bedeutung zukommt. Mit ihnen wird u. a. die Einführung von redundanten Systemkomponenten begründet.“ [SPES12b] „Zudem ist nicht immer nachvollziehbar durch welche Modellierungsaspekte (Control/Monitor-Architektur, Redundanzen, …) die […] Safety-Requirements im Design umgesetzt und abgedeckt werden.“ [SPES12c] Verbesserungsvorschlag: In der Fallstudie wurde initialerweise eine einfache Modellierungstechnik der Safety-Anforderungen mittels SysMLRequirementsdiagrammen aufgesetzt (siehe [SPES12b] und dort u.a. Abschnitt 4.3). Diese Technik könnte weiterentwickelt werden, um beispielsweise die Zuordnung von Fehlertoleranzmaßnahmen zu Safety-Anforderungen expliziter darzustellen.

Zuletzt geändert: 27.04.2012 10:00

31/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

7.2.3 Explizite Dokumentation der Nachvollziehbarkeit zwischen verschiedenen Artefakten, Modellen und Modellelementen Problem: „Die Traceability-Methodik sollte […] erläutert werden. Gegebenenfalls ist diese durch die Namensgebung vorhanden. Dann sollten aber Aussagen bzgl. des Aufbaus (Pre-/Suffix), … dargestellt werden. Empfohlen wird jedoch die Verwendung von Tracepoints und Verlinkungstabellen, da sich diese Mittel in der Praxis sehr bewährt haben (hohe Eindeutigkeit, geringe Verwechslungsgefahr, einfache Handhabung, …). Ohne eine eindeutige und einfache Verlinkung von einzelnen Requirements, ist die in der Luftfahrt geforderte Nachweisführung bzgl. Erfüllung und Verifikation der Anforderungen nur schwer umsetzbar.“ [SPES12c] Verbesserungsvorschlag: Es gibt konkrete Überschneidungen zwischen verschiedenen Artefakttypen, die im RE-Ansatz ausgenutzt werden. Diese Überschneidungen stellen den Übergang zwischen den Artefakten dar. Die explizite Darstellung der Übergänge müsste noch weiter ausgebaut werden. Ein Beispiel hierfür wird in Abschnitt 2.9 in [SPES12c] vorgestellt.

7.2.4 Stärkere Integration von natürlichsprachlichen Anforderungen und Anforderungsmodellen Problem: „Ohne eine eindeutige und einfache Identifizierung von einzelnen Requirements, ist die in der Luftfahrt geforderte Nachweisführung bzgl. Erfüllung und Verifikation der Anforderungen nur schwer umsetzbar.“ [SPES12c] Dabei erleichtert die traditionell an textuellen Dokumenten orientierte Nachweisführung erheblich, wenn die Anforderungen gleichzeitig neben den Anforderungsmodellen auch mittels textuellen Anforderungen spezifiziert werden. So könnten die Anforderungsmodelle den Entwicklungsprozess unterstützen, und die textlichen Spezifikationen den Zertifizierungsprozess vereinfachen. Verbesserungsvorschlag: Der RE-Ansatz macht genaue Angaben, an welchen Stellen schablonenbasierte, komplementäre textuelle (natürlichsprachliche) Anforderungen eingesetzt werden können/müssen. Die praktischen Erfordernisse gehen aber über den komplementären Einsatz von Anforderungsmodellen und natürlichsprachlichen Anforderungen hinaus und Zielen auf parallele und gleichwertige Entwicklung von beiden Artefaktentypen. Hierbei wäre eine besondere Herausforderung (und ggf. auch ein Nachteil) die Synchronität der beiden Artefaktentypen im Laufe eines Entwicklungsprojektes zu erhalten.

7.2.5 Klarere Trennung von Anforderungen und Design Problem: „Die Unterscheidung zwischen Anforderung und Design sollte ggf. klarer dargestellt werden.“ [SPES12c] Verbesserungsvorschlag: Ein Vorschlag zur klareren Trennung entsprechend den aus der Avionik kommenden Erfordernissen wird in Kapitel 2.9 in [SPES12c] vorgestellt. Das Beispiel stellt es nicht deutlich heraus, wie zwischen Anforderungen und Design (werden hier als Abstraktionsebenen bezeichnet) unterschieden werden soll. Aus den Traceability-Tabellen in Kapitel 2.9 kann man schließen, dass unter Anforderungen nur die Umgebungsdiagramme (der Kontext) fallen und die lösungsorientierten Anforderungen zusammen mit den Architekturdiagrammen das Design ('White-Box'-Betrachtung) bilden. Hier entsteht ggf. eine Verschiebung im Verständnis der Konzepte. Beim RE-Ansatz gehören nämlich die lösungsorientierten Anforderungen zu der Anforderungsperspektive.

Zuletzt geändert: 27.04.2012 10:00

32/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf Hier wäre eine Untersuchung notwendig, wo genau die Unterschiede zwischen Avionik- und RE-Ansatz-Perspektiven in der Betrachtung der Trennung zwischen (bzw. Verzahnung von) Anforderungen und Design liegen. Darauf aufbauend kann im zweiten Schritt ein Verbessrungsvorschlag ausgearbeitet werden.

Zuletzt geändert: 27.04.2012 10:00

33/36

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

8 Anhang B – Fragebogen zur Methodenakzeptanz (auf der nächsten Seite)

Zuletzt geändert: 27.04.2012 10:00

34/36

- Fragebogen zur Evaluierung des in ZP-AP2 entwickelten modellbasierten Requirements-Engineering-Ansatzes -

Version: 1.0

Projektbezeichnung

SPES 2020

Verantwortlich

Bastian Tenbergen

QS-Verantwortlich



Erstellt am

10.10.2011

Zuletzt geändert

02.12.2011 13:18 Vertraulich für Partner: ; ; …

Freigabestatus X

Projektöffentlich Öffentlich

Bearbeitungszustand

in Bearbeitung vorgelegt X

fertig gestellt

1/9

Weitere Produktinformationen Erzeugung

Sebastian Gabrisch (SG), Bastian Tenbergen (BT)

Mitwirkend

Marian Daun (MD)

Änderungsverzeichnis Änderung

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Nr.

Datum

Version

1

10.10.11

0.1

Alle

Initiale Produkterstellung

SG

In Bearbeitung

2

17.10.11

0.2

Alle

Überarbeitung und Erweiterung

BT

In Bearbeitung

3

11.11.11

0.3

Alle

Finalisierung und Fertigstellung

BT

In Bearbeitung

4

02.12.11

1.0

Alle

Review und Qualitätssicherung

MD

Fertig gestellt

2/9

Vielen Dank für Ihre Teilnahme an unserer Evaluierung! Ziel dieses Fragebogens ist, eine Evaluierung des Requirements-Engineering-Ansatzes hinsichtlich bestimmter Evaluierungskriterien quantitativ zu ermöglichen.

Bitte lesen Sie das Ihnen zur Verfügung gestellte Informationsmaterial durch und füllen Sie den Fragebogen möglichst vollständig durch ankreuzen von genau einer Antwortmöglichkeit aus. Selbstverständlich werden alle Ihre Antworten vertraulich und anonym behandelt.

Falls Sie eine Frage aus betriebsinternen oder anderen Gründen nicht beantworten können, so vermerken Sie dies bitte an der Frage.

Für Fragen, die eine 7-Punkt-Skala vorgeben, gilt grundsätzlich das folgende Schema: 1 = trifft nie zu 2 = trifft in den seltensten Fällen zu 3 = trifft eher selten zu 4 = teils-teils (trifft genauso oft zu, wie es nicht zutrifft) 5 = trifft eher oft zu 6 = trifft in den meisten Fällen zu 7 = trifft immer zu

3/9

ID

Frage

1 trifft nie zu

2 fast nie

3 selten

4 teilsteils

5 oft

6 häufig

7 trifft immer zu

4

Ich finde den Ansatz nützlich für meinen Job.

O

O

O

O

O

O

O

81

Es gibt nicht genug Trainingsmaterial zum Ansatz, damit ich die Artefakte schnell und einfach finden, verstehen und damit arbeiten kann.

O

O

O

O

O

O

O

14

Ich habe Zugriff auf die notwendigen Ressourcen, um den Ansatz verwenden zu können.

O

O

O

O

O

O

O

86

Die Artefakte werden in einem lesbaren und nützlichen Format dargestellt.

O

O

O

O

O

O

O

3

Die Verwendung des Ansatzes erhöht meine Effektivität in meinem Job.

O

O

O

O

O

O

O

39

In meinem Job ist es wichtig, den Ansatz verwenden zu können.

O

O

O

O

O

O

O

63

Es ist einfach, mit dem Ansatz bestimmte Informationen in den Artefakten zu finden, selbst wenn ich den Ansatz noch nie verwendet habe.

O

O

O

O

O

O

O

1

Der Ansatz verbessert meine Leistung in meinem Job.

O

O

O

O

O

O

O

33

Ich verwende den Ansatz freiwillig.

O

O

O

O

O

O

O

16

Der Ansatz ist nicht kompatibel zu anderen Verfahren, die ich bei meiner Arbeit verwende.

O

O

O

O

O

O

O

40

In meinem Job ist es relevant, den Ansatz verwenden zu können.

O

O

O

O

O

O

O

4/9

ID

Frage

1 trifft nie zu

2 fast nie

3 selten

4 teilsteils

5 oft

6 häufig

7 trifft immer zu

53

Dem Ansatz fehlen wichtige Artefakte, die notwendig sind, um meine Arbeit zu vereinfachen.

O

O

O

O

O

O

O

11

Ich könnte meine Arbeit mit dem Ansatz durchführen, wenn mir jemand vorher zeigt, wie es geht.

O

O

O

O

O

O

O

46

Ich glaube, dass ich mit anderen über die Konsequenzen der Nutzung des Ansatzes reden könnte.

O

O

O

O

O

O

O

55

Es ist deutlich schwieriger, meine Aufgaben mit dem Ansatz als ohne den Ansatz zu erledigen, da der Ansatz wichtige Artefakte nicht bereitstellt.

O

O

O

O

O

O

O

5

Den Ansatz anzuwenden ist klar und verständlich.

O

O

O

O

O

O

O

34

Meine Vorgesetzten zwingen mich nicht, den Ansatz zu verwenden.

O

O

O

O

O

O

O

54

Die Artefakte, die der Ansatz bereitstellt sind genau die Richtigen, um meine Aufgaben erledigen zu können.

O

O

O

O

O

O

O

13

Ich habe die Kontrolle über die Arbeit mit dem Ansatz.

O

O

O

O

O

O

O

35

Auch wenn er hilfreich ist, die Verwendung des Ansatzes ist nicht verpflichtend in meinem Job.

O

O

O

O

O

O

O

44

Ich schätze die Ausgabeartefakte des Ansatzes als exzellent ein.

O

O

O

O

O

O

O

82

Mir steht ausreichend Training zur Verfügung, um meine Arbeit mit dem Ansatz effektiv durchführen zu können.

O

O

O

O

O

O

O

5/9

ID

Frage

1 trifft nie zu

2 fast nie

3 selten

4 teilsteils

5 oft

6 häufig

7 trifft immer zu

66

Es ist einfach, Zugriff auf die Artefakte, die ich brauche, zu erhalten.

O

O

O

O

O

O

O

51

Ich plane, den Ansatz in den nächsten 12 Monaten zu verwenden.

O

O

O

O

O

O

O

12

Ich könnte meine Arbeit mit dem Ansatz durchführen, wenn ich zunächst mit einem anderen Ansatz aus dem SPES-Projekt gearbeitet hätte.

O

O

O

O

O

O

O

47

Die Arbeitsergebnisse durch Nutzung des Ansatzes erschließen sich mir leicht.

O

O

O

O

O

O

O

57

Der Ansatz beinhaltet Artefakte mit dem für meine Zwecke richtigen Detaillierungsgrad.

O

O

O

O

O

O

O

43

Die Qualität der Ausgabeartefakte des Ansatzes ist unproblematisch.

O

O

O

O

O

O

O

67

Der Ansatz ist zu unflexibel, um mir schnell andere Artefakte zur Verfügung zu stellen, wenn ich spontan ein anderes Artefakt benötige.

O

O

O

O

O

O

O

88

Die Artefakte werden in so vielen verschiedenen Kategorien eingeordnet, dass es schwierig ist, zu verstehen, wie sie effektiv zu nutzen sind.

O

O

O

O

O

O

O

41

Die Verwendung des Ansatzes ist unabdingbar für verschiedene Aufgaben in meinem Job.

O

O

O

O

O

O

O

64

Es ist einfach, unter Verwendung des Ansatzes Informationen über das zu entwickelnde System zu erhalten.

O

O

O

O

O

O

O

48

Ich würde Schwierigkeiten haben, meinen Kollegen den Mehrwert durch die Nutzung des Ansatzes zu erklären.

O

O

O

O

O

O

O

58

Die Artefakte des Ansatzes sind für meine Zwecke genau genug.

O

O

O

O

O

O

O

6/9

ID

Frage

1 trifft nie zu

2 fast nie

3 selten

4 teilsteils

5 oft

6 häufig

7 trifft immer zu

65

Ich kann auf Artefakte schnell und einfach zugreifen, wenn ich sie brauche.

O

O

O

O

O

O

O

8

Ich finde es einfach, mit dem Ansatz das zu tun, was ich tun möchte.

O

O

O

O

O

O

O

49

Unter der Voraussetzung, dass ich den Ansatz verwenden kann, plane ich, diesen auch zu verwenden.

O

O

O

O

O

O

O

85

Die Artefakte, die ich benötige werden mir durch den Ansatz in einer verständlichen Form zur Verfügung gestellt.

O

O

O

O

O

O

O

45

Ich habe keine Schwierigkeiten mit anderen über die Ausgabeartefakte des Ansatzes zu reden.

O

O

O

O

O

O

O

56

Der Ansatz sorgt dafür, dass Artefakte ausreichend detailliert dokumentiert werden.

O

O

O

O

O

O

O

6

Den Ansatz zu verwenden erfordert wenig mentale Anstrengung.

O

O

O

O

O

O

O

50

Ich werde sicherlich den Ansatz in Zukunft verwenden.

O

O

O

O

O

O

O

87

Es gibt so viele Artefakte, dass es schwierig ist, zu verstehen, in welcher Situation welche Artefakte einzusetzen sind.

O

O

O

O

O

O

O

69

Ich mache keinen schnellen Fortschritt, wenn ich schnell auf neue Artefakte zugreifen muss.

O

O

O

O

O

O

O

2

Der Ansatz erhöht meine Produktivität in meiner Arbeit.

O

O

O

O

O

O

O

7/9

ID

Frage

1 trifft nie zu

2 fast nie

3 selten

4 teilsteils

5 oft

6 häufig

7 trifft immer zu

10

Ich könnte meine Arbeit unter Verwendung des Ansatzes durchführen, wenn mir nur die Dokumentation (bspw. Kapitel „Requirements View“) zur Verfügung steht.

O

O

O

O

O

O

O

59

Bei der Verwendung des Ansatzes gibt es Probleme mit der Genauigkeit der bereitgestellten Artefakte.

O

O

O

O

O

O

O

68

Wenn sich Geschäftsanforderungen ändern, ist es einfach mit dem Ansatz die Anforderungen an das System zu ändern.

O

O

O

O

O

O

O

9

Ich könnte meine Arbeit mit dem Ansatz durchführen, wenn ich niemanden hätte, der mir die Verwendung erklärt.

O

O

O

O

O

O

O

42

Die Qualität der Ausgabeartefakte, die ich durch den Ansatz erhalte, ist hoch.

O

O

O

O

O

O

O

15

Wenn man die Ressourcen, Möglichkeiten und das Wissen bedenkt, die man benötigt, den Ansatz zu verwenden, dann wäre es einfach für mich, dies auch zu tun.

O

O

O

O

O

O

O

7

Ich finde, dass der Ansatz leicht zu verwenden ist.

O

O

O

O

O

O

O

8/9

Vielen Dank nochmals für Ihre Teilnahme! Wenn Sie uns nun noch Kommentare oder Meinungen mitteilen möchten, dann können Sie dies auf dieser Seite gerne tun.

9/9

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

9 Anhang C – Fragebögen zur Methodenanwendbarkeit (auf der nächsten Seite)

Zuletzt geändert: 27.04.2012 10:00

35/36

EvaSys

Paluno - The Ruhr Institute of Software Technology (Woche 7)

Markieren Sie so:

Bitte verwenden Sie einen Kugelschreiber oder nicht zu starken Filzstift. Dieser Fragebogen wird maschinell erfasst.

Korrektur:

Bitte beachten Sie im Interesse einer optimalen Datenerfassung die links gegebenen Hinweise beim Ausfüllen.

ID/PIN Liebe/r Student/in, um die folgenden Fragebögen immer der gleichen Person zuzuordnen und um trotzdem anonym zu bleiben, hast du dir im ersten Fragebogen eine ID ausgedacht. Bitte gib ihn im folgenden Feld wieder an. Unser Hinweis vom ersten Fragebogen war: Erster Buchstabe vom Geburtsnamen deiner Mutter + letzte zwei Ziffern deiner Telefonnummer + Initialien deines Großvaters mütterlicherseits + letzten beiden Ziffern deiner Postleitzahl" (Beispiel: M34HM57)

Aufwandsabschätzung In der letzten Woche habe ich mich mit dem folgenden Artefakt... ...Ziele

sehr wenig

...Zielbaum

sehr wenig

...Szenarien

sehr wenig

...textuelle Anforderungen

sehr wenig

...Kontextmodell

sehr wenig

...Hard- und Softgoals

sehr wenig

...Message Sequence Charts (MSCs)

sehr wenig

...Datenflussdiagramme (DFDs)

sehr wenig

...logische und technische Ziele

sehr wenig

...Datenmodell

sehr wenig

...technisches Konzept

sehr wenig

sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt sehr viel beschäftigt

Insgesamt habe ich mich schon mit den folgenden Artefakten beschäftigt: Ziele Zielbaum Datenmodell Kontextmodell Message Sequence Charts (MSCs) Datenflussdiagramme (DFDs) textuelle Anforderungen Die Arbeitsbelastung für die Entwicklung in dieser Woche empfand ich als... Die Arbeitsbelastung für das Review in dieser Woche empfand ich als...

F462U39373P1PL0V0

Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet

Szenario technisches Konzept logische und technische Ziele

zu niedrig

zu hoch

zu niedrig

zu hoch

21.06.2011, Seite 1/4

EvaSys

Paluno - The Ruhr Institute of Software Technology (Woche 7)

Förderung der Diskussion (aus Perspektive des Modellierers) Die Methodik hat eine zielgerichtete Diskussion unterstützt. Die Methodik hat mir geholfen meine Gedanken über die Aufgabe zu kommunizieren. Die Methodik hat mir geholfen, zielgerichtete Fragen zu stellen. Die Methodik hat den fachlichen Austausch innerhalb der Gruppe gefördert. In der zurückliegenden Woche haben wir uns innerhalb der Gruppe intensiv über das System ausgetauscht. In der zurückliegenden Woche haben wir uns zwischen den Gruppen intensiv über das System ausgetauscht. Die Arbeit in der Gruppe schätze ich als konstruktiv ein.

stimme völlig zu stimme völlig zu stimme völlig zu stimme völlig zu stimme völlig zu stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu

Nützlichkeit der Methodik Ziele waren für mich nützlich bei meiner Arbeit in der vergangenen Woche. Zielbäume waren für mich nützlich bei meiner Arbeit in der vergangenen Woche. Szenarien waren für mich nützlich bei meiner Arbeit in der vergangenen Woche. Textuelle Anforderungen waren für mich nützlich bei meiner Arbeit in der vergangenen Woche.

stimme völlig zu stimme völlig zu stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu

Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet

Das Kontextmodell war für mich nützlich bei meiner Arbeit in der vergangenen Woche. Message Sequence Charts (MSCs) waren für mich nützlich bei meiner Arbeit in der vergangenen Woche.

stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu

Artefakttyp nicht verwendet Artefakttyp nicht verwendet

Datenflussdiagramme (DFDs) waren für mich nützlich bei meiner Arbeit in der vergangenen Woche.

stimme völlig zu

stimme überhaupt nicht zu

Artefakttyp nicht verwendet

Hard- und Softwaregoals waren für mich nützlich bei meiner Arbeit in der vergangenen Woche.

stimme völlig zu

stimme überhaupt nicht zu

Artefakttyp nicht verwendet

Logische und technische Ziele waren für mich nützlich bei meiner Arbeit in der vergangenen Woche.

stimme völlig zu

stimme überhaupt nicht zu

Artefakttyp nicht verwendet

Das Datenmodell war für mich nützlich bei meiner Arbeit in der vergangenen Woche. Das technische Konzept war für mich nützlich bei meiner Arbeit in der vergangenen Woche.

stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu

Artefakttyp nicht verwendet Artefakttyp nicht verwendet

Durch die Anwendung der Methodik habe ich das Gefühl, das System besser verstanden zu haben. Ich habe das Gefühl, dass ich mit der Methodik Sicherheit im Umgang mit der Aufgabenstellung bekommen habe.

stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu

stimme völlig zu stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu

Förderung der Diskussion (aus Perspektive des Reviewers) Die Methodik hat eine zielgerichtete Diskussion unterstützt. Die Methodik hat mir geholfen meine Gedanken über die Aufgabe zu kommunizieren. Die Methodik hat mir geholfen, zielgerichtete Fragen zu stellen.

F462U39373P2PL0V0

21.06.2011, Seite 2/4

EvaSys

Paluno - The Ruhr Institute of Software Technology (Woche 7)

Förderung der Diskussion (aus Perspektive des Reviewers) [Fortsetzung] Die Methodik hat den fachlichen Austausch innerhalb der Gruppe gefördert. In der zurückliegenden Woche haben wir uns innerhalb der Gruppe intensiv über das System ausgetauscht. In der zurückliegenden Woche haben wir uns zwischen den Gruppen intensiv über das System ausgetauscht. Die Arbeit in der Gruppe schätze ich als konstruktiv ein.

stimme völlig zu stimme völlig zu stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu

Verständlichkeit der Spezifikation aus der Sicht des Reviewers Die Spezifikation ist für mich als Reviewer nachvollziehbar. Die Abstraktionsebenen haben mir als Reviewer geholfen das zu entwickelnde System zu verstehen. Die Einteilung in lösungsneutrale Anforderungen, lösungsbezogene Anforderungen und Lösungskonzept haben für mich als Reviewer das Verständnis der Spezifikation erhöht. Durch die Methodik war es mir möglich, ein strukturiertes Review durchzuführen. Durch die Methodik war es mir als Reviewer möglich, ein strukturiertes Feedback an die andere Gruppe zu geben. Ich hatte viele Rückfragen an die andere Gruppe bezüglich ihrer Spezifikation.

stimme völlig zu stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu

stimme völlig zu stimme völlig zu stimme völlig zu

stimme überhaupt nicht zu stimme überhaupt nicht zu stimme überhaupt nicht zu

Bitte bewerte, wie hilfreich das folgende Artefakt für dich beim Review war... ...Ziele

sehr hilfreich

gar nicht hilfreich

...Zielbaum

sehr hilfreich

gar nicht hilfreich

...Szenarien

sehr hilfreich

gar nicht hilfreich

...textuelle Anforderungen

sehr hilfreich

gar nicht hilfreich

...Kontextmodell

sehr hilfreich

gar nicht hilfreich

...Hard- und Softgoals

sehr hilfreich

gar nicht hilfreich

...Message Sequence Charts (MSCs)

sehr hilfreich

gar nicht hilfreich

...Datenflussdiagramme (DFDs)

sehr hilfreich

gar nicht hilfreich

...logische und technische Ziele

sehr hilfreich

gar nicht hilfreich

...Datenmodell

sehr hilfreich

gar nicht hilfreich

...technisches Konzept

sehr hilfreich

gar nicht hilfreich

F462U39373P3PL0V0

Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet Artefakttyp nicht verwendet

21.06.2011, Seite 3/4

EvaSys

Paluno - The Ruhr Institute of Software Technology (Woche 7)

Sonstige Fragen Mir hat in dieser Woche am besten gefallen:

Zur Spezifikation des zu entwickelnden Systems wären für mich noch folgende Modelle wichtig gewesen:

Für das Verständnis der Spezifikation wären für mich folgende Informationen oder Artefakte noch interessant gewesen:

Alles weitere, was ich noch sagen wollte:

Vielen Dank für deine Teilnahme an dieser Befragung!

F462U39373P4PL0V0

21.06.2011, Seite 4/4

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von Anforderungen und Entwurf

10 Anhang D – Ein Ansatz zur Spezifikation von Echtzeitanforderungen am Beispiel von Szenarien (auf der nächsten Seite)

Zuletzt geändert: 27.04.2012 10:00

36/36

Ein Ansatz zur Spezifikation von Echtzeitanforderungen

Version: 1.0

Projektbezeichnung

SPES 2020

Verantwortlich

Thorsten Weyer (Universität Duisburg-Essen)

QS-Verantwortlich



Erstellt am

17.02.2011

Zuletzt geändert

19.01.2012 14:40 Vertraulich für Partner: ; ; …

Freigabestatus

Projektöffentlich X Bearbeitungszustand

Öffentlich in Bearbeitung vorgelegt

X

fertig gestellt

Weitere Produktinformationen Erzeugung

Nadezhda Avramova (NA), Björn Wolfahrt (BW), Thorsten Weyer (TW)

Mitwirkend

Änderungsverzeichnis Änderung

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Nr.

Datum

Version

1

17.02.11

0.1

Alle

Produkterstellung

NA, BW

Vorgelegt

2

28.04.11

1.0

-

Review und Finalisierung

TW, NA

Fertig gestellt

Kurzfassung In diesem Dokument wird eine Erweiterung der COSMOD-RE Methode nach [Pohl10] präsentiert. Dabei sollen sich zusätzlich Echtzeitanforderungen durch die Methode in die Spezifikation eines eingebetteten Systems aufnehmen lassen. Die Erweiterung basiert auf einem semantischen Modell für Formalisierung von zeitbehafteten Message Sequence Charts. Das Dokument zeigt auch die Anwendung dieser Erweiterung an einem Beispiel.

Zuletzt geändert: 19.01.2012 14:40

3/25

Inhalt

1

Einordnung und Kurzbeschreibung ..................................................................... 5 1.1 1.2 1.3

2

Motivation und Einordnung ........................................................................... 5 Management Summary ................................................................................ 5 Überblick ...................................................................................................... 5

Einführung in die Modellierung von Eingebetteten Systemen ............................. 6 2.1 Eingebettete Systeme .................................................................................. 6 2.2 Die COSMOD-RE Methode .......................................................................... 6 2.3 Problemstellung............................................................................................ 7 2.4 Verwandte Literatur ...................................................................................... 7 2.4.1 ROOM ................................................................................................... 7 2.4.2 UML-SPT .............................................................................................. 7 2.4.3 MSCs .................................................................................................... 8

3

Modellierung von Echtzeitanforderungen in CODMOD-RE ................................. 9 3.1 Basic Message Sequence Charts ................................................................ 9 3.2 High-Level Message Sequence Charts ...................................................... 11 3.3 Zeitbehaftete MSCs.................................................................................... 11 3.4 Semantisches Modell für zeitbehaftetete MSCs zur Spezifikation von Echtzeitanforderungen in der COSMOD-RE Methode .......................................... 13 3.4.1 Partialordnungsmodell für (Zeitbehaftete) MSCs ................................ 14 3.4.2 Semantik der Partialordnung für Zeitbehaftete MSCs ......................... 16 3.4.3 Besonderheiten der Basic MSC (bMSC) ............................................. 16 3.4.4 Besonderheiten von MSC mit Strukturen ............................................ 17 3.4.5 Besonderheiten der High-Level MSC (hMSC)..................................... 18

4

Beispiel .............................................................................................................. 19 4.1 Anwendungskontext ................................................................................... 19 4.2 Spezifikation der Echtzeiteigenschaften ..................................................... 19 4.2.1 Anforderungen an das SOAHarbor-System ........................................ 19 4.2.2 Formale Spezifikation des Anwendungbeispiels ................................. 20

5

Zusammenfassung ............................................................................................ 24

6

Literaturverzeichnis ........................................................................................... 25

Zuletzt geändert: 19.01.2012 14:40

4/25

1 Einordnung und Kurzbeschreibung 1.1 Motivation und Einordnung Das vorliegende Dokument beschreibt eine Erweiterung der COSMOD-RE Methode um die Möglichkeit zur Spezifikation von Echtzeitanforderungen an eingebettete Systeme. Dieses Dokument betrachtet die COSMOD-RE Methode sowie andere Ansätze zur Spezifikation von Echtzeitanforderungen an eingebettete Systeme. Die vorgestellte Erweiterung berücksichtigt die Besonderheiten der COSMOD-RE Methode.

1.2 Management Summary 1.3 Überblick Abschnitt 2 dieses Dokuments beschreibt die eingebettete Systeme und ihre Eigenschaften, die COSMOD-RE Methode, mit der sich Anforderungen an eingebettete Systeme spezifizieren lassen und die verwandte Literatur zum Problem der Spezifizierung von Echtzeitanforderungen in Modellen für eingebettete Systeme. Im Abschnitt 3 wird die Erweiterung der COSMOD-RE Methode detailliert beschrieben, indem zuerst eine Übersicht über die Message Sequence Charts gegeben wird, und danach auf die eigentliche Erweiterung eingegangen wird. Abschnitt 4 zeigt die Anwendung der beschriebenen Erweiterung an einem Beispiel.

Zuletzt geändert: 19.01.2012 14:40

5/25

2 Einführung in die Modellierung von Eingebetteten Systemen 2.1 Eingebettete Systeme Eingebettete Systeme sind Computersysteme, die nicht als solche wahrgenommen werden [ELLS97]. Sie sind auch dadurch charakterisiert, dass in ihnen Mikroprozessoren eingesetzt werden [Wolf94]. Viele Autoren sind sich einig, dass für eingebettete Systeme eine enge Beziehung zwischen Hardware und Software typisch ist (siehe [ELLS97, Wolf94, Pohl10]). Beispiele für eingebettete Systeme sind Mikrowellengeräte, automatische Türen in Gebäuden oder Fahrzeugen, mobile Telefongeräte, elektronische Systeme in Autos und Flugzeugen. Eine spezielle Art eingebettete Systeme sind diese, an denen auch Echtzeitanforderungen gestellt werden. Dies bedeutet, dass alle oder ein Teil der Funktionen im System innerhalb eines fest definierten Zeitrahmens ausgeführt werden sollen. Beispiele für solche Systeme sind Motorsteuersysteme in Automobilen, Herzschrittmacher, mobile Telefongeräte, Drucker, usw. (siehe [Kope97]).

2.2 Die COSMOD-RE Methode COSMOD-RE (siehe [Pohl10]) ist eine Methode zur Unterstützung der Entwicklung von eingebetteten Systemen und der Hardware-Software Codesign. Der letzte Begriff bezeichnet die parallele Entwicklung von Hardware- und Softwarekomponenten für eingebettete Systeme, da diese eng miteinander interagieren und deren separate Entwicklung nicht umsetzbar ist. Die Spezifizierung eines eingebetteten Systems nach der COSMOD-RE Methode erfolgt durch verschiedene Abstraktionsebenen. Diese sind Systemanforderungsebene, Systemgrobarchitektur-, Funktionsgruppenanforderungen-, HW/SWGrobarchitektur-, HW/SW-Anforderungs- und SW-Deployment-Ebene. Der Detailierungsgrad der erarbeiteten Artefakte steigt in jeder Ebene. So, z.B. werden in der Systemanforderungsebene die Anforderungen für das gesamte Systeme spezifiziert, auf der Funktionsgruppenebene – für einzelne Funktionsgruppen, d.h. Teile des Systems. Aus dem Namen der einzelnen Abstraktionsebenen wird ersichtlich, dass Anforderungen und Architektur parallel entwickelt und entlang der Abstraktionsebenen verfeinert werden. Die COSMOD-RE Methode besteht aus drei Codesign-Prozesse, die Entwicklung von eingebetteten Systemen auf den Abstraktionsebenen bestimmen. Diese sind: System-Codesign Funktionsgruppen-Codesign Komponenten-Codesign In jedem dieser Codesign-Prozesse werden Ziele und Szenarien, Anforderungen und Architektur parallel entwickelt. Die Ziele und Szenarien werden entlang der Abstraktionsebenen verfeinert. Sie dienen in jedem Codesign-Prozess als Grundlage für die Spezifizierung der Anforderungen auf die jeweilige Abstraktionsebene. Aus den Anforderungen wird dann die entsprechende Architektur, wiederum pro Abstraktionsebene entwickelt. Am Ende der Codesign-Prozesse stehen Ziele und Szenarien, AnZuletzt geändert: 19.01.2012 14:40

6/25

forderungen und Architektur für jede Abstraktionsebene, wobei jede Artefakt in jeder Abstraktionsebene verfeinert wird. Die Verfeinerungen, sowie die Artefakte untereinander müssen konsistent sein.

2.3 Problemstellung Wie bisher angemerkt, ist es möglich, dass eingebettete Systeme Zeitaspekte enthalten. Diese sollen in die Spezifikation angegeben werden, damit sie validiert werden können, so dass eventuelle Fehler so früh wie möglich entdeckt werden. Die COSMOD-RE Methode ist für die Spezifizierung von eingebetteten Systemen dadurch vorteilhaft, dass sie die enge Beziehung zwischen Hardware und Software beim Spezifikationsprozess berücksichtigt. Problematisch bei dieser Methode ist, dass sie keine Möglichkeit bietet, Zeitaspekte in der Spezifikation zu notieren. In dieser Arbeit soll dieses Problem gelöst werden, indem eine Erweiterung der COSMODRE Methode entwickelt wird, mit der sich Zeitaspekte in die Spezifikation aufnehmen lassen. Es ist anzumerken, dass Zeitaspekte in der Spezifikation nur diejenigen Modelle betreffen, die dynamische Prozesse des Systems spezifizieren. Solche sind z.B. die Verhaltens-, Kontrollfluss-, Sequenzmodelle, etc. Modelle aus der Spezifikation, die die Systemstruktur spezifizieren enthalten in der Regel keine Zeitaspekte. In der COSMOD-RE Methode sind die Szenariomodelle die einzige Modellgruppe, die dynamische Prozesse des Systems abbildet. Daher wird sich die geplante Erweiterung des COSMOD-RE in diesem Deliverable nur auf die Szenariomodelle auswirken.

2.4 Verwandte Literatur 2.4.1 ROOM Mit der Real-Time Object-Oriented Modeling Methode (ROOM) (siehe [Seli96]) lassen sich Echtzeitsysteme modellieren. Der Fokus dieser Methode ist in der strukturellen Modellierung der Komponente eines Echtzeitsystems. Komponenten werden als Vierecke im Modell angegeben, die durch Ports und Links miteinander verbunden werden können. Jede Verbindung verweist auf einem Kommunikationsprotokoll, der zwischen den beiden verbundenen Komponenten, stattfinden kann. Zeitaspekte werden in dieser Methode relativ durch ein Sequenzdiagramm modelliert. Das Sequenzdiagramm repräsentiert die zeitliche Reihenfolge der Ereignisse, die in einem Kommunikationsprotokoll gegeben sind. Durch State Charts werden die möglichen Ereignisse, die das Echtzeitsystem zu erwarten hat, sowie ihr Antwortoptionen, modelliert.

2.4.2 UML-SPT Das UML-Profil für Schedulability, Performance and Time Specification (SPT) (siehe [OMG05]) ist die meist verwendete UML-Erweiterung zur Spezifikation von Zeitaspekten. Da das SPT Profil die UML Sprache erweitert, ist es für viele Zwecke, aber auch für die Modellierung von Echtzeit-Eingebetteten Systemen geeignet. Das Profil bietet die Möglichkeit Zeitschranken, reale Zeit, Ereigniseintrittszeitpunkte und Dauer anzugeben. Dies geschieht in Form von Annotationen an alle möglichen UMLZuletzt geändert: 19.01.2012 14:40

7/25

Modellierungselemente, für die Zeit relevant sein kann. Solche Elemente können z.B. Aktionen, Transitionen, Nachrichten oder Zustände sein. Die Zeitangaben an den Modellen erweitert diese um die zu beachtenden Zeitaspekten.

2.4.3 MSCs Die Message Sequence Charts (MSCs) sind eine szenariobasierte Modellierungssprache, die hauptsächlich zur Spezifikation von Kommunikation und Verhalten eingesetzt wird [Itut04]. Diese Sprache ähnelt sehr der Sequenzdiagramme aus UML, bietet aber auch die Möglichkeit Zustandsübergänge entsprechend dem Nachrichtenaustausch zu modellieren. Der Eignung der MSCs für die Spezifikation von eingebetteten Systemen wird z.B. in [KGSB98] festgestellt. Die MSCs sind eine standardisierte Sprache und nach dem Jahr 2000 ist es möglich mit ihnen auch Zeitaspekte im Verhalten zu modellieren. Zeitaspekte werden an den Diagrammen in Form von Zeitintervallen angegeben, die beim Eintritt von einem Ereignis anfangen oder enden. Die MSCs bieten auch die Möglichkeit absolute und relative Zeit zu spezifizieren, Zeitintervalle anzugeben, in denen ein Ereignis eintreten soll, etc.

Zuletzt geändert: 19.01.2012 14:40

8/25

3 Modellierung von Echtzeitanforderungen in CODMOD-RE In diesem Abschnitt wird die Erweiterung der COSMOD-RE Methode vorgestellt, die die Methode um die Möglichkeit zur Spezifizierung von Echtzeitanforderungen von eingebetteten Systemen erweitern soll. Wie bisher angemerkt, beziehen sich Zeitaspekte nur auf die dynamischen Modelle einer Spezifikation. Das sind die Modelle, die Verhalten oder Nachrichtenaustausch im Laufe einer bestimmten Zeit ausdrücken. In der COSMOD-RE Methode sind das lediglich die Szenariomodelle, die Interaktionen zwischen den Komponenten und/oder Akteuren eines eingebetteten Systems abbilden. Die anderen Modellarten, die in COSMOD-RE eine Rolle spielen, sind die Zielmodelle und die Modelle über lösungsorientierte Anforderungen. Diese Modelle enthalten die Ziele eines eingebetteten Systems und seine Anforderungen unter der Funktionsperspektive (siehe [Pohl10]). Bei beiden Modellen spielt die Zeit keine Rolle. Aus diesem Grund sind die bei der Erweiterung der COSMOD-RE Methode um Zeitaspekte nicht relevant. Für die Modellierung von Szenarien wird durch die COSMOD-RE Methode die Verwendung entweder von UML-Sequenzdiagrammen oder von MSCs empfohlen. In diesem Abschnitt wird die Erweiterung der COSMOD-RE Methode auf der Basis der MSCs erfolgen. Dies kann dadurch argumentiert werden, dass diese Modellierungssprache einfach in der Anwendung ist, gute Möglichkeiten zur Strukturierung der einzelnen Modelle anbietet und als Spezifikationssprache für eingebettete Systeme bekannt ist. Im Folgenden werden zuerst die Besonderheiten der MSCs vorgestellt und danach potentielle Probleme mit der Modellierung der Zeitaspekte in eingebetteten Systemen hervorgehoben. Anschließend wird die vorgeschlagene Erweiterung der COSMODRE Methode beschrieben.

3.1 Basic Message Sequence Charts Die MSC Diagramme können in bMSC (Basic Message Sequence Charts) und hMSCs (High-level Message Sequence Charts) untergliedert werden. bMSCs spezifizieren die Nachrichtenkommunikation zwischen verschiedenen Instanzen – Akteure, Systemkomponenten, etc. – und deren Zustandswechsel nach Erhalt der Nachrichten. Wenn nur der Begriff MSC verwendet wird, wird darunter eine bMSC verstanden. hMSCs dienen zur Organisation der bMSCs und geben an, wie die einzelnen bMSCs voneinander abhängen. Ein Beispiel eines bMSC kann man Abbildung 3-1 (siehe [Itut04]) entnehmen:

Zuletzt geändert: 19.01.2012 14:40

9/25

Abbildung 3-1 – Basic Message Sequence Chart

Jeder am Szenario teilnehmender Akteur wird innerhalb des bMSC durch eine Instanz und das korrespondierende grafische Notationselement repräsentiert (s. Abbildung 3-1). Die Instanzen werden durch Rechtecke repräsentiert () mit dem entsprechenden Namen (). Senkrecht unter jeder Instanz wird eine Zeitachse in Form einer Linie angegeben. An dieser kann der Verlauf der Nachrichtenkommunikation im Laufe der Zeit für jede Instanz verfolgt werden (). Die Kommunikation zwischen den Akteuren wird durch Nachrichten und dem korrespondierenden grafischen Notationslelement definiert (s. Abbildung 3-1). Die Nachrichten werden als Pfeile dargestellt (), an denen der Name der Nachricht angegeben wird (). Das Senden einer Nachricht ist der Anfang eines Pfeils, der an der Zeitachse der sendenden Instanz angegeben ist (). An der Zeitachse der empfangende Instanz wird das Ende des Nachrichtenpfeils angegeben (). In bMSCs sind das Senden und der Empfang einer Nachricht asynchrone Events. Dabei wird angenommen, dass die Umwelt des MSCs Nachrichten vom MSC empfangen und Nachrichten zum MSC senden kann (s. [Itut04]). Neben den vorgestellten Basiselementen des MSC gibt es noch einige weitere Notationselemente, die für diese Arbeit von Bedeutung sind. Dazu gehören vor allem die strukturellen Konzepte der MSC-Sprache repräsentiert durch Inline Expressions und References. Mit Inline Expressions kann die Komposition der Ereignisstrukturen innerhalb eines MSC definiert werden. Die Operatoren beziehen sich dabei auf die alternative, parallele und sequentielle Komposition, Iteration, Ausnahmen und optionale Regionen. Unter Berücksichtigung der zuvor gewählten Reihenfolge werden folgende Schlüsselwörter für die grafische Repräsentation der Operatoren benutzt: alt, par, seq, loop, exc und opt. Eine MSC reference wird benutzt, um andere MSCs des MSC-Dokuments zu referenzieren. Durch das wird eine MSC-Referenz grafisch notiert. MSC-Referenzen sind Objekte von dem Typ, der durch das referenzierte MSC vorgegeben ist. Eine MSC-Referenz kann ein einzelnes MSC oder eine MSC reference expression referenzieren. [Itut04]

Zuletzt geändert: 19.01.2012 14:40

10/25

3.2 High-Level Message Sequence Charts High-Level MSCs (hMSCs) stellen Hilfsmittel zur Verfügung, um grafisch definieren zu können wie eine Menge von bMSCs kombiniert werden können. Ein hMSC ist ein gerichteter Graph in dem jeder Knoten entweder: ein Startsymbol (in jedem hMSC gibt es nur ein Start symbol), ein Endsymbol, eine MSC-Reference, eine Condition, ein Connection Point, oder ein hMSC inline expression frame ist. Die Knoten in einem hMSC stellen Referenzen zu bereits spezifizierten bMSCs. Die Knoten im hMSC werden durch Pfeile verbunden, die deren möglichen Sequenzen anzeigen. Eingehende Pfeile werden immer mit der oberen Ecke des Knotensymbols verbunden, wohingegen ausgehende Pfeile stets mit der unteren Ecke des Knotensymbols verbunden werden. Gibt es mehr als einen ausgehenden Pfeil von einem Knoten, dann handelt es sich um eine Alternative.

Abbildung 3-2 – High-level Message Sequence Chart

In Abbildung 3-2 (siehe [Itut04]) ist ein Beispiel eines hMSC gegeben. Die Ausführung des hMSC beginnt beim Startsymbol (). Nach der Condition „when disconnected“, kann entweder das refenrezierte bMSC „failure“ oder „connection“ ausgeführt werden, abhängig davon, wie die Condition ausgewertet worden ist (). Das hMSC endet beim Endsymbol (), wenn die Condition „connected“ () erfüllt worden ist.

3.3 Zeitbehaftete MSCs Wie bereits angemerkt, führt die neueste MSC-Spezifizierung (s. [MSC‘2000Standard]) Zeitkonzepte zur Notation quantifizierter Zeit in MSCs ein. Dies ermöglicht Zuletzt geändert: 19.01.2012 14:40

11/25

die Anordnung von Ereignissen (d.h. Senden oder Empfangen von Nachrichten) zu quantifizieren und führt zu einer ausdrucksstärkeren Beschreibung von Echtzeitsystemen. Im MSC‘2000-Standard existieren folgende Zeitkonzepte (siehe [Itut04, ZhKH02]): Pro Message Sequence Chart wird eine globale Uhr angenommen. Entlang jeder Instanz-Achse verläuft die Zeit von oben nach unten. Sofern nicht anders gekennzeichnet, unterliegen alle Ereignisse einer absoluten, zeitlichen Reihenfolge entlang jeder Instanz-Achse. Ereignisse von unterschiedlichen Instanzen werden durch Nachrichten geordnet (s. [Kerb07]). Der Zeitverlauf ist für alle Instanzen eines MSC gleich. Es ist zu beachten, dass die Zeitbedingungen nur die Anordnung von Ereignissen quantifizieren und die Zeit beschränken, in der bestimmte Ereignisse eintreten können. MSC-Ereignisse selbst, können nicht durch Zeitbedingungen spezifiziert werden, da diese ohne Verzögerung eintreten und keine Zeit verbrauchen. Der Zeitbereich kann dicht oder diskret sein. Der Zeitbereich muss eine Gesamtordnung sein und mit einem kleinsten Element oder mit der Zeit 0 beginnen. Die MSC-Spezifikation beschreibt eine relative und eine absolute Zeitberechnung. Die relative Zeitberechnung benutzt Ereignispaare – vorhergehendes und nachfolgendes Ereignis – und dient zur Spezifikation der Verzögerung zwischen zwei Ereignissen (relative Verzögerung). Die absolute Zeitberechnung wird benutzt, um das Eintreten von Ereignissen in Relation zum Wert der globalen Uhr zu definieren (absolute Verzögerung). Ein weiteres wichtiges Konzept sind die Zeitintervalle. Sie können verwendet werden, um eine relative oder absolute Verzögerung mithilfe einer minimalen oder maximalen Schranke zu spezifizieren. Sie definieren die Zeitbedingungen für das Eintreten von Ereignissen. Zur Spezifikation einer relativen Verzögerung kann ein Zeitintervall mit minimaler und maximaler Schranke oder ein konkreter Zeitwert benutzt werden. Zum Beispiel wird eine relative Verzögerung von 4 bis 5 Sekunden durch [4s, 5s] repräsentiert. Beträgt die relative Verzögerung exakt 3 Sekunden, so wird dies durch [3s] spezifiziert. Ähnliches gilt für die Spezifikation der absoluten Verzögerung, die nur eine leicht abweichende Notation verwendet. Tritt ein Ereignis beispielsweise zwischen der vierten und fünften Sekunde (in Relation zur globalen Uhr) ein, so wird dies wie folgt notiert: @[4s, 5s]. Wenn das Ereignis hingegen exakt zur dritten Sekunde eintritt, ist [@3s] zu notieren. Abbildung 3-3 (angelehnt an [ZhKH02]) zeigt die grafische MSC-Notation der erwähnten Beispiele für Zeitbedingungen. MSCs mit Zeitbedingungen, die zu einer Quantifizierung der Ereignisanordnung führen werden als Zeitbehaftete bzw. Timed MSCs bezeichnet (s. [ZhKH02, AlHP96]). Die in der Abbildung dargestellten Ereignisse sind mit a, b, c, d, e und f benannt. Das MSC spezifiziert den Nachrichtenaustausch zwischen den Instanzen i und j, wobei die Anordnung der gekennzeichneten Ereignisse durch die Verwendung relativer und absoluter Verzögerungen quantifiziert ist. Relative Verzögerungen sind zwischen den Ereignissen a und d, b und c und e und f spezifiziert. Der jeweilige Eintritt der Ereignisse a, c und d ist durch absolute Verzögerungen spezifiziert.

Zuletzt geändert: 19.01.2012 14:40

12/25

Abbildung 3-3 – Zeitbehaftetes Message Sequence Chart

Die Semantik von Zeitbehafteten MSCs wird in der MSC-Spezifikation durch sogenannte Traces mit speziellen Zeitereignissen zwischen den anderen Ereignissen repräsentiert. Beispielsweise ist der Trace für das MSC, repräsentiert in Abbildung 3-3, {a, t1, b, t2, c, t3, d, e, t5, f}. Befindet sich zwischen zwei normalen Ereignissen kein Zeitereignis, wie dies zwischen den Ereignisse d und e der Fall ist, so treten diese simultan ohne Zeitverzögerung ein. Diese Semantik wird in der MSC-Spezifikation allerdings informal und unvollständig beschrieben. Um die Semantik von Zeitbehafteten MSCs vollständig und formal definieren zu können, bedarf es eines adäquaten semantischen Modells, mit dem alle möglichen Traces eines (zeitbehafteten) MSCs abgebildet werden können. Ein solches semantisches Modell wird im folgenden Abschnitt vorgestellt.

3.4 Semantisches Modell für zeitbehaftetete MSCs zur Spezifikation von Echtzeitanforderungen in der COSMOD-RE Methode Semantische Modelle werden benötigt, um die Benutzung von MSCs zu unterstützen. Sie bedienen sich einer formalen Semantik, welche die zugrundeliegende Sprache präzise definiert. Dies verhindert vor allem Mehrdeutigkeiten in der Interpretation. Angestoßen durch die neuste Version des MSC-Standards, MSC‘2000 (s. []), wurden weitere formale Semantiken bzw. semantische Modelle entwickelt, um die neu eingeführten Konzepte der MSC-Spezifikation abzudecken. Eines der neu eingeführten Konzepte sind die Zeitbedingungen, die eine adäquate Spezifikation von u. a. Echtzeitsystemen erlauben. In [ZhKH02] wird ein semantisches Modell zur Definition von MSCs mit Zeitbedingungen, den sogenannten Zeitbehafteten MSCs, vorgestellt. Dieses Modell basiert auf dem Partialordnungsmodell von [Heym98], den lposets (labelled partially ordered set), und erweitert dieses um einen Zeitbereich. Es ermöglicht

Zuletzt geändert: 19.01.2012 14:40

13/25

die Definition der Semantik von Zeitbehafteten MSCs. Als konkretes semantisches Modell wurden die Zeitbehafteten bzw. Timed lposets definiert. In dieser Arbeit wird der in [ZhKH02] formulierten Meinung gefolgt, dass ein MSC die partielle Anordnung zwischen Ereignissen definiert und diese Anordnung durch Zeitbedingungen quantifiziert. Aus diesem Grund werden die Zeitbehafteten lposets in dieser Arbeit als semantisches Modell für die Definition der formalen Semantik der Zeitbehafteten MSCs herangezogen. In den nächsten Abschnitten wird das semantische Modell aus [ZhKH02] näher erläutert.

3.4.1 Partialordnungsmodell für (Zeitbehaftete) MSCs Um die Anforderungen eines Zeitbehafteten MSC zu erfüllen, werden die lposets um zwei Verzögerungsfunktionen angereichert. Des Weiteren wird Time zur Repräsentation des Zeitbereichs verwendet, welcher aus einer Menge von nicht-negativen, reellen oder ganzen Zahlen bestehen kann. Dabei ist P(Time) die Potenzmenge von Time. Mit diesen Erweiterungen kann nun das Zeitbehaftete lposet definiert werden. Ein Zeitbehaftetes lposet ist ein Tupel (A, E, ≤, l, D, T), in dem A die Menge der Label ist. E die Menge der Ereignisse ist. ≤: eine Partialordnung über E ist. l: eine Labeling-Funktion ist, welche ein Ereignis zu einem Label assoziiert. Es kann eine partielle Funktion sein. D: eine absolute Verzögerungsfunktion ist, welche ein Ereignis zu einer Menge von Zeitwerten assoziiert. Sie definiert einen Bereich, in dem ein Ereignis eintreten kann. T: eine relative Verzögerungsfunktion ist, welche ein Ereignispaar zu einer Menge von Zeitwerten assoziiert. Sie definiert mögliche Verzögerungen zwischen zwei Ereignissen. Die Menge der Labels A definiert die „Bedeutung“ eines Ereignisses. Für das zugrundeliegende Modell kann ein Ereignis ein Nachrichteneingang, Nachrichtenausgang, eine interne Aktion, Timerstart, Timerstop oder Timeout sein. Somit können die Labels wie folgt definiert werden: send(i, j, m): Instanz i sendet eine Nachricht m an Instanz j, receive(i, j, m): Instanz i empfängt eine Nachricht m von Instanz j, action(i, a): Instanz i führt eine interne Aktion a aus, starttimer(i, T, n): Instanz i setzt einen Timer T mit der Timeout-Periode n, stoptimer(i, T): Instanz i bricht den Timer T ab, timeout(i, T): Der Timer T in der Instanz i läuft ab. Jedes Ereignis wird mit einem eindeutigen Label versehen. So wird zwischen jeder Nachricht (unabhängig vom Inhalt) und jedem Timer (unabhängig vom Wert) eindeutig differenziert. Ein Trace eines Zeitbehafteten lposet wird definiert als eine Sequenz von Zeitbehafteten Events (e1, t1), (e2, t2), …, (en, tn) mit , so dass für alle i und j, : wenn wenn

Informal, repräsentieren i und j die Positionen der Ereignisse in einem Trace. Die erste Bedingung drückt die Erfüllung der Partialordnung zwischen zwei Ereignissen in Zuletzt geändert: 19.01.2012 14:40

14/25

einem Trace aus. Die zweite Bedingung garantiert Zeitkonsistenz. Die beiden anderen Bedingungen bedeuten, dass Ereignisse ihre Zeitbedingungen erfüllen müssen. Die Menge der Traces eines Zeitbehafteten lposet lp ist definiert als Tr(lp) = {w | w ist ein Trace von lp}. Ein Ereignis e ist ein minimales Element in E entsprechend ≤, wenn es kein Ereignis gibt, so dass . Ein Ereignis e ist ein maximales Element in E entsprechend ≤, wenn es kein Ereignis gibt, so dass . Aufgrund der Partialordnung kann es verschiedene minimale und maximale Elemente in E geben. Wird verwendet um die leere Menge zu repräsentieren, so kann ein lposet ε = (A, E, ≤, l, D, T) als ein Identitäts-lposet in dem A, E, ≤, l, D und T = sind, definiert werden. Um ein MSC mit einem Deadlock zu repräsentieren, wird ein lposet (A, E, ≤, l, D, T) als δ notiert, wenn Dies bedeutet, dass δ keinen Trace hat. Für alle Ereignisse in einem MSC für die keine absolute oder relative Verzögerung explizit spezifiziert wurde, gilt eine Verzögerung von [0, ∞). Ein Zeitbehaftetes lposet kann benutzt werden um ein Ereignis in einem MSC, einen Teil des MSC oder das gesamte MSC zu repräsentieren. Um dies tun zu können, gibt es verschiedene definierte Operationen, die auf lposets durchgeführt werden können: die sequentielle, alternative und parallele Komposition. Seien zwei lposets p und q gegeben, deren Ereignisse auf verschiedenen Instanzen oder der gleichen Instanz angesiedelt sein mögen. Formal beschrieben, seien p = (Ap, Ep, ≤p, lp, Dp, Tp) und q = (Aq, Eq, ≤q, lq, Dq, Tq) zwei Zeitbehaftete lposets in denen Ap und Aq disjunkt und ≤p , ≤q sind. Für eine Relation S, wird S+ zur Repräsentation der transitiven Hülle von S benutzt. Die sequentielle Komposition ( ) von p und q ist dann ein lposet, das definiert ist als: +

,

in dem 1) 2)

sind die Mengen der Ereignisse, die bei Instanz i auftreten,

3)

Informal, bedeutet dies für: 1) Wenn ein Ereignis das Senden einer Nachricht referenziert und ein anderes Ereignis das Empfangen dieser Nachricht referenziert, dann ist eine neue Anordnung zwischen diesen Ereignissen einzufügen. 2) Wenn zwei Ereignisse auf der gleichen Instanz angesiedelt sind, dann ist eine neue Anordnung zwischen diesen Ereignissen einzufügen. 3) Wenn ein Ereignis das Starten eines Timer mit einer Timeout-Periode beschreibt und ein anderes Ereignis das Beenden oder Ablaufen des Timer repräsentiert, dann ist eine Zeitbedingung zwischen diesen Ereignissen einzufügen. + Des Weiteren definiert die Semantik, wenn keine Partialordnung ist, dass die sequentielle Komposition von zwei lposets als δ in der definiert ist. Und dass die sequentielle Komposition von δ und einem beliebigen lposet stets δ ist. Für das Identitäts-lposet ε wird definiert, dass seine sequentielle Komposition mit ei-

Zuletzt geändert: 19.01.2012 14:40

15/25

nem beliebigen lposet p stets p ist. Für zwei Mengen von lposets und , wird die sequentielle Komposition definiert als:

Die alternative Komposition ( ) von zwei lposets p und q ist definiert als eine Menge von lposets:

Für zwei Mengen von lposets native Komposition definiert als:

und

, ist die alter-

Die parallele Komposition ( ) von zwei lposets p und q ist definiert als: , In der parallelen Komposition wird gefordert, dass und disjunkt sind, was dazu führt dass auch und disjunkt sind. Wird eine Nachricht m zwischen den gleichen Instanzen in p und q ausgetauscht, so muss diese in m1 und m2 umbenannt werden. Die Instanzen in p und q können die gleichen sein. Für zwei Mengen von lposets und , wird die parallele Komposition definiert als:

3.4.2 Semantik der Partialordnung für Zeitbehaftete MSCs Die Semantik für Zeitbehaftete MSCs aus [ZhKH02] fordert eine Differenzierung zwischen bMSCs, MSCs mit Strukturen (z.B. Inline Expressions) und HMSCs. Die Differenzierung ist hierbei wie folgt zu verstehen: Ein bMSC beinhaltet ein oder mehrere Ereignisse und ein HMSC beinhaltet ein oder mehrere bMSCs, während dessen ein MSC mit Strukturen sowohl Ereignisse als auch bMSCs enthalten kann. Somit komponiert ein bMSC, Ereignisse, ein HMSC, bMSCs, und ein MSC mit Strukturen sowohl Ereignisse als auch bMSCs. Diese Struktur führt zu der Annahme, dass Ereignisse anstatt bMSCs die kleinsten zu betrachtenden Einheiten sind. Ein lposet repräsentiert somit ein Ereignis, als kleinste Einheit, einen Teil eines MSC oder ein komplettes MSC.

3.4.3 Besonderheiten der Basic MSC (bMSC) Es wird an dieser Stelle angenommen, dass bMSCs nur Ereignisse beinhalten. Da diese Ereignisse die Basiseinheiten darstellen, kann ein bMSC mit Hilfe von Ereignissen, durch Verwendung der sequentiellen Komposition definiert, über lposets komponiert werden. Dabei ist es wichtig, dass die einzelnen Ereignisse eindeutig benannt werden. Die Semantik des bMSC wird über ein lposet definiert, das alle Ereignisse beinhaltet und deren Reihenfolge spezifiziert. Entlang jeder Instanz-Achse sind Ereignisse von oben nach unten zu ordnen. Zwischen verschiedenen Instanzen, muss ein Nachrichtenausgangsereignis vor dem korrespondierenden Nachrichteneingangsereignis auftreten.

Zuletzt geändert: 19.01.2012 14:40

16/25

3.4.4 Besonderheiten von MSC mit Strukturen Ein MSC mit Strukturen kann mit einem lposet oder mit einer Menge von lposets repräsentiert werden. Dann ist die Semantik eines MSC mit Strukturen die sequentielle Komposition dieser Strukturen und den anderen Ereignissen im MSC. Eine MSC-Reference wird benutzt um ein einzelnes MSC oder MSC-Expression zu referenzieren. Eine MSC-Reference kann durch Zeitintervalle bedingt werden. Ein Zeitintervall spezifiziert die Zeitdauer zwischen dem ersten und letzten Ereignisses einer MSC-Reference. Dabei ist zu beachten, dass eine Referenz mehrere erste und letzte Ereignisse beinhaltet kann, so dass die Zeitdauer jedes dieser Ereignispaare durch das definierte Zeitintervall spezifiziert wird. Im MSC-Standard werden verschiedene Operatoren spezifiziert um MSCs zu definieren. Im semantischen Modell nach [ZhKH02] werden folgende Operatoren definiert, die für die Spezifikation von Echtzeiteigenschaften relevant sind: sequence (seq), alternation (alt), parallel (par) und iteration (loop). Diese Operationen können auf die Operationen der lposets abgebildet werden. Dies führt für zwei MSCs oder InlineOperanden A und B zu folgenden Abbildungen:

Für den noch ausstehenden Operator loop, ist die Abbildung der Semantik aufgrund der absoluten Verzögerungen etwas komplizierter. Wird M benutzt, um ein bMSC zu repräsentieren, dann könnte ein beliebiges Ereignis in M, welches durch eine absolute Zeitbedingung näher spezifiziert ist, Auswirkungen auf die Anzahl der Ausführungen von M haben. Eine absolute Verzögerung könnte im Konflikt mit der Iterationsgrenze stehen. Aus diesem Grund darf ein MSC in einer Iteration nur einmal ausgeführt werden, sobald ein Ereignis durch einen absoluten Zeitpunkt bedingt ist. Wenn alle Ereignisse in einem MSC durch keine absolute Verzögerung eingeschränkt sind, dann ist die Anzahl der Ausführungen des MSC in einer Iteration nur durch die Iterationsgrenze beschränkt. Somit kann ohne die Wahl des Zeitbereichs einschränken zu wollen die Semantik des loop-Operators durch folgende Mengen von lposets definiert werden:

Hier repräsentiert m die aktuelle Anzahl der Ausführungen von A. Die Bestimmung von m erfolgt durch die absoluten Zeitbedingungen der Ereignisse in A. Wenn die absolute Verzögerung eines Ereignisses ein Zeitpunkt ist, dann gilt stets m = 1. Im Zeitbereich der ganzen Zahlen kann m kleiner als j oder sogar als i sein. Für k > 0 wird definiert:

Wird M[Ak] berechnet, so ist es notwendig alle Nachrichten- und Timer-Ereignisse so umzubenennen, dass jedes dieser Ereignisse eindeutig für die Iteration ist. Wenn ein loop unendlich ist, kann die Menge eine unendliche Anzahl an lposets beinhalten.

Zuletzt geändert: 19.01.2012 14:40

17/25

3.4.5 Besonderheiten der High-Level MSC (hMSC) Ein HMSC ist ein gerichteter Graph, in dem MSCs als Knoten repräsentiert sind und Geraden die Knoten verbinden, um die möglichen Ausführungssequenzen entlang der Knoten zu definieren. Die seq-, alt- und par-Operatoren können in HMSCs verwendet werden. Die Iteration kann in einem hMSC durch Verwendung des loopOperators umschrieben werden. Somit ist es möglich ein hMSC zu einem MSCAusdruck zu transformieren. Die Conditions in hMSCs werden außer Acht gelassen. Der Vorgang der Transformation eines HMSC in einen MSC-Ausdruck wird in [ZhKH02] näher beschrieben. Für ein HMSC H, das die Menge von lposets besitzt, wird die Menge der Traces von H wie folgt definiert: für jedes Im nächsten Abschnitt wird das semantische Modell für zeitbehaftete MSCs am Beispiel einer Anwendung für eingebettete Systeme angewendet.

Zuletzt geändert: 19.01.2012 14:40

18/25

4 Beispiel In diesem Abschnitt wird die Umsetzung des Vorgehens zur Spezifikation von Echtzeiteigenschaften in eingebetteten Systemen illustriert. Dazu wird ein Beispiel genommen.

4.1 Anwendungskontext Das Anwendungsbeispiel stammt aus der Domäne der Logistik. Konkret geht es um einen automatisierten Containerhafen. Dieses Anwendungsbeispiel ist angelehnt an SOAHarbor (s. [SOAH10]), eine Plattform, die eine Service-orientierte Architektur (SOA) für eingebettete Systeme realisiert. In diesem Projekt wurde eine SOA für einen Miniaturhafen zur Steuerung der Entladung und Beladung von Containern entwickelt. Dazu wurden Lego Mindstorms (Roboter, die mit Hilfe einer Java-Engine programmiert werden können) eingesetzt, die ein sensorbasiertes Dock, eine Ladebrücke, ein Containerfließband, einen Containeraufzug und einen Gabelstapler als eingebettetes System repräsentieren. Des Weiteren beinhaltet das Containerhafensystem ein Informationssystem, das systemrelevante Daten zu Verfügung stellt. Das sensorbasierte Dock erkennt über einen RFID-Sensor, dass ein neues Containerschiff in den Hafen eingelaufen ist und startet einen Prozess zum Entladen und Beladen des Schiffs. Die Ladebrücke ist für die Entladung des eingelaufenen Containerschiffs zuständig und steuert alle dazu notwendigen Interaktionen mit den anderen Robotern des Containerhafens. Die Beladung des Containerschiffs und die dafür notwendigen Interaktionen werden vom Gabelstapler gesteuert.

4.2 Spezifikation der Echtzeiteigenschaften Dieser Abschnitt behandelt die Spezifikation des Anwendungsbeispiels durch ein zeitbehaftetes MSC nach dem im Abschnitt 3 vorgestellten semantischen Modell. Im Folgenden werden die Anforderungen an das System beschrieben.

4.2.1 Anforderungen an das SOAHarbor-System Folgende natürlich-sprachliche Anforderungsbeschreibung an das SOAHarborSystem liegt vor: A1) Sobald ein neues Containerschiff in den Hafen eingelaufen ist, wird der Entladungsprozess initialisiert. A2) Basierend auf der ID des Containerschiffs, wird der zu entladene Container anhand der korrespondierenden Container-ID identifiziert. A3) Bevor mit der Entladung des Containers begonnen werden kann, ist die Ladebrücke zu kalibrieren und in die Ausgangslage zu bringen, um die Voraussetzungen für eine fehlerfreie Entladung zu schaffen. A4) Sind die in A3) beschriebenen Voraussetzungen geschaffen, ist mit der Entladung des Containers zu beginnen. Dabei sind folgende Echtzeitanforderungen zu erfüllen: EA1) Die Entladung eines Containers soll im ungünstigsten Fall bei günstigen Randbedingungen (keine technischen Defekte oder unerwarteten Störungen) innerhalb von 420 Sekunden erfolgen. Diese Zeitbedingung ist Voraussetzung für die Einhaltung der maximalen Gesamtentladungszeit des Containerschiffs.

Zuletzt geändert: 19.01.2012 14:40

19/25

EA2)

Die Ladebrücke darf frühestens zur 32.Sekunde zur Entladung des Containers aufgerufen werden. Eine Überschreitung dieser Deadline könnte dazu führen, dass die Kalibrierung der Ladebrücke noch nicht abgeschlossen ist oder diese sich noch nicht am definierten Ausgangspunkt befindet und somit die Anforderung A3) nicht erfüllt werden kann. Die Echtzeiteigenschaften an das zu spezifizierende System sind nicht Teil der Anforderungsbeschreibung, da diese durch äußere Umstände wie z. B. die Performance der Hardware-Plattform und der zugrundeliegenden technischen Infrastruktur vorgegeben sind. Die konkreten Zeitwerte der Echtzeiteigenschaften des Systems bzw. der eingebetteten Aktivitäten können über durchgeführte Messungen oder Befragung von Domänenexperten gewonnen werden. Die Modellierung und Spezifikation dieser Echtzeiteigenschaften des zugrundeliegenden Anwendungsbeispiels werden im nächsten Unterkapitel vorgestellt.

4.2.2 Formale Spezifikation des Anwendungbeispiels Die Spezifikation des Anwendungsbeispiels wird in Abbildung 4-1 und Abbildung 4-2 repräsentiert. Fehler! Verweisquelle konnte nicht gefunden werden. Abbildung 4-1 zeigt die bMSC-Spezifikationen der eingebetteten Basisaktivitäten, die von der hMSC-Spezifikation unload_container referenziert werden. Die hMSC-Spezifikation definiert die Ausführungsstruktur der referenzierten Basisaktivitäten, die im Folgenden beschriebenen werden. Die bMSC-Spezifikation receive_RS definiert die Instanziierung eines zentralen Systemsteuerungsprozesses (Process) zur 0.Sekunde, durch das sensorbasierte Dock (RS), das die Schiffs-RFID an den Prozess übermittelt. Der danach folgende assign Operator kopiert den Inhalt der Variablen RFID in die Variable shipRFID, was im bMSC assign_1 modelliert wird. Das bMSC invoke_IS spezifiziert die Identifizierung des zu entladenden Containers anhand der bekannten shipRFID durch Aufruf des Informationssystems (IS) und Empfang der Variablen RFID. Nachdem es bekannt ist, welcher Container entladen werden muss, ruft der zentrale Systemsteuerungsprozess die Ladebrücke (LB) auf, um die Kalibrierung der Ladebrücke zu initialisieren. Diese antwortet dem Prozess, sobald mit der Kalibrierung begonnen wurde. Diese Interaktion wird durch das bMSC invoke_LB_1 spezifiziert.

Zuletzt geändert: 19.01.2012 14:40

20/25

Abbildung 4-1 - bMSC-Spezifikationen des Anwendungsbeispiels

Das Kopieren des Inhalts der Variablen RFID in die Variable containerRFID und das Blockieren des Prozesses für 20 Sekunden wird mit Hilfe einer parallele Komposition der bMSCs wait_1 und assign_2 im hMSC unload_container spezifiziert (s. Abbildung 4-2). Diese parallele Komposition bewirkt zum einen eine Verringerung der Gesamtausführungszeit des zentralen Systemsteuerungsprozesses (gegenüber einer sequentiellen Komposition der beiden entsprechenden bMSCs) und zum anderen die geforderte Wartezeit für die Kalibrierung der Ladebrücke. Danach wird die Entladung des Containers durch Aufruf der Ladebrücke angestoßen. Die Ladebrücke sendet dem zentralen Systemsteuerungsprozess eine Antwort, sobald die Entladung des Containers abgeschlossen wurde. Der Empfang dieser Antwortnachricht repräsentiert das Endereignis des gesamten Prozesses. Die zuletzt beschriebene Interaktion wird im bMSC invoke_LB_2 spezifiziert.

Zuletzt geändert: 19.01.2012 14:40

21/25

Abbildung 4-2 – hMSC-Spezifikation des Anwendungsbeispiels

Tabelle 4-1 – Beziehung zwischen Spezifikation und AnforderungenTabelle 4-1 skizziert die Beziehungen zwischen den Anforderungen und der Spezifikation SOAHarbor Systems. Die Tabelle stellt die Anforderungen den assoziierten MSCSpezifikationen gegenüber. Tabelle 4-1 – Beziehung zwischen Spezifikation und Anforderungen

Anforderung A1)

Spezifikation MSC reveive_RS

A2)

MSCs invoke_IS, assign_1

A3)

MSCs invoke_LB_1, wait_1

A4)

MSCs invoke_LB_2, assign_2

Ob auch die Echtzeitanforderungen an das SOAHarbor System erfüllt werden, kann erst durch die Validierung der Echtzeiteigenschaften des Prozesses überprüft werden. Die Echtzeitanforderung EA1) wird durch die relative Zeitbedingung [tmin_bq, 420s] in Abbildung 4-2 repräsentiert. Die absolute Zeitbedingung @[32s, Tmax_n] im Zuletzt geändert: 19.01.2012 14:40

22/25

HMSC unload_container spezifiziert die Echtzeitanforderung EA2). Die vorgegebenen Echtzeiteigenschaften des SOAHarbor Systems sind in den BMSCSpezifikationen in Abbildung 4-1 spezifiziert.

Zuletzt geändert: 19.01.2012 14:40

23/25

5 Zusammenfassung In diesem Dokument wurde eine Erweiterung der COSMOD-RE Methode vorgestellt, die das Ziel hat, Instrumente für die Modellierung von Echtzeitanforderungen in eingebetteten Systemen anzubieten. Diese Erweiterung kann dazu helfen, dass früh erkannte Zeitaspekte zusammen mit den anderen Anforderungen an das eingebettete System validiert werden. Da Zeitaspekte in den Anforderungen nur die dynamischen Modelle einer Spezifikation betreffen, wirkt sich die Erweiterung der COSMOD-RE Methode nur auf die Szenariomodelle aus. Dabei ist die Erweiterung an einem semantischen Modell zur formalen Spezifikation von zeitbehafteten Message Sequence Charts angelehnt. Die erläuterten Konzepte in diesem Dokument wurden im letzten Abschnitt 4 an einem Beispiel evaluiert.

Zuletzt geändert: 19.01.2012 14:40

24/25

6 Literaturverzeichnis Seli96Seli96AlHP9 6

ELLS97

Heym98

Itut04

Kerb07

Kope97

OMG05

Pohl10 Seli96

SOAH10 Wolf94

ZhKH02 KGSB98

Alur, Rajeev; Holzmann, Gerard J.; Peled, Doron. An Analyzer for Message Sequence Charts. Lecture Notes in Computer Science, Volume 1055/1996, 35-48, Springer Berlin/Heidelberg. 1996. Edwards, Stephen; Lavagno, Luciano; Lee, Edward A.; Sangiovanni–Vincentelli, Alberto. Design of Embedded Systems: Formal Models, Validation, and Synthesis. Proceedings of the IEEE, Band 85, Heft 3, S. 366-390. März 1997. Heymer, Stefan. A Non-Interleaving Semantics for MSC. Proceedings 2. Workshop of the SDL Forum Society on SDL and MSC - SAM’98. Berlin, Deutschland. Juni 1998. ITU-T Z.120. Series Z: Languages and General Software Aspects for Telecommunication Systems, Formal description techniques (FDT) – Message Sequence Chart (MSC). . April 2004 Kerber, Kai Lennard. Performance Message Sequence Chart – Sprache zur Leistungsvorhersage mittels der Generierung eines Prototypen im Kontext des Protokollentwurfs mit SDL und MSC, Dissertation Universität Erlangen-Nürnberg, 2007. Kopetz, Hermann. Real-Time Systems: Design Principles for Distributed Embedded Applications. Kluwer International Series in Engineering & Computer Science. 1997. Object management Group (OMG). UML Profile for Schedulability, Performance, and Time Specification. Version 1.1, formal/05-01-02. Januar 2005. Pohl, Klaus. Requirements Engineering – Foundations, Principles, Techniques. Springer, 2010. Selic, Bran. Tutorial: Real-Time Object-Oriented Modeling (ROOM). http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=0050953 8. 1996 Projekt-Blog: SOAHarbor - SOA for embedded systems, < http://soaharbor.blogspot.com/> 2010. Wolf, Wayne H. Hardware-Software Co-Design of Embedded systems. Proceedings IEEE, Band 82, Heft 7, S. 967-989. Juli 1994 Zheng, Thong; Khendek, Ferhat; Helouet, Loic. A Semantics forTimed MSC, Elsevier Science B. V., 2002. Krüger, Ingolf; Grosu, Radu; Scholz, Peter; Broy Manfred. From MSCs to Statecharts. Proceedings DIPES’98, IFIP WG10.3/WG10.5 International Workshop on distributed and parallel Systems. 1998.

Zuletzt geändert: 19.01.2012 14:40

25/25