Was bedeutet Integration im Software Engineering? (S.11)
Unabhängig entwickelte Komponenten zu einem Gesamtsystem kombinieren.
Wozu dient der Integrationstest laut Ablaufgrafik? (S.12)
Prüfen ob Komponenten wie im Entwurf vorgesehen zusammenarbeiten.
Welche Integrationsstrategien gibt es und welche ist meist vorzuziehen? (S.13)
Big Bang/ Top down/ Bottom up/ Kontinuierliche Integration/ Inkrementell ist Big Bang meist überlegen.
Warum braucht man für Integration Planung der Entwicklungsreihenfolge? (S.13)
Abhängige Komponenten müssen in sinnvoller Reihenfolge verfügbar sein.
Wofür nutzt man einen Abhängigkeitsgraphen? (S.14)
Visualisiert benötigt-Beziehungen und unterstützt Top-down bzw. Bottom-up Planung.
Was zeigt die Abhängigkeitsmatrix gegenüber dem Graphen? (S.15)
Tabellarische Übersicht der Abhängigkeiten mit leichterer Ableitung von Integrationsschritten.
Was sind Stubs und wann setzt man sie ein? (S.16)
Platzhalter die fehlende Komponenten simulieren/ Einsatz wenn reale Komponente noch nicht verfügbar ist.
Worum geht es in der Übung „Integrationsplanung“? (S.17)
Bottom-up Integrationsreihenfolge aus der Matrix ableiten um Stubs zu vermeiden.
Wo entstehen bei der Integration typischerweise Probleme und warum? (S.18)
An Schnittstellen/ wegen unklarer Spezifikation oder spät verfügbaren externen Komponenten.
Was gehört in einen Integrationsplan und warum schriftlich? (S.19)
Zu integrierende Komponenten/ technische Voraussetzungen/ Reihenfolge/ Besonderheiten/ schriftlich für Nachvollziehbarkeit.
Welche Grundprinzipien der Integration gelten? (S.20)
Früh planen/ früh beginnen/ Aufwand für Test und Integration nicht unterschätzen/ Strategie an Prozesse anpassen/ Aufwand erfassen/ Risiken reduzieren.
Welche typischen Stolpersteine gibt es? (S.21)
Falsche Komponenten integriert/ Doppelentwicklung/ verlorene Testdaten/ Arbeiten ohne Sicherung/ Änderungen überschrieben.
Was ist der Unterschied zwischen Versionen und Varianten? (S.23)
Versionen sind zeitliche Entwicklungsstufen/ Varianten sind parallele Ausprägungen für unterschiedliche Bedürfnisse.
Wie lassen sich Versionen und Varianten im Überblicksbaum einordnen? (S.24)
Versionen sind linear mit Abzweigungen/ Varianten laufen parallel zur Hauptlinie.
Was ist eine Version laut Definition und was passiert mit der alten? (S.25)
Neue Auslieferung eines Konfigurationselements/ ersetzt die vorherige Version.
Was kennzeichnet Varianten? (S.26)
Parallel bestehende kundenspezifische Ausprägungen die sich nicht gegenseitig ersetzen.
Welche Probleme verursachen viele Varianten und alte Versionen? (S.27)
Hoher Wartungsaufwand/ Portierungen in jede Variante/ Support für als veraltet angesehene Stände.
Warum braucht man eine Versionspolitik und welche Fragen stellt sie? (S.29)
Um Releases planbar zu machen/ Welche Features in welche Version/ Welche Stände bekommen Updates/ Umgang mit Sicherheitslücken in Abhängigkeiten.
Was ist mit „öffentlicher API“ im Sinne der Versionspolitik gemeint? (S.30)
Das faktische Versprechen nach außen oft Handbuch oder Spezifikation nicht nur Code-APIs.
Welche Erwartungen gibt es an API-Stabilität? (S.31)
Seltene Änderungen/ nachvollziehbares Versionierungsschema/ semantische Änderungen sollen sich syntaktisch widerspiegeln.
Warum „bitte systematisch“ und was ist die Idee von SemVer? (S.32)
Nachvollziehbare Regeln statt Bauchgefühl/ SemVer definiert klare Erhöhungsregeln.
Warum entstehen Abhängigkeiten und was bedeutet „keine grüne Wiese“? (S.34)
Projekte bauen auf Bibliotheken und Diensten auf/ Abhängigkeiten wachsen mit Projektgröße.
Was bedeuten Version Lock und Version Promiscuity? (S.35)
Lock: zu strikte Bindung erzeugt Update-Lawinen/ Promiscuity: zu lax führt zu falscher Kompatibilitätsangabe.
Wann spricht man von Abhängigkeitshölle? (S.36)
Bei Lock/ Promiscuity oder beidem wodurch Entwicklung stark behindert wird.
Wie vermeidet bzw. verlässt man die Abhängigkeitshölle? (S.37)
Situation analysieren/ Soll definieren/ Schritte planen/ konsistentes Versionierungsregelwerk anwenden zB SemVer.
Wer schlug Semantic Versioning vor und wo findet man es? (S.39)
Tom Preston-Werner/ Regelwerk kompakt auf semver.org.
Wie lautet das SemVer-Schema und die Grundregeln? (S.40)
MAJOR.MINOR.PATCH/ MAJOR bei inkompatiblen Änderungen/ MINOR bei kompatiblen Features/ PATCH bei kompatiblen Bugfixes/ Prärelease und Build-Metadaten möglich.
Wie ist SemVer formal aufgebaut? (S.41)
Version core aus major.minor.patch optional Prärelease mit - und Build mit +.
Welche Voraussetzungen braucht SemVer in Projekten? (S.42)
Öffentliche API muss klar/ präzise/ ausführlich dokumentiert sein als Doku oder Code.
Was bedeutet „keine nachträglichen Änderungen“ bei SemVer? (S.44)
Veröffentlichten Inhalt nicht ändern/ Änderungen immer als neue Version releasen.
Wie sind 0.y.z und 1.0.0 zu interpretieren? (S.45)
0.y.z ist instabile Entwicklungsphase/ ab 1.0.0 ist die öffentliche API definiert.
Wann sollte ein Projekt 1.0.0 vergeben? (S.46)
Bei produktiver Nutzung oder bestehender stabiler API auf die sich Nutzer verlassen.
Was zeigt das Negativbeispiel „Portfolio Performance“ mit Version 0.xx? (S.47)
Langes Verbleiben unter 1.0 trotz Stabilität verwechselt die Aussage zur API-Stabilität.
Wann erhöht man PATCH laut SemVer und welche Grauzonen gibt es? (S.48)
Bei reinen kompatiblen Bugfixes/ unklare erwartete Verhaltensbeschreibung kann Abgrenzung erschweren.
Wann erhöht man MINOR laut SemVer? (S.49)
Bei kompatiblen Features/ bei Deprecation-Ankündigungen/ optional bei größeren internen Änderungen/ PATCH wird dabei auf 0 gesetzt.
Wann erhöht man MAJOR laut SemVer? (S.50)
Bei API-inkompatiblen Änderungen/ MINOR und PATCH werden auf 0 gesetzt.
Welche weiteren Detailregeln nennt SemVer? (S.51)
Prärelease und Build-Metadaten/ definierte Sortierung zB 1.0.0-alpha < 1.0.0.
Wie geht SemVer mit Deprecation und Fehlversionierungen um? (S.52)
Deprecation vorher in MINOR ankündigen/ versehentliche Regelverletzung auf gleicher Ebene reparieren und dokumentieren.
Worum geht es in der Übung „Semantic Versioning“ und was ist falsch im Szenario? (S.53)
Verstöße erkennen/ Entfernen von Kreditkarten ist MAJOR nicht MINOR/ Bugfixes gehören als PATCH nicht als neue MAJOR.
Zuletzt geändertvor einem Monat