Bei der Planung der Entwicklung eines AS ist es notwendig, die Arbeiten in der folgenden Reihenfolge durchzuführen:

eine Liste der Arbeiten zur Entwicklung des AS erstellen;

Bestimmen Sie die Zusammensetzung und Anzahl der Interpreten für jedes Werk.

die Reihenfolge und Beziehungen der Arbeit festlegen;

Bestimmen Sie die Komplexität und Dauer jedes Auftrags.

einen Arbeitsplan erstellen.

Die Ausgangsdaten für die Zusammenstellung eines Werkverzeichnisses zur Erstellung eines AS und die Festlegung der Zusammensetzung und Anzahl der ausübenden Künstler sollten in der Regel während der Vorstudienpraxis oder während der Entwurfsphase in der Organisation, in der die Arbeit ausgeführt wird, eingeholt werden. dieses Projekt. In diesem Fall ist es notwendig, die gesamte Liste der Arten von Arbeiten zur Erstellung eines AS abzudecken, ohne sich nur auf die vom Doktoranden persönlich erbrachten Arbeiten zu beschränken. In diesem Fall muss man davon ausgehen, dass der Doktorand als Hauptentwickler des Systems fungiert und während des gesamten Entwicklungszeitraums mit der Durchführung von Arbeiten beschäftigt ist. Zur Ausführung einzelne Arten andere Interpreten können an der Arbeit beteiligt sein. Für jede Art von Arbeit werden das Qualifikationsniveau der ausübenden Künstler (Positionen) und die Anzahl der ausübenden Künstler ermittelt. Die Komplexität der Ausführung jeder Arbeit wird von Experten in Manntagen bewertet und ist probabilistischer Natur, da sie von vielen Faktoren abhängt, die schwer zu berücksichtigen sind, daher Schätzungen der minimal möglichen Arbeitsintensität bei der Ausführung bestimmter Arten von Arbeiten - a j, das maximal mögliche - b j und das wahrscheinlichste - m j werden verwendet. Basierend auf diesen Werten wird der Erwartungswert der Arbeitsintensität nach folgender Formel geschätzt:

;

Die Dauer jedes Jobs D j wird durch die Formel Tage bestimmt:

wobei n j die Anzahl der Darsteller, Personen ist.

Expertenschätzungen und berechnete Werte der Arbeitsintensität und -dauer sind in der Tabelle zusammengefasst. 2.

Tabelle 2 – Schätzung der Arbeitsintensität einzelner Arbeitsarten.

Die Namen der Arbeiten zum Entwurf eines automatisierten Systems, die darin enthaltenen Aufgaben, die Beziehungen der Arbeiten, die Ausführenden, die Arbeitsintensität und die Dauer werden in eine Übersichtstabelle für die Planungsarbeiten eingetragen, für die ein Beispiel in der Tabelle aufgeführt ist. 3.

Tabelle 3 – Übersichtstabelle für die Arbeitsplanung

			Darsteller
Berufsbezeichnung		Die Arbeiten müssen vorher abgeschlossen sein	Berufsbezeichnung		Arbeitsaufwand, Personentage	Arbeitsdauer, Tage
	Entwicklung technischer Spezifikationen für die Entwicklung von AS		Chef
			leitender Ingenieur
	Algorithmenentwicklung Modul 1…		Programme.
	Kodierung Modul 1
	Debugging-Modul 1
	Testmodul 1
	Algorithmenentwicklung Modul 2…
	Kodierung Modul 2
	Debugging-Modul 2
	Testmodul 2
	Algorithmenentwicklung
	Kodierung Modul 3
	Debugging-Modul 3
	Testmodul 3
	Debuggen und Testen der Systemintegration
	Papierkram

Wenn die Liste nicht mehr als 10 Werke umfasst, erfolgt die Planung des Erstellungsprozesses eines AS auf der Grundlage von Streifendiagrammen. Bei der Planung komplexerer automatisierter Systeme wird ein Netzplan erstellt und die Apparatur von Netzplanungssystemen genutzt.

Das Netzwerkdiagramm wird unter Berücksichtigung der Reihenfolge und Zusammenhänge der Arbeiten (Tabelle 3) gemäß den Regeln zur Erstellung von Netzwerkmodellen erstellt. Ein Beispiel für ein Netzwerkdiagramm ist in Abbildung 1 dargestellt. Aktivitäten werden durch einen Pfeil angezeigt, Ereignisse durch einen Kreis. Jedes Ereignis hat eine Nummer, die nach dem Aufbau des Netzwerks vergeben wird.

Reis. 1 - Netzwerkdiagramm des Systementwicklungsprozesses

Die Dauer der AS-Entwicklung wird durch die Dauer des kritischen Pfads des Netzwerkdiagramms bestimmt.

Ein kritischer Pfad ist eine Abfolge von Vorgängen zwischen dem ersten und dem letzten Netzwerkereignis, die die längste Dauer hat.

Entwicklungsdauer automatisiertes System wird installiert, nachdem der Netzwerkplan erstellt wurde.

Zu diesem Zweck werden die Zeitparameter von Ereignissen und Operationen des aufgebauten Netzwerks berechnet.

FRÜHZEITIGE ABSCHLUSSFRIST DER I-TEN VERANSTALTUNG T pi – die Zeit, die erforderlich ist, um alle Arbeiten vor dieser Veranstaltung abzuschließen.

T r i = t[ L(Ii)max ],

wobei L(Ii) die Pfade sind, die vom Anfangsereignis I zum gegebenen Ereignis i führen.

t[ L(Ii)max ] – die Dauer des maximalen Pfades vom Anfangsereignis I bis zum gegebenen Ereignis i.

Die Dauer des kritischen Pfades t(L cr) ergibt sich aus der Formel:

t(Lcr) = t[ L(IС)max ],

wobei L cr der kritische Pfad ist;

L(IС) – Pfade, die vom Anfangsereignis I zum Endereignis C führen.

Verspätetes Abschlussdatum des i-ten Ereignisses Tpi ist der Zeitpunkt des Ereignisses, dessen Überschreitung zu einer ähnlichen Verzögerung beim Beginn des letzten Ereignisses führt.

T p i = t(L cr) - t[ L(iC)max ],

t[ L(iC)max ] – die Dauer des maximalen Pfades von einem gegebenen Ereignis i bis zum endgültigen C.

Die Zeitreserve des i-ten Ereignisses R i ist definiert als die Differenz zwischen dem späten und dem frühen Datum des Ereignisses i, d.h.

R i = Tpi – Tpi.

Die Zeitparameter der Arbeit zwischen den i- und j-Ereignissen des Netzwerkmodells sind wie folgt:

frühes Startdatum Tðij = Tði;

spätes Enddatum T poij = T pj ;

frühes Enddatum T роij = T рнij + t ij ;

spätes Startdatum T pnij = T poij - t ij ;

Vollzeitreserve Rпij = Tоij - Tоij;

Freizeitreserve Rсij = Tðj - Tроij,

wobei t ij die Arbeitsdauer ij ist.

Zeitliche Parameter von Ereignissen und Arbeiten werden in Form einer Tabelle dargestellt. 4.

Tabelle 4 – Temporäre Parameter des Netzwerkplans

	Paare auf Zeit Ereigniszähler				Temporäre Arbeitsparameter

Der Zeitplan für die Entwicklung des AS wird auf Basis der berechneten Zeitparameter des Netzwerks und des Zieltermins für den Entwicklungsbeginn  erstellt. Wenn diese Frist nicht angegeben ist, wird  gleich 0 angenommen.

Eine ungefähre Ansicht des Arbeitsplans ist in der Tabelle dargestellt. 5.

Tabelle 5 – Linearer Arbeitsplan

	Name			Kalender, Monate
			Anzahl, Tage
	Entwicklung technischer Spezifikationen für das KKW
	Auswahl eines Komplexes technische Mittel
	Papierkram

Wenn im Rahmen der Abschlussarbeit Software entwickelt wird, sollten die Fragen der Organisation, Erstellung und Nutzung von Softwareprodukten genauer betrachtet werden.

Der Zweck des Kbesteht darin, eine unkontrollierte Entwicklung des Projekts zu verhindern. Zur Regulierung des Kin verschiedenen Branchen wurden eine Reihe internationaler und nationaler Standards verabschiedet.

08.08.2013 Nikita Nalyutin

Der Zweck des Kbesteht darin, eine unkontrollierte Entwicklung des Projekts zu verhindern, indem sichergestellt wird, dass alle Änderungen gemäß der anerkannten Entwicklungstechnologie berücksichtigt und genehmigt werden. Zur Regulierung des Kin verschiedenen Branchen wurden eine Reihe internationaler und nationaler Standards verabschiedet.

Bei der Entwicklung von Softwaresystemen werden viele miteinander verbundene Objekte erstellt: Anforderungen, Quellcodes, Objektdateien, Testbeschreibungen usw. – koordinierte Sätze davon werden üblicherweise als Konfigurationen bezeichnet, und der Prozess der Aufrechterhaltung ihrer Änderungen und Integrität währenddessen Lebenszyklus Projekt - Konfigurationsmanagement. Der Hauptzweck der Einführung eines Kin ein Projekt besteht darin, eine unkontrollierte Entwicklung des Projekts zu verhindern und sicherzustellen, dass alle vorgenommenen Änderungen berücksichtigt und genehmigt werden. Das Konfigurationsmanagement umfasst Verfahren zur Identifizierung von Designelementen, zur Verwaltung von Änderungen und zur Aufrechterhaltung der Objektrückverfolgbarkeit sowie Aktivitäten zur Unterstützung von Zustandsprüfungen und zur Überwachung des Konfigurationsstatus.

Konfigurationsobjekt(Configuration Item, CI): Quellcodes, kompilierte Programme, Programmquellcodes, Dokumentation, Hardwareelemente, Verfahren und Schulungsmaterialien usw. - Basiskonzept Konfigurationsmanagementprozess Normalerweise fallen jedoch nur die Ergebnisse von Projektaktivitäten unter das Konfigurationsmanagement: Software und zugehörige Dokumentation, Schnittstellenanforderungen und -dokumentation, Ausgabedateien aus der Verwendung von Projekttools, Machbarkeitsdokumente und Benutzeranforderungsaufzeichnungen, Projektmanagementpläne, Tools und Benutzerhandbücher, Projektverlaufsaufzeichnungen, Testpläne, Verfahren und Beispiele für einzelne Testfälle.

Wenn Konfigurationsobjekte kombiniert werden, werden sie gebildet Aufbau- jede strukturierte Menge von Softwaresystem-Entwicklungsobjekten, dargestellt in Form von CI, oder eine Reihe von Prozessen und Technologieketten eines Projekts zur Entwicklung eines Softwaresystems, deren Beschreibungen auch in Form von CI dargestellt werden können. Der Konfigurationsmanagementprozess in verschiedenen Branchen wird durch internationale und nationale Standards geregelt: GOST R 51904, DO-178, AS9100, AS9006, ISO10007, ISO/IEC TR 15846, ISO/IEC 15408, IEEE 1042 usw. Bei der Entwicklung hochkritischer Systeme , ist der Einsatz des Kunbedingt erforderlich – die Kosten für die Behebung von Fehlern in solchen Systemen können sehr hoch sein.

Der Standard GOST R 51904 wurde 2002 vom staatlichen Standard Russlands übernommen und regelt die Anforderungen an die Entwicklung und Dokumentation eingebetteter Systeme. Darin wird der Konfigurationsmanagementprozess als eine Gruppe integraler Prozesse klassifiziert, die zur Sicherstellung der Qualität von Entwicklungsprozessen und deren Ausgabedaten erforderlich sind. Integrale Prozesse laufen parallel zu den Entwicklungsprozessen ab und bieten eine kontinuierliche Entwicklungsunterstützung. Die Hauptziele des Kgemäß GOST 51904 bestehen darin, Folgendes sicherzustellen:

• definierte und verwaltete Softwarekonfiguration über den gesamten Lebenszyklus;
• Integrität bei der Replikation ausführbaren Objektcodes für die Softwareproduktion oder, falls erforderlich, seiner Neugenerierung für Forschungs- oder Änderungszwecke;
• Verwaltung der Eingabe- und Ausgabedaten des Prozesses während des Lebenszyklus, was die Konsistenz und Wiederholbarkeit der Arbeit in Prozessen gewährleistet;
• ein Bezugspunkt für die Überprüfung, Statusbewertung und Änderungskontrolle durch die Verwaltung von Konfigurationselementen und die Festlegung einer Baseline;
• Sicherstellen, dass Mängeln und Fehlern Beachtung geschenkt wird und Änderungen aufgezeichnet, genehmigt und umgesetzt werden;
• Beurteilung der Übereinstimmung der Software mit den Anforderungen;
• Zuverlässige physische Archivierung, Wiederherstellung und Wartung von Konfigurationselementen.

Der Prozess ist in mehrere Teilprozesse unterteilt. Durch die Identifizierung werden jedes Konfigurationselement und nachfolgende Versionen eindeutig gekennzeichnet, um eine Grundlage für die Kontrolle und Referenzierung von Konfigurationselementen zu schaffen. Zu diesem Zweck wird ein Identifizierungsschema übernommen, das die Regeln für die Kennzeichnung verschiedener Arten von Konfigurationselementen, ihrer Version, Revision und ihres Status definiert. Der Teilprozess der Konfigurationskontrolle besteht aus der Festlegung einer Reihe von Regeln, die den Zugriff auf Konfigurationselemente verschiedener Benutzergruppen regeln, sowie der Protokollierung aller Aktionen zum Zugriff und zur Änderung von Konfigurationselementen.

Der nächste Teilprozess besteht darin, eine Entwicklungsbasislinie zu definieren, um eine „Momentaufnahme“ des Status der Konfiguration zu einem bestimmten Zeitpunkt zu erstellen. Die Grundlinie kann entweder als weiter verwendet werden ein Ausgangspunkt B. um neue Konfigurationen zu erstellen oder Systemelemente festzulegen, die der Zertifizierungsstelle zur Zertifizierung vorgelegt werden.

Im Prozess des Konfigurationsmanagements erstellen das Entwicklungsteam und andere Projektteilnehmer Fehlerberichte, die Beschreibungen von Inkonsistenzen des entwickelten Systems mit Anforderungen oder der Nichteinhaltung akzeptierter Standards durch Entwicklungsprozesse enthalten. Das Fehlerberichtsmanagement muss sicherstellen, dass Korrekturmaßnahmen zur Beseitigung von Mängeln qualitativ hochwertig und zeitnah durchgeführt werden.

Um eine spontane Weiterentwicklung des Systems zu verhindern, ist eine Änderungskontrolle erforderlich – alle daran vorgenommenen Änderungen müssen aufgezeichnet, bewertet, überprüft und genehmigt werden. Solche Änderungen verletzen nicht die Integrität des Systems und der Konfiguration. Gleichzeitig wird die Konfigurationsarchivierung durchgeführt – dies ist der wichtigste Teilprozess, der sicherstellt, dass alle CIs in der Konfiguration genehmigt und Änderungen daran autorisiert werden. Dies wird erreicht, indem die Zugriffsrechte auf CI abgegrenzt und Regeln für deren Änderung durch verschiedene Entwicklergruppen definiert werden. Der Entwickler kann nicht auf das CI zugreifen, es sei denn, dieser Zugriff wurde autorisiert.

Darüber hinaus sind auch Teilprozesse zur Meldung des Konfigurationsstatus notwendig

• um Entwicklungspläne und Engpässe zu ermitteln und Fristen festzulegen;
• Kontrolle des Software-Ladens, wodurch aus CI eine Konfiguration erstellt wird, die zur Veröffentlichung und/oder zum Laden in ein eingebettetes System bestimmt ist (dieser Konfiguration wird eine Registrierungsnummer zugewiesen und die Hardware, auf der das System laufen soll, wird bestimmt);
• Kontrolle der Lebenszyklusumgebung, um sicherzustellen, dass alle Projekttools identifiziert, verwaltet und kontrolliert werden und aus der Projektdatenbank abgerufen werden können.

Fast alle im GOST R 51904-Standard definierten Konfigurationsmanagementprozesse erfordern die Verfolgung des Lebenszyklusstatus von Objekten, die in der Konfiguration platziert sind. Konfigurationskontrolle impliziert also, dass sich der Zugriffsmodus auf CIs abhängig von ihrem Zustand ändern kann. Die Erstellung von Baselines erfolgt nur, wenn alle darin enthaltenen CIs einen bestimmten Status erreichen. Die Fehlermeldung wird auf der Grundlage von Informationen über den Status der Fehlermeldung und den Fehler selbst sowie darüber, ob er behoben wurde, verwaltet. Der Konfigurationsstatusbericht muss Informationen über CI-Status enthalten. Auch Archivierungskonfigurationen können ihren Zustand ändern. Der Prozess zur Überwachung der Softwarelast wird automatisiert, indem eine Basislinie von CIs erstellt wird, die einen bestimmten Status erreicht haben. Die Lebenszyklusumgebung wird anhand von Informationen über den Status der Projekttools und ob diese aktualisiert werden müssen, überwacht.

Im Kern basiert GOST R 51904, dessen Geltungsbereich alle eingebetteten Systeme umfasst, auf dem internationalen Standard DO-178, der bei der Entwicklung von Luftfahrtsystemen verwendet wird. Systeme, die nach dieser Norm entwickelt wurden, können zertifiziert werden, um die Lufttüchtigkeitsanforderungen zu erfüllen.

Im Allgemeinen zielt der im DO-178-Standard abgedeckte Konfigurationsmanagementprozess darauf ab, die Integrität der in allen Phasen des Produktlebenszyklus erstellten Daten aufrechtzuerhalten. Die Hauptspezifität des in dieser Norm geregelten Kbesteht darin, Aspekte der Lufttüchtigkeitszertifizierung zu berücksichtigen, die alle in Luftfahrzeugen verwendeten Software durchlaufen muss. Luftfahrtsysteme. Daten aus dem Konfigurationsmanagementprozess werden als primäre Daten von Interesse für Zertifizierungsbehörden verwendet, denen Konfigurationsindizes zur Verfügung gestellt werden – Listen eindeutig identifizierter Elemente (Quellcode, Datendateien, Objekt- und ausführbarer Code), die in der Software enthalten sind. Um die Qualität der Software zu bestätigen dieses Niveau Kritizität der Bordsoftware werden die Ergebnisse ihrer gemäß den Anforderungen dieser Stufe durchgeführten Tests vorgestellt. Die Konfiguration umfasst Verbindungen zwischen Anforderungen, Quellcodes, Tests, deren Ergebnissen und anderen Entwicklungsobjekten, was deren Nachvollziehbarkeit gewährleistet.

Um eine Zertifizierung zu erreichen, müssen alle Konfigurationselemente einen Status haben, der angibt, dass sie zur Zertifizierung bereit sind, und alle Probleme, die während der Entwicklung auftreten, müssen auf die eine oder andere Weise gelöst werden. Dieser Aspekt der Zertifizierung wird durch die Bereitstellung von Informationen zum Problemmanagement und die Aufnahme von Problemberichten und zugehörigen Änderungsanforderungen in den Konfigurationsindex unterstützt.

Aus der Sicht von ISO 10007 ist Konfigurationsmanagement eine Managementdisziplin, die während des gesamten Lebenszyklus eines Produkts angewendet wird, um Transparenz und Kontrolle über funktionale und physische Eigenschaften zu gewährleisten. Diese Aktivität ist eine Möglichkeit, bestimmte Anforderungen anderer internationaler Normen der ISO 9000-Reihe zu erfüllen. Gemäß dieser Norm umfasst der Konfigurationsmanagementprozess die folgenden Typen Aktivitäten: Konfigurationen identifizieren, Konfigurationen überwachen, Konfigurationsstatus melden, Konfigurationen überprüfen. Der Anwendungsbereich dieser Norm ist breiter als die der beiden vorherigen – nicht nur die Softwareentwicklung, sondern auch alle Ergebnisse der Unternehmenstätigkeit können nach den Grundsätzen des Konfigurationsmanagements verwaltet werden.

Darüber hinaus gibt es die Standards AS 9100/AS9006, die die Anforderungen des ISO-Qualitätsmanagementsystems speziell an die Luftfahrtindustrie anpassen.

Alle aufgeführten Standards (dargestellt in der Tabelle) stellen nahezu die gleichen Anforderungen an die CI-Identifizierung, Rückverfolgbarkeit und Statusberechnung. Generell lässt sich eine Tendenz zur Verschärfung der darin vorgegebenen Anforderungen feststellen, vor allem hinsichtlich der Integration von Entwicklungsprozessen und Managementaktivitäten.

Nikita Nalyutin([email protected]) - Qualitätssicherungsmanager, Experian (Moskau).

Viele Unternehmen implementieren Asset Management, bevor sie Configuration Management implementieren. Die Prozesse in diesem Abschnitt gelten sowohl für das Asset Management als auch für das Konfigurationsmanagement.

Die Kontrolle der IT-Infrastruktur und -Dienste über verteilte Systeme, mehrere Standorte und mehrere Supportteams hinweg erfordert eine sorgfältige Planung. Diese Planung sollte die Prozesse Change Management, Configuration Management und Release Management umfassen, da diese Prozesse voneinander abhängig sind. Es sollte über die Planung und Implementierung zentralisierter Change-Management-, Konfigurations-Management- und Release-Management-Prozesse nachgedacht werden, die von verteilten Teams unterstützt werden (siehe Anhang 7A).

7.5.1 Erstplanung.

Zu den Aktivitäten für die Erstplanung eines Konfigurationsmanagementprojekts gehören:

■ Einigung über die Ziele, Ziele, Umfang, Prioritäten und Vorgehensweise zur Implementierung des Konfigurationsmanagementprozesses;.

■ Ernennung einer Person, die für die Prozesse und Systeme des Konfigurationsmanagements verantwortlich ist;

■ Analyse bestehende Systeme Konfigurations-, Daten- und Prozessmanagement;

■ Entwicklung eines allgemeinen Konfigurationsmanagementplans (der in die Änderungsmanagement- und Konfigurationsmanagementpläne der Organisation einbezogen werden kann) und eines Projekts zur Erstellung eines Konfigurationsmanagementsystems;.

■ Planung und Beschaffung von Finanzmitteln für Konfigurationsmanagement-Tools und Zusagen zur Bereitstellung zusätzlicher Ressourcen;

■ Einigung über Unternehmensrichtlinien und -prozesse erzielen und die Punkte identifizieren, die während der Bereitstellung „maßgeschneidert“ werden.

Für alle außer den kleinsten Systemen sind Tools zur Unterstützung des Änderungsmanagements und des Konfigurationsmanagements besonders erforderlich, da papierbasierte Systeme unpraktisch sind. Das Hosten von Konfigurationsmanagement-Tools, insbesondere der CMDB, erfordert Hardware- und Speicherressourcen. Support-Tools müssen mindestens die Übertragung von Daten aus einzelnen Systemen ermöglichen. Projektmanagement Konfigurationen" ohne erneute Eingabe. Im Idealfall sollten Konfigurationsmanagement-Tools für ein System in der Produktion und für Projekte in der Entwicklung integriert funktionieren.

Sobald der allgemeine Konfigurationsmanagementplan vereinbart und unterzeichnet wurde, kann mit der Implementierungsplanung begonnen werden. Es wird eine schrittweise Implementierung empfohlen, beginnend mit einem klar definierten Dienst und Unternehmensdaten. Dadurch können Vorteile früher nachgewiesen werden und die Wirksamkeit nachgelagerter Implementierungsbemühungen verbessert werden.

7.5.2 Ausrichtung von Zweck, Zielen, Umfang, Prioritäten und Umsetzungsansatz entsprechend den Geschäftsanforderungen.

Der Zweck, die Ziele, der Umfang und die Prioritäten des Konfigurationsmanagements müssen mit dem Service Manager und anderen Managern vereinbart werden und mit den Geschäftsanforderungen übereinstimmen. Es sollte eine Vereinbarung darüber getroffen werden, ob dieser Prozess mit Change Management und Release Management zentralisiert wird.

Der Zweck und Umfang kann wie folgt sein:.

Implementieren Sie Konfigurationsmanagement-, Änderungsmanagement- und Release-Management-Prozesse konsistent in allen Betriebsumgebungen, Paketanwendungen und Geschäftssystemen.

Die Aufgabe könnte wie folgt aussehen:.

Schaffen Sie die Kontrolle über alle IT-Dienste und Infrastrukturkomponenten sowie die zugehörige Dokumentation und stellen Sie Informationsdienste bereit, um die effektive und effiziente Planung, Vorbereitung und Umsetzung von Änderungen an IT-Diensten zu erleichtern.

Detaillierte Aufgaben für das Konfigurationsmanagement sollten Folgendes umfassen:

■ Bereitstellung korrekter und genauer Informationen über bestehende Konfigurationen und deren physische und funktionale Spezifikationen für alle, die in den Service-Management- und Support-Prozessen arbeiten;

■ Definition und Dokumentation der einzuhaltenden Verfahren und Arbeitsreihenfolge;

■ Identifizierung, Kennzeichnung und Aufzeichnung der Namen und Versionen der CIs, aus denen die IT-Dienste, die Infrastruktur und ihre Verbindungen bestehen;.

■ Berichterstattung über den aktuellen Status und die Historie aller Elemente der IT-Infrastruktur;.

■ Sicherstellen, dass alle Änderungen am UE so schnell wie möglich aufgezeichnet werden;

■ Verfolgung und Anpassung aller Konfigurationsaufzeichnungen und Konfigurationsdaten an den tatsächlichen Zustand der IT-Infrastruktur;.

■ Schulung und Durchführung von Schulungen zu Kontrollprozessen in der Organisation;.

■ Berichterstattung über Kennzahlen im Zusammenhang mit CIs, Änderungen und Releases;.

Prüfung und Meldung von Verstößen gegen Infrastrukturstandards und Konfigurationsmanagementverfahren.

Für viele Organisationen ist ein stufenweiser Ansatz zur Umsetzung, einschließlich Change Management, besonders wichtig. Der Implementierungsansatz kann nach Organisationseinheiten, nach Standort, nach Kundengruppen, nach Supportgruppen oder nach einem anderen Merkmal definiert werden. Einige Organisationen geben Implementierungsprioritäten nach Art der kontrollierten CEs an.

Die höchsten Prioritäten können für folgende Typen angegeben werden:.

In Infrastrukturunterstützungsservern;.

In Mainframe-Systemen;.

Zu Datenbanken von Kunden und Lieferanten;.

In Betriebsumgebungen und Anwendungen, die regulierte Geschäftssysteme unterstützen.

Bei geschäftskritischen Diensten;.

In Workstation-Baugruppen und Softwarelizenzen;.

Alle diese Prioritäten müssen in Bezug auf die Verfahren und die Reihenfolge, in der Änderungen in den verschiedenen Gruppen durchgeführt werden, ausgewogen sein. Für Teams ist es schwierig, mehrere Change-Management- und Konfigurationsmanagement-Prozesse gleichzeitig zu implementieren, außer für kurze Zeiträume.

Supportkosten müssen basierend auf den Hardwareanforderungen geplant werden. Obwohl Tools in der Lage sind, die Arbeit von Incident Management, Change Management, Konfigurationsmanagement, Release Management, Problem Management usw. zu integrieren Dienstleistungen Desk kostet möglicherweise deutlich mehr als „einfache“ Konfigurationsmanagement-Tools. Die zusätzlichen Kosten werden häufig durch den höheren Integrationsgrad gerechtfertigt. Für größere Organisationen sind diese Managementprozesse ohne geeignete Unterstützungstools nahezu unmöglich.

7.5.3 Ernennung des Konfigurationsmanagers und Planung des Konfigurationsmanagementteams.

Es ist möglich, ein Funktionszentrum einzurichten, das für die Verwaltung von Änderungen an Hardware, Kommunikationsgeräten und -software, Systemsoftware, Anwendungssoftware im Betrieb sowie allen Dokumentationen und Verfahren verantwortlich ist, die mit dem Betrieb, der Unterstützung und der Wartung im Betrieb verbunden sind Systeme. Empfehlungen zur Einrichtung eines Funktionszentrums sind in Anhang 7A beschrieben.

Der Konfigurationsmanagementprozess erfordert von den beteiligten Mitarbeitern harte Arbeit und Liebe zum Detail. Das Support-Center benötigt Personal (außer bei kleinen Organisationen). Bei der Personalplanung für das Konfigurationsmanagement sollten folgende Faktoren berücksichtigt werden:

■ Ist es möglich, dass das Personal des Konfigurationsmanagements mit anderen Aufgaben beschäftigt ist, oder ist die volle Aufmerksamkeit engagierter Spezialisten erforderlich?

■ wird die Konfigurationsmanagementgruppe für Projekte sowie IT-Infrastruktur und -Dienste verantwortlich sein?

■ ob diese Gruppe Teil eines gemeinsamen Change-, Konfigurations- und Release-Management-Teams sein wird;

■ die Größe der IT-Infrastruktur, die Ebene, auf der die Kontrolle aufrechterhalten werden muss, und daher die Anzahl der CIs, die kontrolliert werden müssen;.

■ die Anzahl des Personals, das Kontrollaktivitäten in anderen Gruppen und Projekten durchführen wird;.

■ Verfügbarkeit von Support-Tools;.

■ die Größe, Häufigkeit und Komplexität von Änderungen und Veröffentlichungen.

Für das Konfigurationsmanagement müssen Rollenspezifikationen entwickelt werden. Beispiele für Verantwortlichkeiten sind in Anhang 7B aufgeführt. Zu den typischen Rollen gehören Konfigurationsmanager und Konfigurationsbibliothekar. Es ist notwendig, so früh wie möglich einen Konfigurationsmanager zu ernennen und weitere Schlüsselrollen zu definieren, da zugewiesene Mitarbeiter als wichtige Geschäftsbenutzer in die Implementierung eingebunden werden.

7.5.4 Analyse bestehender Systeme.

Sogar Organisationen, die in ihrem Betrieb keine Prozesse verwenden, verfügen über Konfigurationsmanagementprozesse und -verfahren. Sie können in andere Verfahren eingebettet oder einer bestimmten Gruppe zugeordnet sein. Wenn eines Ihrer Ziele darin besteht, ein gemeinsames Konfigurationsmanagementsystem zusammen mit den zugehörigen Prozessen zu implementieren, ist es wichtig, Folgendes zu identifizieren und zu analysieren:

■ Besitzer von hochrangigen UE;.

■ aktueller Prozessumfang und Ressourcen ( Personalwesen und Automatisierungstools).

■ aktuelle Verfahren, Prozesse und Abläufe für Change Management und Configuration Management;.

■ verallgemeinerte Konfigurationsdaten für aktuelle Ausstattungslisten, gedruckte Materialien, lokale Tabellen oder Datenbanken;.

■ die Rollen, Verantwortlichkeiten und Fähigkeiten des am Konfigurationsmanagement beteiligten Personals.

7.5.5 Entwicklung von Konfigurationsmanagementplänen und Systemdesign.

Bei einigen Technologien und Plattformen kann das Konfigurationsmanagement im gesamten Unternehmen verteilt sein, beispielsweise auf Mainframe-Systemen, Netzwerken und Workstations. Eine Reihe von Organisationen delegieren die Kontrolle an Supportteams, die Experten für eine bestimmte Technologie oder Plattform sind, da es nicht kosteneffektiv ist, zentrales Personal in speziellen Bereichen zu schulen. In diesen Fällen ist der Support-Gruppenmanager für die Überwachung der Buchhaltungselemente verantwortlich, die dieser Gruppe gehören und von ihr verwaltet werden. Wo immer möglich sollten Verfahren für Change Management, Configuration Management, Release Management und eine zentrale CMDB eingesetzt werden. Diese Verfahren können im Änderungs- und Konfigurationsmanagementplan der Organisation (siehe Anhang 7 A) definiert und durch betriebliche und betriebliche Maßnahmen unterstützt werden Projektdokumentation für das Konfigurationsmanagementsystem. Die Verbindungen zwischen diesen Plänen sollten dokumentiert werden, um den Mitarbeitern zu helfen, den Kontext des Konfigurationsmanagements so zu verstehen, wie er für ihr Team gilt. Jeder Gruppenleiter muss diesen Plan unterzeichnen. Ein Beispiel für Verbindungen ist in Abbildung 7.2 dargestellt.

Detaillierte Pläne Um Wiederholungen zu vermeiden, sind die allgemeinen Pläne einzuhalten und darauf Bezug zu nehmen.

Es kann Situationen geben, in denen die Verantwortung für das Konfigurationsmanagement auf verschiedene Abteilungen (innerhalb der Organisation) übertragen wird, die über die entsprechenden Qualifikationen verfügen. Wenn die Ressourcen es zulassen, ist es jedoch im Idealfall besser, über ein Funktionszentrum zu verfügen, das einheitliche Prozesse und Verfahren bereitstellt. Die Delegation von Verantwortlichkeiten hingegen erfordert eine sorgfältige Verwaltung und regelmäßige Audits. Es ist wichtig, immer nur einen Prozessverantwortlichen zu haben – und dies wird noch wichtiger, wenn mehrere getrennte Teams Konfigurationsmanagementaktivitäten durchführen.

Abbildung 7.2 – Beispiele für Konfigurationsmanagementpläne in einer Organisation.

Konfigurationsmanagementpläne definieren den Umfang des Konfigurationsmanagements, der während des Systementwurfs und der nächsten Planungsphase erforderlich ist.

7.5.6 Detaillierte Umsetzungsplanung.

Sobald wichtige Entscheidungen über den Umfang des Konfigurationsmanagements getroffen wurden und die Planung abgeschlossen ist, muss ein Implementierungsplan für das Konfigurationsmanagement entwickelt werden. Sofern es sich bei dem betreffenden Gebiet nicht um Neuland handelt, sind wahrscheinlich bereits einige Verfahren und Aufzeichnungen vorhanden. Dies müssen Sie bei der Planung Ihrer Umsetzung berücksichtigen.

Die Hauptaktionen sind wie folgt:.

■ das bestehende Ksowie seine Interaktion mit anderen Prozessen des Servicemanagements, der Beschaffung und Entwicklung genauer analysieren;

■ Analysieren Sie die Fähigkeiten bestehender Abteilungen und Mitarbeiter, die am Konfigurations-, Änderungs- und Release-Management beteiligt sind.

■ Konfigurationsdaten überprüfen, die in gedruckter Form, lokalen Tabellenkalkulationen oder Datenbanken enthalten sind, und eine Strategie für die Übertragung/das Herunterladen dieser Daten entwickeln;

■ Anforderungen und Funktionsspezifikationen sammeln, überprüfen und eine Einigung darüber erzielen;.

■ Kriterien für die Auswahl von Anbietern von Konfigurationsmanagement-Automatisierungstools entwickeln;.

■ CMDB- und Konfigurationsmanagement-Automatisierungstools bewerten und auswählen;

■ CMDB- und Konfigurationsmanagement-Automatisierungstools kaufen und installieren;.

■ Erstellen eines detaillierten Entwurfs des Konfigurationsmanagementsystems, einschließlich Schnittstellen zu Change Management, Release Management, anderen Service Management-Prozessen, Beschaffung und Entwicklung;.

■ Bestimmen Sie die Arten von UEs, ihre Attribute, Arten von Beziehungen und verallgemeinerte UEs.

■ Entwicklung von Geschäftsprozessen und -verfahren für das Konfigurationsmanagement, die in Tools für das Konfigurationsmanagement integriert sind;

■ Überprüfen Sie die CMDB und andere Support-Tools und lassen Sie ausreichend Zeit, um Probleme zu beheben, auch solche, die geringfügiger sind und den erfolgreichen Betrieb nicht beeinträchtigen. Sie müssen auch vor der Implementierung des Konfigurationsmanagements beseitigt werden.

■ Planung und Bereitstellung sicherer UE-Repositorys (z. B. Schränke, kontrollierte Bibliotheken und Kataloge) in Verbindung mit Release Management;.

■ Entwicklung und Einigung über Rollen, Verantwortlichkeiten und Schulungspläne;.

■ Erklären Sie Ihren Mitarbeitern die Bedeutung von Change Management und Configuration Management und schulen Sie sie in der Anwendung dieser Prozesse.

Möglicherweise ist zusätzliches Personal erforderlich, um das Konfigurationsmanagement zu implementieren, die vorhandene Infrastruktur zu prüfen und CMDB-Daten zu füllen. Manchmal beauftragt das Management Mitarbeiter mit der Unterstützung bei diesen Aufgaben, wenn es die Vorteile des Konfigurationsmanagements erkennt und die Personalressourcen im Voraus geplant sind.

Durch die Planung einer schrittweisen Implementierung des Konfigurationsmanagements können Sie die Vorteile früher erkennen und den Bedarf an Finanzmitteln und Ressourcen in späteren Phasen rechtfertigen. Für jede Phase müssen Sie die folgenden Aktionen planen:.

■ Planen Sie Orientierungsschulungen für wichtiges Personal, das am Konfigurationsmanagement beteiligt ist.

■ Konfigurationsmanagementpläne für jede Gruppe oder Technologie identifizieren und entwickeln und bei Bedarf lokale Verfahren erstellen;

■ Analysieren, Entwerfen und Zusammenstellen von Konfizur Unterstützung von Kund allen damit verbundenen Prozessen, Schnittstellen und Daten;

■ Evaluierung und Festlegung aktualisierter Mitarbeiterrollen und Verantwortlichkeiten, einschließlich Konfigurationsmanagement-Prozessaktivitäten;

■ Registrierungsverfahren für neue UEs entwickeln und planen und so früh wie möglich mit deren Umsetzung beginnen (vorzugsweise bevor Daten zu bestehenden UEs gesammelt werden);

■ Laden Sie die Erstkonfiguration und die zugehörigen Konten in das Konfigurationsverwaltungssystem hoch.

■ Schulung des Personals kurz vor der Nutzung neuer Verfahren und Software;

■ Beginn des kommerziellen Betriebs und Unterstützung bei der Umsetzung;.

■ weiterhin die CMDB und die Referenzsoftwarebibliothek füllen; Der längste Teil der Implementierung besteht darin, Informationen über das UE zu sammeln und die CMDB und die Definitive Software Libaray (DSL) zu füllen.

■ Überwachen Sie den Fortschritt, um eine effektive und effiziente Nutzung neuer Verfahren und Software sicherzustellen.

Wenn das Konfigurationsmanagement zur Unterstützung der Ausführung anderer Prozesse, beispielsweise des Incident Managements, verwendet wird, ist zusätzliche Planung erforderlich, um diese Systeme parallel bereitzustellen. Lokale Konfigurationsmanagementpläne können Prozesse zur spezifischen Identifizierung und Steuerung von CIs definieren Technologiekonzerne. Der Teamleiter kann einen Konfigurationsmanager ernennen, der für den lokalen Konfigurationsmanagementplan verantwortlich ist und mit den Mitarbeitern des zentralen Konfigurationsmanagements sowie als Vertreter im Change Advisory Board (CAB) kommuniziert.

Planen Sie, die CMDB zu füllen, während Sie eine Bestandsaufnahme für jede Phase der Implementierung durchführen. Für die korrekte Erledigung dieser Aufgaben muss Zeit eingeplant werden. Erwägen Sie für solche Aufgaben den Einsatz von Zeitarbeitskräften mit Dateneingabekenntnissen. Wenn es die Zeit erlaubt, kann die Durchführung dieser Aufgaben den Mitarbeitern des Konfigurationsmanagements jedoch die Möglichkeit bieten, sich besser mit der Verwendung von Support-Tools vertraut zu machen. Wenn für andere Zwecke ein Teil der Daten bereits vorhanden ist im elektronischen Format, erwägen Sie eine Neuformatierung und Migration dieser Daten.

Idealerweise sollte der Status des CI beim Befüllen der CMDB „eingefroren“ oder „ausstehend“ sein, dies ist jedoch möglicherweise nicht praktikabel. Sobald das Konfigurationsmanagement jedoch Daten zu bestimmten CIs gesammelt hat, müssen diese CIs sofort unter die Kontrolle des Konfigurationsmanagements gebracht werden. In diesem Fall ist es möglich, die CMDB schrittweise zu füllen (d. h. mit der Hardware beginnen und dann schrittweise zu Software und Netzwerken übergehen), siehe Abschnitt 7.5.7.

Es kann sein, dass die Übertragung von Artikeln in die Steuerung des Konfigurationsmanagements aufgrund der Inbetriebnahme der Geräte nicht möglich ist. In diesen Fällen ist es notwendig, Verfahren zu planen, um Änderungen zu verfolgen und aufzuzeichnen, die von der Inbetriebnahme des Geräts bis zum Beginn der Konfigurationsmanagement-Kontrolle (d. h. bis zum Abschluss der Bestückung der CMDB) auftreten.

Sobald alle vorbereitenden Arbeiten abgeschlossen sind, müssen die Mitarbeiter für den Go-Live an einem vereinbarten Tag und zu einer vereinbarten Uhrzeit mit der Nutzung der neuen Verfahren beginnen. Machen Sie Datum und Uhrzeit der Implementierung neuer Verfahren den Betroffenen bekannt, insbesondere allen IT-Supportmitarbeitern, externen Anbietern und Dienstleistern. Das Personal sollte von Beginn seiner Arbeit an an seine Verantwortung erinnert werden, die neuen Verfahren einzuhalten.

7.5.7 CMDB und DSL füllen.

UEs müssen unter die Kontrolle des Konfigurationsmanagements gebracht werden, sobald Daten über sie erfasst wurden. Ohne die Kontrolle des Konfigurationsmanagements sollten keine neuen Elemente zur IT-Infrastruktur hinzugefügt werden.

Die ideale Möglichkeit zum Befüllen der CMDB besteht darin, Änderungen beim Befüllen der CMDB „einzufrieren“. Dann unterliegen alle Änderungen der Kontrolle des Konfigurationsmanagements. Dies ist möglicherweise nicht immer praktikabel, aber es ist dennoch eine Möglichkeit, die in Betracht gezogen werden sollte. Konfigurationsmanagement und Änderungsmanagement arbeiten zusammen – tatsächlich ist es sehr schwierig, einen Prozess ohne den anderen aufzubauen. Sobald die CMDB gefüllt ist, muss ein gewisses Maß an Änderungsmanagement bereitgestellt werden, um den Konfigurationsdatensatz und die Konfigurationsdaten zu aktualisieren.

Wenn dieser Ansatz nicht möglich ist, ist es wichtig, alle Änderungen aufzuzeichnen, die zwischen der Erfassung der CI-Daten, der anschließenden Eingabe dieser Daten in die CMDB und der Übertragung des CI an die Koauftreten. Um dies zu erreichen, sollte das Intervall zwischen diesen Stufen für jedes UE minimiert werden. Zunächst sollten Änderungsanfragen (RFCs) und Release-Datensätze gesammelt werden, die sich auf Änderungen beziehen, die noch nicht implementiert wurden. Alle weiteren RFCs müssen in der CMDB enthalten sein. Mit diesem Ansatz kann die CMDB zur Aufzeichnung aller nachfolgenden Change-Aktivitäten, einschließlich Autorisierung und Implementierung, verwendet werden. Die Sammlung aller erforderlichen historischen Aufzeichnungen kann beiseite gelegt werden, um sie zu einem geeigneten Zeitpunkt abzuschließen.

Der Release-Management-Prozess sollte die Reference Software Library (DSL) parallel zur Implementierung der CMDB füllen. Es sind Verfahren erforderlich, um sicherzustellen, dass:.

■ dass diese DSL-gehostete Software geschützt ist;

Sobald das erforderliche Personal, die Hardware und der Support vorhanden sind und alle erforderlichen Schulungen abgeschlossen sind, müssen die DSL- und Build-Umgebung erstellt werden. Es sollten Zugriffsrechte festgelegt werden, um sicherzustellen, dass nur autorisiertes Personal darauf zugreifen kann. Die DSL- und Build-Umgebung muss anhand der in der Planungsphase definierten Kriterien getestet werden.

Das an Projekten sowie an der Anwendungsentwicklung und dem Support beteiligte Personal muss darüber informiert werden, wann mit der Lieferung des Materials begonnen werden soll und an wen es zur Aufnahme in die DSL gesendet werden soll. Es ist notwendig, die Speicherung bestimmter kommerzieller Standardsoftware in einer CMDB und DSL zusammen mit der zugehörigen Dokumentation (z. B. Lizenzen) zu organisieren.

Die Implementierung der Zusammenstellung, Verteilung und Inhaltsverwaltung sollte einige Zeit nach der Erstellung des DSL erfolgen. Diese Verfahren sollten vor ihrer Verwendung getestet werden. Bei Verwendung eines phasenweisen Ansatzes erfolgt der erste Build eines Release, wenn das ausgewählte Projekt oder die Ergebnisse des Anbieters in die Phase der betrieblichen Abnahmetests eintreten. Wenn Releases an die Produktionsumgebung übermittelt werden müssen, sind die Build- und Release-Kontrollverfahren bereits vorhanden, um die Software in die betriebliche Abnahmetestumgebung zu übertragen. Daher stellt dies eine weitere Gelegenheit dar, viele Arten potenzieller Probleme im Zusammenhang mit Verfahren und Software zu identifizieren und zu beseitigen.

Hierzu müssen jedoch Aktionspläne erstellt werden Notfallsituationen im Falle des Scheiterns neuer Verfahren und Mittel. Wenn ein Software-Release dringend erforderlich ist, kann es notwendig sein, vorübergehend zu alten Verfahren zurückzukehren, bis die neuen Verfahren korrigiert sind. Es wird empfohlen, Testverfahren und Tools für die Softwareverteilung nach Möglichkeit von Tools für die Installation und das Testen von Software vor Ort zu trennen, damit mit jeder dieser Phasen verbundene Probleme isoliert und separat gelöst werden können.

Obwohl Verfahren gründlich getestet werden sollten, bevor sie in Betrieb genommen werden, muss sich Zeit genommen werden, Konflikte und Probleme im Zusammenhang mit Innovationen frühzeitig im Betrieb zu lösen.

7.5.8 Umstellung auf neue Prozesse.

Die Umstellung auf neue Prozesse kann parallel zur Befüllung der CMDB und DSL erfolgen. CIs können schrittweise unter die Kontrolle des Konfigurationsmanagements gebracht werden, indem Daten über CIs gesammelt und in der CMDB aufgezeichnet werden. Alle Änderungen an Buchhaltungspositionen, die noch nicht unter die Kontrolle des Konfigurationsmanagements fallen, müssen an die zentrale Stelle gemeldet werden. Wenn möglich, sollten CIs, die von der Änderung betroffen sind, sofort unter Kontrolle gebracht werden. Alle UEs, die nach dem Start des Konfigurationsmanagementsystems erschienen sind, müssen sofort prozessgesteuert übertragen werden.

In vielen Fällen können Verfahrensmetriken und der Einsatz von Automatisierungstools für einige Konfigurationskontroll-, Freigabe-, Verteilungs- und Prüfprozesse eine Rückkehr zu einem früheren Verfahren oder einer vorherigen Reihenfolge verhindern oder zumindest erkennen.

Nach Inbetriebnahme neues System Das Konfigurationsmanagement ist von entscheidender Bedeutung, um sicherzustellen, dass ohne die Autorisierung des Konfigurationsmanagements keine neuen Elemente zur IT-Infrastruktur hinzugefügt werden. Hierzu sind Schnittstellen zu Entwicklungs-, Akquisitions- oder Materialbeschaffungsprozessen erforderlich. Vorhandene Elemente unter der Kontrolle des Konfigurationsmanagements (d. h. alle CIs mit Ausnahme derjenigen, die aufgrund der schrittweisen Implementierung vorübergehend nicht berücksichtigt werden) sollten nicht ohne Genehmigung geändert werden. Alle nicht autorisierten Versionen des CE und des CE selbst müssen entweder entfernt oder unter der Kontrolle des Konfigurationsmanagements übertragen werden.

7.5.9 Sonstige Probleme im Zusammenhang mit der Umsetzung.

Das Konfigurationsmanagement für Infrastruktur und Dienste erfordert eine gute Planung und Gestaltung, um sicherzustellen, dass die Ziele erreicht und die erwarteten Vorteile erzielt werden.

Um effektiv arbeiten zu können, erfordert das Konfigurationsmanagement ein langfristiges Engagement des Managements und der Mitarbeiter. Voraussetzung für eine erfolgreiche Umsetzung ist eine ausreichende Anzahl geschulter Mitarbeiter. Herrscht in der für das Konfigurationsmanagement zuständigen Einheit ein Personalmangel oder sind die Mitarbeiter nicht ausreichend geschult, kann dies zu einem Engpass bei der Umsetzung des Prozesses führen und zu kritischen Fehlern führen, deren Behebung unter Umständen mehr kostet Kosten für die Bezahlung qualifizierter Mitarbeiter. Während der Projektumsetzung kann für kurze Zeit zusätzliches Personal erforderlich sein (z. B. zur Unterstützung bei der Inventarisierung und/oder zum Auffüllen der CMDB).

Es wird empfohlen, das Konfigurationsmanagement schrittweise einzuführen, beginnend bei den CI-Typen oder den Teilen der IT-Infrastruktur, bei denen die Kontrolle am wichtigsten ist oder bei denen der größte Verbesserungsbedarf besteht, und das System dann auf andere Bereiche auszuweiten.

Angesichts der Komplexität von IT-Systemen und -Diensten ist es wichtig, sicherzustellen, dass das Konfigurationsmanagementsystem unterstützt wird, da sonst Konfigurationsdaten schnell irrelevant und nicht mehr vertrauenswürdig werden. Um dies sicherzustellen, müssen Analysen und Prüfungen der Aktivitäten geplant werden.

■ Prüfung der Konfigurationsmanagementaktivitäten auf ihre Übereinstimmung mit den Konfigurationsmanagementplänen;.

■ ein ausreichender (wenn auch nicht zu detaillierter) Satz von CIs unter Konfigurationsmanagement, um Kontrolle bereitzustellen und.

Unterstützung effektives Management Probleme, Änderungsmanagement und Release-Management;.

■ Verfügbarkeit von Ressourcen und ausreichende Qualifikationen des Personals zur effektiven Durchführung von Konfigurationsmanagementaktivitäten;.

■ ein ausreichender Automatisierungsgrad, um die Anzahl arbeitsintensiver Aktionen und Aktionen mit hoher Fehlerwahrscheinlichkeit zu reduzieren;.

■ Das IT-Service-Management-Personal hat ständigen Zugriff auf aktualisierte, genaue und vollständige Konfigurationsaufzeichnungen und Konfigurationsdaten.

7.5.10 Kosten.

Die durch die Implementierung des Konfigurationsmanagements erzielten Vorteile werden die Kosten überwiegen. Beispielsweise können viele Organisationen ihre Aufgaben nicht zufriedenstellend erfüllen, wenn sie nicht in der Lage sind, eine große Menge an Software- und Hardwareänderungen ohne Qualitätsverlust zu bewältigen. Ohne entsprechende Kontrollen sind Unternehmen dem Risiko von Computerbetrug, versehentlicher Softwarebeschädigung, Softwareviren und anderer Software, die in böswilliger Absicht verwendet wird, ausgesetzt. Die Reparatur von Schäden, die aus den oben genannten Gründen verursacht wurden, kann viel Geld kosten.

Zu den mit der Implementierung einer Konfigurationsmanagementeinheit verbundenen Kosten gehören Personalgehälter und Gemeinkosten, Supporttools, Teamraumkosten und Schulungskosten. Während der Anfangszeit Betriebskosten kann das normale Niveau überschreiten, während das Personal die Verfahren erlernt.

Die praktische Anwendung von Change Management und Configuration Management wird zu einer verbesserten Servicequalität führen, die alle Gemeinkosten mehr als ausgleicht. Die Gemeinkosten hängen von vielen Faktoren ab, darunter:

■ Personalkosten für die Entwicklung und Implementierung von Verfahren;.

■ Identifizierung von Hardware- und Softwarekonfigurationen und der Grad der Kontrolle darüber;.

■ Hardware und Software für CMDB und DSL, inklusive Kosten für Lizenzen und Wartung;.

■ spezielle Konfigurationsmanagement-Software für jede Plattform, einschließlich der entsprechenden AO;.

■ die Anzahl der Benutzer, die Zugriff auf das Konfigurationsmanagementsystem benötigen, und der Standort dieser Benutzer;.

■ die Notwendigkeit, das Konfigurationsmanagementsystem neu aufzubauen, um den Anforderungen der Organisation gerecht zu werden;.

■ die Notwendigkeit, Konfigurationsmanagement-Tools und Service-Management-Tools zu integrieren;.

■ die Vielfalt und Qualität der vorhandenen Informationen, die in die CMDB geladen werden müssen.

Mit der erstmaligen Datenerhebung können zusätzliche Personalkosten verbunden sein. Begehen Sie jedoch nicht den Fehler, die Personalkosten für Change- und Konfigurationsprozesse als Gemeinkosten einzustufen! Wenn bisher kein Konfigurationsmanagement durchgeführt wurde, ist mit einem Anstieg des Personalbedarfs zu rechnen. Die Korrektur vermeidbarer Prozesse wird einige Zeit in Anspruch nehmen und mehr Personal für die Bearbeitung von Änderungen und Problemen erfordern.

Zu den weiteren mit der Implementierung des Konfigurationsmanagements verbundenen Kosten gehören:

■ mit Personalschulung und -ausbildung;.

■ mit Personalkosten für die Entwicklung und Umsetzung von Verfahren;.

■ mit der Anzahl der Benutzer, die Zugriff auf das Konfigurationsmanagementsystem haben müssen;.

■ die Vielfalt und Qualität der vorhandenen Informationen, die in die CMDB und DSL geladen werden, und der Aufwand, der für deren Verarbeitung und Laden erforderlich ist;

■ mit der Zeit und den Ressourcen, die zum Bereinigen von Daten schlechter Qualität erforderlich sind;.

Konfigurationsmanagementplan in Standards

Der Managementplan ist das wichtigste Dokument des Prozesses. Im Großen und Ganzen ist es das einzige Dokument des Managementprozesses. Die Zusammensetzung und Inhalte des Managementplans sind in einigen Standards festgelegt, werden jedoch in den meisten Fällen erheblich geändert, um den Anforderungen einer bestimmten Organisation oder eines bestimmten Projekts bei der Implementierung von PS-Lebenszyklusprozessen gerecht zu werden. Alle in diesem Buch besprochenen Standards definieren den Prozess und die Rollen, aber nicht alle definieren und klassifizieren Managementpläne. Schauen wir uns die Anforderungen der Standards an den Inhalt von Managementplänen genauer an:

Faktoren, die die Struktur des Konfigurationsmanagementplans und seine Details beeinflussen

	Mögliche Werte	Wirkung, Beschreibung
Projekttyp	Modell-(Prototypen-)Entwicklung PS-Unterstützungsprojekt Kommerziell (mit Support) Kommerziell unbegleitet Subunternehmer
Verfügbarkeit mehrerer Büros (regional verteilte Entwicklung)	Ein Büro Mehr als eine	Das Vorhandensein mehrerer Büros verkompliziert den Plan und ergänzt ihn durch Regelungen für die Interaktion zwischen den Büros. Außerdem wirken sich zusätzliche Büros auf die Gesamtarchitektur des Projekts aus. Für solch Schlüsselfaktoren als Anzahl der Zweige im Designbaum (in der Regel führt das Hinzufügen einer neuen Region dazu, dass für jede Region mindestens ein Zweig hinzugefügt wird). Eine Erhöhung der Anzahl der Regionen wirkt sich auf den Grad des Formalismus des Plans aus. Niveau - hoch.
Relative Projektgröße		Beeinflusst die Anzahl der Vorschriften sowie deren Ausarbeitung und Detailliertheit. Phasen, Interaktion zwischen Gruppen und die Weitergabe von Änderungswünschen werden detaillierter beschrieben. Je größer das Projekt, desto formaler sollte der Plan sein.
Anzahl der Konfigurationselemente	Die Anzahl der Konfigurationselemente beeinflusst lediglich eine tiefergehende Ausarbeitung der Elementidentifikation. In manchen Fällen ist es sinnvoll, alle Arten von Konfigurationselementen in einem Plan anhand von Mustern zu definieren (z. B. anhand von Dateierweiterungen).
Anzahl der Komponenten und Subsysteme	Die Anzahl der Komponenten und Subsysteme kann die Auswahl der Elemente aus dem Endlager (die Methode der Probenahme und des Zugriffs) beeinflussen. Beeinflusst auch die Tiefe der Darstellung des Abschnitts, der die Struktur des Projektverzeichnisses beschreibt
Lebenszyklusphase	Der Managementplan beschreibt in der Regel alle Phasen des Software-Lebenszyklus. Bei der Zusammenarbeit mit Subunternehmern ist es manchmal notwendig, die Phase, in der der Subunternehmer beteiligt ist, klarer zu identifizieren. Außerdem kann zum Managementplan ein Nachtrag herausgegeben werden, der die Phase des Lebenszyklus der Software widerspiegelt.
Entwicklungsmodell	Je nachdem, welches Entwicklungsmodell zugrunde gelegt wird (Kaskade, Iterationen, Spirale), ist es notwendig, den Managementplan hinsichtlich der Zusammensetzung der Phasen des Softwarelebenszyklus, der Tiefe ihrer Beschreibung und der Methode der Identifizierung anzupassen Basisversionen und die Herausgabe von Releases.
Verfügbarkeit (Verfügbarkeit) von Verwaltungsfonds und anderen damit verbundenen Fonds	Grundlegende Verwaltungssysteme (normalerweise nur Versionsverfolgung) Berichtsgeneratoren (normalerweise integriert) Bibliotheksverwaltungstools Fortschrittlich, integriert Das gleiche wie oben. Plus Change-Management-Tools Integrierte Build- und Audit-Tools Verstreut	Das Projekt kann ganz ohne Automatisierungstools erstellt werden (z. B. Verwaltung der Konfiguration einer Leiterplatten-Layout-Baugruppe). Der Fortschritt des Projekts und des Plans wird maßgeblich von Faktoren wie den verwendeten Entwicklungstools und der Entwicklungsplattform beeinflusst (Entwicklung auf mehreren Plattformen und für mehrere Plattformen gleichzeitig ist möglich). Auch sehr wichtig Sie verfügen über die Art und Anzahl der Implementierungstools (MC-Automatisierung) und gehören einem oder mehreren Anbietern. Beispielsweise könnte ein Projekt ein Versionskontrolltool eines Anbieters und ein Änderungskontrolltool eines anderen Anbieters verwenden. Möglicherweise verfügen Sie über eine Integration des Management-Tools in Projektmanagement-Tools oder auch nicht. Die Art der Integration zwischen Tools und der Integrationsarchitektur sollte im Plan ausführlich besprochen werden.
Grad der Formalisierung (sowohl organisatorische Prozesse als auch Art der Plankontrolle)		Der Grad der Formalisierung kann abhängig von vielen Faktoren variieren, einschließlich derjenigen, die in dieser Tabelle aufgeführt sind. Bei der Wahl des Formalitätsgrads und der Präsentationstiefe müssen Sie sich an den zugrunde liegenden Aufgaben und Zielen orientieren. Faktoren wie die Komplexität des Projekts, die regionale Streuung, die Art des Projekts und die Anwesenheit von Subunternehmern sollten automatisch die Erstellung eines stark formalisierten Managementplans veranlassen. Durchschnittlich und niedriges Niveau kann in relativ kurzfristigen Projekten verwendet werden, die Projekte umfassen eine kleine Menge Entwickler. Mit dem Wachstum des Teams und der Rollenverteilung sollte der Managementplan überarbeitet und der Formalisierungsgrad erhöht werden.

Der Plan selbst wird während seiner Entwicklung von vielen Faktoren beeinflusst. Die Struktur des Managementplans und sein Inhalt hängen von Faktoren wie der Art des Projekts und seiner Dauer, dem Grad der Formalisierung der Prozesse, der Größe des Teams (Präsenz regional verteilter Gruppen), der Anzahl der Subunternehmer, und viele andere. Dies bedeutet, dass die Struktur des Plans und die Zusammensetzung der Anträge unter Beibehaltung eines einzigen „Geistes“ in relativ großen Grenzen variieren können.

Das Konfigurationsmanagement ist eine grundlegende Disziplin, die bestimmt, wie Projektarbeitselemente, deren Änderungen und Statusinformationen zu einzelnen Aufgaben und zum gesamten Projekt verwaltet und gesteuert werden. Der Erfolg eines Projekts hängt weitgehend davon ab, wie gut der Konfigurationsmanagementprozess aufgebaut ist, der das Projekt entweder retten oder begraben kann, wenn der CM-Prozess selbst eine schlechte Leistung erbringt.

Entwicklungsgeschichte der Disziplin Konfigurationsmanagement

Der erste bemerkenswerte Schritt in der Entwicklung des Konfigurationsmanagements (abgekürzt CM) war die Erfindung des Mikrometers im Jahr 1636 (William Gascoigne). Dieses Gerät spielte eine wichtige Rolle in der industriellen Revolution und dem Übergang zur Massenproduktion. Dieses Tool ermöglichte die Verwendung austauschbarer Teile in verschiedenen Geräten, was ein wesentlicher Grund für den Einsatz von Kwar.

Die ersten technischen Konzepte, die zur Entstehung der Disziplin des Konfigurationsmanagements führten, nahmen Anfang des 20. Jahrhunderts Gestalt an und nahmen in den 60er Jahren des letzten Jahrhunderts konkrete Gestalt an.

Ursprünglich verfolgten die Erfinder des Konfigurationsmanagementkonzepts das Ziel, Methoden zur Entwicklung und Wartung von Softwaretools (Software) zu verbessern. Die „Gründerväter“ des Konfigurationsmanagements wollten eine Disziplin schaffen, die sicherstellt, dass die entwickelte Software den Bedürfnissen der Benutzer entspricht, für die sie entwickelt wurde. Sie untersuchten erfolgreiche Projekte und fassten die Erfahrungen beim Einsatz bewährter Technologien zusammen. Ein weiteres wichtiges Ziel bestand darin, eine einfache Modifizierung und Wartung der Software sowie (da die „Gründerväter“ hauptsächlich für Regierungsbehörden arbeiteten) die Möglichkeit für den Softwarekunden zu gewährleisten, den Entwickler zu wechseln, ohne den gesamten Softwareentwicklungszyklus von Grund auf durchlaufen zu müssen .

Darüber hinaus wurde als weiteres Ziel die Bereitstellung einer Bewertung des Projektstatus anhand der Berichterstattung über Schlüsselindikatoren angesehen. Sie konzentrierten sich auf das Erreichen langfristiger Ziele und erwarteten nicht, dass sich aus der Nutzung der von ihnen entwickelten Technologien sofort offensichtliche Vorteile ergeben würden. Es ist zu beachten, dass die Vorteile dieser Art schwer zu quantifizieren sind, da eine Organisation bei erfolgreicher Nutzung des Konfigurationsmanagements einfach keine Ressourcen mehr für unnötige Arbeit verschwendet. Zum Beispiel, um einen Fehler erneut zu korrigieren, der bereits zuvor behoben wurde, aber erneut aufgetreten ist, weil beim Zusammenstellen der Software versehentlich der richtige Code durch einen falschen ersetzt wurde.

Die Gründerväter erkannten, dass sie zunächst kontrollieren mussten, welche Teile verarbeitet wurden fertiges Produkt(unter einem Produkt kann sowohl Software als auch Ausrüstung verstanden werden und im weitesten Sinne jedes Produkt, das aus verschiedenen Teilen besteht) und wie sie miteinander verbunden sind, sowie Änderungen in einzelnen Teilen des Produkts und in ihren Beziehungen zueinander verfolgen. Sie wählten das Wort „Konfiguration“, um „die relative Anordnung von Teilen“ zu bedeuten. Das Wort „Management“ hatte eine durchaus passende Bedeutung und das Ergebnis war „Konfigurationsmanagement“.