Qualitätssicherung, Betrieb und Weiterentwicklung

Betrieb

Nach Installation, Abnahme und Inbetriebnahme des Softwaresystems wird im Anwendungsbetrieb dafür gesorgt, dass das System für die Nutzer verfügbar ist und gegen Ausfall- und Bedrohungsszenarien abgesichert wird. Der Anwendungsbetrieb hat an sich keine explizit konstruktive oder qualitätssichernde Funktion bei der Entwicklung eines Softwaresystems. Jedoch muss zum einen bei der Übergabe der Software gewährleistet sein, dass sie nach Vorgaben und Richtlinien des Betriebs ausgeführt werden kann. Zum anderen muss die Software von der für den IT-Betrieb zuständigen Abteilung nach Entwicklung und Test in den Betrieb übernommen werden können.

Da industrielle Informationssysteme für viele Branchen und Unternehmen geschäftskritische Betriebs- und Produktionsmittel sind, müssen Änderungen an laufenden Systemen mit äußerster Sorgfalt geplant und durchgeführt werden. Insbesondere, da moderne Informationssysteme technische und prozessuale Abhängigkeiten zu anderen Systemen der Anwendungslandschaft eines Unternehmens haben, beeinflussen Ausfälle oder Defekte von IT-Systemen häufig auch die Geschäftsfähigkeit von Unternehmen.

Releaseplanung

Um unter diesen Umständen dennoch Aktualisierungen und Änderungen an der Unternehmens-IT durchzuführen, werden zwischen Fachabteilungen, IT-Anwendungsentwicklung und IT-Betrieb Releasepläne vereinbart. Ein Releaseplan legt konkrete Termine fest, zu denen Änderungswünsche und Anpassungen an Softwaresystemen umgesetzt und in Betrieb genommen werden. Mithilfe der Releaseplanung können Fachabteilungen, Anwendungsentwicklung und Betrieb intern die zum Einspielen einer neuen Softwareversion erforderlichen Aufgaben einplanen und durchführen. Dazu zählen insbesondere auch Aktivitäten der Qualitätssicherung.

Für große Systeme sind 1-4 Releasetermine im Jahr nicht unüblich, die konkreten Termine richten sich häufig nach branchenüblichen Zyklen oder gesetzlichen Vorgaben: Der Online-Versandhandel hat in der Vorweihnachtszeit Hochkonjunktur, KFZ-Versicherungen werden häufig im Spätherbst gekündigt und neu abgeschlossen, Online-Versteigerungen enden meistens am Wochenende und Systeme für Sachbearbeiter in Behörden werden nur an Werktagen produktiv eingesetzt.

Eine übersichtliche Releaseplanung mit zum Beispiel 4 Releaseterminen jährlich führt allerdings zu folgenden Phänomenen:

• Um alle gewünschten Anpassungen und Änderungswünsche in wenigen Releases unterzubringen, müssen Änderungen an vielen Stellen der Anwendung gleichzeitig durchgeführt werden. Jedoch bergen große Anpassungen immer auch ein hohes Fehlerrisiko. Daher müssen auch umfassende Maßnahmen zur Qualitätssicherung durchgeführt werden, was wiederrum zu weniger Zeit für den Einbau der Anpassungen führt.
• Fachabteilungen sind unzufrieden mit der IT-Unterstützung, wichtige Änderungswünsche werden in der Regel erst nach Wochen oder Monaten umgesetzt. Insbesondere in Unternehmen, bei denen Informationssysteme direkt in der Wertschöpfungskette beteiligt sind, können durch eine zu langsame Reaktionszeit der IT Wettbewerbsnachteile entstehen.
• Eine lange Dauer zur Behebung von neu entdeckten Sicherheitslücken oder Fehlern in der Anwendung führt zu offenen Schwachstellen der IT-Infrastruktur und somit zu möglichen Angriffsszenarien.

Continuous Integration
Um die Nachteile der wenigen und großen Releases zu umgehen, jedoch gleichzeitig die Betriebssicherheit nicht zu gefährden, werden zunehmend durch Automatisierung und Werkzeugunterstützung tägliche und wöchentliche Releases von Softwaresystemen erstellt und automatisch getestet. Man spricht in dem Fall von einer kontinuierlichen Integration oder auch von Continuous Integration, da unabhängig von konkreten Terminen alle Änderungen in kurzen Zyklen zu einer Anwendung integriert werden.

Continuous Delivery
Falls alle Tests positiv abgeschlossen werden, kann durch den Aufbau eines automatischen Deployments (deutsch: Verteilung, Installation) die angepasste Anwendung direkt in Betrieb genommen werden. Vergleichbar mit der Continuous Integration wird beim Continuous Delivery unabhängig von konkreten Terminen die in kurzen Zyklen erzeugte neue Version einer Anwendung in Betrieb genommen, daher auch der Begriff kontinuierliche Auslieferung. Die Voraussetzung von Continuous Integration und noch viel mehr von Continuous Delivery ist allerdings eine intensive Zusammenarbeit von Anwendungsentwicklung und Betrieb, die organisatorische und technische Fähigkeit regelmäßige automatische Tests durchzuführen und die organisatorische und technische Fähigkeit die Aktivitäten der Inbetriebnahme zu automatisieren.

IT-Service Management

Neben der Beteiligung der für den Betrieb von IT-Systemen zuständigen Abteilungen bei der Planung und Durchführung von Software Releases ist eine weitere Aufgabe im Betrieb das Bereitstellen von sogenannten IT-Services (deutsch: IT-Dienstleistungen). IT-Services sind etwa die Bereitstellung von Datennetzen, Serversystemen (Hardware), Betriebssystemen, Speichersystemen und Backup-Lösungen. Also Dienstleistungen, die für die Entwicklung und den Betrieb von Softwaresystemen benötigt werden.

Um einerseits die IT-Infrastruktur auf die konkreten Bedürfnisse der Fach- und IT-Anwender anzupassen aber andererseits den Aufwand für das Betreiben und den Support der IT-Infrastruktur möglichst gering zu halten, muss im Betrieb aktives IT-Service Management betrieben werden. Ein weltweit verbreiteter Standard für das IT-Service Management ist die sogenannte "Information Technology Infrastructure Library" (ITIL). In ITIL werden typische Aktivitäten und Best-Practices zum Managen von IT-Services kategorisiert und beschrieben.

Ein wichtiges Ziel von IT-Service Management ist dabei die Erarbeitung eines standardisierten Service-Portfolios, das gezielt auf typische Anforderungen des IT-Services zugeschnitten ist, jedoch gleichzeitig einen standardisierten und effizienten Betrieb der IT-Infrastruktur ermöglicht.

Eine weitgehende Standardisierung der IT-Infrastruktur ist jedoch nur möglich, wenn sich sowohl fachliche Anforderungen als auch Architekturentscheidungen der Softwareentwicklung an die Rahmenbedingungen halten, die durch das standardisierte IT-Service-Portfolio vorgegeben werden.