Codequalität für autonome Fahralgorithmen gewährleisten

Die Entwicklung autonomer Fahrzeuge ist ein Wettrennen, daher müssen schnellstmöglich stabile Algorithmen für das autonome Fahren entwickelt werden. Dafür müssen Bug Fixes und neue Features so schnell wie möglich implementiert werden, aber ohne die Qualität aus den Augen zu verlieren. Wie kann das gerade in solch großen und komplexen Projekten gewährleistet werden? Die Antwort findet sich in einer skalierbaren „Continuous Integration“ und Continuous Delivery“ Pipeline. Hier erfahren Sie wie der Aufbau einer skalierfähigen Continuous Integration und Continuous Delivery Pipeline in OpenShift funktionieren kann.

Continuous Integration und Delivery – was ist das?

Continuous Integration oder kurz CI sorgt dafür, dass neu entwickelter Code zusammengeführt, getestet und dann in die Gesamtcodebasis eingefügt wird. CI soll die Zusammenarbeit der Entwickler vereinfachen und dabei helfen Fehler frühzeitig zu erkennen.

continous integration

Abbildung 1: So funktioniert Continuous Integration [1]

Mehrere Entwickler arbeiten an neuen Features oder Bug Fixes. Sobald einer von ihnen sein Arbeitspaket fertiggestellt hat, wird der Code committet und genau hier setzt CI dann ein. Sobald der Code gepusht wird, überprüft CI ob der neue Code sich nahtlos in die schon vorhandene Codebasis einfügen lässt. Anschließend startet ein automatischer Build, der dann aufzeigt ob der Code fehlerfrei gebaut werden kann oder ob es fehlschlägt. Schlägt der Build fehl, muss der Entwickler den Bug finden und beheben und den Prozess erneut starten. War der Build fehlerfrei, wird getestet und das entsprechende Ergebnis reportet.

Continuous Delivery oder kurz CD sorgt dafür, dass eine aktuelle Version der Software verfügbar gemacht wird. CD erweitert das CI Vorgehen um den Punkt „Release“ (Continuous Integration + Release = Continuous Delivery). Dabei wird die neue Codebasis auf eine Produktivumgebung implementiert, sodass die neuen Features dort getestet werden können.

Umsetzung mit OpenShift

CI/CD ist einer der beliebtesten Anwendungsfälle für die OpenShift Container Plattform. OpenShift stellt Container für den Bau von Continuous Delivery-Pipelines zur Verfügung. Dies ermöglicht es unter anderem Jenkins, viele Aufträge parallel auszuführen und beseitigt die Wartezeit für die Ausführung von Builds in großen Projekten. OpenShift bietet eine End-to-End-Lösung für den Aufbau kompletter Bereitstellungspipelines und ermöglicht die notwendige Automatisierung, die für die Verwaltung von Code- und Konfigurationsänderungen über die Pipeline erforderlich ist.

Dieses Beispiel zeigt eine CI/CD-Infrastruktur auf OpenShift:

Beispielhafter Aufbau einer CI oder CD-Infrastruktur auf OpenShift

Abbildung 2: Beispielhafter Aufbau einer CI/CD-Infrastruktur auf OpenShift (eigene Darstellung)

Einsatz in der Fahralgorithmen Entwicklung

Wenn ein neues Feature für den Algorithmus entwickelt wird, beispielsweise eine Erkennung von Ampeln, dann wird dieses Feature in einzelne Module aufgeteilt. Dies wird gemacht, da ein solches Feature meist zu groß ist, um es mit nur einem Team zu entwickeln oder es zu zeitintensiv ist, um es in einem Sprint fertigzustellen. Jedes dieser Module wird daher getrennt (pro Team/Sprint) entwickelt und jedes durchläuft einen CI Prozess. Dadurch durchläuft jede Teilentwicklung Unit- und Integrationstests, wodurch die Codequalität jedes Moduls und dadurch auch jedes Features steigt.

CI oder CD Prozess anhand der Entwicklung eines neuen Fahralgorithmen Features

Abbildung 3: CI/CD Prozess anhand der Entwicklung eines neuen Fahralgorithmen Features (eigene Darstellung)

Ein CD erfolgt meist zu einem Sprint Ende oder pro Feature. Zum Sprint Ende werden dann mehrere neu entwickelte Features auf die E2E Umgebung und schlussendlich auf PROD deployed (siehe Abbildung 4). Bei der zweiten Herangehensweise wird ein Feature, sobald es fertig ist, deployed (siehe Abbildung 3).

Continous Delivery bei der Entwicklung autonomer Fahrfunktionen
Abbildung 4: Continous Delivery bei der Entwicklung autonomer Fahrfunktionen (eigene Darstellung)

Fazit: Was bringen CI und CD, auch im Umfeld autonomes Fahren?

Die Umsetzung einer CI und CD bringt einige Vorteile mit sich:

  • Da neue Features und Bug Fixes schneller auf der E2E beziehungsweise auf Produktivumgebung sind, kann früher mit Testfahrzeugen unter realen Bedingungen getestet und das Feedback der Kunden eingeholt werden.
  • Die gesamte Entwicklungs- und Testzeit neuer Features ist schneller, was eine übergreifend schnellere Entwicklung des Fahralgorithmus bedeutet. Das wiederrum kann einen Wettbewerbsvorteil in der Automobilbranche bringen.
  • Bugs werden früher erkannt und können besser identifiziert werden, da man nach jedem Commit weiß ob der Build geklappt hat oder nicht.
  • Daraus folgt eine übergreifend höhere Code- und Softwarequalität, was gerade für autonome Fahrfunktionen besonders wichtig ist.

 

Wie die Cloud bei großen Datenmengen in der Testausführung von autonomen Fahrzeugen unterstützt erfahren Sie hier!

 


Quellen:

[1] https://cloud.google.com/solutions/continuous-integration/images/hero-banner.png

https://blog.openshift.com/cicd-with-openshift/

Git Logo: https://git-scm.com/images/logos/2color-lightbg@2x.png

Jenkins Logo: https://miro.medium.com/max/2100/1*LOFbTP2SxXcFpM_qTsUSuw.png

SonarQube Logo: https://www.sonarqube.org/images/logos/sonarqube-dark.png

OpenShift Logo: https://upload.wikimedia.org/wikipedia/commons/thumb/3/3a/OpenShift-LogoType.svg/1200px-OpenShift-LogoType.svg.png

Den Nutzen von Big Data auch ohne Big Data Technologien erreichen

Vor allem in mittelständischen Unternehmen gilt Big Data mitunter als eine Art „eierlegende Wollmilchsau“. Die Einschätzung „Heute macht man das halt mit BigData, Spark, SMACK-Stack, Hortonworks, in der Cloud mit AWS“ führt häufig zu sehr komplexen Lösungen mit hohen Anforderungen an die Hardware. Ein Aufwand, der in vielen Fällen aber gar nicht erforderlich wäre oder gar ungeeignete Lösungen bringt. Zumal die Kosten oft den Nutzen deutlich übersteigen. Vor diesem Hintergrund gerieten klassische Technologien wie relationale Datenbanken durch neue Technologien, Produkte und Paradigmen im Big Data Umfeld in den Hintergrund.

Davon ausgehend beleuchten wir nachfolgend klassische Technologien, die in der Literatur im Big Data Umfeld als nicht leistungsfähig eingestuft werden, hinsichtlich Skalierungsmöglichkeiten. Ziel ist es zu validieren, wie zum Beispiel auch mit relationalen Datenbanken der Nutzen von Big Data Instrumenten erreicht werden kann und ob es eindeutige Indikatoren dafür gibt, ab wann man tatsächlich sinnvollerweise auf Big Data Technologien setzen sollte.

Es muss nicht immer Big Data sein

Grundsätzlich gilt: Mit der Einführung von Big Data Technologien muss auch die IT-Infrastruktur angepasst werden, um die Anwendungen auch optimal betreiben zu können.

Eine solche Anpassung an Big Data Technologie ist vor allem dann notwendig, wenn es darum geht, semistrukturierte oder unstrukturierte Daten zu analysieren. Klassische Technologien wie relationale Datenbanken sind hier durch ihre technischen Restriktionen weniger geeignet, denn mit diesen kann nur auf strukturierten Daten direkt gearbeitet werden.

Liegen allerdings bereits strukturierte Daten vor, muss es nicht zwingend eine Big Data Technologie sein. Hier sollte man zunächst anhand des Anwendungsfalls bewerten, ob eine Optimierung der bestehenden Technologie oder eine Anpassung der Fragestellung ausreichend ist. Möglicherweise genügt eine Ja/Nein Entscheidung anstatt der exakten Berechnung mit feingranularer Wahrscheinlichkeitsrechnung.

3-V Model als Indikator für Big Data

Eine eindeutige Einstufung, ab wann Big Data Technologien eingesetzt werden sollten, existiert nicht. Allerdings ist es anhand des sogenannten 3-V-Modells möglich zu erkennen, ob der Einsatz von Big Data Technologien hilfreich wäre.

Die Metriken Datenvolumen, -geschwindigkeit und -vielfalt

(Quelle: https://gi.de/informatiklexikon/big-data/)

Die Metriken Datenvolumen, -geschwindigkeit und -vielfalt charakterisieren die Anforderungen für einen Anwendungsfall. Je nach Ausprägung der drei Eigenschaften lässt sich abschätzen, ob moderne Technologien eingesetzt werden sollten.

Liegen in mehreren Datenbereichen die höchsten beziehungsweise zweithöchsten Anforderungen vor (äußerster und zweiter Ring von außen), ist der Einsatz moderner Technologien bzw. Big Data sinnvoll. Stellen hingegen nur einzelne Anforderungen in einem Bereich hohe Anforderungen (zum Beispiel „besonders schnell, aber kein hohes Datenvolumen“, oder „sehr hohes Datenvolumen per Batchjobs“), muss jeder Anwendungsfall individuell beurteilt werden, ob sich Big Data Technologien anbieten oder ob es bessert ist, klassische Technologien zu optimieren.

Optimierungsmöglichkeiten von klassischen Technologien

Best Practices um Skalierungspotenziale relationaler Datenbanken auszuschöpfen:

  • Grundsätzlich sind die Daten in relationalen Systemen unsortiert, aufgrund dessen kann das Anlegen von Indizes zu schnelleren Zugriffszeiten führen.
  • Das Verlagern von Teilrelationen in den Arbeitsspeicher kann zur schnelleren Verarbeitung der Daten führen, da die Daten nicht mehr zwischen Arbeitsspeicher und Festplattenspeicher übertragen werden.
  • Das Erstellen von Partitionen und Replikationen führt zu parallelen oder einzelnen Zugriffen auf verschiedene Teilrelationen einer Datenbank. Dadurch ist eine parallele Verarbeitung gewährleistet, oder es werden nur relevante Daten einer Relation zur Analyse verwendet.
  • Das Einrichten einer Master-Slave-Architektur orientiert sich am verteilten Datenmanagement, das auch Hadoop verwendet. Dadurch können Datensätze auf unterschiedlichen Servern verteilt und parallele Analysen durchgeführt werden, indem die Last einer Anfrage aufgeteilt wird.
  • Für die „Vorverarbeitung“ der Daten und zur späteren Präsentation der Ergebnisse lassen sich materialisierte Sichten verwenden, um Zeit zu sparen.

 

Fazit:

Big Data Technologien können in vielen Situationen eine Lösung bieten, die ohne diese nicht möglich gewesen wäre. Die Entscheidung zum Einsatz solcher Technologien muss aber gut überlegt sein, denn der Einsatz ist kostspielig und aufwändig. Das 3-V-Modell kann helfen zu entscheiden, ob nicht auch schlankere und damit günstigere Ansätze ebenso zum Ziel führen können.

Co-Autor Bartu Uysal

 

Mehr zu Datenintegration gibt’s hier

It’s #FrontendFriday – Klassen / Modul-Diagramme in Frontend-Projekten

Hallo #FrontendFriday-Leser/in,

heute geht es um Tools, die Klassendiagramme aus Frontend-Projekten (speziell TypeScript, Angular) generieren.

Zu Beginn eines Projekt wird eine Architektur der Anwendung erstellt (die sich im Laufe des Projekts weiterentwickelt). Während des Projekts stellt sich die Frage, ob die geplante Soll-Architektur mit der tatsächlich umgesetzten Architektur übereinstimmt. Hierzu können unter anderem Klassendiagramme helfen, die automatisch aus dem entwickelten Code generiert werden.

Tools

Liste der getesteten Tools. Die Tools, sind verlinkt. Dort finden sich auch Beispiel-Diagramme.

  1. IntelliJ nur in Ultimate verfügbar. Testklassen (.spec.ts) können nicht exkludiert werden.
  2. NGD Generiert sehr breite Bilder. Das Dokumentationstool compodoc verwendet diese Library zur Darstellung einzelner Module.
  3. ngrev Eigenständige Applikation mit UI. Wird von einem Entwickler vom Angular Team entwickelt.
  4. tplant Generiert PlantUML Diagramme, aber ohne direkten Angular-Projekt Support.
  5. tsviz Generiert sehr breite, unübersichtliche Bilder.
  6. vscode-ts-uml Plugin für VS-Code, analysiert nur einzelne Dateien, kann keine Übersicht über ein Projekt erstellen.
  7. TsUML Sendet den Quellcode an einen Onlinedienst, der Klassendiagramme generiert.

 
Die Tools sind nach Empfehlung geordnet.

Fazit

Mehrere, auch kostenpflichtige Tools, wurden getestet. Ein ganz zufriedenstellendes Ergebnis konnte bisher keines liefern. Für einen schnellen Überlick kann dies aber reichen.
Für andere Programmiersprachen (z.B. Java) sind ausgereiftere Tools verfügbar. Sind euch bessere Möglichkeiten bekannt?

Oerlikon Hackathon powered by doubleSlash Experten

Am Wochenende des 08.11.2019 bis 10.11.2019 hat doubleSlash eine tolle Veranstaltung als Experten begleiten dürfen: Den ersten Hackathon der Oerlikon Group in toller Atmosphäre des Oerlikon Digital Hub. Neben Workshop Räumen und sogar einem Kino ist das technische Setup exzellent und erleichterte allen Teilnehmern die Arbeit.

Hackathon? Pures Wissen in agiler Lösungskompetenz

Pragmatisch und agil in einem: Ziel ist es, innerhalb der Dauer einer Hackathon Veranstaltung gemeinsam nützliche, kreative oder unterhaltsame IT – oder Software Produkte oder –Anwendungen herzustellen und so Lösungen für bestehende Probleme zu finden.

Ein breiter Mix an talentierten Personen

Die Zielgruppe des Events war ein sehr breiter Mix an talentierten Personen: von Softwareentwicklern über Data Scientists bis hin zu Spezialisten der Industrie. Die rund 80 Teilnehmer setzten sich zusammen aus Studenten, Softwareentwicklern bis hin zu Data Scientists und Oerlikon Mitarbeiter.

Die Challenges waren in 4 Kategorien aufgeteilt: IoT, Computer Vision, Data Science und Waste Reduction – wobei die letzte Kategorie sich wohl auch in die Data Science Aufgaben einsortieren lässt. Unter diesen Kategorien gab es je bis zu zwei Challenges – in Summe 7 Challenges. Für jede Challenge konnten sich nur eine definierte Zahl Teams anmelden, um sicher zu stellen, dass alle Challenges angegangen wurden.

Fünf doubleSlash IoT und KI Experten vor Ort

Auf Anfrage von Oerlikon beschloss doubleSlash das Event als Sponsor in Form von fünf Experten zur Unterstützung der Teilnehmer zu stärken: Vincenzo Crimi, Nico Mutter, Andreas Nuber, Timo Demler und Ralf Richter. Wir gaben Hilfestellung in den Bereichen Consulting, Coding, Architektur, technischer Spezialisierung mit PTC und Microsoft Azure, aber auch im Bereich Organisation und Strukturierung. Unsere Experten standen den Teams zur Seite, indem sie sie berieten und bei der Entwicklung weiterhalfen, ohne dabei Einfluss auf den Lösungsweg zu nehmen.

Gemeinsam mit unserem Partner PTC beschlossen wir bereits zu Beginn des Hackathons, unsere gewohnte enge Zusammenarbeit für den Support an den Teams zu leisten. Neben dem Mentoring für die Teams lieferten wir zwei tolle Workshops in den Bereichen Ideation und Pitch Training. Beide Workshops wurden ein toller Erfolg und leisteten einen wertvollen Beitrag für das Gelingen des Hackathon.

 

 

 

 

 

Fazit

Das Engagement unserer Experten für die Teams war beachtlich und ging über die Grenzen eines normalen Arbeitstages hinaus. Alle Teilnehmerteams schätzten diesen Support  spürbar, auch während der Pitches kam positives Feedback. Wir haben auch in anderen Formaten sehr positive Erfahrungen mit diesem agilen Veranstaltungsformat gemacht und sehen hier den deutlichen Mehrwert: Schwarmintelligenz in agiler Atmosphäre schafft gemeinsam innovative Lösungen zu konkreten Problemen.
Besonders stolz sind wir darauf, dass alle Teams, die von der doubleSlash Hilfe aktiv Gebrauch machten, in die Finals kamen. Besonders freuen wir uns über den Erfolg unseres doubleSlash-Studenten-Teams: Sie haben von 17 Teams einen sehr guten Platz 4 erarbeitet. Wir freuen uns auf kommende Events, die wir als doubleSlash begleiten können oder sogar selbst ausrichten werden.

 


Mehr zur KI und IoT Kompetenz von doubleSlash

Mehr zum Oerlikon Digital Hub

Vendor Lock-In in der Cloud richtig erkennen

Besitzen Sie mehrere Apple-Produkte? Dann können Sie nicht einfach auf ein Samsung Smartphone umsteigen, da Ihnen so die Kompatibilität zu Ihrer Apple Watch verloren ginge. Sie müssten sich zusätzlich noch eine andere Smartwatch zulegen, die mit Ihrem neuen Smartphone kompatibel ist. Selbst wenn Sie gerne also ein Samsung Smartphone hätten, der komplette Umstieg auf eine andere Marke wäre teuer. Hindern Sie die abzusehenden Kosten an einem solchen Umstieg und Sie bleiben deshalb bei Ihrem iPhone, hat Apple Sie „eingelockt“ – man spricht hier auch von „Vendor Lock-In“. Wir zeigen Ihnen was Vendor Lock-In ist und wie Sie es richtig erkennen.

Vendor Lock-In ist die Abhängigkeit eines Anwenders/ Kunden/ Nutzers bezüglich eines oder mehrerer Produkte oder Services von einem bestimmten Hersteller. Diese Abhängigkeit entsteht dadurch, dass ein Wechsel zu einem alternativen Anbieter

  • aufgrund mangelnder Alternativen (z.B. fehlender Funktionen) nicht möglich oder
  • aufgrund zu hoher Transaktionskosten unwirtschaftlich ist.

Das klingt zunächst nach etwas, womit wir uns nur selten befassen müssen. Aber weit gefehlt – Vendor Lock-In kann nicht nur in unserem Alltag auftreten, sondern auch in der Cloud. Wie entsteht ein solcher Vendor Lock-In und wie können Sie ihn erkennen?

Vendor Lock-In der Cloud – was ist das?

Ein Vendor Lock-In in der Cloud entsteht dann, wenn die Kosten für eine Migration höher sind als ihr Nutzen.¹ Haben Sie sich für einen bestimmten Cloud-Anbieter entschieden, kann es verschiedene Gründe geben, dass ein Umstieg zu einem anderen Cloud-Anbieter – sollte dieser gewünscht oder notwendig sein – so teuer ist, dass diese Kosten die Vorteile der Migration überwiegen. Im Rahmen meiner Thesis habe ich ein Vorgehen entwickelt, um einen möglichen Vendor Lock-In in der Cloud frühzeitig erkennen und ihm vorbeugen zu können.

Vendor Lock-In am Beispiel von Serverless-Plattformen

Wie ein Vendor Lock-In in der Cloud entstehen kann, lässt sich sehr gut anhand verschiedener Serverless Plattformen zeigen. AWS Lambda und Google Cloud Functions ermöglichen beispielsweise beide das Erstellen von Functions. Functions sind in ihrer Funktion abgeschlossene Code-Einheiten, die bei Bedarf automatisiert ausgeführt werden. Vergleicht man AWS Lambda² mit Google Cloud Functions³, so fällt zunächst auf, dass nicht unbedingt die gleichen Programmiersprachen und Laufzeitumgebungen verwendet werden können. Von beiden Umgebungen werden Node.js, Python und Go unterstützt, seitens AWS Lambda zudem noch Java, C# und Ruby. Wurden nun Functions für AWS Lambda in Java erstellt, können diese nicht für die Google Cloud übernommen werden, da hier keine Java Functions unterstützt werden.

Weiterhin werden in den verschiedenen Cloud-Plattformen verschiedene proprietäre Bibliotheken verwendet. Eine Bibliothek ist eine vorgefertigte Sammlung von Programmcode, der für bestimmte Aufgaben eingesetzt werden kann. Für die betrachteten Plattformen gibt es zum Beispiel die folgenden Bibliotheken:

  • AWS – aws-lambda-java-core: Diese Bibliothek enthält unter anderem das Lambda-Context-Objekt, über das mit der AWS Lambda-Ausführungsumgebung interagiert wird.4
  • Azure – com.microsoft.azure.functions: Diese Bibliothek enthält unter anderem den ExecutionContext, durch den mit der Azure Functions-Ausführungsumgebung interagiert wird.5

Functions können also nicht immer einfach von einer Cloud in die andere übernommen werden, sondern müssen vorher möglicherweise angepasst oder komplett neu geschrieben werden.

Für ein paar Functions ist dies vielleicht kein großer Aufwand. Denken Sie jedoch daran, dass Ihre Anwendung vermutlich nicht ausschließlich aus Functions besteht. Sie müssen beispielsweise auch folgende Punkte genauer betrachten:

  • Sind Ihre Daten kompatibel mit der Zieldatenbank in der neuen Cloud?
  • Wie viel kostet der Export der Daten?
  • Was muss in der Anwendung angepasst werden, um proprietäre Cloud-Schnittstellen unterstützen zu können?
  • Und sind die benötigten Funktionalitäten überhaupt in der neuen Cloud verfügbar?

 

Vendor Lock-In richtig erkennen

Die Summe all dieser verschiedener Lock-In-Gefahren ist es, die am Ende einen Vendor Lock-In ausmachen können. Aus diesem Grund beschäftigte sich meine Thesis mit der Entwicklung einer Möglichkeit, einen Vendor Lock-In zu erkennen. Damit noch darauf reagiert werden kann, muss dies möglichst vor der Migration in eine Cloud oder vor der Neuentwicklung eines Cloud-Services geschehen.

Wie bereits erwähnt entsteht ein Vendor Lock-In dann, wenn die Kosten für eine Migration ihren Nutzen übersteigen. Es müssen also sowohl die Kosten einer Migration als auch ihr Nutzen identifiziert werden, um einen Vendor Lock-In erkennen zu können.

Da der tatsächliche Nutzen einer Migration erst in der Zukunft deutlich werden würde und somit nicht vorhersehbar ist, muss hierfür eine alternative Zahl herangezogen werden. Deshalb wird der Nutzen betrachtet, der bei der Wahl eines bestimmten (anstatt eines bestimmten anderen) Cloud-Anbieters entsteht. Beispielhaft ist dies hier mit fiktiven Zahlen zu sehen:

 

Berechnung eines Vendor Lock-Ins
Abbildung: Beispiel für die Berechnung eines Vendor Lock-Ins (anhand fiktiver Zahlen)

Im Beispiel fällt die Entscheidung auf die Cloud A. Betrachtet werden die Erstellungskosten, bei denen zunächst gegenüber der Wahl von Cloud B ein Nutzen von 10.000€ entsteht. Durch die günstigeren Nutzungskosten in einem bestimmten Betrachtungszeitraum entsteht hier außerdem ein Nutzen von zusätzlich 5.000€. Der Nutzen im Betrachtungszeitraum insgesamt liegt also bei 15.000€. Diesem muss man jedoch die zu erwartenden Migrationskosten gegenüberstellen, im Beispiel 30.000€. Da der Nutzen dann negativ wird, entstünde hier ein Vendor Lock-In.

 

Fazit:

Letztendlich besteht jedoch auch hier das Problem, dass sich in der Zukunft die Nutzungskosten und die zu erwartenden Migrationskosten verändern können. Entweder wird so eventuell ein Vendor Lock-In vorausgesagt, der dann doch nicht entsteht, oder ein Vendor Lock-In tritt wider Erwarten doch auf. Es kann also keine genaue, durch Zahlen belegte Aussage getroffen werden, ob bei einem Cloud-Anbieter mit Sicherheit ein Vendor Lock-In auftreten wird.

Trotzdem können die identifizierten Migrationskosten zumindest als Einschätzung herangezogen werden, an welchen Stellen in einer Cloud-Anwendung ein Vendor Lock-In entstehen könnte. In Verbindung mit Expertenwissen kann so eingeschätzt werden, ob einem möglichen Lock-In entgegengewirkt werden sollte und welche Maßnahmen hierzu herangezogen werden können.


Quellen:

1 angelehnt an: Justice Opara-Martins, Reza Sahandi und Feng Tian. „A Holistic Decision Framework to Avoid Vendor Lock-in for Cloud SaaS Migration. In: Computer and Information Science 10 (Juli 2017), S. 29. issn: 1913-8989. doi: 10.5539/cis.v10n3p29. (S.30)

2 https://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html

3 https://cloud.google.com/functions/docs/writing

4 https://docs.aws.amazon.com/de_de/lambda/latest/dg/java-programming-model.html

5 https://docs.microsoft.com/en-us/java/api/com.microsoft.azure.functions.executioncontext?view=azure-java-stable

 

Agiles Anforderungsmanagement: die wesentlichen Kernelemente für erfolgreiche IT-Projekte

Immer häufiger werden IT-Lösungen nach dem Lean-Start-Up Prinzip realisiert. Beginnend mit der initialen Entwicklung eines, auf die Kernfunktionen fokussierten Produktes zum Markteinstieg („Minimal Viable Product – MVP“), wird das Produkt nach dem Go-Live durch direktes Marktfeedback, weiterentwickelt und optimiert.

Das erfordert ein entsprechendes Umdenken, auch im Anforderungsmanagement. Was sind die wesentlichen Kernelemente, die beim agilen Anforderungsmanagement über Erfolg und Misserfolg eines Softwareprojektes entscheiden?

Eine Frage auf die es vermutlich viele verschiedene Antworten gibt. In folgendem Blogbeitrag wollen wir uns dem Thema auf den drei Ebenen „Prozess“, „Tooling“ und „Mindset“ annähern und praxisnah darauf eingehen, wie agiles Anforderungsmanagement in diesen Bereichen jeweils Beachtung finden kann. Die Inhalte stammen größtenteils aus unserem Vortrag, den wir auf der ModernRE 2019 in Berlin gehalten haben.

Der Prozess: Von der Idee zur spezifizierten Anforderung

In einem Projekt liegt die thematische Verantwortung beim Fachbereich. Daher erstellt und aktualisiert dieser regelmäßig die Vision des Produkts – das Zielbild. Anhand dieser Vision werden viele Ideen abgeleitet um dieses Zielbild zu erreichen.

Die technische Verantwortung liegt wiederum beim IT Team. Das IT Team hat eine etwas andere Perspektive auf das Produkt und daher auch andere Ideen, als der Fachbereich, Im besten Falle ergänzen sich die Sichtweisen der IT mit der des Fachbereiches.

Von der Idee zur spezifizierten Anforderung
Abbildung: Von der Idee zur spezifizierten Anforderung

Eine Besonderheit ist es, dass alle Teammitglieder dazu aufgerufen sind ihre Ideen an einen eigens hierfür eingerichteten Bereich, dem sogenannten Ideen-Backlog, einzutragen und zu detaillieren. Ideen kommen dabei von einzelnen Teammitgliedern, die Verbesserungs- und Optimierungspotenziale erkannt haben, von externen Studien, in Form von direktem Feedback von Kunden, oder Dritten aus dem Markt.

In regelmäßigen Abständen findet durch den Fachbereich eine Begutachtung aller neuer Ideen aus dem Ideen-Backlog statt. Bei der inhaltlichen Prüfung der Ideen wird der bereits priorisierte Backlog betrachtet, sodass neue Ideen, die weiterverfolgt werden sollen, direkt priorisiert werden können. Auf diese Weise ist sichergestellt, dass immer die Idee als nächstes im Detail spezifiziert wird, die den größten Nutzen für Dritte und Kunden stiftet oder die größte Relevanz für das Produkt hat.

In der Spezifikation werden die Themen detailliert und im Sinne des Anforderungsmanagements spezifiziert. Es müssen beispielsweise Stakeholder ermittelt werden, die in einem Kick-off-Termin in das Vorhaben eingeweiht werden. Erste Erkenntnisse und Anforderungen werden notiert und grafisch in Form von Wireframes, Mockups oder mittels eines passenden Diagrammtyps aufbereitet. Ein Spezifikationstemplate hilft, wiederkehrende Fragen und Sachverhalte standardisiert zu betrachten und so keine wichtigen Aspekte zu vergessen. Klassische Ansätze kommen an dieser Stelle ebenfalls zum Tragen. Anforderungen müssen erhoben, analysiert, spezifiziert und validiert werden.

Nach jeder Spezifiaktionsphase steht das Review der fertigen Spezifikation an. Für das Review wird ein Teilnehmerkreis, bestehend aus dem Fachbereich und einem dedizierten IT-Ansprechpartner, dazu eingeladen, Feedback zur Spezifikation abzugeben. Um technische Risiken und die Umsetzbarkeit zu prüfen, sollte eng mit dem IT Team zusammen gearbeitet werden. Zusätzlich nehmen Kollegen aus der IT einen anderen Betrachtungswinkel ein und decken so zum Beispiel häufig noch nicht betrachtete Randfälle auf. Am Ende eines definierten Zeitraums ist es die Aufgabe des Autors, das Feedback zu konsolidieren, zu sichten und in die Spezifikation einzuarbeiten.

Am Ende steht eine finale Version der Spezifikation (v1.0), die sowohl vom Fachbereich, als auch vom IT Team gleichermaßen mitgetragen wird. Prozessual wird die fertige Fachspezifikation im IT-Refinement vom Fachbereich an das IT Team übergeben, Letzte Zusammenhänge werden betrachtet und ein einheitliches Verständnis hergestellt. Anschließend werden aus der Spezifikation User Stories für das Product Backlog der Software Entwicklung abgeleitet, definiert, priorisiert und detailliert.

Tooling in einer kollaborativen & verteilten Arbeitswelt

Ein toller Prozess allein reicht nicht aus! Es sind Tools notwendig, die diesen kollaborativen Ansatz ermöglichen und unterstützen. Zumeist werden zwei Tools in Kombination, beispielthaft JIRA und Confluence aus der Atlassian Suite, eingesetzt, um diesen Prozess abbilden zu können.

In einem Ticketingtool (Abbildung: Requirements Board im Ticketingtool) wird ein Kanban Board erstellt. Dort werden sämtliche Prozessschritte abgebildet, um den Überblick über alle Themen im Prozess zu behalten. Die Tickets im Status „Ready for Specification“ stellen den bereits priorisierten Backlog dar, der aus dem Ideen-Backlog gespeist wird. Ideen, die keine Relevanz für das Produkt liefern, werden hier schon gar nicht mehr berücksichtigt. Themen, die sich momentan in der Bearbeitung befinden – sei es in der Erstellung der Spezifikation („In Specification„) oder im Review („In Review„) – werden per Drag-and-Drop in den entsprechenden Status gezogen. Durch die Verlinkung des Tickets zur Spezifikation besteht die Möglichkeit, in einem Klick vom Ticketingtool zum Kollaborationstool (Erklärung im nachfolgenden Absatz) zu springen. In die entgegengesetzte Richtung ist dies ebenso möglich. Auf diese Weise werden unnötige Tool- und Systembrüche vermieden und Arbeitsabläufe effizienter gestaltet. Aus Fachbereichssicht ist eine Spezifikation, nach dem das Review beendet wurde, mit der Übergabe an das IT Team („Handover to IT„) fertiggestellt. Um eine vollständige Dokumentation zu gewährleisten, ist es notwendig, dass diese um die umgesetzten Funktionserweiterungen ergänzt wird („Documentation done„). Erst jetzt ist der Zeitpunkt erreicht, an dem man guten Gewissens von einer umgesetzten Anforderung sprechen kann.

Requirements Board im Ticketingtool
Abbildung: Requirements Board im Ticketingtool

In einem Kollaborationstool findet die Dokumentation der Spezifikation und das Review statt. Zwischen den beiden Tools sind Verlinkungen der entsprechen Tickets und Spezifikationen möglich, um so direkt vom einen in den anderen Bereich springen zu können. Zusätzlich lassen sich Workshops ebenfalls im Kollaborationstool dokumentieren und als Entscheidungsprotokolle direkt in die Spezifikation verlinken. Durch zahlreiche Add-ons kann der Funktionsumfang eines Kollaborationstools sehr individuell auf die Bedürfnisse im Projekt und Prozess angepasst werden. So können beispielsweise Wireframes direkt im Kollaborationstool selbst erstellt und bearbeitet werden.

Der wohl größte Vorteil durch den Einsatz eines Kollaborationstools ergibt sich bei der Durchführung des Reviews einer Spezifikation. Vor dem Umzug in der Spezifikation in das Kollaborationstool wurde das Review anhand eines Word-Dokuments durchgeführt, wodurch je Review-Teilnehmer eine Version des Dokuments auf dem Fileserver abgelegt wurde. Die Aufgabe des Requirements Engineers bestand daraus, das Feedback zu konsolidieren und in die Spezifikation einzuarbeiten. Bei doppelten oder gar widersprüchlichen Kommentaren in den unterschiedlichen Review-Dokumenten führte das zu erhöhtem Abstimmungs- und Klärungsaufwand mit den entsprechenden Review-Teilnehmern. Durch den Umzug in das Kollaborationstool kann nun auf die vollen Funktionsumfänge zur Unterstützung und Verbesserung der Kollaboration unter den Review-Teilnehmern und des Requirements Engineers zurückgegriffen werden. Die Inline-Kommentarfunktion (Abbildung: Spezifikation und Review im Kollaborationstool) bietet die Möglichkeit, dass jeder Review-Teilnehmer durch Markieren einer Textstelle einen Kommentar platzieren kann, welcher für alle anderen Review-Teilnehmer sichtbar ist. Auf diese Weise werden Dopplungen vermieden, es entstehen Diskussionen, die neue Themen aufwerfen oder etwaige Rückfragen direkt klären. Für den Requirements Engineer verringert sich der Konsolidierungsaufwand des Review-Feedbacks signifikant, da nun mehr alle Kommentare in einem Dokument zu finden sind, Dopplungen und Widersprüche leichter zu identifizieren und aufzulösen sind.

Spezifikation und Review im Kollaborationstool

Abbildung: Spezifikation und Review im Kollaborationstool

Am Ende eines jeden Reviews sind alle Teilnehmer dazu aufgefordert, zu bestätigen, dass das Review beendet wurde und anzugeben, ob eine weitere Abstimmung mit dem Autor der Spezifikation gewünscht wird.

Review Log am Ende jeder Spezifikation

Abbildung: Review Log am Ende jeder Spezifikation

Mindset

Damit ein Projekt erfolgreich abgeschlossen werden kann, benötigt es mehr als funktionierende Prozesse und moderne Tools. Häufig wird ein wichtiges Kernelement übersehen: Das Mindset. Nur wenn die Menschen im Projekt kooperativ und auf das Projektziel ausgerichtet arbeiten, greifen die Prozesse und Tools effektiv ineinander. Heutzutage stoßen wir in Projekten jedoch häufig auf sogenannte Silos (z.B. bei verschiedenen Abteilungen innerhalb eines Konzerns), die das Zusammenarbeiten erschweren können. Silos verfolgen im schlechtesten Falle eigene Ziele, welche auf den ersten Blick nicht immer mit den Zielen des aktuellen Projekts übereinstimmen.

Georg Jocham, Coach für Projektmanager und Führungskräfte, greift in einem seiner Podcasts zum Thema „Silos“, auf eine im Jahre 2005 durchgeführte Studie zurück. Hier zeigte der Sozialpsychologe Mark Levin, welchen negativen Einfluss Silodenken auf das Kooperationsverhalten über die eigene Gruppe hinaus haben kann. Dazu werden Fußballfans von Manchester United zu Beginn des Versuchs Fragen im Themenumfeld rund um ihren Verein gestellt. Anschließend kann beobachtet werden, dass die Hilfsbereitschaft unter den Teilnehmern gegenüber anderen Manchester Fans um ein Vielfaches höher ist, als gegenüber Fans eines rivalisierenden Vereins. Beim zweiten Teil der Studie werden weitere Manchester United Fans eingeladen. Nun wird mit Hilfe einer anfänglichen Umfrage jedoch der Fokus nicht auf den Verein gelegt, sondern auf die gesamte englische Liga. Interessanterweise ist die im Anschluss beobachtete Hilfsbereitschaft gegenüber Menschen, die dem rivalisierenden Verein angehören massiv gestiegen ist. Sie erreicht dabei fast dasselbe Niveau wie die Kooperation den eigenen Vereinskollegen gegenüber.

Die Studie zeigt wie eklatant sich das Kooperationsverhalten unterscheidet: Je nachdem welcher Gruppe sich Menschen zum aktuellen Zeitpunkt zugehörig fühlen und ob deren Gegenüber ebenfalls Teil dieser Gruppe ist oder nicht. Die Studie zeigt neben den Gefahren die Silos bergen können, bereits eine mögliche Lösung, um aus dem Dilemma zu entkommen. Menschen, die in einem Projekt über verschiedene Abteilungen oder Firmen zusammenarbeiten, benötigen eine gemeinsame Projektidentität. Diese muss möglichst früh im Projekt etabliert werden, z. B. durch Vermittelung des gemeinsamen Projektziels im gemeinsamen Kick-off zu Beginn des Projekts.
Ist eine Projektidentität geschaffen muss sichergestellt werden, dass diese Bestand hat. Innerhalb dieses Projektteams haben sich zwei grundlegende Werte herausgeprägt die für den Zusammenhalt und eine funktionierende Zusammenarbeit innerhalb der Gruppe von großer Bedeutung sind: Wertschätzung und Vertrauen.

Ein wertschätzender Umgang im Projekt kann sich auf vielseitige Art und Weise äußern. So ist es zum Beispiel wertschätzend, andere nach Ihrer Meinung zu fragen oder sich für geleistete Arbeit zu bedanken. Eine hohe Wertschätzung im Projekt kann dazu führen, dass das Team eine höhere Loyalität dem Projekterfolg gegenüber zeigt.
Auch ein hohes Maß an Vertrauen spielt eine nicht unwesentliche Rolle, ob ein Team die gemeinsam etablierten Prozesse und Tools optimal nutzen kann. Dazu muss sichergestellt werden, dass jeder Beteiligte sich darauf verlassen kann, dass das gesamte Team auf den Projekterfolg ausgerichtet ist und somit auch das Ansprechen von Risiken, Fehlern und auch das Einbringen der eigenen Meinung als einen Beitrag zu diesem angesehen werden. In Projekten in denen ein hohes Maß an Vertrauen herrscht, steigt die Transparenz und die Berührungsängste in fachlichen Diskussionen und im schriftlichen Austausch nehmen stark ab. Es geht wieder mehr um die Sache. Insbesondere Transparenz ist in agilen Frameworks, wie zum Beispiel Scrum, eine wesentliche Grundvoraussetzung.

Wertschätzung und Vertrauen im Projekt

Abbildung: Wertschätzung und Vertrauen im Projekt

Fazit

Jedes der drei obigen Themen würde mehr als einen eigenen Vortrag füllen. Das hat sich unter anderem auch in der Agenda der diesjährigen ModernRE 2019 gezeigt. So wurden auf der Konferenz eigene Vorträge zum Einsatz einzelner Tools im Anforderungsprozess und zum Zusammenspiel von Ticketing- und Kollaborationstools gehalten. Auch auf das Thema Mindset wurde in einem spannenden Vortrag mit dem Titel „Wie Teams wirklich Stark werden“ eingegangen.
Auch wenn die Rahmenbedingungen in IT-Projekten sehr unterschiedlich sind, so lohnt es sich doch von Zeit zu Zeit den eigenen agilen Anforderungsprozess unter die Lupe zu nehmen und bei Bedarf zu Überarbeiten. Besonders leicht fällt das, wenn man mit Tools arbeitet, die hier die notwendige Flexibilität mitbringen.

Wovon mit Sicherheit alle Projekte profitieren, unabhängig der Rahmenbedingung, ist ein wertschätzender und vertrauensvoller Umgang innerhalb eines gemeinsamen Projektziels.

Co-Autor Findan Eisenhut

 


Weiterführende Links

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Kundenzufriedenheit durch Erfüllung von Anforderungen – das Kano-Modell

 

Mehr zur Anforderungsanalyse für Softwareprojekte gibt’s hier

 

Mit der Cloud vielfältige Fahrszenarien lernen – Wie die Cloud bei großen Datenmengen in der Testausführung von autonomen Fahrzeugen unterstützt

Jeder spricht darüber und alle großen Automobilhersteller entwickeln es – das autonome Fahrzeug. Doch wie „lernt“ ein Fahrzeug, selbständig zu fahren und mit der Flut an Datenmengen (Szenarien, Sensoren etc.) umzugehen? Wir zeigen Ihnen, warum die Cloud einen großen Teil dazu beiträgt und wie der Nutzen der skalierbaren Cloud für die Verarbeitung großer Datenmengen durch Function as a Service (FaaS) entsteht.

Vorsicht Fahranfänger – Wie Fahrzeuge mit riesigen Datenmengen umgehen lernen?

Genauso wie wir Menschen das Fahren lernen – mit Übung. Je mehr Kilometer wir fahren, desto sicherer werden wir im Straßenverkehr. „Learning by doing“ ist hier das Stichwort. Fahrzeuge tun das mit Hilfe von Sensoren, Rechenkapazität und dem Einsatz künstlicher Intelligenz (KI). Die Sensoren überwachen pausenlos umliegenden Gebäude, Fußgängerwege, Verkehrsteilnehmer und andere Personen. Die Rechner verarbeiten diese gewaltige Datenflut mit Hilfe von Algorithmen. Diese interpretieren dann die Daten und schaffen so ein Bild der Umgebung des Fahrzeugs und reagieren darauf.

Sensoren autonomes Fahren

 

 

 

 

 

 

 

 

 

 

( zu sehen 09:36 How a driverless car sees the road Quelle: YouTube)

Sensoren und KI autonomes Fahren

 

 

 

 

 

 

 

 

 

 

(09:44 How a driverless car sees the road Quelle: YouTube)

Über das maschinelle Lernen tasten sich die Systeme immer mehr an komplizierte Situationen im Straßenverkehr heran. Die Königsdisziplin ist der Arc de Triomphe in Paris – eine Herausforderung für den normalen Autofahrer und eine enorme Herausforderung für ein autonomes Fahrzeug – auch im Hinblick der in dieser Situation zu meisternden Datenmengen.

KI Algorithmen werden mit Hilfe großer Datenmengen trainiert, damit sie Verkehrssituationen richtig interpretieren, vor allem aber korrekt darauf reagieren können. Dafür werden viele Millionen gefahrene Testkilometer benötigt. Aber vor der Quantität steht die Qualität, denn bei perfekten Bedingungen kann jeder fahren. Ein leistungsstarker Algorithmus muss mit Extremsituationen umgehen können, weshalb er gerade diese lernen muss. Doch wie bringt man ein Fahrzeug kontrolliert in teilweise gefährliche Extremsituationen?

Simulieren statt Probieren

Die enorme Anzahl an zu fahrenden Testkilometern und das Testen gefährlicher Extremsituationen, kann während der Entwicklung eines Algorithmus nicht geliefert werden. Denn nach jeder Änderung an diesen Algorithmen müssten diese Testkilometererneut gefahren werden. Um dieses Problem zu lösen, wird ein Großteil der Testkilometer virtuell per Simulation zurückgelegt. BMW spricht davon, dass „rund 95% der Testkilometer per Simulation absolviert werden“, so Martin Peller [1], Leiter der Fahrsimulation bei BMW. Diese Simulationen können nun entweder in der Cloud oder OnPremise betrieben werden.

Hoch performante Cloud-Anwendungen als Basis

Die Cloud bietet eine Vielzahl von Vorteilen gegenüber einer On-Premise (Vor Ort) Lösung:

  • Kein eigenes Rechenzentrum und somit auch einen geringeren Personalaufwand
  • Der Cloud Anbieter liefert meist Support und Wartung Rund um die Uhr
  • Die Rechenleistung ist flexibel skalierbar und lässt sich somit perfekt an den Bedarf anpassen
  • Die räumliche Unabhängigkeit bietet einen Zugriff von jedem beliebigen Ort aus
  • Cloud Anbieter gewährleisten dank Sicherheitskopien und Co eine hohe Datensicherung
  • Keine Investitionskosten für Server-Hardware, was den Einstieg kostengünstiger macht

All diese Punkte sprechen für eine Cloud-Lösung und zeigen auf, warum Cloud-Computing-Anbieter wie AWS (Amazon Web Services) und Microsoft Azure so eine Marktrelevanz haben. Auch wir bei doubleSlash beschäftigen uns mit den Big Playern des Cloud Computing und entwickeln hoch performante Cloud Anwendungen. Speziell eben auch im Bereich der Testfahrten-Simulation für autonome Fahrzeuge. Solch performante Lösungen nennt man „Function as a Service“ oder kurz FaaS.

Fazit: Function as a Service als wichtiger Bestandteil bei der Entwicklung autonomer Fahrzeuge

Anwendungen wie die Simulation von Testfahrten oder der Sprachassistent Alexa sind Beispiele für eine Function as a Service (FaaS) Lösung. Dabei werden dem Anwender einzelne Funktionen zur Verfügung gestellt, die angesprochen werden können und innerhalb kürzester Zeit Ergebnisse liefern. Bei Alexa wäre das beispielsweise eine Anfrage, wie das Wetter morgen wird.

Daher findet der FaaS Ansatz häufig dann seinen Einsatz, wenn Performanz und Skalierbarkeit Kernanforderungen an die Lösung sind. Zudem wird nur die tatsächliche Rechenzeit, die zur Ausführung der Funktionen benötigt wird, in Rechnung gestellt.

FaaS-Lösungen und damit leistungsfähige Cloud Infrastrukturen wie Azure und AWS sind also ein wichtiger Bestandteil der Entwicklung autonomer Fahrzeuge.

————————————

In Kürze erfahren Sie noch mehr zum Thema:

 

Weitere Artikel rundum das autonome Fahren:

https://blog.doubleslash.de/autonomes-fahren-im-praxistest-zf-teststrecke-im-selbstversuch/

https://blog.doubleslash.de/vision-zero-durch-autonomes-fahren/

https://blog.doubleslash.de/von-driver-only-bis-roboter-taxi-die-herausforderungen-beim-automatisierten-fahren/


Quellen:

https://www.bmw.com/de/innovation/die-entwicklung-selbstfahrender-autos.html

https://www.automotiveit.eu/virtuelle-kilometerfresser/entwicklung/id-0064486

https://www.it-management.today/on-premise-vs-cloud-software-vor-und-nachteile/

It’s #FrontendFriday – Kann ich dieses npm Paket nutzen?

Hallo #FrontendFriday-Leser/in,

endlich ist es wieder #FrontendFriday!  Heute geht es um einen sehr effizienten Weg, npm Pakete zu evaluieren, ohne diese vorher auszuprobieren.

Zum Node Package Manager (kurz: npm) gehört neben essentiellen JavaScript Tools auch das globale npm-Repository (https://www.npmjs.com).
Hier finden sich über 1.000.000 JavaScript-Pakete. Die meisten davon sind OpenSource. Im Entwickleralltag stößt man häufig auf Aufgabenstellungen, die durch ein solches npm-Paket gelöst werden könnten.Mehr

It’s #FrontendFriday – Trusted Web Activity

Endlich ist es wieder soweit – Es ist Freitag und das bedeutet It’s #FrontendFriday

Was ist Trusted Web Activity?

Trusted Web Activity ist eine neue Möglichkeit, eure Webinhalte mit Hilfe einer Chrome Activity im Vollbildmodus in euer Android-App zu integrieren.

Technisch ist eine Trusted Web Activity (kurz: TWA) eine besondere Version des Chrome Custom Tab (kurz: CCT). Dadurch könnt ihr viele Chrome-Features nutzen, die auch mit dem CCT möglich sind – nicht aber in der klassischen Webview.

Konkret sind das Funktionen wie Push-Benachrichtigungen, Hintergrundsynchronisierung, Autofill bei Eingabeformularen, Media-Source-Extensions oder die Sharing API. Ein weiterer Pluspunkt: Die TWA teilt den Cache, Speicher und Sessions mit dem installierten Webbrowser.

Wenn der Nutzer sich also in der TWA anmeldet, ist er es auch weiterhin beim Starten der Web-App im Browser – weil eben die Session geteilt wird.Mehr

It’s #FrontendFriday – DOM vs Virtual DOM vs Shadow DOM

Hallo Liebe FrontendFriday Leser.

Um euch am Anfang maximal zu verwirren, gleich mal eine schöne Einstiegsfrage:

Was ist der Unterschied zwischen DOM und HTML DOM?

Es grenzt an Haarspalterei, aber es gibt tatsächlich einen Unterschied. DOM allein stehend ist ein W3C-Standard, welcher definiert, wie auf ein Dokument zugegriffen werden kann. Der W3C-DOM-Standard wird mit Core DOM (für alle Dokumententypen), XML DOM und HTML-DOM in drei Teile aufgeteilt. Das HTML DOM ist somit das Objektmodell und die Schnittstelle für das HTML, welches jedes HTML-Element als Objekt mit allen Eigenschaften, Methoden und Ereignissen definiert. Somit ist das HTML DOM der Standard, um HTML-Elemente zu ändern, hinzuzufügen oder zu löschen. Im folgenden Beitrag wird stellvertretend für den HTML DOM der DOM ausdruck verwendet.

Mehr