1. Grundlage
1.1. 1.Das große Ziel CD beschreiben und was für Bestandteile es hat.
1.1.1. Als Grundlage das Beispiel von GoCD verwenden (einziger Blogeintrag darüber)
1.2. 1.1Auch hier schon mal einen kleinen Ausblick geben, was für (andere) Herausforderungen im Bereich von mobilen Applikation bestehen
1.3. 2.Mit dem "Fazit": Die Lösungen gibt es bereits. Aber wir wollen nicht gleich alles auf einmal. Sondern Stück für Stück
1.3.1. ganz im geiste von agile und buildmesaurelearn
1.3.2. "Demming-Cycle"
2. Fazit/Ausblick
2.1. Codepush mit Hybriden Apps | nicht möglich mit nativen Apps
2.2. Bei Apps in der Kategorie Solutionfit (also ganz am Anfang) muss mehr auf den "Delivery" und "Reporting" Aspekt geachtet werden...
2.3. Modell kann verwendet werden als Grundlage für empirische Studien, die den Stand in der Industrie quantifizieren wollen
2.4. Low hanging fruits
2.5. Weitere Dimension des Modells ansprechen
2.5.1. Typ das Projektes
3. Sonstiges/Meta
3.1. Methoden
3.1.1. Zu Ihrer wissenschaftlichen Leistung zählt daher auch eine kurze Begründung, warum Sie eine bestimmte Methode und ein bestimmtes Beispiel gewählt haben und warum dies Ihre Forschungsfrage Ihrer Meinung nach am besten behandelt.
4. Einleitung/Grundlagenteil
4.1. Warum testen?
4.1.1. Im mobilen Bereich ist Qualität ein entscheidender Faktor
4.1.1.1. Abhängig von Nutzerwertungen
4.1.1.2. Eingeschränkte Möglichkeit von Updates (Fehlerverbesserungen)
4.1.1.3. Größere Masse an Kunden
4.1.2. Testen der Funktionalität ("Funktioniert es wie es soll?"), aber auch Testen von Business Kriterien
4.2. Testen ist nicht alles
4.2.1. Kein Testen zum Selbstzweck
4.2.1.1. Sinnvoll im ganzen Konstrukt der Continuous Delivery
4.2.2. Effektiver/Schneller Software ausliefern
4.2.2.1. Weil halt agil und so
4.2.2.2. Continous Delivery
4.2.2.2.1. Siehe andere Map
4.2.3. Besser Programmieren
4.2.3.1. Im sinne von architektur --> Komponenten
4.2.3.2. Best practices einhalten
4.2.3.3. Code smell vermeiden
4.2.3.4. testbarer code schreiben
4.2.3.5. "build quality in"
4.2.4. Testergebnis muss transparent sichtbar für alle sein
4.3. Automatisch (mobile) testen
4.3.1. "Je früher bugs gefunden werden, desto billiger sind sie um sie zu beheben"
4.3.2. Das ist eigentlich das Ziel
4.3.3. Großes Thema aktuell
4.4. Qualität
4.5. Zielsetzung und Fragestellung
4.6. Ziel des Modells
4.6.1. Metriken
4.6.2. Ultimate aim is to improve
4.6.3. weniger Fehler
4.6.4. faster, more predictable
4.6.5. s. 419
5. Auch Grundlage?
5.1. 3. Wie/Was automatisieren?
5.1.1. Emulator oder device?
5.1.1.1. "State of the art emulatoren sind super" (oder so)
5.1.2. In der cloud? Inhouse?
5.1.3. Integrieren in die Pipeline?
5.2. 4. Open-Source vs. Paid Service (Device-Cloud, SaaS, Crowd-Tester)
5.3. 5. Probleme
5.3.1. Es lässt sich (leider noch) nicht alles automatisieren.
5.3.2. Manueller Test-Anteil ist hoch
5.3.2.1. Gründe: ....
5.3.2.2. Umgedrehte Testpyramide
5.3.3. Wie lässt sich das mit dem herkömmlichen Ansatz der CD - Pipeline vereinbaren/integrieren?
6. Das Reifegradmodell
6.1. Maturity Map
6.1.1. Selbst entwerfen/modellieren
6.1.2. Fragen dazu ausdenken
6.2. Beschreibung
6.2.1. Warum? Weil hilfreich um "Stück für Stück" zu reifen
6.2.1.1. Nicht alles auf einmal. An den Reifegrad angepasst.
6.2.2. Was bedeuten die einzelnen Spalten/Zeilen
6.2.3. Was ist die Grundlage davon
6.2.4. Was wird vorrausgesetzt
6.2.5. Warum nochmal ein Modell, statt die es schon gibt?
6.3. Kontext
6.3.1. Phase
6.3.1.1. Software development lifecycle (SDLC)
6.3.1.1.1. Phase bestimmen
6.3.1.1.2. Nicht zu verwechseln mit Software development process (wie z.B. Scrum/Waterfall etc)
6.3.1.1.3. Marketfit/Problemfit --> siehe (Lean Startup by Eric Ries)
6.3.2. Was ist der Kontext
6.4. Aufbau
6.4.1. Alle Kategorien Levelweise erklären
6.4.1.1. Test
6.4.1.2. Build
6.4.1.3. Releas
6.4.1.4. Reporting
6.4.1.5. Kultur
6.4.1.6. Technologie
6.5. Verwendung
6.5.1. Grundlage ist die Feststellung des Reifegrades
6.5.2. Wie ist es zu verwenden
6.5.3. Was sind die "low-hanging-fruits"?
6.5.3.1. Was sollte man (nach der Feststellung) umsetzen/implementieren?
6.5.3.2. Als erstes? zweites? drittes?
6.5.3.3. Step by Step
6.5.3.4. Das "Einfachste" nehmen siehe auch praqma mit ihrer Formel
6.5.4. Mehr als "Black-Box" zu sehen
6.5.4.1. Es intressiert eher weniger was die einzelnen stufen enthalten
6.5.4.1.1. der weg ist nach oben