Software Engineering. Konfigurationsmanagement

Transkript

1 Software Engineering Konfigurationsmanagement Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber wird auf branchenspezifische Beispiele zur Softwareentwicklung Bezug genommen, die ggf. einer Anonymisierung unterzogen wurden Prof. Dr. Andreas Schmietendorf 1

2 Inhaltsübersicht Einführung zum Konfigurationsmanagement Ermitteln der Konfigurationselemente Dokumentation von Konfigurationen Versionen und Varianten Werkzeuge zum Konfigurationsmanagement Prof. Dr. Andreas Schmietendorf 2

3 Einführung zum Konfigurationsmanagement Prof. Dr. Andreas Schmietendorf 3

4 Typische Probleme der Softwareentwicklung Häufige Änderungen an Software-Elementen - Warum wurde geändert? - Von wem wurde die Änderung durchgeführt? - Was wurde geändert? Umgang mit aufgetretenen Fehlern Gegenseitige Behinderung bei mehreren Entwicklern Erfassung aller zu einer Lieferung gehörenden Elemente Kenntnis der beim Kunden eingesetzten Versionen Unter Verwendung von: Balzert, H.: Lehrbuch der Softwaretechnik, S. 234, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 4

5 Historie des Konfigurationsmanagements In den fünfziger Jahren von der amerikanischen Raumfahrtindustrie eingeführt. Entwicklung von Raumfahrzeugen unterlag zahlreichen undokumentierten Veränderungen. In den Tests wurden die Raumfahrzeuge zerstört und es war nicht oder nur schwer möglich, den Prototyp nachzubauen. Konfigurationsmanagement sollte diesen Informationsverlust verhindern, d.h. sämtliche Veränderungen dokumentieren. Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 234, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 5

6 Entstehung von Systemfamilien In Anlehnung an: Sommerville, I.: Software Engineering (8. Auflage), S. 739, Pearson Studium, München, Prof. Dr. Andreas Schmietendorf 6

7 Grundfunktionen des Konfigurationsmanagements Änderungssteuerung (configuration control) Konfigurationsidentifizierung (configuration identification) Konfigurationsüberwachung (configuration tracking) Konfigurationsbuchführung (configuration protocolling) Konfigurationsaudit (configuration auditing) Unter Verwendung von: Dumke, R.: Software Engineering (4. Auflage), S. 236, Vieweg Verlag, Wiesbaden, Prof. Dr. Andreas Schmietendorf 7

8 Ermitteln der Konfigurationselemente Prof. Dr. Andreas Schmietendorf 8

9 Planung des Konfigurationsmanagements Definition zu verwaltender Objekte und deren formelle Bezeichnung Festlegung von Verantwortlichen (inkl. Rollen & Berechtigungen): - Im Kontext von Konfigurationsmanagementverfahren. - Abgabe der Objekte beim Konfigurationsmanagementteam. Richtlinien für Änderungskontrolle und Versionsmanagement - Bilden von Releases - Beschreibung einzelner Builds Einsetzbare Werkzeuge und deren Verwendung z.b. Maven Struktur der Konfigurationsdatenbank festlegen In Anlehnung an: Sommerville, I.: Software Engineering (8. Auflage), S. 741, Pearson Studium, München, Prof. Dr. Andreas Schmietendorf 9

10 Konfigurationsdatenbank An welche Kunden wurde eine bestimmte Systemversion geliefert? Erforderliche Rahmenbedingungen für bestimmte Systemversion - Hard- und Netzwerkkonfigurationen - Betriebssystemkonfiguration - Benötigte Services und deren exakte Version Unerledigte Änderungsanträge für eine bestimmte Version Anzahl der gemeldeten Fehler zu einer bestimmten Version In Anlehnung an: Sommerville, I.: Software Engineering (8. Auflage), S. 743, Pearson Studium, München, Prof. Dr. Andreas Schmietendorf 10

11 Konfigurationen Software-Konfiguration: Benannte und formal freigegebene Menge von SW-Elementen, inklusive gültiger Versionsangaben. Elemente sind aufeinander abgestimmt und erfüllen vorgesehene Aufgabe. Software-Element: Jeder identifizierbare und maschinenlesbare Bestandteil des entstehenden Produkts oder der entstehenden Produktlinie. - Jedes SW-Element hat eindeutigen Bezeichner; - Jede Änderungen erzeugt neues Element mit neuem Bezeichner. Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 234, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 11

12 Beispiele für Konfigurationselemente Klassifikation entsprechend der Entstehung: Quellelemente Durch manuelle Eingaben erzeugte Softwareelemente (z.b. Quelltext) Abgeleitete Elemente Vollautomatisch erzeugte Elemente (z.b. Objektcode) Klassifikation entsprechend der Struktur: Atome Softwareelemente als unteilbare Einheit im Kontext eines Produktes Konfigurationen Softwareelement ist aus mehren Softwareelement zusammengesetzt Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 235, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 12

13 Übung 2-1 Geben Sie für das von Ihnen im dritten Semester durchgeführte Programmierprojekt konkrete Beispiele für Quellelemente, abgeleitete Elemente, Atome und Konfigurationen an! Wie ist das Verhältnis zwischen den verschiedenen Objekttypen? Kann es beispielsweise abgeleitete Atome geben? Welche Typen von SW-Elementen schließen sich gegenseitig aus? Haben Sie bei den oben angegebenen Beispielen alle Möglichkeiten abgedeckt? Prof. Dr. Andreas Schmietendorf 13

14 Dokumentation von Konfigurationen Prof. Dr. Andreas Schmietendorf 14

15 Konfigurations- Identifikationsdokument Das Konfigurations-Identifikationsdokument (KID) führt auf, welche SW-Elemente zu einer Konfiguration gehören. Dieses Dokument wird auch als Konfigurationshierarchie oder Elementstrukturplan bezeichnet. Es werden in der Regel auch Hilfsmittel oder Werkzeuge (z.b. Compilerversion) aufgeführt, die zur Erstellung beigetragen haben, aber nicht an den Kunden ausgeliefert werden. Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 235, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 15

16 Beispiel eines KID Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 237, Spektrum Akademischer Verlag, Heidelberg Berlin, 1998 (überarbeitet durch Faustmann, G.: Vorlesung Software Engineering, FHW Berlin) Prof. Dr. Andreas Schmietendorf 16

17 Referenzkonfigurationen Neue Konfigurationen ergeben sich durch: - Pflege und Wartung - Entwicklung im Prozess (baselines) Eine Referenzkonfiguration (baseline) ist zu einem Zeitpunkt im Entwicklungsprozess ausgewähltes, gesichertes und freigegebenes Zwischenergebnis. Dieses kann sich z.b. beziehen auf die - Anforderungskonfiguration - Entwurfskonfiguration - Implementierungskonfiguration - Testkonfiguration Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 237, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 17

18 Versionen und Varianten Prof. Dr. Andreas Schmietendorf 18

19 Version eines Softwareelements Eine Version ist die Ausprägung eines SW-Elements zu einem bestimmten Zeitpunkt. Sie erhält eine Nummer. Die Versionsnummer besteht im allgemeinen aus zwei Teilen: - Release-Nummer steht getrennt durch einen Punkt vor der Level Nummer und bezeichnet kleinere formale oder inhaltliche Änderungen - Level-Nummer beschreibt größere oder gravierende Änderungen Beispiel einer Versionszählung: Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 239, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 19

20 Modell zur Versionsverwaltung Checkin/Checkout-Modell - Checkout holt Kopie aus dem Archiv und reserviert es für den Ausbucher. Die Kopie darf jetzt geändert werden. Wird erneut ausgebucht, wird dies verhindert oder ein paralleler Entwicklungsast wird abgespalten. - Checkin Geändertes SW-Element wird in das Archiv befördert und die Reservierung wird aufgehoben. Änderungen werden formal erfasst (Autor, Buchungszeitpunkt, Grund der Bearbeitung, etc.). Eingebuchte Elemente können nicht mehr geändert werden; es kann nur durch erneutes Checkout/Checkin ein weiteres Element erzeugt werden. Unter Verwendung von: Balzert, H.: Lehrbuch der Softwaretechnik, S. 238, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 20

21 Variantenbegriff Zeitgleich nebeneinander liegende Ausprägungen von SW- Elementen, Darstellung paralleler Entwicklungslinien, Verschiedene Implementierungen derselben Schnittstelle, Unterschiede durch bedingte Übersetzung, Unterschiede für verschiedene HW-/SW-Konstellationen, Ab einem bestimmten Abstraktionsniveau nicht mehr zu unterscheidende Implementierungen. Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 239, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 21

22 Beispiel - Variante mit einem Zweig Die Versionen 1.0 und 1.1 befinden sich bei Kunden im Einsatz. Die Entwicklung findet an Version 1.2 statt. In Version 1.0 wird ein Fehler entdeckt, der Kunde kann jedoch nicht auf 1.1 übergehen. Somit wird eine abgespaltene Version entwickelt ( ) Variantennummer = release.level.branch.sequence Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 239, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 22

23 Beispiel - Variante mit zwei Zweigen Der Kunde mit V benötigt eine spezielle Funktion; er erhält die Variante V und nach Fehlerbehebung die Variante V Version 2.0 ist so fehlerhaft, dass Version 2.1 aus Version 1.1 abgeleitet wird. Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 240, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 23

24 Übung 2-2 Das Produkt Merkur (Katalogsystem) liegt in der Version 2.5 vor. Aus welchen Teilen setzt sich die Versionsnummer zusammen? Seit der letzten Version wurden nur geringe Änderungen vorgenommen. Wie lautet die Versionsnummer des Vorgängers? In der nächsten Version wird der Funktionsumfang des Produkts Merkur erheblich erhöht. Welche Versionsnummer sollte das Produkt dann tragen? Für einen Kunden müssen spezifische Anpassungen an die Version 2.5 gemacht werden. Wie behandelt man diesen Fall im Konfigurationsmanagement? Prof. Dr. Andreas Schmietendorf 24

25 Änderungsmanagement Änderungen an einem SW-Element müssen einen formalen Änderungsprozess durchlaufen, da sich somit die gesamte Konfiguration ändert. Änderungen eines Softwareelements führen: - Zustand in Bearbeitung - Versionsnummer wird um 1 erhöht (gravierende Änderungen führen zu einem neuen Release) - Vorlage zur Qualitätssicherung - Nach Freigabe erhält das Softwareelement den Status akzeptiert - Bereit zu Einbettung in eine neue Softwareversion Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 240, Spektrum Akademischer Verlag, Heidelberg Berlin, Prof. Dr. Andreas Schmietendorf 25

26 Beispiel - Änderungsmanagement Quelle: Balzert, H.: Lehrbuch der Softwaretechnik, S. 240, Spektrum Akademischer Verlag, Heidelberg Berlin, 1998 (überarbeitet durch Faustmann, G.: Vorlesung Software Engineering, FHW Berlin) Prof. Dr. Andreas Schmietendorf 26

27 Werkzeuge zum Konfigurationsmanagement Prof. Dr. Andreas Schmietendorf 27

28 Werkzeugbeispiele Kommerzielle Produkte - Rational ClearCase (Fa. IBM) - Visual SourceSafe (Fa. Microsoft) Open Source Produkte - Subversion ( - Concurrent Versions System ( - Apache Ant ( - Apache Maven ( Prof. Dr. Andreas Schmietendorf 28

29 TortoiseSVN Subversion-Client Ausschecken (Checkout) Änderungen ins Projektarchiv übertragen (Checkin) Quelle: Küng, S.; Onken, L.; Large, S.: TortoiseSVN -Ein Subversion-Client für Windows - Version 1.5.0, URL: Prof. Dr. Andreas Schmietendorf 29

30 Übung 2-3 Analysieren Sie mit Hilfe des Internets die Funktionalitäten eines selbst gewähltes KM-Systems (Abstimmung mit dem Dozenten ist erforderlich). Gehen Sie dabei auf die folgenden Aspekte ein: - Vorraussetzungen zur Installation - Architektur des verwendeten Projektarchivs - Schritte zum Aufsetzen eines Projektarchivs - Integration in Software-Produktionsumgebungen (verfügbare Clients) - Vorgehen zum checkin bzw. checkout - Verwaltungsfunktionen des Projektarchivs Gehen Sie auf die Visualisierungsmöglichkeiten des ausgewählten KM-Systems ein (z.b. project-, trunk- und branchbezogen) Prof. Dr. Andreas Schmietendorf 30