Die Zeiten, in denen die Unternehmen getreu dem Motto "Business as usual" leben konnten und dabei wettbewerbsfähig blieben, sind vorbei. Um auf dem Markt mitzuhalten und dabei noch für potenzielle Kunden aus der Masse hervorzustechen, müssen die Unternehmen die "Time-to-market" auf ein Minimum bis hin zu "On-Demand"-Auslieferung via OTA reduzieren. Dies wird bereits von einigen disruptiven Herstellern wie z.B. Tesla getan und führt nachweislich zu hoher Kundenzufriedenheit. Besonders bei den alteingesessenen Unternehmen, in der Regel OEMs, fällt auf, dass diese immer häufiger von der Komplexität der ständig steigenden Kundenanforderungen überfordert sind und es immer häufiger vorkommt, dass Liefertermine nicht eingehalten werden können und die Qualität der Software darunter leidet.
In der IT-Welt wurde gerade dies durch die Einführung der kollaborativen DevOps-Kultur ermöglicht. Der Fokus der Methoden liegt dabei auf schnellerem Feedback für die Entwickler und der damit einhergehenden Möglichkeit der schnelleren Auslieferung von Software-Verbesserung für den Kunden. Dabei muss zwischen der reinen Webentwicklung und der Embedded-Systementwicklung unterschieden werden. Gerade bei der Einführung der DevOps-Methoden in der Embedded-Systementwicklung verlaufen die ersten Schritte im Vergleich zur Webentwicklung nicht geradlinig. Besonders für Unternehmen aus dem Embedded-Systementwicklungsbereich lässt sich daher in den letzten Jahren ein stetig steigender Beratungsbedarf beobachten.
Das vorliegende Praxisbeispiel soll die Idee hinter der Masterarbeit verdeutlichen:
Der Kunde möchte sich über den Ist-Zustand seiner eigenen Entwicklungsmethodik sowie auf ihn zukommende Kosten bei nötiger Aktualisierung informieren. Der Kunde erwartet dabei eine individuelle Beratung mit anschließender Umsetzung zum Thema DevOps, Systementwicklung und eine Einschätzung des ROI. Das Ziel ist es somit, die Zufriedenheit des Kunden zu steigern, eine schnelle Erfassung und Darstellung des Ist-Zustands zu liefern, einen Überblick über entstehende Kosten bei Aktualisierung zu geben und dabei die langfristige Ersparnis bei Neuerung aufzuzeigen.
Aufbau der Arbeit:
1) Analyse bestehender Modelle mit Fokus auf Embedded-Systementwicklung
2) Konzepterstellung eines Kompetenzmodells in Verbindung mit einem ROI- / Kostenmodell
3) Evaluierung der beiden Modelle durch interne und externe Projekte
4) Fokus auf Gewährleistung von Effizienz inklusive Gewichtung nach Signifikanz und Relevanz
Inhaltsverzeichnis
1 Einleitung
1.1 Ausgangssituation der Arbeit
1.2 Motivation der Arbeit
1.3 Zielsetzung und Aufbau der Arbeit
2 DevOps
2.1 Entstehung der DevOps-Bewegung
2.2 Bedeutung von DevOps
2.3 Phoenix-Projekt
3 CI/CD-Pipeline
3.1 Software-Lebenszyklus
3.2 Phasen der Pipeline
3.3 Entwicklung der Pipeline
4 Grundlagen des Kompetenzmodells
4.1 Verbreitung von DevOps
4.2 DevOps im Embedded-Umfeld
4.3 Analyse bestehender Modelle
5 Umsetzung des Kompetenzmodells
5.1 Konzeption des Kompetenzmodells
5.2 Erstellung des Kompetenzmodells
5.3 Evaluierung des Kompetenzmodells
6 Umsetzung des Kostenmodells
6.1 Grundlage des Kostenmodells
6.2 Analyse bestehender Modelle
6.3 Erstellung des Kostenmodells
7 Fazit
Zielsetzung & Themen der Arbeit
Das Hauptziel dieser Arbeit ist die Entwicklung eines kundenschmerzorientierten Kompetenz- und Kostenmodells, welches speziell auf die Anforderungen der Embedded-Systementwicklung unter Verwendung von DevOps-Methoden zugeschnitten ist, um die Systementwicklung zu verbessern und messbare wirtschaftliche Vorteile aufzuzeigen.
- Analyse der DevOps-Entwicklungskultur und deren Relevanz für eingebettete Systeme.
- Erforschung der CI/CD-Pipeline und deren Anpassung an Hardware- und Embedded-Szenarien.
- Untersuchung bestehender Reifegradmodelle sowie Ableitung spezifischer Anforderungen für das Embedded-Umfeld.
- Konzeption, Erstellung und Evaluierung eines neuen, praxisnahen Kompetenz- und Kostenmodells zur Prozessverbesserung.
Auszug aus dem Buch
2.1 Entstehung der DevOps-Bewegung
„DevOps stellt kein Ziel dar, sondern ist ein nicht endender Prozess der kontinuierlichen Verbesserung.“
- Jez Humble, 2015
Es gibt die unterschiedlichsten Aussagen und Meinungen darüber, was genau unter dem Begriff „DevOps“ verstanden wird. Eine offizielle und allgemeine gültige Definition gibt es bisher nicht. Der Begriff taucht an den verschiedensten Stellen bei Konferenzen, in der Fachliteratur und den unterschiedlichsten Webseiten auf und wird dabei immer beliebter. Dabei stellt sich die Frage, wo und wie der Begriff entstanden ist.
Patrick Debois, in der DevOps-Szene besser bekannt als der „Pate von DevOps“, arbeitet 2007 in der Funktion Systemadministrator einer Rechenzentrumsmigration der belgischen Regierung. Debois bemerkt dabei auftretende Konflikte zwischen den Entwicklern und Systemadministratoren-Teams. Zugleich bewundert er die agilen Methoden, die von einigen Teams angewandt werden und ist davon begeistert, wie produktiv die Teams dadurch sind und wie schnell sie die Aufgaben erledigen können. Im darauf folgenden Jahr experimentiert er selbst mit den agilen Methoden und verfasst ein „IEEE Papier“. Dieses stellt er 2008 in Toronto auf der „Agile Conference“ vor, jedoch findet sein Vortrag mit dem Titel „Agile Infrastructure & Operations“ geringen Anklang. Andrew Shafer, ebenfalls Referent in Toronto, hat einen Vortrag zu Thema „agile Infrastruktur“ vorbereitet, allerdings findet sein Vortrag noch geringeren Anklang. Es stellt sich heraus, dass Debois der einzige Interessent bzw. Teilnehmer des Vortrags ist. Daher beschließt Shafer, seinen Vortrag gar nicht erst zu halten. Trotzdem kommen die beiden ins Gespräch und gründen zusammen die Google Forum Gruppe „Agile System Administration“.
Zusammenfassung der Kapitel
1 Einleitung: Beschreibt die Ausgangssituation, die Motivation und die Zielsetzung der Arbeit unter Berücksichtigung moderner Entwicklungsansätze wie OTA-Updates.
2 DevOps: Beleuchtet die theoretischen Grundlagen und die Entstehung der DevOps-Bewegung sowie das Phoenix-Projekt als Praxisbeispiel.
3 CI/CD-Pipeline: Erläutert den Software-Lebenszyklus und die Phasen einer Pipeline für eine automatisierte Bereitstellung.
4 Grundlagen des Kompetenzmodells: Analysiert die Verbreitung von DevOps, die Besonderheiten im Embedded-Umfeld und vergleicht bestehende Reifegradmodelle.
5 Umsetzung des Kompetenzmodells: Behandelt die Konzeption, die konkrete Erstellung sowie die Evaluierung des neu entwickelten Modells.
6 Umsetzung des Kostenmodells: Beschreibt die ökonomische Basis, analysiert bestehende Kostenmodelle und stellt die Erstellung eines eigenen Kostenmodells für DevOps dar.
7 Fazit: Fasst die Ergebnisse der Arbeit zusammen und gibt einen Ausblick auf die Weiterentwicklung der Modelle.
Schlüsselwörter
DevOps, Embedded-Systeme, CI/CD-Pipeline, Kompetenzmodell, Kostenmodell, Return-on-Investment, Softwareentwicklung, Prozessverbesserung, Kundenschmerz, Agile Methoden, Systementwicklung, Automatisierung, Reifegradmodell, Transformation, Lean Management
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Arbeit beschäftigt sich mit der Einführung und Verbesserung von DevOps-Methoden in der Embedded-Systementwicklung, um die Wettbewerbsfähigkeit durch schnellere Release-Zyklen und höhere Qualität zu steigern.
Was sind die zentralen Themenfelder?
Die zentralen Felder umfassen die Unternehmenskultur, Lean Management, den Build- und Hardware-Change-Prozess, Test-Automatisierung, Infrastruktur sowie die Systemarchitektur.
Was ist das primäre Ziel der Forschungsarbeit?
Ziel ist die Entwicklung eines Kompetenz- und Kostenmodells, das Unternehmen hilft, den aktuellen DevOps-Stand zu ermitteln und konkrete Verbesserungen zur Effizienzsteigerung abzuleiten.
Welche wissenschaftliche Methode wird verwendet?
Es wurde eine praxisorientierte Forschungsmethode gewählt, die eine Analyse bestehender Modelle, Experten-Interviews im Embedded-Bereich sowie eine anschließende Modellentwicklung mit Evaluierung umfasst.
Was wird im Hauptteil der Arbeit behandelt?
Der Hauptteil gliedert sich in die theoretische Fundierung von DevOps und CI/CD-Pipelines, die Analyse der spezifischen Herausforderungen im Embedded-Bereich sowie die detaillierte Ausarbeitung und Validierung der entwickelten Modelle.
Welche Schlüsselwörter charakterisieren die Arbeit?
Die zentralen Begriffe sind DevOps, Embedded-Systeme, CI/CD-Pipeline, Kompetenzmodell, Kostenmodell und Return-on-Investment.
Warum ist eine Unterscheidung zwischen Web- und Embedded-Entwicklung wichtig?
Web-Entwicklungen sind oft weniger hardwaregebunden und flexibler in der Bereitstellung. Embedded-Systeme unterliegen strengeren Normen, langen Support-Zyklen und direkten Hardwareabhängigkeiten, was spezifische Anpassungen in der DevOps-Kultur erfordert.
Wie generiert das Modell konkrete Verbesserungsvorschläge?
Basierend auf den Antworten des Nutzers zu sechs spezifischen Kategorien werden durch eine logische Verknüpfung individuelle Maßnahmenpläne (Basis, Fortgeschritten, Experte) generiert.
Welche Rolle spielt das Phoenix-Projekt?
Das Phoenix-Projekt dient als wichtiges Fallbeispiel in der DevOps-Literatur, um die Bedeutung von Kultur, WIP-Limitierung und den „drei Wegen“ des DevOps für Führungskräfte verständlich zu machen.
Warum wurde ein Kostenmodell integriert?
Das Kostenmodell dient dazu, den Return-on-Investment (ROI) der DevOps-Transformation zu quantifizieren und dem Management messbare wirtschaftliche Vorteile aufzuzeigen.
- Citar trabajo
- Stephan Weihrauch (Autor), 2020, Kundenschmerzorientiertes Kompetenzmodell für Verbesserungen der Systementwicklung unter Verwendung von DevOps-Methoden, Múnich, GRIN Verlag, https://www.grin.com/document/939310
