SW-Qualitätsmanagement bei der Entwicklung eingebetteter Software Projekt COROTLOG

Transkript

1 SW-Qualitätsmanagement bei der Entwicklung eingebetteter Software Projekt COROTLOG Norbert DÖLER Deutsches Zentrum für Luft- und Raumfahrt e.v. (DLR) Workshop in Braunschweig, 10. Nov

2 COROT COnvection and ROTation Ein nationales französisches Projekt mit europäischer Beteiligung zur Erforschung der Pulsation von Sternen (Astroseismologie) und zur Suche von extrasolaren Planeten 2

3 Astroseismologie 3

4 Suche von extrasolaren Planeten Transit eines Planeten 4

5 COROTLOG On-Board Software für die Nutzlast Die On-Board-Software besteht aus zwei Modulen (Executables) Primary Boot Software (PBS) und Application Software (APS), Datenreduktion (1:100 1:400) - Boot-up nach Einschalten - TC (Tele Command) Empfang, Verifikation, Bestätigung, Ausführung - TM (Telemetry) Erzeugung, Formatierung, Transfer - Instrument Initialisierung und Kontrolle - Wissenschaftliche Daten, Verwaltung und Verarbeitung - Winkelmessung zur Feinausrichtung des Satelliten - Speicher Management (up- und download, Software Patches) - Event und Fehler Management, House-Keeping - Instrument und DPU Status und Moden Management 5

6 COROTLOG On-Board Software für die Nutzlast Primary Boot Software (PBS) und Application Software (APS), Datenreduktion (1:100 1:400) Die eingebettete On-Board-Software besteht aus zwei Modulen (Executables) und besitzt kein GUI. 6

7 COROTLOG Satelliten Plattform DPU Teleskop mit CCDs 7

8 Charakteristik COROTLOG Software (Zwei Module) PBS APS Projekt Eingebettete SW (PROM) mit hoher Kritikalität 4000 Codezeilen in Assembler Hohe Zuverlässigkeit für 150 Tage ununterbrochenen Betrieb Echtzeit SW 200 Seiten Nutzerforderungen, komplex (Kommandierung) 15 Personenjahre, 4 Jahre Laufzeit Auftraggeber-Auftragnehmerbeziehung mit CNES Hohe Qualitätsforderungen (analog zu ECSS) ECSS European Cooperation for Space Standardization CNES Centre National d'etudes Spatiales 8

9 Die Rolle von SISTEC Software Qualitätssicherung Begleitung in allen Projektphasen Hilfe bei der Umsetzung der Qualitätsforderungen Verantwortung für Umsetzung gegenüber CNES (interne Audits) Unterstützung bei Reviews 9

10 10 Projektphasen Software

11 E-70 PHASE O/A B C D NAME Feasibility Studies and Conceptual Design Preliminary Design Design Procurement Production Integration & Technical Verification and Validation Operational Validation Projektphasen System ACTIVITIES REVIEWS Development of a Software Element of the Ground Segment Identify Characteristics, Constraints, Concepts. Assess feasibility. (G/S) perspective GSRR E-40 Processes E-40 Activities E-40 Reviews Additional Reviews Define requirements on G/S& G/S Baseline GSPDR System Requirements Analysis SRR Complete G/S design to element level & start implementation GSCDR Requirements Engineering Software Requirements Analysis Top Level Software Architectural Design PDR Procure G/S facilities & elements GSTVVRR Design Engineering AD Phase Integrate, Verify & Validate G/S systems (includes preliminary validation of mission data GSTVVR OVRR Qualification Engineering E-40 Detailed Design Train people & Validate full G/S (i.e. includes people and mission data Technical Validation QR ORR Operational Validation Customer Supplier Customer Figure 2: Second Mapping of ECSS-E-70 to ECSS-E-40 (Phases A - D): Complex Architecture, well-defined requirements ADR CDR AR 11

12 Qualitätsforderungen I 180 QS Forderungen von CNES 164 relevant 40 Dokumente und Listen gefordert benötigt + Eigene Projektdokumentation (z.b. Design File) Dokumente Software Quality Assurance Plan Development Plan (enthält Risiko Analyse) Software requirements... Traceability matrix (Konfigurations-Management).. Software index. 12

13 Qualitätsforderungen II 28 Forderungen beziehen sich auf configuration MO The partner shall set up a software development environment integrating the chosen development tools, and the tools associated with software configuration management, verification, product assurance and inspection activities. CL The design documentation shall be under documentation and configuration rules. GQ The DLR realizes, tests and confirms any modification on a working configuration similar to the configuration in exploitation and different from this one. 13

14 Wie erreicht man (SW)-Qualität? Maßnahmen und Methoden Organisatorische Maßnahmen sorgen dafür, dass konstruktive und analytische Maßnahmen stattfinden können Aufbau, Einführung und Pflege eines Qualitätsmanagementsystems Konstruktive Maßnahmen sollen das Entstehen von Fehlern und Qualitätsmängeln durch Vorgabe von geeigneten Methoden und Werkzeugen von vornherein verhindern. Planung Vorgehensmodelle Dokumentation Konfigurationsmanagement Analytische Maßnahmen dienen zur Erkennung und Lokalisierung von Mängeln und Fehlern. Tests Reviews Audits Kennzahlen Qualitätslenkung Qualitätsprüfung 14

15 Umsetzung der Qualitätsforderungen durch Einführung eines definierten Engineering Prozesses, Unterstützung durch integrierte Werkzeugumgebung und konsequente Anwendung. Rational Unified Process Rational RequisitePro Anforderungs-Management Rational ClearQuest Änderungs-Managenment Rational ClearCase Konfigurations-Management Rational TestManager, TestRealTime 15

16 Konfigurations-Management Sicherstellung der Integrität der Konfiguration Kontrolle der Änderungen Management der Änderungen Auslieferung mit definierten Status 16

17 Software Tests Testen deckt Fehler auf, zeigt aber nicht dass die Software fehlerfrei ist! Nachweis, dass die SW die Spezifikationen erfüllt Eigenschaften der SW berücksichtigen, (eingebettete SW, Realtime SW) Testabdeckung demonstrieren, (100% bei PBS gefordert) Rückverfolgbarkeit, Wiederholbarkeit, Versionskontrolle, Dokumentation, Erfordert ein automatisiertes Testsystem mit Anbindung an die Projektdatenbanken 17

18 Software Testsystem RequisitePro SW Forderungen Teleskop ClearCase ClearQuest Simulator COROTLOG Test Fälle Test Ergebnisse Test Manager Simulator Satelliten- Plattform Eingebettet in DPU Test nur über Schnittstellen 18

19 Software Testumgebung "Rational Unified Process" im automatisierten Testsystem 4Automatische Ausführung der Tests (Test Manager TestRealTime ) 4Automatische Archivierung der Testdaten (Test Manager TestRealTime, Test Manager Requisite Pro ) 4Erzeugung Test/Fehler Reports (TestRealTime Test Manager ClearQuest ) 4Versions-Kontrolle der Tests ( TestRealTime ClearCase ) 4"Tracing" der Testfälle gegen SW Forderungen ( Requisite Pro Test Manager ) 19

20 Probleme und Nicht-Konformitäten Änderungsmanagement Probleme, besonders in kritischen Systemen, erfordern Aufzeichnung, Verfolgung und Überwachung bis zu einer Lösung (Entscheidung). Dies kann zu Änderungen führen, die dokumentiert werden müssen, oder zu Nicht-Konformitäten die eine systematische und formale Behandlung erfordern, speziell wenn andere Systeme oder Subsysteme betroffen sind. 20

21 Risiko Management Beispiele: Startverschiebung (Risiken von außen), akzeptieren oder Auswirkung durch Planung minimieren Betriebssystem, keine Wartung mehr, Alternative? Risiko Management ist ein systematischer Prozess um Risiken zu Identifizieren, Analysieren, Quantifizieren (Kosten, Zeit, Design, Wahrscheinlichkeit) und zu Reagieren (Vermindern, Akzeptieren) Tritt ein Risiko ein, ist es kein Risiko mehr sondern ein Problem! 21

22 Erfahrungen Einführung eines neuen Prozesses für Entwicklung und Management + einheitlich, Werkzeug gestützt, Verfolgbarkeit und Dokumentation vereinfacht -+ Einarbeitungszeit, Disziplin Risiken durch externe Partner nicht abschätzbar Verzögerung, Schnittstellen Zusätzlicher Zeitaufwand Reviews (PDR, CDR), (wechselndes Team) Verständnis von Forderungen (DLR) und deren Umsetzung (CNES) Übereinstimmung der relevanten QS-Forderungen mit DLR Basis- Standards QS-Forderungen sind mit entsprechenden Prozess erfüllbar 22

23 Erfolg durch Kooperation 23