Vorgehensmodell der Deutschen Telekom: Entwicklung und Instandhaltung von komplexen Softwaresystemen [Reprint 2018 ed.] 9783486791761, 9783486239348

Citation preview

Vorgehensmodell der Deutschen Telekom Entwicklung und Instandhaltung von komplexen Softwaresystemen herausgegeben von Arnulf Ganser, Deutsche Telekom AG Autoren: Sabine Pullwitt, Klaus-G. Tannenbaum

R. Oldenbourg Verlag München Wien 1996

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Pullwitt, Sabine: Vorgeheosmodell der Deutschen Telekom : Entwicklung und Instandhaltung von komplexen Softwaresystemen / Autoren: Sabine Pullwitt ; Klaus G. Tannenbaum. Hrsg. von Arnulf Ganser. - München ; Wien : Oldenbourg, 1996 ISBN 3-486-23934-1 NE: Tannaibaum, Klaus G. :

© 1996 R. Oldenbourg Verlag GmbH, München Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München

ISBN 3-486-23934-1

Inhalt Vorwort des Herausgebers

7

Vorwort der Autoren

9

1.

Einführung

11

2.

Das Vorgehensmodell für die Entwicklung und Instandhaltung

13

2.1 Die Submodelle der Produktsicht 2.1.1 Das I V-Produktmanagement 2.1.2 Das produktbezogene Konfigurationsmanagement

15 15 18

2.2 2.2.1 2.2.2 2.2.3 2.2.4

Die Submodelle der Projektsicht Das Projektmanagement Das projektbezogene Konfigurationsmanagement Die projektinterne Qualitätssicherung Entwicklung und Instandhaltung

20 20 24 26 28

3.

Das Arbeiten mit dem Vorgehensmodell

35

3.1

Die Aufbauorganisation der Entwicklungszentren

35

3.2

Anpassung des Vorgehensmodells an die konkrete Projektsituation 3.2.1 Vortailoring 3.2.2 Tailoring 3.2.3 Einsatz von Standardsoftware

36 36 39 41

3.3

Unterstützung der Anwender

43

4.

Das Phasenmodell

45

4.1

Projektierung (PH 1)

50

4.2 Vorprojekt (PH2) 4.2.1 Lösungsalternativen entwickeln und Grundsatzentscheidung (SE220 und SE230) 4.2.2 Ausgewählte Lösungsalternative konkretisieren (SE240) 4.2.3 Realprojekte planen und beauftragen (SE250 und SE260)

51 53 55 56

5

Inhalt 4.3 Fachliches Feinkonzept (PH3) 4.3.1 DV-System fachlich beschreiben (SE3 20) 4.3.2 Sonstige Anforderungen ermitteln und Dokumentation erstellen (SE330)

61

4.4 4.4.1 4.4.2 4.4.3

DV-technisches Feinkonzept (PH4) Systemkonfiguration planen (SE420) Anwendungsdesign erstellen (SE430) Einführung planen (SE440)

63 65 66 70

4.5 4.5.1 4.5.2 4.5.3

DV-Realisierung (PH5) Codieren und Modultest (SE550) Einführung vorbereiten (SE570) Integration mit Systemtest (SE580)

71 73 75 77

4.6 4.6.1 4.6.2 4.6.3 4.6.4

Systemtest mit Abnahme (PH6) Lauffähigkeit herbeiführen (SE620) Funktionsfähigkeit testen und abnehmen (SE630) IV-Anwendung zur Einführung freigeben (SE640) IV-Anwendung übergeben (SE650)

79 80 83 84 84

4.7 4.7.1 4.7.2 4.7.3 4.7.4

Einführung (PH7) IV-Anwendung erproben (SE720) Wirkbetrieb vorbereiten (SE730) IV-Anwendung zum Wirkbetrieb freigeben (SE740) Wirkbetrieb aufnehmen (SE750)

86 88 90 91 91

5.

Weiterentwicklung des Vorgehensmodells

95

6.

Glossar

97

7.

Register

107

8.

Abbildungen

111

6

58 59

Vorwort des Herausgebers Die Informationstechnik ist heute eine strategische Komponente der Unternehmenspolitik. Die Position des Unternehmens auf dem Markt, die Flexibilität der Unternehmensstruktur, die Unternehmenskultur, letztlich die Dynamik des Unternehmens überhaupt werden von ihr heute so entscheidend beeinflußt, wie früher von Fertigungs- oder Prozeßtechnik. Von äußerst wettbewerbskritischer Relevanz ist es daher, daß die Entwicklung der Informationssysteme diesen hohen Anforderungen gerecht wird. Der Begriff "Software-Engineering" wurde vor 25 Jahren von Friedrich L. Bauer geprägt. Er betont, daß Software-Entwicklung eine Ingenieursdisziplin ist. An den Methoden und Verfahren der Ingenieure muß sich die Software-Entwicklung heute entschiedener als bisher orientieren, insbesondere bei großen, komplexen Systemen. Nur dann können Engineering-Erfolge z.B. in der Bauindustrie, im Anlagenbau oder im Flugzeugbau ebenso in der Software-Entwicklung erreicht werden: hohe Qualität der Produkte, hohe Flexibilität im Prozeß, große Anpassbarkeit und Zuverlässigkeit von Produkten und Prozessen zu optimierten, kalkulierbaren Kosten. Ein wesentlicher Bestandteil ingenieurmäßigen Vorgehens ist eine wiederholbare, nachvollziehbare und dokumentierte Methode, wie sie in diesem Buch vorgestellt wird. Sie verhindert, daß Informationsmonopole einzelner beteiligter Personen entstehen. Sie ermöglicht verfahrensorientierte Arbeitsteilung und gestaltet somit einen nachvollziehbaren, revisionssicheren Entwicklungsprozeß. Damit entstehen qualitätsgesicherte, wartbare Produkte. Dieses Vorgehensmodell ist eine Grundlage der Sofitware-Entwicklung in den sechs Software-Entwicklungszentren der Deutschen Telekom. Alle sechs Entwicklungszentren sind zertifiziert nach DIN ISO-9001, eine Qualitätsnorm, die nicht softwarespezifisch ist, sondern an der sich ebenso Ingenieure anderer Industrien messen. Software-Engineering komplexer Systeme - Systems-Engineering formt die Informationstechnik heute zu einer strategischen Option eines Unternehmens. Das vorliegende Vorgehensmodell bietet eine konkrete Orientierungshilfe, die für jedes geplante Projekt oder Produkt zielorientiert angepaßt werden kann. Neue evolutionäre Verfahren können auf dieser Basis schnell etabliert werden. Arnulf Ganser Geschäftsbereichsleiter "Softwareentwicklung und -Pflege" Deutsche Telekom AG

8

Vorwort der Autoren Für die Deutsche Telekom ist Software-Engineering nicht die einmalige Erarbeitung einer Theorie sondern eine Methode, die ständig weiterentwickelt wird. Ausgehend von dieser Grundhaltung ist das "Vorgehensmodell für die Entwicklung und Instandhaltung von komplexen Softwaresystemen" die Verknüpfung der Theorie des SoftwareEngineering mit der Projektrealität in unserem Unternehmen. Das Vorgehensmodell ist dabei nur soweit abstrahiert worden, wie es notwendig ist, um möglichst viele Projekttypen darstellen zu können. Für das Arbeiten mit dem Vorgehensmodell ist von entscheidener Bedeutung, daß es nicht als restriktive Arbeitsanweisung verstanden wird. Wir sehen es vielmehr als Unterstützung des Managements bei der Projektplanung und -Steuerung. Die Erarbeitung des Vorgehensmodells in der vorliegenden Form war nur möglich, weil viele Mitarbeiterinnen und Mitarbeiter unseres Hauses ihre Ideen und Erfahrungen eingebracht haben. Auf diesem Wege möchten wir allen für ihre Mithilfe und ihr Engagement danken. Wir hoffen, dem Leser Hilfestellung in seiner Tätigkeit geben zu können und sind für Anregungen und Kritik jederzeit dankbar. Klaus-Georg Tannenbaum

Sabine Pullwitt

9

10

1. Einführung Software ist heute für ein Telekommunikationsunternehmen in mehrfacher Hinsicht von großer Bedeutung: 1. Durch technische Weiterentwicklungen in der Informations-, Telekommunikations- und Medienindustrie ergeben sich vollkommen neue Produkte und Dienstleistungen. 2. Software wird zunehmend bei Schalt- und Vermittlungsfunktionen, also im Kernbereich der Telekommunikation, eingesetzt. 3. In komplexer werdenden Unternehmen können die kundenspezifischen Serviceerwartungen nur durch geeignete Softwareunterstützung bewältigt und erfüllt werden. Für die gesamte Deutsche Telekom wird die Software von einem Unternehmensbereich bereitgestellt. Der Bereich "Softwareentwicklung und -pflege" betrachtet sich dabei als Dienstleister für die internen Kunden, d.h. die Unternehmensbereiche und Töchter der Deutschen Telekom. Dieser Bereich ist als Service-Center in zwei Ebenen aufgebaut: 1. Die Ebene der Informationssystemplanung hat die Aufgabe, in enger Zusammenarbeit mit den internen Kunden am Geschäft orientierte, integrierte Informationssysteme zu konzipieren. 2. In Entwicklungszentren werden die Softwareanteile dieser Informationssysteme (die Softwaresysteme) nach dem Vorgehensmodell zur Entwicklung und Instandhaltung von komplexen Softwaresystemen realisiert. Dieses Vorgehensmodell ist ein System ineinander greifender Komponenten, das sicherstellt, daß die vom Kunden gewünschte Leistung in hervorragender Qualität erbracht wird. Dabei wird nicht nur der reine Softwareanteil am Informationssystem, also das Softwaresystem, betrachtet. Die Bereiche Hardware, Systemsoftware und Einbindung in die bestehende Organisation werden dort berücksichtigt, wo sie Einfluß auf die Softwareentwicklung und -einftihrung haben. Die Begriffe "IV-Anwendung" und "Anwendung" werden synonym für "Informationssystem" benutzt. Genauso ist DV-System ein Synonym für "Softwaresystem".

11

12

2. Das Vorgehensmodell für die Entwicklung und Instandhaltung Probleme (Notfall)

Auftrag

Produktrelease

Externe Q S des E Z Abb. 2-1 Vorgehensmodell für die Entwicklung und Instandhaltung von komplexen Softwaresystemen

13

2. Das Vorgehensmodell fìir die Entwicklung und Instandhaltung Das bei der Erstellung qualitativ hochwertiger, anforderungsgerechter Softwaresysteme immer vorhandene Risiko, zu teuer oder zu langsam zu entwickeln, wird reduziert, wenn in einer standardisierten, d.h. erprobten Softwareproduktionsumgebung nach reproduzierbaren Verfahren entwikkelt wird. Die einzelnen Prozesse, die für die Entwicklung, Einführung und Instandhaltung der Softwaresysteme erforderlich sind, werden in der Verfahrenstechnik zu Modellen zusammengefaßt. Diese Vorgehensmodelle stellen sicher, daß • nach bewährten und ständig verbesserten Methoden, • mit ausreichender Dokumentation für Weiterentwicklung und Instandhaltung, • in der gleichen Begriffswelt und • unter Berücksichtigung der allgemeinen Vorschriften des Gesetzgebers und des Unternehmens (z.B. für Datenschutz und Datensicherheit) entwickelt wird. Das Vorgehensmodell der Deutschen Telekom orientiert sich an dem Gnindgedanken der Trennung von Produkt und Projekt. Dabei wird das Softwaresystem als Produkt bezeichnet. Der Lebenszyklus solch eines Produktes besteht aus drei verschiedenen Abschnitten: • Aufbauzeitraum: Das Produkt wird entwickelt. Hierzu zählen Tätigkeiten wie Produktplanung, Machbarkeitsuntersuchungen, Beauftragung, Durchführung der Entwicklung, Infrastrukturbereitstellung und Einführung. • Betriebszeitraum: Im Betriebszeitraum wird das Produkt in Zyklen instandgehalten und ggf. weiterentwickelt. Der Betriebszeitraum endet mit der Außerbetriebnahme des Produktes. • Aufbewahrungszeitraum: Im Aufbewahrungszeitraum wird das außerbetriebgenommene Produkt für einen definierten Zeitraum archiviert. Die Entwicklung des Produktes im Aufbauzeitraum und die Weiterentwicklung und Instandhaltung im Betriebszeitraum erfolgt in Projekten. Am Ende eines jeden Projektes geht eine neue Version des Produktes in den Wirkbetrieb. Daraus ergibt sich, daß ein integriertes Vorgehensmodell die Produktsicht und die Projektsicht berücksichtigen muß. • Produktsicht: Hier wird das Softwaresystem versionsübergreifend betrachtet. • Projektsicht: Hier steht die anforderungsgerechte Entwicklung von Software im Vordergrund. Ausgehend von diesen Überlegungen gliedert sich das Vorgehensmodell in folgende Submodelle:

14

2.1 Die Submodelle der Produktsicht • • • • • •

IV-Produktmanagement, produktbezogenes Konfigurationsmanagement, Projektmanagement, projektbezogenes Konfigurationsmanagement, projektinterne Qualitätssicherung sowie Entwicklung und Instandhaltung.

Aufbau

Betrieb

Aufbewahrung

Wie aus Abbildung 2-1 deutlich wird, beschreiben die Komponenten "IV-Produktmanagement" und "produktbezogenes Konfigurationsmanagement" die Produktsicht. Diese Komponenten bestehen über den gesamten Lebenszyklus des Produktes, während die anderen Komponenten die Vorgehensweise für Projekte beschreiben, von denen n-viele im Lebenszyklus eines Produktes durchgeführt werden.

2.1 Die Submodelle der Produktsicht 2.1.1 Das IV-Produktmanagement Die Betonung des Präfix "IV" zum Produktmanagement ist notwendig, um deutlich zu machen, daß das "Managen des Produktes" die originäre Aufgabe des Kunden ist. Das hier beschriebene Vorgehensmodell fokussiert lediglich auf die IV-Perspektive.

15

2. Das Vorgehensmodell für die Entwicklung und Instandhaltung

7 KM ; produkt- ¡ ! bezogen;

Abb. 2-3 Das Vorgehensmodell - IV-Produktmanagement Das IV-Produktmanagement ist Ansprechpartner des internen Kunden für alle Produktbelange. Es sorgt dafür, daß Entwicklungsaufträge so in Projekte umgesetzt werden, daß die Anfordemngen des Kunden zeitgerecht erfüllt werden. Dahinter steht die Philosophie, daß ein Entwicklungsauftrag nicht unbedingt 1:1 in einem Projekt abgearbeitet wird, sondern nach Auftragslage und Komplexität in mehreren Projekten bearbeitet wird, um so schneller die Anforderungen des Kunden realisieren zu können. Das IV-Produktmanagement hat die Übersicht über alle Projektaufträge. Der Kunde wendet sich mit seinen Wünschen nur an das IV-Produktmanagement. Er muß nicht wissen, in welchen Projekten sein Auftrag bearbeitet wird. Während der Entwicklung oder des Wirkbetriebs eines Softwaresystems wird es Anforderungen zur Fehlerbeseitigung, Anpassung und Weiterentwicklung des Softwaresystems geben. Diese Probleme werden vom produktbezogenen Konfigurationsmanagement (vgl. Seite 18) aufgenommen und nach Analyse des erwarteten Aufwandes an das IVProduktmanagement weitergeleitet. Das Management solcher Probleme ist eine weitere Aufgabe des IV-Produktmanagementes. Probleme lassen sich in drei Kategorien unterteilen: 1. Fehler: Bereits definierte Aufgaben eines Softwaresystems werden nicht korrekt erledigt. 2. Verbesserungen (Optimierung): Definierte Aufgaben eines Softwaresystems können anders besser erledigt werden. 3. Veränderungen (Anpassungen und Erweiterungen): An ein Softwaresystem werden neue Anforderungen gestellt.

16

2.1 Die Submodelle der Produktsicht

Verbesserungen und Veränderungen werden zusammenfassend als Change-Requests (CR) bezeichnet. Change-Requests können sein: • rein fachlicher Natur (z.B. erfordert eine Gesetzesänderung eine neue Steuerberechnung) oder • IV-technisch bedingt (z.B. wird eine Rechnerlinie nicht mehr unterstützt). Das IV-Produktmanagement entscheidet über die Problemlösung im Rahmen seiner Ressourcen, die ihm für das Produkt bzw. für die Projekte zur Verfügung gestellt worden sind. Werden die finanziellen oder andere Eckpunkte überschritten, so erfolgt eine Klärung mit dem Kunden. Wenn der Nutzen der Anforderungen den Aufwand nicht rechtfertigt, werden solche Wünsche zurückgegeben. Das IV-Produktmanagement entscheidet über Change-Requests nicht nur aufgrund des zu erwartenden Aufwandes. Es bezieht in seine Entscheidung die Kundenwünsche mit ein. Gerade dieser Aspekt ist von großer Bedeutung, denn die Änderungsstände eines Softwaresystems müssen in Zusammenarbeit mit dem Kunden geplant werden, damit ein aus strategischer Sicht geplantes Softwaresystem nicht durch Change-Requests so verändert wird, daß es nicht mehr in die Softwarestniktur des Unternehmens paßt. Nach der Entscheidung wird ein Projektauftag für die Entwicklung einer neuen Softwareversion oder für eine Instandhaltungsmaßnahme erteilt. Der beschriebene Regelkreis für das Problemmanagement läuft etwas anders ab, wenn es sich bei dem Problem um einen Notfall handelt. Notfälle sind Fehler eines im Probe- oder Wirkbetrieb befindlichen Softwaresystems, durch die der Deutschen Telekom wirtschaftlicher Schaden droht. Diese werden direkt dem IV-Produktmanagement gemeldet. Das IV-Produktmanagement stößt die Fehlerbeseitigung an und übergibt die Notfälle dann dem produktbezogenen Konfigurationsmanagement zur weiteren Bearbeitung. Das IV-Produktmanagement hat als Bindeglied zwischen dem internen Kunden und der Entwicklung nicht nur aufitrags- und problembezogene Aufgaben. Eine weitere Aufgabe ist die Information der Anwender über veränderte Funktionen des Softwaresystems. Der Kunde ist in der Regel eine zentrale fachliche Organisationseinheit. Für die Nutzung des Softwaresystems ist es aber notwendig, alle betroffenen Stellen über Änderungen zu informieren. Das IV-Produktmanagement verfügt über die Information, wer betroffen ist und übernimmt die Unterrichtung in Abstimmung mit dem Kunden. Neben diesen kundenbezogenen Funktionen hat das IV-Produktmanagement auch Aufgaben in Richtung Entwicklung und Instandhaltung. In Zusammenarbeit mit dem produktbezogenen Konfigurationsmanagement kann es aufgrund seines Überblicks über alle

17

2. Das Vorgehensmodell fur die Entwicklung und Instandhaltung Versionen eines Sofwaresystems Anregungen zu Verbesserungen geben und wiederverwendbare Produkte bzw. Produktteile identifizieren. Dieses Re-use sollte auch außerhalb des ursprünglichen Umfeldes genutzt werden, um so die Gesamtkosten des Unternehmens zu minimieren.

2.1.2 Das produktbezogene Konfígurationsmanagement

Produkt-

Abb. 2-4 Das Vorgehensmodell - produktbezogenes Konfigurationsmanagement

18

2.1 Die Submodelle der Produktsicht Das produktbezogene Konfigurationsmanagement verwaltet alle Produktteile (Konfigurationselemente) in Status und Kombination so, daß eine geregelte Releaseplanung und Dokumentation jederzeit gewährleistet ist. Dazu gehören folgende Aufgaben: • die Anforderungs-/Auftragsverwaltung, • die Bibliotheksverwaltung, • die Lieferverwaltung und • die Notfallverwaltung. In der Anforderungs-/Auftragsverwaltung werden Aufträge und Probleme als Anfordeningen aufgenommen und Vorschläge für ihre Bearbeitung in Projektaufträgen erarbeitet. Sie stellt die Dringlichkeit der Anforderung fest, untersucht in einer Auswirkungsanalyse die Komplexität und die Auswirkungen der Anforderung und stellt fest, welche Konfigurationselemente (K-Elemente) betroffen sind. Aufgrund der Ergebnisse dieser Analyse wird die Anforderung möglicherweise in verschiedene Projektaufträge zerlegt oder mit anderen Anforderungen zu einem Projektauftrag zusammengefaßt. Das Konfigurationsmanagement gibt die Ergebnisse dieser Analyse an das IV-Produktmanagement weiter, das dann über die Anforderungen entscheidet. Das IV-Produktmanagement stößt nach seiner Entscheidung die weitere Bearbeitung der Anforderungen in Projektaufträgen an. Das produktbezogene Konfigurationsmanagement verfolgt die Bearbeitung der Projektaufträge bis zu ihrer Erledigung, damit jederzeit Auskunft darüber gegeben werden kann, • wie die Anfordeningen umgesetzt worden sind und • wie die Projektaufträge bearbeitet werden. In der Bibliotheksverwaltung wird das Softwaresystem über die einzelnen Projekte hinweg verwaltet und koordiniert. Wenn kein Projekt an dem Softwaresystem arbeitet, hat nur sie Zugriff auf das Produkt. Durch die Bibliotheksverwaltung werden alle K-Elemente einer Konfiguration in der Produktbibliothek abgelegt und verwaltet, so daß sie weder absichtlich noch unabsichtlich zerstört oder verändert werden können. Sie liefert für die Planung neuer Projekte Informationen und Auswertungen über das Produkt, sie identifiziert Konfigurationen und vergibt Zugriffsrechte für Projekte und Instandhaltungsmaßnahmen. Bei Bedarf wird die Bibliothek reorganisiert und K-Elemente werden rückgespeichert. Die Lieferverwaltung des produktbezogenen Konfigurationsmanagements verwaltet die Information, wer wann welche Kopien eines Produktreleases erhalten hat. Sie hat somit die Übersicht über die Verteilung eines Softwaresystems. Arbeitet kein Projekt an dem Softwaresystem und

19

2. Das Vorgehensmodell für die Entwicklung und Instandhaltung werden Kopien von Produktreleases gebraucht, so übernimmt sie das Kopieren und Versenden der gewünschten Bereitstellungsdatenträger. Schließlich gehört zum produktbezogenen Konfigurationsmanagement noch die Notfallverwaltung. Sie sorgt dafür, daß die von einem Notfall betroffenen K-Elemente nach den Regeln des Konfigurationsmanagements bearbeitet werden, obwohl in diesem Fall die Fehlerbeseitigung im Vordergrund steht. Durch ein Notfallteam wird der Fehler sofort beseitigt, während die Dokumentation der durchgeführten Arbeiten erst nachträglich erfolgt.

2.2 Die Submodelle der Projektsicht 2.2.1 Das Projektmanagement Das Projektmanagement ist verantwortlich für die Entwicklung bzw. Instandhaltung von Softwaresystemen in IV-Projekten. Das Management von Instandhaltungsmaßnahmen wird hier unter der Überschrift "Projektmanagement" mit beschrieben, weil auch die Instandhaltung nach dem Phasenmodell in Instandhaltungsprojekten abläuft (vgl. Seite 32) und die Aufgaben des Instandhaltungsmanagements den Projektmanagementaufgaben gleichen. Zu den Arbeitsschwerpunkten gehört die Bereitstellung der Softwareproduktionsumgebung (SPU) für das Projekt. Zur Softwareproduktionsumgebung gehören • die Hardware, • die Systemsoftware, • das Know-How und • die Tools. Grundsätzlich obliegt es den Projekten, welche Tools sie zur Entwicklung einsetzen. Der Projektleiter denkt bei der Toolauswahl jedoch nicht nur an das derzeit anstehende Projekt; er bezieht in seine Überlegungen die bereits vorhandene Softwarestruktur und deren SPUs mit ein. Soll mit einer bei der Deutschen Telekom bisher noch nicht eingesetzten SPU gearbeitet werden, so wird in die Nutzenbetrachtung mit einbezogen, daß eventuell Know-How in Form von externen Beratern oder Schulungsmaßnahmen eingekauft werden muß und daß sich dadurch die Projektkosten erhöhen und die Entwicklungszeit verlängert. Der Projektleiter wägt Vor- und Nachteile einer neuen SPU gegeneinander ab

20

2.2 Die Submodelle der Projektsicht und entscheidet sich für die geeigneste SPU fur Entwicklung, Weiterentwicklung und Instandhaltung. Hauptaufgabe des Projektmanagements ist die Projektplanung und -Steuerung bezüglich der Größen • Aufwand, • Personal, • Zeit, • Kosten und • Mittel.

r

(Projekt Ì ι planen und/ \ steuern /

/Ο/ η //>/.•?$/.

SjC? o. ® ft-c·. CÍR,

KM projektbezogen

, Projektinterne QS Instandhaltung

Abb. 2-5 Das Vorgehensmodell - Projektmanagement Die Projekt- bzw. Instandhaltungsaufträge, die Arbeitsgrundlage für das Projektmanagement sind, sind jedoch für die Planung dieser Größen viel zu allgemein formuliert und müssen daher in projektinterne Arbeitsaufträge umgesetzt werden. Dazu wird eng mit dem projektbezogenen Konfigurationsmanagement zusammengearbeitet. Dort werden sie als Anforderung aufgenommen und hinsichtlich der Menge und Komplexität der betroffenen K-Elemente analysiert und bewertet. Diese Information wird an das Projektmanagement zur Aufwandsplanung weitergegeben.

21

2. Das Vorgehensmodell für die Entwicklung und Instandhaltung Bei der Aufwandsplanung werden für alle Tätigkeiten im Projekt Aufwände in Personentagen oder -wochen geplant. Dabei ist nicht nur • die Software-Erstellung, sondern auch • die Planung und Einführung der Software-Pakete in den Betrieb, • die Planung und Einführung der neuen Organisation und • die Planung und Einführung der technischen Infrastruktur von Bedeutung. Zu Beginn des Projektes wird der Aufwand nach der Analogiemethode geschätzt. Nachdem das geplante Softwaresystem fachlich beschrieben ist, stehen alle Informationen zu Verfügung, um das Function-Point-Verfahren zur Aufwandsschätzung einzusetzen. Der so ermittelte Gesamtaufwand wird auf die einzelnen Tätigkeiten im Projekt aufgeteilt, um den Beginn und das Ende der einzelnen Tätigkeiten in der Zeitplanung zu terminieren und in der Personalplanung den Aufwänden Personalkapazitäten zuzuordnen. Dabei werden die unmittelbar anstehenden Aufgaben detaillierter geplant, als die erst später erforderlichen Tätigkeiten. Für diese werden nur grobe Ansätze gewählt, die dann mit Fortschreiten des Projektes und wachsender Kenntnis immer genauer werden. Den in der Aufwandsplanung ermittelten Aufwänden werden in der Personalplanung Personen zur Erledigung dieser Aufgaben zugeordnet. Dabei sind schon bekannte Ausfallzeiten wie z.B. Fortbildungsmaßnahmen und Erholungsurlaub zu bedenken. In der Zeitplanung werden die einzelnen Tätigkeiten in eine Reihenfolge gebracht und zeitlich terminiert. Dabei sind insbesondere die Abhängigkeiten der einzelnen Aufgaben untereinander und der Ausbildungs- bzw. Kenntnisstand der zur Verfügung stehenden Personen von Bedeutung. Im Durchführungsplan laufen schließlich die Aufwands-, Personalund Zeitplanung zusammen. Auf Basis des Durchführungsplanes werden dann die Meilensteine terminiert. Aufgrund der erarbeiteten Ergebnisse werden projektinterne Arbeitsaufträge gebildet. In Teamsitzungen wird festgelegt, wer welche Aufgabe mit welchen Terminen und welchen K-Elementen zu bearbeiten hat. Jedes Projekt kostet natürlich Geld. Der Projektleiter sorgt für die Bereitstellung der erforderlichen Mittel und erfaßt und überwacht die anfallenden Kosten. Kostenbewußtes Verhalten aller Teammitglieder sorgt für preiswerte Produkte und beeinflußt damit die Rentabilität und die Amortisationsdauer des Projektes. Können die Planwerte nicht eingehalten werden, so greift das Projektmanagement steuernd ein. Durch das schrittweise Konkretisieren aller Pläne und durch ständige Soll-Ist-Vergleiche und die Meilensteintrendanalyse wird schnell deutlich, wo die Probleme liegen und wo nach gesteuert werden muß. Bei der Ausregelung der auftretenden Probleme bewegt sich der Projektleiter im Spannungsfeld von 22

2.2 Die Submodelle der Projektsicht • • • •

Quantität (geforderte Funktionalität des Softwaresystems), Zeit, Qualität und Kosten. Unternehmensrahmen - Produkte-/ Diensteplanung - Geschäftsprozeßplanung - Softwarearchitekturplanung Produktrahmen für die Entwicklung und Instandhaltung von IV-Produkten Interne Parameter der Softwareentwicklung: - Personalqualifikation Methoden, Werkzeuge, Projektmanagement... - Rechnerkapazität etc. Einflüsse der Unternehmens-/ GeschäftsfeldPlanung

Abb. 2-6 Softwareentwicklung im Unternehmenszusammenhang Aus der Abbildung 2-6 wird deutlich, daß diese Größen zum einen in den Unternehmensrahmen eingebunden sind und zum anderen durch den Projektrahmen des Softwareentwicklungsprojektes bestimmt werden: • Unternehmensrahmen: Die Gesamtplanung im Unternehmen gibt den "Maximalrahmen" für die Informationssystementwicklung vor. • Produktrahmen für die Entwicklung und Instandhaltung von IV-Produkten: In der Unternehmensgesamtplanung wird ein bestimmter Rahmen zur Realisierung der IV-Produkte vorgegeben. Dieser Rahmen entspricht der Fläche des Vierecks in der Grafik. Wird eine Zielgröße für die IV-Produkte verändert, so muß auch eine Veränderung bei einer oder mehrerer der anderen Zielgrößen eintreten, damit die Fläche des Vierecks und damit der Produktrahmen gewahrt bleibt. • Interne Parameter der Softwareentwicklung: Durch dieses Viereck werden die Möglichkeiten des Projektleiters beschrieben, innerhalb des Projektrahmens ausregelnd zu wirken. Der Projektleiter entscheidet frei über die Behandlung der Probleme, solange er den Rahmen, der bei Projektbeauftragung gesteckt wurde, nicht überschreitet. Eine Überschreitung des einmal gesteckten Projektrahmens

23

2. Das Vorgehensmodell für die Entwicklung und Instandhaltung ist in der Regel nur dann möglich, wenn dies mit dem IV-Produktmanagement bzw. dem internen Kunden abgestimmt ist. Das Projektmanagement dokumentiert seine Planungen nach der Struktur des Vorgehensmodells. Durch die Projektsteuerung werden diese Dokumente aktualisiert. Zur Information der projektexternen Kontrollorgane werden Berichte und Reports gefertigt sowie Reviews durchgeführt. Daneben sammelt ein Management-Informationssystem Daten aus den Projekten und stellt sie für Steuerungs- und Kontrollprozesse während der Produktentwicklung zur Verfügung. Eine wichtige Aufgabe des Projektmanagements zum Abschluß eines Projektes oder einer Instandhaltungsmaßnahme ist die Nachkalkulation. Ihr Ergebnis geht in die Gegenüberstellung der geplanten und der tatsächlich benötigten Aufwände, Personalressourcen, Zeiten, Kosten und Mittel ein. Treten beachtliche Abweichungen auf, so werden die Ursachen hierfür analysiert. Durch diese vergleichende Betrachtung soll die Qualität zukünftiger Planungen erhöht werden.

2.2.2 Das projektbezogene Konfigurationsmanagement Aufgabe des projektbezogenen Konfigurationsmanagements ist es, dem Projekt alle benötigten K-Elemente zur Verfügung zu stellen und deren Integrität und Konsistenz über alle Bearbeitungsvorgänge zu sichern. Dazu wird zu Beginn eines Projektes das Konfigurationsmanagement initialisiert. D.h., • der organisatorische Rahmen, die Schnittstellen und die Regelungen des Konfigurationsmanagements werden im KM-Plan beschrieben, • die Projektbibliothek und die zugehörigen Werkzeuge werden bereitgestellt und • aus der zentralen Produktbibliothek werden die Ausgangskonfiguration und wiederverwendbare Komponenten als Ausschnitt zur Verfügung gestellt. Danach kann das Konfigurationsmanagement seine Arbeit aufnehmen. Eine wichtige Aufgabe ist die projektinterne Anforderungs-/Auftragsverwaltung. Sie hat die Aufgabe, Projektaufträge und projektintern auftretende Problemmeldungen als Anforderungen aufzunehmen. Danach wird in einer Auswirkungsanalyse festgestellt, wie komplex die Anforderung ist, welche Auswirkungen sie hat und welche K-Elemente betroffen sind.

24

2.2 Die Submodelle der Projektsicht

Datensicherung

Abb. 2-7 Das Vorgehensmodell - projektbezogenes Konfigurationsmanagement Aufgrund der Ergebnisse dieser Analyse erarbeitet das Konfigurationsmanagement einen Vorschlag für einen projektinternen Arbeitsauftrag. Dabei kann es sinnvoll sein, mehrere Anforderungen zusammen zu betrachten oder mächtige Anforderungen zu stückeln, um sie in projektinternen Arbeitsaufträgen zu bearbeiten. Nach der Bearbeitung der projektinternen Arbeitsaufträge durch das Projektmanagement (vgl. Seite 21) werden diese vom projektbezogenen Konfigurationsmanagement bis zu ihrer Erledigung weiterverfolgt, um jederzeit produktbezogene Aus-

25

2. Das Vorgehensmodell für die Entwicklung und Instandhaltung künfite zu den Anforderungen und Aufträgen geben zu können und sicherzustellen, daß jede Anforderung bearbeitet wird. Eine weitere Aufgabe des projektbezogenen Konfigurationsmanagements ist die Änderungs-/Lieferverwaltung. Sie verwaltet die Statusänderungen eines jeden K-Elementes. Aus den einzelnen K-Elementen wird schrittweise die Konfiguration fur ein neues Produktrelease gebildet, getestet und abgenommen. Jeder eingefrorene Zustand einer Konfiguration wird als Baseline bezeichnet. So werden die K-Elemente auch der projektinernen Qualitätssicherung zur Verfügung gestellt. Das Ergebnis der Qualitätssicherung wird wiederum vom projektbezogenen Konfigurationsmanagement verwaltet. Nach Abschluß der Entwicklungsarbeiten sorgt die Änderungs-/Lieferverwaltung für die Verteilung des erstellten Produktreleases an alle betroffenen Stellen. Zum projektbezogenen Konfigurationsmanagement gehört schließlich noch die Datensicherung und das Berichtswesen. Die Datensicherung erfolgt regelmäßig nach Vorgaben im Durchführungsplan und KM-Plan. Das Berichtswesen stellt sicher, daß alle Projektteammitglieder über die Aktitivitäten des projektbezogenen Konfigurationsmanagements angemessen informiert werden.

2.2.3 Die projektinterne Qualitätssicherung Die Projektleiter stellen sicher, daß die geforderten und vereinbarten Qualitäten geliefert bzw. eingehalten werden. Dazu wird innerhalb eines Projektes ein Team für die Qualitätssicherung gebildet, das einerseits in das Projekt integriert, andererseits, vom Berichtsweg her gesehen, unabhängig ist. Qualitätssicherung wird dabei nicht so verstanden, daß nach Entwicklungsabschluß Fehler gesucht und nachgebessert werden, sondern die Qualität wird permanent bei allen Zwischenprodukten des Entwicklungsprozesses geprüft. Wird diese projektbegleitende Qualitätssicherung konsequent durchgeführt, ist die Abnahme zum Projektende zum Teil schon erledigt. Aus diesem Umfeld heraus werden folgende zentrale Forderungen an die Qualitätssicherung gestellt: • Die Qualitätssicherung muß geplant werden: Ausgehend von den Qualitätsanforderungen werden konstruktive und analytische Maßnahmen der Qualitätssicherung bei der Projektinitialisierung geplant und in einem Qualitätsmanagementplan festgeschrieben. • Die Qualitätssicherung muß projektbegleitend erfolgen: Qualitätssicherung wird in jeder Phase des Projektverlaufs durchgeführt. Zu jedem Phasenbeginn wird der Qualitätsmanagementplan fortgeschrieben und 26

2.2 Die Submodelle der Projektsicht konkretisiert. Im Phasenverlauf werden Qualitätssicherungsmaßnahmen durchgeführt. Zu jedem Phasenende wird die Zielerreichung in einem Phasenabschlußreview zusammenfassend überprüft. • Die Qualitätssicherung muß angemessen sein: Qualitätssicherungsmaßnahmen werden zum einen soweit möglich nach Risiko und Bedeutung eines möglichen Fehlerverhaltens (Kritikalität) der betroffenen (Teil-)Produkte eingesetzt und beurteilt. Zum anderen werden Qualitätssicherungsmaßnahmen Wirtschaftlichkeitsbetrachtungen unterzogen. • Die Qualitätssicherung muß nachvollziehbar sein: Durchgeführte Qualitätssicherungsmaßnahmen und ihre Ergebnisse, die später relevant oder nützlich sein können, werden in angemessener Weise dokumentiert und aufbewahrt.

IVProduktmanagement

KM "" " "r"-r produkt' ' bezogen ' I

·. "

- » '

I

Bewertung-

I I

/

Externe QS des EZ

Abb. 2-8 Das Vorgehensmodell - projektinterne Qualitätssicherung

27

2. D a s Vorgehensmodell für die Entwicklung und Instandhaltung

U m einen einheitlichen Qualitätsstandard über alle Projekte garantieren zu können, gibt es die projektexterne Qualitätssicherung. Sie abstrahiert und multipliziert einerseits projektindividuelle Qualitätssicherungsmaßnahmen und bringt Bewährtes aus anderen Projekten ein. Andererseits reviewt sie die Einhaltung der Vorgaben des Unternehmens in Bezug auf die Qualitätssicherung.

Arbeitsergebnis/ Projekttätigkeiten It. Vorgehensmodell

Abb. 2-9 Aufgaben der projektexternen Qualitätssicherung Die Ergebnisse dieser Arbeiten führen unter anderem zur ständigen Aktualisierung des "Qualitätsmanagement-Handbuchs" eines j e d e n Entwicklungszentrums. In diesem Handbuch wird die Qualitätsphilosophie mit den erforderlichen Maßnahmen des jeweiligen Entwicklungszentrums beschrieben.

2.2.4 Entwicklung und Instandhaltung Im Kern des Vorgehensmodells wird die Entwicklung und Instandhaltung von Softwaresystemen in einem Phasenmodell mit sieben P h a s e n beschrieben: 1. Projektierung, 2. Vorprojekt, 3. Fachliches Feinkonzept, 4. DV-technisches Feinkonzept, 5. DV-Realisierung, 6. Systemtest mit Abnahme, 7. Einführung. Bei der Deutschen Telekom wird bei der Entwicklung eines neuen Produktes zunächst nur ein Vorprojekt durchgeführt. Die Planung und

28

2.2 Die Submodelle der Projektsicht Beauftragung des Vorprojektes ist in der Phase 1 und die Durchführung des Vorprojektes ist in der Phase 2 des Phasenmodells beschrieben.

bzogen

^„X

Abb. 2-10 Das Vorgehensmodell - Entwicklung und Instandhaltung Das Vorprojekt wird durchgeführt um, • die Machbarkeit generell festzustellen (Feasibility Study), • die Kosten des Projektes dem Nutzen für das Unternehmen gegenüberzustellen (Profibility Study) und • die Realisierung des Informationssystems in Realprojekten zu planen (Implementation Study). Für das Vorprojekt gilt, daß es in höchstens sechs Monaten durchführt werden muß. Diese zeitliche Begrenzung soll folgenden Fehlentwicklungen vorbeugen: 1. Im Vorprojekt sollen die Machbarkeit und die Kosten/Nutzen-Relation des Informationssystems erarbeitet werden. Auf diesen Ergebnissen basiert die Entscheidung über die Realisierung des Informationssystems. Ohne zeitliche Begrenzung würden diese Entscheidungshilfen unnötig aufgebläht, ohne die Entscheidungsbasis wesentlich zu verbessern. 29

2. Das Vorgehensmodell fìir die Entwicklung und Instandhaltung 2. Die Ergebnisse des Vorprojektes sollen aktuell sein, damit das geplante Informationssystem während der Realisierung nicht schon veraltet ist.

Auftrag

Problem

Vorprojekt beauftragen

max 6 Zeitmonate

max. 1 Zeitmonat

P h a s e 2 Vorprojekt

\\ Κ -\

Realprojekt beauftragen

Abb. 2-11 Überblick über die Zeitvorgaben für die Informationssystementwicklung Das Vorprojekt liefert einen Managementbericht mit Entscheidungsvorlage, aufgrund derer entschieden wird, ob das Informationssystem entwickelt wird oder nicht. Die Realisierung des Informationssystems erfolgt in Realprojekten (Phasen 3 bis 7). Eine kurze Entwicklungszeit ist heute ein wesentlicher Erfolgsfaktor der Softwareentwicklung. Ein Realprojekt soll deshalb 1, maximal 2 Jahre dauern. Ist das Informationssystem dazu zu komplex oder stehen die erforderlichen Ressourcen nicht in ausreichender Menge zur

30

2.2 Die Submodelle der Projektsicht

Verfügung, wird in mehreren Realprojekten entwickelt, die parallel, sequentiell oder zeitversetzt laufen können. So kann zunächst ein Softwaresystem mit einer überschaubaren, homogenen Funktionalität entwickelt und eingeführt werden, das durch bereits im Vorprojekt geplante, aufbauende Versionen weiterentwickelt wird. Weiterhin wird erreicht, daß in überschaubaren Projekten realisiert wird, die leichter zu handhaben sind als ein "Mammutprojekt". 5 Realprojekte laufen parallel

>

1

T

^

>

O

2

>

3

>

4

>

Σ

sequentiell ablaufende Realprojekte

Realprojekte laufen zeitversetzt

Abb. 2-12 Mögliche Struktur von Realprojekten Bei der Entwicklung des Softwaresystems im Realprojekt können zwei Hauptaufgaben unterschieden werden: • die eigentliche Entwicklung des Softwaresystems und • dessen Einführung in den Betriebsablauf, bzw. das betriebliche Arbeitssystem. Da bei der Deutschen Telekom viele Softwaresysteme in über 100 Niederlassungen zur Verfügung gestellt werden müssen, hat es sich als zweckmäßig erwiesen, diese beiden Aufgaben in zwei Teilprojekten, einem Entwicklungsprojekt und einem Einführungsprojekt zu organisieren. Zum Entwicklungsprojekt gehören alle Tätigkeiten, die direkt mit der Erstellung des Softwaresystems zusammenhängen. Aufgabe des Einftihrungsprojektes ist es, die Einfuhrung des Informationssystems in den Wirkbetrieb zu organisieren. Die Koordination dieser Teilprojekte übernimmt der "Gesamt"-Projektleiter, der abhängig von der Projektgröße auch gleichzeitig ein Teilprojekt leitet. Die Abbildung 2-13 zeigt das Zusammenspiel von Einführungs- und Entwicklungsprojekt. Im Einführungsprojekt fehlen dabei die "Phasenschnitte". Der Gnind ist darin zu sehen, daß die Einführung eigentlich nur

31

2. Das Vorgehensmodell für die Entwicklung und Instandhaltung in zwei Phasen abläuft, der Phase "Einführung" und den vorbereitenden Tätigkeiten. Diese Arbeiten sind aber abhängig von den Ergebnissen, die im Entwicklungsprojekt in den einzelnen Phasen erarbeitet werden. Das Phasenmodell wirkt so nur mittelbar auf das Einführungsprojekt. Im Phasenmodell werden die Tätigkeiten für Entwicklungs- und Einfuhrungsprojekt im Zusammenhang beschrieben. Die Zuständigkeiten ergeben sich aus einer Zuständigkeitsmatrix.

Abb. 2-13 Einftihrungs- und Entwicklungsprojekt Bei der Instandhaltung von Softwaresystemen steht die Werterhaltung des Produktes im Vordergrund. Für diese Produktpflege steht pro Jahr für jedes Softwaresystem nur das Budget zur Verfügung, das mit dem Auftrag als Instandhaltungsaufwand vom Kunden genehmigt worden ist. Aus diesem Grund muß die Instandhaltung sorgfältig geplant und organisiert durchgeführt werden. Aus diesem Budget werden primär Maßnahmen zur Fehlerbeseitigung finanziert, aber auch kleine Anpassungen

32

2.2 Die Submodelle der Projektsicht und Erweiterungen können innerhalb der Instandhaltung durchgeführt werden. Bei der Fehlerbeseitigung werden Notfälle, die sofort bearbeitet werden müssen, und Fehler, die in einem vorgegebenen Zeitraum beseitigt werden sollen, unterschieden. Notfälle werden von einem Notfallteam sofort bearbeitet. Alle Instandhaltungsmaßnahmen, die nicht als Notfälle bearbeitet werden, werden nach Bearbeitungspriorität und sachlicher Zusammengehörigkeit zu Instandhaltungsprojekten zusammengefaßt. Jedes Instandhaltungsprojekt durchläuft die Phasen 3 bis 7 in verkürzter Form. Das Durchlaufen des Phasenmodells ist notwendig, weil nicht nur der Fehler beseitigt, sondern auch nachdokumentiert, getestet und abgenommen werden muß. Es ist jedoch nicht immer notwendig, in der Phase 3 oder 4 mit dem Durchlauf zu beginnen. Dies ist z.B. der Fall, wenn ein Codierfehler beseitigt wird, der keine Auswirkung auf die fachliche Spezifikation des Softwaresystems hat. Eine Abnahme und die Einführung der Änderung sind aber immer erforderlich.

33

34

3. Das Arbeiten mit dem Vorgehensmodell Für das Arbeiten mit dem Vorgehensmodell ist es wichtig, zu wissen, wie es sich in die Aufbauorganisation der Entwicklungszentren einfügt.

3.1 Die Aufbauorganisation der Entwicklungszentren In einem Entwicklungszentrum wird eine sich ständig verändernde Anzahl zeitlich befristeter und unterschiedlich dimensionierter Projekte bearbeitet. Sie ist deshalb geprägt durch eine flexible, projektorientierte Organisation. Aus einem Kräftepool werden Gruppen in der jeweils erforderlichen Zusammensetzung für die Entwicklung und Instandhaltung gebildet. Zur Verbesserung der Kommunikation und Integration werden verwandte Projekte oder Projekte mit gleichen Bezugsbereichen unter einem Entwicklungsbereich zusammengefaßt.

Bereich Β Beratung

Bereich Q Qualitätsmanagement

Projekte

Projekte

Projekte

Projekte

Produkte

Bereich Ζ Zentrale Aufgaben

Abb. 3-1 Aufbauorganisation eines Entwicklungszentrums (EZ)

35

3. Das Arbeiten mit dem Vorgehensmodell

Für unterstützende Aufgaben gibt es die Bereiche Beratung (B) und Qualitätsmanagement (Q). Der Bereich Beratung unterstützt einerseits die Projekte in speziellen Aufgaben mit Expertenwissen und macht andererseits Erfahmngen, die in Projekten gewonnen werden, parallel laufenden oder späteren Projekten zugänglich. Der Bereich Qualitätsmanagement übernimmt die Aufgaben der projektexternen Qualitätssicherung. Er berät die Projekte in allen Fragen des Qualitätsmanagements. Außerdem überprüft er in Reviews zu bestimmten Meilensteinen in der Projektabwicklung die Arbeit der Qualitätssicherungskräfte der einzelnen Projekte und stellt so sicher, daß das Entwicklungszentrum gleichbleibende bzw. ständig verbesserte Qualitäten für alle entwickelten Produkte garantieren kann. Der Bereich "Zentrale Aufgaben" (Z) ist für die mittelbaren Aufgaben im Entwicklungszentrum zuständig. Dieser Bereich versteht sich genauso wie die Bereiche "Beratung" und "Qualitätsmanagement" als Dienstleister, der dafür sorgt, daß dem Produktionsbereich optimale Arbeitsbedingungen zur Verfügung gestellt werden. Im Vorgehensmodell sind die Entwicklungstätigkeiten und deren Dokumentation ohne Bezug auf die zuständige Organisationseinheit oder den betroffenen Aufgabenträger beschrieben. Die Einbindung des Vorgehensmodells in die Aufbauorganisation erfolgt nicht unmittelbar, sondern über sog. "Rollen" wie z.B. "Projektleiter" oder "KM-Administrator". Das Vorgehensmodell enthält eine Beschreibung der möglichen Rollen. In Verbindung mit den Organigrammen, Stellenbeschreibungen und Anforderungsprofilen des Unternehmens wird der zuständige Bearbeiter ermittelt. Dieses Vorgehen macht das Vorgehensmodell unabhängig von Veränderungen in der Aufbauorganisation.

3.2 Anpassung des Vorgehensmodells an die konkrete Projektsituation 3.2.1 Vortailoring Das bisher beschriebene Vorgehensmodell der Deutschen Telekom ist ein in sich konsistentes System. Probleme hat jedoch die konkrete Beschreibung der Entwicklungstätigkeiten bei Einsatz unterschiedlicher Softwareproduktionsumgebungen (SPU) bereitet.

36

3.2 Anpassung des Vorgehensmodells an die konkrete Projektsituation

Abb. 3-2 Das Schieberegister In einem Großunternehmen wie der Deutschen Telekom ist es nicht möglich, eine einheitliche Softwareproduktionsumgebung anzuwenden, dazu sind die Problemstellungen zu differenziert. Die Herausforderung hat darin bestanden, trotzdem nur ein Vorgehensmodell zu benutzen. Die Lösung besteht darin, daß nach Art eines "Schieberegisters" sich die SPU-abhängigen Prozeßteile (Kernprozesse) mit den SPU-unabhängigen (Rahmenprozesse) bedarfsgerecht kombinieren lassen. Die Abbildung 3-2 zeigt, wie dieser Gedanke im Vorgehensmodell umgesetzt wurde.

37

3. Das Arbeiten mit dem Vorgehensmodell

Die beiden ersten Phasen enthalten im wesentlichen nur Rahmenprozesse und sind deshalb unabhängig vom Projekttyp zu durchlaufen. Das gleiche gilt für die beiden letzten Phasen. Die mittleren Phasen enthalten sowohl Kern- als auch Rahmenprozesse. Die Beschreibung der Rahmenprozesse ist für alle Projekte gleich. Die Kernprozesse variieren dagegen und wie in einem Schieberegister werden sie für die entsprechende Softwareproduktionsumgebung ausgetauscht. Die Abschnitte • IV-Produktmanagement / Projektmanagement, • Konfigurationsmanagement und • projektinterne Qualitätssicherung sind ebenfalls für alle Projekte gleich. Daraus ergibt sich, daß zwar verschiedene Vorgehensmodelle für die verschiedenen Softwareproduktionsumgebungen existieren. Diese unterscheiden sich jedoch nur im Aufbau der Kernprozesse und somit in ihrem Phasenmodell ftir Entwicklung und Instandhaltung voneinander. Durch dieses Vorgehen sind drei Ziele erreicht worden: 1. Es ist vermieden worden, daß es eine Unzahl von Vorgehensmodellen gibt, die nicht miteinander korrespondieren. 2. Wenn Entwickler in eine neue Softwareproduktionsumgebung einsteigen, ist die Einarbeitungszeit für das Vorgehensmodell gering. 3. Durch gleiche Rahmenprozesse werden Projekte mit unterschiedlichen Softwareproduktionsumgebungen für das Management vergleichbar und damit besser steuerbar. Das Vorgehensmodell-BASIS (VM-BASIS) ist bereits als SPU-unabhängige Beschreibung des Entwicklungsprozesses realisiert worden. In diesem Vorgehensmodell werden die Phasen 3 bis 6 nur sehr grob beschrieben. Es gibt ein Vorgehensmodell für die Entwicklungsumgebung Composer by IEF und ein Vorgehensmodell für die Entwicklung mit dem Data-Dictionary-System Datamanager von M S P und dem Programmiergenerator DELTA. Weitere Vorgehensmodelle sind für die objektorientierte Entwicklung und ftir PC-Anwendungen geplant. Die Vorgehensmodelle lassen sich in die IS09000-konform aufgebaute Dokumentationsstruktur des Qualitätsmanagements (Qualitätsmanagement-Pyramide) wie folgt einordnen: Das Vorgehensmodell-BASIS und die daraus abgeleiteten, speziellen Vorgehensmodelle sind auf der mittleren Ebene der Pyramide einzuordnen. Aus ihnen werden in den Projekten die individuellen "Arbeitsanweisungen" abgeleitet. Diese Arbeitsanweisungen sind z.B. die projektspezifische Vorgehensweise, die Durchführungspläne und die Projektstandards.

38

3.2 Anpassung des Vorgehensmodells an die konkrete Projektsituation

QM\ \ ' Handbuch

Qualitätspolitik, A u f b a u - u n d Ablauforganisation, Leistungsbeschreibung des Q M - S y s t e m s , Verantwortlichkeiten, K o m p e t e n z e n M e t h o d e n und Verfahrensbeschreibungen Ausführungsbestimmungen für bestimmte Aktivitäten

Abb. 3-3 Dokumentationsebenen des Qualitätsmanagement-Systems

3.2.2 Tailoring Das Vorgehensmodell gibt Entwicklungsschritte und deren Dokumentation vor und empfiehlt, die Informationssystementwicklung nach einem bestimmten Grundmuster durchzufuhren. Das Vorgehensmodell kann dabei aber immer nur eine allgemeingültige Beschreibung sein. Es ist deshalb zwingend notwendig, daß das Projektmanagement vor Projektbeginn generell und bei neuen Erkenntnissen fortlaufend in einem Tailoring-Prozeß das Vorgehensmodell an die Bedürfnisse des jeweiligen Projektes anpaßt. Durch das Vortailoring sind Vorgehensmodelle für bestimmte Projekttypen entstanden. Im eigentlichen Tailoring-Prozeß wird das ftir das Projekt ausgewählte Vorgehensmodell auf die Gegebenheiten des konkreten Projektes zugeschnitten. Das Projektmanagement prüft, ob alle Entwicklungsschritte und Dokumente des Vorgehensmodells für dieses Projekt notwendig sind. Nicht notwendiges wird gestrichen. Wenn projektspezifisch Tätigkeiten und Dokumente zusätzlich benötigt werden, können sie in das Phasenmodell aufgenommen werden. Dabei sind die sieben Phasen des Vorgehensmodell nicht als Wasserfallmodell zu verstehen, bei dem eine neue Projektphase abgeschlossen sein muß, bevor mit der nächsten begonnen werden kann. Jederzeit können Tätigkeiten späterer Phasen vorgezogen werden, wenn es für das konkrete Projekt notwendig ist. Genauso sind Rücksprünge in vorgelagerte Aktivitäten projektindividuell möglich. Der Durchfiihrungsplan des Projektes entsteht dann, indem die projektspezifische Vorgehensweise durch Zuordnung von Aufgabenträgern und Festlegung von Erledigungsterminen konkretisiert wird.

39

3. Das Arbeiten mit dem Vorgehensmodell

Vortalloring Vorbereitet für Projekttypen mit gleicher Softwareproduktionsumgebung

Tailoring Anpassen des V M an die Besonderheiten des Projektes

Projektspezifische Vorgehensweise

Welche Aufgaben sollen wann von wem erledigt werden?

Durchführungsplan

Projektplanung Erstellen eines Durchführungsplanes unter Berücksichtigung der Projektressourcen, Terminvorgaben, etc.

Abb. 3-4 Erstellen einer projektspezifischen Vorgehensweise durch Anpassung / Individualisierung des Basismodells Diese Überlegungen gelten sinngemäß auch für kleine Projekte. Durch Überarbeitung kann das Vorgehensmodell auf die Projektgröße angepaßt werden und so auch dort Basis für die Durchführungsplanung sein. Oftmals wird von diesen kleinen Projekten gegen das Vorgehensmodell eingewendet, daß die Einarbeitung zu viel Zeit in Anspruch nimmt. Gerade bei diesen Projekten ist aber wegen der kurzen Entwicklungszeit eine sorgfaltige Zeitplanung erforderlich, da nur wenig Ressourcen zur Kompensation von z.B. vergessenen Aktivitäten vorhanden sind.

40

3.2 Anpassung des Vorgehensmodells an die konkrete Projektsituation 3.2.3 Einsatz von Standardsoftware Bei der Deutschen Telekom soll Standardsoftware nach Möglichkeit in den Nichtwettbewerbsbereichen eingesetzt werden. Diese Software bildet Wissen ab, das im wesentlichen alle Wettbewerber besitzen. Ein Wettbewerbsvorteil kann hier durch Eigenentwicklungen nicht erreicht werden. Durch den Einsatz von Standardsoftware in diesen Bereichen wird erreicht, daß • gute Softwarelösungen schnell verfügbar sind, • technisch ausgereifte Lösungen kostengünstig eingesetzt werden und • die Instandhaltung gut kalkuliert werden kann. Für den Einsatz von Standardsoftware ist kein eigenes Vorgehensmodell entwickelt worden. Vier Überlegungen haben zu dieser Entscheidung geführt: 1. Die Variationsbreite der möglichen Formen des Einsatzes von Standardsoftware ist sehr groß. 2. Die Vorgehensweise bei der Einführung von Standardsoftware ist von der mitgebrachten Softwareproduktionsumgebung abhängig. 3. Die Einführung einer Standardsoftware wird um so komplexer, je mehr Möglichkeiten die Standardsoftware mitbringt, sie an das jeweilige Unternehmen anzupassen. Beim Einsatz moderner, flexibler Standardsoftware müssen also die fachlichen Anforderungen ähnlich konkret beschrieben werden, wie bei einer Neuentwicklung. 4. In der überwiegenden Zahl der Fälle wird es Erweiterungen der Standardsoftware geben, die nach einem Vorgehensmodell für Neuentwicklungen entwickelt werden müssen. In einem Tailoring-Prozeß wird deshalb ein Vorgehensmodell auf den Einsatz von Standardsoftware zugeschnitten. Wie aus Abbildung 3-5 deutlich wird, sollte es beim Einsatz von Standardsoftware zwei parallel laufende Entwicklungsprojekte geben. Ein Entwicklungsprojekt bezieht sich auf die richtige Einstellung der Parameter der Standardsoftware, während in einem zweiten Entwicklungsprojekt Erweiterungen realisiert werden.

41

3. Das Arbeiten mit dem Vorgehensmodell

Entwicklungsprojekt Planung - Organisation

Standardsoftware anpassen

- Schulung - Infrastruktur

Entwicklungsprojekt Standardsoftware erweitern - Fachliches Feinkonzept - D-technisches Feinkonzept - DV-Realisierung

¡Einführung

Probebetrieb

Software

Einführung in die Fläche

Wirkbetrieb

Abb. 3-5 Realprojekt mit Standardsoftware

42

Software

3.3 Unterstützung der Anwender

3.3 Unterstützung der Anwender Bei der Deutschen Telekom ist die Erfahrung gemacht worden, daß es nicht ausreicht, ein Vorgehensmodell auf vielen Seiten niederzuschreiben und dessen Anwendung "anzuordnen". Es muß vielmehr daraufhingearbeitet werden, das Vorgehensmodell in verschiedenen Formen zielgruppengerecht zur Verfügung zu stellen. Das Vorgehensmodell ist in seinem Ursprung in einer Datenbank abgelegt. Auf diese Datenbank können alle Entwickler zugreifen und die Abfragemöglichkeiten nutzen. Wer mit der Datenbank nicht vertraut ist, kann sich online das Vorgehensmodell als WINHELP-Datei ansehen. In dieser Datei kann nicht nur gesucht und gelesen werden; es können auch persönliche Anmerkungen angelegt werden. Querverweise (Hypertextlinks) zwischen den Abschnitten unterstützen die gezielte Information. Das Vorgehensmodell steht außerdem • in gedruckter Form und • als Bestandteil eines Projektplanungstools zur Verfügung, und es • wird in Schulungsmaßnahmen vorgestellt. Keine noch so gut gestaltete Unterlage und auch kein Lehrgang kann jedoch eine individuelle Projektberatung ersetzen. Hierfür stehen die Bereiche "Beratung" der Entwicklungszentren oder die Gnippe " V M - B A S I S " beim Entwicklungszentrum Nord, Außenstelle Braunschweig, zur Verfügung. Die Gnippe " V M - B A S I S " nutzt darüber hinaus die Erfahrungen der Projekte mit dem Vorgehensmodell für dessen Weiterentwicklung. So werden Teile, die die User beim projektspezifischen Tailoring als überflüssig oder ergänzenswert beurteilt haben, eingearbeitet. So baut sich langsam eine Erfahrungs"datenbank" der besten Entwicklungspraxis auf.

43

44

4. Das Phasenmodell Das Phasenmodell ist nicht als "Lesebuch" sondern als "Arbeitsbuch" konzipiert. Die vollständige Darstellung des Entwicklungsgangs eines Softwaresystems ist nicht in der fur Texte üblichen Gliederungsstruktur beschrieben. Die Beschreibung der Tätigkeiten im Entwicklungsprozeß hat vielmehr einen besonderen Aufbau, der in der Abbildung 4-1 dargestellt ist.

Dokumentation

Arbeitspapiertypen

Ergebnisdokumenttypen

Abb. 4-1 Strukturierte Beschreibung der Entwicklungstätigkeiten Die Beschreibung der fur den Entwicklungsprozeß erforderlichen Tätigkeiten erfolgt in Aktivitäten. Aus Gründen der Übersichtlichkeit werden die Aktivitäten (AK) in Segmente (SE) und diese wiederum in

45

4. Das Phasenmodell Phasen (PH) zusammengefaßt. Teilaktivitäten werden gebildet, wenn eine Aktivität so umfangreich ist, daß eine weitere Gliederungsstufe zur übersichtlichen Beschreibung notwendig wird. Die Namen der Phasen, Segmente, Aktivitäten und Teilaktivitäten sind zur schnellen Orientierung nach folgendem Nummerungsschema gebildet worden. Phase PH 1 Segment SE 120 Aktivität AK 12001 Teilaktivität AK 12001-01 Im Gegensatz zu vielen anderen Vorgehensmodellen werden bei der Deutschen Telekom nicht nur die Entwicklungsarbeit, sondern auch die Entwicklungsergebnisse beschrieben. Dadurch soll erreicht werden, daß die Dokumentation für alle Projekte einheitlich strukturiert ist. Die Entwicklungsergebnisse werden in sog. Arbeitspapieren dokumentiert. Dies sind nicht unbedingt "Papierdokumente"; es kann sich um Einträge in Textverarbeitungssysteme, Datenbanken und andere elektronische Speichermedien handeln. Arbeitspapiere sind Instanzen des Arbeitspapiertyps. Im Vorgehensmodell ist der Informationsgehalt der Arbeitspapier(y/?e« beschrieben, so z.B. des Arbeitspapieres- ANW524 Dialog. Da es im Projekt mehr als einen Dialog geben wird, wird fiir jeden Dialog ein Arbeitspapier vom Typ ANW524 in der Entwicklungsdatenbank abgelegt. Wenn Arbeitsergebnisse einen bestimmten Entwicklungsstand erreicht haben, werden sie zu Ergebnisdokumenten zusammengefaßt. Die Ergebnisdokumenttypen sind ebenfalls im Vorgehensmodell beschrieben. Der Informationsgehalt und die Präsentation eines Ergebnisdokumentes müssen auf die jeweilige Zielgruppe zugeschnitten sein. Deshalb werden drei Formen der Ergebnisdokumenterstellung unterschieden. Die Abbildung 4-2 gibt hierzu einen Überblick. Eine besondere Rolle hinsichtlich der Dokumentation der Entwicklungsergebnisse nimmt die Produktdokumentation ein. In diesem Teil des Vorgehensmodells sind Vorgaben für die Erstellung der Handbücher zum Softwaresystem enthalten. Hierdurch wird erreicht, daß die Beschreibung aller Softwaresysteme einheitlich aufgebaut ist. Darüber hinaus sind Tätigkeiten und Dokumentation in zweisortigen Netzen miteinander verkettet. In den Aktivitäten ist aufgelistet, welche Arbeitspapiere und Ergebnisdokumente Informationsquelle für diese Aktivität sind und welche Ergebnisse in ihr erarbeitet werden. Genauso enthalten die Arbeitspapier- und Ergebnisdokumenttypbeschreibungen eine Auflistung, in welchen Aktivitäten dieser Arbeitspapier- oder Ergebnisdokumenttyp als Informationsquelle benötigt oder als Ergebnis erzeugt wird.

46

4. Das Phasenmodell

ζ. Β. Grobkonzept

U

ζ. Β. Dateihandbuch

CT' AP ED

Managementbericht

Arbeitspapiertyp Ergebnisdokument

Abb. 4-2 Die Erstellung von Ergebnisdokumenten Durch die Verkettung von Entwicklungsschritten und Dokumentation wird schnell ersichtlich, wie die Entwicklungsergebnisse entstehen und wo sie im Projektverlauf wieder benötigt werden. So kann z.B. beim Tailoring sicher beurteilt werden, ob eine Tätigkeit und mit ihren Ergebnissen nur einmalig von Bedeutung ist, oder ob während der weiteren Entwicklung im Projekt darauf zurückgegriffen werden muß. In der Abbildung 4-3 wird dieser Informationsfluß graphisch dargestellt. Dieser Informationsfluß spiegelt sich in den Strukturdiagrammen des Vorgehensmodells wider. Dabei handelt es sich nicht immer um einen "geradlinigen" Fluß. Ergebnisse werden zum Teil iterativ erarbeitet, weil sich verschiedene Tätigkeiten gegenseitig beeinflussen. Um die Strukturdiagramme möglichst übersichtlich zu halten, werden die Iterationen in den Graphiken nicht dargestellt. In der Tätigkeitsbeschreibung wird jedoch auf die gegenseitige Beeinflussung hingewiesen. In den Strukturdiagrammen werden neben den Tätigkeiten und der Dokumentation der Ergebnisse auch sog. Objekte der Realität dargestellt. Hierbei handelt es sich um die realen Produkte des Entwicklungsprozesses wie z.B. das Coding. Diese sind in die Strukturdiagramme eingebunden, damit deutlich wird, wann welches Teilergebnis real vorliegt. Im Phasenmodell sind neben den operativen Arbeiten auch Segmente beschrieben, in denen Entscheidungen fallen. Dadurch wird deutlich, welche Genehmigungsschritte ein Informationssystem durchlaufen muß. Eine Übersicht gibt die Abbildung 4-4.

47

4. D a s Phasenmodell

Aus der Abbildung 4-4 wird deutlich, welche Bedeutung die Entscheidung zur Durchflihrung eines Realprojektes (Ende der Phase 2) hat. Zwischen dem Ende des Vorprojektes und der Phase 6 sind keine weiteren Genehmigungsschritte vorgesehen, weil in den Phasen 3 bis 5 "nur" die Konzepte verfeinert werden, die in Phase 2 grob umrissen und in einer Kosten- und Nutzenbetrachtung bewertet worden sind. Ändert sich während der Entwicklung etwas an diesen Annahmen des Vorprojektes, so ist es Aufgabe des Projektmanagements, eigeninitiativ steuernd einzugreifen. Gleiches gilt, wenn die tatsächliche Realisierung nicht der geplanten entspricht, weil z.B. die geplante Arbeitskapazität bereits nach der Hälfte der Zeit verbraucht zu sein scheint. Das Fehlen von Genehmigungsschritten in den Phasen drei bis fünf bedeutet jedoch nicht, daß das Projekt hier unkontrolliert arbeitet. Eine Kontrolle der Projektentwicklung erfolgt durch regelmäßige Statusreports und durch die Meilensteinreviews am Ende der Phasen, an denen auch die projektexterne Qualitätssicherung beteiligt ist. Nach dieser Philosophie wird eine Grundsatzentscheidung für das Projekt nicht mehr nach jeder Detaillierungsphase erforderlich. Sollten die Projektentwicklung, Meilensteinreviews oder externe Einflüsse jedoch Anlaß geben, den Projekterfolg in Frage zu stellen, muß von der dispositiven Ebene sofort entschieden werden.

48

4. Das Phasenmodell

I

Phase 1 Projektierung"

operative Ebene SE120 Vorprojekt planen

ρ

dî$pû$itîve Ebene

1 ¡SE130 "Vorprojekt in Auftrag I geben

SE220 1 Lösungsalternativen | entwickeln Ν ω

ν 'S"