Optimierte Entwicklungsprozesse & Konfigurationsmanagement durch Software Qualität und Testing 11. EUROFORUM-Jahrestagung Software im Automobil Ein Vortrag von: Stanislav Flígl und Janos Koppany
Nov 28, 2014
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
[email protected] [email protected]
www.skoda.cz/en www.intland.comwww.javaforge.com