Software Lifecycle. Management und Entwicklung GERMAN

Software Life Cycle

Marco Kuhrmann Norbert Diernhofer

Software Life Cycle Management und Entwicklung

schnell + kompakt

Marco Kuhrmann, Norbert Diernhofer Software Life Cycle schnell + kompakt Frankfurt, 2007 ISBN 978-3-939084-38-9

© 2007 entwickler.press, ein Imprint der Software & Support Verlag GmbH

http://www.entwickler-press.de http://www.software-support.biz Ihr Kontakt zum Verlag und Lektorat: [email protected] Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de 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.

Inhaltsverzeichnis Vorwort

7

Kapitel 1: Der allgemeine SLC 1.1 Phasen im Software Life Cycle 1.2 Vorgehensmodelle und Werkzeuge 1.3 Die Schnittstelle zum Betrieb Betrieb Evolution im Betrieb von Software 1.4 Einheitliches Management

9 11 14 15 15 17 19

Kapitel 2: Vorgehensmodelle 2.1 Vorgehensmodelle: Entwicklung Der Rational Unified Process Das V-Modell XT Agile Methoden 2.2 Vorgehensmodelle: Betrieb CobiT ITIL Microsoft Operations Framework 2.3 MSF 4.0 und MOF

21 23 23 25 28 29 30 30 32 33

Kapitel 3: Werkzeuge 3.1 Werkzeuge für den Entwurf Entwicklung – Visual Studio 2005 Datenhaltung – Visual SourceSafe Testen – Unit-Testing Management – Team Foundation Server Projektverwaltung – Microsoft Project

35 35 35 37 38 40 41

schnell + kompakt

5

Inhaltsverzeichnis

3.2 Werkzeuge des IT-Betriebs Verteilung – SMS Überwachung/Steuerung – MOM Helpdesk – Ticket Tracker CMDB – ITIL Inventar Application Scanner Verschränkung Entwicklung & Betrieb

42 43 44 45 46 47 47

Kapitel 4: Systementwicklung 4.1 Anforderungsfestlegung 4.2 Entwurf 4.3 Entwicklung 4.4 Test

49 50 55 58 66

Kapitel 5: Betrieb 5.1 Ziele des Betriebs 5.2 Deployment 5.3 Betrieb 5.4 Wartung & Pflege

73 74 80 84 86

Kapitel 6: Ganzheitlicher Life Cycle 6.1 Projektmanagement Projektmanagement im Großen Projektmanagement im Kleinen Aufgabenmanagement 6.2 Weitere Managementdisziplinen Qualitätsmanagement Problem- und Änderungsmanagement Konfigurationsmanagement 6.3 Ganzheitlicher Life Cycle

89 93 93 94 94 96 96 97 100 101

Stichwortverzeichnis

105

6

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

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

KAPITEL 1 Der allgemeine SLC 1.1

Phasen im Software Life Cycle

11

1.2

Vorgehensmodelle und Werkzeuge

14

1.3

Die Schnittstelle zum Betrieb

15

1.4

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

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

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

1 – Der allgemeine SLC

Anforderungsfeststellung

Entwurf/Design

Implementierung

klassisch

- Anforderungen - Entwurf - Implementierung - Test

Test

Betrieb

real

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

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

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

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

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

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

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 Ereignisse1 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

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

KAPITEL 2 Vorgehensmodelle 2.1

Vorgehensmodelle: Entwicklung

23

2.2

Vorgehensmodelle: Betrieb

29

2.3

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

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):

Wer?

Aktivitätsmodell

Wie?

Artefakt-/Produktmodell

Was?

Wann?

Rollenmodell

Prozess

Womit?

(Quasi)-Standards, Methoden und Werkzeuge

Abb. 2.1: Vorgehensmodell als strukturierte Sammlung verschiedener Disziplinen des Software Engineering

22

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

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

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 XT1 ist ähnlich dem RUP ein komplexes, breit anwendbares und hoch integriertes formales Vorgehensmodell. Das V-Modell ist weiterhin der IT-Entwicklungsstandard für ITProjekte 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: http://www.v-modell-xt.de

schnell + kompakt

25

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

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

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

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

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 SarbanesOxley 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 ITGoverance-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: http://www.legalarchiver.org/soa.htm

30

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

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:

C ha ng g in

O pt im iz in g

쐌 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

pe r O

g tin

or

at

in g

pp Su

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

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

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

KAPITEL 3 Werkzeuge 3.1

Werkzeuge für den Entwurf

35

3.2

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

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

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-Systems1 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 Repository2. 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, funktionieren1. 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

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 NUnit3 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: http://www.nunit.org

38

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

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

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

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

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

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

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

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

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

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

KAPITEL 4 Systementwicklung 4.1

Anforderungsfestlegung

50

4.2

Entwurf

55

4.3

Entwicklung

58

4.4

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 Wasserfallmodell1 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”, 1970.

schnell + kompakt

49

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

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

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

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

4 – Systementwicklung

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

54

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

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

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 UserService 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

Code AF

AF AF

Code

Code Code Code

Abb. 4.5: Entstehungsweg von Code aus Anforderungen und Spezifikationen

schnell + kompakt

57

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-Level2 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) http://www.sei.cmu.edu/cmmi/

58

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

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 ProjektSet-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

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, Klassenmodelle3 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

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

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

4 – Systementwicklung

Lastenheft/ Ausschreibung

Spezifikation

Implementierung

AF

Code Code

AF

AF AF

Änderung schlagen durch

Änderung durch Kunden

AF’ neuer 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-XMLDokumentation, 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

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

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

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

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 Randbereichen4 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

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

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

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

KAPITEL 5 Betrieb 5.1

Ziele des Betriebs

74

5.2

Deployment

80

5.3

Betrieb

84

5.4

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 E-Mail-Systems und eventuell auch die Abrechnung.

schnell + kompakt

73

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

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

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, Anfragen, Rückfragen

Störungen

Incident Management

Störungen

Kommunikation, Updates, Workarounds

Help Desk

Problem Management

Changes Change Management

Releases Release Management Configuration Management

Störungen

Probleme Bekannte Fehler

Änderungen, Cis, Beziehungen

CMDB

Abb. 5.1: ITIL in schematischer Übersicht

76

Releases

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

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

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

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

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

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

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

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

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

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

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

KAPITEL 6 Ganzheitlicher Life Cycle 6.1

Projektmanagement

93

6.2

Weitere Managementdisziplinen

96

6.3

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. Implementierung

Überwachung Test Anforderungen zur Adaption

Schnittstelle zwischen Entwicklung und Betrieb

Entwurf

Übernahme der Software Anforderungsfeststellung

Installation und Betrieb

Abb. 6.1: Konzept integrierter Prozesse

schnell + kompakt

89

6 – Ganzheitlicher Life Cycle

Wir betrachten beide großen Teilprozesse des SLC. Wie Sie sehen, gibt es zwischen ihnen Berührungspunkte, in denen Informationen oder Produkte ausgetauscht werden. In Abbildung 6.2 haben wir das noch einmal hervorgehoben. Als besonders wichtig betrachten wir die Abschnitte der Anforderungsfeststellung (Entwicklungsprojekt) und der Softwareübernahme (Betrieb) sowie Änderungsanforderungen (Betrieb). In diesen Abschnitten der jeweiligen Projekte sind Anforderungen Gegenstand der Arbeit. Im Entwicklungsprojekt dienen Anforderungen der Fähigkeitsermittlung und sind Grundlage der Implementierung einer Software. Anforderungen müssen jedoch nicht zwangsweise auf expliziten Kundenwunsch entstehen, sondern können auch Konsequenz aus den Betriebsprozessen sein. Stellen sich beispielsweise Probleme im Betrieb einer Software heraus, werden üblicherweise Problemmeldungen erzeugt. Diese können entweder operativ gelöst werden oder bedürfen einer Anpassung der Software im Kontext einer Folgeentwicklung. Probleme werden somit zu Anforderungen von (neuen) Entwicklungsprojekten. Implementierung

Überwachung Test Anforderungen zur Adaption

Schnittstelle zwischen Entwicklung und Betrieb

Entwurf

Übernahme der Software Anforderungsfeststellung

Abb. 6.2: Schnittstelle integrierter Prozesse

90

Installation und Betrieb

Ganzheitlicher Life Cycle

Es ist ziemlich schlüssig, dass die Anforderungen das Kommunikationsmittel in und zwischen Projekten sind. Wir müssen uns an dieser Stelle dann damit beschäftigen, wie die Anforderungen zwischen einzelnen Projekt- oder Organisationsteilen ihren Weg finden. Dazu sehen wir uns im Folgenden zwei Integrationskonzepte an. Integration auf der organisatorischen Ebene Die Integration auf der organisatorischen Ebene setzt vor allem eine Integration der verschiedenen Teams voraus. So sollte der Betrieb möglichst früh in die Produktplanung mit einbezogen werden. Nur so kann ein langfristiges Bebauungsmanagement für die Infrastruktur etabliert werden. Der Betrieb kann so auch schneller auf Anforderungen, die sich aus einem Softwareentwicklungsprojekt ergeben, reagieren und die notwendigen Maßnahmen in der Infrastruktur umsetzen. Er trägt darüber hinaus zu einer Standardisierung der Entwicklung bei, da der Betrieb das Bindeglied zwischen verschiedenen Softwareentwicklungsprojekten darstellen kann. Da alle Projekte auf der Infrastruktur umgesetzt werden, müssen auch alle mit dem Betrieb reden. Integration auf Basis der Tools Eine Integration auf Basis der eingesetzten Tools stellt sicher, dass Medienbrüche vermieden und Datenverluste verhindert werden. Insbesondere die Einheitlichkeit der Werkzeuglandschaft kann sich positiv sowohl für Betrieb als auch für die Anwender und Entwickler auswirken. Anwender finden sich überall zurecht und der Betrieb findet eine homogene, integrierte Umgebung. Für Entwickler hat eine integrierte, definierte Werkzeuglandschaft den Vorteil, dass sie Annahmen über Rahmenbedingungen und Fähigkeiten machen können. Wie in Kapitel 3 bereits beschrieben, kann das Microsoft DSI-Modellformat eine Schnittstelle darstellen, die mit Visual Studio 2005 und Systems

schnell + kompakt

91

6 – Ganzheitlicher Life Cycle

Center Configuration Manager 2007 einen Übergang der Daten von der Entwicklung in den Betrieb ermöglicht. Integration und Management Darüber hinaus entsteht aus der Integration von Organisationseinheiten und Werkzeugen eine vollständige Dokumentation der Unternehmensstruktur, in der Veränderungen nachverfolgt werden können. Dieses Bild mag zurzeit idealisiert sein – ist aber dennoch ein lohnenswertes Ziel. Hinweis Dieser Ansatz geht über die Ansätze des Bebauungsmanagements hinaus und integriert auch den Softwareentwicklungsprozess nicht nur auf Basis seiner Ergebnisse, sondern seiner Einzelschritte. Unabhängig davon, welche Art der Integration erfolgen soll, das Management muss immer mit eingebunden werden. Von daher sehen wir den gangbarsten Weg dort, wo im Management konsolidierende Entscheidungen getroffen werden können. Konkret sehen wir die klassischen Disziplinen als Ausgangspunkt: 쐌 쐌 쐌 쐌

Projektmanagement Qualitätsmanagement Problem- und Änderungsmanagement Konfigurationsmanagement

Diese vier Kerndisziplinen des Managements greifen unabhängig von der Art des Projekts und gelten somit sowohl für Entwicklungs- als auch Pflegeprojekte sowie den Betrieb. In allen diesen vier Disziplinen entstehen Produkte, die Input für verschiedene Prozesse sein können.

92

Projektmanagement

Hinweis Diese vier Kerndisziplinen werden üblicherweise von allen Vorgehensmodellen (egal ob Betrieb oder Entwicklung) in der einen oder anderen Form adressiert. Das V-Modell XT beispielsweise räumt ihnen dabei eine so zentrale Rolle ein, dass es sie im sogenannten V-Modell Kern zusammenfasst und für alle Projekte verbindlich zur Umsetzung vorschreibt. Wir wollen nicht noch einmal definieren, was sich hinter den einzelnen Managementdisziplinen verbirgt. Vielmehr wollen wir im Folgenden auf einige Aspekte eingehen, die einzelnen Projekten die Tür in eine übergreifende Organisationsform öffnen.

6.1 Projektmanagement Die Systementwicklung (Kapitel 4) ist üblicherweise ein komplexes Projekt, sodass ein entsprechendes Projektmanagement erforderlich ist. Das Projektmanagement umfasst dabei vor allem die Planung und Steuerung des Projekts. Unter Berücksichtigung der Einbettung in einen größeren Kontext kann der Fokus aber nicht allein auf ein Projekt beschränkt bleiben. Deshalb unterscheiden wir hier zwei Arten von Projektmanagement, die unterschiedliche Ebenen adressieren.

Projektmanagement im Großen Das Projektmanagement im Großen umfasst die Leitung eines Gesamtprojekts, die Aufstellung des oder der Teams, die Planung der einzelnen Abschnitte und die Festlegung der Vorgaben für das Projekt wie die Gesamtlaufzeit und die Meilensteine. Die Planung erfolgt dabei durch einen Projektleiter in Abstimmung mit dem Kunden.

schnell + kompakt

93

6 – Ganzheitlicher Life Cycle

Eine Aufgabe, die ebenfalls Teil des Managements im Großen ist, ist die Planung des Einsatzes der Mitarbeiter, die oft auch in anderen Projekten arbeiten, die Planung des finanziellen Einsatzes und die Planung, welche Mitarbeiter entsprechend eingesetzt werden. Unterstützende Werkzeuge für diese Schritte sind Tools wie Microsoft Project. Frameworks wie das V-Modell, MSF oder MOF geben mit Rollen und Aufgaben einen Rahmen vor.

Projektmanagement im Kleinen Neben der Planung des Gesamtprojekts müssen aber auch die Einzelschritte geplant werden. Wir sprechen hier von Planung im Kleinen. Dazu gehört unter anderem die Planung der Aufgaben (Aufgabenmanagement) für die verschiedenen Beteiligten. Ein Beispiel wäre, welche Systemkomponenten bis wann fertig entwickelt sein müssen, wann teilintegrierte Tests stattfinden und welcher Entwickler welche Änderungen bearbeitet. Diese Planung erfolgt, wenn mehrere Teams vorhanden sind, durch den jeweiligen Teamleiter und hilft den Mitgliedern, ihre tägliche Arbeit zu strukturieren und zu dokumentieren. Tools für das Projektmanagement im Kleinen sind Sharepoint und die Funktionen des Visual Studio Team Foundation Server. Wichtig und nicht zu vernachlässigen ist die Integration in die Managementtools auf der Gesamtprojektebene. Die Aufgaben ergeben sich aus den Rollenbeschreibungen und der Umsetzung der konkreten Projektschritte auf die Rolle.

Aufgabenmanagement Unabhängig, ob im Kontext einzelner Projektteile, des Gesamtprojekts oder in einer Betriebsorganisation; Aufgabenmanagement ist eine der Kerndisziplinen. Sie ist dem Projektmanagement untergeordnet, stellt jedoch das Bindeglied zwischen

94

Projektmanagement

Anforderungen, Risiken, Problemen oder Änderungsanträgen dar. In Kapitel 4 haben sind wir bereits auf die wichtige Rolle des Aufgabenmanagements im Kontext seiner Einbindung in das Visual Studio (Abbildung 4.6) eingegangen. Dort war auch zu sehen, dass Aufgaben das gesamte Spektrum der Projektaktivitäten abdecken können. Wichtig für das Aufgabenmanagement im Kontext eines einheitlichen, integrierten Software Life Cycle ist, dass die Möglichkeit geschaffen werden muss, Projektgrenzen zu überschreiten. Aufgaben müssen auch über die Projektgrenze (Abbildung 6.3) hinaus erstellt und zugewiesen werden können. Beispiel Denken Sie beispielsweise an eine Software, die sich im Einsatz befindet. Tritt ein Fehlverhalten auf, das reproduzierbar auf ein Softwareproblem zurückzuführen ist, muss eine entsprechende Problem-/Änderungsmeldung in die Entwicklungsabteilung geleitet werden. Diese erzeugt dann mehrere Aufgaben in einem Entwicklungsprojekt. Die Abhängigkeit zwischen dem Fehler in der produktiven Laufzeitumgebung und den Aufgaben zur Behebung des Bugs in der Entwicklung muss dabei dokumentiert und erhalten werden. Es ist also wichtig, die Wirkungen einzelner Aktionen auch über den Projektkontext hinaus zu betrachten. In der Abbildung 6.3 können Sie sehen, dass aus einer „einfachen“ Problemmeldung ganz schnell viele Arbeitsaufträge entstehen können. Hier sind also auf einmal viele Personen beteiligt, die informiert und koordiniert werden wollen. Insbesondere in Projekten, die in einem globalen Umfeld stattfinden, ist das Aufgabenmanagement eine Herausforderung, da hier nicht nur viele Personen mit einzubeziehen sind, sondern auch noch das Zeitzonenproblem zu beachten ist. Insbesondere wenn zum Beispiel Service Level Agreements (SLA) zu erfüllen sind, kann hier eine kritische Größe im Projekt entstehen.

schnell + kompakt

95

6 – Ganzheitlicher Life Cycle

Lastenheft/ Ausschreibung

Spezifikation

Arbeitsauftrag: Fehler lokalisieren Konzept

Problemmeldung

Arbeitsauftrag: Lösung entwickeln

Änderungsforderung

Arbeitsauftrag: Lösung umsetzen

Code

Implementierung Arbeitsauftrag: Lösung testen Code Arbeitsauftrag: Patch packetieren Arbeitsauftrag: Software verteilen

Release/Patch

Lösung

Abb. 6.3: Erzeugung von Arbeitsaufträgen

6.2 Weitere Managementdisziplinen Die weiteren Managementdisziplinen wollen wir nur kurz anreißen und sie im Kontext eines einheitlichen SLC betrachten.

Qualitätsmanagement Qualitätsmanagement steuert die Organisationspolitik hinsichtlich einheitlicher, verbindlich umzusetzender Qualitätsnormen und Richtlinien auf projektübergreifender Ebene. Das Qualitätsmanagement gibt somit die Rahmenbedingungen für die Qualitätssicherung in einzelnen Projekten wie auch im Betrieb einzelner Anwendungen vor. Hinweis Unterscheiden Sie immer zwischen Qualitätsmanagement und Qualitätssicherung. Es ist oftmals verführerisch, diese beiden Begriffe miteinander zu vermengen.

96

Weitere Managementdisziplinen

Als Orientierung für das Qualitätsmanagement dienen in der Regel Reifegradmodelle wie CMMI oder SPICE, die die Güte eines Prozesses bewerten. Ebenfalls sehr populär in diesem Bereich sind Zertifizierungen gemäß ISO, zum Beispiel die ISO 9000. Diese sind sowohl auf einzelne Projekte als auch auf den Betrieb anwendbar. Wichtig im Kontext eines einheitlichen SLC ist es, dass alle beteiligten Parteien sich immer darüber im Klaren sind, nach welchen Spielregeln gespielt wird. Um beispielsweise einen hohen CMMI-Level zu erreichen, müssen in Entwicklungsprojekten zuweilen aufwändig anmutende Prozeduren durchgeführt werden. Beteiligte Partner auf der Seite des Betriebs müssen hierfür sensibilisiert werden und können bei der Umsetzung eines einheitlichen Konzepts mit eingebunden werden.

Problem- und Änderungsmanagement Problem- und Änderungsmanagement ist die Managementdisziplin, die zwangsläufig alle Beteiligten zur Zusammenarbeit zwingt. Hier entstehen Aufgaben quer über viele Projekte und Organisationseinheiten hinweg (siehe auch Abbildung 6.3). Umso wichtiger ist es, dass hier ein organisationsweit einheitlicher, formaler Änderungsprozess etabliert ist. Die Formalisierung eines solchen Prozesses halten wir an dieser Stelle für zwingend erforderlich, da ein großer Teil der aktuellen Probleme mit Software aufgrund pragmatischer Lösungen entstehen. Hinweis Bei der Beratung einiger Organisationen konnten wir Einblick in verschiedene Änderungsverfahren nehmen. Es hat sich dabei bestätigt, dass der auf dem Flur zugerufene Änderungswunsch der erste Schritt in Richtung Wildwuchs und Instabilität ist.

schnell + kompakt

97

6 – Ganzheitlicher Life Cycle

Die Vorteile eines organisationsweit festgelegten Änderungsprozesses liegen auf der Hand: 쐌 Es sind Beteiligte und Verantwortliche klar festgelegt. 쐌 Probleme und Änderungswünsche sowie Änderungsforderungen sind respektierte Größen im Tagesgeschäft und finden ihren Platz in Projekt-, Zeit- und Ressourcenplänen. Hinweis Durch die Integration in die Managementwelten des Betriebs und der Entwicklung ist hier auch die Erstellung eines Patch für die Entwickler wie in Kapitel 5 beschrieben, deutlich einfacher möglich, da alle Informationen über die eingesetzten Versionen und Konfigurationen bekannt sind. In der folgenden Abbildung 6.4 haben wir Ihnen beispielhaft einen Prozess skizziert, wie er unter anderem auch im V-Modell XTEntwicklungsprojekt eingesetzt wird.1 Ausgehend eines (beliebigen) Auslösers werden Probleme oder Änderungsforderungen in den Änderungsprozess eingebracht. Dort wird zunächst in einem Pflegeprozess, der am besten zentralisiert sein sollte, eine Meldung/ein Antrag erstellt. Die Meldung wird im Kontext aller anderen positioniert (zum Beispiel Referenzen auf ähnliche Probleme) und gepflegt (Statuskontrolle). Über sämtliche Aufgaben wird in der einen oder anderen Form beschieden, sodass hier auch Bewertungsprozesse vorzusehen sind.

1. Der Änderungsprozess des V-Modell XT wird komplett in der Software Mantis (http://www.mantisbt.org/) abgebildet. Der Prozess deckt dabei sowohl Möglichkeiten für das Stellen von Feature Request als auch klassisch das Problem- und Änderungsmanagement ab.

98

Weitere Managementdisziplinen

Arbeitsauftrag: Problemmeldung/ Änderungsforderung erstellen

Auslöser eines Problems/einer Änderungsforderung

Änderungen plegen

Arbeitsauftrag: Änderungsstatusliste führen/pflegen Arbeitsauftrag: Problemmeldung/ Änderungsforderung bewerten

Änderung einplanen/ umsetzen

Vorgehen entscheiden

Verwerfen/ablehnen Zurückstellen (neues Projekt etc.)

Abb. 6.4: Beispiel eines Änderungsprozesses

Eine Änderungsentscheidung führt zu einem weiteren Vorgehen mit den Problemen oder Änderungen. Beispielsweise ist es möglich, Änderungen unmittelbar in den Projektplan zu integrieren oder Anträge abzulehnen. Die Menge der möglichen Entscheidungspfade sollte jedoch organisationsweit definiert sein. Der Änderungsprozess geht mit dem Aufgabenmanagement (siehe Abbildung 6.3) Hand in Hand. Er sollte deshalb mit ebensolcher Sorgfalt betrachtet und definiert werden. Alle Beteiligten sollten angemessen in das Problem- und Änderungsmanagement eingebunden werden. Insbesondere für die Entscheidungsfindung sollte ein Verfahren definiert werden, in dem sowohl Anwender, Entwickler und Betrieb mit eingebunden sind.

schnell + kompakt

99

6 – Ganzheitlicher Life Cycle

Konfigurationsmanagement Abschließend wollen wir noch kurz auf das Konfigurationsmanagement eingehen. Dieses dient dazu, einerseits Projektkonfigurationen, Produkte (Deliverables), aber auch die Infrastrukturen zu erfassen und angemessen zu verwalten. Konfigurationsmanagement positionieren wir ebenfalls in der Schnittstelle zwischen Entwicklung und Betrieb (Abbildung 6.2). Als besonders geeignetes Mittel zur Kommunikation sehen wir hier einen Release-Plan, wie er durch das Microsoft Solutions Framework definiert wird. Durch ihn wird ersichtlich, zu welchen Zeitpunkten welche Konfigurationen eines Produkts mit welchen Versionen von Dokumentation etc. erstellt und verteilt werden. Dies sind essentielle Informationen für den Betrieb, der beispielsweise aus diesen Informationen Verteilungspakete für die Testoder später auch die Produktivumgebung erzeugen kann. Profitipp Sehen Sie sich hierzu einmal die Produktvorlagen „Anforderungen (Lastenheft)“ und „Gesamtsystemspezifikation (Pflichtenheft)“ des V-Modells an. Diese beinhalten Kapitel und Hinweise, wie eine Infrastrukturschnittstelle bereits auf der Ebene der Anforderungen erfasst und konzipiert werden kann. Die dem Betrieb zur Verfügung stehenden Werkzeuge, wie SMS, unterstützen dann ein automatisches Roll-Out der verschiedenen Komponenten, hier ist auch die Modellierung von Beziehungen und Abhängigkeiten zwischen den Komponenten möglich. Damit können die Release-Pläne zu den geplanten Zeitpunkten automatisch umgesetzt werden. Die Inventardaten der CMDB spiegeln dann automatisch den neuen Zustand wider und können zur Kontrolle eines erfolgreichen Deployment verwendet werden und die IT-Infrastruktur fortlaufend dokumentieren.

100

Ganzheitlicher Life Cycle

6.3 Ganzheitlicher Life Cycle Zum Abschluss wollen wir noch etwas konkreter werden und die Punkte der vorangegangenen Kapitel und Abschnitte weiter zusammenfassen. In den Abbildungen 6.1 und 6.2 haben wir Entwicklungs- und Betriebsprozesse gegenübergestellt und die Schnittstelle(n) herausgearbeitet.

- t se en ea m el e R ag an m

In t Ü egt b e ra rg tio ab n/ e

Im Folgenden wollen wir Ihnen einen vereinfachten, einheitlichen Ansatz zeigen, der keine explizite Trennung mehr zwischen den Entwicklungs- und Betriebsanteilen eines Projekts vornimmt.

Test/Bug Tracking

Bebauungsmanagement

Tools Im p

Betrieb/ Ticket Tracking

ru n g

Be tr

ieb

entie lem

Architektur

Anforderungsmanagement

Changemanagement

Abb. 6.5: Modell eines ganzheitlichen Life Cycle

schnell + kompakt

101

6 – Ganzheitlicher Life Cycle

Abbildung 6.5 zeigt diesen Ansatz, der sich im Wesentlichen in die folgenden fünf Abschnitte aufteilt: 쐌 쐌 쐌 쐌 쐌

Anforderungs- und Changemanagement Implementierung Integration/Übergabe Releasemanagement Betrieb

Der Gesamtprozess umfasst dabei sowohl Anteile des Betriebs wie auch Anteile der Entwicklung. Koppelstelle zwischen beiden Prozessen ist das Anforderungsmanagement (auf der Seite der Entwicklung) und gleichberechtigt das Changemanagement auf der Seite des Betriebs. Den detaillierten Aufbau dieser Schnittstelle haben wir anhand von Abbildung 6.2 bereits zu Beginn dieses Kapitels besprochen. Die einzelnen Abschnitte gliedern sich jeweils wieder in phasenbezogene Workflows, wie zum Beispiel das Programmieren oder Testen während der Entwicklungsabschnitte. Besonders hervorzuheben (siehe Abbildung 6.5) sind aber bestimmte Querschnittdisziplinen, die in klassischen Ansätzen nicht immer im notwendigen Zusammenhang betrachtet werden. So sollten die Disziplinen 쐌 쐌 쐌 쐌

Testen und Bug Tracking, Bebauungsmanagement, Betrieb und Ticket Tracking und Architektur

in enger Verbindung stehen. Bug Tracking und Ticket Tracking stehen dabei ebenso eng miteinander in Beziehung, wie Architektur und Bebauungsmanagement. Diese Teilgebiete müssen entsprechend zusammenhängend betrachtet werden. Ein adäquates Mittel hierzu ist eine geeignete Werkzeuglandschaft, wie in Kapitel 3 eingeführt. Eine möglichst integrierte Werkzeug-

102

Ganzheitlicher Life Cycle

landschaft hilft dabei nicht nur, Medienbrüche zu vermeiden, sondern auch alle relevanten Prozesse angemessen zu unterstützen und zu automatisieren. Das Schaffen einer einheitlichen Infrastruktur sollten Sie immer im Kontext der umzusetzenden Prozesse angehen. Beide Anteile, Werkzeuge und Prozesse, müssen passen – und zwar nicht nur in den Anwendungskontext, sondern auch zueinander. Die Planung und Umsetzung mag Aufwände verursachen, stellt aber eine homogene, klarer strukturierte und somit langfristig kostengünstigere Lösung dar.

schnell + kompakt

103

Stichwortverzeichnis A Active Directory 78 Agile Methoden Extreme Programming 28 Scrum 28 Anforderungsfeststellung 13, 50, 90 Application Scanner 85 Aufgabenmanagement 59

B Bebauungsmanagement 79 Betrieb 11, 15, 73

IT-Governance 29 ITIL 30

K Konfigurationsmanagement 13

M Management 19, 92 Microsoft Operations Framework 32 Microsoft Solutions Framework 33 Monitoring 18 MSF 33

C CMMI 58 CobiT 30

O

D

P

Deployment 80 Design 13 Downtime 83

Phase 10 Projektmanagement 93 Prototyp 62

E

Q

Eclipse Process Framework 23 Entwicklung 12 Entwurf 13, 55 EPF Eclipse Process Framework 23

Qualitätssicherung 13, 66

Open Unified Process 23

R Rational Unified Process 23 Repository 37 RUP 23

H Helpdesk 87

I IT Infrastructure Library 30, 74 Aufgaben 74

schnell + kompakt

S Sarbanes-Oxley Act 30 Scale-out 83 Service Level Agreements 95 Setup 81

105

Stichwortverzeichnis

SLA 95 SLC 10 Software & Systems Engineering 13 Software Life Cycle 10 SOX 30 Staging 47, 82 Systementwicklung 11, 49

T Test 66 Test-Driven Development 61 Total Cost of Ownership 11

U UML 23 Unified Modeling Language 23

V Virtualisierung 79 Visual Studio 35

106

Visual Studio Team System 34 V-Modell XT 25 Tailoring 26 Vorgehensmodell 14, 21

W Werkzeug Application Center 2000 47 FxCop 65 Microsoft Operations Manager 45 NUnit 38 Project 41 Systems Management Server 43 Visual SourceSafe 37 Visual Studio 35 Visual Studio Team Foundation Server 40 Werkzeuge 35