Change Configuration Management Change Configuration ManagementZu einem effektiven internen Kontrollsystem der Software-Wartung gehört auch eine lückenlose Dokumentation durchgeführter Änderungen. Durch manuelle Einträge in den Programm-Quellen oder mit Unterstützung von Change-Configuration-Management-(CCM-)Werkzeugen können diese Änderungen gut nachvollzogen werden.
In Anlehnung an die rechtlichen Vorgaben aus § 239 Abs. 3 HGB, § 146 Abs. 4 AO und den einschlägigen fachlichen Stellungnahmen wie den Grundsätzen ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS), den Grundsätzen ordnungsmäßiger Buchführung bei Einsatz von Informationstechnogie (FAIT 1) sowie dem internationalen Standard Governance, Control and Audit for Information and related Technology (CoBIT/3) besteht die Notwendigkeit eines nachvollziehbaren Nachweises von Programmänderungen, vor allem bei rechnungslegungsrelevanten und kaufmännischen Anwendungssystemen.
Gleichzeitig legt man hiermit die Grundlage einer zeitgemäßen Qualitätssicherung im Softwareentwicklungsprozess (Software Development Life Cycle – SDLC) und der zugehörigen Wartungsprogrammierung. Da diese häufig über einen langen Zeitraum und gegebenenfalls unter Beteiligung vieler Programmierer erfolgt, besteht ein hoher Informationsbedarf zur Durchführung einzelner Programmänderungen. Es ist wichtig, die Informationen über die Programmänderung aktuell zu halten, da eine veraltete und inkonsistente Dokumentation das Verständnis der Software erschwert; eine hochwertige und aktuelle Dokumentation ist Voraussetzung für eine effiziente Programmwartung.
Der aus technischer Sicht Change-Configuration-Management (CCM) geführte lückenlose Nachweis aller Programmänderungen ist jedoch auch ein wichtiger Punkt des internen Kontrollsystems (IKS) im SDLC und der Wartungsprogrammierung.
In der Praxis können Änderungen bereits innerhalb von Programm-Sources nachgehalten werden: Eine manuelle Änderungshistorie als Vorspann des eigentlichen Programmes durch einen Kommentarblock kann eine gute Basisdokumentation abgeben, wenn er versionsgerechte Angaben zum Programmierer, Datum der Änderung, Beschreibung des fachlichen oder IT-Hintergrunds der Programmwartung und gegebenenfalls einem eindeutig identifizierenden Schlüssel in Gestalt einer Änderungsstands- oder Versionsnummer enthält. Dieser Schlüssel wird in der eigentlichen Programmlogik an derjenigen Stelle als Referenz eingefügt, an der die effektive Wartung erfolgt ist. Zudem kann man den Kommentarblock um die Angabe zum Programmstatus mit den Werten "in Bearbeitung", "abgeschlossen" und so weiter ergänzen.
Eine derartige pragmatische Vorgehensweise ist bei disziplinierter Anwendung gut geeignet, Programmänderungen und -historie als Versionskontrolle zu dokumentieren. Allerdings sollte diese Vorgehensweise heutzutage mit Software-Werkzeugen ergänzt werden, die das CCM-(Verfahren) um kontrollorientierte Funktionen unterstützt.
Software-Werkzeuge existieren zwischenzeitlich für das host-gestützte und das web-orientierte Umfeld. Zum Teil wird die Änderungsdokumentation auch durch Funktionen innerhalb der eingesetzten Programmiersprachen unterstützt – so überliest beispielsweise Java kommentierte Programmzeilen, diese können aber mit dem Tool Javadoc im HTML-Format als Berichte ausgegeben werden. Zudem stehen spezielle Kommentaranweisungen (Tags) bereit, die aktiv genutzt werden sollten: etwa @author, @version, @param oder @return.
Im web-orientierten Umfeld sind Software-Werkzeuge, wie das Concurrent Version System (CVS) oder "Subversion" als Open-Source-Produkte oder das kommerzielle Tool Perforce verfügbar. Für den host-orientierten Bereich kann das CCM-Werkzeug Endevor/MVS als Quasistandard gelten. Der Änderungsstand wird dort mit einer so genannten Änderungsstufe eindeutig dokumentiert. Zur besseren Lesbarkeit lassen sich die Änderungsstufen reorganisieren und verdichten; im Bedarfsfall kann eine Wiederherstellung der ursprünglichen Änderungsstufen erfolgen. Zudem werden Informationen zur Lebensspanne einer Programm-Quelle durch die Anzahl der jeweiligen Anweisungen sowie Angaben zu Löschungen und Einfügungen geführt. Innerhalb einer Änderungsstufe wird durch "+/-"-Kennzeichen in Verbindung mit den Anweisungen angezeigt, welche Programmteile konkret hinzugefügt oder gelöscht wurden.
ISACA German Chapter e. V.
Eichenstrasse 7
46535 Dinslaken
![[externer Link]](../../../../images/link.gif)
www.isaca.de
Karin Thelemann, CISA
ISACA-Vorsitzende
Tel.: +49 69 15208-26488
E-Mail: karin.thelemann@de.ey.com
Bernd Wojtyna
Vorstand Facharbeit
Tel.: +49 251 288-4253
E-Mail: Bernd.Wojtyna@extern.Sparkassen-Informatik.de
Egal, welches Werkzeug zum Einsatz kommt, sind die folgenden Features innerhalb der CCM-Tools als wichtige kontrollwirksame Funktionen notwendig:
Eine pragmatische Vorgehensweise mit konsequenter Kommentierung erfüllt bereits die grundlegenden Kriterien einer versionsgerechten Dokumentation in der Wartungsprogrammierung. Durch unterstützende CCM-Werkzeuge lässt sich dies weiter automatisieren und verbessern.
Ein Datenschutz-Audit ist erforderlich, da das Bundesdatenschutzgesetz (BDSG) im Grundsatz zunächst Verarbeitung und Nutzung personenbezogener Daten verbietet. Fast jedes Anwendungssystem enthält jedoch personenbezogene Daten, sodass regelmäßig überprüft werden muss, ob die Anforderungen des BDSG und anderer Rechtsvorschriften ausreichend berücksichtigt wurden. Diese Prüfung ist sowohl bei der Einführung eines Systems als auch bei der laufenden Anwendung und im Falle einer Auftragsdatenverarbeitung auch beim Outsourcer durchzuführen.
Je nach Status der Anwendung sind dabei unterschiedliche Prüfungsschwerpunkte zu setzen. Beim Einführungsprozess steht die Prüfung der vorgesehenen Erhebung und Nutzung personenbezogener Daten im Vordergrund, zudem (u. a.) vorgesehene Übermittlung, Benachrichtigung der Betroffenen, Umsetzung der Auskunftsansprüche und Verpflichtung der Mitarbeiter auf das Datengeheimnis. Während der laufenden Anwendung ist vor allem die Umsetzung eingerichteter Konzepte zu prüfen.
Beim Audit einer Auftragsdatenverarbeitung sind schwerpunktmäßig die Vertragsgestaltung mit dem Auftragnehmer, dessen Pflichten, der Umfang der Datenverarbeitung, technische und organisatorische Maßnahmen zur Realisierung des Datenschutzes, Wahrung des Datengeheimnisses und der Rechte von Betroffenen, Datenschutz beim Auftragnehmer selbst sowie gegebenenfalls die Verarbeitung im Ausland zu prüfen.
Datenschutz-Audits werden jedoch in vielen Unternehmen stiefmütterlich behandelt, oft auch einfach ignoriert. Da der Datenschutzbeauftragte selbst mit dieser Aufgabe vielfach fachlich überfordert ist, sucht er oft Unterstützung bei der internen Revision. Andererseits ist unter Datenschutz-Audit auch die Überprüfung zu verstehen, ob der Datenschutzbeauftragte seine Arbeit korrekt und vollständig durchführt. Letzteres führt zu einem Konflikt in den Fällen, in denen der interne Revisor gleichzeitig auch Datenschutzbeauftragter ist.
Denn häufig wird, beispielsweise in vielen mittelständischen Unternehmen, die Funktion "Datenschutz" aus Bequemlichkeit dem internen Revisor zugeordnet. Da die Audit-Aufgaben sich stark ähneln, liegt diese Lösung nahe, birgt aber gleichzeitig den genannten gravierenden Interessenskonflikt. Wer prüft dann den Datenschutzbeauftragten, ob er trotz der Doppelfunktion alle seine Aufgaben wahrnimmt? Im Zweifel gehen nämlich Revisionspflichten meist vor.
Dieser Konflikt ist wohl nur dadurch zu lösen, dass hier eine strikte Funktionstrennung realisiert wird. Die Datenschutzfunktion gehört grundsätzlich nicht zum Revisor. Als Kompromiss wäre allenfalls denkbar, dass der Revisor die übrigen Aufgaben des Datenschutzbeauftragten wie Auskunftserteilung auf Anforderung wahrnimmt, aber kein Datenschutz-Audit durchführt. Als Lösung hierfür bietet sich eventuell der Einsatz eines externen Spezialisten an. (Dipl.-Kfm. Hans-Joachim Gaebert, Hamburg, gaebert@t-online.de)
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2005#5, Seite 90
| 