SW-Qualitätsmanagement bei der Entwicklung eingebetteter ... · Charakteristik COROTLOG Software (Zwei Module) PBS Eingebettete SW (PROM) mit hoher Kritikalität 4000 Codezeilen

1Simulations- und Softwaretechnik

SW-Qualitätsmanagement bei der Entwicklung eingebetteter Software

Projekt COROTLOG

Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)

Simulations- und Softwaretechnik

Workshop in Braunschweig, 10. Nov 2004

Norbert DÖLER<[email protected]>

Simulations- und SoftwaretechnikNorbe

rt Döler, N

ov 200

4

2

COROTCOnvection and ROTation

Ein nationales französisches Projekt mit europäischer Beteiligung zur Erforschung der Pulsation von Sternen (Astroseismologie) und zur Suche

von extrasolaren Planeten


rt Döler, N

ov 200

4

3

Astroseismologie


rt Döler, N

ov 200

4

4

Suche von extrasolaren PlanetenTransit eines Planeten


rt Döler, N

ov 200

4

5

COROTLOG

• Primary Boot Software (PBS) und • Application Software (APS), Datenreduktion (1:100 – 1:400)

Die On-Board-Software besteht aus zwei Modulen (Executables)

- 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

On-Board Software für die Nutzlast


rt Döler, N

ov 200

4

6

COROTLOG

• 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.

On-Board Software für die Nutzlast


rt Döler, N

ov 200

4

7

COROTLOGSatelliten Plattform

Teleskop mit CCDs

DPU


rt Döler, N

ov 200

4

8

Charakteristik COROTLOG

Software (Zwei Module)

PBS Eingebettete SW (PROM) mit hoher Kritikalität

4000 Codezeilen in Assembler

APS Hohe Zuverlässigkeit für 150 Tage ununterbrochenen Betrieb

Echtzeit SW

200 Seiten Nutzerforderungen, komplex (Kommandierung)

Projekt

15 Personenjahre, 4 Jahre Laufzeit

Auftraggeber-Auftragnehmerbeziehung mit CNES

Hohe Qualitätsforderungen (analog zu ECSS)

ECSS European Cooperation for Space StandardizationCNES Centre National d'Etudes Spatiales


rt Döler, N

ov 200

4

9

Die Rolle von SISTECSoftware 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


rt Döler, N

ov 200

4

10

Proj

ektp

hase

n So

ftwar

e


rt Döler, N

ov 200

4

11

NAME

ACTIVITIES Identify Characteristics,Constraints, Concepts.Assess feasibility.(G/S)perspective

GSRR GSPDRGSTVVRR

GSCDR

Define requirementson G/S& G/SBaseline

Complete G/Sdesign to elementlevel & startimplementation

Procure G/Sfacilities &elements

Integrate, Verify &Validate G/S systems(includes preliminaryvalidation of missiondata

Train people& Validate full G/S(i.e. includes peopleand mission data

E-70 PHASE O/A B C D

REVIEWSGSTVVR

OVRR

ORR

Feasibility Studiesand

Conceptual Design

PreliminaryDesign Design Production

Procurement Integration & Technical Verification

and Validation

OperationalValidation

Development of a Software Elementof the Ground Segment System

RequirementsAnalysis

SoftwareRequirements

Analysis

Top LevelSoftware

ArchitecturalDesign

Requirements Engineering

SRR PDR

TechnicalValidation

OperationalValidation

Qualification Engineering E-40

QR AR

Customer Supplier Customer

Figure 2: Second Mapping of ECSS-E-70 to ECSS-E-40 (Phases A - D): Complex Architecture, well-defined requirements

DetailedDesign

CDR

Design EngineeringE-40 Processes

E-40 Activities

E-40 Reviews

Additional Reviews

AD Phase

ADR

Proj

ektp

hase

n Sy

stem


rt Döler, N

ov 200

4

12

Qualitätsforderungen I

180 QS Forderungen von CNES → 164 relevant

40 Dokumente und Listen gefordert → 10 + 3 benötigt

+ Eigene Projektdokumentation (z.B. Design File)

Software Quality Assurance PlanDevelopment Plan (enthält Risiko Analyse)

Software requirements.........Traceability matrix (Konfigurations-Management)…..Software index….

Dokumente


rt Döler, N

ov 200

4

13

Qualitätsforderungen II

MO030-5.3.7 The partner shall set up a software developmentenvironment integrating the chosen development tools, and thetools associated with software configuration management,verification, product assurance and inspection activities.

CL080-5.4.2 The design documentation shall be underdocumentation and configuration rules.

GQ220-4.5 The DLR realizes, tests and confirms any modificationon a working configuration similar to the configuration in exploitation and different from this one.

≈ 28 Forderungen beziehen sich auf configuration


rt Döler, N

ov 200

4

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.

PlanungVorgehensmodelle

DokumentationKonfigurationsmanagement

Analytische Maßnahmen……dienen zur Erkennung und

Lokalisierung von Mängeln und Fehlern.

TestsReviewsAudits

Kennzahlen

Qualitätslenkung Qualitätsprüfung


rt Döler, N

ov 200

4

15

Umsetzung der Qualitätsforderungendurch

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


rt Döler, N

ov 200

4

16

Konfigurations-Management

• Kontrolle der Änderungen

• Management der Änderungen

• Auslieferung mit definierten Status

Sicherstellung der Integrität der Konfiguration


rt Döler, N

ov 200

4

17

Software Tests

• 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,

Testen deckt Fehler auf, zeigt aber nicht dass die Software fehlerfrei ist!

Erfordert ein automatisiertes Testsystem

mit Anbindung an die Projektdatenbanken


rt Döler, N

ov 200

4

18

Teleskop

Satelliten-Plattform

Test Manager

TestErgebnisse

TestFälle

SWForderungen

RequisitePro

ClearQuestClearCase

Simulator

SimulatorCOROTLOG

Eingebettet in DPU

Test nur über Schnittstellen

Software Testsystem


rt Döler, N

ov 200

4

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 )


rt Döler, N

ov 200

4

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.


rt Döler, N

ov 200

4

21

Risiko Management

Risiko Management ist ein systematischer Prozess um Risiken zuIdentifizieren, Analysieren, Quantifizieren (Kosten, Zeit, Design, Wahrscheinlichkeit) und zuReagieren (Vermindern, Akzeptieren)

Beispiele:

Startverschiebung (Risiken von außen), akzeptieren oder Auswirkung durch Planung minimieren

Betriebssystem, keine Wartung mehr, Alternative?

Tritt ein Risiko ein, ist es kein Risiko mehr sondern ein Problem!


rt Döler, N

ov 200

4

22

Erfahrungen

Risiken durch externe Partner nicht abschätzbarVerzögerung, Schnittstellen

Zusätzlicher ZeitaufwandReviews (PDR, CDR), (wechselndes Team)

Verständnis von Forderungen (DLR) und deren Umsetzung (CNES)

Übereinstimmung der relevanten QS-Forderungen mit DLR Basis-StandardsQS-Forderungen sind mit entsprechenden Prozess erfüllbar

Einführung eines neuen Prozesses für Entwicklung und Management+ einheitlich, Werkzeug gestützt, Verfolgbarkeit und Dokumentation vereinfacht

-+ Einarbeitungszeit, Disziplin


rt Döler, N

ov 200

4

23

Erfolg durch Kooperation

Documents

SW-Qualitätsmanagement bei der Entwicklung eingebetteter ... · Charakteristik COROTLOG Software (Zwei Module) PBS Eingebettete SW (PROM) mit hoher Kritikalität 4000 Codezeilen