Optimierte Entwicklungsprozesse & Konfigurationsmanagement durch

Software Qualität und Testing

11. EUROFORUM-JahrestagungSoftware im Automobil

Ein Vortrag von:Stanislav Flígl

undJanos Koppany

Agenda

• Angewandtes Software-Engineering und funktionale

Sicherheit

• Verwalten von Anforderungen, Testspezifikationen und

Integration mit Testtools

• Verteilte Versionskontrollsysteme: Einsatz im

Entwicklungsprozess

Angewandtes Software -Engineering und funktionale Sicherheit

SW Entwicklungsprozesse V-Model in der elektrischen Traktion

IEC 61508 Sicherheit sicherheitsbezogene elektrische /elektronische /programmierbare elektronische System e

ČSN EN 61508 Basisnorm

Einige Fachspezifische Normen:

Prozessindustrie

Kerntechnik

Straßenfahrzeuge bis 3500 kg

Eisenbahn

Flugzeugtechnik

IEC 61508

IEC 61511

IEC 61513

ISO 26262

EN 50128

DO 178(ED-12)

IEC 61508 Sicherheit sicherheitsbezogene elektrische /elektronische / programmierbare elektronische Syste me

ČSN EN 61508 Basisnorm (IEC 61508:2000, ČSN EN 61508:2002, IEC 61508:2010, ČSN EN 61508:2011)

Einige Fachspezifische Normen:

Straßenfahrzeuge bis 3500 kg (ISO 15504:1998, ISO 1 5504:2003-2008, MISRA:1994, MISRA-C:1998, MISRA-C:2004, ISO 26262:2 009, ISO 26262:2011?)

Eisenbahn (EN 50128:2001, ČSN EN 50128:2003, EN 50128:2011?)

Flugzeugtechnik (DO178A-1985, DO178B-1992, DO178C-2 011?)

IEC 61508

ISO 26262

EN 50128

DO 178(ED-12)

ISO 26262 und EN 50128

ISO 26262

EN 50128

EN 50128:2001 und EN 50128:2009 draft

EN 50128:2001 EN 50128:2009

Aufgabe für die Implementierung

VER

VER

VER

VER

VAL

VAL

VAL

Component Design Coding & Testing Phase

VER

VER

SW Development

Software Validation

Phase

Software Integration

Phase

Software Component

Testing Phase

Software Component

Design Phase

Software Architecture & Design Phase

Software Requirements

Phase

Kódování SW modulu

Implementierung in bestehende Dokumentensysteme

Schéma procesu vývoje SW

15- DI

Plán testování integrace SW/HW

Etapa požadavků na SW

Ověření

Ověření

1 - DI

Specifikace požadavků

na SW

2 - VAL

Specifikace testování

požadavků na SW

3 - VER

Zpráva o ověřování požadavků

na SW

4 - TMP

Kontrola 3 a

schválení 1, 2, 3

20- VAL

Zpráva o validaci

SW

21- TMP

Kontrola 19, 20 a

schválení 19, 20

5 - DI

Specifikace architektury

a návrhu SW

6 - VER

Zpráva o ověřování

architektury a návrhu

SW

7- VAL

Kontrola 6, a schválení 5, 6

16- DI

Zpráva o testování integrace SW/HW

17- VER

Kontrola 15, 16

18- VAL

Schválení 15, 16

8- DI

Specifikace návrhu SW modulů a

Specifikace testování

SW modulů

9- DI

Zpráva o testování SW

modulů a

Zdrojový kód

10- VER

Zpráva o ověřování

SW modulů a

Zpráva o ověřování zdroj. kódu

12- VER

Plán testování integrace

SW

13- VER

Zpráva o testování integrace

SW

14- VAL

Kontrola 12, 13

a schválení

12, 13

11- VAL

Kontrola 10 a

schválení 8, 9, 10

KONEC

1, 19 1

5, 6 1, 5 1,5,15 15,16

8 8, 9 8, 10 5,8,12

Schválení Schválení

Schválení Schválení

15,16

12,13

Ověření

Etapa návrhu, kódování a testování SW modulů

Etapa architektury a návrhu SW Etapa integrace SW/HW

Etapa integrace SW

Etapa validace SW

START

Ověření Ověření Ověření

Ověření

Ověření

1, 3

Schválení Schválení

Ověření

&

&

1, 2 19- VAL

Plán validace

SW

Software Engineering

1968 – NATO Software Engineering Konferenz in Garmis ch-Partenkirchen

Krisis der Software definiert als:

* Projects running over-budget.

* Projects running over-time.

* Software was very inefficient.

* Software was of low quality.

* Software often did not meet requirements.

* Projects were unmanageable and code difficult to main tain.

* Software was never delivered.

Die Einführung eines neuen Begriffs: „Software Engi neering“

■

■

■

Über 40 Jahre Erfahrung / produzierte neue Werkzeuge

Viele Werkzeuge stammen ursprünglich nicht aus dem Embedded Bereich.

Die Verbindung der Norm mit der Vielfalt ist schwie rig.

Erst in der letzten Jahren ist SW Engineering an Un iversitäten ein etabliertes Fach geworden.

Viele Werkzeuge sind als OpenSource Produkte erhältl ich – einige in sehr hoher Qualität.

Versionskontrolsysteme

Buildsysteme

Kontinuierliche Buildserver

Issue Tracking Systeme

Requirement Management Werkzeuge

Wiki-Systeme

Testwerkzeuge

Simulationswerkzeuge

RT-Simulationsumgebungen

Domain Specific Languages

■

■

■

■

■

■

■

■

■

■

■

Versionkontrollsysteme und IssueTracking Systeme

Entwickler sind oft während der Endphase des Projek t unterwegs - in Versuchshallen oder

an Teststrecken – oft mit schlechter oder keiner Net zanbindung.

Klassische Methoden scheitern.

■

■

Verwalten von Anforderungen, Testspezifikationen und Integration mit

Testtools

codeBeamer

"codeBeamer", Intlands voll

integrierte Plattform für die

embedded Software Entwicklung,

begleitet geografisch verteilte

Projektteams während des

gesamten Entwicklungsprozesses

– vom Requirements Management

bis zum Application Lifecycle.

Verwalten von Anforderungen, Testspezifikationen un d Testtool Integration

CB WIKI

CB CMDB

CB SCM und Hg

CB ReportingTesttools: (z.B)Vectorcast, HP QC

CB WIKI, Baselines

CB Projects

Entwicklungsprozess mit Mercurial und codeBeamer

Code

ComponentSpec.

ComponentTest

SW Design Spec.

SW Integration

SW Rquirements Specification

SW Validation

Entwicklungsprozess mit Mercurial und codeBeamer

SW Requirement Specification

Wiki

Exprot PDF

Approval

Tracker

Entwicklungsprozess mit Mercurial und codeBeamer

SW Design Specification

Entwicklungsprozess mit Mercurial und codeBeamer

SW Component Design

Entwicklungsprozess mit Mercurial und codeBeamer

Code

Sourcecode Entwicklung mit Mercurial, HgEclipse, Mylyn und Eclipse Helios

Entwicklungsprozess mit Mercurial und codeBeamer

Component Test & SW Integration

CB REQ CB TEST

Creation of REQ or Change request

Transfer to HP QC

After testing, transfer of results in codeBeamer test Tracker

After review of test results, change of REQ or CR status

CB Releases

Test Status can be shown in releases

Testspezifikation über CMDB Eintrag

Reports über Testergebnisse und Ausführungsgrade erstellen und Ablage in Dokumentenmanagement

HP QC

Beispiel für HP QC Integration

Entwicklungsprozess mit Mercurial und codeBeamer

Software Validation

Version/ Release Übersicht über Bugs, Test, REQ, Tasks

Release Notes für Kunden

Dokumentation in Wiki+Baselines

Verteilte Versionskontrollsysteme:

Einsatz im Entwicklungsprozess

Versionkontrolsysteme - GeschichteSCCS (Source Code Control Systems) – Marc Rochkind, Be ll Labs

– Anfang 70. Jahre (Konzept – Dateienabschliessen)

RCS (Revision Control System) – Walter F. Tichy – Anfang 80. Jahre

CVS (Concurrent Version System) – Brian Berliner

– 1989 (zentralisiert Klient / Server)

ClearCase

– ursprünglich Atria Software 1992, später auch Ratio nal, ab 2003 IBM

TeamWare – Sun Microsystems

– Anfang 90. Jahre (verteiltes System, atomic commits )

Visual SourceSafe – Microsoft 1995

Team Foundation Server – Microsoft 2006

Subversion – SVN (zentralisiert) – als Ersatz für CVS entwickelt – CollabNet 2000

Mercurial – HG (verteilt) – inspiriert durch Monotone (SHA-1 2003) und TeamWare

– Selenic 2005

Git (verteilt ) – inspiriert durch BitKeeper (2002) – Linus Torvalds 2005

■

■

■

■

■

■

■

■

■

■

Versionkontrolsysteme – Auswahlverfahren2008 – Suche nach einem besserem Versionkontrolsystem und möglichen Alternativen

für die Verwaltung von SW Lebenszyklus nach EN 5012 8

Herbst / Winter 2008 – erste Experimente mit Subversi on und nachträglich mit Mercurial

April 2009 – Auswahl eines Projektes für den Ersteins atz von Mercurial

Juli 2009 – Auswahl von codeBeamer unter mehreren Too ls als geeignetes alternatives Verwaltungssystem zu vorhandenen ALM Lösungen

August 2009 – Errste Konversion von älteren Versionk ontrolsystemen in Mercurial

Dezember 2010 – Beenden der Konversion von älteren Pr ojekten von CVS in Mercurial

Januar 2011 – alle neue Projekte unabhängig vom Proze sssteuerungssystem

mit Mercurial verfolgt.

Januar 2011 – Installation von codeBeamer 5.5.1

Februar 2011 – Auswahl der ersten Projektes

März 2011 – Übergang und Vereinheitlichung zu Mercur ial 1.7.5

April 2011 – Milestein – Requirements

■

■

■

■

■

■

■

■

■

■

■

Warum Distributed Version Control Systeme

•Ein zentrales Repository•Ständige Netzwerkkonnektivitätbenötigt

•Branching/ Merging schwierig•Workflow Gestaltung nach neuen ISO Normen begrenzt/ komplex

•Verteilte Repository•Netzwerkunabhängige Entwicklung•Branching und Merging sind natürlicher Bestandteil

•Abbildung von Workflows und Integration von QA Tools möglich.

Beispiel Workflow für Bremssystem mit DVCS

untrusted-repository

mainrepository

carbrake system

Brake system

Supplier 1 Supplier 2 Supplier 3 Supplier 4

•open-source compliance check•code review

Distance control system

QA Check

Danke schön für Ihre Aufmerksamkeit

Vielen Dank für Ihre Aufmerksamkeit

Für weitere Informationen besuchen Sie bitteunsere Homepage:

Stanislav Flígl1

undJanos Koppany2

1stanislav.fligl@skoda.cz 2janos.koppany@intland.com

www.skoda.cz/en www.intland.comwww.javaforge.com