Diskussion:Konfigurationsmanagement

CMDBf und Architektur

'Fortgeschrittene Konfigurationsmanagementwerkzeuge verwenden ein objektorientiertes Konzept und Datenbanktechnologien für die Verwaltung von Versionen.'

Die Architektur von Konfigurationswerkzeugen tut hier nichts zur Sache. Objektorientierung ist kein Indiz für den erreichten Fortschritts- oder Reifegrad eines Konfigurationswerkzeugs. Im gegenteil wird heir der Eindruck erweckt, das jedes nicht-objektorientierte Werkzeug nicht firtschrittlich ist.

Pauschalierte Bewertungen sollten aus einem enziklopädischen Artikel herausgehalten werden.

Interessanter wäre eine Einführung von CMDBf (als neuen Standard der DMTF für CMDB Federation) in die Tooldiskussion, die Abdeckung von Outsourced Services, im Besonderen external Computing und Storage Clouds im Tooldesign.

Quellen hierzu www.cmdbf.org, www.dmtf.org (nicht signierter Beitrag von 160.83.30.149 (Diskussion) 11:34, 16. Sep. 2010 (CEST))

Hi, dein Beitrag war zwar von 2010, aber ich habe nachgelegt und verbessert. Deine Aussage oben ist gültig, es spielt keine Rolle ob das Tool "objektorientiert" ist an sich. Wir leben in 2021, die Tools haben sich massiv verändert und auch die Thematik KM. DMTF habe ich eingefügt, wobei der Link zu CMDBf.org nicht mehr geht, und auch nicht mehr gebraucht wird. Bin sehr froh von CMDB gelernt zu haben, was mir vorher (und ich kenne hunderte ISO-Normen, Gremien, etc.) nicht bekannt war. Ich mach den Kommentar zu. FG

Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 16:31, 14. Apr. 2021 (CEST)

--17387349L8764 (Diskussion) 16:31, 14. Apr. 2021 (CEST)

Überarbeiten

Warum muss dieser Artikel überarbeitet werden? Es fehlt der Link zu http://de.wiki.x.io/wiki/Configuration_Management_Database.

• Es fehlt z.B. eine Definition des Konfigurationsmanagements aus der Informatik.
• Es fehlt der Hinweis auf weitere Normen und Standards
• Sehr formale Beschreibung - es fehlen die praktischen Informationen

---

Na tolle Sache. Einfach hier ein paar Forderungen hinschreiben, aber selbst nichts dazu beitragen. Zum Beispiel finde ich die Definition bzgl. der Informatik völlig ausreichend. Warum soll auf weitere Normen verwiesen werden, wenn noch nicht einmal die Originalnorm (IEEE 1042?) genannt wurde? Des Weiteren sind Normen nun mal formal, für die praktischen Hinweise gibt es Bücher und sind die angesprochenen Dinge durchaus ausreichend. Nachtklavier

---

Ich möchte anmerken, dass die vermeintliche "Originalnorm" IEEE 1042 in Ihren Versionen lediglich Konfigurationsmanagement auf den Anwendungsbereich Software spezialisiert und somit ungeeignet ist, Konfigurationsmanagement als allgemein anwendbare Disziplin zu erklären. Ebenso finde ich die Abschnittsbezeichnung offizielle Definition unpassend, da keine offizielle Definition existiert. Wenn "offiziell" meint, einem Standard entsprechend, ist das Eingangszitat aus der ISO ebenso offiziell. ANSI ist zudem ein Industriestandard der eher die Rolle eine Substandards einnimmt.

Es könnte lediglich versucht werden, die Kerngedanken der relevanten Normen zu einer Quasi-Definition zu machen.

---

Die derzeitige Beschreibung geht stark von Software im Allgemeinen aus (Dokumente, HTML-Seiten, ...), obwohl die Definition am Anfang ausdrücklich auch die Hardware berücksichtigt. Das Problem mit der Hardware ist ja zunächst, dass sie als solche in keine Datenbank reinpasst und auch nicht so einfach kopiert werden kann. Welche Ansätze gibt es hier? Ist die Abstraktion der Maschine durch Beschreibung der Eigenschaften in einem Dokument die einzige? Wie wird die Hardware erfasst (Abstraktionsgrad)? Wie geht man mit minimalen Änderungen um (ein neuer Schalter = neue Version)? Welche Ansätze gibt es dann die Gesamt-Konfiguration (Hardware, Software, Dokumentation und Dienstleistung) zu identifizieren (wird jeweils hochgezählt)? -- thiemo68 14:36, 19. Jan. 2011 (CET) (ohne Benutzername signierter Beitrag von Thiemo.weiss (Diskussion | Beiträge) )

---

Ich finde den Gedanken von Thiemo.weiss prinzipiell gut: Es könnte lediglich versucht werden, die Kerngedanken der relevanten Normen zu einer Quasi-Definition zu machen. Aber widerspricht das nicht den Wikipedia Richtlinien?

Aktuell finde ich den Artikel sehr unverständlich. Hier sind unterschiedliche Begriffswelten vermischt, unterschiedliche Betrachtungsebenen (SW? Produkt? Dienstleistung?...) aneinandergereiht. Unter Kapitel ANSI Definition ist eine ISO aufgeführt. Viel Raum nehmen die konzeptionellen Teilgebiete ein, einen Beleg dafür sehe ich nicht. Unter Literatur wird ohne Kontext was zum Thema Requirements management aufgeführt. Aufgelisete Einzelnachweise sind teilweise keine Nachweise. Zweck der Auflistung von Versionsmanagement Werkzeugen sehe ich an dieser Stelle nicht (ist ein separates Thema). Auch die Auflistung von KM Werkzeugen hilft nicht den Artikel verständlicher zu gestalten. Am verständlichsten finde ich die Abschnitte Historie und Ziele, die jedoch ohne erkennbare Nachweise kommen.

Lösungsvorschlag: Prinzip des KM erläutern anhand einer ausgewählten Norm (z.b. ISO 10007:2017, die ist recht allgemein in Organisationen anwendbar). Auf andere Normen und deren abweichenden Scope/Fokus/Sprachgebrauch hinweisen. Auf Schnickschnack verzichten.

(ich kanns leider nicht selber machen, daher nur als Vorschlag)

Telematoxx (Diskussion) 17:35, 18. Okt. 2017 (CEST)

---

Hi, ich überarbeite derzeit einige SW-Artikel. Dieser KM-Artikel MUSS überarbeitet werden. Kaum inline-citations, schlechte Quellen, durcheinander, und teils veraltet. Da ihr (oben) bereits nicht mehr Benutzer seit (rote Benutzernamen?) oder unsigniert kommentiert, schließe ich diese Kommentare jetzt und setze mir eine Deadline, den Artikel zu überarbeiten zu wollen. Ich denke die EN Seite ist eine gute Vorlage, https://en.wiki.x.io/wiki/Configuration_management. Ich habe heute https://de.wiki.x.io/wiki/Distributed_Management_Task_Force überarbeitet, wer sich ein Beispiel nehmen will, der war extrem veraltet und ungepflegt. VG

Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 22:12, 14. Apr. 2021 (CEST)

CMII

CMII (Configuration Management II) geht ja noch einen Schritt weiter als CM. Bei CMII wird als Leitsatz "Dokumente führen" vorgegeben. Also im geschlossenen Changekreislauf erst die Requirements definieren, über das Change Board absegnen und erst dann umsetzen) Macht es Sinn, CMII hier mit unter CM als eigenen Abschnitt abzuhandeln oder sollte CMII einen eigenen Wikipedia-Eintrag bekommen?

Hi, ich kommentiere zu CM2 unten. Dieser Teil, da von 2007 und ohne Signatur wird als erledigt markiert.

Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 15:43, 14. Apr. 2021 (CEST)

CMII - eigene Rubrik

Da es sich bei CMII um die einzig standardisierte Methode (How-To) zum Thema Konfigurationsmanagement (engl. Configuration Management) handelt, würde es sich sicher lohnen, einene eigene Rubrik anzulegen. Vor allem auch, weil die Verbreitung stetig steigt. --Polione 11:07, 22. Feb. 2007 (CET)

Hallo, CM2 aus Siehe auch gelöscht. "Da es sich bei CMII um die einzig standardisierte Methode" Nein. Wo ist der Standard bitte, IEEE? ISO? IEC? Es gibt keine guten Inline-Citationen dazu, noch gibt es einen CM2-Artikel im Wiki-Space. Weiter, wenn man auf https://cmii.eu/ geht (was man über Suchemaschine findet), und dann Impressum klickt, gelangt man auf https://hosting.seo-nw.de/impressum.php was sehr seltsam ist. Dort steht z. B. "Die Methoden von CMII werden in der Software-Entwicklung, der Fertigungsindustrie und der Verwaltung eingesetzt.", aber ist das so? Wo sind die Referenzen, Papers, Bücher? CM2 habe ich auch im professionellen Kontext noch nie gehört. VG

Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 16:12, 14. Apr. 2021 (CEST)

--17387349L8764 (Diskussion) 16:12, 14. Apr. 2021 (CEST)

Unverständlich

Das Intro wirkt geschwollen und unverständlich, ich habe mal folgendes versucht:

Konfigurationsmanagement (KM) ist „eine Managementdisziplin, die organisatorische und verhaltensmäßige Regeln auf den Produktlebenslauf einer Konfigurationseinheit von seiner Entwicklung über Herstellung und Betreuung anwendet.“ (vgl. [DIN], S. 7). Konfigurationseinheit meint in diesem Zusammenhang eine beliebige Kombination aus Hardware, Software oder Dienstleistung. KM ist somit nicht per se an einen bestimmten Anwendungskontext gebunden. Konfigurationsmanagement geschieht innerhalb eines sogenannten Konfigurationsmanagement-Prozesses (KMP), dieser bedarf der Organisation und Planung (KMO).

Es sind vier Teilgebiete (Teilprozesse) des KM zu unterscheiden:

• Konfigurationsidentifizierung (KI),
• Konfigurationsbuchführung (KB),
• Konfigurationsüberwachung (KÜ) und
• Konfigurationsaudit (KA).

ihre koordinierte Umsetzung ist wesentlich für ein erfolgreiches Konfigurationsmanagement.

Ich habe dabei versucht, das was ich aus dem Text gelesen habe lesbarer zu formulieren. Aber ich habe im Prinzip nicht viel Ahnung vom Thema. Sollte mein Text völlig verballert sein, kann man an ihm zumindest nachvollziehen, was Menschen mitnehmen, die diese Version lesen. die Es wäre gut, wenn sich jemand der Sache annehmen könnte. Grüße --Peu 14:44, 9. Mär. 2009 (CET)

Gut und deswegen eingearbeitet! Grüße -- Nolispanmo Disk. Hilfe? 16:20, 10. Mär. 2009 (CET)

Hi, Artikel komplett überarbeitet und Stand der Technik. FG

Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 10:38, 23. Apr. 2021 (CEST)

--17387349L8764 (Diskussion) 10:38, 23. Apr. 2021 (CEST)

Systemkonfiguration

Es ist doch wohl ein Fehler, dass der Artikel auf Computer weiterleitet, oder? --Minihaa (Diskussion) 16:09, 27. Aug. 2012 (CEST)

Ich finde im Artikel das Wort "Computer" nicht. Unter Siehe auch gibt es keine Link. Markiere deinen Kommentar von 2012 daher als erledigt.

Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 15:44, 14. Apr. 2021 (CEST)

--17387349L8764 (Diskussion) 15:44, 14. Apr. 2021 (CEST)