Marco Kuhrmann Norbert Diernhofer. Software Life Cycle. Management und Entwicklung. schnell + kompakt

Transkript

1 Software Life Cycle

2

3 Marco Kuhrmann Norbert Diernhofer Software Life Cycle Management und Entwicklung schnell + kompakt

4 Marco Kuhrmann, Norbert Diernhofer Software Life Cycle schnell + kompakt Frankfurt, 2007 ISBN entwickler.press, ein Imprint der Software & Support Verlag GmbH Ihr Kontakt zum Verlag und Lektorat: lektorat@entwickler-press.de Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Korrektorat: Petra Kienle Satz: text & form GbR, Carsten Kienle Umschlaggestaltung: Melanie Hahn, Maria Rudi Belichtung, Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn. Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

5 Inhaltsverzeichnis Vorwort 7 Kapitel 1: Der allgemeine SLC Phasen im Software Life Cycle Vorgehensmodelle und Werkzeuge Die Schnittstelle zum Betrieb 15 Betrieb 15 Evolution im Betrieb von Software Einheitliches Management 19 Kapitel 2: Vorgehensmodelle Vorgehensmodelle: Entwicklung 23 Der Rational Unified Process 23 Das V-Modell XT 25 Agile Methoden Vorgehensmodelle: Betrieb 29 CobiT 30 ITIL 30 Microsoft Operations Framework MSF 4.0 und MOF 33 Kapitel 3: Werkzeuge Werkzeuge für den Entwurf 35 Entwicklung Visual Studio Datenhaltung Visual SourceSafe 37 Testen Unit-Testing 38 Management Team Foundation Server 40 Projektverwaltung Microsoft Project 41 schnell + kompakt 5

6 Inhaltsverzeichnis 3.2 Werkzeuge des IT-Betriebs 42 Verteilung SMS 43 Überwachung/Steuerung MOM 44 Helpdesk Ticket Tracker 45 CMDB ITIL Inventar 46 Application Scanner 47 Verschränkung Entwicklung & Betrieb 47 Kapitel 4: Systementwicklung Anforderungsfestlegung Entwurf Entwicklung Test 66 Kapitel 5: Betrieb Ziele des Betriebs Deployment Betrieb Wartung & Pflege 86 Kapitel 6: Ganzheitlicher Life Cycle Projektmanagement 93 Projektmanagement im Großen 93 Projektmanagement im Kleinen 94 Aufgabenmanagement Weitere Managementdisziplinen 96 Qualitätsmanagement 96 Problem- und Änderungsmanagement 97 Konfigurationsmanagement Ganzheitlicher Life Cycle 101 Stichwortverzeichnis 105 6

7 Vorwort Software ist ein immaterielles Gut. Trotzdem gibt es Zeitpunkte im Leben einer Software, zu denen sie entworfen und geplant wird, zu denen sie erstellt wird und reift und zu denen sie zu guter Letzt auch stillgelegt wird. Ähnlich wie bei Menschen und anderen Lebewesen verfügt auch Software über einen Lebenszyklus einen Software Life Cycle (SLC). Anders, als oftmals kommuniziert, ist dieser Software Life Cycle aber nicht in einzelne, klar getrennte Phasen gegliedert. Und schon gar nicht ist unmittelbar nach der Entwicklung einer Software alles getan. Der Software Life Cycle ist einer der komplexesten Prozesse, die Menschen beherrschen müssen, um in der heutigen Welt konkurrenzfähige Software zu produzieren und zu betreiben. Dabei ist Software niemals isoliert zu betrachten. Softwaresysteme sind äußerst komplexe Systeme, die sich aus einer Vielzahl verschiedener Anwendungen und Hardwareinfrastrukturen zusammensetzen. Die hohe Integration und der enorme Grad der Durchdringung von Software (oder IT-Systemen im Allgemeinen) führen zu einer großen Abhängigkeit. Software ist alltäglich geworden und ist heute nicht mehr nur in Toastern oder auf Servern, sondern auch verstärkt in kritischen Bereichen zu finden (Finanz- und Medizinsektor, Automobilsoftware etc.). Durchgängige Konzepte für Entwicklung und Betrieb einer Software sind hier erforderlich. In diesem Buch beschreiben wir, wie sich die Vorgehensweisen der Softwareentwicklung und des Betriebs geeignet miteinander verbinden lassen. Durch die Betrachtung und Integration aller Phasen und Abschnitte im Software Life Cycle kann die Kommunikation der beteiligten Personen verbessert und so Reibungsverlusten vorgebeugt werden. Neben der Beschreibung der we- schnell + kompakt 7

8 Vorwort sentlichen Konzepte gehen wir auch auf die im.net-umfeld vorhandenen Werkzeuge ein und stellen deren Funktionen für die jeweiligen Phasen vor. Schwerpunktmäßig orientieren wir uns dabei am Visual Studio 2005 Team System mitsamt der Backend-Komponente Team Foundation Server. Wir beschränken uns dabei jedoch nicht ausschließlich auf die.net-welt, sondern bieten Ihnen in weiten Bereichen auch Hinweise zu alternativen Verfahren an. Praktisch erläutern wir alles an einem Anwendungsbeispiel. Insbesondere bezogen auf das Anwendungsbeispiel wollen wir uns an dieser Stelle sehr herzlich bei Natalie Georgieva, Leo Khodos, Aleksey Shumilin, Yevhen Dukin, Dimitri Schechter, Witali Aswolinskiy, Simo Moutchihiho Rodrigue und Harald Manske bedanken. Sie haben im Rahmen des Praktikums zur Vorlesung Verteilte Systeme mit.net: Architektur und Entwicklung an der Fachhochschule Augsburg die Software Fitosophie entwickelt und uns für dieses Buch freundlicherweise als Beispiel zur Verfügung gestellt. Außerdem gilt unser Dank Herrn Erik Franz, der uns zu diesem Buchprojekt motiviert und im Anschluss begleitet hat. Norbert Diernhofer und Marco Kuhrmann (Garching, Februar 2007) 8

9 Der allgemeine SLC KAPITEL Phasen im Software Life Cycle Vorgehensmodelle und Werkzeuge Die Schnittstelle zum Betrieb Einheitliches Management 19 Software wird erdacht, geplant, geschaffen und betrieben. Aber nicht immer ist dabei klar, welche Ergebnisse welcher Abschnitte oder Phasen in anderen Abschnitten weiterverwendet werden. Es ist gar nicht so einfach, immer klare Trennungen der einzelnen Lebensabschnitte vorzunehmen. Zuständigkeiten (organisatorische Fragen) und Technologien spielen hier eine Rolle. Oftmals gibt es in Projekten Knatsch, eben weil die hohe Komplexität auch hohes Konfliktpotenzial bietet. Betrachten wir einmal kurz technische und menschliche Problemfelder: Technische Schwierigkeiten entstehen beispielsweise dann, wenn Sie an die üblichen Probleme mit Entwicklungs-, Test- und Produktivumgebungen denken. Steht allen Beteiligten dieselbe Software zur Verfügung? Haben alle Beteiligten Zugang zu den notwendigen Ressourcen? Wer hat wann welche Veränderung durchgeführt und wieso funktioniert der Build-Vorgang nicht mehr? schnell + kompakt 9

10 1 Der allgemeine SLC Und noch weitere. Menschliche Probleme stehen dann zur Debatte, wenn es um die Verteilung von Zuständigkeiten und Verantwortungsbereichen geht. Hier gibt es dann Fragestellungen wie: Wer ist für die Architektur zuständig? Wer ist wem gegenüber weisungsbefugt? Bei der Systementwicklung unterstützen hier Vorgehensmodelle im Betrieb existieren wie auch auf Unternehmensebene sogenannte Governance Frameworks mit ebenfalls umfangreichen Vorgaben und Empfehlungen. Spannend wird es jedoch dann, wenn alle Vorgaben und Richtlinien zusammengeführt werden müssen. Wird eine Software entwickelt und in den Betrieb überführt, sind einerseits verschiedene Werkzeuglandschaften miteinander zu verknüpfen, andererseits sind verschiedene Teams mit verschiedenen Aufgaben und Interessen zusammenzubringen die völlig unterschiedliche Perspektiven auf eine Anwendung haben und teilweise auch keine gemeinsame Basis: Entwickler sprechen über den Quellcode der Anwendung, in den sie auch schnell mit ihren Werkzeugen wie Debugger oder Entwicklungsumgebung Einblick erhalten, Administratoren über die Komponenten, die in der Infrastruktur ausgeführt werden, und Fehlermeldungen in Logbüchern beides dasselbe, aber in unterschiedlichen Zuständen. Mit diesem Kapitel wollen wir Ihnen einen kurzen Blick auf die Gesamtheit des Software Life Cycle (SLC) geben. Wir beleuchten hier insbesondere die Themen: Phasen bzw. Abschnitte im Leben einer Software und darauf aufbauend in den beiden folgenden Kapiteln: Vorgehensmodelle für Entwicklung und Betrieb Werkzeuge zur Umsetzung der Vorgehensmodelle und Unterstützung des Betriebs 10

11 Phasen im Software Life Cycle Wir halten diesen Abschnitt bewusst kurz, um dann die weiteren Inhalte in eigenen Kapiteln zu vertiefen. 1.1 Phasen im Software Life Cycle Auch Software lebt. Ähnlich wie der Mensch durchläuft Software während ihres Lebens verschiedene Abschnitte. Die beiden offensichtlichsten Abschnitte sind ohne Zweifel die Abschnitte Systementwicklung und Betrieb. Allgemein anerkannt ist mittlerweile auch das Verhältnis zwischen diesen beiden großen Lebensabschnitten: das berühmte 20/80-Verhältnis, losgetreten durch den 1987 von Gartner eingeführten Begriff der Total Cost of Ownership (TCO). Dieses Verhältnis besagt: Ein großer Teil der Kosten eines Systems bzw. einer Software liegt im Betrieb und nicht in der Entwicklung (Abbildung 1.1). Erstaunlich dabei ist, dass auch heute diese beiden Abschnitte immer noch sehr oft getrennt voneinander betrachtet werden. Die Gründe hierfür sind vielschichtig. Aktuelle Vorgehensmodelle wie das V-Modell XT oder das Microsoft Solutions Framework (MSF) betrachten den Betrieb oft nur beiläufig. Systementwicklung wird als ein in sich geschlossener Vorgang angesehen und auch als solcher behandelt. Vorgehensweisen oder -modelle, wie sie auf der anderen Seite beispielsweise in ITIL oder im Microsoft Operations Framework (MOF) für den Betrieb definiert sind, basieren meist auf den Ergebnissen der Softwareentwicklung integrieren diese aber nicht in ihre Prozesse. Sie richten sich vor allem an den Anforderungen des Betriebs aus. schnell + kompakt 11

12 1 Der allgemeine SLC Entwurf/Design Anforderungsfeststellung Implementierung Test Betrieb klassisch real - Anforderungen -Entwurf - Implementierung -Test Betrieb Abb. 1.1: Klassisches und reales Modell der Lebensabschnitte eines Softwaresystems Die Schnittstelle zwischen beiden Welten ist nicht klar geregelt. Der Betrieb nimmt oft zu wenig Einfluss auf die Softwareentwicklung. Deswegen gehen Chancen zur Entwicklung einer einheitlichen (und somit beherrschbaren) Anwendungslandschaft verloren. Auch die Zwischenergebnisse der Softwareentwicklung, die bei einer weiteren Nutzung einen Beitrag im Betrieb leisten könnten, bleiben in der Regel außer Acht. Häufig fehlt eine Rückkopplung zwischen Entwicklern und Betriebspersonal, um Anwendungen kontinuierlich auf Basis der Daten des Betriebs weiterzuentwickeln. Damit würden sich Synergien erschließen, Kosten einsparen und die Effektivität sowohl der Entwicklung als auch des Betriebs steigern lassen. Systementwicklung Die Entwicklung eines Systems/einer Software ist der erste Teil des Lebenszyklus, der für viele Leute am einfachsten ersichtlich und fassbar ist. Denkt man beispielsweise an das Mautsystem oder die Software für das Arbeitslosengeld II, so findet man hier bekannte Entwicklungsprojekte. Allerdings fragt heute niemand 12

13 Phasen im Software Life Cycle mehr nach dem Mautprojekt, vielmehr nehmen wir bestenfalls noch die Mautbrücken auf den Autobahnen zur Kenntnis. Der Betrieb interessiert hier gar nicht mehr, obwohl erst durch die Ausführung der Auswertung in den Rechenzentren die Funktionalität an sich erbracht wird. Die Systementwicklung nimmt aber auf der anderen Seite anteilsmäßig nur einen vergleichsweise kurzen Abschnitt im Leben einer Software ein (Abbildung 1.1). Nichtsdestotrotz ist auch dieser kurze, kreative Abschnitt weiter untergliedert. Viele Teildisziplinen des Software & Systems Engineering sind allein hier schon wiederzufinden: Anforderungsfeststellung (Requirements Engineering) Entwurf und Design als Architekturdisziplinen Konfigurationsmanagement Qualitätssicherung, Testen Implementierung Test Entwurf Anforderungsfeststellung Abb. 1.2: Disziplinen des Software Engineering in einem beispielhaften Entwicklungszyklus schnell + kompakt 13

14 1 Der allgemeine SLC Alle diese Disziplinen sind integrale Bestandteile eines Entwicklungsprojekts (Abbildung 1.2). Keine davon steht für sich allein, sondern existiert immer mit Bezug auf den Projektgesamtkontext. Dies impliziert natürlich eine Komplexität, die der des eigentlichen Produkts in nichts nachsteht. Entwicklungsprojekte sind in der Regel immer so komplex wie das System, das entwickelt werden soll. Bereits bei durchschnittlichen Projekten mittlerer Größe kann das Komplexitätsniveau so hoch sein, dass Einzelpersonen keine ganzheitliche Sicht mehr besitzen. Es entsteht hier zwangsläufig Kommunikation. Kommunikation zu lenken und auf wesentliche Ergebnistypen zu fokussieren das ist eine der wesentlichen Aufgaben, die Vorgehensmodelle erfüllen. 1.2 Vorgehensmodelle und Werkzeuge Vorgehensmodelle regeln, Wer hat Wann an Wen und Was zu liefern. Dies ist mit Sicherheit keine belastbare Definition, jedoch eine, die uns an dieser Stelle ausreicht. Vorgehensmodelle (sofern Sie noch nicht damit in Berührung gekommen sind) können als Frameworks verstanden und angewendet werden. Sie existieren im Spannungsbogen zwischen Allgemeingültigkeit und präziser Anleitung/Regelung. Sie existieren für spezielle Domänen oder generell für Organisationen oder sogar abstrakt als generisches, allgemeingültiges Vorgehen. Die Anzahl der Vorgehensmodelle ist nahezu unüberschaubar groß. Wenige populäre Ansätze haben sich aber breiter etabliert oder erreichen zumindest einen größeren Bekanntheitsgrad. Beispiele hierfür sind der Rational Unified Process, das V-Modell XT oder das Microsoft Solutions Framework. Jedes Vorgehensmodell zieht aber bei seiner Einführung Konsequenzen für das Projekt nach sich. 14

15 Die Schnittstelle zum Betrieb Hinweis Die Entscheidung für oder gegen ein Vorgehensmodell ist ebenso wie die Entscheidung für oder gegen ein Werkzeug elementar für den gesamten weiteren Lebensweg Ihrer Software. Alle Konzepte und Anforderungen, mit denen Sie umgehen müssen, orientieren sich früher oder später am technologisch Umsetzbaren. Beachten Sie, dass zum Beispiel ein nicht eingeplanter Wechsel des Entwicklungsprozesses während des Projekts das Aus für ein Projekt bedeuten kann. In Kapitel 2 vertiefen wir das Thema Vorgehensmodelle, steigen genauer ein und diskutieren verschiedene Disziplinen und Vorgänge. 1.3 Die Schnittstelle zum Betrieb Die Entscheidung für oder gegen ein Vorgehen erfolgt vergleichsweise früh. Die Entwicklungsanteile und alle darin enthaltenen Aktivitäten richten sich nach der Auswahl. Die meisten Vorgehensmodelle decken die Entwicklungsanteile auch mindestens zufriedenstellend ab und bieten allen Projektbeteiligten einen angemessenen Aktionsrahmen. Doch was dann? Entwicklungsprojekte enden mit der finalen Auslieferung eines Systems eine provokante Aussage, die sehr kritisch hinterfragt werden muss. Was passiert denn mit einer Software, wenn sie fertig entwickelt wurde? Sie wird in den Betrieb überführt und die Realität zeigt (leider): Es geht wieder von vorne los Betrieb Der Betrieb ist der Abschnitt im Software Life Cycle, in dem eine Software wirklich zum Leben erweckt und für die Anwender schnell + kompakt 15

16 1 Der allgemeine SLC nutzbar gemacht wird. Erst hier wird die Software für den Zweck eingesetzt, für den sie entwickelt wurde. Fast keine große Anwendung wird heute für sich allein betrieben. Komplexe Softwarelandschaften, zum Beispiel in einem Rechenzentrum, erfordern mittlerweile eine Standardisierung des Managements und der Betriebsprozesse, um die Komplexität beherrschen zu können. Es sind Rahmenbedingungen zu definieren, an die sich die zu betreibenden Softwaresysteme halten müssen und die gleichzeitig Einfluss auf deren Entwicklung haben bzw. haben sollten. Entsprechende Rahmenbedingungen sind zum Beispiel: Verwendete Basistechnologien wie die eingesetzten Webserver Erlaubte Konfigurationen zur Benutzeranmeldung Technische Voraussetzungen, die sich beispielsweise aus einem Clustereinsatz ergeben (Anwendungen dürfen sich zum Beispiel nicht auf die Existenz von Session-States verlassen) Diese Vorgaben sind nicht nur technisch begründet, sondern ergeben sich auch aus rechtlichen Anforderungen wie Datenschutzbestimmungen oder Vorgaben zum Risikomanagement. Sie müssen bereits in der Phase des Requirement Engineering also schon während der Entwicklung entsprechend beachtet werden. Wichtig ist in diesem Zusammenhang, dass der Betrieb als Ganzes weniger von einem Vorgehen geprägt ist, sondern sich viele Prozesse, vor allem die IT-Infrastruktur, das Ökosystem in dem die Software ausgeführt wird, pflegen und in einem konsistenten Zustand erhalten. Diese Prozesse sind an sich wieder durch Vorgehensmodelle beschrieben, orientieren sich aber nicht an einem Produkt, das erstellt wird, sondern stellen die Verfügbarkeit eines Service sicher. Deswegen wiederholen sich hier viele Vorgänge immer wieder, ohne zu einem sichtbaren Ergebnis zu kommen. Das Ergebnis ist vielmehr die Verfügbarkeit des Dienstes an sich. 16

17 Die Schnittstelle zum Betrieb Evolution im Betrieb von Software Während des Betriebs eines Softwaresystems treten üblicherweise und in mehr oder weniger regelmäßigen Intervallen Veränderungen an der Infrastruktur auf. Neue Versionen des Betriebssystems oder anderer Komponenten können Anpassungen an der Software erfordern (Abbildung 1.3). Sobald sich die Umwelt einer Anwendung jedoch ändert, kann es ohne weiteres passieren, dass alte Bekannte wieder ans Tageslicht kommen: Fehler. Überwachung Anforderungen zur Adaption Übernahme der Software Installation und Betrieb Abb. 1.3: Abschnitte in einem beispielhaften Betriebsprozess Treten Fehler in der Software nach der Entwicklungsphase auf, die neu sind oder beim Testen nicht gefunden wurden, ist die Analyse der Rahmenbedingungen in der Produktivumgebung aufwändig, da sie in der Regel nicht direkt möglich ist. Hilfsmittel der Entwickler wie Debugger oder Testrahmen stehen hier üblicherweise nicht zur Verfügung, ein kurzer Blick in den Quellcode ist nicht möglich. Im Betrieb ist es daher erforderlich, ande- schnell + kompakt 17

18 1 Der allgemeine SLC re Hilfsmittel zu definieren und Vorgehensweisen zu vereinbaren, um eventuelle Fehler und Probleme gegebenenfalls wieder in die Entwicklung zurückzugeben. Dazu muss in der Anwendung bereits beim Design ein Mechanismus definiert werden, der den Entwicklern die dazu notwendigen Informationen liefert und die Anwendung beobachtet. Beobachtungen Bei komplexen Softwaresystemen ist es notwendig, die Ereignisse 1 innerhalb des Systems in definierter Weise dem Administrator zur Verfügung zu stellen und dies in ein entsprechendes Monitoring-Werkzeug zu integrieren. Dieses bietet sich zum Beispiel an, um die Leistungsdaten des Softwaresystems zu überwachen und zur Analyse und Weiterentwicklung der Software zu nutzen. Wird dies angemessen und konsequent umgesetzt, entsteht hier ein Kreislauf von Informationen zwischen Entwicklungs- und Betriebsabteilungen. Der Kreislauf fasst Entwicklungsprojekte und Betriebsabschnitte zusammen und bildet eine übergreifende, komplexe Struktur. Hinweis Für den Betrieb ist es entscheidend, keinen Flickenteppich von verschiedenen Anwendungen mit ihren jeweiligen Managementwerkzeugen entstehen zu lassen, sondern zu einer einheitlich wartbaren Anwendungslandschaft zu kommen. Dies spart Kosten im Betrieb und sorgt dafür, dass Unternehmens- oder gesetzliche Vorgaben beim Betrieb aller Anwendungen umgesetzt werden können. 1. Ereignisse eines Systems im Betrieb können beispielsweise Fehler-, Status- oder Warnungsmeldungen sein. Ursachen und Typen sind hier verschiedenartig und sie sind angemessen im Rahmen eines Betriebskonzepts zu definieren. 18

19 Einheitliches Management Der zugrunde iegende Prozess erfordert aber eine andere Art Management, die wir als einheitliches Management bezeichnen wollen. 1.4 Einheitliches Management Es besteht immer die Möglichkeit, ein Projekt (und somit ein Produkt) unter verschiedenen Gesichtspunkten zu betrachten und mehrere Sichten zu definieren. Das V-Modell XT spricht beispielsweise explizit von Entwicklungsprojekten oder Wartungsund Pflegeprojekten. Auch im Kontext der für uns hier interessanten Microsoft-Prozesse gibt es mit dem Solutions Framework einen Entwicklungsprozess und mit dem Operations Framework einen Leitfaden für den Betrieb von Anwendungen. Unter Berücksichtigung einer strikten Rollen- und Aufgabenverteilung erscheint dies zunächst sinnvoll. Bei näherer Betrachtung schlägt jedoch der findige Anwender zurück und kann sich ruhigen Gewissens auf den Standpunkt zurückziehen, dass der Betrieb die Entwickler nichts anginge. Richtig neues Projekt, neue Spieler, neue Karten. Betrachtet man jedoch große und komplexe Systeme, zeigt sich: Ein einheitliches Verständnis eines Systems, quasi eine Begleitung von der Wiege bis zur Bahre, ist eines der Erfolgskriterien eines Projekts und somit letztendlich auch des resultierenden Produkts. Im Gegensatz zu den sehr wenigen Projekten, die für sich alleine in einem eigenen Serverpark ausgeführt werden, müssen die meisten Anwendungen in eine bestehende IT-Landschaft integriert werden. An der Entwicklung der Vorgaben und Standards für diese Anwendungen muss sich auch der Betrieb frühzeitig beteiligen, da die Abteilung die Anwendung über mehrere Jahre betreuen muss und eine einfache Integration in die Überwachungswerkzeuge und einheitliche Wartungsprozesse im Interesse des Betriebs liegen. schnell + kompakt 19

20

21 Vorgehensmodelle KAPITEL Vorgehensmodelle: Entwicklung Vorgehensmodelle: Betrieb MSF 4.0 und MOF 33 Vorgehensmodelle sind seit einigen Jahren immer wieder auf dem Plan der Berater und Controller. Sie werden in Entwicklungsabteilungen oftmals eingeführt, indem sie als Schrankware ein Schattendasein im Bücherregal fristen. Dennoch stellen sie angesichts stetig steigender Komplexität und kritischer Bedeutung von Softwareprojekten ein wirksames Mittel dar, um eines der Hauptprobleme beherrschbarer zu machen: Kommunikation und Koordination. Wenn Einfaches schwer wird Es ist weithin bekannt und akzeptiert, dass die handwerklichen Fähigkeiten in der Softwareentwicklung (Programmieren, Testen) im Wesentlichen beherrscht werden. Problematisch ist es dann aber schon, wenn große, gegebenenfalls auch räumlich verteilte Projekte koordiniert werden müssen. Hier entstehen oftmals typische Probleme wie: Wem gehört das zentrale Architekturdokument? Gibt es ein solches überhaupt? Wenn Softwaremodul A der Abteilung 1 gehört und Modul B der Abteilung 2, wem gehört dann die integrierte Fassung C? Wer macht die Integration? Und wer sagt es demjenigen? schnell + kompakt 21

22 2 Vorgehensmodelle Und noch vieles weitere mehr Handwerklich einfache und beherrschte Tätigkeiten werden in Projekten, in denen arbeitsteilig, asynchron und verteilt über verschiedene Standorte gearbeitet wird, zu (oftmals unerwarteten) Problemen. Erfahrungen, die wir in verteilt ablaufenden Projekten sammeln konnten, bestätigen dies. Vorgehensmodelle als Option Vorgehensmodelle bieten hier eine Option an, die Probleme zumindest wieder in beherrschbare Größen zu holen. Aber zu glauben, der Einsatz eines Vorgehensmodells lasse alle Probleme verschwinden, ist natürlich naiv und nicht zielführend. Wahr ist, Vorgehensmodelle beschränken Freiräume und reglementieren Arbeitsschritte in einem Projekt. Sie regeln (mehr oder weniger) detailliert, wer für die Erstellung bestimmter Artefakte verantwortlich ist. Allgemeine Definitionen von Vorgehensmodellen sind wie so oft in der Informatik an vielen Stellen und in vielen Ausprägungen zu finden. Wir beschreiben ein Vorgehensmodell in der Regel immer als Sammlung von W-Fragen (Abbildung 2.1): Womit? Rollenmodell Wer? Aktivitätsmodell Artefakt-/Produktmodell Wie? Was? Wann? Prozess (Quasi)-Standards, Methoden und Werkzeuge Abb. 2.1: Vorgehensmodell als strukturierte Sammlung verschiedener Disziplinen des Software Engineering 22

23 Vorgehensmodelle: Entwicklung 2.1 Vorgehensmodelle: Entwicklung Wir wollen an dieser Stelle einen kompakten Einblick in bekannte Vorgehensmodelle anbieten. Wir liefern hier keine detaillierte oder vollständige Einführung, sondern listen nur auf und geben Ihnen einen kompakten Einstieg. Der Rational Unified Process Der Rational Unified Process (RUP) ist ein vergleichsweise komplexes und umfassendes Vorgehensmodell von IBM Rational. Er unterstützt als Methodik die objektorientierte Systementwicklung mit der Unified Modeling Language (UML). Hinweis Der RUP ist ein von IBM Rational definierter und gepflegter Prozess. Er ist in seiner Gesamtheit sehr umfangreich und in ein weitreichendes Produktportfolio integriert. Es gibt jedoch Teile des RUP, die im Rahmen des Eclipse Process Framework (EPF) als Open Unified Process (OpenUP) frei verfügbar sind. Der RUP ist ein Phasenmodell, das in einzelnen Phasen verschiedene Workflows positioniert, die jeweils iterativ durchlaufen werden. Im Wesentlichen definiert der RUP die vier Phasen: Inception Elaboration Construction Transition Orthogonal dazu stehen zunächst die neun definierten Workflows: Business Modeling Requirements Analysis & Design schnell + kompakt 23

24 2 Vorgehensmodelle Implementation Test Deployment Configuration & Change Management Project Management Environment Die letzten drei der gerade gezeigten Workflows haben dabei unterstützenden Charakter. Die Workflows treten in den einzelnen Phasen in verschiedener Gewichtung auf. Sie werden also in der Regel nie einzeln betrachtet, sondern immer in verschiedenen Kombinationen. Abbildung 2.2 zeigt einen Ausschnitt aus dem EPF Composer, das Werkzeug des freien von IBM gesponsorten OpenUP. Abb. 2.2: Phasen am Beispiel des EPF/OpenUP 24

25 Vorgehensmodelle: Entwicklung RUP ist ein aktivitätsgetriebener Prozess, der definiert, wer was zu erledigen hat. Ergebnisse in Form von Artefakten beliebiger Art fallen hierbei nebenbei ab. UML als Sprache des Prozesses Der RUP verwendet als Modellierungssprache die UML. Er setzt diese Sprache dabei konsequent und breit um, das heißt, dass beispielsweise die Modellierung von Geschäftsprozessen mithilfe von UML-Anwendungsfalldiagrammen (Use Case Diagram) erfolgt. Als Ausgangspunkt hierfür dient dem RUP das von P. Kruchten eingeführte 4+1-Sichtenmodell. Es stellt den Use Case in das Zentrum und ordnet Sichten für Implementierung, Analyse, Prozesse und Verteilung unter diesem Modell ein. Verwendung finden dann in den einzelnen Teilen verschiedene UML-Modelle, wie zum Beispiel Komponenten- oder Klassendiagramme. Das macht den RUP attraktiv für Werkzeughersteller, die hier eine große Menge Automatisierungspotenzial vorfinden. Automatische Codeerzeugung oder allgemein modellgetriebene Entwicklung sind Beispiele für die Anwendung des RUP in der Softwareentwicklung. Das V-Modell XT Das V-Modell XT 1 ist ähnlich dem RUP ein komplexes, breit anwendbares und hoch integriertes formales Vorgehensmodell. Das V-Modell ist weiterhin der IT-Entwicklungsstandard für IT- Projekte in der öffentlichen Hand der Bundesrepublik Deutschland. Es ist als generisches Vorgehensmodell nicht nur auf die Softwareentwicklung beschränkt, sondern skaliert auch über weitere Projekttypen, wie zum Beispiel die Entwicklung eingebetteter oder großer, komplexer IT-Systeme. 1. Alle Informationen zum V-Modell XT: schnell + kompakt 25

26 2 Vorgehensmodelle Das V-Modell definiert eine Reihe einfacher Konzepte, die es in weiten Teilen zu einem modular erweiterbaren und anwendbaren Vorgehensmodell machen. Die drei wesentlichen Konzepte sind: Vorgehensbausteine Projektdurchführungsstrategien Tailoring Vorgehensbausteine enthalten mit Produkten, Rollen und Aktivitäten alle wesentlichen (strukturellen) Elemente des V-Modells. Sie sind Container für alle Elemente einer Projektdisziplin (zum Beispiel Projektmanagement oder Systementwicklung). Vorgehensbausteine mit allen enthaltenen Elementen machen aber im Weiteren keine Aussagen, in welcher Reihenfolge bzw. nach welcher Strategie in einem Projekt vorzugehen ist. Dies übernehmen die Projektdurchführungsstrategien, die eine Reihenfolge über so genannte Entscheidungspunkte (denen wiederum Produkte zugeordnet sind) definieren. Sie regeln somit also, wann welche Produkte in einem Projekt zu erstellen sind und wann eine Projektfortschrittsstufe erreicht wird. Anders als beispielsweise der RUP ist das V-Modell produktorientiert. Nicht die Aktivitäten stehen im Vordergrund, sondern die erwarteten Ergebnisse. Dies hat aber auch Folgen. So erlaubt es die Produktzentrierung beispielsweise, sich weitgehend von konkreten Methoden zu lösen. Das V-Modell nimmt dies auch für sich in Anspruch und verzichtet in weiten Bereichen auf die Definition von Methoden. Automatisches Tailoring im V-Modell XT Das vielleicht interessanteste Konzept des V-Modell XT ist das automatisierte Tailoring. Das V-Modell deckt aufgrund seines generischen Charakters viele mögliche Einsatzbereiche ab. 26

27 Vorgehensmodelle: Entwicklung Abb. 2.3: Der V-Modell XT Projektassistent führt das automatische Tailoring aus. Wird es jedoch in einem konkreten Projekt zur Anwendung gebracht, sind in der Regel nicht immer alle Bestandteile des V-Modells notwendig. Es ist sinnvoll, die nicht relevanten Teile aus der Prozessdefinition zu entfernen und sich nur auf das Wesentliche zu konzentrieren. Das V-Modell implementiert hierfür einen Mechanismus, der eine solche Anpassung automatisch durch Werkzeuge gestattet (Abbildung 2.3). Wird in einem Projekt beispielsweise nur Software entwickelt, sind die Vorgaben des V-Modells bezüglich Hardwareentwicklung nicht notwendig und können daher entfallen. Das speziell auf ein Projekt angepasste V-Modell ist in der Regel vom Unfang her kompakter und straffer. Für unsere Anforderungen hier ist es jedoch von Nachteil, dass das V-Modell methodenneutral ist. Es verzichtet zugunsten einer schnell + kompakt 27

28 2 Vorgehensmodelle möglichst breiten Anwendbarkeit auf konkrete Methoden für bestimmte Aufgaben. Gerade diese wollen wir aber im Kontext des gesamten Software Life Cycle mit Ihnen betrachten, weshalb wir auf ein anderes Vorgehensmodell, das Microsoft Solutions Framework, ausweichen werden. Agile Methoden In den letzten Jahren haben agile Methoden wie Extreme Programming (XP) oder Scrum verstärkt an Bedeutung gewonnen. Agile Methoden versuchen, sich stärker an Kundenbedürfnissen zu orientieren, und binden sie verstärkt in das Projektgeschehen ein. Oftmals verzichten agile Methoden wie zum Beispiel das XP auf hohe Verfeinerungsstufen und setzen stattdessen auf eine Zielvereinbarung. Dem Ziel nähert man sich schrittweise (iterativ) und verfeinert regelmäßig die Zieldefinition. Szenarios und Tests Obwohl man agilen Methoden oftmals einen leicht chaotischen Touch unterstellt, weisen sie dennoch interessante Aspekte auf, die mittlerweile auch in formalen Vorgehensmodellen Einzug gehalten haben. Szenariobasierte oder testgetriebene Entwicklungsansätze seien hier nur einmal als Beispiel genannt. Szenarios nehmen im agilen Vorgehen üblicherweise den Platz der formalen Anforderungen ein. Anwender formulieren, was sie vom System erwarten, und Analysten formulieren daraus Szenarios. 2 Sind Szenarios erst einmal definiert, können aus diesen auch Testfälle gewonnen werden. Ein Vorteil der Szenarios ist, dass sie in der Regel überprüfbar sind. 2. Wir verwenden hier konsequent den Begriff Szenario. Je nach Vorgehen können Ihnen aber auch Begriffe wie zum Beispiel User Story begegnen. 28

29 Vorgehensmodelle: Betrieb Hinweis Ein Extremfall dieses Vorgehens ist das Test-Driven Development. Hier wird basierend auf einem Szenario ein Testfall definiert und Fachcode nur in dem Umfang geschrieben, der erforderlich ist, um den Test erfolgreich zu durchlaufen. Über agile Methoden kann man lang und viel schreiben (und auch vortrefflich streiten). Wir wollen an dieser Stelle jedoch nicht weitergehen und Sie stattdessen auf die weiteren Teile des Buchs verweisen. Auch wir haben für unser Beispiel auf eine agile Methode gesetzt. Denn einen Vorteil haben agile Methoden: Sie sind in der Regel so kompakt, dass sie sich auch für kleine und Kleinstprojekte eignen. 2.2 Vorgehensmodelle: Betrieb Nachdem wir uns im Bereich der Entwicklung ein wenig umgesehen haben, wenden wir uns noch kurz dem Betrieb zu. Auch für den Betrieb gibt es Vorgaben, die für das Vorgehen bei der Bereitstellung einer Softwarelandschaft sowie die Organisation der Erbringungseinheit Best Practices zur Verfügung stellen. Dabei ist zu beachten, dass es sich beim Betrieb weniger um ein Projekt mit einem Produkt als Ergebnis handelt, sondern um eine Unternehmensorganisation. Die Prozesse sind deswegen vor allem auf sich wiederholende Tätigkeiten ausgerichtet. Ein noch wichtigerer Aspekt ist in diesem Zusammenhang die Klärung von Zuständigkeiten und Verantwortungsbereichen, ein Thema, das oft auch unter dem Schlagwort IT-Governance zusammengefasst wird. Wir werden Ihnen im Folgenden ausgewählte Frameworks aus dem Bereich IT-Betrieb vorstellen. schnell + kompakt 29

30 2 Vorgehensmodelle CobiT CobiT ist ein weitverbreitetes Framework für IT-Governance. Es benennt abstrakte Prozesse, die in der IT-Betriebsabteilung umgesetzt werden müssen, und gibt den Verantwortlichen Steuerungsvorgaben an die Hand, mit denen diese Prozesse umgesetzt werden können. Es wird dabei nur bestimmt, welche Prozesse relevant sind, und nicht die konkrete Umsetzung der Prozesse. CobiT orientiert sich an den COSO-Vorgaben, welche die IT-Goverance-Vorgaben mit den Corporate Governance-Vorgaben verbinden. Die durchgängige Konformität ist gerade auch in Bezug auf neue regulierende Frameworks wie den Sarbanes- Oxley Act (SOX) 3 wichtig, um die Vorgaben durchgängig zu erfüllen und deren Einhaltung belegen zu können. CobiT 4 als bisher letzte Aktualisierung legt besonderen Wert auf die Integration der Geschäftsziele in das Rahmenwerk. Hinweis Ein Geschäftsziel ist es, den Kunden davon zu überzeugen, dass ein Unternehmen vertrauenswürdig ist und entsprechend handelt. Diese allgemeine Vorgabe findet sich in den IT- Goverance-Vorgaben zur Datensicherheit und zum Datenschutz im Unternehmen wieder, die entsprechend umgesetzt werden müssen, um das Unternehmensziel zu erreichen. ITIL CobiT macht abstrakte Vorgaben für den IT-Betrieb und beschreibt, welche Prozesse umgesetzt werden müssen. ITIL, die IT Infrastructure Library, setzt eine Ebene tiefer an und beschreibt die Prozesse an sich. Sie macht Vorgaben für den Betrieb, aber auch für betriebsrelevante Bereiche wie Financial Management. 3. SOX: 30

31 Vorgehensmodelle: Betrieb Dabei beschreibt ITIL die Prozesse mit ihren verschiedenen Schritten. ITIL geht dabei noch nicht auf eine konkrete Architektur oder Managementsoftware ein. Die Vorgaben sind Best Pratices, die an die jeweils eingesetzte Soft- und Hardwareinfrastruktur angepasst werden müssen. Viele Managementwerkzeuge orientieren sich aber mittlerweile an ITIL und setzen die entsprechenden Prozesse für ihren jeweiligen Einsatzzweck um bzw. verfeinern diese auf das jeweilige Anwendungsszenario. Hinweis Wir beschreiben in diesem Buch die ITIL Version v2. Momentan befindet sich eine neue Version in Vorbereitung, die 2007 veröffentlicht wird. ITIL teilt sich dazu in zwei große Bereiche auf: Service Delivery, mit den Unterbereichen Service Level Management, Financial Management, Capacity Management, Availability Management, IT Continuity Management und Security Management Service Support, mit den Unterbereichen Service Desk, Configuration Management, Incident Management, Problem Management, Release Management und Change Management Diese verschiedenen Bereiche beeinflussen sich, so stützt sich der Service Desk auf die Informationen des Configuration Management und nutzt das Incident Management zur Behandlung von Ereignissen in der Infrastruktur. Rund um ITIL existieren eine Vielzahl an Tools, die die verschiedenen Prozesse implementieren. So ist die Umsetzung in der IT-Infrastruktur einfach möglich. schnell + kompakt 31

32 2 Vorgehensmodelle Microsoft Operations Framework Das Microsoft Operations Framework (MOF) ist ein Rahmenwerk für den IT-Betrieb, das ITIL erweitert und die Vorgaben auf eine Microsoft-Infrastruktur umsetzt. MOF beinhaltet: Ein Prozessmodell, das Prozesse zum Betrieb der IT-Infrastruktur beschreibt Ein Teammodell, das eine Organisationsstruktur und die notwendigen Rollen für den Betrieb beschreibt Ein Risikomodell, das die Bewertung einer IT-Infrastruktur und ein Management der Risiken, denen diese unterliegt, ermöglicht Optimizing Changing Supporting Operating Abb. 2.4: Phasen des Betriebsmodells MOF Es integriert sich damit strukturell sehr gut in die Philosophie des Solutions Framework für die Softwareentwicklung, das wir im nächsten Abschnitt kurz streifen und als Grundlage für dieses 32

33 MSF 4.0 und MOF Buch verwenden. MOF teilt die Prozesse in vier Quadranten ein (siehe Abbildung 2.4, die einen iterativen Betriebsprozess beschreibt). Dieser umfasst die Stufen: Change Änderung Operate Betrieb Support Optimize Optimierung Durch Service-Management-Funktionen werden die einzelnen Aufgaben dieser verschiedenen Quadranten erbracht. Beispiele sind Configuration-Management und der Service Desk, Incidentund Change-Management, alte Bekannte aus der ITIL-Welt, die hier nur konkreter für die Microsoft-Infrastruktur definiert sind, aber auf den Vorgaben aufbauen. 2.3 MSF 4.0 und MOF Nach unserem kurzen Überflug über die Domäne verschiedener Vorgehen für verschiedene Phasen des Lebenszyklus einer Software wollen wir Ihnen noch unser Handwerkszeug für dieses Buch vorstellen. Als Vorgehensmodelle haben wir uns hier für das Microsoft Solutions Framework (MSF) und das Microsoft Operations Framework (MOF) entschieden. Den MSF haben wir aufgrund seiner relativen Schlichtheit bei gleichzeitiger, umfassender Werkzeugintegration gewählt. Den MOF betrachten wir als Spezialfall von ITIL, verwenden ihn aber insbesondere aus dem Grund heraus, dass er eine Schnittstelle zum MSF hin anbietet. In diesem Buch verwenden wir das Microsoft Solutions Framework in der Version 4.0. Der MSF ist mittlerweile zu einem Vorgehensmodell gereift, das in seinen wesentlichen Grundzügen gar nicht so weit vom V-Modell XT weg ist. Der MSF verfügt ebenso über ein Metamodell und ist durch ein Tailoring-Konzept wenn schon nicht dynamisch so doch zumindest auf der Or- schnell + kompakt 33

34 2 Vorgehensmodelle ganisationsebene auf verschiedene Anwendungsszenarios anpassbar. Der MSF ist im Kontext dieses Buchs deshalb von besonderem Interesse, weil wir Ihnen mit dem Ziel des ganzheitlichen Managements eines Softwaresystems den Life Cycle über die Systementwicklung hinaus darstellen wollen. Dazu bedienen wir uns der Schnittstelle des MSF zum Microsoft Operations Framework (MOF). Diese beiden Frameworks decken den gesamten Life Cycle einer Anwendung ab. Um hier nicht zu theoretisch zu werden, betrachten wir den MSF in seiner natürlichen Umwelt dem Visual Studio Team System und dem Team Foundation Server. Beide Werkzeuge stehen in einer Kette von Tools, die beispielhaft für eine Projektdurchführung sind. Auch MOF betrachten wir nicht weiter theoretisch, sondern wir verdeutlichen uns seine Konzepte an einer Werkzeuglandschaft. Hier stellen wir aber wesentlich detailliertere Verbindungen zu ITIL her. Bevor wir in die Detaildiskussionen gehen, widmen wir uns aber ebenso wie bei den Vorgehensmodellen noch einigen exemplarischen Werkzeugen. 34

35 KAPITEL 3 Werkzeuge 3.1 Werkzeuge für den Entwurf Werkzeuge des IT-Betriebs 42 In diesem Kapitel stellen wir Ihnen ausgewählte Werkzeuge für die verschiedenen Phasen des Softwarelebenszyklus vor. Dabei gehen wir von den in den vorigen Kapiteln vorgestellten Aufgaben und Frameworks aus. 3.1 Werkzeuge für den Entwurf Die Werkzeuge für den Softwareentwurf umfassen zum einen die Entwicklungsumgebungen selbst, zum anderen aber auch unterstützende Werkzeuge zum Projektmanagement und zur Umsetzung. Entwicklung Visual Studio 2005 Visual Studio ist die Entwicklungsumgebung von Microsoft für.net-basierte Projekte (Abbildung 3.1). Es bietet dem Entwickler ein integriertes Toolset aus Editoren, Compiler, Debugger und Laufzeitumgebung für seine Anwendungen. Je nach Version ist auch die Integration in entsprechende Back-End-Systeme wie Visual SourceSafe und den Visual Studio Team Foundation Server möglich. schnell + kompakt 35

36 3 Werkzeuge Abb. 3.1: Das Visual Studio 2005 als Entwicklungsumgebung für.net-basierte Anwendungen Diese Integration bietet Entwicklern die Möglichkeit, Code in einem gemeinsamen Repository abzulegen. Durch die Integration von NUnit-basierten Unit-Tests ist damit auch eine Qualitätskontrolle möglich. Aber nicht nur Unit-Tests sind als qualitätssichernde Maßnahme im Visual Studio integriert, sondern auch Werkzeuge wie FxCop. FxCop realisiert eine statische Codeanalyse und erlaubt unter anderem auch die Durchsetzung von Coding Guidelines. Das Visual Studio ist durch den Team Foundation Server in eine Projektmanagementinfrastruktur eingebunden. Dies hat zur Folge, dass Entwickler, Analysten, Architekten und Tester ge- 36

37 Werkzeuge für den Entwurf meinsam, arbeitsteilig an einem Projekt in einer einheitlichen Umgebung arbeiten können. Dies umfasst beispielsweise gemeinsames Aufgabenmanagement oder gemeinsamen Code und Dokumentation. Der Entwickler sieht so direkt in seinem Werkzeug, welche Aufgaben zu erledigen sind. Da aber beispielsweise Projektmanager nicht immer unbedingt Entwicklungsumgebungen bevorzugen, gibt es für diese auch Anbindungen an andere Werkzeuge, wie zum Beispiel Microsoft Office. Visual Studio erlaubt die Entwicklung von Unit-Tests und ein automatisches Testen des Codes in einem Quasi-Batch-Betrieb direkt auf dem Team Foundation Server. Durch die Integration des Build-Systems 1 und der entsprechenden Definitionen einer oder mehrerer Build-Konfigurationen im Projekt sind somit auf einfache Weise Nightly-Builds möglich, bei denen die Anwendung übersetzt wird und anschließend alle Testfälle angewendet werden. Die Ergebnisse und Fehler lassen sich dann wieder in Aufgaben für die Entwickler überführen. Datenhaltung Visual SourceSafe Neben dem Team Foundation Server bietet Microsoft mit Visual SourceSafe ein zweites Produkt an, das eine gemeinsame Datenbasis für die Entwickler zur Verfügung stellt. Oft spricht man in diesem Zusammenhang auch von einem Repository 2. Der Anwendungscode wird im Repository abgelegt und allen Entwicklern zur Verfügung gestellt. Hat ein Entwickler seine Arbeiten erledigt und die entsprechenden Unit-Tests erfolgreich abgeschlossen, fügt er den Code entsprechend in das Repository mit ein. Damit steht dem Teamleiter der aktuelle, funktionieren- 1. Zum Einsatz kommt hier das frei verfügbare Microsoft Build ein XML-basiertes Buildsystem, ähnlich NAnt. 2. Visual SourceSafe ist direkt im TFS integriert. Je nach Konfiguration sind aber auch andere Repositories wie CVS oder SVN möglich. schnell + kompakt 37

38 3 Werkzeuge de Stand der Anwendung zur Verfügung. Visual SourceSafe ist direkt in den Team Foundation Server integriert und liefert hier einen erheblichen, unmittelbar sichtbaren Mehrwert: Check-In Policies. Für ein Projekt können direkt Regeln angegeben werden, denen einzucheckende Elemente genügen müssen. Beispielsweise kann man erzwingen, dass nur kommentierter oder nur FxCop-geprüfter Code eingecheckt wird. Testen Unit-Testing Nach oder vor der Entwicklung der Funktionalität (je nach angewendetem Prozess) muss diese getestet werden. Dabei wird für jede einzelne Softwarekomponente der entsprechende Testfall erzeugt. Tools wie NUnit 3 erlauben es, diese Einzeltests zusammenzufassen und automatisch auf den Sourcecode anzuwenden. Damit ist die Testautomatisierung sehr einfach möglich. NUnit stellt eine Benutzerschnittstelle zur Verfügung, die einen Überblick über die Ergebnisse des Tests liefert. Integration in das Visual Studio Das Tool NUnit kommt ursprünglich aus dem Bereich des XP und ist durch die Java-Variante JUnit rasend bekannt und beliebt geworden. Über verschiedene Entwicklungsstufen wird eine eigens angepasste Version von NUnit direkt im Visual Studio unterstützt. Eine separate Anwendung ist nicht mehr erforderlich. Es wird ein Projekttyp Testprojekt angeboten (Abbildung 3.2), der es erlaubt, Testklassen und Testfälle zu erstellen und im Visual Studio als Container laufen zu lassen. Der Ablauf der Tests kann durch den Team Foundation Server gesteuert automatisiert im Nightly-Build erfolgen. 3. NUnit: 38

39 Werkzeuge für den Entwurf Abb. 3.2: NUnit-basierte Testprojekte im Visual Studio Bugtracking Treten während der Softwareentwicklung Fehler zutage, müssen diese nicht nur gefunden und gemeldet, sondern auch irgendwann behoben werden. Wichtig ist hier eine direkte Anbindung an das Aufgabenmanagement. Die Fehler müssen zunächst einmal verwaltet, kategorisiert und festgehalten werden. Nachdem sie erfasst wurden, kommt das Aufgabenmanagement ins Spiel. Im Rahmen des im Team Foundation Server realisierten Bugtracking kann dies geschehen. Darüber hinaus können die Bugs verfolgt werden, um zum Beispiel zu erfahren, ob sie bereits behoben wurden. Aus diesen Bugreports ergeben sich dann möglicherweise neue Anforderungen und Aufgaben für die Ent- schnell + kompakt 39

40 3 Werkzeuge wickler, die umgesetzt werden müssen. Beispiele für ähnliche Werkzeuge sind die Open-Source-Tools Bugzilla und Mantis. Management Team Foundation Server Der Visual Studio 2005 Team Foundation Server (VSTFS) stellt das Backend von Visual Studio dar. Er stellt neben einer Sharepoint-basierten Webseite für das Entwicklungsteam auch ein gemeinsames Repository, eine Build-Umgebung und ein Aufgabenmanagement zur Verfügung. Der Team Foundation Server implementiert mindestens ein Prozessmodell, dem sich alle angebotenen Funktionen unterordnen, und realisiert somit ein zentralisiertes Projektmanagement für Entwicklungsprojekte. Die Steuerung eines Softwareentwicklungsprojekts wird durch ihn auf eine formale Basis gestellt. Standardmäßig bietet er zwei Prozesstemplates für die beiden verschiedenen MSF-Prozesse CMMI oder Agile an. Der Projektleiter definiert für sein Projekt und Team den entsprechenden Prozess und erhält bereits die vorgefertigten Schablonen, die er an sein Projekt anpassen kann (Abbildung 3.3). Durch die Integration der Reporting Services von SQL Server 2005, der technischen Basis der Datenhaltung im VSTFS, kann der Projektmanager umfangreiche Statistiken zum Projektfortschritt erstellen und so den Status und Trends analysieren. Dies ist einer der Vorteile und Mehrwerte, die der Team Foundation Server mit sich bringt: Ein Projekt kann von Anfang an gemessen werden. Ermöglicht wird dies durch die einheitliche Datenablage und die Integration von Warehousing-Fähigkeiten. 40

41 Werkzeuge für den Entwurf Abb. 3.3: Auswahl eines Projekt-Template beim Anlegen eines neuen Teamprojekts Projektverwaltung Microsoft Project Die im Team Foundation Server integrierten Projektmanagementfunktionen kann man aber trotzdem auch nur als rudimentär bezeichnen, da beispielsweise Mechanismen für eine Ressourcenplanung und Ähnliches nicht integriert sind. Für das Management im Großen sind entsprechende mächtigere Werkzeuge notwendig, um den Projektplan zu verwalten. Microsoft Project bietet hier unter anderem die notwendigen Fähigkeiten. Project kann an den Team Foundation Server angebunden wer- schnell + kompakt 41

42 3 Werkzeuge den und die Projektpläne und Aufgaben dort ablegen. Das notwendige Add-in steht nach der Installation von Visual Studio zur Verfügung. Damit erhält der Projektleiter eine einfache Sicht auf den Projektfortschritt, die aber in die Werkzeuge der Entwickler direkt integriert ist. Hinweis Die Integration von Project zeigt hier auch noch einmal die Intention des Team Foundation Server: Biete allen Beteiligten passende Sichten. So kann der Projektmanager beispielsweise sein gewohntes Project verwenden und trotzdem synchrone Datensätze mit seinen Entwicklern austauschen. Sollten es Kunden fordern, können beispielsweise auch Kalkulationen in Excel exportiert werden. Auch Plug-ins für Ecplise sind mittlerweile verfügbar, sodass die Möglichkeiten hier sehr vielfältig sind Durch die nun mögliche Verwaltung der verschiedenen, am Projekt beteiligten Ressourcen, die Möglichkeit der Hinterlegung zum Beispiel von Tagessätzen und die Einsatzplanung/Urlaubsplanung ist auch eine finanzielle Steuerung des Projekts möglich. 3.2 Werkzeuge des IT-Betriebs Für den IT-Betrieb existiert eine babylonische Vielzahl von Werkzeugen. Wir werden hier wieder die Produkte aufgreifen, die die schon vorgestellten Aufgaben des IT-Betriebs abdecken und unterstützen. In diesem Abschnitt werden wir schwerpunktmäßig auf die ITIL-Tools und die Microsoft-Produkte eingehen und darstellen, welche Aspekte des Softwarelebenszyklus sie abdecken, wie sie kombiniert und sinnvoll eingesetzt werden. 42

43 Werkzeuge des IT-Betriebs Verteilung SMS Wir haben die Übernahme von Software aus der Entwicklung in den Betrieb bereits angesprochen und als wichtig eingestuft. Der System Center Configuration Manager 2007, vormals Systems Management Server (SMS), von Microsoft ist das Werkzeug, das für die Verteilung von Software und das Asset Management in der Systems Center Suite verantwortlich ist. Damit werden die Informationen über die im Einsatz befindlichen IT-Systeme gesammelt und inventarisiert (Abbildung 3.4). Dazu gehören nicht nur die Informationen über die Hardwareausstattung der verschiedenen Systeme, sondern auch die Software, die auf diesen eingesetzt wird, mit ihren Komponenten und Updates. Abb. 3.4: Der Ressource Explorer des SMS schnell + kompakt 43

44 3 Werkzeuge SMS verwendet dazu einen Agenten, der auf den zu verwaltenden Rechnern installiert wird und die Verwaltungsaufgaben übernimmt. Die Inventardaten der Rechner werden gesammelt und an die SMS-Infrastruktur weitergeleitet. Darüber hinaus können für das Patchmanagement Agenten ausgeführt werden, die den Zustand des Rechners analysieren und überprüfen, welche Patches bereits eingerichtet sind. Dazu wird ein Katalog zur Verfügung gestellt, der die Informationen der Windows Update Site beinhaltet und die Installation der notwendigen Patches prüfbar macht. Die Schnittstelle des Katalogs ist offengelegt, damit sich auch andere Hersteller in diesen Prozess integrieren können. Für Adobe Flash ist dies bereits möglich. Diese Tools dienen nach dem Deployment eines Patch auch der Überprüfung, ob die Installation erfolgreich war. Dazu bietet SMS die Dienste zur Verteilung von Anwendungen und Patches auf die Infrastruktur. Diese Funktionen können von Anwendungsentwicklern benutzt werden, um für die eigenen Anwendungen Updates zu verteilen. Mit dem Desired Configuration Monitoring steht ein Modul für SMS zur Verfügung, das es ermöglicht, einen standardisierten Server oder Desktop zu beschreiben und Abweichungen von diesem Standardmodell von verschiedenen Systemen zu erkennen. Damit wird die Durchsetzung eines Standardmodells vereinfacht und die Einhaltung der aufgestellten Richtlinien überwacht. Durch die Integration in den Verteilungsmechanismus werden Rechner automatisch aktualisiert und die installierten Softwarekomponenten auf dem vorgegebenen Standard gehalten, auch neue Installation Komponenten auf den Rechner bringen, die veraltet sind. Überwachung/Steuerung MOM Neben der Verteilung der Software spielt vor allem die Überwachung des korrekten Betriebs der IT-Systeme eine entscheidende 44

45 Werkzeuge des IT-Betriebs Rolle. Der Microsoft Operations Manager (MOM) erfüllt genau diese Aufgabe, indem er Anwendungen überwacht und Fehler erkennt. MOM überwacht die Ereignislogbücher der verwalteten Serversysteme und analysiert alle Ereignisse, die dort verzeichnet werden. Darüber hinaus werden die Leistungsdaten der Rechner gesammelt, die auch mit dem Performance Monitor von Windows aufgezeichnet werden können. Für spezielle Anwendungen erfolgt auch eine Überprüfung der Erreichbarkeit und des Antwortverhaltens der Softwarekomponenten durch Testzugriffe. Die Information, welche Bedeutung ein Fehler einer Anwendung hat und wie diese aufgebaut ist, steckt dabei in so genannten Management Packs. Diese stehen für die Microsoft-Serverkomponenten standardmäßig zur Verfügung, können mit einem SDK aber auch einfach entwickelt werden. Dabei werden für die Management Packs Informationen aus der Entwicklung der Software benötigt, dort müssen alle Ereignisse, die eine Anwendung erzeugen kann, mit ihrer jeweiligen Bedeutung hinterlegt werden. Im Management Pack werden diese Informationen dann mit der Beschreibung verknüpft. Darüber hinaus müssen Handlungsanweisungen beschrieben werden, wie bei entsprechenden Ereignissen zu verfahren ist. Helpdesk Ticket Tracker Der Ticket Tracker (Abbildung 3.5) ist ein wichtiges Werkzeug für den Help/Service Desk. Anfragen von Benutzern oder Meldungen der Managementwerkzeuge werden im Ticket Tracker erfasst und eingestuft. Der Ticket Tracker ermöglicht neben der Beschreibung der verschiedenen durchgeführten Aktivitäten auch die Abrechnung der Arbeitszeit der Supportmitarbeiter. Der Ticket Tracker stellt quasi das Gegenstück zum Bugtracker in der Softwareentwicklung dar. Er geht darüber hinaus, weil hier auch Statusmeldungen gesammelt werden, Tickets, die Fehler in schnell + kompakt 45

46 3 Werkzeuge einer Anwendung beschreiben, sollten jedoch direkt in das Bugtracking-Tool der Entwickler übernommen werden, um so eine durchgängige Dokumentation von Veränderungen am Sourcecode der Anwendung zu erhalten. Abb. 3.5: Beispiel eines Tickets für den Helpdesk CMDB ITIL Inventar Die CMDB realisiert die Informationsbasis für das ITIL Configuration Management und beinhaltet die Inventardaten für das Asset Management, aber auch die Informationen über die Kon- 46

47 Werkzeuge des IT-Betriebs figurationen der verschiedenen Anwendungen und Systeme. Darüber hinaus wird nicht nur das aktuelle Bild in der CMDB abgelegt, sondern auch alle Veränderungen werden hier dokumentiert. Damit sind Trendanalysen möglich und es entsteht bei Fehlern durch die Integration des Incident Management eine Wissenbasis, die neben der Beschreibung auch die Problemlösung beinhaltet. Application Scanner Application Scanner analysieren die IT-Infrastruktur und die Softwareverteilung und legen diese Informationen in der CMDB ab. Neben der Erstellung eines ersten Inventars werden so auch die Auswirkungen von Veränderungen der Infrastruktur verfolgt und überprüft. Verschränkung Entwicklung & Betrieb Ein interessantes Produkt war der Application Center 2000 (AC2000), das Produkt ist mittlerweile abgekündigt. Wir werden das Verfahren kurz vorstellen, da es ein gutes Beispiel für einen gemeinsamen Ansatz ist. Application Center kann mehrere Webserver zu einem Cluster zusammenfassen und für diesen das Management übernehmen. Die verschiedenen Server stellen dabei gemeinsam die Website zur Verfügung, die Last wird auf die verschiedenen Systeme verteilt. Alle Konfigurationsänderungen am Masterserver werden auf die anderen Cluster-Knoten gespiegelt. Innerhalb des Systems werden Anwendungen basierend auf COM-Komponenten und Websites definiert, die überwacht und verwaltet werden können. AC2000 integriert darüber hinaus mit dem Staging-Prozess ein Verfahren zur Übernahme von Testkonfigurationen in den Betrieb. Das Verfahren geht von einem Integrationsserver aus, der weitgehend der Produktivumgebung entspricht. Auf dieser Ma- schnell + kompakt 47

48 3 Werkzeuge schine werden die Komponenten vom Softwareentwickler installiert. Danach wird die Umgebung einem Integrationstest unterzogen und die korrekte Funktionsweise aller Komponenten der Anwendung sichergestellt. Fällt dieser Test positiv aus, kann AC2000 die Applikation durch den Staging-Prozess automatisch mit allen Konfigurationseinstellungen auf die produktive Umgebung transferieren. Der Prozess ist anpassbar. So ließen sich hier auch Tests aus der Softwareentwicklung integrieren. AC2000 kann außerdem den Zustand von Websites überwachen. Dabei wird auf die verschiedenen Seiten zugegriffen und bei Fehlern der Administrator über verschiedene Mechanismen gewarnt. Hier können auch entsprechende Skripte integriert werden, die einen Server im Fehlerfall neu starten oder Änderungen an der Konfiguration vornehmen. Für die Tests können hier auch externe Komponenten eingebunden werden. Eine Möglichkeit ist die Wiederverwendung der Unit-Tests, solange sich diese auch in der produktiven Umgebung einsetzen lassen und keine Daten verändern. Ein Test der Funktion delete-all() wäre hier nicht sinnvoll. Die aktuellen Entwicklungen in Visual Studio 2005 zeigen eine neue Richtung auf und verwenden einen etwas anderen Ansatz und erfordern einen administrativen Zugang des Entwicklers auf die Produktivumgebung. Dieser Ansatz ist in kleineren Umgebungen eventuell sinnvoll, wird sich aber in großen Organisationen nicht umsetzen lassen. Ein Staging-Prozess und die entsprechende Tool-Unterstützung fehlen leider momentan. Durch das Modell der Dynamic System Initiative (DSI) soll aber ein gemeinsames Modell des Entwicklers und des Administrators geschaffen werden. VS2005 ist das erste Produkt, in das DSI integriert wurde. Systems Center Configuration Manager 2007, der Nachfolger von SMS 2003, wird das erste Managementprodukt, das auf DSI basiert. Damit steht ein Application Scanner zur Verfügung, dessen Datenformat standardisiert ist. 48

49 Systementwicklung KAPITEL Anforderungsfestlegung Entwurf Entwicklung Test 66 Als Lebensabschnitt ist die Systementwicklung vergleichsweise kurz. Dennoch ist dieser Abschnitt derjenige, der wesentliche Weichen für das System, dessen Aussehen und seine Betriebseigenschaften festlegt. Darüber hinaus ist diese Phase diejenige, in der die Kreativität sowohl der Anwender, der Administratoren als auch der Entwickler gefragt ist ein erster Hinweis auf Konfliktpotenzial, da deren Ziele nicht immer unbedingt übereinstimmen müssen. Um bereits früh eine Richtung und Struktur in die Entwicklung zu bekommen, werden Entwicklungsprozesse schon seit dem Wasserfallmodell 1 strukturiert. In diesem Kapitel geben wir Ihnen Einblick in die wesentlichen Entwicklungsetappen und beschreiben zentrale Prozesse und Ergebnisse von der Anforderungsermittlung bis zur Vorbereitung der Verteilung. 1. Wasserfallmodell nach Winston Royce, Managing the Development of Large Software Systems: Concepts and Techniques, schnell + kompakt 49

50 4 Systementwicklung 4.1 Anforderungsfestlegung Anforderungsfestlegung ist Sache des Kunden! Denn nur er weiß, was er will. Anforderungsfestlegung ist eine der Kerndisziplinen in einem Projekt. Die meisten Weichen werden hier gestellt und alle Beteiligten können sich hier mit einbringen. Was sind Anforderungen? Anforderungen legen die quantitativen und die qualitativen Eigenschaften eines Softwaresystems fest. Sie sind der Ausgangspunkt für die Systemerstellung und definieren gleichzeitig Bedingungen für Abnahme und Betrieb. Üblicherweise werden Anforderungen in funktionale und nichtfunktionale Anforderungen unterteilt. Erstere beschreiben dabei im Wesentlichen den Leistungsumfang eines Systems, Letztere die Art der Leistungserbringung. Hinweis Unterscheiden Sie immer zwischen Anforderungen und Spezifikationen! Diese beiden Begriffe sind nicht gleichzusetzen. Anforderungen machen Aussagen zu Leistungsumfang und Aussehen eines Produkts. Sie treffen jedoch keine Aussage über die konkrete Realisierung. Das übernimmt eine Spezifikation, die in der Regel immer direkt umsetzbar ist. Die Trennung in funktionale und nichtfunktionale Anforderungen ist sehr sinnvoll, da sich hier verschiedene Interessen separat betrachten lassen. Anforderungen und Anwender Fachabteilungen sind in der Regel daran interessiert, dass alle relevanten Geschäftsprozesse angemessen (wenn möglich vollständig) abgebildet werden. Dies beinhaltet neben einer vollständigen Abbildung der Domäne (Daten, Vorgänge) auch die 50

51 Anforderungsfestlegung Erfassung aller Beteiligten (Stakeholder), also die Definition eines Rollenmodells. Mit Rollen kommt automatisch der Anwender mit ins Spiel. Anwender lassen sich in vielerlei Form beschreiben. Einen sehr hohen Verbreitungsgrad weist beispielsweise die Beschreibung eines Anwenders nach Murphy auf: ein typischer Kunde/Anwender weiß nicht, was er will; er weiß aber, was er (definitiv) nicht will; was er stattdessen will, weiß er aber auch nicht. Diese Sicht ist vielleicht etwas polemisch, zeigt jedoch schon recht eindrucksvoll die eigentliche Problematik. Abbildung 4.1 stellt ein sogenanntes Kano-Diagramm dar. sehr zufrieden Zufriedenheit Durch den Anwender erwarteter (Zusatz)-Nutzen... KANN völlig unzufrieden Erfüllungsgrad vollständig MUSS geforderter/ fachlicher Nutzen völlig unzufrieden Abb. 4.1: Beispiel für ein Kano-Diagramm schnell + kompakt 51

52 4 Systementwicklung Anwenderforderungen und funktionale Anforderungen der Fachabteilungen ergänzen sich in weiten Teilen, unterscheiden sich jedoch in der Zufriedenstellungsschranke. Funktionale Anforderungen der Fachabteilungen lassen sich in der Regel auf die MUSS-Kriterien abbilden, die für sich alleine jedoch die Anwender nicht unbedingt zufriedenstellen. Der Anwender braucht mehr und, um bei Murphy zu bleiben, jeder auch etwas mehr von dem einen oder dem anderen Oftmals ist es schwer, diesen erwarteten (oftmals nicht geäußerten da selbstverständlichen) Zusatznutzen zu quantifizieren und in Anforderungen unterzubringen. An dieser Stelle greifen dann Anforderungen, die unterstützenden Charakter haben und die Randbedingungen für die Realisierung eines Systems festlegen. Diese nichtfunktionalen Anforderungen regeln beispielsweise: Leistungsanforderungen Qualitätsanforderungen Realisierungsanforderungen Oftmals finden sich hier Anforderungen nach Sicherheits-, Transaktions- oder Fehlerbehandlungsroutinen (also Anforderungen für die Betriebsphase). Aber auch Anforderungen im Bereich der Benutzerschnittstelle sind hier zu finden. Hinweis Für den Betrieb ergeben sich Anforderungen an die Architektur und das Management einer Software, die möglichst früh in die Planungen integriert werden sollten. Dazu gehören auch die bereits vorhandenen Basiskomponenten, auf die sich eine Anwendung stützen kann. Diese Sicht entspricht dabei oft nicht der des Anwenders des Systems, sondern ist eine dritte Sicht, die die Betreiber auf das System haben. 52

53 Anforderungsfestlegung Anforderungen erfassen und strukturieren Anforderungen können strukturiert erfasst werden. Am Beispiel des MSF 4.x Agile und der Unterstützung des Visual Studio können Sie das sehr einfach nachvollziehen (Abbildung 4.2). Abb. 4.2: Erfassen von Anforderungen im Visual Studio Um ein einheitliches Vorgehen auch über die Entwicklung hinaus zu ermöglichen, vertiefen wir die zugrunde liegenden Strukturen ein wenig und erzeugen eine Datenstruktur für Anforderungen, die wir dann auch für die Betriebsphase weiterverwenden. In Abbildung 4.3 sehen Sie ein InfoPath-Formular, das wir nach dem Vorbild der Szenariobeschreibungen des Visual Studio entworfen haben. Ebenfalls Pate stand ein Ticket Tracker, wie er bei uns im Einsatz ist. schnell + kompakt 53

54 4 Systementwicklung Abb. 4.3: Beispiel für ein InfoPath-Formular zur Erfassung von Anforderungen 54

55 Entwurf Profitipp Die Festlegung eines übergreifenden Formats für Anforderungen, Problem- und Änderungsmeldungen erleichtert die Kommunikation zwischen Entwicklung und Betrieb. Sie ermöglicht es beispielsweise, Problemmeldungen direkt in den Analyseprozess für die Weiterentwicklung eines Produkts zu integrieren. Insbesondere die Kommunikation sollten Sie im Hinterkopf haben, wenn Sie mit dem Gedanken spielen, sich InfoPath näher anzusehen. InfoPath unterstützt Sie, indem es den direkten Versand aus Outlook unterstützt und zentral via SharePoint verwaltet werden kann. 4.2 Entwurf Im Entwurf sind im Wesentlichen zwei Schienen zu befahren: Softwarearchitektur Softwarespezifikation Beide Disziplinen dienen einer (vollständigen) schrittweisen Beschreibung eines Systems und seiner Eigenschaften. Je nach gewähltem Vorgehen werden diese Disziplinen separat (zum Beispiel beim V-Modell XT) oder kombiniert (zum Beispiel beim MSF) betrachtet. Architektur Zur Architektur finden Sie bereits bei einer einfachen Google-Suche nahezu unzählige Definitionen. Wir reduzieren an dieser Stelle den Architekturbegriff zunächst einmal auf die strukturellen Anteile eines Systems, das heißt die Zerlegung einer Software in ihre Komponenten und die zu betrachtenden Abhängigkeiten. schnell + kompakt 55

56 4 Systementwicklung Bereits Software durchschnittlicher Größe kann heute nur noch schwer von Einzelpersonen bewältigt werden. Dort, wo man also schon auf der Ebene des Projektmanagements damit anfängt, einzelne Teile in separate Arbeitspakete zu verlagern, ist die Zerlegung eines Gesamtsystems in dazu passende Teile nur der nächste logische Schritt. Neben der allgemeinen Darstellung des Aufbaus einer Software definiert die Architektur also gleichermaßen auch die Zerlegung (Dekomposition) und dann rekursiv die Struktur der resultierenden Komponenten (Abbildung 4.4). Abb. 4.4: Anwendungsarchitektur auf der obersten Ebene in einem Application Diagram 56

57 Entwurf Abbildung 4.4 zeigt ein Beispiel für eine solche Systemstruktur. Verwendung findet hier die Darstellung, die der Anwendungsdesigner des Visual Studio anbietet. Die Abbildung zeigt die Lösungsarchitektur unseres Beispiels bestehend aus fünf Web Services und einer Windows-Forms-Anwendung. Die beiden links zu sehenden Services AuthorizationService und User- Service bilden das Benutzermanagement ab, während die verbleibenden drei Web Services die Fachlogik für den Trainingsbetrieb im Fitnessstudio liefern. Hier finden Sie außerdem ein anschauliches Beispiel für eine hierarchische Systemzerlegung. Auf der obersten Ebene (Abbildung 4.4) finden Sie den Verbund der Teilsysteme, die das Gesamtsystem bilden. Hinter jedem der unscheinbaren Kästen verbirgt sich ein Visual-Studio-Projekt, das selbst auch wieder modellierbar ist. Die fachlichen Strukturen (das Domänenmodell) lassen sich beispielsweise mithilfe des Class Designer anfertigen. Spezifikation Auf Augenhöhe mit der Architektur sehen wir die Spezifikationsanteile einer Software. Hier geht es im Wesentlichen darum, Anforderungen in (implementierbare) Funktionen umzusetzen oder Zuordnungen zu Schnittstellen vorzunehmen. Lastenheft/ Ausschreibung Spezifikation Implementierung AF AF AF AF Code Code Code Code Code Abb. 4.5: Entstehungsweg von Code aus Anforderungen und Spezifikationen schnell + kompakt 57

58 4 Systementwicklung Spezifikationen zeigen somit auch Verhaltensaspekte eines Systems. Wichtig ist, dass Architektur (Struktur) und Spezifikation (Verhalten) konsistent zueinander sind. Ebenso wichtig ist es, dass es zweifelsfrei möglich sein muss, eine Brücke von den Anforderungen beginnend über Architektur- und Spezifikationsdokumente hin zur konkreten Implementierung schlagen zu können. Hier gibt es eine Reihe von Techniken, die im Rahmen einer Anforderungsverfolgung möglich (im Kontext bestimmter CMMI-Level 2 sogar erforderlich) sind. In Abbildung 4.5 haben wir dies noch einmal illustriert. Diesmal auf einer abstrakteren Ebene finden Sie eine Menge von Anforderungen (AF), die auf Architektur-/Spezifikationsdokumente abgebildet werden. Eine feinere Unterscheidung machen wir an dieser Stelle nicht und überlassen dies den Vorgaben konkreter Vorgehensmodelle. Aus den Spezifikationen entstehen dann entweder direkt oder über weitere Zwischenschritte Implementierungen (hier Codes). Alle Anteile dieser Kette Anforderung Spezifikation Code müssen eindeutig positionierbar sein. Es ist insbesondere in komplexen Systemen erforderlich, zu wissen, aufgrund welcher Anforderung bestimmter Code erstellt wurde und warum er sich genau so und so verhalten muss. 4.3 Entwicklung Nachdem wir die Entwurfsphase hinter uns gelassen haben, befinden wir uns nun schon mitten in der Entwicklung. Als zentrale Größe finden wir die Anforderungen auch hier wieder. Üblicherweise entstehen aus einer Anforderung auf der Ebene der Implementierung mehrere Arbeitsaufträge, die die Entwicklung von Komponenten zur Folge haben. 2. CMMI: Capability Maturaty Model Integrated Reifegradmaß des Software Engineering Institute (SEI) 58

59 Entwicklung Hinweis Arbeitsaufträge verlassen dabei den Bereich des Anforderungsmanagements und sind im Aufgabenmanagement anzusiedeln. Aufgabenmanagement ist eine nicht zu unterschätzende Managementdisziplin, die gerade in verteilten Entwicklungsprojekten hoher Aufmerksamkeit bedarf. Meist sind die Entwicklungsaufgaben (der MSF spricht hier beispielsweise von Tasks) für sich isoliert und können vom Entwickler als kleine, eigenständige Einheit betrachtet und umgesetzt werden. Abbildung 4.6 zeigt Ihnen dies am Beispiel des Visual Studio, in dem unser Beispielprojekt angelegt ist. Abb. 4.6: Aufgabenmanagement im Visual Studio System schnell + kompakt 59

60 4 Systementwicklung Einige der Aufgaben werden beim Anlegen eines Projekts automatisch durch das System angelegt. Diese Aufgaben sind durch den Prozess definiert und dienen beispielsweise dem Projekt- Set-Up. Eine Integration der arbeitsteilig erstellten Systemteile zum Gesamtsystem erfolgt spätestens beim Integrationstest. Das Aufgabenmanagement muss hier allen Beteiligten genügend Informationen bereitstellen. So müssen Entwickler über die Szenarios informiert werden, die sie implementieren sollen, während gleichzeitig die Tester entsprechende Tests vorbereiten müssen. Hinweis Die Synchronisation und Konsistenzhaltung der Aufgaben ist gerade während der Entwicklungsabschnitte essenziell! Lassen Sie zu, dass Entwicklungs- oder Testaufgaben nicht konsistent zu den definierten Anforderungen sind, erhalten Sie über kurz oder lang das, was wir als den UML-Effekt bezeichnen: Modellierung, Design und Entwurf stellen nicht das dar, was implementiert wurde, und haben nur noch den Wert eines Schaubilds. Unabhängig von der Größe des Systems sollten Sie immer zwei parallel laufende Entwicklungsstränge anstreben: Entwicklung der Software Entwicklung der Testrahmen Wir propagieren hier ganz klar den Test-Driven Development Ansatz, der eigentlich aus dem Bereich der agilen Methoden kommt. 60

61 Entwicklung Test-Driven Development Test-Driven Development ist ein Programmierparadigma, in dem basierend auf einer Szenariobeschreibung, einer Anforderung oder optimalerweise einer Spezifikation zuerst ein Testrahmen entwickelt wird, der die spezifizierte Funktionalität erfüllt. Code wird gegen diesen Testrahmen entwickelt. Der Testrahmen wird somit zum Akzeptanzkriterium. Ändern sich Anforderungen, wird zunächst wieder der Testrahmen angepasst und der (bereits existierende) Code gegen den aktualisierten Testrahmen geprüft. Vorteilhaft an diesem Ansatz ist, dass er sich zumindest auf der Ebene der Fachkomponenten weitgehend automatisieren lässt. Zum Einsatz kommen hier populäre Open-Source-Werkzeuge wie JUnit oder NUnit. Aber auch komplexe Entwicklungsumgebungen wie das Visual Studio, SharpDevelop oder Eclipse bieten hier mittlerweile schon eine ausgereifte Unterstützung an. Später greifen wir dieses Thema noch einmal auf. Modelle und Code Weg vom Test und hin zum Code befassen wir uns jetzt mit Mitteln zur Programmierung. Ein Ergebnis der Architektur ist ein vorliegendes Modell aus Fachklassen (auch Domänenmodell). Beziehen wir uns wieder auf das Visual Studio als Entwicklungswerkzeug, finden Sie dort bereits entsprechende Modellierungswerkzeuge (vgl. Abbildung 4.4), die es Ihnen gestatten, Klassenmodelle 3 zu erstellen. Diese Modelle finden sich 1:1 im Code wieder, das heißt, dass Modell und Software konsistent zueinander sind. Die Sicherstellung der Konsistenz ist deshalb als zentral herauszustellen, da auch transitiv über mehrere Ebenen noch 3. Obwohl die Ähnlichkeit durchaus vorhanden ist, sind die Klassendiagramme des Visual Studio Class Designer nicht zur UML 2.0 konform. schnell + kompakt 61

62 4 Systementwicklung nachvollziehbar sein muss, aus welcher Anforderung der Code resultiert (Abbildung 4.5). Hinweis Die Nachvollziehbarkeit der Anforderungen ist insbesondere für die Betriebsphase und eventuell auftretende Änderungsforderungen relevant. Tritt beispielsweise ein Problem auf, muss es sich schnell lokalisieren lassen und die auslösenden und betroffenen Komponenten müssen identifizierbar sein. Nur so ist eine schnelle, zielgerichtete Intervention möglich. Über die Nachvollziehbarkeit von Anforderungen Die Nachvollziehbarkeit von Anforderungen bis hinunter auf die Ebene der Codes hat noch weitere Konsequenzen: Der final implementierte Code wird erstellt auf der Ebene: einer Architektur, einer Spezifikation oder eines Testfalls, der eine Spezifikation erfüllt. Der Testfall selbst wird ebenfalls auf der Grundlage der Spezifikation erstellt und prüft ein spezifiziertes Verhalten. Architektur und Spezifikation ergeben sich aus den Anforderungen, die der Kunde (Anwenderforderungen) angibt. Gerade aus dem letzten Punkt ergibt sich, dass Anforderungen zwischen zwei Parteien ausgetauscht werden müssen. Dabei ist es in der Regel der Anwender/Kunde, der eine Abnahme nur unter der Bedingung, dass die eine oder andere Anforderung modifiziert wird, erteilt. Prototypen sind ein Paradebeispiel für dieses Vorgehen. 62

63 Entwicklung Über Änderungen und deren Auswirkungen Werden Anforderungen im Rahmen einer stufenweisen Entwicklung geändert, müssen einerseits die unmittelbaren Konsequenzen ermittelbar sein. Andererseits müssen aber auch indirekt betroffene Teile identifizierbar sein. Unter Teile sind hier alle Elemente eines Projekts (Anforderungen, Spezifikationen, Tests, Code) zu verstehen. In Abbildung 4.7 können Sie die Problematik noch einmal nachvollziehen: Eine Anforderung wird durch einen Kunden geändert. Dementsprechend ändern sich Teile der Spezifikation des zu erstellenden Systems mit der Konsequenz, dass entweder neuer Code erstellt werden muss oder andererseits bereits existierender Code angepasst, gegebenenfalls sogar verworfen werden muss. Insbesondere im letzteren Fall ist eine lückenlose (am besten automatisierbare) Nachverfolgung von Abhängigkeiten und Änderungen zwingend. Ein Beispiel für ein Konzept zur konsistenten Abhängigkeitsermittlung/-verfolgung ist das Refactoring ebenfalls wieder als Disziplin den agilen Methoden entliehen. Beispiel Anforderung eines Kunden kann es beispielsweise sein, dass sich ein Bezeichner von A in B ändert. Diese Änderung muss konsistent in allen Bereichen eines Projekts nachgezogen werden (siehe auch Abbildung 4.7). Ein praktisches Beispiel wäre an dieser Stelle die Änderung eines Datentyps an einer viel benutzten Schnittstelle. Refactoring ist nur ein kleines, in seiner Wirkungsweise auf Code begrenztes Beispiel. Anforderungsverfolgung und die Konsistenzhaltung von Code zielt hier auf ein wesentlich breiteres Feld ab, zum Beispiel bei der Integration oder Änderung ganzer Geschäftsprozesse. schnell + kompakt 63

64 4 Systementwicklung Lastenheft/ Ausschreibung Spezifikation Implementierung Änderung durch Kunden AF AF AF AF AF Änderung schlagen durch neuer Code Code Code Code Code Code geänderter Code Code Code Code Code Code Abb. 4.7: Änderung von Anforderungen und deren Auswirkungen auf Spezifikationen und Codes Qualität und Dokumentation von Code Ein Mittel, um sich in seinem Code zurechtzufinden, ist das Modell (wie gerade besprochen). Modell und Code sind immer konsistent zu halten. Doch was kann ein Modell eigentlich erfassen? Deskriptive Texte wie zum Beispiel natürlichsprachliche Beschreibungen einer Funktionalität einer Klasse gehören üblicherweise nicht dazu. Diese sind für Modellelemente schon zu konkret. Dennoch ist die Dokumentation des Quellcodes elementar! Wichtig ist es auch, einheitliche (möglicherweise sogar organisationsweite) Richtlinien verfügbar zu haben. Wenn Sie sich beispielsweise C#-Code ansehen, sehen Sie, dass dieser bereits Normative für seine Dokumentation anbietet. Mit einer inline-xml- Dokumentation, die überdies vom Compiler geprüft wird, gehen Sie schon erste wesentliche Schritte. Doch trotz allem ist Dokumentation von Code ein Vorgang, den Entwickler in der Regel händisch vornehmen. Sie erlassen eine Regel zur Gestaltung des 64

65 Entwicklung Quellcodes (nichts weiter ist eine Dokumentationsvorschrift) und diese Regel wird eigenverantwortlich ausgeführt. Über die Dokumentation hinaus haben Sie aber auch die Möglichkeit, weitergehende Richtlinien zu erlassen und diese sogar zu Teilen automatisch zu prüfen. Beispielhaft wollen wir hier auf das Werkzeug FxCop (Abbildung 4.8) verweisen, das Sie bei einer automatischen Qualitätssicherung Ihres Quellcodes unterstützt. Abb. 4.8: FxCop dient der statischen Codeanalyse und setzt Coding Rules konsequent durch. FxCop prüft Ihren Code anhand zuvor festgelegter Regeln, zum Beispiel, ob Sie Ihre Assemblies auch digital signiert haben. Abbildung 4.8 zeigt Ihnen die Stand-alone-Version des Tool. Mit schnell + kompakt 65

66 4 Systementwicklung dem Visual Studio 2005 ist dieses Werkzeug auch direkt integriert, was Ihnen weitreichende Optionen eröffnet. So können Sie beispielsweise erzwingen, dass nur durch FxCop geprüfter Code, also Code, der Ihren Vorgaben entspricht, durch den Team Foundation Server eingecheckt werden darf. 4.4 Test Mit der Anwendung von FxCop bewegen wir uns schon im Bereich der Qualitätssicherung. Wenden wir uns dem wohl bekanntesten Vertreter der qualitätssichernden Maßnahmen zu: dem Test. Testen ist neben dem Entwurf zeitlich üblicherweise mit einer der aufwändigsten Teile eines Entwicklungsprojekts. Wir empfehlen, soweit möglich Test-Driven-Development-Verfahren einzusetzen, was neben der guten Möglichkeit der Anforderungsverfolgung auch die Option der automatisierten Tests bietet. Dies setzt natürlich voraus, dass einerseits Ihre Werkzeuge Testautomatisierung unterstützen, andererseits Ihr zu entwickelndes System die Automatisierung aber auch ermöglicht. Als unkritisch stufen wir dabei Systeme ein, in denen die Benutzerinteraktion nicht bestimmend für den Systemablauf ist. Dies meint zum Beispiel Komponenten der Geschäftslogik, die Sie mit synthetischen Testdaten versorgen können. Benutzerinteraktionen, also interaktive Systeme, sind hier wesentlich schlechter automatisch zu testen. Eine Lösungsvariante, die sich hier einiger Beliebtheit erfreut, ist das Testen mithilfe von Skripten. Hinweis Darüber hinaus ergibt sich die Möglichkeit, die Tests auch zu verwenden, um Module zur Überwachung der Software im Betrieb zu implementieren. So kann der korrekte Ablauf der Anwendung sichergestellt werden. Die Wiederverwendung der Testmodule verringert die Entwicklungskosten. Eine Wie- 66

67 Test derverwendung 1:1 ist jedoch meist nicht möglich, da auf produktiven Daten einige Tests (zum Beispiel alle Objekte in der Datenbank löschen) nicht ausgeführt werden können. Um Testprozesse weiter zu systematisieren, beziehen wir uns erneut auf die Zentralisierung der Anforderungen. Ein Testprozess startet hier wieder bei der Festlegung der Anforderung, deren Überführung in Architektur und Spezifikation und das Erstellen eines Testfalls. Hierbei muss aber zunächst noch geklärt werden, was zu testen ist. Sicherlich können Sie sich einfach vorstellen, dass der Test einer einzelnen Klasse anders aussieht, als der Test eines vollständig integrierten Systems im Rahmen einer Abnahme. Daher stellen wir verschiedene Ebenen von Tests fest (Abbildung 4.9). Integration Stufe n (Gesamtsystem) Integration Stufe Integration Stufe 2 Integration Stufe 1 Unit Test Code Abnahme (Gesamtsystem) Abnahme (Teilsystem(e)) Abb. 4.9: Testebenen, Integration und Abnahmen Unit Tests Die Unit Tests bilden die unterste, konkreteste Ebene der Testhierarchie (Abbildung 4.9). Diese sind in der Regel voll automatisiert und testen Einzelkomponenten bzw. auch teilintegrierte Subsysteme. Unit Tests können über die Spezifikation aus den schnell + kompakt 67

68 4 Systementwicklung Anforderungen abgeleitet werden. So können beispielsweise in der Spezifikation definierte Abläufe im einzelnen Testfall implementiert werden. Auch ist es auf der Grundlage der Spezifikation relativ einfach möglich, Testdaten zu ermitteln. Zumindest die drei Standardklassen von Testdaten: gültige Standardtestdaten, ungültige Daten und Daten in Randbereichen 4 lassen sich hier schon recht gut ermitteln. Hierzu ist es aber erforderlich, dass die Formulierung der Anforderungen (und nachfolgend der Spezifikation) Vor- und Nachbedingungen sowie Regelabläufe und Ausnahmesituationen berücksichtigt. Profitipp Unit Tests = Spezifikation: Sowohl in kleinen Projekten als auch in Szenarios, in denen Sie eine Spezifikation Ihres Systems liefern müssen, stellen Unit Tests eine billige Möglichkeit dar, mehrere Fliegen mit einer Klappe zu schlagen. Sie spezifizieren mit Unit Tests erwartetes Verhalten das entspricht im Wesentlichen auch den Inhalten einer Spezifikation. Wenn Sie also ein System spezifizieren müssen, tun Sie das durch die Definition der Tests. Sie können somit beispielsweise auch einfach nachweisen, dass das System die Spezifikation erfüllt. Integrationstests Integrationstests finden auf höheren Systemebenen statt. Der Ansatz, den wir hier vorstellen, ist auch unter dem Begriff Bottom-Up-Test bekannt. 4. Unter Randbereichen von Testdaten verstehen wir Datensätze, bei denen das Testergebnis umschlägt. Ein Beispiel hierfür ist die Behandlung von Extremwerten. 68

69 Test Diese Teststrategie geht von einem systematischen Test einzelner, kleiner Einheiten aus, die dann schrittweise zu Einheiten höherer Dichte integriert werden. Dabei können die Einzeltests auch noch vom jeweiligen Entwickler verwendet werden, um die korrekte Arbeitsweise seines Moduls zu testen, bevor dieses in die gemeinsame Codebasis aller Entwickler übernommen wird. Der letzte Punkt bedarf auch großer Aufmerksamkeit: Verwenden Sie beispielsweise einen gemeinsamen Nightly-Build, sollten Sie generell fordern, dass von den Entwicklern nur testbarer (in der Regel also zumindest compilierbarer) Code in das Repository eingestellt wird. Der Team Foundation Server unterstützt Sie beispielsweise mit einer entsprechenden Check-In Policy und verweigert gegebenenfalls das Einchecken der Daten. Hinweis Mit der Integrationsdichte steigt bei diesem Verfahren auch die Komplexität und Vollständigkeit; so weit, bis zu einem definierten Zeitpunkt ein vollständig integriertes System vorliegt. Mit den Integrationstests führen Sie in definierten Schritten die einzelnen, arbeitsteilig entwickelten Teilsysteme wieder zusammen. Dabei gilt es insbesondere zu beachten, dass die Anzahl der Testebenen (siehe Abbildung 4.9), das heißt also die Anzahl der Testintegrationsstufen, der der Spezifikationshierarchie entspricht. Hinweis Stellen Sie sich die zu entwickelnde Software als Baum vor, in dem jeder Knoten ein Teilsystem und jedes Blatt eine konkrete Implementierungseinheit darstellt. Dann gehen Sie mit den Integrationstests jeweils die Knoten zurück bis zur Wurzel. Sollten Sie irgendwo unterwegs hängen bleiben, sollten Sie schnell + kompakt 69

70 4 Systementwicklung sich noch einmal mit Ihrer Systemarchitektur beschäftigen. Möglicherweise ist diese nicht mit dem Release-Plan abgestimmt. Abnahme- und Akzeptanztests Haben Sie die Integrationstests so weit durchgeführt, dass Sie nur noch den Wurzelknoten testen müssen, haben Sie im Testabschnitt im Wesentlichen nur noch zwei Schritte vor sich: Den abschließenden Gesamtsystemtest Den Akzeptanztest Der Akzeptanztest ist nun wieder ein gutes Stück davon abhängig, wie Ihr Projekt aufgebaut ist bzw. welche Art Akzeptanztest Ihnen Ihr gewähltes Vorgehensmodell vorschreibt. Profitipp Oft wird erst bei dieser Art Test der Kunde wieder in die Entwicklung mit einbezogen. Vermeiden Sie das und beziehen Sie ihn kontinuierlich während der gesamten Entwicklung mit ein! Bei der Abnahme haben Sie eine Skalierung der Lieferung vom einfachen Prototypen, der Ihnen durch einen Kunden abgenommen wird, bis hin zur komplexen Lieferung, die aus der Software, Dokumentation, Datenträgern oder Ähnlichem besteht. Für die Abnahme sind verschiedene Verfahren denkbar. Ein praktikables Vorgehen ist beispielsweise die Miteinbeziehung von Pilotbenutzern, die das System später auch einsetzen und durch den Test geschult werden. Wichtig ist hierbei, dass die Infrastruktur, auf der dieser Test ausgeführt wird, die Integrations- oder Staging-Plattform möglichst der Konfiguration der Betriebsplattform entsprechen. Hier greifen wieder die Anforde- 70

71 Test rungen, die eine Abnahme im Rahmen eines Akzeptanztests mithilfe diverser Abnahmekriterien hinreichend definieren sollten. Hinweis Üblicherweise werden die Konditionen für eine Abnahme zwar in den Anforderungen des Kunden beschrieben, greifen werden jedoch die vertraglich vereinbarten Konditionen. Hier kann es also sein, dass (technische) Anforderungen und Abnahmekriterien differieren. Die Rolle der Anforderungen Wie Sie sehen, reichen die ursprünglich definierten Anforderungen einer Software über den Entwurf, die Implementierung bis in den Test und die Abnahme hinein. Daher ist es wichtig und unerlässlich, dass es in einem Projekt zu jeder Zeit möglich ist, Anforderungen zuordnen und zurückverfolgen zu können. Es muss immer möglich sein, zu einer gegebenen Anforderung A zu ermitteln, zu welchen anderen Anforderungen sie in Beziehung steht und welche Realisierungseinheiten daraus resultieren. Das Resultieren von Realisierungseinheiten, also üblicherweise Code ist auch ein wesentlicher Punkt, der beachtet werden muss, wenn das System in den Betrieb überführt werden muss. Es ist erforderlich, dass sich der Erzeugnispfad von der Realisierung wieder auf die einzelne Anforderung zurückführen lässt (bidirektionales Tracing). In der Betriebsphase ist dies eines der wesentlichen Kriterien für ein funktionierendes Änderungsmanagement. schnell + kompakt 71

72

73 KAPITEL 5 Betrieb 5.1 Ziele des Betriebs Deployment Betrieb Wartung & Pflege 86 Der Betrieb übernimmt die Ergebnisse der Softwareentwicklung, vor allem die verschiedenen Softwarekomponenten, aber auch die entsprechende Dokumentation, richtet diese auf der IT-Infrastruktur ein, passt die Einstellungen der Softwarekomponenten an die Umgebung an und betreibt die Softwarekomponenten auf den Servern des Rechenzentrums. Damit werden diese für die Anwender nutzbar. Je nach Organisation kann der Betrieb durch eine Fachabteilung im Unternehmen oder durch einen externen Dienstleister im Rahmen eines Outsourcing-Vertrags erbracht werden. Beispiel Ein Beispiel ist der Betrieb eines Webshop bei einem der großen Webhoster. Diese Angebote beinhalten dabei meist auch den Betrieb des -Systems und eventuell auch die Abrechnung. schnell + kompakt 73

74 5 Betrieb 5.1 Ziele des Betriebs Zur Einrichtung, Ausführung und Überwachung gehört dabei vor allem, die korrekte Arbeitsweise der Anwendungen sicherzustellen. Da die IT-Infrastruktur und die entsprechenden Softwarekomponenten in Schichten aufgebaut sind, zu denen neben der Hardware auch ein Betriebssystem, Basiskomponenten, eventuell eine Laufzeitumgebung wie die.net Runtime und die verteilte Anwendung selbst gehören, müssen all diese Schichten überwacht werden. Dazu kommt die Netzwerkinfrastruktur. Es muss sichergestellt werden, dass ein Dienst nicht nur im Rechenzentrum ausgeführt wird, der Dienst muss auch für den Anwender nutzbar sein. Man spricht bei dieser Art der Überwachung auch von End-to-End Monitoring. Die Dienste werden aus dem Netzwerk des Kunden überwacht und somit wird die Sicht des Kunden auf die Anwendung überprüft. Damit lassen sich auch Fehler in der Netzwerkverbindung erkennen. Hinweis Beachten Sie, dass der Betrieb im Gegensatz zur Softwareentwicklung sehr viele verschiedene Anwendungen betrachten muss. Die Aufgaben des Betriebs umfassen aber nicht nur die Bereitstellung der einzelnen Softwarekomponenten. Zum Betrieb der IT-Infrastruktur gehören ebenso Unterstützungsaufgaben, wie die Absicherung der Infrastruktur und der Schutz vor Angriffen von außen und innen, die Durchführung der Datensicherung der Systeme sowie die Verwaltung der Benutzer. ITIL Ebenen und Aufgaben Eines der wichtigsten Frameworks, das die Aufgaben des Betriebs beschreibt und Best Practices vorgibt, ist die IT Infrastructure Library (ITIL). Momentan findet hier der Übergang von Ver- 74

75 Ziele des Betriebs sion 2 zu Version 3 statt, für unsere kurze Einführung verwenden wir ITIL v2. ITIL spricht sehr oft von Services. Services sind Dienste oder Anwendungen, die der Betrieb bzw. die Betriebsabteilung anbietet. Dies sind zum einen die angebotenen Fachanwendungen, aber auch die Unterstützungsprozesse, die dazu notwendig sind. ITIL definiert drei Ebenen für den IT-Betrieb: Strategische Ebene mit den Aufgaben Qualitätsmanagement und IT-Betrieb/Service-Organisation Taktische Ebene zur Planung und Steuerung von IT-Dienstleistungen, auch Service Delivery bezeichnet Operationelle Ebene zur Unterstützung von IT-Dienstleistungen als Service Support Die strategische Ebene beschreibt vor allem, wie der IT-Betrieb organisiert wird. Dazu gehört unter anderem der Aufbau der zuständigen Abteilung. Die taktische Ebene umfasst Aufgaben wie das Service Level und das Capacity Management. Diese leisten neben der Entwicklung von Services im Sinne der (Weiter-)Entwicklung des Dienstangebots des Rechenzentrums auch das IT Continuity Management, das unter anderem die Risikoanalyse übernimmt und entsprechende Lösungen entwickelt. Das erfordert detaillierte Informationen über die zu betreibenden Anwendungen, um den Bedrohungen für die Anwendung und die beteiligten Systeme begegnen zu können. Dazu gehören Informationen über die verwendeten Basiskomponenten, die durch die Software bereitgestellten Schnittstellen nach außen und die Konfigurationsmöglichkeiten. Mit dem Financicial Management, also die Betrachtung der wirtschaftlichen Voraussetzungen der Bereitstellung der Anwendungen und die Optimierung der Kostenstruktur des Betriebs, spielt auch die ökonomische Betrachtung des IT-Betriebs in ITIL eine Rolle, die sich in den anderen Prozessen wiederfindet. Die ope- schnell + kompakt 75

76 5 Betrieb rationelle Ebene ist für das Tagesgeschäft der Bereitstellung von Anwendungen verantwortlich. Gestützt auf Managementwerkzeuge, die wir in Kapitel 3 genauer vorgestellt haben, werden hier die Prozesse Incident Management und Problem Management ausgeführt, die sich mit akut auftretenden Problemen der Infrastruktur beschäftigen. Das Change Management und Release Management sind für die Einführung und die langfristige Pflege der Anwendungen und Infrastrukturkomponenten verantwortlich. Das Configuration Management stellt dabei mit der Configuration Management Database (CMDB) die Datenbasis für alle Prozesse des Service Support zur Verfügung. Die Schnittstellen und Verbindungen zwischen den Prozessen verdeutlicht Abbildung 5.1. Unternehmen, Kunden und Benutzer Management Werkzeuge Störungen Störungen, Anfragen, Rückfragen Kommunikation, Updates, Workarounds Incident Management Störungen Help Desk Problem Management Changes Change Management Releases Release Management Configuration Management Störungen Probleme Bekannte Fehler Änderungen, Cis, Beziehungen Releases CMDB Abb. 5.1: ITIL in schematischer Übersicht 76

77 Ziele des Betriebs ITIL v3 bedeutet unter anderem strukturelle Veränderungen. Die Kerndokumente (Core) beschreiben Best Practices und allgemeine Vorgaben, die sich seltener ändern und die Basis für ITIL beschreiben. Complementary-Guidance-Dokumente bauen auf diesen auf. Sie beschreiben die konkrete Umsetzung und sind damit deutlich näher an den verschiedenen Technologien, den regulatorischen Vorgaben und den eingesetzten Tools orientiert. Damit lassen sich Teile von ITIL einfacher aktualisieren, die Trennung zwischen Core und Complementary vereinfacht neue Versionen von ITIL aufgrund von technologischen und geschäftlich motivierten Veränderungen, die keine Änderungen an den grundlegenden Aussagen erfordern. Aufgaben im Betrieb: Daten und Datensicherung Die einzelnen Aufgaben, die sich rund um den Betrieb ergeben, sind schon für sich aufwändig. Beispiel Eine sinnvolle Backup-Strategie beinhaltet zum Beispiel eine mehrstufige Sicherung auf unterschiedlichen Bändern, meist Bandroboter, die Archivierung der Daten, vor allem auch in Bezug auf rechtliche Vorgaben an die Vorhaltung von Daten, die Sicherstellung der Echtheit und Lesbarkeit der Daten sowie die Planung für den Katastrophenfall wie einen Brand im Rechenzentrum. Wichtig ist dabei nicht nur die Bereitstellung der Daten an sich, sondern auch die Entwicklung einer Wiederherstellungsstrategie für die Wiederaufnahme des Betriebs innerhalb einer vorgegebenen Zeitspanne nach einer Katastrophe. Oft beinhalten entsprechende Planungen redundante Datenhaltung an unterschiedlichen Orten und reichen bis zu gespiegelten Rechenzentren. Dabei muss die Struktur der von der Anwendung abgelegten schnell + kompakt 77

78 5 Betrieb Daten bekannt sein, vor allem, um diese Daten wiederherstellen zu können. Gerade in komplexen IT-Landschaften beziehen sich häufig auch Fremdsysteme auf diese Daten. Auch diese Abhängigkeiten müssen entsprechend dokumentiert sein. Aufgaben im Betrieb: Benutzermanagement Das Benutzermanagement erfordert neben der Bereitstellung der notwendigen Infrastruktur für Passwortmechanismen oder andere Autorisierungsverfahren wie Chipkarten ein vollständiges Lifecycle-Management. Rechte und Rollenstrukturen für Benutzer und Anwendungen müssen definiert, für verschiedene Benutzer eingerichtet und gepflegt werden und abgelaufene Kennungen müssen entsprechend gesperrt werden. Die Rollen sind dabei oft nicht einheitlich für alle Anwendungen geregelt, die in der Infrastruktur ausgeführt werden. Unter Windows steht mit dem Active Directory ein zentrales Benutzermanagement zur Verfügung. Nutzt eine Anwendung diese zentral angebotene Funktion nicht, so müssen die Rollen und Kennungen in der Anwendung selbst gepflegt werden. Bei vielen verschiedenen Systemen stellt dies einen zusätzlichen Aufwand dar. In heterogenen Umgebungen mit verschiedenen Betriebssystemen bedeutet dies zusätzliche Arbeitsschritte, um die entsprechenden Rollen synchron zu halten. Infrastrukturfragen Wir haben im vorigen Kapitel die Softwareentwicklung für eine Anwendung dargestellt. Wichtig ist für den Betrieb, dass so gut wie immer mehr als eine Anwendung betrachtet werden muss, die auf der Infrastruktur ausgeführt wird. Zu dieser gehört neben Servern mit unterschiedlichen Hardwarearchitekturen auch die Netzwerkinfrastruktur mit ihren Komponenten, die sich meist in eine physikalische und eine logische Struktur aufspalten und sowohl als Daten- als auch als Spei- 78

79 Ziele des Betriebs chernetze genutzt werden. Die Einführung von Virtualisierungslösungen sowohl im Bereich der Netze als auch der Serversysteme sorgt dabei für immer komplexere Strukturen und gegenseitige Abhängigkeiten, die oft auf den ersten Blick nicht ersichtlicht sind. Oft schließen sich verschiedene Kombinationen von Anwendungen auf einem Server aus und können nicht gemeinsam ausgeführt werden. Sie benutzen beispielsweise unterschiedliche Versionen derselben Basiskomponente oder kommunizieren über denselben Netzwerkport. Die unterschiedlichen Ebenen und Abhängigkeiten müssen gemeinsam betrachtet und überwacht werden. Fehler einzelner Komponenten beeinflussen üblicherweise immer mehrere, eigentlich logisch getrennte Systeme. Oft werden auch dieselben Leistungen für mehr als einen Kundenkreis erbracht. Ist die Anwendung nicht mandantenfähig, müssen verschiedene Instanzen derselben Anwendung bereitgestellt werden. Bebauungsmanagement und Softwarekartografie Im Bereich des Betriebs etabliert sich in den letzten Jahren eine neue Disziplin, das Bebauungsmanagement. Oft wird hierbei auch von Softwarekartografie gesprochen. Die Hauptaufgabe des Bebauungsmanagements ist die Umsetzung einer einheitlichen und durchgängigen IT-Infrastruktur zur Nutzung gegenseitiger Synergieeffekte und zur Senkung von Kosten vor allem im Bezug auf die Wartung. Bebauungsmanagement hat damit sehr viele Schnittstellen zur Architektur in der Softwareentwicklung. Die Vernetzung dieser beiden Aufgaben stellt dabei eine der von uns propagierten Schnittstellen dar, die bei einem umfassenden Software Lifecycle betrachtet werden müssen. Wir stellen in diesem Kapitel schwerpunktmäßig die verschiedenen Prozesse für den IT-Betrieb in Bezug auf die Bereitstellung von Anwendungen auf der IT-Infrastruktur vor und beginnen bei der Einführung neuer Software auf der IT-Infrastruktur. An- schnell + kompakt 79

80 5 Betrieb schließend beschreiben wir die Prozesse zur Überwachung und Steuerung der Systeme und gehen auf die Prozesse ein, mit denen Softwaresysteme gewartet und gepflegt werden. 5.2 Deployment Der Deployment-Prozess beschreibt die Einführung von Softwarekomponenten auf einer IT-Infrastruktur. Dabei kann im einfachen Fall eine Softwarekomponente auf einem Serversystem installiert werden. Aber auch komplexe Anwendungen mit verschiedenen Softwarekomponenten und gegenseitigen Abhängigkeiten können auf mehreren Servern eingerichtet werden. Dazu müssen zuerst die Anforderungen der Anwendung analysiert und vor dem Deployment auf dem Server überprüft werden. Diese Voraussetzungen können sehr unterschiedlich sein: Einsatz spezieller Basiskomponenten auf dem Serversystem (ODBC-Treiber,.NET-Laufzeitumgebung ) Einsatz spezieller Versionen des Betriebssystems oder der Basiskomponenten (Service Packs, Hotfixes) Spezielle Benutzerkennungen/-rechte für die Anwendungen, in denen diese ausgeführt werden Zugriff auf Basisdienste in der Infrastruktur (Active Directory zur Benutzerauthentifikation, SQL Server zur Datenhaltung) Vor allem bei komplexen Anwendungen können sich hier auch Anforderungen an die Reihenfolge des Deployment ergeben. Beispiel Eine Anforderung kann sein, dass zuerst die Datenbanken der Anwendung eingerichtet werden müssen, bevor darin die Konfigurationsinformationen abgelegt werden können. Erst auf diesen Vorleistungen aufbauend können die Softwarekomponenten auf den verschiedenen Servern eingerichtet werden. 80

81 Deployment Der Deployment-Prozess muss diese Schritte entsprechend beschreiben. Dabei werden die Softwarekomponenten auf die verschiedenen Systeme kopiert, konfiguriert und anschließend ausgeführt. Das Setup Dazu müssen die Entwickler entsprechende Setup-Programme bereitstellen. Wichtig ist dabei, auch auf unterschiedliche Konfigurationen beim Kunden einzugehen. Das Setup muss von einem konsistenten Zustand des Systems in einen anderen konsistenten Zustand führen und sollte sich rückgängig machen lassen, wenn dabei ein Fehler auftritt oder die Anwendung zwar technisch fehlerfrei arbeitet, aber fachliche Fehler beinhaltet. Techniken, wie sie beispielsweise mit dem Windows Installer bereitgestellt werden, sind hier sehr brauchbar. Hinweis Die Erstellung eines Setup für die Einführung einer Software ist relativ einfach, da der Entwickler nur alle Komponenten, die die Anwendung benötigt, auf das Zielsystem bringen muss. Schwieriger ist ein Update oder ein Patch eines bestehenden Systems. Diese Problematik verschärft sich, wenn die Anwendung sehr stark konfigurierbar ist und so viele Varianten bei den Kunden im Einsatz sind. Diese Problematik sollte schon bei der Entwicklung der ersten Version einer Anwendung beachtet werden, ist aber unumgänglich bei allen weiteren Versionen. Die Anforderungen einer Anwendung an die Infrastruktur gelten dabei sowohl für die Produktivumgebung als auch für das Testsystem. Diese Informationen müssen vom Entwickler zur Verfügung gestellt werden. Die Erstellung eines Setup ist hier schnell + kompakt 81

82 5 Betrieb häufig nicht ausreichend, wenn dieses sich nicht in die Deployment-Werkzeuge integrieren lässt. Staging- und Integrationssysteme Die Anwendung müssen Sie nach einem erfolgreichen Integrationstest auf das Produktivsystem überführen. Dieser Vorgang wird oft auch als Staging bezeichnet. Das Testsystem sollte die Produktivumgebung so weit wie möglich nachbilden. Trotzdem werden meist Unterschiede zwischen den beiden Systemen existieren, wie unterschiedliche Netzwerkverbindungen oder unterschiedliche Hardwareplattformen. Je komplexer die Anwendung und die beteiligten IT-Systeme, desto schwieriger ist die Schaffung einer realistischen Testumgebung. Für Webanwendungen bieten Produkte wie der Microsoft Application Center 2000 entsprechende Lösungen. Neben der Verwaltung von Webfarms kann der AC 2000 auch ein Staging von Anwendungen von einem Server auf einen zweiten durchführen. Dazu werden die Anwendungen mit ihren Komponenten als eine Anwendung innerhalb der Managementapplikation definiert. Durch einen Prozess innerhalb des Werkzeugs werden anschließend automatisch die Einstellungen und Dateien der Anwendung von einem Server auf einen anderen transferiert und die Anwendung wird so in die Produktivumgebung übernommen. Je komplexer die Anwendungen sind, desto schwieriger wird jedoch genau dieser Schritt. Für eine Exchange-Infrastruktur ist dieser Weg nicht mehr umsetzbar. Deswegen ist es in diesem Fall wichtig, die genaue Wirkung der Einführung neuer Komponenten oder von Veränderungen zu kennen, bevor diese Veränderungen umgesetzt werden. 82

83 Deployment Verteilung und Verfügbarkeiten Eventuell müssen Datenbankschemata beim Deployment geändert werden oder die Anwendung steht für eine gewisse Zeit nicht zur Verfügung. Dann muss diese Downtime entsprechend eingeplant werden. Kritisch ist in diesem Fall auch, dass es meist schwierig ist, wieder in den Ausgangspunkt zurückzukommen, falls eine Installation fehlschlägt, da auch die Schemaänderungen wieder rückgängig gemacht werden müssen. Softwareentwickler neigen hier häufig zu dem pragmatischen Ansatz, noch nicht einmal eine Meldung anzuzeigen, wenn Dienste während eines Setup oder eines Update angehalten werden. Auch ein Neustart des Rechners, um sicherzugehen, dass alle Dienste neu gestartet werden Boot tut gut, ist im Sinne des Continuity Management eines Dienstes ein extrem kritisches Verhalten. Wichtig ist bei solchen Änderungen, dass Veränderungsprozesse möglichst automatisch durchgeführt werden können. Dies sorgt dafür, dass notwendige Schritte auf mehreren Servern automatisch erfolgen können. Damit lassen sich diese Änderungen aber auch einfach wiederholen, falls Komponenten durch einen Fehler überschrieben werden. Gerade wenn die Anforderungen an die Infrastruktur wachsen und durch ein Scale-out, also die Verteilung der Last auf mehrere Server, die Leistungsfähigkeit der Anwendung gesteigert werden soll, kann die Einrichtung des zusätzlichen Systems automatisch erfolgen. Dies trägt vor allem auch zu einer Standardisierung der verschiedenen Installationen bei, was diese deutlich einfacher wartbar macht. Neben der Installation der Softwarekomponenten ist dabei auch die Überprüfung der Installation notwendig, ob alle Komponenten korrekt eingerichtet wurden und die Anwendung funktionsfähig ist. Dieser Schritt schafft gleichzeitig auch die Basis für den Betrieb und die Überwachung. In die Überwachungswerkzeuge schnell + kompakt 83

84 5 Betrieb müssen dabei die Systeme und Komponenten eingetragen werden, aus denen die Anwendung besteht. Eine Möglichkeit der Überprüfung der Anwendung ist die Nutzung der Integrationstests und die Überprüfung des Systems durch die Pilotnutzer. Diese haben meist schon ein tiefer gehendes Verständnis für die Applikation. Hinweis Ein Test durch den Benutzer darf auf keinen Fall automatisierte Tests ersetzen! Gerade beim Einspielen von Patches oder kleineren Veränderungen ist es wichtig, automatisierte Tests zur Überprüfung einer Anwendung einsetzen zu können. Dies stellt zum einen sicher, dass keine Tests vergessen werden und verringert zum anderen den dafür notwendigen Aufwand. 5.3 Betrieb Es ist ebenso erforderlich, dass Sie für den Betrieb ein Abbild der vorhandenen Infrastruktur haben, in ITIL realisiert die CMDB diese Datenbasis. Alle Komponenten müssen dazu entsprechend inventarisiert sein. Wichtig ist aber nicht nur die Inventarisierung aller vorhandenen physikalischen Komponenten im Sinne einer betriebswirtschaftlichen Inventarisierung, sondern auch die Schaffung eines Modells der gesamten Infrastruktur und ihrer logischen Strukturen. Dazu gehört die Beschreibung der eingesetzten Softwarekomponenten mitsamt ihrer Beziehungen. Die Inventardaten für den IT-Betrieb sind deshalb deutlich detaillierter. Das Inventar wird meist durch Werkzeuge automatisch erstellt und bildet auch die Basis für den Deployment-Prozess. Dies gilt auch für die Informationen über die Software, die in der IT-Infrastruktur eingesetzt wird. Die dafür eingesetzten Tools werden als 84

85 Betrieb Topology oder Application Scanner bezeichnet. Diese Werkzeuge kennen die Struktur der unterschiedlichen Anwendungen und analysieren deren Konfiguration und Verteilung auf zu erfassenden Rechnern. Die benötigten Informationen müssen von der Softwareentwicklung zur Verfügung gestellt und in die entsprechenden Werkzeuge integriert werden. Damit lässt sich einerseits die Überwachung der eingesetzten Lizenzen realisieren, andererseits ist damit aber auch die Darstellung der Softwareverteilung und der verschiedenen Konfigurationen in der IT-Infrastruktur möglich. Werden die Tools nach Veränderungen nochmals ausgeführt, lässt sich das Inventar aktualisieren und die Auswirkungen der Änderungen werden dokumentiert. Dadurch werden Change-Requests in der Infrastruktur abgeschlossen. Überwachung Die eingesetzten Werkzeuge haben jeweils unterschiedliche Aufgaben und benötigen deshalb auch unterschiedliche Informationen. Inventarisierungstools beschreiben die Hardware und ihre Eigenschaften sowie ihre logische Struktur. Monitoring-Systeme beschreiben die ausgeführten Dienste und deren Eigenschaften wie die Auslastung der Serversysteme, die Reaktionszeit und die Verfügbarkeit der ausgeführten Dienste, die in der Infrastruktur aufgetretenen Ereignisse. Dazu werden verschiedene Informationsquellen verwendet: Logbücher speichern die Informationen über Ereignisse, die in der Infrastruktur aufgetreten sind. Diese können entsprechend ausgewertet werden. Aktive Tests überwachen das Verhalten von Anwendungen auf einem Server. Dazu gehören lokale Tests, also auch Tests aus der Sicht des Kunden einer Anwendung. Mittlerweile rücken die CMDBs in den Vordergrund, die zum einen die Inventardaten beinhalten, zum anderen aber auch Monitoring-Daten speichern. Dies ist vor allem wichtig, um schnell + kompakt 85

86 5 Betrieb Veränderungen über die Zeit zu dokumentieren. Neben der Abrechung von Diensten ist dies auch ein wichtiges Mittel bei der Planung von Erweiterungen der IT-Infrastruktur oder auf der Suche von Fehlern, um nachträglich aufgetretene Ereignisse analysieren zu können. 5.4 Wartung & Pflege Neben den geplanten Prozessen des Deployment treten beim Betrieb auch immer wieder unvorhergesehene Ereignisse auf. Systeme fallen aus, Fehler in Softwarekomponenten führen zu erhöhtem Speicherbedarf, Abstürze von Anwendungen und Basiskomponenten erfordern Neustarts von Servern. Über Planbarkeit Diese Prozesse sind im ITIL Incident Management und Problem Management beschrieben und müssen häufig sehr kurzfristig durchgeführt werden. Sie entziehen sich deshalb meist einer zentralen Planung. Beispiel (Sicherheits-)Updates für Betriebssysteme und Basiskomponenten stellen Änderungen im Laufe der Zeit an den Anwendungen dar. Hier müssen Risiken abgeschätzt werden, ob und wie zugrunde liegende Sicherheitslücken ausgenutzt werden. Gleichzeitig müssen aber auch die Auswirkungen der Installation des Update auf die existierende Infrastruktur analysiert werden, um den korrekten Betrieb der installierten Anwendungen sicherzustellen. Hier ergeben sich teilweise Zielkonflikte, die je nach Schwere des Sicherheitsproblems abgewogen werden müssen. Die Installation dieser Patche sollte sich dabei möglichst an den Prozessen 86

87 Wartung & Pflege zum Deployment, also des Release Managements orientieren, um einen möglichst einheitlichen Softwareverteilungsprozess etablieren zu können. Darüber hinaus müssen Sie hier entsprechende Kompatibilitätsprüfungen vorsehen. Aus Veränderungen heraus ergeben sich auch Anforderungen zur Änderung an die Softwaresysteme, die in der IT-Infrastruktur ausgeführt werden. Ein Beispiel sind umfangreichere Service Packs, die Konfigurationsänderungen erfordern oder aus Sicherheitsgründen spezielle Funktionen des Betriebssystems nicht mehr erlauben. Anwendungen müssen in diesem Fall angepasst werden, um unter den neuen Bedingungen ausgeführt werden zu können. Änderungswünsche Eine andere Quelle für Änderungsanforderungen sind Änderungswünsche von Benutzern. Der IT-Betrieb sollte mit einem Helpdesk oder einem Service Desk eine Schnittstelle zur Verfügung stellen, die die Sicht des IT-Betriebs hin zum Kunden realisiert. Der Helpdesk erhält aber nicht nur Anfragen der Benutzer in Bezug auf die Ausführung des Dienstes (Wiederherstellen von Daten aus dem Backup/Anlegen von Benutzerkennungen). Diese Anfragen sollten Sie in einem Ticket-Managementsystem erfassen und verwalten. Damit ist nicht nur eine Zuordnung von Anfragen und Änderungen an einen Benutzer möglich, die Informationen können auch zur Abrechnung verwendet werden. schnell + kompakt 87

88

89 KAPITEL 6 Ganzheitlicher Life Cycle 6.1 Projektmanagement Weitere Managementdisziplinen Ganzheitlicher Life Cycle 101 Nachdem wir in den letzten Kapiteln einige Einzelaspekte auszugsweise beleuchtet haben, widmen wir uns nun dem gesamten Life Cycle und schlagen eine Brücke zwischen Entwicklung (Kapitel 4) und Betrieb (Kapitel 5) einer Software. Um beide Welten miteinander zu verbinden, ist es erforderlich, eine Art Schnittstelle zu definieren. In Abbildung 6.1 haben wir das einmal skizziert. Anforderungsfeststellung Implementierung Test Überwachung Anforderungen zur Adaption Schnittstelle zwischen Entwicklung und Betrieb Entwurf Abb. 6.1: Konzept integrierter Prozesse Übernahme der Software Installation und Betrieb schnell + kompakt 89