10. Konfigurationsmanagement Software Engineering
10. Konfigurationsmanagement
Software Engineering
Gliederung Vorlesung
� Einführung
� V-Modell XT
� Analyse und Anforderungsmanagement
� Benutzungsoberflächen
� Architektur
� Entwurf
� Entwurfsmuster
� Persistenz
� Testen
� Konfigurationsmanagement
� Abnahme, Einführung, Wartung und Pflege
Allweyer: Software Engineering
Warum Konfigurationsmanagement?
� Änderungen nachvollziehen● Man hat etwas im Code geändert, möchte dann aber wieder einen früheren
Inhalt wiederherstellen
� Zusammengehörige Dateien verwalten● Alle Quelltextdateien, Bibliotheken, Hilfsdateien usw.● Jeweils in den Versionen, die zusammengehören
� Zusammenarbeit im Team● Alle sollen jeweils mit den aktuellen Dateien der Kollegen arbeiten● Geänderte Dateien sollen den anderen wieder zur Verfügung gestellt
werden● Lösung von Konflikten: 2 Leute haben die gleiche Datei geändert
� Wartung verschiedener Versionen● Kunde erhält eine stabile Version (Release)● Entwicklung arbeitet an der aktuellen Version weiter● Bugfix muss in die stabile Version einfließen
Allweyer: Software Engineering
Allweyer: Software Engineering
Software-Elemente
� Eindeutig identifizierbare (Zwischen-)Ergebnisse, die im Laufe der Software-Entwicklung entstehen
� Beispiele● Pflichtenheft● Qualitätsplan● Quelltext-Dateien● Ausführbare Datei
� Unterscheidung nach Erzeugungsart:● Quellelement
− Durch manuelle Eingaben erzeugt, z. B. Pflichtenheft, Quelltext
● Abgeleitetes Element− Z. B. ausführbare Datei
� Software-Elemente müssen eindeutig bezeichnet werden● Namenskonventionen
Konfigurationsmanagement mit Subversion (SVN)
Allweyer: Software Engineering
Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversionhttp://svnbook.red-bean.com/nightly/de/svn-book.html
Konflikte: Versehentliches Überschreiben
Allweyer: Software Engineering
Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversionhttp://svnbook.red-bean.com/nightly/de/svn-book.html
Revisionsnummern
� Eine Revisionsnummer in SVN bezieht sich immer auf den gesamten Baum
● Nicht auf einzelne Dateien
Allweyer: Software Engineering
Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversionhttp://svnbook.red-bean.com/nightly/de/svn-book.html
Aktuellste Revision („HEAD“)
Wichtige Tätigkeiten
� Checkout● Das gesamte Projekt aus dem Repository holen
● Macht man am Anfang
� Update● Neuerungen vom Repository holen
● Seine Arbeitskopie aktualisieren
● Falls es Konflikte gibt: Dateien zusammenführen („Merge“)
� Commit● Lokal veränderte Daten hochladen
● Führt zu einer neuen Revision des HEAD
● Geht nur, wenn man im HEAD keine Daten überschreiben würde− Ggf. vorher Merge durchführen
Allweyer: Software Engineering
Merge
� Vergleich der Unterschiede● Übernahme von Änderungen und manuelle Anpassung möglich
● Anschließend wird die Version als „merged“ markiert und kann commited werden
Allweyer: Software Engineering
Arbeiten mit SVN
� Arbeitsablauf
1. Initialer Checkout um die erste Arbeitskopie des Projekt zu bekommen
2. Das tägliche Arbeiten:i. Update !!!
ii. Bearbeiten
iii. Evtl. Revert (Lokale Änderungen rückgängig machen)
iv. Konflikt:i. Merge der Dateien
ii. Commit inklusive Kommentar!
v. Kein Konflikt:i. Commit inklusive Kommentar!
Allweyer: Software Engineering
Allweyer: Software Engineering
Beispiel: Tägliche Systemerstellung
� Diese Vorgehensweise eignet sich für iterative Vorgehensmodelle
� Es wird jeden Tag eine funktionierende Konfiguration erstellt● Definierter täglicher Abgabezeitpunkt (z. B. 14 Uhr)● Alle Entwickler müssen die neuen Versionen der geänderten Quelltext-
Elemente einreichen. Diese müssen nicht vollständig sein, aber kompilierbar und testbar.
● Daraus wird ein neues System erstellt● Dieses wird mit Hilfe von vordefinierten, z.T. automatisierten Tests getestet● Parallel arbeiten die Entwickler an ihren Quelltexten weiter● Gefundene Fehler werden an die Entwickler zurückgemeldet, diese
beheben sie in einer Folgeversion
� Vorteile● Frühes Erkennen von Fehlern● Man hat ständig ein funktionierendes System (Risikoreduktion)
Allweyer: Software Engineering
Umgebungen
� Entwicklungsumgebung● Persönlicher Arbeitsbereich jedes Entwicklers● Hier werden auch Elemente anderer Entwickler benötigt, damit der
Entwickler seine Elemente testen kann -> Jeweils mit aktueller Baseline updaten
� Referenzumgebung● Software-Elemente, die unter ausschließlicher Kontrolle des
Konfigurationsmanagers stehen● Fasst Software-Elemente zu reproduzierbaren Konfigurationen zusammen
� Prüfumgebung● U.U. lokale Modifikationen (zum Ausprobieren), kein Weiterentwickeln
� Produktionsumgebung● Nur freigegebenes Release
Allweyer: Software Engineering
Was wird abgelegt?
� Produktdokumente● Quell-Texte
● U.U. abgeleitete Elemente (z. B. Binaries)
● In jedem Fall: Notwendige Verfahren zur Reproduktion von Ableitungen− Makefiles, Compiler, Entwicklungsumgebungen, …
� Projektdokumente● Z. B. Projektplan
� Prüfnachweise● Z. B. Testprotokoll
● Selbst nicht versioniert, bezieht sich aber auf eine bestimmte Produktversion
Historie einer Datei
Allweyer: Software Engineering
Kommentare sind wichtig!
Vergleich mit früherer Version
� Man kann auch auf einen früheren Stand zurückgehen
Allweyer: Software Engineering
SVN-Repository - empfohlene Verzeichnisstruktur
� Trunk● Stamm des Versionsbaums (Hauptentwicklungslinie)
● Normalerweise wird hier gearbeitet
� Branches● Äste im Versionsbaum, parallele Entwicklungszweige
� Tags● Besonders gekennzeichnete Versionen, die bestimmte Entwicklungsstände
repräsentieren (z. B. Meilenstein oder Release)
Allweyer: Software Engineering
Repository
Tags
� Ein Tag bezeichnet eine Momentaufnahme des Projektes,auf die man später evtl. wieder zurückgreifen möchte
● Meilenstein, Release, etc.
● Bezeichnung mit einem sprechenden Namen (z. B. „Release 1.0“) statt einfach einer Revisionsnummer (z. B. 4367).
� Ein Tag ist in SVN einfach eine Kopie der Verzeichnisstruktur● Man sollte aber nicht darin weiterarbeiten
− Dafür dienen Branches
● Versucht man, in das Verzeichnis „tags“ zu committen, erhält man eine Warnung− Aber es wird nicht verhindert. Die Verwendung des Verzeichnis „tags“ ist nur
eine Konvention.
Allweyer: Software Engineering
Entwicklungszweige (Branches)
Allweyer: Software Engineering
Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversionhttp://svnbook.red-bean.com/nightly/de/svn-book.html
Anlegen eines Zweiges (Branch)
� Ein Branch ist eine Kopie, auf der unabhängig vom Trunk weitergearbeitet wird
Allweyer: Software Engineering
Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversionhttp://svnbook.red-bean.com/nightly/de/svn-book.html
Verzweigung in der Geschichte einer Datei
Allweyer: Software Engineering
Quelle: Collins-Sussman/Fitzpatrick/Pilato: Versionskontrolle mit Subversionhttp://svnbook.red-bean.com/nightly/de/svn-book.html
Allweyer: Software Engineering
Änderungsmanagement
� Änderungen sind natürlich und unvermeidlich● Änderungen im Umfeld, z. B.
− Gesetzesänderungen
− Geänderte externe Schnittstellen
− Neue Anforderungen
− Neue Betriebsumgebung (z. B. geänderte Datenbankversion)
● Entdeckte Fehler / Probleme im Produkt
� Änderungen kontrolliert einbringen
� Mittel: Änderungsmanagement
Allweyer: Software Engineering
Ablauf Änderungsmanagement
Change Control Board-Projektmanager-Entwicklung-Auftraggeber
Oft: Verschiedene Gremien,je nach Schwere des Falls
Oft resultieren zusätzlicheKosten / größere Dauern – diesmuss vom Auftraggeber genehmigt werden!
Allweyer: Software Engineering
ÄnderungsantragChange Request Form
Project: Proteus/PCL-T ools Number: 23/02Change requester: I. Sommerville Date: 1/12/02Requested change:When a component is selected from the structure, displaythe name of the file where it is stored.
Change analyser: G. Dean Analysis date: 10/12/02Components affected: Display-Icon.Select, Display-Icon.Display
Associated components: FileT able
Change assessment: Relatively simple to implement as a file name table isavailable. Requires the design and implementation of a display field. No changesto associated components are required.
Change priority: Low
Change implementation:Estimated effort: 0.5 days
Date to CCB: 15/12/02 CCB decision date: 1/2/03CCB decision: Accept change. Change to be implemented in Release 2.1.Change implementor: Date of change:Date submitted to QA: QA decision:Date submitted to CM:Comments Quelle:
Sommerville