Wie Sie Risiken und Rückrufaktionen in der
Automobilbranche vermeiden
 2004 Founded with Groundbreaking Vision
 2005 First Unified, 100% Browser-Based ALM
 10 Years Focus on Unlocking Syner...
Flexible Solution Solves and Evolves
Requirements
Management
Test & Quality
Management
Issue & Defect
Management
Variant
M...
Broad, Loyal Customer Base
Certified Tool, Standards Templates
• Only ALM Tool Certified for IEC 61508/ISO 26262
• Templates for CMMI, FAA, FDA, IEC,...
Open Architecture
Trends & Herausforderungen
#
2015: Die Wahrnehmung ändert sich
“Any publicity is good publicity.” – P. T. Barnum
• Flut schlechter Nachrichten aus der ...
Gefahren der Software-Entwicklung
• Funktionale Sicherheit behält oberste Priorität
• FMEA
• Neue Ausfallkategorien
• Mögl...
Worauf es ankommt
• Gesteigerte Bedeutung des Entwicklungs-Lebenzyklus
• Als Aspekt des Markterfolgs definieren
• Software...
Embedded
Software
Development
Risk Analysis and
Management
Quality Systems
System Requirements
Design Requirements
PLM ECO...
Pragmatisch Agil – WaterSCRUMfall
AGILE
Embedded Systems- und
Geräte-Trends
• Traditionelles vs. V-Modell
• Agile Epics, U...
Problem Projekt Silos
Anforderungs
Management
Entwicklungs
Release Management
Qualitätssicherung
Funktionale
Sicherheit
 Sicherheits-Gefahrenanalyse und Risikoeinschätzung
- ISO 26262-3
 Item-Definition
 Bestimmung von Gefahren und gefährl...
Typische Fragen
• Wer hat Änderungen an der Gefahrenanalyse vorgenommen?
• Wann wurden die Änderungen gemacht?
• Was wird/...
Varianten-Features
Evolution des Variantenmanagements
Die Lösung:
 Feature-Modell
- Organisation der Features
- Repräsentiert als Polarion Work Items, Dokumente
 Master-Spezi...
Feature-Modell
Variante wird als Auswahl an
Features definiert
Varianten-Optionen
Spezifikations-Optionen
Restriktionen
• Einfache und komplexe
Logik
• Dynamisches Lesen von
Features
• Domain-Knowledge
150% Specification
100%-Spezifikation
Die Varianten-Spezifikationen
• Requirements
• Design
• Qualität/Regulierungen
• Tes...
Webinaraufzeichnung
ansehen
Thank you.
www.polarion.com
Thank you.
www.polarion.com
DANKE
Nächste SlideShare
Wird geladen in …5
×

Wie Sie Risiken und Rückrufaktionen in der Automobilbranche vermeiden

294 Aufrufe

Veröffentlicht am

Sie sind verantwortlich für Risiko- oder Testmanagement und Qualitätssicherung in der Software-Entwicklung? Compliance-Regelungen sind Ihr Tagesgeschäft und die Anforderungen ändern sich stetig? Das vergangene Jahr mit einer Rekordsumme an Rückrufaktionen macht deutlich: Die Automobilbranche befindet sich im Wandel.

In diesen Webinarfolien sehen Sie, wie Sie es schaffen, sich von unübersichtlichen Excel-Tabellen und anderen antiquierten Modellen zu verabschieden und am Puls der Zeit bleiben.

Veröffentlicht in: Automobil
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
294
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
6
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Polarion ALM Solution Overview
  • About Polarion:
    Polarion was founded in 2004 to start with a blank sheet and instigate a paradigm shift that would deliver a groundbreaking solution.
    Launched a year later, the Industry’s FIRST Unified, 100% Browser-Based ALM Solution based on ONE repository, data structure, and business logic did indeed disrupt the industry. This has been copied since by MKS, IBM, and Microsoft first, and more recently by Jama and Kovair.
    But of course, we have not stood still, and in the last 10 years, our customers have been able to Unlock Unprecedented Synergies and empower their disparate teams. Their feedback has helped us further expanded and refine the power of Real-Time Collaboration, a User-Driven UI, and Full Traceability.
    The Value Polarion provides is demonstrated by the 250 deployments in F1000 companies, 2.5M users ww, 200+ Extensions in the PEP, and a vibrant community of 15K registered members


    ---
    FYI - Original Stefano Storyboard Guidance:
    Vision: Founded in 2004 on the idea that the market was mature for a new ALM approach: not putting pieces together but build an unique foundation for ALM. We then refined it more and more to give unparalleled usability to all the stakeholders

  • Our customer rely on the Flexibility of the Solution to empower and connect ALL internal and external stakeholders in complex development ecosystems with the level of information and functionality they need to collaborate, stay in synch and succeed.

    Here you see the full set of capabilities unified in the Polarion platform to comprehensively address the development lifecycle.

    A great aspect of the architecture of the solution is that organizations can set out to Solve a specific pain point, and later Evolve and pursue incremental deployments as needed. This flexibility brings down the Total Cost of Ownership (TCO) to the lowest level in the industry (based on customer feedback).



  • The fact that Polarion is the only qualified ALM solution further builds on the great benefits offered to our customers. With this certification, customer efforts to proof tool compliance are minimized up to the highest automotive safety integrity level (ASIL-D/TCL2). Templates for a wide range of standards augment the offering. Customers are of course thrilled about this, as it saves them a lot of time and money.


    ---

    Polarion ALM solution for software and hardware development has been qualitifed for ISO 26262 [1], a functional safety standard for automobiles, by TUV Nord in Germany, a third-party certification authority. ISO 26262 specifies the requirements for safety-related systems, hardware, and software. Compliance with these standards is key for the whole industry, as any company who does not comply with the standard risks losing the legal right to sell their products in the main economic markets of the world. The qualification by TUV Nord demonstrates that Polarion’s software development processes comply with the highest Automotive Safety Integrity Level (ASIL-D) as defined in ISO 26262, and that the company can reliably implement and replicate the processes. This also means that customers using Polarion Software products do not need to certify the tool, and can easily just refer to Polarion qualification for ISO 26262 and show that required process activities are performed.
  • Slide: 7
    ======================================================
  • Slide: 8
    ======================================================
  • Slide: 9
    ======================================================
  • Slide: 10
    ======================================================


    And now, here’s David….
  • Experience with PL approaches in practice shows, that organizations mature their reuse
    capabilities along the following model in the past:
    Figure: Maturity of Variation Management Approaches
    After standardizing their development infrastructure, often companies establish a platform
    first.
    They develop and maintain a platform based on which the products or applications are built.
    The platform contains the development infrastructure as well as all functionality that is
    common to all products or applications. This means, they focus on commonality and support
    variability only in a minimalistic manner.
    Remark: Platform focusses on commonality
    Once the organization has reaped first (low hanging) reuse benefits, they increase the amount
    of functionality in the platform to the level where functionality common to several but not all
    products (shared parts) becomes part of the core assets too. With this they follow a more
    balanced variability approach. This approach is called a System or Software Product Line
    approach.
    Remark: Product Line means to support variability

    Production Line
    In recent years, sophisticated tooling for variability management has been provided, which
    allows organizations to evolve along the aforementioned stages in a faster way.
    In the so-called Production Line (aka. 2nd Generation SPL) approach organizations directly
    adopt a maximalist variability approach.
  • Wie Sie Risiken und Rückrufaktionen in der Automobilbranche vermeiden

    1. 1. Wie Sie Risiken und Rückrufaktionen in der Automobilbranche vermeiden
    2. 2.  2004 Founded with Groundbreaking Vision  2005 First Unified, 100% Browser-Based ALM  10 Years Focus on Unlocking Synergies: • Real-Time Collaboration • Intuitive UI • Full Traceability Fortune 1000 Deployments 250+ Users 2.5+M Extensions 200+ Registered Community Members 15K
    3. 3. Flexible Solution Solves and Evolves Requirements Management Test & Quality Management Issue & Defect Management Variant Management Change & Configuration Build & Release Management Resource Management Audits, Metrics, & Reports ALM
    4. 4. Broad, Loyal Customer Base
    5. 5. Certified Tool, Standards Templates • Only ALM Tool Certified for IEC 61508/ISO 26262 • Templates for CMMI, FAA, FDA, IEC, ISO, SPICE etc. "We’re just thrilled about Polarion’s tool qualification for ISO 26262. This saves us a lot of time and money in our own qualification process.” - Maria Eugenia Zuniga, Quantum Technologies
    6. 6. Open Architecture
    7. 7. Trends & Herausforderungen #
    8. 8. 2015: Die Wahrnehmung ändert sich “Any publicity is good publicity.” – P. T. Barnum • Flut schlechter Nachrichten aus der Automobilindustrie • 2014 – Höchste Rückrufrate in der Geschichte der Automobilindustrie • 500 Rückrufkampagne mit 50+ Millionen Einheiten • Rücktritte von CEOs bei Zulieferern und Herstellern • Hohe Wahrnehmung (vielleicht übertrieben) von aufgedeckten Hacks • Veröffentlicht durch Hacker-Communitys und technologieaffine Medien • Ein Rückschlag der leuchtenden Zukunft der “Connected Things” und selbstfahrender Autos • Rückruf von mehreren Millionen Einheiten (Software Patch) • Über das Web ausgeliefert – Vom Besitzer über USB installiert“ Thumb Drive” “Truly, we are entering a brave new world of vehicle ownership.” -- Autoweek • Veränderungen in der Konsumentenpsychologie / Marktwahrnehmung / Kundenbeziehungen - Automobilindustrie hat sich schon lange in Technologieindustrie gewandelt  Jahrzehnte der Digitalisierung – betrifft fast jedes Kraftfahrzeug  “This car runs on code.” – Millionen von Lines of Code  Tatsache, die Ingenieuren bekannt ist, aber jetzt erst beim Kunden ankommt - Autos sind keine mechnaischen Produkte mehr, sondern werden von den Besitzern mehr in der Kategorie Smartphone gesehen.  “Mr. Goodwrench” (Mechaniker aus GM-Werbung) wird durch “Genius Bar” (Apple-Tech-Support-Station) ersetzt  Sprachgebrauch im Kfz-Umfeld – Design, Pferdestärken, Beschleunigung, Verlässlichkeit etc.,… …..wird ergänzt User Interface, Setup-Optionen, Upgradeability, Customization, Stabilität ect. #
    9. 9. Gefahren der Software-Entwicklung • Funktionale Sicherheit behält oberste Priorität • FMEA • Neue Ausfallkategorien • Mögliche Revisionen der Standards und/oder neue Standards • ISO 26262 • Risiko-Assessment-Methode bleibt relevant • Integration des Sicherheits-Lebenszyklus mit Software-Entwicklungs-Lebenszyklus • Leistungsfähigkeit/Reifegrad des Entwicklungsprozesses - Vorgehensweise und Mittel der Entwicklung gleichermaßen wichtig wie die gelieferten Ergebnisse (PFMEA) - CMMI & Automotive SPICE  Both revolve around Process Reference and Assessment Models + organizational commitment to interpret & apply  Objectivity of Capability Assessments; Proving process capability / maturity • Kundeninteresse an Software-Features und –Qualität nimmt zu - Sicherheit als Voraussetzung; Advanced Driver Assistance Systems (ADAS) wird erwartet  Funktionale Sicherheit rettet Leben – Kunden gewinnt man jedoch an anderer Stelle z.B, Farben des UI, Bluetooth-Anbindung, etc.  Neue Möglichkeiten zur Differenzierung – Wachsende Nachfrage nach Optionen, Varianten und Customization  Auch wenn die Software noch so gut ist, sie wird kein hässliches Auto verkaufen …  aber schlechte Software-Qualität / -Features schaffen es, aus dem schönsten Design einen Flop zu machen. #
    10. 10. Worauf es ankommt • Gesteigerte Bedeutung des Entwicklungs-Lebenzyklus • Als Aspekt des Markterfolgs definieren • Software-Lieferkette managen • Software-Integration / -Oberflächen • Sicherheit und Datenschutz • Schutz proprietärer Daten und intellektuellem Eigentum • Datenschutz der Konsumenteninformationen • Time-to-Market und Anpassbarkeit - Druck auf bereits ausgelastete Entwicklungsteams und –organisationen - Reaktionszeiten auf Aktionen des Wettbewerbs und der Umwelt - Neue Technologien und Präferenzen der Konsumenten  Unbekanntes  Erwartungen nach Personalisierung • Schonungslos komplex - Simultanes revolutionäre Engineering  Mechnaische Systeme und Komponenten  Potential, Geräte und Technologieplattformen zu integrieren  App im/auf dem Auto installieren  Netzwerk-Verbindung #
    11. 11. Embedded Software Development Risk Analysis and Management Quality Systems System Requirements Design Requirements PLM ECO/HW Design Safety/Regulatory Standards Business Requirements Engineering Standards “Es geht nicht nur um Software”
    12. 12. Pragmatisch Agil – WaterSCRUMfall AGILE Embedded Systems- und Geräte-Trends • Traditionelles vs. V-Modell • Agile Epics, User Storys implementieren Anforderungen • Schnellere SW-Iterationen • Das Beste des “Agile Manifesto” einarbeiten • Herausforderungen: Globale Teams
    13. 13. Problem Projekt Silos Anforderungs Management Entwicklungs Release Management Qualitätssicherung Funktionale Sicherheit
    14. 14.  Sicherheits-Gefahrenanalyse und Risikoeinschätzung - ISO 26262-3  Item-Definition  Bestimmung von Gefahren und gefährlichen Ereignissen  ASIL- Bestimmung  Konzepte zur Funktionalen Sicherheit  Sicherheitsziele  Anforderungen an die Funktionale Sicherheit - Usability bei Anforderungen und Planung des Kfz - System-Zulieferer für ASIL-Level  FMEA Riskomanagement - sFMEA, dFMEA, pFMEA - Werkzeuge zur Gefahrenanalyse Die Lösung:
    15. 15. Typische Fragen • Wer hat Änderungen an der Gefahrenanalyse vorgenommen? • Wann wurden die Änderungen gemacht? • Was wird/ist getan, um Gefahren zu reduzieren? • Erfüllt die Verkettung von ASIL bis ISO 26262? • Abdeckung: Wurde mindestens eine Funktionale Sicherheitsanforderung für ein Sicherheitsziel definiert?
    16. 16. Varianten-Features
    17. 17. Evolution des Variantenmanagements
    18. 18. Die Lösung:  Feature-Modell - Organisation der Features - Repräsentiert als Polarion Work Items, Dokumente  Master-Spezifikationen (150%-Spezifikation) - Gemeinsame Anforderungen - Anforderungen an die Variabilität - Repräsentiert als Polarion Work Items, Dokumente  Varianten-Feature-Auswahl - Definiert Mass Customization - Automatisierte cErstellung von 100%-Spezifikationen - Repräsentiert als Polarion “Branched Documents”
    19. 19. Feature-Modell Variante wird als Auswahl an Features definiert
    20. 20. Varianten-Optionen
    21. 21. Spezifikations-Optionen Restriktionen • Einfache und komplexe Logik • Dynamisches Lesen von Features • Domain-Knowledge
    22. 22. 150% Specification 100%-Spezifikation Die Varianten-Spezifikationen • Requirements • Design • Qualität/Regulierungen • Tests
    23. 23. Webinaraufzeichnung ansehen
    24. 24. Thank you. www.polarion.com Thank you. www.polarion.com DANKE

    ×