1 / 39

Konfigurationsmanagement

Konfigurationsmanagement. Vorlesung Uni München 9. Februar 2004 Thomas Belzner Waldemar Lohrer. Worum geht es eigentlich?. Man sagt: Wer Ordnung hält, ist nur zu faul zum Suchen! Oder auch: Wer Ordnung hält, ist nur zu schlau zum Suchen!.

berne
Télécharger la présentation

Konfigurationsmanagement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Konfigurationsmanagement Vorlesung Uni München9. Februar 2004Thomas Belzner Waldemar Lohrer Vorlesung KonfigMgmt

  2. Worum geht es eigentlich? Man sagt: Wer Ordnung hält, ist nur zu faul zum Suchen! Oder auch: Wer Ordnung hält, ist nur zu schlau zum Suchen!

  3. Konfigurations-Management: Ordnung Halten in (Software-)Systemen Fürunser Geschäft gilt jedenfalls: Wer in der Software-Entwicklung Ordnung halten will, muss ganz schön clever sein! Die Konsequenz: Wer auch nur ein bisschen schlau ist und das Chaos meiden möchte, betreibt bei der SW-Ent-wicklung Konfigurations-Management

  4. Worum geht‘s? Komplexität in der SW-Entwicklung Einsatzbereiche KonfigMgmt im SW-Entw.-Prozess Technik und Produkte Workflow und Raumkonzepte Übersicht

  5. Gründe für die Komplexität • Zu einem SW-Sytem gehören eine Vielzahl von Software-Elementen verschiedenster Typen: • Text-Dokumente, Spezifikationen, • (halb-)formale grafische Quellen • Code, Objekte, Module, Komponenten • aber auch: Werkzeuge, Basis-Software, ... • Große SW-Systeme sind bereits komplex durch die schiere Quantität ihrer Bausteine • Die Anzahl der zu verwaltenden Einheiten (Software-Elemente) liegt oftmals im drei- oder gar vierstelligen Bereich

  6. Softwareprodukt ... viele Zutaten ... sd&m 6

  7. ... und es wird noch komplexer ... • Verschiedenste technische Systeme müssen zusammenspielen: • Rechner (Host, Web-Server, PC‘s, Netzwerke) • Betriebssysteme • Plattformen, Werkzeuge, Entwicklungsumgebungen • Schnittstellen verlangen z.T. enge Integration mit anderen Systemen • Entwicklung und Wartung geschieht • mit vielen Menschen • an vielen Orten • manchmal für viele Kunden

  8. ... viele Menschen, viele Orte, viele Kunden ... Feedback, Anforderungen Integration QS Produktgenerationen sd&m 8

  9. ... Dynamik macht es noch komplexer... • Bei der Entwicklung und Wartung eines SW-Systems haben wir mit vielen Objekten, mit vielen, meistens komplexen, Beziehungen zwischen Objekten zu tun • Die Objekte und Beziehungen ändern sich mit der Zeit - die sind dynamisch, z. B: • Änderungen der angeforderten Funktionalität • Source Code Änderungen • Plattformwechsel • Kundenwechsel • Diese Dynamik erschwert die Beherrschung des Systems

  10. KonfigMgmt im SW-Entwicklungs-Prozess Worum geht‘s? Komplexität in der SW-Entwicklung Einsatzbereiche KonfigMgmt im SW-Entw.-Prozess Technik und Produkte Workflow und Raumkonzepte

  11. Projekt- bibliothek Die vier Säulen des KonfigMgmt Change- Mgmt Versions- Mgmt Vewaltung und Kon-trolle von SW-Elemen-ten (Änderungen mit Autor, Grund, Datum, Ablageort, ...) Steuerung der Änderungsver-langen der Um-welt Release- Mgmt Build- Mgmt Verwaltung von Abhängigkeiten zw. den SW-Elementen und Erzeugung von ausführbaren Kompo-nenten Verwaltung und Dokumen-tation der End-ergebnisse der SW-Entw.

  12. Versions-Management: ... Schritt für Schritt • (Fast) jedes Software-Element wird in vielen Schritten entwickelt. • Jede definierte Änderung an einem Element führt zu einer neuen Version (englisch oft auch revision) des Elementes. • Zu jeder Version wird dokumentiert: • Autor(en) • Gegenstand, Grund • Vorversion • Nummer • (Name, Label)

  13. 1.1 1.2.2.1 1.2 1.2.1.1 1.3 1.2.1.2 1.2.2.1.1 1.2.2.1.2 1.4 2.0 Versions-Baum eines SE

  14. Build-Management: Bauplan für das Ganze • Produktionskette:Erzeugung der ausführbaren Einheit(en) des Software-Systems aus den Quellen • oftmals über viele Schritte, z.B. generieren, kompilieren, binden, ... • Abhängigkeiten zwischen den Input-Elementen sind zu beachten • Eine Konfiguration ist eine Zusammenstellung bestimmter Versionen der Quell-SE plus die Beschreibung des Produktionsvorganges • welche Elemente sind mit welchen (Versionen der) Werkzeuge wie und ggf. in welcher Reihenfolge zu bearbeiten ...

  15. Kochrezept für eine Konfiguration a.pc a.c y.exe b.c y.exe m.exe m.hlp m.c m.exe Entwicklung Produkt Ausgangspunkt: Quellen aus dem Versions-Management

  16. Wer schlau ist, ist faul und macht‘s ... ... automatisch: • Der Produktionsprozess • findet bei effizienter Entwicklung großer Systeme oft täglich statt, • dauert manuell bis zu vielen Stunden, manchmal Tage, • muss die Abhängigkeiten zwischen den Elementen beachten, und muss deshalb automatisiert werden! • Nur durch Automatisierung des Builds (Produktions-prozesses) lassen sich Fehler und kleine Nachlässig-keiten reproduzierbar erkennen und beseitigen.

  17. Releases und deren Management • Konfigurationen, die veröffentlicht werden, d.h. an den Kunden, Abnehmer, Anwender zum Einsatz übergeben werden, nennt man Releases (engl. auch versions). • Physikalisch ist ein Release meist eine Zusammen-stellung der ausführbaren Elemente mit zugehöriger Dokumentation und der Definition des Installations-Vorganges (auch dies möglichst automatisiert), ... manchmal aber auch eine Zusammenstellung der Quellen zusammen mit dem Produktionsprozess.

  18. Konfiguration(Release) Sourcen (Versions-Management) Zeit A B C 1.0 1.0 1.0 Release 1 1.1 1.1 1.2 1.3 2.0 1.2 Release 2 Release-Mgmt: Die fertigen Pakete Release-Arten: - Vollrelease - Teilrelease - Bugfix - Emergency Pack Wichtig: - Stücklisten fürReleases; - Kennzeichnender Releases

  19. Change-Management Außer bei der ersten Entwicklung eines SW-Systems werden die Änderungen an einem SW-System hauptsächlich durch Anforderungen der Umwelt veranlasst: • Fehler treten auf und müssen behoben werden, • neue oder geänderte Funktionalität wird gebraucht, • technische Basissysteme, Schnittstellen ändern sich, • ...

  20. Release 1 Release 2 Change-Management ... ... ist der geordnete steuernde Umgang mit diesen Anforderungen der Umwelt an das System und gibt schließlich den Anstoß zur Erzeugung neuer • Versionen, • Konfigurationen und • Releases des Systems.

  21. Kunde • Entwickler Nein • Kunde Ja • Entwickler Ja Nein Nein Ja • Kunde Der Change-Management-Prozess Änderungsantrag (Change Request) Was ist zu ändern?Richtig verstanden? Auslieferung • Entwickler(Versions-,Release-Management) Beauftragung Wie ist zu ändern? Was kostet es?Vorschlag ok? KundeChange Control Board

  22. KonfigMgmt im SW-Entwicklungs-Prozess Das Konfigurations-Management ist ein wichtiger Baustein bei allen Normen und Richtlinien zur SW-Entwicklung, wie z.B. • DIN EN ISO 9001 („TÜV-Zertifikat“) • V-Modell • IEEE-Normen (828-90, 1027-87) • Standards des US-Verteidigungsministeriums, der NASA, • ... • und nicht zuletzt auch das „aktuelle“ RUP (Rational Unified Process) von den „Köchen“ der UML.

  23. KonfigMgmt bei ISO 9001 6. Unterstützende Tätigkeiten (phasenunabhängig) 6.1 Konfigurationsmanagment (KM) 6.1.1 Allgemeines 6.1.2 KM-Plan 6.1.3 KM-Tätigkeiten 6.1.3.1 Identifikation und Rückverfolgung der Konfiguration 6.1.3.2 Lenkung von Änderungen 6.1.3.3 Konfigurations-Statusbericht

  24. KonfigMgmt bei ISO 9001 6.1.1 Allgemeines ... Das KM sollte a) die Versionen jedes Softwareelements (SE) eindeutig identifizieren; b) die Versionen jedes SE, die gemeinsam die spezifische Version eines Produkts bilden, identifizieren; ...

  25. Workflow und Raumkonzept Worum geht‘s? Komplexität in der SW-Entwicklung Einsatzbereiche KonfigMgmt im SW-Entw.-Prozess Technik und Produkte Workflow und Raumkonzept

  26. Workflow entlang Versions-/Build-/ReleaseMgmt ... Entwickeln der Quellen, compilieren und testen der einzelnen erzeugten SE (ausleihen) (zurückgeben) produktiveNutzung Integrieren und testen einer Konfiguration SystemtestTesten des Ge-samtsystems(Release + Nach-barsysteme + Umwelt) Erzeugen und testen eines Releases

  27. ... führt zum 3-stufigen Raumkonzept

  28. Der Weg durch die Räume • Die Übergänge von SE bzw. Konfigurationen in den nächsten Raum stellen wichtige Planungseinheiten für ein Entwicklungs- oder Wartungsprojekt dar. • Hier spielen KM und QM (Qualitätsmanagement) zusammen: Für den Übergang müssen definierte Qualitätskriterien erfüllt sein. • Der Übergang in den nächsten Raum ist mit Aktivitä-ten zur Dokumentation und des KM verbunden • z.B. Erstellung von Release-Notes • z.B. Archivierung eines Release

  29. KM auch für Konfigurationen und Räume • Ebenso wie die einzelnen Software-Elemente unterliegen auch die Konfigurationen und Releases dem Versionsmanagement. • Je nach Testvorgehen und Parallelisierung der Inte-grations- und Testarbeiten kann es auch mehrere Integrationsräume für eine Konfiguration geben. • Für ein Release gibt es jedoch immer genau einen Releaseraum.

  30. Technik und Produkte für das KM Worum geht‘s? Komplexität in der SW-Entwicklung Einsatzbereiche KonfigMgmt im SW-Entw.-Prozess Technik und Produkte Workflow und Raumkonzepte

  31. KM und Werkzeug-Unterstützung • Eine Umsetzung der beschriebenen Konzepte des Konfigurations-Managements ohne Unterstützung durch Werkzeuge ist - außer im trivialen 1-1-1-Fall (1 Entwickler, 1 SE, 1 Version) - praktisch nicht möglich! • Allerdings muss auch klar sein: Allein der Einsatz eines KonfigMgmt-Werkzeuges alleine - und sei es noch so ausgefuchst - sichert noch lange kein sauberes Konfigurations-Manage-ment im Projekt!

  32. Standard-Funktionalität eines KM-Tools • Ausleihen, Zurückgeben (check out, check in) • zum Ändern (u.U. nur an den Autor) • nur zum Lesen • auch „alte“ Versionen • Definition von Konfigurationen • Zustandsmodelle für SE, Konfigurationen • Infos (Autor, Grund der Änderung, ...) zu einzelnen SE-Versionen • Reports (Konfigurationen, SE in einem bestimmten Zustand, ...)

  33. KM ist Drehscheibe für den Workflow

  34. Weitere Features von KM-Werkzeugen • Rollenkonzepte für Entwickler (Autor, Reviewer, Leser eines SE) • Freie Definition von Zustandsmodellen für SE, Konfigurationen, Releases • Automatisierung von Prozessen (z.B. beim check-in Benachrichtigung von Autoren von SE, die von einer Änderung betroffen sein können, Prüfroutinen auf Konsistenz, sonstige Trigger ...) • Unterstützung von Raumkonzepten (z.B. virtuelle Dateisysteme, ...) • ...

  35. Interner Aufbau von KM-Werkzeugen • Es gibt verschiedenen Speicherverfahren der verschiedenen Versionen eines SE • Delta, reverse Delta, Vollversionen, komprimiert • Organisation der Datenspeicherung • alles im Dateisystem • Inhalte im Dateisystem, Metainformationen in der Datenbank • alles in einer Datenbank • z.T. starke Integration mit dem Betriebsystem bzw. dem Dateisystem

  36. Produkte • Freie Software • rcs (revision control sytem) • cvs (concurrent version system) • Betriebssystemkomponenten • sccs (source code control system) • ... • Mächtige (und teure) Produkte • Continuus (von Telelogic) • ClearCase (Rational -> IBM)

  37. Weitere Einsatzbereiche für KM Worum geht‘s? Komplexität in der SW-Entwicklung Einsatzbereiche KonfigMgmt im SW-Entw.-Prozess Technik und Produkte Workflow und Raumkonzepte

  38. KonfigMgmt nur für „große“ Projekte? NEINM ! Es lohnt sich schon bei einem Mitarbeiter, denn • es unterstützt Versionierung und Baselining und damit das Festhalten definitiver Entwicklungs- und Auslieferungsstände, • es erleichtert die Übersicht und Dokumentation der Änderungen.

  39. KonfigMgmt nur für SW-Entwicklung? NEINM ! Es lohnt sich ebenso z.B. bei Studien, denn • auch dort hat man schnell mit einer Vielzahl von Einzel-Elementen des Gesamtwerkes zu tun (Kapitel, Abbildungen, Listen und Tabellen im Anhang, etc.); • auch diese Text-Dokumente entwickeln sich in vielen Schritten (Versionen) bis zum endgültigen Stand; • auch für Text-Dokumente gibt es ein Zustandsmodell, definiert durch die Qualitätssicherung.

More Related