Nachträgliche Einführung von Software-Engineering bei Wartung und Weiterentwicklung des DLR-Codes FLOWer

Größe: px

Ab Seite anzeigen:

Download "Nachträgliche Einführung von Software-Engineering bei Wartung und Weiterentwicklung des DLR-Codes FLOWer"

Max Waltz
vor 8 Jahren
Abrufe

1 DLR Nachträgliche Einführung von Software-Engineering bei Wartung und Weiterentwicklung des DLR-Codes FLOWer Jochen Raddatz DLR Braunschweig Institut für Aerodynamik und Strömungstechnik Software-Technologie im DLR Workshop 05./06. November 2001, Köln

Raddatz DLR Braunschweig Institut für Aerodynamik und

2 Inhalt Strömungslöser FLOWer Ausgangssituation Qualitätssicherung in FLOWer - Aufgaben und Ziele - FLOWer Entwicklungsprozess - Konfigurationsmanagement - Einsatz von CASE-Tools Fazit

3 DLR Strömungslöser FLOWer I Simulation der Umströmung beliebiger Körper durch Lösung der Reynolds-gemittelten Navier-Stokes Gleichungen (RANS). Nutzung einer Finite Volumen Raumdiskretisierung auf blockstrukturierten Netzen. Einsatz-Schwerpunkte: Strömungssimulation für - Flugzeug-Konfigurationen (Transport, Militär) - Hubschrauber Anwendungen außerhalb der Luftfahrt: - Lüfter - Eisenbahn cp

Nutzung einer Finite Volumen Raumdiskretisierung auf blockstrukturierten Netzen.

4 DLR Strömungslöser FLOWer II Speicherbedarf: abhängig von der Diskretisierung des Rechenraumes; üblich: 1 GB GB Hauptspeicher Rechenzeit auf NEC-SX5: > 1 cpu-h hohe Anforderungen an die "Performance" des FLOWer Codes effiziente Algorithmen, gute Vektorisierung, gute Parallelisierung Einsatz beim DLR, bei diversen Industriefirmen und an vielen Universitäten Portabilität DLR-IAS / Le Chuiton / October 2001 Eddy Viscosity / Molecular Viscosity Distribution View: 0 µt / µl 300 with = Dauphin 365N M = α = -3o β = 0o Re = ONERA Mesh / 94 Blocks / 7 Million Points Uniform Actuator Disc: CT = Mtip = µ = 0.15

Parallelisierung Einsatz beim DLR, bei diversen Industriefirmen und an vielen Universitäten Portabilität DLR-IAS / Le Chuiton / October 2001 Eddy Viscosity / Molecular

5 Ausgangssituation I 80-er Jahre: Entwicklung vieler Strömungslöser (Produktions-Codes) für die Luftfahrt im DLR CEVCATS und in der Industrie MELINA, NSFLEX. IKARUS Merkmale dieser Codes : Hauptgewicht der Entwicklung lag auf: Programmiersprache: FORTRAN; verwendeter Rechner: CRAY Vektorrechner. - Implementierung von Funktionalitäten; - Verbesserung der Leistungsfähigkeit; Entwicklungsstandards und Software-Engineering wurden damals kaum angewendet: Geringe Modularität des Codes, schwierige Wartbarkeit; Keine Nutzer- und Entwicklerdokumentation; Unzureichend festgelegte Entwicklungsprozesse; kein Versions-Management.

- Implementierung von Funktionalitäten; - Verbesserung der Leistungsfähigkeit; Entwicklungsstandards und Software-Engineering wurden damals kaum

6 Ausgangssituation II Anfang der 90-er Jahre: Initiative zur Vereinheitlichung der Produktionscodes in der Luftfahrt ( BMBF-Projekte: POPINDA, Megaflow ). Ergebnis: FLOWer CEVCATS MELINA nationaler Strömungslöser für blockstrukturierte Netze IKARUS NSFLEX Ziel: Die Erstellung eines industriell einsetzbaren, d.h. zuverlässigen, qualitativ hochwertigen und effizienten Programmsystems.

Ergebnis: FLOWer CEVCATS MELINA nationaler Strömungslöser für blockstrukturierte Netze IKARUS

7 Die wichtigsten Ziele bezügl. der Weiterentwicklung von FLOWer Zuverlässigkeit, Korrektheit der Rechnung Effizienz ( hinsichtlich Speicher- und Rechenzeitbedarf ) Portabilität ( Nutzung verschiedener Rechnerarchitekturen ) P r i o r i t ä t Erweiterung des Einsatzbereichs durch den Einbau neuer Funktionalitäten gute Wartbarkeit ( einfache Weiterentwicklung des Codes ) Schnelle und leichte Einarbeitung neuer Entwickler und Nutzer Wiederverwendbarkeit einzelner Softwarekomponenten Geringe Codekomplexität

Rechenzeitbedarf ) Portabilität ( Nutzung verschiedener Rechnerarchitekturen ) P r i o r i t ä t Erweiterung des

8 NOTWENDIG: Einführung eines QS-Systems Ansatz: Schaffung, Einführung und Anwendung eines spezifischen Qualitätsmanagementsystems; Zertifizierung des QS-Systems nach DIN EN ISO Vorgehensweise: Bildung eines QS-Teams: - Kompetenz von der zentralen DLR QS-Abteilung (heute SISTEC); - Bestimmung eines QS-Verantwortlichen ( Einstellung einer Informatikerin mit QS-Fachkenntnissen ); - Bestimmung eines System-Verantwortlichen; - Schulung der Projektmitarbeiter.

Vorgehensweise: Bildung eines QS-Teams: - Kompetenz von der zentralen DLR QS-Abteilung (heute SISTEC); - Bestimmung

9 Aufgaben der QS für FLOWer Änderungen und Erweiterungen des Codes systematisch nach fehlervermeidenden Regeln zu implementieren und zu testen. Mit jeder Code-Änderung die bestehende Codestruktur zu analysieren, um die Struktur mit den Änderungen besonders hinsichtlich Modularität begleitend zu verbessern. Durch definierte Entwicklungs- und Prüfabläufe zu einer stabilen und hohen Produktqualität beitragen.

Mit jeder Code-Änderung die bestehende Codestruktur zu analysieren, um die Struktur mit den

10 FLOWer QS-Verfahrensrichtlinien Qualitätsmanagementplan Dokumentationsstandard Konfigurationsmanagementverfahren Codier- und Designstandard Teststandard Störmelde- und Wartungsverfahren Entwicklerhandbuch FLOWer Verfahrensanweisungen für den Entwickler (Auszug aus der QS-Doku)

Designstandard Teststandard Störmelde- und Wartungsverfahren

11 Teststufen Beispiel eines QS-Verfahrens: Regressionstest Review der Testmodelle Teststufe 2 erweiterter Integrations und Funktionstest Integrations und Funktionstest Verifikation der geänderten Komponenten Teststufe 1 Modifikationsstufe 0 interne Modifikationen Teststufe 3 Systemtest Modifikationsstufe 1 interne Modifikationen Modifikationsstufe 2 Änderung der Systemstruktur Änderung der Leistungsspezifikation (z.b. Neuentwicklung, Funktionalitätserweiterung) Leistungsmerkmale und globale Variable ändern sich nicht keine Auswirkungen auf andere Komponenten Modifikationsstufe 3 systemweite Änderungen Änderung globaler Variablen Leistungsmerkmale und globale Variable ändern sich nicht mit Auswirkungen auf andere Komponenten Modifikationsstufen

Systemstruktur Änderung der Leistungsspezifikation (z.b.

12 Beispiel eines QS-Verfahrens: Ziele des Konfigurationsmanagements Jede Software-Komponente und -Version ist eindeutig identifiziert. Die Software besteht aus einem konsistenten Set von Komponenten. Jede Veränderung an der Software ist geprüft und dokumentiert. Änderungen an der Software gehen nicht verloren. (z.b. durch simultane Updates) Zugriff auf vorangegangene, konsistente Versionen der Software ist jederzeit möglich. Durch Aufzeichnung der Änderungshistorie ist nachvollziehbar, wer was und wann geändert hat.

Jede Veränderung an der Software ist geprüft und dokumentiert. Änderungen an der Software gehen nicht verloren. (z.b.

13 FLOWer Entwicklungsprozess Definierter Entwicklungsprozess Codier / Designregeln Testverfahren Entwickler QS + KM + Test Anwender Verantwortliche Entwicklungsauftrag Konzept Implementation Test Dokumentation Konfig. Management + Problem Tracking Verwaltung von Source Code und Dokumentation Eingangspruefung Integrationstest Systemtest Freigabe Fehlerberichte Funktionalitaets anforderungen Anderungsauftrage : :

14 Einsatz von CASE Tools Kontrolle der Codierregeln: ftn_check Entwicklungsumgebung: SNIFF+ Problem Tracking: Continuus / PT Konfigurationsmanagement: Continuus / CM Messung der Testüberdeckung: DEC profiler + shell scripts Testumgebung/Testdokumentation: shell scripts - zur automatischen Durchführung einer Testreihe - zum Vergleich von Ergebnisdaten Dokumentation: Continuus und QA-Fortran

DEC profiler + shell scripts Testumgebung/Testdokumentation: shell scripts - zur automatischen

15 Konfigurationsmanagement mit Continuus I Verwaltet Software-Komponenten einschließlich der Änderungs-Dokumentation mit Hilfe eines Relationalen Datenbank Systems. Bedienung durch ein graphisches Benutzer Interface. Bietet die Visualisierung der Änderungshistorie für jede einzelne Software-Komponente. Dadurch ist eine komfortable Verwaltung und Informationsbereitstellung gegeben.

Bedienung durch ein graphisches Benutzer Interface.

16 Konfigurationsmanagement mit Continuus II Entwickler 1 Entwickler 2 Sources: delete.f main.f..... work area work area Sources: Version 1 / released Version 2 / released Doku delete.f main.f new.f..... Version 1.1 / working Version 1 / released Version 1 working Doku + + Continuus Datenbank Sources: Dokumente: delete.f Version 1 / released Aenderungs Manuals Version 1 delete.f Version 1.1 / working Doku Manuals Version 2 main.f Version 1 / released QS Standards main.f Version 2 / released Version 2

1 / working Version 1 / released Version 1 working Doku + + Continuus Datenbank Sources: Dokumente: delete.

17 Continuus: Darstellung der Entwicklungsgeschichte

18 Konfigurationsmanagement mit Continuus: Erfahrungen Die Zielsetzungen des Konfigurationsmanagements lassen sich mit Hilfe von Continuus mit geringem Aufwand erreichen. - Continuus läuft sehr stabil und zuverlässig!! - Die Entwicklungsgeschichte jedes einzelnen "Objekts" (z.b. Source- Code-Datei) wird sehr übersichtlich dargestellt. Es bestehen gute Vergleichsmöglichkeiten verschiedener Dateiversionen. - Zugriff auf alte Versionen des FLOWer-Codes ist schnell und einfach möglich. - Jeder Entwickler hat sofort Zugriff auf alle in der "Integrations-Version" vorhandenen Datei-Versionen. Das Zusammenspiel von Konfigurationsmanagement und Problem Tracking ermöglicht eine effiziente Unterstützung der Dokumentation aller Entwicklungsarbeiten. Probleme: Kosten und Einführungsphase.

Es bestehen gute Vergleichsmöglichkeiten verschiedener Dateiversionen. - Zugriff auf alte Versionen des FLOWer-Codes ist schnell und einfach möglich.

19 Fazit: Einführung von Software-Engineering bei Wartung und Weiterentwicklung des FLOWer-Codes Die nachträgliche Einführung von QS hat die Arbeitsweise der Entwickler zu mehr Qualitätsbewußtsein verändert. Die Einarbeitungszeit neuer Entwickler konnte stark reduziert werden durch: - verbessertes Design; - Vermeidung fehleranfälliger Codierung; - gute Dokumentation ( Installation and User Handbook, Architektur-Handbuch, Source-Code Doku ). Die Dokumentation der Testergebnisse erleichtert die Fehlersuche, da jederzeit mit alten Testergebnissen verglichen werden kann. Die vielfältigen Testaktivitäten sichern eine relativ hohe Fehlerfreiheit und somit Kunden- und Entwicklerzufriedenheit.

Die Einarbeitungszeit neuer Entwickler konnte stark reduziert werden durch: - verbessertes Design; - Vermeidung fehleranfälliger Codierung; - gute Dokumentation (

20 Fazit (Teil 2): Kompetenz von SISTEC bei der Einführung von QS sehr hilfreich ( Erstellung der QS-Verfahrensrichtlinien ). Umsetzung der QS-Richtlinien erfordert auch Kompetenz hinsichtlich QS im Entwickler-Team. Berücksichtigung des zusätzlichen Personalbedarfs seitens der Projektleitung erforderlich. Probleme: - Auswahl und Anpassung geeigneter CASE-Tools; - Umsetzung von QS-Maßnahmen ohne CASE-Tool Unterstützung; - Umschulung der Entwickler ( Entwicklung im Team, Anwendung der QS-Richtlinien ); - Nachträgliche Umsetzung der Design- und Codier-Regeln; - Anpassung des QS-Systems an den vorhandenen Code; z.b. nachträgliche Erstellung eines Pflichtenhefts.

Berücksichtigung des zusätzlichen Personalbedarfs seitens der Projektleitung erforderlich.

Ähnliche Dokumente

Angepasste Software Standards für DLR- Eigenentwicklungen - Die DLR Software Basisstandards -

Angepasste Software Standards für DLR- Eigenentwicklungen - Die DLR Software Basisstandards - Anita Herrmann Braunschweig, 10. Nov 2004 Ausgangspunkte Im DLR werden nach vorsichtigen