RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen

Größe: px

Ab Seite anzeigen:

Download "RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen"

Helge Neumann
vor 8 Jahren
Abrufe

1 RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen Thorsten Keuler (thorsten.keuler@iese.fraunhofer.de) IESE Fraunhofer Institut Experimentelles Software Engineering

Thorsten Keuler (thorsten.keuler@iese.fraunhofer.

2 RTLOpen Projekt Agenda Ziele & Herausforderungen ProMiS Ansatz KobrA Ansatz Demonstrator Beispiel Zusammenfassung Ausblick Seite 2

3 RTLOpen Projekt Ziele 1. Erstellung, Bewertung und Dokumentation einer industriellen Software Plattform zur Erstellung echtzeitfähiger Systeme. 2. Die Nutzung und Integration bestehender freier Software Werkzeuge sowie Linux Erweiterungen. 3. Entwicklung und Validierung einer leichtgewichtigen Methode zur systemtischen Entwicklung von Lösungen Seite 3

4 RTLOpen Projekt Herausforderungen bzgl. Methode (Ziel 3) Parallele Entwicklung von HW (Mechanik, Elektronik) & SW Task-Synchronisation Echtzeitanforderungen: Partitionierung (HW/SW) Verfolgbarkeit Softwarearchitektur Entwurf, Pflege und Wiederverwendung (Evolution) Qualitätssicherung z.b. Built-in tests Seite 4

Task-Synchronisation Echtzeitanforderungen: Partitionierung (HW/SW)

5 RTLOpen Projekt ProMiS (Projektmanagement für interdisziplinäre Systeme) Motivation Konzept zur Koordinierung von Aktivitäten in interdisziplinären Projekten Besonders in der Domäne der Echtzeitsysteme gilt es Experten aus den verschiedensten Disziplinen zu koordinieren Die inkrementelle und iterative Vorgehensweise minimiert Risiken bereits in der Projektfrühphase Seite 5

Echtzeitsysteme gilt es Experten aus den verschiedensten Disziplinen zu koordinieren Die

6 ProMiS Ansatz Mechanik Initial phase Anforderungs analyse Entwickler anforderunge n Realisierung Systemintegration Qualitäts sicherung Forderung nach Lösung Produkt Elektronik Software Iterativ Inkrementell Seite 6

Systemintegration Qualitäts sicherung Forderung nach

7 ProMiS Ansatz Detailsicht auf Entwicklungsstrang Ergebnisse vereinbaren Entwicklungsqualität controllen QG-Checkliste/ Reifegradindikator Weg darlegen Fortschritt synchronisieren Seite 7

8 Das Quality Gate Konzept - Schritt 1 Ergebnisse vereinbaren Realisierung Vertrieb Kunde Management Entwicklungsteams E, SW... interne/ externe Kunden parallele Entwicklungsbereiche Interessenspartner Entwicklungsteam M S c h r i t t 1 Beteiligte ermitteln geforderte Ergebnisse zusammenstellen Abnahmebedingungen und Testverfahren für die Ergebnisse festlegen Machbarkeit und Risiko prüfen und priorisieren geforderte Ergebnisse konsolidieren Festlegung interdisziplinäre Kommunikation Seite 8

ermitteln geforderte Ergebnisse zusammenstellen Abnahmebedingungen und Testverfahren für die Ergebnisse festlegen

9 Das Quality Gate Konzept - Schritt 2 Weg darlegen Realisierung QM-Plan Ablauf Methoden Risiken Indikatoren parallele Entwicklungsbereiche S c h r i t t 2 Projektabschnitt planen Previews planen (Anzahl, Termine, Teilnehmer, Inhalte Detaillierung Aufgaben, Kompetenzen, Verantwortung interne, disziplinspezifische Meilensteine Reifegradbewertung planen Risikoliste und Notfall-Prozedere erarbeiten einzusetzende Methoden und Werkzeuge festlegen Seite 9

Teilnehmer, Inhalte Detaillierung Aufgaben, Kompetenzen, Verantwortung interne, disziplinspezifische

10 Das Quality Gate Konzept - Schritt 3 Fortschritt synchronisieren Realisierung Mechanik Elektronik Software Synchronisation parallele Entwicklungsbereiche ggf. interne Kunden Reifegrad S c h r i t t fachübergreifende Regelkommunikation Risikoliste pflegen Synchronisation in Previews In Iterationen Selbstbewertung des Projektreifegrades 3 Seite 10

interne Kunden Reifegrad S c h r i t t fachübergreifende Regelkommunikation

11 Das Quality Gate Konzept - Schritt 4 Entwicklungsqualität controllen Realisierung Anforderungen erfüllt? interner/ externer Kunde parallele Entwicklungsbereiche Interner/ externer Kunde S c h r i t t 4 Review der Entwicklungsleistung durch internen/ externen Kunden sachliche und konstruktive Diskussion mit Kunde über Erfüllungsgrad bei nicht erfüllten Forderungen Definition von Maßnahmen Reifegradbewertung durch Kunden Seite 11

interner/ externer Kunde parallele Entwicklungsbereiche Interner/ externer Kunde S c h r i t t 4 Review der

12 KobrA Ansatz KobrA (Komponenten-basierte Anwendungsentwicklung) Motivation Wiederverwendung existierender Bauteile (Komponenten) UML 2.0 basierte Notationen unterstützen (automatisierte) Verfolgbarkeit von Qualitätsattributen (z.b. Echtzeit) Gewinn Verbesserte (Produkt-)Qualität Beschleunigte Projektabwicklung Niedrigere Kosten (Entwicklung/Wartung) Seite 12

0 basierte Notationen unterstützen (automatisierte) Verfolgbarkeit von

13 Komponenten Zwei Sichten auf die Eigenschaften einer KobrA- Komponente Externe Sicht Nach außen sichtbare oder extern kontrollierbare Eigenschaften (provides & needs) Beschrieben durch die Spezifikation Interne Sicht Von innen sichtbare Eigenschaften Beschrieben durch die Realisierung Externe Sicht Komponente Spezifikation WAS? Interne Sicht Realisierung WIE? Seite 13

durch die Spezifikation Interne Sicht Von innen sichtbare Eigenschaften Beschrieben durch

14 Komponentenartefakte Specification Decision Model (textual) Functional Model Behavioral Model Realization Interaction Model Structural Model Structural Model Activity Model Decision Model (textual) Seite 14

Realization Interaction Model Structural Model

15 Komponentenartefakte (Spezifikation) Structural model Modelliert Daten die von der Komponente oder ihrer Umgebung manipuliert wird und jede weitere extern sichtbare Struktur Functional model Definiert Operationen die von der Komponente ausgeführt werden Behavioral model Definiert Zustände in der sich die Komponente befinden kann und Ereignisse die diese verändern Seite 15

model Definiert Operationen die von der Komponente ausgeführt werden Behavioral model

16 Komponentenartefakte (Realisierung) Beschreibt, wie eine Komponente die spezifizierten Dienste bereitstellt Ist im Kontext der Komponentenspezifikation definiert Die Modelle der Realisierung erweitern die Information aus der Spezifikation Seite 16

Kontext der Komponentenspezifikation definiert Die Modelle

17 Kontext Realisierung<<Labyrinth System>> Strukturmodell Beispiel (Demonstrator) Seite 17

18 Kontext Realisierung<<Labyrinth System>> Aktivitätsmodell Beispiel (Demonstrator) Seite 18

19 Kontext Realisierung<<Labyrinth System>> Interaktionsmodell Beispiel (Demonstrator) Seite 19

20 Beispiel (Demonstrator) Spezifikation Komponente <<Labyrinth System>> Strukturmodell Seite 20

21 Beispiel (Demonstrator) Spezifikation Komponente <<Labyrinth System>> Verhaltensmodell (Funktionales Modell weggelassen) Seite 21

22 Beispiel (Demonstrator) Realisierung Komponente <<Labyrinth System>> Strukturmodell Seite 22

23 Beispiel (Demonstrator) Realisierung Komponente <<Labyrinth System>> Interaktionsmodell Seite 23

24 Beispiel (Demonstrator) Containment tree Seite 24

25 RTLOpen Projekt Zusammenfassung Interdisziplinäre Projekte synchronisieren mit ProMiS Komplexität beherrschbar machen durch Softwarearchitektur Qualitätssicherung durch Wiederverwendung bereits bewährter Komponenten (Komponentenbasiertes Design) Seite 25

26 RTLOpen Projekt Ausblick Erweiterung der Ansätze zu einem Gesamtansatz der die zu Beginn geforderten Ziele erreicht Qualitätsattribute (z.b. Echtzeit, Verlässlichkeit) abschätzbar durch Softwarearchitektur Nachweis der Effektivität der Methode im Rahmen des RTLOpen Projekts bis Ende 2006 Seite 26

27 RTLOpen Projekt Fragen? Demonstration Seite 27

Ähnliche Dokumente

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen