PROJEKTMANAGEMENT IN MODERNER SOFTWAREENTWICKLUNG

METHODEN DES P RO J E K T M A NAG E M E N T S I N MODERNER S O F T WA R E E N T W I C K LU N G am Beispiel eines plattformübergreifenden elektronischen Tagebuchs

Am IT-Center Dortmund

Prüfer:

erstellte Thesis

Prof. Dr. K. Zeppenfeld

im Studiengang IT-Bachelor

Prof. Dr. F. M. Thiesing

zur Erlangung des akademischen Grades »Bachelor in Information Technology« von Florian Alexander Michalik, geboren am 11. Januar 1981

Dortmund, den 3. Juni 2007

Methoden des Projektmanagements in moderner Softwareentwicklung

INHALTSVERZEICHNIS TEIL I VORWORT ........................................................................................................7 1 „Auf den Schultern von Giganten” ................................................................................. 7 2 Sprachliche Besonderheiten .......................................................................................... 7 3 Dank................................................................................................................................8 TEIL II EINLEITUNG ................................................................................................... 9 4 Motivation ..................................................................................................................... 9 5 Überblick ...................................................................................................................... 10 TEIL III PROJEKTMANAGEMENT IN DER SOFTWAREENTWICKLUNG .................................... 11 6 Wirtschaftlichkeitsaspekte ........................................................................................... 11 6.1 Kosten- und Nutzenbegriff .................................................................................... 11 6.2 Kostenminimierung .............................................................................................. 12 7 Rollen und Teams .........................................................................................................15 7.1 Modell der Motivation .......................................................................................... 15 7.1.1 Charakterisierung von Leistungstypen........................................................... 16 7.1.2 Managementstrategie zur Motivationserhöhung ......................................... 17 7.2 Rollen und Verantwortlichkeiten......................................................................... 18 7.2.1 Auftraggeber.................................................................................................... 18 7.2.2 Auftragnehmer ............................................................................................... 18 7.2.3 Fachreferent .................................................................................................... 18 7.2.4 Benutzer.......................................................................................................... 19 7.2.5 Projektleitung ................................................................................................. 19 7.2.5.1 Charakterisierung und Bedeutung .......................................................... 19 7.2.5.2 Aufgaben .................................................................................................. 20 7.2.6 Softwareentwickler ........................................................................................24 7.3 Teamstrukturen .................................................................................................... 25 7.3.1 Teamorganisation ........................................................................................... 25 7.3.1.1 Einzelpersonen und kleine Gruppen ....................................................... 25 7.3.1.2 Anarchische Teamstruktur ...................................................................... 26 7.3.1.3 Demokratische Teamstruktur.................................................................. 27 7.3.1.4 Hierarchische Teamstruktur ................................................................... 28 7.3.1.5 Chief-Programmer- Teamstruktur .......................................................... 28 7.3.2 Entwicklergruppen ........................................................................................ 29 7.3.2.1 Kreative Teams ......................................................................................... 29 7.3.2.2 Feature Teams .......................................................................................... 30 Seite 2

Methoden des Projektmanagements in moderner Softwareentwicklung

7.3.2.3 Tiger Teams .............................................................................................. 30 8 Softwareentwicklungsprozesse .................................................................................... 31 8.1 Vorgehensmodelle ................................................................................................. 31 8.1.1 Code and Fix .................................................................................................... 31 8.1.2 Wasserfallmodell ............................................................................................ 32 8.1.3 Iterativ-inkrementelle Entwicklung .............................................................. 35 8.1.4 Spiralmodell ....................................................................................................36 8.1.5 Model Driven Architecture ............................................................................ 38 8.2 Prozessmodelle .................................................................................................... 40 8.2.1 Phasenmodell ................................................................................................. 40 8.2.2 Unified Software Development Process........................................................42 8.2.2.1 Generischer Unified Process.................................................................... 42 8.2.2.2 IBM Rational Software Development Process .......................................44 8.2.3 V-Modell XT ...................................................................................................45 8.2.4 Agile Prozessmodelle .................................................................................... 48 8.2.4.1 Extreme Programming ........................................................................... 49 8.2.4.2 Crystal ...................................................................................................... 52 8.2.5 Cleanroom Development Process .................................................................54 9 Projektdurchführung und Projektsteuerung.............................................................. 57 9.1 Projektplanung und -überwachung .....................................................................58 9.2 Schätzungen und Messungen ..............................................................................59 9.3 Risikomanagement .............................................................................................. 60 9.4 Dokumentation ................................................................................................... 64 TEIL IV ENTWICKLUNG EINES PLATTFORMÜBERGREIFENDEN ELEKTRONISCHEN TAGEBUCHS .......................................................................................................... 66 10 Anforderungsdefinition ............................................................................................ 66 11 Bestimmung der Projektparameter ............................................................................ 67 11.1 Kostenminimierung des Projekts .........................................................................67 11.2 „Rollen und Teams“ im Projekt ...........................................................................67 11.3 Festlegen des Softwareentwicklungsprozesses .................................................. 68 11.3.1 Einsatz von Code and Fix .............................................................................. 68 11.3.2 Einsatz des Wasserfallmodells ..................................................................... 68 11.3.3 Einsatz der iterativ-inkrementellen Entwicklung ....................................... 68 11.3.4 Einsatz des Spiralmodells ............................................................................. 69 11.3.5 Einsatz der Model Driven Achritecture ....................................................... 69 11.3.6 Einsatz des Phasenmodells .......................................................................... 69 Seite 3

Methoden des Projektmanagements in moderner Softwareentwicklung

11.3.7 Einsatz des Unified Process ...........................................................................70 11.3.8 Einsatz des V-Modell XT ...............................................................................70 11.3.9 Einsatz agiler Prozessmodelle .......................................................................70 11.3.10 Einsatz des Cleanroom Development Process ............................................70 11.3.11 Entscheidung 체ber den Einsatz eines Softwareentwicklungsprozesses ..... 71 12 Realisierung ..................................................................................................................71 12.1 Projektplanung ..................................................................................................... 71 12.1.1 Vorkonzeption ................................................................................................ 71 12.1.2 Risikomanagement im Projekt ...................................................................... 73 12.1.2.1 Unbekannte Technologie: Flash-Video-Format..................................... 73 12.1.2.2 Design-Probleme: Unentdeckte Fehler durch mangelndes Feedback ........................................................................................................... 74 12.1.2.3 Qualit채tsproblem: Entwicklerpr채gung .................................................. 74 12.1.3 Arbeitspakete ................................................................................................. 75 12.1.4 Abh채ngigkeiten..............................................................................................76 12.1.5 Iterationsplan ................................................................................................ 79 12.1.5.1 Spiralmodell Umlauf 1 ............................................................................. 79 12.1.5.2 Spiralmodell Umlauf 2 ............................................................................ 79 12.1.5.3 Spiralmodell Umlauf 3 ........................................................................... 80 12.1.5.4 Spiralmodell Umlauf 4 ........................................................................... 80 12.1.5.5 Weitere Iterationen................................................................................ 80 12.2 Umsetzung des Projektplans .............................................................................. 80 12.2.1 Machbarkeitsstudie ...................................................................................... 80 12.2.1.1 Flash-Video-Format Konverter ............................................................... 81 12.2.1.2 Webserverkonfiguration ......................................................................... 81 12.2.1.3 Flash-Video-Player .................................................................................. 85 12.2.1.4 Ergebnis .................................................................................................. 86 12.2.1.5 Schlussfolgerung .................................................................................... 86 12.2.2 Realisierung der verbindlichen Merkmale.................................................. 86 12.2.2.1 Objektorientierter Entwurf .................................................................... 87 12.2.2.2 Datenhaltung ......................................................................................... 88 12.2.2.3 Implementierung ................................................................................... 90 12.2.3 Abschluss der Implementierung und Freigabe .......................................... 94 12.2.3.1 Unbekannte Technologie: Flash-Video-Format .................................... 95 12.2.3.2 Design-Probleme: Unentdeckte Fehler durch mangelndes Feedback ........................................................................................................... 95 Seite 4

Methoden des Projektmanagements in moderner Softwareentwicklung

12.2.3.3 Qualitätsproblem: Entwicklerprägung .................................................. 95 12.2.4 Lauffähiges Programm..................................................................................95 TEIL V RESÜMEE UND AUSBLICK ................................................................................. 97 TEIL VI ABKÜRZUNGSVERZEICHNIS ............................................................................ 99 TEIL VII ANHÄNGE ................................................................................................. 100 13 Anhang A: Pflichtenheft des plattformübergreifenden elektronischen Tagebuchs .................................................................................................................. 100 13.1 Zielbestimmung .................................................................................................. 100 13.1.1 Verbindliche Merkmale................................................................................ 100 13.1.2 Optionale Merkmale ..................................................................................... 101 13.1.3 Abgrenzungskriterien ................................................................................... 101 13.2 Einsatz ................................................................................................................. 101 13.2.1 Anwendungsbereich ..................................................................................... 101 13.2.2 Zielgruppen .................................................................................................. 101 13.2.3 Betriebsbedingungen ................................................................................... 101 13.3Umgebungsanforderungen................................................................................. 102 13.3.1 Software ........................................................................................................ 102 13.3.1.1 Entwicklungsrechner ............................................................................. 102 13.3.1.2 Clientrechner ......................................................................................... 102 13.3.1.3 Serverrechner......................................................................................... 102 13.3.2 Hardware ..................................................................................................... 103 13.3.2.1 Entwicklungs- und Serverrechner .........................................................103 13.3.2.2 Clientrechner .........................................................................................103 13.3.3 Organisatorisches ........................................................................................ 103 13.4 Funktionalität .................................................................................................... 103 13.4.1 Verbindliche Merkmale ............................................................................... 103 13.4.1.1 Pflege und Ansicht der Inhalte ..............................................................103 13.4.1.2 Plattformübergreifende Nutzung......................................................... 104 13.4.2 Optionale Merkmale ................................................................................... 105 13.4.2.1 Passwortschutz für den Einzelbenutzer (Singleuser) ......................... 105 13.4.2.2 Veröffentlichung von multimedialen Inhalten über Mobiltelefone ................................................................................................. 105 13.4.2.3 Export der Inhalte auf einen Datenträger ........................................... 105 13.5 Daten .................................................................................................................. 105 13.6 Performanz......................................................................................................... 105 13.7 Grafische Benutzungsoberfläche ...................................................................... 106 Seite 5

Methoden des Projektmanagements in moderner Softwareentwicklung

13.8 Qualitätsziele ..................................................................................................... 109 14 Anhang B: Bildschirmfotos der Anwendung ............................................................ 110 14.1 Anzeige der Einträge ........................................................................................... 110 14.2 Neuanlegen eines Audioeintrags ....................................................................... 112 14.3 Editieren eines Texteintrags............................................................................... 114 14.4 Editieren eines Videoeintrags ............................................................................ 116 TEIL VIII QUELLENVERZEICHNIS ............................................................................... 118 15 Literatur...................................................................................................................... 118 16 Internet-Quellen ........................................................................................................ 119 TEIL IX ERKLÄRUNG ............................................................................................... 120

Seite 6

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL I VORWORT 1 „AUF

DEN

SCHULTERN

VON

GIGANTEN”

Mit dem Gleichnis „Auf den Schultern von Giganten“ 1 bezeichnete der Soziologe Robert K. Melton das Prinzip des wissenschaftlichen Arbeitens. Es drückte metaphorisch aus, dass neue Arbeiten auf den wissenschaftlichen Erkenntnissen früherer Generationen aufbauen können und sollten.

2 SPRACHLICHE BESONDERHEITEN In der deutschsprachigen Fachliteratur wird heterogen mit fremd-, zumeist englischsprachigen, Fachbegriffen umgegangen. Einige Autoren vermeiden deren Anwendung fast durchgehend. Sie sprechen dann von Wanzen (engl. „Bug“) für Softwarefehler oder von Programmcode-Übersetzern (engl. „Compiler“). Eine andere Gruppe von Autoren verhält sich gegenteilig und verwendet auch englischsprachige Ausdrücke außerhalb von Fachbegriffen.

In der vorliegenden Thesis werden allgemein anerkannte deutsche Fachwörter im deutschen belassen und fremdsprachliche Fachbegriffe zwar erklärt (bzw. übersetzt), jedoch anschließend konsequent in ihrer Originalsprache verwendet.

Fremdsprachliche Fachwörter, die noch keinen Einzug in deutsche Wörterbücher gehalten haben werden bewusst nicht eingedeutscht. So wird beispielsweise auf das typische Präfix „s“ bzw. „es“ der Flexion im Genitivus Subjektivus verzichtet (z. B. „Eingenschaften des Component Model“, jedoch „Vorteile des Managements“).

Abkürzungen werden nur bei ihrer ersten Verwendung kurz erläutert und danach in ihrer

Kurzform

verwendet.

Eine

Übersicht

bietet

der

Abschnitt

„Teil

VI

Abkürzungsverzeichnis“ am Ende dieser Thesis.

Rollenbezeichnungen werden grundsätzlich in ihrer geschlechtsneutralen Grundform verwendet. Dies soll keineswegs Präferenz einer männlichen Besetzung suggerieren, sondern die Lesbarkeit erhöhen. Ausnahmslos jede Rolle kann sowohl von Frauen als auch von Männern verkörpert werden.

1

Robert K. Merton, „On the Shoulders of Giants “, OTSOG, 1965 Seite 7

Methoden des Projektmanagements in moderner Softwareentwicklung

3 DANK Mein besonderer Dank gilt Herrn Prof. Dr. Zeppenfeld für die Unterstützung während des Studiums am IT-Center Dortmund und die Betreuung während der Erstellung dieser Thesis. Außerdem bedanke ich mich bei Sylvia Fähling, die durch das Lektorat dieser, für sie fachfremden Thesis die formale Qualität verbessert hat.

Schließlich danke ich Georg Petzinka und dem gesamten Team der Firma „medomus Technologien & Services“ in Dortmund und Köln, bei der ich mein Wissen in den letzten sieben Jahren mit praktischen Erkenntnissen und neuen Perspektiven bereichern durfte.

Seite 8

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL II EINLEITUNG 4 MOTIVATION Seit die ersten Programme in der Mitte des 20. Jahrhunderts erstellt wurden, nahm der Einsatz von immer komplexer werdender Hardware und Software stetig zu. In den 1970er Jahren stellte George Moore, Chef der Firma Intel, fest, dass die Leistungsfähigkeit der Hardware exponentiell wuchs. Er bemerkte, dass sie sich etwa alle 18 Monate verdoppelt 2 . Durch diesen Umstand wuchsen gleichsam die Einsatzmöglichkeiten von Datenverarbeitungssystemen und somit der Bedarf an Software.

Einzelne Softwareprojekte wurden immer größer und realisierten ständig komplexere Funktionalität. Software gilt heute als eines der komplexesten Gebilde, die der Mensch jemals zustande gebracht hat (vgl. [OES01]).

Große und / oder komplexe Softwareprojekte sind von einem einzelnen Menschen nicht mehr überschau- oder lösbar. Erst das Mitwirken vieler Menschen macht die Entstehung solcher Software realisierbar. Ein einzelner Mitarbeiter muss bzw. kann inzwischen nicht mehr alle Details eines Projekts kennen. Aus diesem Grunde ist es notwendig einem Projekt eine übergeordnete Organisation, ein „Projektmanagement“, zu geben, um nach dem Prinzip „Teile und herrsche!“

eine Lösung arbeitsteilig

realisieren zu können.

Durch moderne Instrumente und Techniken des Projektmanagements lassen sich selbst hochkomplexe Softwareprojekte ökonomisch und qualitativ hochwertig realisieren, die Risiken minimieren und der Entwicklungsprozess optimieren.

Die

vorliegende

Thesis

Projektmanagements Veröffentlichungen

in der

beleuchtet der

aktuelle

Erkenntnisse

Softwareentwicklung.

Bereiche

Sie

Software-Engineering,

Architekturen, IT-Sicherheit und IT-Recht.

2

In der Literatur wird dieser Zusammenhang als „Moore’s Law“ bezeichnet.

Seite 9

und

Modelle des

stützt

sich

auf

objektorientierter

Methoden des Projektmanagements in moderner Softwareentwicklung

5 ÜBERBLICK Im folgenden Teil „Teil III Projektmanagement in der Softwareentwicklung“ werden verschiedene Lösungsansätze und wichtige Gesichtspunkte für Softwareprojekte betrachtet. Besonders die Gedanken von Ludewig und Lichter ([LUD07]) sowie Oesterreich et al. ([OES01]) werden vorgestellt und in Zusammenhang zu anderen modernen Projektmanagement-Methoden gestellt.

Im

Teil „Teil IV

Entwicklung eines

plattformübergreifenden elektronischen

Tagebuchs“ werden die gesammelten Erkenntnisse praktisch auf ein Projekt angewandt und analysiert.

Zum Abschluss dieser Arbeit werden im Teil „Teil V Resümee und Ausblick“ ein kritisches Fazit gezogen und neue Tendenzen im Projektmanagement vorgestellt.

Seite 10

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL III PROJEKTMANAGEMENT IN DER SOFTWAREENTWICKLUNG 6 WIRTSCHAFTLICHKEITSASPEKTE 6 .1 Ko ste n - un d N ut ze n be gr i ff Große Softwareprojekte werden in der heutigen Zeit teilweise mit dutzenden bis hunderten Entwicklern und über viele Monate bis Jahre durchgeführt. Noch vor dem Start eines solchen Projekts müssen viele Parameter der Umsetzung, wie der Funktionsumfang, die erzielte Qualität, die eingesetzten Werkzeuge oder der Umfang und die Qualifikation des eingesetzten Personals beschlossen werden. Sowohl Auftraggeber als auch Auftragnehmer müssen die Kosten dieser Parameter mit dem Nutzen der Umsetzung des Projekts in Verbindung bringen.

Der Begriff der Kosten kann hierbei in laufende und projektbezogene Kosten auf Seiten des Auftragnehmers unterteilt werden (siehe Abbildung 1). Laufende Kosten beziehen sich unter anderem auf Gehälter, Management, Werbung, Räumlichkeiten, Rechner, Netzwerke oder Software als Teil der Infrastruktur. Projektbezogene Kosten sind unter anderem die Kosten des Zeitpersonals, Vertragskosten, Spesen oder Hardund Software als Teile des Produkts (vgl. [LUD07]).

Abbildung 1 – Beispiel für die Unterteilung der Kosten

Auf Seiten des Auftraggebers fallen die beim Auftragnehmer entstandenen Kosten und zusätzliche Kosten für eigenen Personal- und Administrationsbedarf für das Produkt an. Kosten können jedoch auf beiden Seiten auch in Form von nicht oder nicht direkt geldwerten nachteiligen Eigenschaften entstehen. Beispiele hierfür sind eine Seite 11

Methoden des Projektmanagements in moderner Softwareentwicklung

verringerte Qualität des Produkts, ein späterer Fertigstellungstermin oder eine fehlende Produkteigenschaft.

Der Nutzen des Produkts ist dagegen jeder Ăśkonomische oder nicht geldwerte Vorteil, den die Realisierung des Projekts bietet. Als Beispiele sind der Primärnutzen des Produkts (Ăœbereinstimmung zwischen Produkt und tatsächlichen Anforderungen), ein Erfahrungsgewinn des Auftragnehmers (durch die ProjektdurchfĂźhrung), ein Marktvorteil des Auftraggebers bzw. der Umsatz aus der Vermarktung des Produkts zu nennen. Nutzen lässt sich als negativer Kostenbeitrag definieren.

Die Summe aus den Kosten und den negativen Kosten (also dem Nutzen) bildet die Gesamtkosten (siehe Formel 1). Diese sollten in einem Ăśkonomischen Projekt so gering wie mĂśglich sein. đ?‘ž

đ?‘”đ?‘˜ =

r

đ?‘˜đ?‘– + i=1

đ?‘›j j=1

Formel 1 - Gesamtkosten eines Software-Produkts

Die Kosten ergeben sich aus der Summe aus den einzelnen Teilkosten đ?‘˜1 bis k q des Produkts und der Nutzen aus der Summe der einzelnen (negativen) Teilnutzen đ?‘›1 bis nr . Die Gesamtkosten đ?‘”đ?‘˜ sind die Summe der Kosten und des Nutzens. Diese kĂśnnen fĂźr den Auftraggeben und Auftragnehmer oder beide zusammen betrachtet werden.

6 .2 Ko s t e nm i ni m i er ung Ziel wirtschaftlichen Projektmanagements ist es, die Gesamtkosten eines Produkts mĂśglichst gering zu halten.

Besonders hohe und in vielen Fällen unerwartete Kosten gehen von unentdeckten oder ignorierten Risiken, Fehlern im Produkt oder mangelnder Qualität aus.

Als Risiken in einem Projekt werden alle Einflussfaktoren bezeichnet, deren Erscheinen ungewiss und deren Schaden im Falle des Auftretens signifikant ist. Risiken lassen sich arithmetisch quantifizieren. Der Risikowert đ?‘… eines Risikos mit der Eintrittswahrscheinlichkeit p und den im Schadensfall entstehenden Kosten đ??ž lässt sich Ăźber das Produkt aus đ?‘? und đ??ž quantifizieren (siehe Formel 2).

Seite 12

Methoden des Projektmanagements in moderner Softwareentwicklung

đ?‘… = đ?‘? ∙đ??ž Formel 2 - Quantifizierung eines Risikos

Dabei gelten Risiken mit sehr groĂ&#x;en Kosten đ??ž als extreme Risiken und Risiken mit groĂ&#x;er Eintrittswahrscheinlichkeit đ?‘? als inakzeptable Risiken. Die kritischen Werte fĂźr đ?‘? und đ??ž variieren dabei je nach Projektumfang.

Risiken kĂśnnen beispielsweise die mĂśgliche KĂźndigung eines erfahrenen Mitarbeiters, technische HĂźrden oder auch fehlende oder mangelhafte Anforderungen an das Produkt sein. Feyl ([FEY04]) demonstriert die praktische Quantifizierung von Projektrisiken mittels Checklisten, die viele der bekannten Risiken enthalten.

Diese Risiken kĂśnnen durch geeignete GegenmaĂ&#x;nahmen minimiert werden. Dazu sei an dieser Stelle auf den Abschnitt „9.3 Risikomanagement“ verwiesen.

Bekannt werdende Fehler während der Software-Entwicklung sind eine besondere Ausprägung eines Risikos. Grundsätzlich kann von der Existenz von Fehlern im Laufe eines Software-Projekts stets ausgegangen werden. Fehler kÜnnen je nach Schweregrad und Zeitpunkt ihrer Entdeckung und Beseitigung unterschiedlich gravierende Auswirkungen auf die Wirtschaftlichkeit eines solchen Projekts haben.

Die Entdeckung eines Fehlers direkt oder kurz nach seiner Entstehung gilt allgemein als unkritisch. Denn zu diesem Zeitpunkt basieren noch keine oder nur sehr wenige weitere Aktivitäten auf dem fehlerhaften Arbeitsergebnis. So entstehen zwar Kosten fßr die Korrektur des Fehlers, jedoch ist der Schaden auf den Bereich des Auftretens begrenzt.

Doch Fehler werden häufig erst auf derselben Abstraktionsebene entdeckt, auf der sie entstanden sind (siehe Abbildung 2). Ein Fehler in der Analyse (z. B. in der Definition der benÜtigten Programmeigenschaften) wird dann beispielsweise erst im Betrieb als fehlende Funktion entdeckt.

Seite 13

Methoden des Projektmanagements in moderner Softwareentwicklung

t

Fehlerentdeckung

Analyse

Betrieb

Fehlerentdeckung

Spezifikation

Installation

Fehlerentdeckung

Entwurf

Fehlerentdeckung

Codierung

Eingabe

Fehlerentdeckung

Integration

Modultest

Übersetzung

Abbildung 2 - Entdeckung von Fehlern auf derselben Abstraktionsebene (vgl. [LUD07])

Das Ausmaß, sprich die Kosten für die Beseitigung eines solchen Fehlers sind unverhältnismäßig höher, da alle Aktivitäten zwischen der Entstehung des Fehlers und seiner Entdeckung und Beseitigung auf dem fehlerhaften Zwischenergebnis aufgebaut haben und somit ebenfalls nicht mehr korrekt sind. So müssen im o. g. Beispiel eines Analysefehlers, der im Betrieb entdeckt wird, neben der Korrektur der Analyse auch die Spezifikation, der Entwurf, die Codierung, die Eingabe, die Übersetzung, die dazugehörigen Modultests, die Integration und Installation entsprechend überarbeitet oder neu durchgeführt werden. Durch die Fehlerbeseitigung können jedoch neue Fehler (in den reparierten Bereichen) entstehen oder zuvor funktionierende Module negativ beeinflusst werden und dort ebenfalls Änderungen indizieren. Die Kosten der Fehlerbeseitigung steigen exponentiell zwischen dem Entstehen und der Beseitigung des Fehlers. Aus diesem Grunde sind dringend entsprechende Gegenmaßnahmen zu treffen um die Identifikation von Fehlern an einem möglichst frühen Zeitpunkt im Projektverlauf

zu verlagern. Methoden zur Erreichung dieses Ziels werden im

Abschnitt „9.3 Risikomanagement“ dargestellt.

Im

Bezug

auf

Kostenminimierung

spielt

mangelnde

Qualität

eines

Softwareprodukts besonders im Bezug auf Änderbarkeit und Wartbarkeit eine besondere Rolle. Ludewig und Lichter stellen 2007 fest, dass der Aufwand für die Wartung eines Softwareprodukts, d. h. Anpassung an aktuelle Rahmenbedingungen, Verbesserungen und Korrekturen, ebenso hoch bis doppelt so hoch ist, wie die Entwicklung selbst (vgl. [LUD07], siehe Abbildung 3). Platz ging 1983 sogar davon aus Seite 14

Methoden des Projektmanagements in moderner Softwareentwicklung

(vgl. [PLA83]), dass diese Kosten zwischen den doppelten und vierfachen Entwicklungskosten liegen. Die Reduzierung dieser Schätzung in der heutigen Zeit ist durch moderne Wartbarkeit

Entwicklungsprozesse zu begründen, die die Änderbarkeit und

von

Software

Softwareentwicklungsprozesse“),

stark da

begünstigen

diese

Faktoren

(siehe sich

Abschnitt direkt

auf

„8 den

Wartungsaufwand auswirken.

Entwicklung Wartung

Abbildung 3 - Mögliche Kostenverhältnisse zwischen Entwicklung und Wartung (vgl. [LUD07])

7 ROLLEN

UND

TEAMS

7.1 Mo de l l de r Mo ti va ti o n Die Produktivität einzelner Softwareentwickler schwankt sehr stark. In der Literatur werden diese Schwankungen mit einem Faktor von 10 bis 12 angegeben. Das heißt, dass ein sehr guter Entwickler eine Aufgabe in einem Tag löst, für die ein sehr schlechter Entwickler mehr als zwei Wochen benötigt (vlg. [OES01] und [LUD07]).

Die Leistungsbereitschaft eines Mitarbeiters hat direkten Einfluss auf die Produktivität und lässt sich durch ein mengentheoretisches Modell der Motivation beschreiben.

Jedes Element einer Menge sei eine spezielle Tätigkeit.

Seite 15

Methoden des Projektmanagements in moderner Softwareentwicklung

A Fähigkeiten des Mitarbeiters B Handlungsbereitschaft des Mitarbeiters

C Hohe Motivation des Mitarbeiters

D Anerkennung und Honorierung durch die Umgebung

Abbildung 4 - Modell der Motivation (vgl. [LUD07])

Die Fähigkeiten eines Projektmitarbeiters seien durch die Menge đ??´ beschrieben (siehe Abbildung 4). Ihr gehĂśren alle Aktivitäten an, zu denen dieser Mensch in der Lage ist.

Alle Aufgaben auĂ&#x;erhalb der Menge đ??´ beherrscht der Mitarbeiter nicht oder nicht gut.

Aufgaben, die der Mitarbeiter auch tatsächlich bereit ist zu tun, sind Bestandteil der Menge đ??ľ. Alle Tätigkeiten auĂ&#x;erhalb von đ??ľ wird er somit oftmals nicht durchfĂźhren, da er sie nur ungern tut.

In einer Menge đ??ś sind alle Aufgaben der Person enthalten, die er mit hoher Motivation, sprich mit Freude lĂśst.

In der Regel gilt đ??ś ⊆ đ??ľ ⊆ đ??´, d. h. ein Mitarbeiter widmet sich den Tätigkeiten gern, die er beherrscht. SchlieĂ&#x;lich befinden sich in der Menge đ??ˇ Aktivitäten, die von der Umgebung durch Anerkennung honoriert werden.

Im Arbeitsalltag wird ein Mitarbeiter sich stets auf jene Arbeiten konzentrieren, die ihm SpaĂ&#x; machen, oder die er zu tun bereit ist und die gleichzeitig anerkannt werden.

So definieren sich die tatsächlichen

Tätigkeiten

eines Menschen im

Unternehmen als đ??ś âˆŞ (đ??ľ ∊ đ??ˇ).

7.1.1 Charakterisierung von Leistungstypen Ein arbeitssĂźchtiger Mitarbeiter (engl. Workaholic) weist in diesem Modell eine sehr groĂ&#x;e Schnittmenge zwischen đ??ś und đ??ˇ auf. Aufgaben, die er mit Freude erfĂźllt bescheren ihm zusätzlich Anerkennung. Es gibt fĂźr diesen Menschen keinen Grund etwas anderes zu tun.

Seite 16

Methoden des Projektmanagements in moderner Softwareentwicklung

Ein nur leistungsschwacher oder gar unfähiger Mitarbeiter weist grundsätzlich entweder eine nur sehr kleine Menge đ??ľ auf und/oder die Schnittmenge zwischen đ??ľ und đ??ˇ ist nur sehr gering.

Ein Mensch bei dem, anders als in diesem Modellbeispiel, dem đ??ľ oder đ??ś auĂ&#x;erhalb von đ??´ liegt, gibt sich einer Selbsttäuschung hin und erfĂźllt zum Teil mit Freude Aufgaben, zu denen er nicht qualifiziert ist. Als Beispiel kann ein Entwickler genannt werden der sehr gerne, jedoch auch schlecht programmiert.

7.1.2 Managementstrategie zur MotivationserhĂśhung Die o. g. Schnittmenge der tatsächlichen Tätigkeiten eines Mitarbeiters đ??ś âˆŞ đ??ľ ∊ đ??ˇ sollte grundsätzlich mĂśglichst gut mit den Erfordernissen des Unternehmens in Deckung gebracht werden. Um dieses Ziel zu erreichen gibt es einige Ansätze, die vom Management konsequent verfolgt werden sollten.

Zunächst ist es wichtig, die Menge đ??ˇ, der anerkannten Tätigkeiten mĂśglichst nah an die tatsächlichen BedĂźrfnisse des Unternehmens anzugleichen.

Ludewig und Lichter ([LUD07]) geben das Beispiel eines Projektleiters, der sein Projekt schlecht leitet und es fast scheitern lässt, ehe er es in letzter Sekunde rettet. Die Anerkennung der Kollegen ist groĂ&#x;, obwohl der Verlauf des Projekts nicht im Sinne der Unternehmung sein kann.

Um dieses Ziel zu erreichen kĂśnnen besondere Auszeichnungen (z. B. der Titel „Mitarbeiter des Monats“) oder die Anerkennung des Managements helfen. AuĂ&#x;erdem sollte jedem Mitarbeiter klar gemacht werden, welche Erfordernisse das Unternehmen stellt und welches Verhalten erwĂźnscht ist. Dies macht es den Mitarbeitern auch untereinander einfacher zu erkennen welche Aktivtäten anerkennungswĂźrdig sind.

Eine weitere MÜglichkeit die tatsächlichen Aktivitäten eines Mitarbeiters an die Unternehmensansprßche anzupassen besteht darin die Mitarbeiter gezielt zu Schulen und damit zu versuchen, das Selbstvertrauen des Menschen zu stärken, so dass er das neu Erlerne auch gerne umsetzt.

Seite 17

Methoden des Projektmanagements in moderner Softwareentwicklung

7. 2 R o l l e n un d V er a nt w or tl i chk ei te n An der Umsetzung eines Softwareprojekts sind verschiedene Organisationseinheiten und Personen beteiligt. Die wichtigsten werden in den folgenden Teilabschnitten charakterisiert (siehe Abbildung 5).

Abbildung 5 - Rollen und Verantwortlichkeiten

7.2.1 Auftraggeber Eine Person oder Organisation, die die Konstruktion eines Softwareprodukts veranlasst, wird hier als Auftraggeber bezeichnet. Der Auftraggeber muss nicht zum Kreis der Benutzer gehören.

7.2.2 Auftragnehmer Als Auftragnehmer wird die Person oder Organisation, die mit der Entwicklung des Produkts betraut wird, bezeichnet. In speziellen Fällen können Auftraggeber und Auftragnehmer auch derselben Organisation angehören. Dies ist der Fall, wenn eine organisationsinterne Software entwickelt werden soll.

7.2.3 Fachreferent Bei der Softwareentwicklung werden regelmäßig Systeme für verschiedene fachliche Abläufe (z. B. medizinische Software oder Buchhaltungssoftware) von fachfremden Softwareentwicklern konstruiert. Der Auftragnehmer überschaut häufig anfänglich die Seite 18

Methoden des Projektmanagements in moderner Softwareentwicklung

fachlichen Erfordernisse nicht oder ist Laie. Daher ist es wichtig die fachlichen Anforderungen gezielt zum Entwicklerteam des Auftragnehmers zu transferieren.

Der sog. Fachreferent (engl. „Key-User“) definiert, stellvertretend für die Benutzer des Produkts, die fachlichen Anforderungen zusammen mit dem Auftragnehmer. Es kann sich

dabei

um

einen

fachkundigen

Mitarbeiter

des

Auftraggebers,

einen

Sachverständigen oder auch um einen Vertreter der Benutzer handeln. Er steht dem Auftragnehmer sowohl zu Anfang des Projekts, als auch während der gesamten Realisierungsphase für fachliche Fragen und Probleme bereit. Je nach Projektgröße können auch mehrere Fachreferenten bestellt werden.

7.2.4 Benutzer Die Gruppe der Benutzer stellt die Zielgruppe des Softwareprodukts dar. Ein Benutzer gehört organisatorisch nicht zwingend zum Auftraggeber. So kann ein Unternehmen beispielsweise eine Software für Marketingzwecke zur Akquise neuer Kunden des Auftraggebers (Benutzer) beauftragen.

7.2.5 Projektleitung 7.2.5.1 Charakterisierung und Bedeutung Der Projektleiter hat die volle Verantwortung für die Umsetzung eines Projekts inne.

Er ist verantwortlich für die Mitarbeiter und ihre Leistungen, die zum Projekt gehörigen Termine, die Kosten und die Qualität des Produkts. Durch sein Handeln beeinflusst er direkt, ob das Projekt erfolgreich endet oder nicht.

Ein Projektleiter kann auch Weisungsbefugnis haben, die jedoch in der Regel zeitlich begrenzt und projektbezogen ist.

In der Literatur werden dem Projektleiter auch gewisse psychologische oder soziologische Fertigkeiten abverlangt. Er ist in der schwierigen Situation, mit dem zu entwickelnden Softwareprodukt bei den Benutzern nicht immer auf Akzeptanz zu stoßen, denn die Einführung eines solchen Produkts hat immer mit Veränderungen in den beim Benutzer bekannten Abläufen und nicht selten auch mit betrieblichen Rationalisierungsmaßnahmen und Stellenstreichungen zu tun.

Der Auftraggeber, der Auftragnehmer, der Fachreferent, die Benutzer und das Entwicklerteam haben zum Teil höchst unterschiedliche Auffassungen der Ziele des Seite 19

Methoden des Projektmanagements in moderner Softwareentwicklung

Projekts. Die Aufgabe des Projektleiters ist, es die Interessen aller Beteiligen zu erfassen und in einem Projekt zu vereinen.

7.2.5.2 Aufgaben Der Projektleiter ist während des gesamten Projekts mit verschiedenartigen Aufgaben betraut. Allen gemeinsam ist es zu versuchen, das Projekt möglichst kosteneffizient und erfolgreich zu beenden. Dieses Ziel sollte konstant und durchgängig angestrebt werden, um Situationen zu vermeiden, in denen der erfolgreiche Projektausgang ungewiss ist.

Zu Anfang eines jeden Softwareprojekts ist es die Aufgabe des Projektleiters, das Projekt im Vorfeld zu planen. Zunächst werden grobe Aufgabenblöcke geplant, die die wichtigsten Aufgaben des Projekts bezeichnen. Diese werden in einem nächsten Schritt in weitere Teilaufgaben aufgeteilt. Dieses Vorgehen wird dann wiederholt, bis die Granularität auf die Ebene von Arbeitspaketen verfeinert wurde. Ein Arbeitspaket

kann

durchgängig

bearbeitet

werden,

ist

in

sich

frei

von

Koordinationszwängen, hat einen definierten Anfangs- und Endpunkt und kann außerdem in Bezug auf Aufwand und Fertigstellungstermin abgeschätzt werden.

Zwischen Arbeitspaketen können verschiedene Arten von Abhängigkeiten bestehen (siehe Abbildung 6), die der Projektleiter zuweist. Eine sogenannte Ende-AnfangBeziehung zwischen

zwei Arbeitspaketen liegt vor, wenn die Bearbeitung des

zweiten Arbeitspakets erst nach der vollständigen Beendigung des Ersten begonnen werden kann. Dagegen kennzeichnet eine Anfang-Anfang-Beziehung den gleichzeitigen Beginn und eine Ende-Ende-Beziehung den gleichzeitigen Abschluss zweier Arbeitspakete.

Seite 20

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 6 - Grafische Darstellung von Abhängigkeiten Zwischen Arbeitspaketen in Form eines sog. „GanttCharts“

Außerdem werden jedem Arbeitspaket Mitarbeiter zugewiesen, die es bearbeiten und Prioritäten und Meilensteine gesetzt. Ein Meilenstein wird zur Projektplanung und Überwachung genutzt. Er besitzt zwei Zustände: nicht erreicht oder erreicht. Seine Erreichung hängt von der Fertigstellung eines oder mehrerer Arbeitspakte ab. Auch das sog. „Release“ (Veröffentlichung des Produkts) kann als Meilenstein betrachtet werden, der sämtliche Arbeitspakete, die zur Erstellung des Produkts benötigt werden, voraussetzt. Arbeitspakete können jedoch auch durch eine der o. g. Beziehungen von Meilensteinen

abhängen.

Dabei

können

auch

externe

Meilensteine,

d.

h.

Rahmenbedingungen, auf die der Projektleiter keinen direkten Einfluss nimmt, eine Rolle spielen. So kann beispielsweise mit der Lokalisierung (mehrsprachige Realisierung) der Anwendung erst begonnen werden, wenn ein Übersetzungsbüro die dazu notwendigen Texte liefert.

Als „kritischen Pfad“ bezeichnet man alle Arbeitspakete, deren Verzögerung sich direkt auf einen Meilenstein auswirkt und dessen Erreichen ebenfalls verzögert. Projektleiter sollten darauf achten, kritische Pfade in der Planung der Projekte zu vermeiden. Dies kann z. B. durch Pufferzeiten zwischen den Arbeitspaketen oder Parallelisierung von Arbeitspaketen erfolgen.

Sämtliche, auf diese Weise geplanten Aufgaben, werden in einen Projektplan eingetragen und dienen als Grundlage der Berechnung der Releases und des Seite 21

Methoden des Projektmanagements in moderner Softwareentwicklung

Projektaufwands. Als Projektaufwand werden in diesem Zusammenhang die benötigten Ressourcen (Mitarbeiter, Hard- und Software) und die entstehenden Kosten bezeichnet.

Der

Projektplan wird während der gesamten Projektlaufzeit vom Projektleiter

regelmäßig aktualisiert und den aktuellen Gegebenheiten angepasst. Dabei sollte grundsätzlich die kurzfristige Planung einen

hohen Detaillierungsgrad aufweisen,

während die langfristige Planung eine gröbere Granularität erlaubt.

Der Projektleiter überwacht und kontrolliert das Projekt beständig. Dabei achtet er darauf, ob kritische Pfade entstehen, ob Meilensteine fristgerecht eingehalten werden und ob es zu Verzögerungen kommt. Grundlage für diese Projektüberwachung sind jedoch aktuelle Daten über die der Projektfortschritt objektiv erfasst werden kann. In der Praxis sind die Mitarbeiter oft dafür verantwortlich, die von ihnen geleisteten Arbeiten selbst quantifizierbar zu dokumentieren. Der Projektleiter sichtet diese Daten und steuert das Projekt entsprechend.

Die Kommunikation zwischen dem Auftraggeber, dem höheren Management des Auftragnehmers und den Projektmitarbeitern erfolgt in der Regel über den Projektleiter. Er vermittelt und versucht, das Projekt in für alle Beteiligten akzeptable Bahnen zu steuern. Dabei sollte der Projektleiter jeden einzelnen anhören und im Sinne des Projekts Entscheidungen treffen.

Der

Projektleiter

schafft

und

erhält

während

der

Projektlaufzeit

günstige

Rahmenbedingungen für die Entwickler. Er achtet darauf, dass ein konzentriertes und ungestörtes Arbeiten in einem guten Arbeitsklima möglich ist und schirmt die Projektmitarbeiter weitestgehend vom übrigen Alltagsgeschäft ab, damit sie sich voll auf das Projekt konzentrieren können. Ferner fördert er die Offenheit der Mitarbeiter, damit Schwierigkeiten schnell kommuniziert werden. Schließlich nimmt der Projektleiter dem Entwicklerteam die Angst vor Fehlschlägen, die es möglicherweise daran hindert Entscheidungen zu treffen.

Um den Entwicklern ein zielorientiertes Arbeiten zu ermöglichen sollte der Projektleiter die Projektziele klar definieren und kommunizieren. Implizite, unausgesprochene Erwartungen der Projektleitung oder unklare, häufig wechselnde Ziele verunsichern das Entwicklerteam und behindern das Arbeiten. In einer Seite 22

Methoden des Projektmanagements in moderner Softwareentwicklung

Untersuchung (vgl. [OES01]) wurden fünf Entwicklerteams damit betraut, dieselbe Aufgabe zu lösen. Jedem Team wurde jedoch ein anderes Ziel (etwa eine kurze Entwicklungszeit, geringer Speicherverbrauch usw.) genannt, welches bei der Lösung Priorität haben sollte. Vier der fünf Teams erreichten jeweils ihr wichtigstes Ziel.

Jedoch war keines der Entwicklerteams in der Lage, mehr als zwei Ziele gleichzeitig erfolgreich zu verfolgen. Daraus lässt sich schließen, dass Entwicklerteams mit klar definierten Zielen diese zu erreichen in der Lage sind. Definierte und bekannte Projektziele steigern die Produktivität und Motivation der Mitarbeiter. Die Projektleitung sollte dabei für sich selbst Ziel der Fertigstellung des Produkts jedoch vor Detailziele der Realisierung setzen.

Von einem Projektleiter wird erwartet, Entscheidungen zu treffen. Für ihn gilt genau so wie für seine Mitarbeiter, dass Entscheidungen nicht hinausgezögert werden sollten, sondern mit Mut getroffen werden müssen. Ein Projektleiter sollte seinem Team nichts befehlen, sondern dessen Meinungen einholen, respektieren und abwägen eher er sich entscheidet.

Es ist in der Praxis nicht selten der Fall, dass Projektmitarbeiter besonders zu Beginn eines Projekts, wenn der Leistungsdruck noch gering und der Release-Termin noch weit entfernt zu sein scheint, tageweise aus dem Projekt abgezogen und mit anderen Aufgaben betraut werden. Dies passiert besonders bei guten, erfahrenen Entwicklern, die sich auch mit älteren Systemen aus früheren Projekten gut auskennen. Der temporäre Verlust eines erfahrenen Mitarbeiters ist für das Projekt jedoch zu jeder Zeit schädlich und es sollte erwogen werden in diesem Fall einen neuen Mitarbeiter mit der Wartung des früheren Projekts zu betrauen, selbst wenn er länger brauchen würde.

Der Projektleiter sollte überdies vom Anfang des Projekts an ein Gefühl der Dringlichkeit, z. B. durch zu erreichende Meilensteine in naher Zukunft bei den Mitarbeitern wecken. Dies erhöht die Produktivität und Motivation der Mitarbeiter aus dem Gefühl heraus, Teiletappen bald gemeistert zu haben.

Seite 23

Methoden des Projektmanagements in moderner Softwareentwicklung

Tabelle 1 - Beispiel einer Risikoliste (fingiert)

Die Identifikation und Bekämpfung von Risiken im Projekt sind ebenfalls Tätigkeiten, denen der Projektleiter während der gesamten Projektlaufzeit nachgeht. Dazu gehört jede Art von denkbaren Problemen und Verzögerungen im Projektablauf. So werden in der Praxis z. T. regelmäßig Listen der zehn größten Projektrisiken (größter Risikowert) erstellt (siehe Tabelle 1) und deren Eintreten unter hoher Priorität durch die Projektleitung und das Entwicklerteam verhindert. Maßnahmen zur Bewältigung von Projektrisiken sind im Abschnitt „9.3 Risikomanagement“ beschrieben.

7.2.6 Softwareentwickler Für industrielle Fertigungsanlagen werden Maschinen oder Herstellungsverfahren entwickelt, mit denen nach ihrer Fertigstellung die tatsächlichen Produkte produziert werden können. Bei der Erstellung von Software ist diese Unterscheidung nicht möglich. Die „Produktion“, sprich die Vervielfältigung, ist nun mit sehr geringem Aufwand verbunden. Dagegen stellt die Entwicklung eines Softwareprodukts selbst bereits das Produkt dar. Dieses kann jedoch jederzeit weiter modifiziert werden. Daher Seite 24

Methoden des Projektmanagements in moderner Softwareentwicklung

wird im Allgemeinen häufiger von Softwareentwicklung statt Softwarekonstruktion oder –produktion gesprochen.

Menschen die an der technischen Realisierung dieser Softwareentwicklung beteiligt sind werden als Softwareentwickler bezeichnet. Sie erarbeiten die Softwarearchitektur, definieren Schnittstellen und implementieren Klassen und Komponenten der Software.

Die Entwickler gehören dem Projektteam unter der Führung des Projektleiters an.

Durch die beschriebene Komplexität der Projekte und die übliche Bearbeitung in Gruppen gehört die Teamfähigkeit in der heutigen Zeit bei Softwareentwicklern zu den in der Praxis häufig geforderten Eigenschaften.

7.3 Te a m str ukt ur e n Die passende Zusammensetzung des Entwicklerteams und die geeignete Verteilung der Aufgaben an die Mitarbeiter sowie die Zusammenarbeit der Menschen im Team gelten als ausgesprochen wichtig für den Erfolg eines Softwareprojekts. In der Praxis werden die Projektmitarbeiter oft nicht vom Projektleiter selbst, sondern vom Management des Auftragnehmers ernannt.

Dem Projektleiter obliegt daher die Aufgabe sein Team in sich zu organisieren, um den Projekterfolg zu gewährleisten. Dabei kann zwischen der eigentlichen soziologischen Organisation des gesamten Teams und speziellen Entwicklergruppen, die mit der Lösung bestimmter Aufgaben betraut sind, innerhalb dieser Organisation unterschieden werden.

7.3.1 Teamorganisation Zur Erarbeitung einer Lösung eines großen und komplexen Softwareprojekts kann es sinnvoll sein, das Projektteam in mehrere Teams zu unterteilen. Jedes Team sollte bestimmte Arbeitspakete bearbeiten und aus ca. fünf bis sieben Personen zusammengesetzt sein. Ein solches Team kann wiederum einen Verantwortlichen, einen sog. Teilprojektleiter, besitzen.

7.3.1.1 Einzelpersonen und kleine Gruppen In der Praxis arbeiten nicht selten einzelne Mitarbeiter an einem Problem (siehe Abbildung 7). Dies passiert insbesondere bei Arbeitspaketen die sich nicht sinnvoll auf mehrere Personen verteilen lassen. Der Vorteil dieser Praxis ist, dass ein einzelner Seite 25

Methoden des Projektmanagements in moderner Softwareentwicklung

Mitarbeiter keinerlei Mehraufwand durch Kommunikation verursacht. Dies impliziert jedoch auch einen direkten Nachteil, denn der Mangel an Kommunikation verhindert die Besprechung des vom Entwickler gewählten Lösungsweges und macht so Kritik in Bezug

auf

Verbesserungsvorschläge,

Mängel

und

Fehler

unmöglich.

Das

Arbeitsergebnis ist stark vom Entwickler geprägt und für Dritte oft nur schwer verständlich. Auf diese Weise können unnötige Folgekosten bei der späteren Wartung entstehen. Es ist empfehlenswert auch bei Arbeiten von einzelnen Entwicklern regelmäßige Reviews (Durchsichten, Prüfungen und Kritiken) der Ergebnisse durch andere Entwickler einzuführen.

Abbildung 7 - Kleine Entwicklergruppe

Arbeiten zwei Entwickler an einer Lösung so kann dies in sich drei verschieden Ausprägungen der Zusammenarbeit haben. Erstens kann dem Entwickler ein Assistent für die Delegation von Aufgaben zur Verfügung gestellt werden. Dabei obliegt die Führung der zweiköpfigen Gruppe dem Entwickler, während der Assistent ausschließlich zuarbeitet. Zweitens ist eine Konstellation zum Wissensaustausch möglich, wobei der erfahrene Entwickler dem weniger erfahrenen Entwickler seine Kenntnisse übermittelt. Dies kann insbesondere zur Entlastung des erfahrenen Entwicklers im Anschluss an den Wissenstransfer dienen. Drittens können zwei Softwareentwickler auch als gleichberechtigtes Team auftreten und die Bearbeitung der Arbeitspakete gemeinsam und einvernehmlich durchführen. Dieses Vorgehen wird unter anderem beim sog. „Pair Programming“ im „Extreme Programming“ eingesetzt.

Der Abschnitt „8.2.4.1 Extreme Programming“ enthält eine Beschreibung dieses Prozessmodells.

7.3.1.2 Anarchische Teamstruktur Die Mitarbeiter eines anarchischen Teams arbeiten oftmals als eine Gruppe von Einzelpersonen zusammen (siehe Abbildung 8). Jeder einzelne bearbeitet das Projekt autonom nach seinen eigenen Vorstellungen. Hierarchische Beziehungen sind dabei nicht vorhanden oder werden missachtet.

Seite 26

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 8 - Anarchische Teamstruktur

Da die Entwickler selbstbestimmt arbeiten gibt es weder Hierarchie-Probleme, noch gibt es nennenswerte bürokratische Hürden. Normierungen und Standards lassen sich bei diesen praktisch nicht organisierten Teams nicht durchsetzen. Die Existenz und Qualität der notwendigen Arbeitsergebnisse ist mehr dem Zufall und der Stimmung im Team überlassen. Ebenso ist die Einführung neuer Methoden oder Werkzeuge vom Willen der einzelnen Mitarbeiter abhängig. Eine solche Teamstruktur findet sich in Organisationen mit sehr flacher Hierarchie oder schwacher Führungsstruktur wieder und gilt insgesamt als nicht lernfähig.

7.3.1.3 Demokratische Teamstruktur Die demokratische ähnelt der anarchischen Teamstruktur ihrem Aufbau nach, jedoch legen die Mitglieder solcher Teams ein diszipliniertes Verhalten an den Tag, indem sie sich gemeinsam auf die Ziele des Projekts verständigen. Falls kein gemeinsamer Konsens gefunden werden kann gibt es im Team eine ausgezeichnete Person die eine Entscheidung fällt oder die Ziele festlegt (siehe Abbildung 9).

Abbildung 9 - Demokratische Teamstruktur

Das Wissen und die Erfahrungen der Teammitglieder fließt in jede Entscheidung ein wobei ein Klima der Offenheit entsteht. Dies hat den Vorteil, dass Risiken frühzeitig besprochen und gemeinsam bekämpft werden. Der Kommunikationsaufwand in

Seite 27

Methoden des Projektmanagements in moderner Softwareentwicklung

solchen Teams ist jedoch verhältnismäßig hoch, da zahlreiche Diskussionen geführt werden müssen und alle Mitglieder an den Entscheidungsprozessen beteiligt sind.

7.3.1.4 Hierarchische Teamstruktur In hierarchisch organisierten Teams werden von einem Projektleiter Entscheidungen gefällt und Ziele des Projekts festgelegt. Er steht an der Spitze des Teams und plant, koordiniert, kontrolliert und steuert das Projekt (siehe Abschnitt „7.2.5 Projektleitung“, siehe Abbildung 10). Die Kommunikationsstrukturen bei dieser Teamstruktur sind einfach und es entsteht wenig zusätzlicher Kommunikationsaufwand.

Abbildung 10 - Hierarchische Teamstruktur

Jeder Mitarbeiter erhält vom Projektleiter klare Aufgaben und kann bei Bedarf leicht ausgetauscht werden. Das Mitspracherecht der Entwickler ist eingeschränkt, was sich negativ auf Motivation und Leistungsbereitschaft auswirken kann. Die gesamte Verantwortung für die Entwicklung hängt an dem Projektleiter.

7.3.1.5 Chief-Programmer- Teamstruktur Die Chief-Programmer-Teamstruktur kann als Sonderform der hierarchischen Teamstruktur verstanden werden. Der Chief-Programmer (Chefentwickler) nimmt die Rolle eines Projektleiters mit deutlich stärkerer Einbindung in technisch-konstruktive Abläufe im Projekt ein. Er ist in der Regel ein sehr erfahrener Entwickler, der in die technische Entwicklung zentral eingebunden ist. Er ist zusätzlich verantwortlich für die Architektur des Produkts und setzt besonders wichtige Teile des Systems selbst Seite 28

Methoden des Projektmanagements in moderner Softwareentwicklung

um. Er prüft beständig die Implementierungen der anderen Teammitglieder und transferiert dabei sein Wissen an das Team.

Dem Chief-Programmer können, je nach Projektgröße, ein Stellvertreter (engl.

Backup-Programmer), der ihn bei Bedarf unterstützt und ein Verwaltungsassistent (engl. Librarian), der administrative Verwaltungsfunktionen teilweise übernimmt, zur Seite stehen (siehe Abbildung 11).

Abbildung 11 - Chief-Programmer- Teamstruktur

Der Chief-Programmer fungiert dabei als gutes Vorbild für das Team und ist, da er in die technischen Projektdetails tief involviert ist, außerordentlich fachkompetent, was den Kommunikationsaufwand mindert und Entscheidungswege verkürzt. Jedoch muss der Chief-Programmer hohen Ansprüchen genügen, um seiner sehr umfangreiche Aufgabe Herr zu werden. Mit einem fähigen Chief-Programmer kann ein Team hervorragende Leistungen erzielen, während ein überforderter Chefentwickler das Projekt stark gefährdet (vgl. [LUD07]).

7.3.2 Entwicklergruppen Zur Lösung besonderer Problemstellungen innerhalb eines Projekts kann es sinnvoll sein, Entwickler in besonderen Einsatzgruppen zu organisieren, die die Aufgabe haben eine Lösung des Problems zu erarbeiten. Oersterreich et al. beschreiben drei besondere Formen von Entwicklergruppen: die kreativen Teams, die Feature Teams und die Tiger Teams (vgl. [OES01]).

7.3.2.1 Kreative Teams Kreative Teams werden einberufen um moderne Lösungen zu erarbeiten. Dabei kann es beispielsweise um neuartige Anwendungen oder Algorithmen oder auch um unkonventionelle Design-Alternativen gehen. Ideen, Theorien, Prototypen und Machbarkeitsstudien sind der zentrale Gegenstand der Arbeit dieser Gruppen. Die Seite 29

Methoden des Projektmanagements in moderner Softwareentwicklung

Mitglieder arbeiten kreativ, motiviert und autonom und verfolgen ihr Ziel hartnäckig.

Es sollte den kreativen Teams eine Umgebung geschaffen werden, in der sie Ihre Ideen ungestört, von äußeren Einflüssen, abgeschirmt ausprobieren können. Bürokratie und der Entwicklungsprozess des restlichen Projekts sollten bei der Arbeit dieses Teams so wenig Einfluss wie möglich haben. Die Ergebnisse der Aktivitäten der Gruppe werden im Anschluss in die normalen Abläufe des Projekts integriert.

7.3.2.2 Feature Teams Sogenannte Feature Teams werden für die Realisierung bestimmter Produktmerkmale eingesetzt, deren Anforderungen noch nicht klar spezifiziert und deren Realisierung noch nicht geklärt ist. Die Mitglieder kommen aus allen wichtigen Bereichen, wie Entwicklung, Marketing, Qualitätssicherung und Management. Dies befähigt das Team ein Produktmerkmal selbstständig zu realisieren und dabei Entscheidungen nach außen zu vertreten. Da die übrige Architektur des Produkts nicht durch die selbstständigen Aktivitäten des Feature Teams gestört werden darf, eignet sich die Aufbietung einer solchen Gruppe besonders bei der Erweiterung eines Produkts um neue Merkmale. Insbesondere beim Einsatz mehrerer, gleichzeitig arbeitender Feature Teams besteht die Gefahr von Schwierigkeiten während der Integration der unabhängig von einander entwickelten Produktmerkmale in das Gesamtprodukt. Sie eignen sich jedoch sehr gut, um zu vage Anforderungen eines Produktmerkmals vorerst aus der Gesamtentwicklung herauszuhalten, um diese nicht zu destabilisieren.

7.3.2.3 Tiger Teams Aufgetretene Schwierigkeiten oder Risiken im Projekt können von sog. Tiger Teams angegangen werden, die sich als Spezialeinsatzgruppen verstehen. Sie bestehen oft nur aus zwei bis fünf Personen, deren Aufgabe es ist, in möglichst kurzer Zeit (ein bis zwei Wochen) eine Lösung für ein aktuelles Problem des Projekts zu finden. Dabei sind diese Gruppen frei vom übrigen Entwicklungsprozess, da die von ihnen gefundene tragfähige

Lösungsalternative

später

mit

den

normalen

Mitteln

im

Entwicklungsprozess umgesetzt wird. Der Einsatz in Tiger Teams kann als besonderes Mittel der Motivation und Anerkennung für einen Mitarbeiter eingesetzt werden, da er dadurch seine gewohnten Tätigkeiten kurzfristig verlässt und das volle Vertrauen der Projektleitung genießt.

Seite 30

Methoden des Projektmanagements in moderner Softwareentwicklung

8 SOFTWAREENTWICKLUNGSPROZESSE Einfache Arbeiten müssen, im Gegensatz zu komplexen Aufgaben, nicht als sequenzielle oder parallele Abfolge von einzelnen Aktionen definiert werden. In den 1950er Jahren galt die Erstellung von Programmen für Fachleute als trivial (vgl.

[LUD07]). Die Programme wurden von einem Programmierer erdacht und sofort kodiert. Ab den 1960er Jahren jedoch wurden die Ansprüche an die Programmierer komplexer und eine direkte Kodierung erschien mehr und mehr als ungünstig (siehe Abschnitt „8.1.1 Code and Fix“). Dijkstra forderte 1972 die Softwareerstellung so zu verändern, dass die vom Menschen intellektuell besser erfasst und gesteuert werden kann (vgl. [DIJ72]).

Es wurden seit den 1960er Jahren Vorgehens- und Prozessmodelle definiert und eingeführt, die die Erstellung von Software in organisatorische Schritte unterteilt und so die Umsetzung größerer und unübersichtlicherer Softwareprojekte arbeitsteilig ermöglichen.

Diese Modelle werden in der Literatur häufig als Softwareentwicklungsprozesse bezeichnet. Die folgenden Abschnitte differenzieren zwischen Vorgehens- und Prozessmodellen und stellen die bekanntesten Vertreter vor.

8 .1 V or ge he nsm ode l l e Ein Vorgehensmodell ist ein Muster, aus dem sich ein konkreter Projektablauf, d .h. die zur Erstellung des Produkts notwendigen Schritte,

ableiten lässt. Ein

Vorgehensmodell hat im Allgemeinen keine Ansprüche an die Projektorganisation (vgl. Abschnitt „8.2 Prozessmodelle“).

8.1.1 Code and Fix Das Vorgehen des „Code and Fix“ kann nicht als Entwicklungsprozess betrachtet werden, da es bar jeder Ordnung verläuft. Es wird dabei der Schwerpunkt darauf gelegt, möglichst rasch mit dem Kodieren zu beginnen um schnellstmöglich ein lauffähiges Programm zu erhalten. Dabei wird so lange programmiert, getestet und korrigiert, bis das Produkt das gewünschte Verhalten aufweist. Dieses Vorgehen gilt als sehr einfach, da kein Entwicklungsprozess beherrscht werden muss und Vorkenntnisse nicht erforderlich sind.

Seite 31

Methoden des Projektmanagements in moderner Softwareentwicklung

Auf die Ausarbeitung einer Architektur und des Designs, die Erstellung einer Dokumentation, qualitätssichernde Maßnahmen und das Einhalten von Standards wird dabei verzichtet. Daher entsteht für diese Tätigkeiten keinerlei Mehraufwand.

Projekte die mit diesem Vorgehen bearbeitet werden sind weder planbar, noch lässt sich der aktuelle Projektstand ermitteln (siehe Abschnitt „9.1 Projektplanung und überwachung“). Risiken bleiben grundsätzlich unerkannt und können daher nicht vermieden werden, sondern treten spontan im Projektverlauf auf und werden erst dann ad-hoc beseitigt.

Es ist kaum möglich mehr als einen Entwickler ein solches Projekt bearbeiten zu lassen, da der Code für Dritte oft nicht nachvollziehbar ist.

Der Aufwand für die Beseitigung von Mängeln ist unangemessen hoch, da diese erst im Einsatz entdeckt werden können. Auch die Wartung eines so entwickelten Projekts ist sehr aufwendig, da die unstrukturierte Umsetzung und das Fehlen einer Dokumentation

die

nachträgliche

Bearbeitung

des

Softwareprodukts

massiv

erschweren.

Dieses Verfahren eignet sich ausschließlich zur Erstellung von Programmen, die nicht produktiv eingesetzt werden, wie „Wegwerfprototypen“ oder Machbarkeitsstudien, da die Qualität und Wartbarkeit dieser Anwendungen keine Rolle spielen. Für umfangreiche Projekte ist dieses Vorgehen aufgrund der gravierenden Kosten für die Fehlerbeseitigung und Wartung sowie die gravierenden Qualitätsmängel nicht geeignet.

8.1.2 Wasserfallmodell Rosove erkannte 1967, dass die Entwicklung eines Softwareprodukts in bestimmten aufeinanderfolgenden Schritten abzubilden ist. Er definierte den sog. „Software Lifecycle“, der die Zeitspanne von der Idee eines Produkts bis zu seiner Außerdienststellung

beschreibt.

Er

erkannte

Tätigkeiten:  Anforderungsdefinition  Strukturierung der Lösung  Erstellung und Integration des Produkts Seite 32

eine

sequenzielle

Abfolge

von

Methoden des Projektmanagements in moderner Softwareentwicklung

 Prüfung des Produkts  Inbetriebnahme  Betrieb und Wartung Royce verhalf 1970 dem Software Lifecycle in Form des sog. Wasserfallmodells zu großer Popularität.

Das Wasserfallmodell kann als Beschreibung der Tätigkeiten zur Softwareentwicklung verstanden werden. Seine schematische Darstellung (siehe Abbildung 12) erinnert an einen Wasserfall und gibt dem Modell seinen Namen. In dem Modell wird mit der Tätigkeit oben links im Schema begonnen und nach deren Abschluss die Aktivität direkt darunter ausgeführt. Wird ein Mangel oder ein Fehler erkannt wird zu einer der vorherigen Arbeiten zurückgekehrt, in der er aufgetreten ist. An dieser Stelle wird der Mangel oder Fehler korrigiert und danach alle darauf folgenden Tätigkeiten angepasst.

Der Weg zurück zu früheren Tätigkeiten wird in der Literatur als Zyklus bezeichnet.

Jede der Aktivitäten erzeugt ein Ergebnis oder eine Anzahl von Teilergebnissen, die in Form von Dokumenten, wozu auch der ausführbare Programmcode zählt. Die nachfolgenden Arbeiten basieren auf dem Resultat der vorherigen Aktivitäten. Die Tätigkeiten werden dabei jeweils, wie beim gewöhnlichen Software Lifecycle sequenziell ausgeführt.

Schon

1965,

Jahre

vor

der

Veröffentlichung

des

Wasserfallmodells

als

Vorgehensmodell, kritisierte Dijkstra das blinde Vertrauen auf scheinbar komplett spezifizierte Programmteile (vgl. [DIJ65]). Er bemerkte, dass auch wenn alle Programmteile einzeln komplett analysiert zu sein scheinen, die Gefahr einer Selbsttäuschung über die praktische Qualität der Spezifikationen besteht.

In den 1980er Jahren erkannte man, dass das Wasserfallmodell große Schwächen in der Praxis aufwies (vgl. [LUD07]). Bei diesem Modell wird angenommen, das Produkt bereits in der Anforderungsphase bis zum Ende durchdenken zu können. Eventuell erst während der Spezifikation, während oder nach der Kodierung auftretende Änderungen können dabei nur über Zyklen in früheren Tätigkeiten erfasst werden.

Weil dabei jedoch alle darauffolgenden Aktivitäten erneut bearbeitet werden müssen, sind derartige Änderungen extrem aufwändig (vgl [OES01]). Dieser Umstand macht Seite 33

Methoden des Projektmanagements in moderner Softwareentwicklung

das Produkt zu jedem Zeitpunkt der Entwicklung extrem unflexibel und nur schwer änderbar. Insbesondere die späte Kodierung des Projekts lässt Probleme erst spät erkennen. Durch den Gebrauch von Zyklen kann der Projektfortschritt nur schwer ermittelt werden, da die aktuelle Aktivität keinen Aufschluss über den tatsächlichen Fertigstellungsgrad des Produkts liefern kann.

Systemanalyse

k rre Ko tu r

Softwarespezifikation

k rre Ko tu r

Architekturentwurf

k rre Ko tu r

Feinentwurf und Kodierung

k rre Ko tu r

Integration und Test

k rre Ko tu r

Installation und Abnahme

Betrieb und Wartung Abbildung 12 - Wasserfallmodell (vgl. [LUD07])

Da heute Neuentwicklungen von Software im Vorfeld nur schwer bis in jedes Detail definiert werden können und nicht alle Risiken schon vor Projektbeginn bekannt sind, eignet sich dieses Vorgehensmodell dafür nicht. Bei Projekten mit bekannten und stabilen Rahmenbedingungen, der Portierungen von Software auf ein anderes System oder der Weiterentwicklung eines vorhandenen Produkts kann das Wasserfallmodell jedoch gut eingesetzt werden, insbesondere da es nur geringen organisatorischen Mehraufwand verursacht (vgl. sonstige Vorgehens- und Prozessmodelle).

Seite 34

Methoden des Projektmanagements in moderner Softwareentwicklung

8.1.3 Iterativ-inkrementelle Entwicklung Die iterativ-inkrementelle Softwareentwicklung wirkt den Schwierigkeiten des Wasserfallmodells entgegen. Bei diesem Vorgehensmodell werden die grundsätzlichen Annahmen vertreten, dass ein zu erstellendes Softwaresystem nicht in einem einzigen Arbeitsprozess anfertiget werden kann und dass die Anforderungen nicht vollständig und unveränderlich definiert sind.

Das Softwareprodukt wird in Form mehrerer Teilprodukte entwickelt. Jedes einzelne davon ist dabei ein lauffähiges Programm und ist eine Weiterentwicklung des vorherigen.

Bei einem inkrementellen Vorgehen wächst die Funktionalität jedes Teilprodukts (Inkrements). Das erste Inkrement stellt den Kern der Anwendung dar, während jedes weitere die Produktmerkmale in Form von Ausbaustufen erweitert. Durch dieses Vorgehen ist bereits eine frühe Auslieferung eines Softwareprodukts mit zunächst noch eingeschränkter Funktionalität möglich.

Das iterative Vorgehen bezeichnet die Entwicklung eines Softwareprodukts in mehreren Durchgängen (Iterationen). Dabei weist das Produkt bereits nach der ersten Iteration viele Produktmerkmale auf, welche zunächst erst teilweise funktionsfähig sind. Mit jedem Durchgang wird die Software weiter verfeinert. So ist es beispielsweise möglich, in frühen Iterationen die Programmoberfläche zu erstellen, während Fachlogik und Datenhaltung erst in späteren Durchgängen realisiert werden.

Das iterative Vorgehen kann als die Erstellung einer Software in der Breite verstanden werden, während das inkrementelle Vorgehen die Bearbeitung der einzelnen Funktionen des Produkts in der Tiefe beschreibt. Sowohl in der Literatur, als auch in der Praxis werden das iterative und inkrementelle Vorgehensmodell vermischt und als iterativ-inkrementelle Softwareentwicklung bezeichnet.

Jede Iteration beginnt mit einer Entwurfsphase, in der die Erkenntnisse der vorherigen Iterationen analysiert und die Anforderungen sowie die Softwarearchitektur aktualisiert bzw. erweitert werden. Im Anschluss wird mit der Implementierung für den aktuellen Durchlauf begonnen, bevor ein lauffähiges Programm durch Integration und Test entsteht.

Seite 35

Methoden des Projektmanagements in moderner Softwareentwicklung

Die Bearbeitung einzelner Iterationen kann sich durchaus überlappen. So kann mit der Entwurfsphase der nächsten bereits während des Tests der aktuellen Iteration begonnen werden.

Der aktuelle Projektstand lässt sich aus dem lauffähigen Produkt und Indikatoren, wie Einbau neuer Funktionen oder Verbesserung der Architektur, ableiten.

Die

iterativ-inkrementelle

Softwareentwicklung

gilt

als

risikoorientierte

Vorgehensweise, da durch die früh zur Verfügung stehenden lauffähigen Programme mangelnde Anforderungen und Probleme frühzeitig erkannt werden können. Auch Fachreferenten und Benutzer haben die Möglichkeit sich dabei durch die Bewertung der lauffähigen Programme direkt zu beteiligen.

Durch die kontinuierliche Integration jedes Iterationsergebnisses bleiben Probleme nicht bis kurz vor der Auslieferung verschleiert sondern werden v0n Projektbeginn an bekämpft.

Der Testaufwand für das Produkt wird bei iterativ-inkrementellem Vorgehen auf alle Iterationen verteilt. Am Ende jeder Iteration steht eine Testphase, ehe die Iteration als abgeschlossen gilt. Dies hat den Vorteil, dass schwerwiegende Fehler früh erkannt werden und sich der Testaufwand nicht auf die Abschlussphase des Projekts konzentriert, in der der Termindruck häufig am größten ist. Dies ermöglicht zudem eine gleichmäßige Auslastung des Testteams im Projekt.

Die Dauer der einzelnen Durchläufe ist jeweils etwa gleich. Auf diese Weise entsteht im Entwicklerteam ein Gefühl der Dringlichkeit und der Fortschritt ist für jeden einzelnen

direkt

sichtbar

(siehe

Abschnitt

„7.1.2

Managementstrategie

zur

Motivationserhöhung“).

8.1.4 Spiralmodell Das Spiralmodell wurde 1988 von Boehm entwickelt und versteht sich als ein iteratives Verfahren. Bei dem Spiralmodell handelt es sich um ein generisches Vorgehensmodell, ein sogenanntes Metamodell, bei dem die schnelle Minimierung von Projektrisiken im Vordergrund steht.

Bei dem Modell, das seinen Namen seiner schematischen, spiralförmigen Darstellung (siehe Abbildung 13) verdankt, entspricht jede Umdrehung der Spirale einer Iteration.

Seite 36

Methoden des Projektmanagements in moderner Softwareentwicklung

Begonnen wird dabei in der Mitte der Spirale. Das Spiralmodell folgt dem Paradigma, in jeder Iteration das jeweils größte verbleibende Projektrisiko zu bekämpfen. Eine Iteration gilt als abgeschlossen, wenn das Risiko behoben und ein lauffähiger Prototyp erstellt wurde.

Abbildung 13 - Spiralmodell nach Boehm (1988) (GNU-Lizenz für freie Dokumentation vgl. [GNU12])

Typisch an diesem Modell ist die Tatsache, dass alle großen Projektrisiken nach einigen Iterationen neutralisiert wurden und das Projekt ab diesem Zeitpunkt konstant und sicher in weiteren Durchläufen abgeschlossen werden kann. Die Anzahl der Iterationen hängt dabei von der jeweiligen Komplexität des Projekts und den zu bewältigenden Risiken ab.

Da es sich bei dem Spiralmodell um ein Metamodell handelt, kann die inhaltliche Ausprägung andere Vorgehensmodelle abbilden. So kann jede Iteration als eine Aktivität des Wasserfallmodells modelliert werden, was bedeutet, dass zunächst die Risiken der Spezifikation, dann diese des Entwurfs und der Implementierung Seite 37

Methoden des Projektmanagements in moderner Softwareentwicklung

angegangen werden, während schließlich Integrationsprobleme gelöst werden. Es ist auch möglich ein komplettes Wasserfallmodell in jeder Iteration zu wiederholen oder die Ansätze iterativ-inkrementeller Entwicklung mit dem Spiralmodell abzubilden. Der entscheidende Punkt ist die vordergründige Risikoorientierung der Iterationen.

8.1.5 Model Driven Architecture Die Model Driven Architekture, kurz MDA, ist ein konkreter Ansatz modellgetriebener Softwareentwicklung (Model Driven Development). Das zu erstellende System wird in der MDA unter Verwendung von Modellen und Generatoren aus der formalen Spezifikation teilweise generiert. Ziel des Modells ist die Entwicklungsgeschwindigkeit des Projekts und die Qualität des Produkts zu steigern. Urheber der MDA ist die Object

Management

Group,

ein

1989

gegründetes,

Konsortium,

dass

die

Standardisierung objektorientierter Softwareentwicklung international vorantreibt. Zu den bekanntesten Standards gehören neben der MDA auch die CORBA (Common Object Request Broker Architecture), die die Verteilung objektorientierter Software in heterogenen Systemen vereinheitlicht sowie die UML (Unified Modeling Language), die als formale Notation objektorientierer Modellierung dient.

Alle Modelle der MDA sind maschinenlesbar und können somit neben der Codegenerierung auch der automatisierten Integration dienen. Durch die Äquivalenz zwischen dem generierten Produkt und den Modellen der MDA werden sowohl die Wartung als auch das Testen der Modelle gegen die Spezifikationen zusätzlich erleichtert. Aus diesem Grunde kann der Test des generierten Codes gegen die Spezifikation im Vergleich zu konventionellen Modellen mehr in den Hintergrund rücken.

Die formalen Modelle der MDA, die sich der UML als Modellierungssprache bedienen, sind in verschiedene Abstraktionsgrade unterteilt (vgl. [ZEP06]):  Computation Independent Model (CIM)  Platform Independent Model (PIM)  Platform Specific Model (PSM)  Implementation Specific Model (ISM) / Quellcode

Seite 38

Methoden des Projektmanagements in moderner Softwareentwicklung

Das Computation Independent Model beschreibt die Anforderungen an das zu erstellende System als Geschäftsmodell (Business Model). Die Darstellung des CIM abstrahiert dabei von der tatsächlichen Implementierung und dient dabei zur Klärung der Anwendungsfälle.

Das Platform Independent Model ist ein detaillierteres, plattformunabhängiges Modell der nächsten Abstraktionsstufe. Es beschreibt die Struktur und die Funktionalität des Systems, ohne eine konkrete technische Realisierung zu berücksichtigen (vgl. [AND04]).

Eine die Zieltechnologie der Umsetzung berücksichtigende Abstraktionssicht, die wiederum mehr Spezifikationsdetails aufweist, ist das Platform Specific Model. Es werden

beispielsweise

Programmiersprachenspezifika,

spezielle

Client-Server-

Technologien oder konkrete Datenbanken in der Spezifikation benutzt.

Das Implementation Specific Model repräsentiert den (generierten) Quelltext der Software und weist damit den geringsten Abstraktionsgrad auf.

Das Ziel das Softwaresystem teilweise zu generieren, wird über automatisierte Transformationen der verschiedenen Abstraktionsmodelle erreicht. Dabei werden die Modelle höheren Abstraktionsgrades in Modelle geringerer Abstraktion umgewandelt.

Die durch diese Transformation gewonnenen Modelle müssen in der Praxis anschließend manuell verfeinert werden, da sie noch nicht vollständig sind und Lücken enthalten können (vgl. [ZEP06]).

Die Modelle in der MDA müssen strengen formalen Ansprüchen genügen, da sie für die Generierung maschinenlesbar sein müssen. Dies verlangt den beteiligten Entwickler eine hohe Disziplin bei der Spezifikation ab, da auch für Menschen intuitiv verständliche Gegebenheiten, etwa eine Methode BerechneAlterInJahren(Geburtsdatum : DateTime)

im Modell exakt algorithmisch festgelegt werden muss.

Durch die relativ bequeme Möglichkeit der Codegenerierung werden die Entwickler jedoch auch angehalten eine saubere und vollständige Spezifikation zu erstellen. Dabei wirkt die MDA der unwillkommenen Praxis entgegen, dass die Inhalte der Seite 39

Methoden des Projektmanagements in moderner Softwareentwicklung

ursprünglichen Spezifikation und der Implementierung im Laufe eines Projekts immer weiter auseinanderdriften, denn in der MDA sind die Spezifikation und die Implementierung während der gesamten Projektlaufzeit direkt und eng miteinander verbunden.

So kann sich der Mehraufwand für die Spezifikation der Modelle in der MDA besonders bei größeren Projekten durch eine höhere Qualität, eine verbesserte Wartbarkeit und durch die Generierung des Codes positiv auf die Gesamtkosten des Projekts auswirken.

8 .2 P r o ze s sm o de l l e Ein Prozessmodell ist ein Muster, aus dem sich ein konkretes Softwareprojekt, d. h. die Abfolge von Schritten, um ein bestimmtes Softwareprodukt zu erzeugen, ableiten lässt. Ein Prozessmodell beinhaltet im Kern häufig ein Vorgehensmodell zur Projektdurchführung und zusätzlich die notwendigen Organisationsstrukturen, welche Vorgaben

für

Projektmanagement,

Qualitätssicherung,

Dokumentation

und

Konfigurationsverwaltung enthalten (vgl. [LUD07]).

Prozessmodelle bilden ein Gerüst für Softwareprojekte, die jedoch sehr heterogen ausgeprägt sein können. Aus diesem Grunde kann es in der Praxis notwendig werden das jeweilige Modell auf ein konkretes Softwareprojekt oder eine Gruppe heterogener Softwareprojekte anzupassen. Dieser Vorgang, der in der Literatur als „Tailoring“ bezeichnet wird, ist insbesondere in allen Fragen vonnöten, in denen das Modell keine oder keine konkreten Vorgaben liefert.

8.2.1 Phasenmodell Dem sog. Phasenmodell liegt die Annahme zugrunde, dass sich ein Softwareprojekt in einzelne Abschnitte, sogenannte Phasen unterteilen lässt. Jede einzelne besitzt einen definierten Anfang und ein definiertes Ende und überlappt niemals mit einer anderen Phase (siehe Abbildung 14).

Meilensteine stehen bei diesem Vorgang an den Anfangs- und Endpunkten einer jeden Phase und trennen sie so deutlich voneinander.

An jeden Meilenstein sind klare Bedingungen und Voraussetzungen geknüpft, die kritisch überprüft werden müssen, bevor er als erreicht gilt. Es können dabei zwar Seite 40

Methoden des Projektmanagements in moderner Softwareentwicklung

Termine für einen Meilenstein festgelegt werden, doch seine Erreichung hängt ausschließlich von den definierten Kriterien ab.

Phase 1

Phase 2

Phase 3

Phase 4 t

M0

M1

M2

M3

M4

Abbildung 14 - Zusammenhang von Phasen und Meilensteinen

Zu Beginn des SoftwareProjekts erfolgt die Einteilung der Phasen, wobei jeder Phase ein festes Budget und ein geplanter Fertigstellungtermin zugeteilt wird. Die einzelnen Phasen werden während der Projektdurchführung streng sequenziell durchlaufen.

Eine Rückkehr zu einer vorherigen Phase ist im Modell nicht vorgesehen. Tritt ein Fehler einer vorangegangenen Phase auf, wird er zunächst dokumentiert. Der Projektleiter entscheidet über die Beseitigung des Fehlers, die jedoch im Budget der aktuellen Phase stattfindet. Nach der Behebung des Fehlers werden die Bedingungen des Meilensteins, der am Ende der Phase der Fehlerursache stand, erneut geprüft.

Gleiches geschieht mit jeder beeinflussten nachfolgenden Phase, da diese von der Änderung ebenso betroffen sein kann. Die Änderung eines bereits geprüften Dokuments ist somit wesentlich aufwändiger als im Wasserfallmodell (vgl. [LUD07]).

Mit dem Phasenmodell geplante Projekte weisen eine präzise Planung und Organisation auf. Diese Planung erlaubt es frühzeitig die Kosten und den Personalbedarf festzulegen. Durch Budget- oder Terminüberschreitungen werden negative Abweichungen von der Planung schnell erkannt, während das Erreichen einer Phase den Projektfortschritt objektiv messbar macht.

Das Phasenmodell selbst besitzt jedoch kein eigenes Vorgehensmodell zur Softwareerstellung. Die Definition des Begriffes der Phase ist sehr allgemein gehalten und Vorgaben zu konkreten Aktivitäten der Entwicklung sind nicht vorhanden. Dies macht das Modell einerseits flexibel für verschiedenartige Projekte, andererseits jedoch Tailoring notwendig, um das Phasenmodell auf die Erfordernisse des Projekts anzupassen.

Seite 41

Methoden des Projektmanagements in moderner Softwareentwicklung

8.2.2 Unified Software Development Process Der Unified Software Development Process, kurz Unified Process genannt, wurde 1999 von den Begründern der Unified Modeling Language (UML) Jacobson, Booch und Rumbaugh erstmals vorgestellt.

Es handelt sich dabei um einen generischen Softwareentwicklungsprozess, dessen konkrete Ausprägung im kommerziellen IBM Rational Software Development Process verkörpert ist.

Zunächst wird auf das frei verfügbare, generische Prozessmodell eingegangen, bevor der kommerzielle Prozess vorgestellt wird.

8.2.2.1 Generischer Unified Process Der generische Unified Software Development Process (Unified Process) ging aus den zunächst parallelen Bemühungen von Jacobson, Booch und Rumbaugh hervor, einen besonders für objektorientierte Softwareentwicklung geeigneten Entwicklungsprozess zu definieren.

Der Prozess untergliedert sich in (vlg. [OES01]):  Phasen und Iterationen  Prozesse (Workflows) und Aktivitäten  Rollen (Worker)  Modelle und Produkte (Artefacts) Die technische Realisierung des Programms unterteilt sich in Iterationen, während sich die organisatorische Sicht in Phasen unterteilt. Jede Phase kann aus mehreren Iterationen bestehen und endet mit einem Artefact (einem Modell oder einem Produkt). Jede Iteration wird von einem definierten Meilenstein abgeschlossen.

Ein

Worker

bezeichnet

Verantwortlichkeiten.

Einige

im

Unified

Beispiele

Process für

bestimmte

Worker

sind

Aufgaben

und

Softwarearchitekt,

Anwendungsfall-Ingenieur oder auch System-Integrator.

Workflows sind in dem gleichen Zusammenhang die Aktivitäten und Arbeitsabläufe, die als zusammenhängende Tätigkeit verstanden werden. Einem Workflow wird ein

Seite 42

Methoden des Projektmanagements in moderner Softwareentwicklung

Worker zugeordnet, der ihn bearbeitet. Dabei ist es auf dieser Abstraktionsebene unerheblich, welcher konkrete Mitarbeiter die Tätigkeit ausführt.

Typisch wird ein Projekt in mindestens vier organisatorische Phasen unterteilt:  Konzeptions- und Vorbereitungsphase (Inception Phase)  Entwurfsphase (Elaboration Phase)  Konstruktionsphase (Construction Phase)  Übergangsphase (Transition) In der Konzeptions- und Vorbereitungsphase wird das Produkt definiert und die grundsätzliche Wirtschaftlichkeit überprüft. Diese Phase wird außerdem dazu benutzt einen ersten, noch unvollständigen Grobentwurf der Softwarearchitektur und des Projektplans zu erstellen, die offensichtlichen Risiken des Projekts zu bewerten und Machbarkeitsstudien durchzuführen. Am Ende dieser Phase steht ein erstes Analysemodell des Produkts zur Verfügung, dass die Ergebnisse dieser Phase beinhaltet.

Die Entwurfsphase dient der Identifikation der noch fehlenden Anforderungen und der größten Projektrisiken. Für jedes Risiko werden Gegenmaßnahmen geplant. Die Phase dient außerdem dazu Architekturentscheidungen zu treffen, die zu einem validen und ausführbaren Modell der Systemarchitektur am Ende dieser Phase führen.

In der Konstruktionsphase wird das System implementiert, integriert und getestet. Beiläufigen Tätigkeiten, wie der Dokumentation, werden fortgesetzt und vervollständigt. Am Ende dieser Phase steht ein stabiles, ausführbares und vor allem auslieferbares System zur Verfügung.

Die abschließende Übergangsphase dient der Übergabe des Produkts an die Anwenderschaft. Beta-Tests der Software sowie letzte Verbesserungen kennzeichnen diese Phase. Schritte zur Markteinführung und zum Vertrieb werden getroffen. Dazu gehören

beispielsweise

die

Vervollständigung

der

Benutzerdokumentation

(Handbuch), das Einrichten einer Support-Hotline (Telefonnummer für Fragen zur Software), die Erstellung der Verpackung und die Produktion der Datenträger.

Wie bereits erwähnt kann jede Phase aus einer oder mehreren Iterationen bestehen.

Die Hauptgehalte eines Durchlaufs sind unterschiedlich und hängen von der aktuellen Seite 43

Methoden des Projektmanagements in moderner Softwareentwicklung

Phase und dem Projektfortschritt ab. Die ersten Iterationen beschäftigen sich beispielsweise sich vordergründig mit der Klärung der Anforderungen und der Architektur der Software, während sich Durchläufe in der Konstruktionsphase stärker mit der Kodierung beschäftigen. Das Testen des Produkts verteilt sich, wie beim iterativ-inkrementellen Vorgehensmodell, auf den gesamten Projektverlauf.

8.2.2.2 IBM Rational Software Development Process Der IBM Rational Unified Process (RUP) prägt den generischen Unified Process zu einem vollwertigen, konkreten Prozessmodell aus (vgl. [LUD07]). Da es sich beim RUP um ein kommerzielles Produkt handelt, ist für die Anwendung des Prozesses eine Lizenzgebühr zu entrichten.

Die einzelnen Arbeitsabläufe, wie z. B. Projektmanagement, Anforderungsanalyse oder Konfigurations- und Änderungsmanagement werden im RUP konkretisiert und genau spezifiziert (siehe Abbildung 15).

Seite 44

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 15 - Aktivitäten im IBM Rational Unified Process, vereinfacht (Bearbeitung)

Der RUP ist in HTML und Textform erhältlich und weist einen hohen Detaillierungsgrad und klare Prozessdarstellungen auf. Dies führt jedoch zu einem unvermeidlichen und nicht zu unterschätzenden Aufwand für das Tailoring des Prozesses. Der IBM Rational Unified Process vereint jedoch verschiedene Vorzüge anderer Modelle in sich, wobei besonders die iterativ-inkrementelle Vorgehensweise und das Phasenmodell zu nennen sind, so dass der Prozess, an die Bedürfnisse eines Projekts

angepasst,

ein

modernes,

flexibles

und

adäquates

Modell

der

Projektdurchführung darstellt.

8.2.3 V-Modell XT Das V-Modell XT versteht sich als Leitfaden zur Planung und Durchführung von Softwareprojekten.

Dabei

werden

sowohl

die

Produkte,

die

während

der

Projektlaufzeit erzeugt werden sollen, als auch die konkreten Vorgehensweisen, die zu den Produkten führen, definiert (vgl. [WWW01]).

Seite 45

Methoden des Projektmanagements in moderner Softwareentwicklung

Das V-Modell wurde vom Bundesministerium für Verteidigung entwickelt und ist dort seit 1992 verbindlich für die Entwicklung von Software vorgeschrieben. Seit 1996 ist es auch bei der Softwareentwicklung in und für zivile Bundesbehörden empfohlen und häufig auch verbindlich vorgeschrieben. Die aktuelle Version des V-Modells, das VModell XT (XT steht für Extreme Tailoring) ist der Nachfolger des 1997 veröffentlichten V-Modell 97, dass auch die Hardwareentwicklung einschloss, und somit die dritte Version des Modells.

Das V-Modell XT kann, anders als sein Vorgänger, für folgende Projektarten genutzt werden (vgl. [LUD07]):  Konkrete Softwareentwicklungsprojekte  Konkrete Hardwareentwicklungsprojekte  Metaprojekte, die ein Vorgehensmodell in eine Organisation einführen oder es pflegen Da das Prozessmodell öffentlich zur Verfügung steht und auch in Unternehmen, die Software für Bundesbehörden erstellen eingesetzt wird, hat es in Deutschland in den vergangenen 15 Jahren einen erheblichen Stellenwert eingenommen.

Produkte und Aktivitäten sind in diesem Modell in einem Netz eng miteinander verknüpft, das dessen Kern bildet. Aktivitäten werden von Rollen ausgeführt, die Fähigkeiten und Aufgaben bezeichnen und von realen Mitarbeitern abstrahieren. Ähnlich wie das Phasenmodell gliedert sich das V-Modell XT in Phasen, sog.

Projektabschnitte,

die

durch

einen

Meilenstein,

einen

sogenannten

Entscheidungspunkt, abgeschlossen werden. An jedem Entscheidungspunkt wird von der Projektleitung über die Fortsetzung oder den Abbruch des Projekts neu entschieden, um kein zum Scheitern verurteiltes Projekt unnötig lange fortzusetzen.

Das Ergebnis wird in einem Schriftstück, einer sog. Projektfortschrittsentscheidung, dokumentiert.

Als Prozessmodell deckt das V-Modell XT neben der technischen Realisierung eines Projekts auch Projektmanagement, Qualitätssicherung, Konfigurationsverwaltung und Problem- und Änderungsmanagement ab, die als sog. Vorgehensbausteine bezeichnet werden. Einem Vorgehensbaustein sind Rollen, Aktivitäten und Produkte zugeordnet.

Seite 46

Methoden des Projektmanagements in moderner Softwareentwicklung

Je nach Projekttyp können im Zuge des Tailoring auch weitere Vorgehensbausteine hinzugefügt werden. Die einzelnen Vorgehensbausteine bauen aufeinander auf und sind voneinander abhängig.

Das

Modell

unterstützt

inkrementelle,

komponentenbasierte

sowie

agile

Entwicklungsprozesse und lässt sich auf die konkreten Projektbedürfnisse anpassen oder für diese erweitern. Bei den Projekten unterscheidet das Modell ferner zwischen Auftraggeber- und Auftragnehmerprojekten, wobei ein Projekt auch beide Sichten beinhalten kann.

Eine sog. Projektdurchführungsstrategie ordnet die benötigten Entscheidungspunkte und legt deren zeitliche Reihenfolge fest. Das V-Modell XT kennt mehrere Projektdurchführungsstrategien,

die

von

der

Sicht

(Auftraggeber-

und

Auftragnehmerprojekten), der Projektart und dem gewählten Entwicklungsprozess (inkrementell, komponentenbasiert oder agil) abhängen.

Seinen Namen hat das V-Modell einerseits von dem Wort Vorgehensmodell, andererseits jedoch auch von dem typischen Ablauf der Prüfungen während der Systemerstellung, die schematisch V-förmig dargestellt wird (siehe Abbildung 16).

Dabei findet die Verifizierung und Validierung zweier Ergebnisse stets auf derselben Abstraktionsebene statt.

Seite 47

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 16 - Entscheidungspunkte in der Struktur der Systemerstellung im V-Modell XT (vgl. [WWW01])

Auch wenn das V-Modell XT als extrem anpassungsfähig einzustufen ist, ist die Beschränkung

auf

inkrementelle,

komponentenbasierte

oder

agile

Entwicklungsprozesse eine unnötige Einschränkung. Ein großer Vorteil des Modells ist neben der hohen Generizität der hohe Stellenwert der projektbegleitenden Aktivitäten, die auf gleicher Stufe mit der technischen Umsetzung (Entwurf und Implementierung) stehen. Der hohe Formalismus und Tailoring-Aufwand lässt die Eignung für kleine oder mittlere Projekte bezweifeln. Durch die breite Nutzung des lizenzkostenfreien Prozessmodells für Entwicklungsprojekte der Bundesbehörden steht jedoch in Deutschland mit dem V-Modell XT ein einheitlicher und vergleichbar stabiler Entwicklungsprozess

zur

Verfügung,

der

die

Qualität

der

Softwareentwicklungsprozesse auf ein gemeinsames Niveau anhebt.

8.2.4 Agile Prozessmodelle Der Ansatz sog. agiler Prozessmodelle kann als Bewegung gegen die Installation streng formalisierter und bürokratischer Softwareentwicklungsprozesse betrachtet werden.

Bei Ansätzen agiler Softwareentwicklung werden die Abschaffung von Bürokratie, die Konzentration auf die Konstruktion der Software, die völlige Bereitschaft auf Wünsche des Kunden oder des Marktes auch während der Projektlaufzeit rasch reagieren zu können und der Faktor Mensch in den Vordergrund gerückt.

Seite 48

Methoden des Projektmanagements in moderner Softwareentwicklung

Im Februar 2001 fand in den USA ein Treffen wichtiger Protagonisten der agilen Bewegung statt, bei dem das sog. Manifest der agilen Softwareentwicklung verabschiedet wurde (vgl. [ZEP06] und [COC03a] (Zitat)): „Durch das Entwickeln von Software und indem wir anderen bei der Entwicklung helfen, erschließen wir bessere Wege der Softwareentwicklung. Durch diese Arbeit haben wir folgende Werte zu schätzen gelernt:  Individuen

und

Interaktionen

sind wichtiger als Prozesse und

Werkzeuge.  Funktionierende Software ist wichtiger als umfassende Dokumentation.  Kundenzusammenarbeit ist wichtiger als Vertragsverhandlungen.  Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen.

Wir schätzen die Punkte auf der rechten Seite, aber wir bewerten die Punkte auf der linken Seite höher“ 8.2.4.1 Extreme Programming Kommunikation, Einfachheit, Testen mit anschließender Rückmeldung (Feedback) und Mut sind die definierten Grundwerte des Extreme Programming, kurz XP genannt. Kommunikation steht dabei für die persönliche und direkte Verständigung aller Projektbeteiligten, d. h. zwischen den Anwendern, dem Kunden und den Entwicklern. Der Begriff Einfachheit bezeichnet die Bemühungen, stets möglichst einfache Lösungen zu entwickeln, die leicht verständlich sind. Der Kunde, die Anwender und auch die Kollegen des Entwicklerteams testen die Software und geben einander beständig Feedback zu den Ergebnissen, um einen hohen Qualitätsstandard der Software zu gewährleisten. Der Begriff Mut soll die Beteiligten encouragieren das System beständig zu verbessern und den Weg der agilen Entwicklung während des Projekts beizubehalten.

In konventionellen Prozessmodellen steigen die Kosten für den nachträglichen Einbau von Änderungen in das Projekt mit der Projektlaufzeit. Eine neue Anforderung, die beispielsweise erst zum Zeitpunkt der Implementierung in das Projekt eingebracht wird, muss bei konventionellen Modellen zunächst eine Anforderungsanalyse und eine Änderung der Spezifikation bzw. des Designs durchlaufen, ehe sie implementiert wird.

Seite 49

Methoden des Projektmanagements in moderner Softwareentwicklung

Daher verursacht eine Änderung zu einem späteren Zeitpunkt deutlich höhere Kosten als zu Beginn des Projekts, während der Anforderungsdefinition. XP verfolgt jedoch den Ansatz, die Kosten für den Einbau von Änderungen in ein Projekt möglichst während der gesamten Projektlaufzeit konstant zu halten (siehe Abbildung 17).

Abbildung 17 - Kosten für Änderungen während der Projektdurchführung (GNU-Lizenz für freie Dokumentation vgl. [GNU12])

Im XP werden gewöhnlich drei bis zehn Programmierer beschäftigt, die von einem oder mehreren Kunden, die als Fachreferenten geeignet sind und die notwendige Entscheidungsbevollmächtigung besitzen, vor Ort täglich unterstützt werden. Alle genannten Projektbeteiligten halten sich in einem, oder in direkt benachbarten Räumen auf, um die Kommunikationswege auch räumlich kurz zu halten.

Entwickelt wird in Iterationen die nur wenige Wochen andauern und jeweils zu einem funktionierenden, getesteten, ausführbaren Programm führen, dass dem Kunden sofort zur Durchsicht und Beurteilung zur Verfügung steht. Nach ca. zwei bis fünf Iterationen wird das Programm an die Endkunden (Benutzer) ausgeliefert.

Die Anforderungen des Projekts werden in sog. User Stories (sing. User Story) erfasst.

Eine User Strory beschreibt eine Funktionalität aus Benutzersicht, die in einer Iteration entwickelt werden kann, möglichst kurz auf einer Karteikarte. Die Entwickler schätzen dabei den Zeitaufwand für die Umsetzung einer User Story, während der Kunde die Prioritäten der Umsetzungsreihenfolge der User Stories setzt und ihre genauen Inhalte festlegt. Vor der Realisierung einer User Stroy besprechen die

Seite 50

Methoden des Projektmanagements in moderner Softwareentwicklung

Entwickler die Inhalte noch einmal mit dem Kunden. Auf diese Weise müssen die Anforderungen nicht ausführlich dokumentiert werden.

Im Extreme Programming wird der Ansatz des Pair Programming, bei dem stets zwei gleichberechtigte Mitarbeiter gemeinsam an einem Arbeitsplatzrechner arbeiten (vgl.

Abschnitt

„7.3.1.1

Einzelpersonen

und

kleine

Gruppen“).

Jedes

zweiköpfige

Entwicklerteam ist berechtigt jede Stelle des Quellcodes ungefragt zu verändern.

Damit wird persönlichen Besitzansprüchen am Code (sog. „Ownership of Code“) entgegengewirkt. Dieser Ansatz wird in der Literatur als Egoless Programming bezeichnet. Die Aufgabe jedes Paares ist es die neuen User Stories einzuarbeiten, wobei zuerst Testfälle implementiert werden, mit denen der hinzugefügte Quellcode validiert und verifiziert werden kann. Ferner

refaktorisieren (Refactoring) die

Entwicklerpaare den vorhandenen Quelltext beständig so, dass er so einfach und übersichtlich wie möglich ist. Die Zusammensetzung der Zweierteams rotiert täglich und wird vom sog. Coach, einem Mitarbeiter des Teams, der einige organisatorische Aufgaben erfüllt und die Entwickler zur Einhaltung der XP Prinzipien ermutigt, bestimmt.

Täglich besprechen die Projektmitglieder in einer etwa fünfzehn minütigen Besprechung, die bewusst im Stehen stattfindet (um die langen Diskussionen vorzubeugen) den aktuellen Projektstand und eventuelle Probleme.

Der Kunde kommuniziert beständig mit den Entwicklern, um Ideen zu vermitteln und Entwicklungsalternativen auszuloten, prüft die Software in Form von Akzeptanztests und erarbeitet neue User Stories für die nächste Iteration.

XP spart, im Sinne der agilen Prozessmodelle, an unnötigem Ballast, insbesondere an Dokumenten und bürokratischen Strukturen. Dies wird durch die kurzen und direkten Kommunikationswege untereinander und zum Kunden, sowie die Verbreitung des Projektwissens durch das Pair Programming möglich. So ist es im XP beispielsweise nicht nötig detaillierte Anforderungsdokumente zu erstellen, da der Kunde direkt vor der Erstellung der Funktionen zu deren Beschaffenheit befragt wird.

Die Anwendung des Extreme Programming erfordert jedoch ein hohes Maß an Disziplin von allen Projektbeteiligten und die Bereitschaft des Kunden aktiv am Entwicklungsprozess teilzunehmen. XP ist nicht skalierbar, d. h. nur auf relativ kleine Seite 51

Methoden des Projektmanagements in moderner Softwareentwicklung

Teams anwendbar, da bei größeren Gruppen der Kommunikationsaufwand deutlich steigt.

In Projekten mit stark fluktuierenden Anforderungen und kleinen, disziplinierten Teams kann das XP deutliche Vorteile gegenüber konventionellen Prozessen in Bezug auf Kosten und Projektlaufzeit erzielen.

8.2.4.2 Crystal Cockburn hat eine Reihe von agilen Prozessmodellen entwickelt, die unter dem Namen Crystal bekannt sind. Die einzelnen Prozessmodelle sind durch Namen von Farben indiziert und werden abhängig von der Zahl der Projektentwickler verwendet:  Crystal Clear

(1-6 Mitarbeiter)

 Crystal Yellow

(7-20 Mitarbeiter)

 Crystal Orange

(21-40 Mitarbeiter)

 Crystal Rew

(41-100 Mitarbeiter)

 Crystal Maroon

(101-200 Mitarbeiter)

 Crystal Blue

(201-500 Mitarbeiter)

 Crystal Violet

(501 und mehr Mitarbeiter)

Die Modelle werden ferner nach dem im ungünstigsten Fehlerfall entstehenden Schaden gruppiert. So entstehen bei sieben Projektgrößenordnungen und vier Schadenseinstufungen insgesamt 28 Modelle (siehe Tabelle 2). Davon wurden von Cockburn die Modelle mit mehr als 100 Mitarbeitern oder mit dem Risiko der Lebensgefahr im Schadensfall nicht, oder nicht näher betrachtet. Crystal Clear ist bislang das am besten dokumentierte Modell, welches Cockburn 2004 in einem Buch detailliert präsentierte.

Seite 52

Methoden des Projektmanagements in moderner Softwareentwicklung

Fehler verursachen

Anzahl der Mitarbeiter im Projekt 1-6 6-20 20-40

40-60

60-100

100-200

200-500

Lebensgefahr (Life)

L6

L20

L40

L60

L100

L200

L500

Hohe Kosten (Essential Money)

E6

E20

E40

E60

E100

E200

E500

D6 Unbequemlichkeit (Comfort) C6

D20

D40

D60

D100

D200

D500

C20

C40

C60

C100

C200

C500

Crystal Red

Crystal Maroon Crystal Blue

Begrenzte Kosten (Discretionary Money)

Crystal Clear

Crystal Yellow Crystal Orange Crystal Red

Tabelle 2 – Übersicht der Crystal Modelle

In Crystal stehen die Managementsicht, sowie die Prozessverbesserung im Vordergrund. Die Entwicklung der Projekte erfolgt in regelmäßigen Inkrementen, wobei Meilensteine durch Entscheidungen und Auslieferungstermine bestimmt sind.

Der

Benutzer

ist

im

Entwicklungsprozess

direkt

involviert.

Bestimmte

Vorgehensweisen während des Projekts (u. A. die Kodierung) wird durch Muster (Templates) definiert.

Der Qualitätssicherung wird in Crystal durch automatisierte Regressionstests und Tests

der

Software

durch

mindestens

zwei

Benutzer

beigetragen.

Die

Anforderungsdefinition wird durch Besprechungen, die zu Anfang und in der Mitte jedes Auslieferungszyklus stattfinden, gewährleistet.

Crystal unterscheidet zwischen vier Personengruppen (vgl. [COC03a]):  Geldgeber (Sponsor, Auftraggeber)  Leitender Programmierer und Designer  Programmierer und Designer im Team  Benutzer Ferner

existieren

beispielsweise

der

in

Crystal

verschiedene

Spezialistenrollen.

Benutzeroberflächendesigner,

der

Dazu

gehören

Systemarchitekt,

der

Datenbankdesigner oder ein Spezialist, der die Wiederverwendung von Komponenten regelt.

Die skalierten Ausführungen des Crystal-Modells haben das Ziel die Anwendung zu erleichtern und keine zu hohen Tailoring-Aufwände zu generieren (siehe als negatives Beispiel dafür den Abschnitt „8.2.3 V-Modell XT“). Da jedoch viele der Modelle bislang Seite 53

Methoden des Projektmanagements in moderner Softwareentwicklung

noch nicht oder nur grob definiert wurden, ist die jetzige Eignung in der Praxis fragwürdig. Es wirkt das Vorhandene wie „eine Vorübung zu dem, was noch kommen soll“ (vgl. [LUD07]).

Ludewig und Lichter urteilen (vgl. [LUD07]): „Insgesamt handelt es sich eher um einen konzeptionellen Rahmen als um konkrete Prozessmodelle. […] Erfahrungen (mit Crystal) scheint es kaum zu geben.“ 8.2.5 Cleanroom Development Process Die Produktion hochintegrierter Schaltkreise, wie Prozessoren oder Speicherchips, ist ein Verfahren, dass keinerlei Fehler erlaubt. Insbesondere Verunreinigungen der Rohstoffe während des Produktionsprozesses führen schnell dazu, dass ein Produkt fehlerhaft ist, was in der Praxis dazu führt, dass das entsprechende Bauteil unbrauchbar wird. Da die Kosten für den Ausschuss an solcherart Produkten bei häufigen Verunreinigungen inakzeptabel hoch wäre, haben sich in der Chipindustrie Reinräume (Cleanrooms) etabliert, die mit angemessenem Aufwand annähernd frei von Staub oder sonstigen Verunreinigungsquellen gehalten werden (siehe Abbildung 18).

Seite 54

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 18 - Industrieller Reinraum (vlg. [GNU12])

Forscher der IBM Federal Systems Devision haben dieses System auf einen Softwareentwicklungsprozess übertragen, den sog. Cleanroom Development Process, kurz CDP. Durch diesen Prozess wird ebenfalls versucht, Fehler vom Softwareprojekt möglichst fern zu halten, anstatt aufwändige Reparaturen der Software, die selbst wiederum Fehler nach sich ziehen können, zu akzeptieren.

Der Prozess existiert in drei Ausprägungen, der Basisimplementierung (introductory), die die Grundideen des CDP verwirklicht, der vollständigen (full)

und der

fortgeschrittenen (advanced) Implementierung, welche die Adaption strenger, formaler Verfahren fordert, die über die vollständige Implementierung hinausgehen (vgl. [LUD07]). Im Folgenden wird die mittlere, vollständige Implementierung näher dargestellt.

Die Spezifikation der zu erstellenden Software erfolgt auf drei Abstraktionsebenen. Die sog.

Black-Box-Spezifikation

beschreibt

für

eine

Softwareeinheit

(das

Gesamtsystem, ein Inkrement, ein Modul, eine Komponente oder Funktion) den Zusammenhang zwischen Ein- und Ausgaben. Dies geschieht in der Praxis durch präzise natürlich sprachliche Definitionen oder Ein- und Ausgabetabellen. Die StateBox-Spezifikation betrachtet die Softwareeinheit als Zustandsautomat und Seite 55

Methoden des Projektmanagements in moderner Softwareentwicklung

beschreibt den Zusammenhang

zwischen

den Zuständen.

Die

Clear-Box-

Spezifikation schließlich abstrahiert direkt vom Quellcode der Softwareeinheit. Sie beschreibt den Feinentwurf in Form von Daten- und Ablaufstrukturen. Um die Korrektheit der beiden letzten Spezifikationsarten zu gewährleisten, werden sie gegen die jeweils höhere Spezifikation validiert, d. h. die Clear-Box-Spezifikation wird gegen die State-Box-Spezifikation geprüft und diese wiederum gegen die Black-BoxSpezifikation.

Da die Erfolgschancen von Projekten geringer Größe und Laufzeit als höher gelten, als die von ausgedehnten Großprojekten, wird ein großes Projekt im CDP zunächst in mehrere Inkremente, also kleinere Teilprojekte, aufgeteilt. Jedes Inkrement sollte mit etwa fünf bis acht Entwicklern in einigen Monaten durchgeführt werden können.

Für die Analyse und Spezifikation steht im CDP weit mehr Zeit zur Verfügung als in konventionellen Prozessen. „Die Spezifikationen werden sehr gründlich inspiziert“ (vgl. [LUD07]).

Auch bei der Codierung hat die Fehlerfreiheit einen extrem hohen Stellenwert. Die Programmierer erstellen den Quellcode ohne Hilfe eines Compilers, der sie auf syntaktische Fehler hinweisen könnte, die es zu reparieren gilt. Stattdessen wird von jedem Entwickler erwartet, einen Code zu liefern, der semantisch und syntaktisch fehlerfrei ist.

Modultests für die fertigen Komponenten werden nicht durchgeführt. Stattdessen werden alle Komponenten integriert und das gesamte System getestet. Dies hat den Vorteil, dass Fehler die bei einem einzelnen Modultest nicht erkannt worden wären, die also aus dem Zusammenspiel verschiedener Komponenten resultieren, erkannt werden.

Fehler werden nur in sehr geringem Maße akzeptiert. Ist die Fehlerrate zu hoch, wird der Code der entsprechenden Komponente verworfen und die komplett neu implementiert. Getestet wird im CDP bevorzugt mit einer sehr großen Menge an Testdaten, wobei es sich zumeist um Zufallsdaten handelt. Die jeweils erwarteten Resultate müssen bei diesen Tests ebenfalls bekannt sein. Nach diesen Tests kann eine statistische Auswertung eine Aussage über die Zuverlässigkeit der Software treffen und es kann geprüft werden, ob das Resultat akzeptiert werden kann.

Seite 56

Methoden des Projektmanagements in moderner Softwareentwicklung

Durch dieses Vorgehen kann eine Fehlerrate von drei bis vier Fehlern pro tausend Codezeilen gegenüber ca. 25 Fehlern pro tausend Codezeilen bei konventionellen Verfahren erreicht werden (vgl. [LUD07]).

Die Management-, Spezifikations-, Entwicklungs- und Zertifizierungsprozesse sind im Cleanroom Developement Process engmaschig miteinander vernetzt und rigide geregelt, was jedoch insgesamt zu einem relativ starren und streng sequenziellen Prozess führt.

Die Anforderungen an die Entwickler sind sehr hoch. Insbesondere benötigen sie ein stabiles Arbeitsumfeld, d. h. möglichst bekannte Werkzeuge und Technologien, und ausreichende

Erfahrung

um

dem

Anspruch

der

möglichst

fehlerfreien

Softwareentwicklung gerecht zu werden. Auf äußere Einflüsse, wie z. B. häufige Änderungswünsche

des

Kunden

oder

wechselnde

Rahmenbedingungen

zur

Projektlaufzeit kann im CDP nur schwerfällig reagiert werden. Daher gilt dieses Prozessmodell besonders für Projekte mit relativ fixiertem Umfeld, klaren Anforderungen und stabilen technischen Rahmenbedingungen, wie z. B. die Portierung bestehender Systeme oder eingebettete Systeme, etwa Gerätesoftware, und für Systeme die eine hohe Zuverlässigkeit erfordern, als besonders geeignet.

In der Literatur wird von positiven, praktischen Erfahrungen mit dem CDP berichtet (vgl. [LUD07]). Die Ersparnis des hohen Aufwands der ständigen Fehlerkorrektur und die hohe Qualität des fertigen Softwareprodukts können den zusätzlichen Aufwand dieses qualitätsorientierten Prozessmodells in geeigneten Projekten rechtfertigen.

9 PROJEKTDURCHFÜHRUNG

UND

PROJEKTSTEUERUNG

Unabhängig vom Softwareentwicklungsprozess gibt es im Projekt Aufgaben und Methoden, die während der Entwicklungszeit durchgehend bearbeitet werden müssen.

In den folgenden Abschnitten wird ein kurzer Überblick über aktuelle Erkenntnisse in der Projektdurchführung und –steuerung gegeben, die in der Literatur primär als praktische Erfahrungswerte gelten. Umfangreichere Handlungsempfehlungen finden sich in der Literatur (vgl. [FEY04], [LUD07] und [OES01]) wieder.

Seite 57

Methoden des Projektmanagements in moderner Softwareentwicklung

9 .1 Pr oj ekt pl a nung un d -Ăź be r wa chu ng Projektplanung basiert auf Planungsdaten, die Aussagen Ăźber Laufzeit und Ressourcenaufwand eines Projekts liefern. Oestereich et al. fordern Planungen mindestens zu diesen Punkten (vgl. [OES01]): ďƒ˜ Zeitplanung ďƒ˜ Ressourcenplanung ďƒ˜ Auswahl eines geeigneten Entwicklungsprozesses ďƒ˜ Teamstruktur ďƒ˜ Strategie zum Risikomanagement Verschiedene Entwicklungsprozesse und Teamstrukturen wurden bereits in den Abschnitten „8 Softwareentwicklungsprozesse“ und „7.3 Teamstrukturen“ vorgestellt.

Die Zeit- und Ressourcenplanung wird im folgenden Abschnitt („9.2 Schätzungen und Messungen“) diskutiert. Der Umgang mit Risiken in Softwareentwicklungsprojekten wird im Abschnitt „9.3 Risikomanagement“ erĂśrtert.

Die Ăœberwachung eines Projekts kann neben der ständigen ĂœberprĂźfung der geplanten

Strukturen

(siehe

oben)

insbesondere

eine

Beobachtung

des

Fertigstellungsgrades des Softwareprodukts beinhalten. Der Fertigstellungsgrad kann durch eine Formel zu jedem Zeitpunkt der Projektlaufzeit ermittelt werden (vgl.

[LUD07], siehe Formel 3).

đ??šđ?‘’đ?‘&#x;đ?‘Ąđ?‘–đ?‘”đ?‘ đ?‘Ąđ?‘’đ?‘™đ?‘™đ?‘˘đ?‘›đ?‘”đ?‘ đ?‘”đ?‘&#x;đ?‘Žđ?‘‘ =

đ??źđ?‘ đ?‘Ą-đ??´đ?‘˘đ?‘“đ?‘¤đ?‘Žđ?‘›đ?‘‘ đ??źđ?‘ đ?‘Ą--đ??´đ?‘˘đ?‘“đ?‘¤đ?‘Žđ?‘›đ?‘‘ + đ?‘…đ?‘’đ?‘ đ?‘Ąđ?‘Žđ?‘˘đ?‘“đ?‘¤đ?‘Žđ?‘›đ?‘‘

Formel 3 - Fertigstellungsgrad eines Softwareprodukts zu einem Zeitpunkt während der Projektlaufzeit

Neben der Berechnung des Fertigstellungsgrades kann die Erfassung von zuvor geplanten Meilensteinen, die nur die Zustände „nicht-erfĂźllt“ und „erfĂźllt“ besitzen, einen realistischen Eindruck des Projektfortschritts auf Phasenebene (siehe Abschnitt „8.2.1 Phasenmodell“) vermitteln. Jedoch gibt dieses Verfahren keinen Aufschluss Ăźber Schwierigkeiten im gesamten Projekt, sondern liefert nur Informationen Ăźber die Fertigungsgeschwindigkeit einer Phase zwischen zwei Meilensteinen. Tiefsitzendere Probleme, wie z. B. ein sehr unerfahrenes Team oder extrem fluktuierende Anforderungen, werden nicht direkt erkannt.

Seite 58

Methoden des Projektmanagements in moderner Softwareentwicklung

Die Änderungshäufigkeit im Produkt, d. h. Anpassung bereits erstellter Teile, gibt Aufschluss über dessen Stabilität und somit indirekt auch über dessen Reifegrad. Ein Softwareprodukt, dass z. B. kurz vor seiner Auslieferung noch immer häufiger Änderungen der Spezifikation oder Architektur bedarf, wird nicht als fertiggestellt betrachtet.

Die Erfassung von Fehlerraten während des Tests einer Software gibt zusätzliche Informationen über die Qualität des Systems. Software, in der noch viele Fehler gefunden werden, sollte nicht ausgeliefert werden.

9 .2 S chä t zu ng e n un d M e s s u ng e n Messungen dienen jeder Schätzung als Basis. Soll der Aufwand für die Erstellung einer Softwareeinheit (Projekt, Teilprojekt oder Projektteil) geschätzt werden, so wird zunächst versucht von bekannten Größen auf den unbekannten Aufwand der zu erstellenden Softwareeinheit zu schließen.

Dazu muss zunächst eine bereits umgesetzte Softwareeinheit mit etwa derselben Größe (z. B. derselben Projektgröße) und denselben Rahmenbedingungen3 gefunden werden. Hierbei wird der Umfang der zu erstellenden Softwarereinheit geschätzt.

Es

gibt

grundsätzlich

zwei

Methoden

um

die

Größe

einer

unbekannten

Softwareeinheit zu schätzen. Die erste Möglichkeit ist die Expertenschätzung, die auch als Makroschätzung bezeichnet wird. Dabei wird die unbekannte Softwareeinheit von erfahrenen Entwicklern mit bekannten Softwareeinheiten verglichen und so auf die Größe geschlossen ohne diese im Detail zu planen. Die zweite Möglichkeit ist die algorithmische Schätzung 4, die auch Mikroschätzung genannt wird, bei der die Softwareeinheit in eine Vielzahl kleiner, gut schätzbarer Teile zerlegt wird.

Beispielsweise könnte eine neu zu entwickelnde Benutzerverwaltung der eines ähnlichen Projekts gleichen. In einer Makroschätzung werden die Unterschiede bewertet und aus Erfahrung auf den Aufwand der neuen Komponente geschlossen. In einer Mikroschätzung wird die zu entwickelnde Komponente zerlegt und jedes

3

D. h. ähnliche Teamgröße, ähnliche Projektlaufzeit und ähnliche Komplexität Ludewig und Lichter ([LUD07]) und Oestereich et. al. ([OES01]) beschreiben in ihren Büchern Methoden der algorithmischen Schätzung, wie Funktionspunkte oder Widget Points 4

Seite 59

Methoden des Projektmanagements in moderner Softwareentwicklung

Einzelteil einzeln bewertet, wobei schließlich ein Mehraufwand für die Integration der Teile addiert wird.

9 .3 Ri si k om a na gem e nt Risiken können, werden sie falsch eingeschätzt, zu spät erkannt oder ignoriert, aufgrund der im Schadensfall entstehenden Kosten den erfolgreichen Projektverlauf gefährden.

Im

Abschnitt

„6.2

Kostenminimierung“

wurde

bereits

auf

die

Quantifizierung von Projektrisiken eingegangen. Vielen Risiken kann begegnet werden, indem geeignete Teamstrukturen und Softwareentwicklungsprozesse gewählt werden, die den Risiken entgegenwirken.

Das Risikomanagement besteht aus zwei grundsätzlichen Schritten pro bestehendem Risiko. Erstens muss eine Risikobewertung durchgeführt und zweitens im Anschluss eine Risikosteuerung etabliert werden.

Für die Risikobewertung müssen Risiken zunächst identifiziert werden, was eine strukturierte Suche nach möglichen Risiken einschließt. Ist ein Risiko bekannt, wird es quantifiziert (siehe Abschnitt „6.2 Kostenminimierung“) und anschließend priorisiert um den Stellenwert der späteren Risikosteuerung festzulegen.

Die folgende Tabelle zitiert eine Liste typischer Projektrisiken nach Oestereich et al. (vgl. [OES01], siehe Tabelle 3).

Seite 60

Methoden des Projektmanagements in moderner Softwareentwicklung

Risiko Feature Creep Optimistische Planung Unerfahrenes Team Neue Technologien Design-Probleme Qualitätsprobleme Silver Bullet Syndrom Managementprobleme Geldprobleme Kostenschätzungen Entwicklungsprozess Ungenaue Metriken Produktivität

Beschreibung Es werden laufend neue Features eingebracht, die „unbedingt“ noch in das laufende Projekt integriert werden müssen.

Der Zeitplan ist unrealistisch und kann nicht eingehalten werden.

Das Team hat nicht genügend Erfahrungen gesammelt für das geplante Projekt.

Es werden neue Technologien verwendet, für die noch nicht genügend Erfahrung gesammelt werden konnten.

Der Entwurf ist unzureichend und die Softwarearchitektur ist instabil.

Die Qualität des Projekts ist unzureichend.

Es wird blind auf die Vorteile eines neuen Werkzeuges oder einer neuen Technologie vertraut.

Die Manager sind unfähig oder nicht genügend mit der Materie vertraut, um vernünftige Entscheidungen treffen zu können.

Es ist unklar, ob die Firma genügend Finanzspielraum hat, um das Projekt bis zum Ende zu finanzieren.

Die Kostenschätzungen reflektieren nicht die realen Kosten des Projekts, weil wichtige Faktoren übersehen wurden.

Es wird ein Entwicklungsprozess eingesetzt, der dem Projekt nicht angepasst ist oder der vom Team nicht befolgt wird.

Der Projektfortschritt wird falsch eingeschätzt, da keine genauen Messwerte vorliegen.

Die Produktivität ist unzureichend, da das Team unerfahren ist oder die falschen Hilfsmittel verwendet.

Tabelle 3 - Liste typischer Projektrisiken (vgl. [OES01])

Es gibt verschiedene Strategien der Risikosteuerung, um einen erfolgreichen Projektabschluss zu erreichen. Die Wahl der jeweiligen Verfahren, die im Folgenden kurz vorgestellt werden, hängt vom Risiko selbst ab.

Das Risiko zu vermeiden ist in vielen Fällen die kostengünstigste und zugleich sicherste Variante. In der Praxis können jedoch Projektanforderungen oder fixe Rahmenbedingungen dieser Strategie im Wege stehen. Es ist beispielsweise nur möglich, auf eine notwendige, jedoch unbekannte, risikobehaftete Technologie zu verzichten, wenn eine geeignete Alternative existiert.

Die genauere Untersuchung eines Risikos, etwa durch Machbarkeitsstudien oder die Erstellung von Prototypen kann die Risikoeinschätzung erleichtern oder sogar zeigen, dass das Risiko minimal ist. Ein Prototyp, in dem eine unbekannte Technologie eingesetzt wird, kann z. B. zeigen, dass diese einfacher zu handhaben ist als angenommen.

Die Beseitigung der Ursache des Risikos bietet einen stabilen Schutz vor dem Auftreten. So kann z. B. ein unerfahrenes Team geschult werden.

Seite 61

Methoden des Projektmanagements in moderner Softwareentwicklung

Das Akzeptieren eines Risikos kann, sofern die Risikoanalyse das Risiko als minimal oder unkritisch eingestuft hat, in der Praxis durchaus eine geeignete Variante sein den Aufwand des Risikomanagements zu reduzieren.

Das direkte Gegensteuern ist eine Alternative, die das tatsächliche Auftreten des Risikos a priori annimmt und daher schon im Vorfeld Gegenmaßnahmen einleitet, die die Kosten des Auftretens oder die Auftrittswahrscheinlichkeit reduzieren.

Die folgende Tabelle zitiert eine Liste von Gegenmaßnahmen typischer Projektrisiken nach Oestereich et al. (vgl. [OES01], siehe Tabelle 4).

Seite 62

Methoden des Projektmanagements in moderner Softwareentwicklung

Risiko Feature Creep

Optimistische Planung

Unerfahrenes Team Neue Technologien

Design-Probleme

Qualitätsprobleme Silver Bullet Syndrom Managementprobleme

Geldprobleme

Kostenschätzungen Entwicklungsprozess

Ungenaue Metriken

Produktivität

Gegenmaßnahmen  Einführung eines formalen Komitees, das Änderungen beschließt  Flexible Softwarearchitektur, welche die einfache Integration neuer Features erlaubt  Iterativer Entwicklungsprozess, um Änderungen kontrolliert einzubringen  Verwendung unterschiedlicher Schätzmethoden, um mehrere Schätzungen zu erhalten  Iterativer Entwicklungsprozess, um mehr Messpunkte für die Verfeinerung der Planung zu erhalten  Iterationen so planen, dass zur Not eine frühere Version der Software geliefert werden kann  Hinzuziehen externer Berater  Schulungen  Schulungen in allen neuen Technologien  Hinzuziehen externer Berater  Erstellen von Prototypen, um Design-Alternativen zu untersuchen  Iterativer Entwicklungsprozess, um Probleme frühzeitig zu erkennen  Design-Reviews mit Fachleuten durchführen  Zeit zum Testen einplanen  Design- und Code-Reviews durchführen  Realistische Erfahrungen von anderen Anwendern einholen  Systemteile sauber kapseln, um sie bei Bedarf ersetzen zu können  Ausbildung der Manager verbessern  Iterativer Entwicklungsprozess erzwingt regelmäßige Entscheidungen  Zusätzliche Geldgeber finden  Produkt auf die wesentlichen Funktionen beschränken, um früher fertig zu werden  Planungen verfeinern und mit Referenzmodellen vergleichen.  Entwicklungsprozess anhand des Projekttyps auswählen  Team bei Prozesseinführung einbeziehen  Mit einfachem Basisprozess starten, der von allen verstanden und akzeptiert wird  Messwerterfassung automatisieren  Iterativer Entwicklungsprozess, um mehrere Messpunkte zu erhalten  Schulungen durchführen, Coaching vereinbaren  Erhältliche Werkzeuge evaluieren und miteinander vergleichen  Wiederkehrende Vorgänge automatisieren

Tabelle 4 - Gegenmaßnahmen typischer Projektrisiken (vgl. [OES01])

Da die Projektrisiken nicht nur zu Anfang der Projektlaufzeit relevant sind, muss das Risikomanagement kontinuierlich bis zum Ende des Projekts fortgeführt werden. Eine Behandlung aller Risiken zur gleichen Zeit ist in der Praxis durch begrenzte Kapazitäten nicht möglich. Daher ist es empfehlenswert, während der ganzen Projektlaufzeit eine nach Prioritäten sortierte Risikoliste zu pflegen und jedem Projektbeteiligen zur Verfügung zu stellen, die auch entsprechende Gegenmaßnahmen Seite 63

Methoden des Projektmanagements in moderner Softwareentwicklung

enthält. Den größten Risiken sollte dabei direkt entgegengewirkt werden.

Grundsätzlich sollten alle Projektrisiken und deren Behandlung in den Projektplan aufgenommen werden.

Konsequentes Risikomanagement begünstigt den erfolgreichen Ausgang eines Softwareentwicklungsprojekts und wirkt sich günstig auf die Projektkosten aus.

9 . 4 D o k um e nta tio n In der Praxis gehört die Dokumentation eines Softwareprojekts zu den häufig vernachlässigten Teilen der Systemerstellung. Dadurch, dass sie scheinbar nicht direkt zur Produktion der Software dient, wird ihr Wert gering geschätzt oder es wird versucht Budgetüberschreitungen durch verkürzte Dokumentation zu kompensieren.

Dieses Vorgehen unterliegt jedoch bei näherer Betrachtung einem Trugschluss.

Sowohl Ludewig und Lichter (vgl. [LUD07]) als auch Oestereich et al. (vgl. [OES01]) führen verschiedene wichtige Argumente an, wie die Dokumentation direkt und indirekt mit der Qualität der Software und der Softwareentwicklung zusammenhängt, die im Folgenden vorgestellt werden.  Die Dokumentation ist, als eine Form der Kommunikation, ein direkter Weg des

Wissenstransfers

innerhalb

der

Entwicklerteams,

zwischen

Entwicklungsabteilungen und zwischen Auftraggeber, Auftragnehmer und ggf. auch dem Benutzer.  Das Wissen wird außerdem personen- und abteilungsunabhängig persistent konserviert, so dass das Wissen über die Software nicht mit einem Mitarbeiter den Auftragnehmer verlässt.  Die entstehenden Dokumente können genutzt werden um Teilprodukte verschiedener Abstraktionsstufen miteinander zu vergleichen, d. h. zu prüfen und somit Fehler frühzeitig zu erkennen .  Der Projektfortschritt kann anhand der entstandenen Dokumente objektiv nachvollzogen werden, da klar ist, welche Bestandteile bereits fertiggestellt wurden und welche Qualität sie bieten.

Seite 64

Methoden des Projektmanagements in moderner Softwareentwicklung

 Dokumentation verbessert die Wartbarkeit und Änderbarkeit von Software, denn sie hilft Fehler im Nachhinein besser finden zu können und verschafft schneller Klarheit über die Struktur des Softwareprodukts, um es erweitern zu können.

In der Literatur werden zahlreiche verschiedene Dokumentationsvarianten vorgestellt, deren Inhalt stark von der Zielgruppe, d. h. den Adressaten der Dokumente und der Bedeutung der Dokumente als Teilprodukte im Entwicklungsprozess abhängt. Einige Softwareentwicklungsprozesse fordern eigene Dokumente, die als Bestandteile des Prozesses Teilprodukte bilden.

Dokumentation gilt als aufwändig. Ludewig und Lichter (vgl. [LUD07]) schätzen die Produktivität eines Entwicklers auf zwei bis vier Seiten pro Tag. Ein vierzigseitiges Dokument kann somit einen Bearbeiter zwischen zwei und vier Wochen beschäftigen und so die Projektlaufzeit signifikant erhöhen. Daher ist es in der Praxis von Bedeutung, Dokumentation besonnen einzusetzen und, je nach Projektausprägung, den Dokumentationsgrad so gering wie möglich, jedoch so detailiert wie nötig zu gestalten.

Seite 65

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL IV ENTWICKLUNG EINES PLATTFORMÜBERGREIFENDEN ELEKTRONISCHEN TAGEB UCHS Die

im

Teil

„Teil

III

Projektmanagement

in

der

Softwareentwicklung“

zusammengestellten Erkenntnisse moderner Projektorganisation finden in den folgenden Abschnitten beispielhafte und praktische Verwendung bei der Erstellung eines realen Softwareprodukts. An dieser Stelle sei auf den beiliegenden Datenträger verwiesen, der einen plastischen Eindruck der entwickelten Software vermittelt.

10 ANFORDERUNGSDEFINITION Ziel ist die Erstellung der ersten Version eines elektronischen Tagebuchs für den privaten Gebrauch. Dieses plattformübergreifende elektronische Tagebuch, kurz „Pet“, soll mehrere Hard- und Softwareumgebungen abdecken und neben den Texten eines klassischen Tagebuchs auch Multimediaelemente wie Videos, Tondokumente oder Bilder plattformübergreifend verfügbar machen.

In seiner ersten Version soll das plattformübergreifende elektronische Tagebuch zunächst sämtliche Grundfunktionen abdecken. Das Projekt soll es jedoch ermöglichen, das Produkt nach der ersten Version sukzessive weiterzuentwickeln, um in folgenden Versionen die Funktionalität weiter zu erhöhen.

Eine

ausführliche

Beschreibung

der

gestellten

Anforderungen

und

Rahmenbedingungen des Produkts liegt in Form eines Pflichtenheftes vor (siehe „13 Anhang A: Pflichtenheft des plattformübergreifenden elektronischen Tagebuchs“).

Pet unterscheidet sich von sog. Weblog-Anwendungen5 (auch Blogs genannt) durch das Einsatzgebiet. Pet wird, anders als ein Blog, weder im Internet veröffentlicht, noch im Internet für die breite Öffentlichkeit zur Benutzung zur Verfügung gestellt. Die Anwendung wird vorwiegend auf einem Rechner des Benutzers installiert und nur von ihm genutzt. Typische Weblogs unterstützen zurzeit Multimediainhalte nur indirekt über manuelle Anpassungen. Eine relativ neue Bewegung stellen die sog. Vlogs (VideoWeblogs) dar. Unter einem Vlog wird ein Blog verstanden, der überwiegend aus audiovisuellen Inhalten besteht. In Zukunft ist ein Aufschwung der Vlogs zu erwarten.

5

Anwendung für ein digitales Tagebuch, dass im Internet ausgeführt wird und dessen Einträge von einem breiten Publikum im Internet gelesen werden können.

Seite 66

Methoden des Projektmanagements in moderner Softwareentwicklung

Ferner grenzt sich Pet von Standardsoftware zur Blog-Administration ab, da es sich bei Pet um eine erweiterungsfähige Individualsoftware handelt, die die Anforderungen maßgeschneidert erfüllt.

11 BESTIMMUNG

DER

PROJEKTPARAMETER

1 1 .1 Ko ste nm i ni m i er ung de s Pr oj e kt s Die

Entwicklung

der

Software

„Pet“

(plattformübergreifendes

elektronisches

Tagebuch) geht nach typischen Kostenminimierungsstrategien vor (siehe Abschnitt „6.2 Kostenminimierung“). Wie bereits erwähnt, spielen dabei besonders die Möglichkeit kosteneffizienter Fehlerbehandlung, ein solides Risikomanagement und Anforderungen an das Qualitätsmanagement eine Rolle.

Im Abschnitt „11.2 „Rollen und Teams“ im Projekt“ wird ein Vorgehens- bzw.

Prozessmodell gewählt, dass die Einhaltung des definierten Qualitätsfaktors „Änderbarkeit und Wartbarkeit“ und die wirtschaftliche Fehlerbehandlung zur Projektlaufzeit ermöglicht. Die projektbezogenen Risiken werden im Abschnitt „12.1.2 Risikomanagement “ bewertet und gesteuert.

1 1 .2 „ Rol l e n un d Tea m s “ i m Pr oj ek t Die Umsetzung der Individualsoftware für den Eigenbedarf erfolgt durch nur eine einige Person. In Bezug auf das Projektmanagement erleichtert eine Umsetzung dieser Art verschiedene Faktoren im Projekt (siehe auch Abschnitt „7.3.1.1 Einzelpersonen und kleine Gruppen“):  Kein Mehraufwand für Kommunikation  Kein Mehraufwand für etwaige Teamorganisation  Klarheit der Projektanforderungen  Keine Ressourcenkonflikte bei Abhängigkeiten von Arbeitspaketen Diesen Vorteilen stehen jedoch auch Nachteile gegenüber, die im Projektverlauf besonders überwacht werden müssen:

Seite 67

Methoden des Projektmanagements in moderner Softwareentwicklung

 Die

Personalunion

sämtlicher

Rollen

im

Projekt

(Auftraggeber

und

Auftragnehmer sowie Projektleiter und Entwickler) begünstigt unentdeckte Fehler aufgrund fehlender Fremdprüfungen (durch einen anderen Entwickler, Projektleiter oder den Kunden).  Das

Arbeitsergebnis

droht

entwicklergeprägt

und

für

außenstehende

unübersichtlich oder schwer verständlich zu werden.  Die Vernachlässigung einer technischen Dokumentation der Entwicklung wird durch einen Einzelentwickler begünstigt.

1 1 .3 F e stl eg e n de s So ft wa r e e nt wi ckl ung s pr o ze s s e s Die

Eignung

der

vorgestellten

Entwicklungsprozesse

(siehe

Abschnitt

„8

Softwareentwicklungsprozesse“) für das vorliegende Projekt wird nacheinander überprüft, ehe das Vorgehen für die Umsetzung des Pet festgelegt wird.

11.3.1 Einsatz von Code and Fix Aufgrund der Forderung nach Änderbarkeit und Wartbarkeit der Anwendung sowie nach Dokumentation schließt sich dieses Vorgehensmodell für die Umsetzung des Gesamtprojekts aus.

Ein Prototyp im Sinne einer Machbarkeitsstudie zur Risikobewertung und –steuerung kann jedoch sinnvoll per Code and Fix realisiert werden.

11.3.2 Einsatz des Wasserfallmodells Die klar definierten und für die erste Version stabilen Anforderungen an das Pet lassen das Wasserfallmodell augenscheinlich als ein geeignetes Vorgehensmodell für die Umsetzung des Projekts wirken.

Die Begünstigung zunächst unentdeckter Fehler, die eventuell erst im Projektverlauf identifiziert werden können und auch die beschriebene Anforderung an das System in mehreren

Ausbaustufen

mit

steigender

Funktionalität,

die

teilweise

noch

unspezifiziert ist, spricht klar gegen das Wasserfallmodell.

11.3.3 Einsatz der iterativ-inkrementellen Entwicklung Das

iterativ-inkrementelle

Projektparameter

nach

Vorgehensmodell

Risikoorientierung, Seite 68

unterstützt stufenweiser

die

geforderten

Entwicklung

und

Methoden des Projektmanagements in moderner Softwareentwicklung

Inbetriebnahme,

Toleranz

der

Fehlerkorrektur

zur

Projektlaufzeit

und

der

Anforderung der Änderbarkeit und Wartbarkeit.

Nachteil dieser Vorgehensweise im Projekt ist die relativ ungenaue Definition der Abläufe innerhalb einer Iteration und der zu erstellenden Produkte, da der iterativinkrementelle Entwicklungsprozess zwar in der Literatur weit verbreitet, jedoch nicht formal und standardisiert festgelegt wurde. Da es sich um Individualsoftware für den Eigenbedarf handelt könnten das Modell nach tatsächlichen Erfordernissen ausgelegt werden,

was

jedoch

bar

jeder

Verifikationsmöglichkeit

geschähe,

da

kein

Referenzmodell vorliegt.

11.3.4 Einsatz des Spiralmodells Das Spiralmodell eignet sich besonders für Projekte mit zahlreichen unbekannten Faktoren und vielen Risiken. Als Metamodell bietet es die Möglichkeit selbst beliebige Vorgehensmodelle aufzunehmen. Insbesondere der risikoorientierte Charakter des Modells und seine iterativen Züge lassen das Modell für den Einsatz im vorliegenden Projekt geeignet erscheinen.

11.3.5 Einsatz der Model Driven Achritecture Obwohl die MDA eine Erhöhung der Qualität und eine Verbesserung der Wartbarkeit ermöglicht, eignet sie sich besonders für größere Projekte (siehe Abschnitt „8.1.5 Model Driven Architecture“). Insbesondere die einzuhaltenden strengen Formalismen für die verschiedenen Modelle stehen in kleineren Projekten wie diesem in keinem günstigen Verhältnis zu der Zeitersparnis durch die Codegenerierung. Ebenso stellt die plattformunabhängige Modellierung in diesem speziellen Projekt, das eine klar definierte Zielplattform ausweist, einen unnötigen Zwischenschritt dar.

11.3.6 Einsatz des Phasenmodells Das vorliegende Projekt kann nicht sinnvoll budgetiert werden, da für die Produktion im Rahmen dieser Arbeit keine finanziellen Grenzen erhoben wurden. Die Einteilung in Phasen, die von Meilensteinen mit festen Erfüllungsbedingungen begrenzt werden, ist in einem Projekt mit einem einzigen Entwickler nur bedingt sinnvoll, da der Entwickler seine eigene Arbeit zur Erreichung eines Meilensteins validieren müsste. Da ein Entwickler keine absichtlichen Fehler macht, wird er eigene Versäumnisse und Seite 69

Methoden des Projektmanagements in moderner Softwareentwicklung

Mängel möglicherweise nicht vor Abschluss einer Phase identifizieren können. Dies führt in der Folge zu ständigen Korrekturen vergangener Phasen, was den Sinn des Einsatzes eines Phasenmodells für einzelne Entwickler mehr als in Frage stellt.

11.3.7 Einsatz des Unified Process Der Unified Process, bzw. auch der RUP, bieten sehr gute Mechanismen um in größeren Projekten iterativ-inkrementell Software zu entwickeln. Da sich der Prozess jedoch mit vielen Bereichen des Projektmanagements, mehreren Entwicklern und getrennten Rollen auseinandersetzt, ist der Prozess für dieses Projekt zu gewichtig, d.h. es ist überskaliert.

11.3.8 Einsatz des V-Modell XT Als überskaliert kann für dieses Projekt auch der Prozess des V-Modell XT gesehen werden, da umfassendes Tailoring und hier unnötige Vorgehensweisen die Kosteneffizienz des Pet durch stark erhöhten Projektmanagementaufwand und Bürokratie sabotieren.

11.3.9 Einsatz agiler Prozessmodelle Die Grundsätze der agilen Softwareentwicklung wirken insbesondere positiv auf die Kommunikation innerhalb der Entwicklerschaft und mit dem Kunden sowie der Behandlung von Anforderungsfluktuationen. In einem Projekt zur Erstellung von Individualsoftware für den Eigenbedarf durch einen Entwickler sind diese Konzepte nicht relevant. Der Einsatz agiler Modelle in diesem speziellen Projekt würde insbesondere durch die deutliche Reduktion von Dokumentationen und die fehlende Rückmeldung (Feedback) von anderen Entwicklern oder einem Projektleiter leicht im Vorgehen von Code and Fix enden.

11.3.10 Einsatz des Cleanroom Development Process Die Entwicklung des Pet mit dem CDP ist durch das Fehlen eines objektiven Prüfers ebenfalls nicht möglich. Ferner sind der Mehraufwand und die damit verbundenen Kosten für das vorliegende Projekt, das keinen Anspruch auf exorbitante Fehlerfreiheit legt, unbegründet und daher nicht wirtschaftlich.

Seite 70

Methoden des Projektmanagements in moderner Softwareentwicklung

11.3.11 Entscheidung über den Einsatz eines Softwareentwicklungsprozess es Für das umzusetzende Projekt erscheint der Einsatz eines vereinfachten Spiralmodells, das die Projektrisiken behandelt, am sinnvollsten zu sein. Dabei werden im Vorfeld nötige Prototypen (Wegwerfprototypen) in einem oder mehreren „Umläufen der Spirale“ mittels Code and Fix erstellt und anschließend in weiteren Umläufen für die Realisierung der verbindlichen Produktmerkmale (siehe „13 Anhang A: Pflichtenheft des

plattformübergreifenden elektronischen Tagebuchs“) auf das risikoorientierte

iterativ-inkrementelle Entwicklungsmodell gewechselt. Die Umsetzung der optionalen Merkmale kann im Anschluss nach demselben Schema durchgeführt werden.

Auf diese Weise können sämtliche Projektanforderungen erfüllt und das Projekt erfolgreich realisiert werden.

12 REALISIERUNG Die

im

Folgenden

beschriebene

Realisierung

des

plattformübergreifenden

elektronischen Tagebuchs „Pet“ konzentriert sich primär auf die Projektdurchführung und beschreibt die inzwischen aus zahlreichen Quellen bekannten Abläufe der objektorientierten

Softwareentwicklung,

wie

objektorientierte

Analyse

und

objektorientiertes Design, nur sekundär. Im Fokus liegen daher die Tätigkeiten und Dokumente, die den sicheren und erfolgreichen Ablauf des Softwareprojekts darstellen.

1 2.1 Pr oj ekt pl a nung 12.1.1 Vorkonzeption Die Vorkonzeption dient der Identifizierung von Projektrisiken und hilft bei der Bestimmung der Arbeitspakete für die Umsetzung. In dieser Konzeption werden auch die optionalen Produktmerkmale betrachtet, deren Umsetzung in der ersten Version des Produkts nicht zwingend erforderlich ist.

Die Forderung eines plattformübergreifenden Einsatzes im Heimbereich spricht für eine Lösung als Anwendung im Intra- oder Internet. Die Anwendung kann über die standardisierten Internetbrowser (HTML 4.01 mit Adobe Flash 8 und JavaScript 1.5) auch auf ansonsten heterogenen Systemen problemlos eingesetzt werden. Eine

Seite 71

Methoden des Projektmanagements in moderner Softwareentwicklung

Installation des Pet ist ausschließlich auf dem Anwendungsserver, und nicht auf den Clientrechnern, notwendig.

Der Einsatz im Intranet ermöglicht zudem auch den Einsatz auf Videokonsolen, die die Anforderungen an den Internetbrowser erfüllen, wie z. B. die Konsole „Wii“ der Firma Nintendo. Auch mobile Geräte, wie Laptops, Tablet PCs, PDAs oder Smartphones (siehe Abbildung 19), die diese Anforderung erfüllen, können als Clientrechner eingesetzt werden.

Abbildung 19 - Laptop und Tablet PC (oben) sowie PDA und Smartphone (unten) (vgl. [GNU12])

Mobiltelefone bieten heute meist die Möglichkeit multimediale Inhalte wie Videos, Tondokumente

oder

Bilder

aufzuzeichnen,

beinhalten

jedoch

meist

keinen

Internetbrowser, der die Softwarevoraussetzungen erfüllt. Um dennoch von den Vorteilen der mobilen Aufzeichnung von Inhalten partizipieren zu können, ist es möglich Mobiltelefone über den Einsatz eines E-Mail-Servers zum Einpflegen neuer Inhalte zu nutzen (optionales Merkmal). Dabei wird eine MMS mit der entsprechenden Bild-, Video-, Ton- oder Textdatei an eine E-Mail-Adresse gesendet, die vom Anwendungsserver abgerufen werden kann. Der Anwendungsserver pflegt den Multimediainhalt anschließend in das Pet ein. Um Unbefugten den Missbrauch der ESeite 72

Methoden des Projektmanagements in moderner Softwareentwicklung

Mail-Adresse zu verweigern, muss im Text einer validen E-Mail ein zuvor definiertes Kennwort enthalten sein.

Plattformübergreifendes elektronisches Tagebuch „Pet“

POP3 empfangen

Datenbank Lesen und Text einpflegen

E-Mail-Server (Internet)

Anwendungsserver (Intra- oder Internet)

Lesen und einpflegen aller Inhaltsarten

Linux

Windows

Mobile Geräte

Macintosh

POP3 versenden (Inhalte einpflegen, nicht lesefähig)

Videokonsole

Mobiltelefon

(z. B. Tablet PC)

Benutzer

Abbildung 20 - Schematische Darstellung des Aufbaus und Einsatzes des Pet

Auf diese Weise stehen dem Benutzer eine Vielzahl von Möglichkeiten der Betrachtung und Pflege der Inhalte des Pet zur Verfügung (siehe Abbildung 20).

12.1.2 Risikomanagement im Projekt Die folgenden drei Projektrisiken wurden identifiziert und werden während der Realisierung ständig überwacht, wobei Gegenmaßnahmen das Risikopotenzial minimieren sollen.

12.1.2.1 Unbekannte Technologie: Flash-Video-Format Die Wiedergabe von Multimediainhalten auf heterogenen Plattformen ist schwierig, da Webbrowser zu deren Wiedergabe (von derartigen Inhalten) oft systemeigene Wiedergabekomponenten einsetzen. So kann zur Entwicklungszeit oft nicht vorhergesagt werden mit welcher Wiedergabekomponente, kurz „Player“, ein Medium abgespielt wird. Dies hat insbesondere zur Folge, dass ein Player auf einzelnen Seite 73

Methoden des Projektmanagements in moderner Softwareentwicklung

Systemen nicht verfügbar ist oder dass ein Player einzelne Codecs (Audio- oder Videoformate) nicht unterstützt und daher die Wiedergabe verhindert. Das Problem lässt sich durch eine plattformübergreifende und standardisierte Komponente, die fähig ist Multimediainhalte abzuspielen, umgehen. Diese Komponente stellt das Adobe Flash Plug-In dar, dass heute in zahlreichen Browsern integriert und für viele Internetbrowser verfügbar ist. Zum Abspielen von Multimediainhalten eines Benutzers, wie Videos oder Audiodokumente, muss das Medium in das sog. FlashVideo-Format konvertiert und mit einem speziellen Flash-Media-Player abgespielt werden. Diese Technologien gelten im Projekt zum jetzigen Stand als unbekannt und müssen daher als besonderes Projektrisiko näher untersucht werden. Können die beschriebenen Technologien nicht eingesetzt werden, besteht die Gefahr des Scheiterns des Projekts, sofern keine alternative Methode der plattformübergreifenden Wiedergabe gefunden werden kann.

Dieses

Risiko

sollte

Wegwerfprototypen,

durch der

einen, als

dem

restlichen

Machbarkeitsstudie

Projekt

vorgeschalteten,

die

technologischen

Rahmenbedingungen klärt, bewertet werden. So kann festgestellt werden, ob eine alternative Lösung gefunden werden muss und ob die Risiken mangelnder Erfahrung oder eines Silver Bullet Syntroms (siehe Abschnitt „9.3 Risikomanagement“) bestehen.

12.1.2.2 Design-Probleme: Unentdeckte Fehler durch mangelndes Feedback Durch die Entwicklung mit einem einzigen Entwickler ist, wie oben bereits erwähnt, das Risiko unentdeckter Fehler, insbesondere im Software-Design, in Ermangelung einer prüfenden Instanz im Projekt, erhöht. Der gewählte Entwicklungsprozess wirkt diesem Risiko passiv entgegen, da er eine relativ ökonomische Fehlerkorrektur zu jeder Zeit des Projekts gestattet.

Die Erstellung notwendiger technischer Dokumentationen begünstigt zusätzlich aktiv das Aufspüren von Mängeln und Fehlern im Projekt.

12.1.2.3 Qualitätsproblem: Entwicklerprägung Die starke Prägung auf einen einzelnen Entwickler kann die kostengünstige Änderbarkeit und Wartbarkeit des Produkts verhindern. Durch mangelndes Feedback kann ein Entwickler allein diesen Zustand nur schwer erkennen. Die technische Dokumentation des Projekts (Planung wie Durchführung) hilft jedoch, die Seite 74

Methoden des Projektmanagements in moderner Softwareentwicklung

Änderbarkeit und Wartbarkeit wiederum zu erhöhen und standardisierte Software zu entwickeln, da dem Vorgehen des Code and Fix entgegengewirkt wird.

12.1.3 Arbeitspakete Die Umsetzung des Projekts sollte zunächst in sinnvolle Arbeitspakete unterteilt werden. Dazu wird das Projektmanagementwerkzeug „Project“ der Firma Microsoft eingesetzt. Das Programm bietet umfangreiche Möglichkeiten der Projektplanung, Projektsteuerung und Projektüberwachung, wobei es hier lediglich für die Planung der Arbeitspakete und deren Abhängigkeiten eingesetzt wird. Project eignet sich insbesondere für mittlere und große Projekte, da die Pflege der Daten einen signifikanten Mehraufwand im Projektmanagement bedeuten können. Nach der o. g.

Definition des Kosten- und Nutzenbegriffs (siehe Abschnitt „6.2 Kostenminimierung“) ist der Einsatz in kleinen Projekten nur bedingt möglich.

Die Arbeitspakete werden zunächst ungeordnet definiert, ehe sie in Abhängigkeit zueinander gesetzt werden und ein Iterationsplan erstellt wird (siehe Tabelle 5).

Seite 75

Methoden des Projektmanagements in moderner Softwareentwicklung

Nr.

Vorgänger

Vorgangsname

Dauer

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

Plattformübergreifendes elektonisches Tagebuch 32,75 Tage?

Def inition der Anf orderungen 0,88 Tage?

2 Projektplanung 0,38 Tage?

3 Machbarkeitsstudien 2 Tage?

Umwandlung Medien in Flash-Videos 0,63 Tage?

5 Abspielen v on Flash-Videos im Browser 0,63 Tage?

6 Webserv erkonf iguration zum Streamen v on Flash-Videos0,75 Tage?

4 Realisierung verbindlicher Inhalte (Version 1.0) 14 Tage?

Analyse und Design 3,5 Tage?

Vorkonzeption der Anwendungsrealisierung (schematisch) 0,5 Tage?

Objektorientierter Entwurf der Klassen 2 Tage?

Datenbankentwurf 1 Tag? 10 Datenbank 1,75 Tage?

Datenbank und Tabellen auf setzen 0,63 Tage?

Kommunikationskomponente f ür Datenbankanf ragen1,13 erstellen Tage?

9 Implementierung (Klassen und Fachlogik) 7,75 Tage?

Erstellen der Klassen laut Entwurf 3 Tage?

Einbau der Fachlogik 1,5 Tage?

Oberfläche und Events 4 Tage?

17EE Anzeige des Tagebuchs (ASP.NET-Seite) 2,25 Tage?

17EE Eingabemaske f ür Text (ASP.NET-Seite) 1 Tag? 17EE Eingabemaske f ür Bilder und Medien (ASP.NET-Seite) 1 Tag? 9;13;16;19 Integration und Test 1 Tag 4;8 Realisierung optionaler Inhalte (Version 1.1) 15,5 Tage?

Analyse und Design 6,38 Tage?

Objektorientierter Entwurf der Klassen der optionalen Inhalte 2,5 Tage?

Erweiterung des Datenbankentwurf s um optionale Inhalte 0,75 Tage?

9 Datenbank 2,13 Tage?

Neue Tabellen auf setzen, bestehende ggf . erweitern 0,5 Tage?

Kommunikationskomponente f ür Datenbankanf ragen0,88 erweitern Tage?

9 Implementierung (Klassen und Fachlogik) 12 Tage?

Erstellen der Klassen laut Entwurf 3,5 Tage?

Einbau der Fachlogik 2,25 Tage?

Oberfläche und Events 4,5 Tage?

32EE Konf iguration (ASP.NET-Seite) 1 Tag? 32EE Login (ASP.NET-Seite) 1,13 Tage?

32EE POP3-Import (ASP.NET-Seite) 0,88 Tage?

32EE Tagebuch-Export (ASP.NET-Seite) 1,5 Tage?

25;28;31;34 Integration und Test 1,38 Tage Meilensteine 15,5 Tage 23 [Fertigstellung Version 1.0] 0 Tage 39 [Fertigstellung Version 1.1] 0 Tage

Tabelle 5 - Definition der Arbeitspakete für das plattformübergreifende elektronische Tagebuch „Pet“

12.1.4 Abhängigkeiten Die Abhängigkeiten der einzelnen Komponenten werden in Form eines GanttDiagramms dargestellt. Die Spalte „Vorgänger“ bezeichnet die Vorgangsnummer des Vorgangs, zu dem eine Abhängigkeit besteht. Eine Ziffernfolge in dieser Spalte bedeutet, dass eine Ende-Anfang-Beziehung besteht. Ende-Ende- werden durch das Suffix „EE“ und Anfang-Anfang-Beziehungen durch die Endung „AA“ gekennzeichnet.

Seite 76

Methoden des Projektmanagements in moderner Softwareentwicklung

Microsoft Project setzt aufgrund dieser Daten die Umsetzung in eine mögliche Reihenfolge (siehe Tabelle 6). Zur besseren Übersicht wurden die Bezeichnungen in Tabelle 6 abgekürzt (abgeschnitten). Die vollständigen Vorgangsbezeichnungen sind Tabelle 5 zu entnehmen.

Seite 77

Methoden des Projektmanagements in moderner Softwareentwicklung

Tabelle 6 - Abh채ngigkeiten der Arbeitspakete in einem Gantt-Diagramm

Seite 78

Methoden des Projektmanagements in moderner Softwareentwicklung

12.1.5 Iterationsplan Die Realisierung des Pet kann, wie beschrieben durch das Spiralmodell mit eingebetteten Vorgehensmodellen erfolgen. Es entstehen für die beschriebenen Merkmale vier Umläufe der Spirale, in denen jeweils das größte aktuelle Projektrisiko zuerst behandelt wird (siehe Tabelle 7).

Spiralmodell Umlauf 1

Iteration

Größtes Risiko

Inhalt der Iteration



Machbarkeitsstudie

2



3



4



Neue Technologie: Adobe Flash Video Design-Problem: Unentdeckte Fehler Qualitätsproblem: Entwicklerprägung Silver-Bullet-Syndrom: Vertrauen auf E-MailFunktion Design-Problem: Unentdeckte Fehler Qualitätsproblem: Entwicklerprägung Design-Problem: Unentdeckte Fehler Qualitätsproblem: Entwicklerprägung



Mehrere weitere

Realisierung der verbindlichen Merkmale

Optionales Merkmal: Import von Multimediaeinträgen von Mobiltelefonen über einen Mailserver Optionales Merkmal: Benutzerauthentifizierung

Optionales Merkmal: Tagebuch-Export

Mehrere weitere

Merkmale späterer Versionen

Tabelle 7 - Iterationsplan des Pet

12.1.5.1 Spiralmodell Umlauf 1  Machbarkeitsstudien zum Einsatz von Adobe Flash-Videos auf dem IIS 7Webserver in Form von Code and Fix Damit wird das größte Projektrisiko noch vor Beginn der Realisierung der Anwendung beherrschbar.

12.1.5.2 Spiralmodell Umlauf 2  Iterativ-inkrementelle

Realisierung

der

verbindlichen

Merkmale

des

plattformübergreifenden elektronischen Tagebuchs Dabei wird besonderes Augenmerk auf die bekannten Projektrisiken (siehe oben) gerichtet. Die Umsetzung erfolgt in einer einzigen Iteration.

Seite 79

Methoden des Projektmanagements in moderner Softwareentwicklung

12.1.5.3 Spiralmodell Umlauf 3  Iterativ-inkrementelle Umsetzung des optionalen Merkmals des Imports von Multimediaeinträgen von Mobiltelefonen über einen Mailserver Dabei sollte besonders dem Risiko des blinden Vertrauens in das gewählte Konzept der Übertragung von Multimediadaten per E-Mail vom Mobiltelefon zum PetServerrechner entgegengewirkt werden (Silver-Bullet-Syndrom). Der Einbau des Merkmals erfolgt in einer weiteren Iteration des inneren, iterativ-inkrementellen Vorgehensmodells.

12.1.5.4 Spiralmodell Umlauf 4  Iterativ-inkrementelle Realisierung der weiteren optionalen Merkmale, d. h.

Benutzerauthentifizierung und Tagebuch-Export Dabei wird wiederum besonderes Augenmerk auf die bekannten Projektrisiken (siehe oben) gerichtet. Da jede weitere Version (entspricht hier jeder Iteration) zeitnah ausgeliefert werden soll, werden die beiden Merkmale in je einer Iteration nacheinander implementiert.

12.1.5.5 Weitere Iterationen Die Weiterentwicklung des Pet kann im Anschluss in mehreren Iterationen erfolgen, die die Funktionalität weiter inkrementell hinzufügen.

1 2.2 Um s et zu ng de s P r oj ekt pl a ns 12.2.1 Machbarkeitsstudie In der vorgeschalteten Machbarkeitsstudie wird das größte Projektrisiko (siehe Abschnitt „12.1.2.1 Unbekannte Technologie: Flash-Video-Format“) untersucht und bewertet.

Es wird ein Wegwerfprototyp erstellt, der Erkenntnisse über die eingesetzten Technologien hervorbringen und so eine Bewertung des Risikos ermöglichen soll. Die wesentlichen Erkenntnisse werden im Folgenden dokumentiert:

Seite 80

Methoden des Projektmanagements in moderner Softwareentwicklung

12.2.1.1 Flash-Video-Format Konverter Das Flash-Video-Format kann mit Hilfe zweier frei verfügbarer Konverter erstellt werden. Es sind dabei zahlreiche Quellformate für die Konvertierung von Audio-, Video- oder Bild-Dateien möglich.  FFMPEG Komponente (Build 2007-02-12) (vgl. [WWW05])  FLVTool Komponente 4.1 (vgl. [WWW06]) Die FFMPEG Komponente konvertiert ein Quellmedium in das Flash-Video-Format, während das FLVTool zusätzliche Metadaten generiert und in das Flash-Video integriert. Eine Dokumentation der Komponenten ist auf den o. g. Internetseiten verfügbar. Eine beispielhafte Anwendung ist über diese Windows-Befehlszeilenaufrufe möglich: ffmpeg.exe -i test.avi test.flv flvtool2.exe -U test.flv

Die Datei „test.avi“ entspricht dabei einem Quellmedium und die Datei „test.flv“ dem konvertierten Flash-Video.

12.2.1.2 Webserverkonfiguration Um den Webserver IIS 7 für das Streaming (siehe Abschnitt „13.1.1 Verbindliche Merkmale“) von Flash-Videos zu konfigurieren sind verschiedene Schritte erforderlich.

Zunächst wird im IIS 7 die Handler-Zuordnung, d. h. die Zuweisung einer ScriptAusführung einer Datei oder zu einer Gruppe von Dateien (Dateityp), konfiguriert (siehe Abbildung 21). Dabei soll die Bearbeitung von Flash-Videos (Endung „.flv“) von Microsoft .NET übernommen werden.

Seite 81

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 21 - Handler-Zuordnung im IIS

Nun wird das Webprojekt der Machbarkeitsstudie angelegt, in der eine Klasse f端r das Streaming von Flash-Videos angelegt wird. Solcherlei einfache Klassen sind im Internet frei verf端gbar.

Inhalt der Klasse FLVStreaming.cs:

Seite 82

Methoden des Projektmanagements in moderner Softwareentwicklung

using System; using System.IO; using System.Web; public class FLVStreaming : IHttpHandler { // FLV header private static readonly byte[] _flvheader = HexToByte("464C5601010000000900000009"); public FLVStreaming() {} public void ProcessRequest(HttpContext context) { try { int pos; int length; // Check start parameter if present string filename = Path.GetFileName(context.Request.FilePath); using (FileStream fs = new FileStream(context.Server.MapPath(filename), FileMode.Open, FileAccess.Read, FileShare.Read)) { string qs = context.Request.Params["start"]; if (string.IsNullOrEmpty(qs)) { pos = 0; length = Convert.ToInt32(fs.Length); } else { pos = Convert.ToInt32(qs); length = Convert.ToInt32(fs.Length - pos) + _flvheader.Length; } // Add HTTP header stuff: cache, content type and length context.Response.Cache.SetCacheability( HttpCacheability.Public); context.Response.Cache.SetLastModified(DateTime.Now); context.Response.AppendHeader("Content-Type", "video/x-flv"); context.Response.AppendHeader("Content-Length", length.ToString()); // Append FLV header when sending partial file if (pos > 0) { context.Response.OutputStream.Write(_flvheader, 0, _flvheader.Length); fs.Position = pos; } // Read buffer and write stream to the response stream const int buffersize = 16384; Seite 83

Methoden des Projektmanagements in moderner Softwareentwicklung

byte[] buffer = new byte[buffersize]; int count = fs.Read(buffer, 0, buffersize); while (count > 0) { if (context.Response.IsClientConnected) { context.Response.OutputStream.Write(buffer, 0, count); count = fs.Read(buffer, 0, buffersize); } else { count = -1; } } } } catch (Exception ex) { System.Diagnostics.Debug.WriteLine(ex.ToString()); } } public bool IsReusable { get { return true; } } private static byte[] HexToByte(string hexString) { byte[] returnBytes = new byte[hexString.Length / 2]; for (int i = 0; i < returnBytes.Length; i++) returnBytes[i] = Convert.ToByte(hexString.Substring(i * 2, 2), 16); return returnBytes; } }

Da Flash-Videos mit dieser Klasse wiedergegeben werden sollen (Streaming), wird in der Datei „web.config“ die Einstellung für den Webserver festgelegt:

Seite 84

Methoden des Projektmanagements in moderner Softwareentwicklung

<?xml version="1.0"?> <configuration> <system.webServer> <handlers> <add name="flv" path="*.flv" verb="GET,POST,HEAD,DEBUG" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework \v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" preCondition="bitness32"/> </handlers> <validation validateIntegratedModeConfiguration="false"/> </system.webServer> <system.web> <httpHandlers> <add verb="*" path="*.flv" type="FLVStreaming"/> </httpHandlers> <compilation debug="true"/> </system.web> </configuration>

12.2.1.3 Flash-Video-Player Innerhalb einer HTML-Seite, bzw. einer ASPX-Seite mit ASP.NET-Code, wird nun der frei Verfügbare „Flash Media Player 3.5“ eingebunden:

Seite 85

Methoden des Projektmanagements in moderner Softwareentwicklung

<script type="text/javascript" src="ufo.js"></script> <p id="player1"><a href="http://www.macromedia.com/go/getflashplayer">Get the Flash Player</a> to see this player.</p> <script type="text/javascript"> var FO = { movie:"mediaplayer.swf",width:"336",height:"297", majorversion:"7",build:"0",bgcolor:"#FFFFFF", allowfullscreen:"true", flashvars:"file=test.flv&image=preview.jpg" }; UFO.create( FO, "player1"); </script>

12.2.1.4 Ergebnis

Abbildung 22 - Flash Media Player 3.5 mit konvertiertem Video

Ein Medium, etwa ein Video, kann nun konvertiert, mit Metadaten versehen und per Streaming von einem IIS 7-Webserver mittels eines Flash-Wiedergabeprogramms abgespielt werden (siehe Abbildung 22).

12.2.1.5 Schlussfolgerung Aufgrund der erfolgreichen Machbarkeitsstudie kann die neue Technologie nun als beherrschbar und das Risiko der unbekannten Technik als irrelevant eingestuft werden.

Das

Projekt

sollte

dabei

jedoch

auf

den

Erkenntnissen

dieser

Machbarkeitsstudie aufbauen und dieselben Technologien einsetzen.

12.2.2 Realisierung der verbindlic hen Merkmale Den genannten Risiken in diesem Umlauf des Spiralmodells, den möglichen DesignProblemen durch unentdeckte Fehler und den Qualitätsproblemen seitens einer Entwicklerprägung, soll die folgende Dokumentation entgegenwirken. Wie im Seite 86

Methoden des Projektmanagements in moderner Softwareentwicklung

Abschnitt

„9.4

Dokumentation“

beschrieben,

wird

eine

ökonomische

Dokumentationstiefe gewählt.

12.2.2.1 Objektorientierter Entwurf Zunächst wird eine objektorientierte Analyse bzw. ein objektorientierter Entwurf der Problematik erstellt. Da der Einbau der optionalen Merkmale des Produkts in die Diagramme auf dieser Ebene einen relativ geringen Mehraufwand bedeutet, andererseits jedoch die Integration der späteren Merkmale erleichtert, sind die Klassen, Attribute und Methoden dieser Inhalte bereits im Diagramm enthalten (siehe Abbildung 23).

Da der Fokus in diesem Schritt auf den verbindlichen Merkmalen liegt, ist eine Änderung des Diagramms im Bezug auf die optionalen Programmeigenschaften in den nächsten Iterationen, die diese realisieren, nicht ausgeschlossen.

Seite 87

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 23 - Objektorientierter Entwurf der Klassen f端r die verbindlichen und optionalen Inhalte

12.2.2.2 Datenhaltung Seite 88

Methoden des Projektmanagements in moderner Softwareentwicklung

Video- und Audioeinträge werden per Streaming über eine C#-Klasse an den Client übertragen. Die Ablage der Quelldateien im Dateisystem des Servers stellte sich in der Praxis gegenüber der Speicherung als BLOB (Binary Large Object) in der Datenbank als

günstiger

heraus.

Daher

werden

lediglich

die

Texteinträge

und

alle

Verwaltungsinformationen der Einträge in einer relationalen Datenbank gespeichert (siehe Abbildung 24).

Abbildung 24 - ER-Diagramm der relationalen SQL-Datenbank

Sämtliche Medien, wie Videos, Bilder oder Audiodateien, werden in einem eigens dafür vorgesehenen Medienordner auf dem Server abgelegt (siehe Abbildung 25). Dabei werden neue, eindeutige Namen vergeben, um Fehlern durch gleiche Benennung unterschiedlicher Dateien vorzubeugen.

Seite 89

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 25 - Ablage der Medien auf dem Server

12.2.2.3 Implementierung Die Implementierung der Fachklassen der Einträge und des Datenbankmanagers war, wie erwartet, vergleichsweise trivial. Bei der Umsetzung wurde hoher Wert auf einen gut nachvollziehbaren und „eleganten“ Code (vgl. [DIJ72]) gelegt und somit ein erhöhtes Maß an Qualität erzielt. Dazu gehören insbesondere die Einhaltung von Kodierungsrichtlinien („Coding-Guidelines“), wie sie auch in ähnlicher Form von der Firma Microsoft bei der Implementierung des .Net-Frameworks selbst angewendet werden. Dies sorgt sowohl projektintern, als auch projektübergreifend für eine einheitliche Semantik im Quellcode. Im Folgenden seien einige Beispiele dieser Coding-Guidelines genannt6:  Private Methoden und Attribute werden im sog. „Pascal-Case“ benannt, d. h. der erste Buchstabe wird klein geschrieben und jedes neue Wort beginnt ohne Leerschritt mit einem großen Buchstaben. Beispiel: showFileDialog()  Nicht-private Methoden und Attribute werden im sog. „Camel-Case“ benannt, d. h. dass im Gegensatz zum „Pascal-Case“ auch der erste Buchstabe groß geschrieben wird. Beispiel: ClearAllEntries()

6

Die tatsächlichen Kodierungsleitlinien können aus urheberrechtlichen Gründen nicht veröffentlicht werden.

Seite 90

Methoden des Projektmanagements in moderner Softwareentwicklung

 Die Benennung erfolgt auf englisch und hält sich an die objektorientierten Paradigmen, wie z. B. Substantive für Klassennamen. (vgl. [BAL05])  Nicht-private

Methoden

und

Dokumentationskommentaren

versehen

Attribute ,

die

werden

Aufschluss

über

mit Zweck,

Parameter und mögliche Ausnahmen des Feldes geben (siehe Abbildung 26).  Der Code ist frei von Redundanzen, wie einen unnötigem this vor objektinternen Feldern oder unnötiger Weise verwendeten Namespaces oder using-Direktiven.

Abbildung 26 - Dokumentation im Object-Browser von Visual Studio 2005

Sämtliche

natürlichsprachlichen

Zeichenketten

wurden

einer

Lokalisierung

unterzogen. Sie wurden aus dem Quellcode entfernt und sprachneutral durch Platzhalter benannt. Auf diese Weise ergeben sich mehrere Vorteile, die der Qualität des Quelltextes nützen:  Alle natürlichsprachlichen Texte des Projekts sind in einer Datei gebündelt und müssen im Falle der Bearbeitung nicht im Quelltext gesucht werden.  Ein Lektorat muss ausschließlich in dieser Datei stattfinden.  Die Übersetzung der Software in weitere Sprachen ist mit sehr geringem Aufwand möglich.

Seite 91

Methoden des Projektmanagements in moderner Softwareentwicklung

 Die Texte können leicht, z. B. durch externe Texter, bearbeitet werden.

Eine besondere Herausforderung in Bezug auf die Qualität des Quelltextes, waren die besonderen Bedingungen der Web-Anwendungsentwicklung. Der Code kann hier bei der Implementierung der Programmoberfläche an zahlreichen Stellen und in den verschiedensten

Varianten

hinterlegt

werden

und

wird

zur

Laufzeit

zu

unterschiedlichen Zeitpunkten ausgeführt.

Beispiele für Hinterlegungsmöglichkeiten von Quelltext für ASP.NET-Seiten und eigene Web-Steuerelemente:  „Code-Behind“ Jede Oberfläche, sprich ASP.NET-Seite, hat eine Datei, in der ein zu der Seite gehörender Server-Quellcode, z. B. in C#, abgelegt werden kann.  JavaScript Ein Code, der auf dem Client ausgeführt werden soll, kann in Form von JavaScript direkt in den Quellcode der ASP.NET-Seite geschrieben werden.  „Code-Block“ Im Code-Behind kann jedoch auch zur Laufzeit JavaScript dynamisch einer ASP.NET-Seite hinzugefügt werden.  Im Quelltext der ASP.NET-Seite selbst kann auch direkt ein Server-Quellcode hinterlegt werden.

Eine Seite oder ein Web-Steuerelement kann wiederum selbst ein oder mehrere WebSteuerelemente besitzen, deren Quelltext zur Laufzeit ebenfalls hinzugefügt wird.

Dies zeigt, dass im Vergleich zur klassischen Programmierung von Fenstersystemoder Dienstprogrammen der Quellcode der Oberfläche bei ASP.NET wesentlich heterogener und somit anfälliger für schlecht lesbaren Code ist.

Das folgende Klassendiagramm zeigt die verwendete ASP.NET Seite („_Default“), sowie die verwendeten eigenen Web-Steuerelemente (siehe Abbildung 27).

Seite 92

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 27 - Generiertes Klassendiagramm von Pet.Webserver.Client

Seite 93

Methoden des Projektmanagements in moderner Softwareentwicklung

Die Anwendung läuft komplett auf einer einzigen physischen ASP.NET-Seite ab, die ihren Inhalt vom aktuellen Status der Anwendung des Benutzers, der sog. Session, abhängig macht. So werden zur Laufzeit dynamisch bestehende Einträge angezeigt oder Eingabefelder zum Bearbeiten zur Verfügung gestellt.

Da die Anwendung auf dem Server hinterlegt ist, wird mit den meisten Benutzerinteraktionen ein Datentransfer zum Server und zurück, ein sog. „Postback“ ausgelöst, dass dem Server den neuen Status mitteilt und entsprechende Ereignisse („Events“) auslöst. In der ASP.NET-Entwicklung ist es nun wichtig, den Quelltext innerhalb der Methoden, die zu diesen Ereignissen aufgerufen werden, in der korrekten Reihenfolge zu gestalten. So ist beispielsweise zu beachten, dass die EventMethode Page_Load(…)

vor der Event-Methode SaveButton_Click(…)

und diese wiederum vor OnLoadComplete(…)

aufgerufen wird. Dies kann an der Praxis verschiedene Schwierigkeiten aufwerfen, die mit der Reihenfolge der Auslösung der Event-Methoden zusammenhängen.

Am Ende der Implementierung ist die mehrmalige selbstkritische Durchsicht und Verbesserung des Quelltextes der gesamten Anwendung wesentlich. Dabei sollten neben Schwachstellen und Ungereimtheiten auch weniger elegant implementierte Quellcodeabschnitte erkannt und überarbeitet werden.

12.2.3 Abschluss der Implementierung und Freigabe Am Ende der Implementierungsphase steht eine letzte kritische Auseinandersetzung mit den o. g. Risiken und Qualitätszielen (siehe „12.1.2 Risikomanagement im Projekt“).

Seite 94

Methoden des Projektmanagements in moderner Softwareentwicklung

12.2.3.1 Unbekannte Technologie: Flash-Video-Format Das Risiko wurde erfolgreich durch eine vorgeschaltete Machbarkeitsstudie minimiert.

In der Umsetzung konnte auf die Ergebnisse zurückgegriffen und somit die Lösung ohne weitere Probleme implementiert werden.

12.2.3.2 Design-Probleme: Unentdeckte Fehler durch mangelndes Feedback Sowohl das Design als auch die Programmfunktionalität wurden durch verstärkte kritische Selbstkontrollen und Tests überprüft. Jedoch kann in der Praxis

nicht

ausgeschlossen werden, eigene Fehler mehrfach zu übersehen. Dies stellt einen deutlichen Nachteil bei der Entwicklung in einem Ein-Mann-Team dar.

12.2.3.3 Qualitätsproblem: Entwicklerprägung Der Quellcode wurde durch das Ansetzen eines hohen Qualitätsmaßstabes kontrolliert. Durch die Anwendung von Richtlinien bei der Erstellung wurde ein den allgemeinen Industriestandards nahes Produkt geschaffen, dass auch von Dritten weiterentwickelt werden kann.

12.2.4 Lauffähiges Programm Die Webanwendung ist am Ende der Arbeiten lauffähig und erfüllt die im Pflichtenheft gestellten Anforderungen.

Im Abschnitt „

Seite 95

Methoden des Projektmanagements in moderner Softwareentwicklung

14 Anhang B: Bildschirmfotos der Anwendungâ&#x20AC;&#x153; wird die Funktionalität des Programms veranschaulicht.

Seite 96

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL V RESÜMEE UND AUSBLICK Die vorliegende Arbeit analysierte Methoden des Projektmanagements in moderner Softwareentwicklung mit dem Ziel einen Überblick über Möglichkeiten und Wege der erfolgreichen Projektdurchführung zu geben.

Es gibt eine Vielzahl von Modellen, von denen nur einige im Rahmen dieser Arbeit vorgestellt werden konnten. Die Modelle unterscheiden sich in ihrer Komplexität, ihren Rahmenbedingungen und der Fähigkeit der Anpassung an eigene Bedürfnisse. In Projekten,

die

eines

dieser

Modelle

erfolgreich

anwenden,

wird

die

Softwareentwicklung grundsätzlich disziplinierter gesteuert und so die Qualität der Software erhöht (siehe Abschnitt „8 Softwareentwicklungsprozesse“).

Im praktischen Teil der Arbeit wurden die gewonnenen Erkenntnisse auf ein verhältnismäßig kleines Projekt angewandt, dass von einer Einzelperson umgesetzt wurde. Dabei zeigte sich, dass sich viele der vorgestellten Modelle nicht oder nur unzureichend mit diesen beiden Gegebenheiten vereinbaren lassen. Die behandelten Modelle sind ausschließlich für mittlere bis große Projekte mit einigen bis vielen Projektmitarbeitern ausgelegt. Daraus folgert sich die Forderung nach Modellen, die

besonders

kleine

Projekte

mit

nur

einem

oder

wenigen

Projektmitarbeitern besser unterstützen.

Die praktische Arbeit hat zudem gezeigt, dass eine Herausforderung darstellt, ohne entsprechende Richt- oder Leitlinien die nötige Selbstdisziplin aufrecht zu erhalten, um nicht in den Stil des klassischen Code and Fix (siehe Abschnitt „8.1.1 Code and Fix“) zu verfallen. Diese Disziplin kann jedoch nur von erfahrenen Entwicklern erwartet werden. Dieser Umstand wird verschlimmert, sobald der Entwickler auch zugleich Projektleiter ist, also selbst die ausführende, kontrollierende und steuernde Instanz im Projekt darstellt, da eigene Fehler grundsätzlich leichter ignoriert, übersehen oder unterschätzt werden können.

Daher kann abschließend die Empfehlung ausgesprochen werden, auch in kleinen Projekten,

die

Kontrollinstanz

von

nur einer

einzuführen

Person und

durchgeführt

sich

Kodierungsrichtlinien) aufzuerlegen.

Seite 97

selbst

werden,

Richtlinien

eine (wie

externe z.

B.

Methoden des Projektmanagements in moderner Softwareentwicklung

Solche Kontrollinstanzen können Kollegen oder (wie in dieser Arbeit) Prüfer sein, denen der Quelltext präsentiert wird oder auch fremde Entwickler, die die Implementierung z. B. im Internet diskutieren.

Seite 98

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL VI ABKÜRZUNGSVERZEICHNIS .NET

.NET bezeichnet eine von der Firma Microsoft entwickelte Technologie, deren Kern mehrere Programmiersprachen bilden. Zu der .NET-Technologie gehören neben

einer

umfangreichen

Klassenbibliothek

eines

Vielzahl

von

Softwarewerkzeugen.

ASP.NET

Alle Komponenten der .NET-Technologie, die sich mit der Entwicklung von Web-Applikationen

befassen,

werden

unter

dem

Begriff

ASP.NET

zusammengefasst.

ASPX

Die Standard-Dateiendung von mit ASP.NET erstellen Seiten lautet „.aspx“.

C#

C# (gesprochen „C Sharp“) ist eine der von .NET zur Verfügung gestellten Programmiersprachen.

CDP

Der Cleanroom Development Process wird mit CDP abgekürzt (siehe Abschnitt „8.2.5 Cleanroom Development Process“).

HTML

Die Abkürzung HTML steht für „Hypertext Markup Language“ und ist als Auszeichnungssprache die Grundlage der Darstellung von Internetseiten.

IIS 7

IIS7 ist die Abkürzung für den Web-Server „Internet Information Server 7“ der Firma Microsoft.

MDA

Die „Model Driven Architecture“ wird mit MDA abgekürzt (siehe Abschnitt „8.1.5 Model Driven Architecture“)

MMS

Die Abkürzung MMS steht für „Multimedia Message Service“. Als MMS wird eine multimediale Nachricht von bzw. an Mobiltelefone bezeichnet, die Bilder, Videos, Töne und Text enthalten kann. Moderne Handys bieten meist die Möglichkeit MMS zu versenden und zu empfangen.

Pet

Abkürzung für das „plattformübergreifende elektronische Tagebuch“ (siehe Abschnitt „Teil IV Entwicklung eines plattformübergreifenden elektronischen Tagebuchs“).

Seite 99

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL VII ANHÄNGE 13 ANHANG A: PFLICHTENHEFT DES PLATTFORMÜBERGREIFENDEN ELEKTRONISCHEN TAGEBUCHS Das folgende Pflichtenheft beschreibt die Anforderungen und Rahmenbedingungen des Produkts und ist strukturell an den Aufbau eines Pflichtenhefts nach Balzert angelehnt (vgl. [BAL05]).

1 3 .1 Zi el be sti m m ung Ziel ist die Erstellung der ersten lauffähigen Version eines elektronischen Tagebuchs für den privaten Gebrauch. Dieses elektronische Tagebuch soll verschiedene Hardund Softwareumgebungen abdecken und neben den Texten eines klassischen Tagebuchs auch Multimediaelemente wie Videos, Tondokumente oder Bilder plattformübergreifend verfügbar machen.

In seiner ersten Version, auf die sich das vorliegende Pflichtenheft bezieht, soll das plattformübergreifende elektronische Tagebuch bereits die zur Führung eines multimedialen Tagebuchs wesentlichen Merkmale aufweisen.

Es handelt sich um eine Individualsoftware. Das Tagebuch soll nach der ersten Version sukzessive weiter entwickelt werden können, um in folgenden Versionen die Funktionalität weiter zu erhöhen. Ein Einsatz als frei verfügbare Standardsoftware in der Zukunft wird nicht ausgeschlossen.

13.1.1 Verbindliche Merkmale Die folgenden Merkmale sind im Produkt enthalten:  Intuitive Bedienbarkeit, ansprechende Benutzungsoberfläche  Pflege und Ansicht der Tagebuchinhalte  Pflege und Ansicht der verschiedenen multimedialen Inhalten im Tagebuch  Streaming von Multimediainhalten7  Navigation für die Ansicht der Tagebuchinhalte, inkl. Kalenderdarstellung  Unterstützung durch Automatismen in der Pflege der Inhalte  Möglichkeit der plattformübergreifenden Nutzung auf verschiedenen Systemen 7

d. h. Wiedergabe des Multimediainhalts bereits während (vor Beendigung) des Empfangs.

Seite 100

Methoden des Projektmanagements in moderner Softwareentwicklung

13.1.2 Optionale Merkmale Die folgenden Merkmale sollen im Produkt enthalten sein, können jedoch auch in einer späteren Version folgen:  Passwortschutz für den Einzelbenutzer (Singleuser)  Veröffentlichung von multimedialen Inhalten über Mobiltelefone  Export der Inhalte auf einen Datenträger 13.1.3 Abgrenzungskriterien Die folgenden Merkmale sind nicht Bestandteil des Produkts:  Mehrbenutzer- bzw. Mandantenfähigkeit ist zurzeit nicht vorgesehen; Die Anwendung ist für den Singleuserbetrieb ausgelegt.  Eine Veröffentlichung der Tagebucheinträge, wie in einem Weblog (BLOG) ist nicht vorgesehen.  Nicht jede Plattform wird unterstützt. Insbesondere an den Serverrechner können besondere Anforderungen gestellt werden. Mobiltelefone können nicht zur Anzeige des Tagebuchs genutzt werden.  Die Formatierung der Texteinträge ist nicht vorgesehen.  Ein automatisiertes Installationsprogramm ist zurzeit nicht vorgesehen.

1 3 .2 E i nsa t z 13.2.1 Anwendungsbereich Das Produkt wird im Heimbereich als persönliches Tagebuch eingesetzt.

13.2.2 Zielgruppen Das Produkt richtet sich an einen oder wenige einzelne Privatanwender, die es eigenständig einrichten und betreiben.

13.2.3 Betriebsbedingungen Der Betrieb der Anwendung sollte nach der Installation keine regelmäßigen Wartungsarbeiten erfordern.

Seite 101

Methoden des Projektmanagements in moderner Softwareentwicklung

1 3 .3 Um ge bung sa nf or de r ung e n Die Anforderungen an die Umgebung sind in die drei Kategorien „Software“, „Hardware“ und „organisatorisches“ unterteilt. Die Kategorien können sich in die drei folgenden Unterkategorien gliedern (siehe Tabelle 8).

Unterkategorie Entwicklungsrechner Clientrechner Serverrechner

Bedeutung Anforderungen an die Umgebung, um das Produkt herzustellen Anforderungen an die Umgebung des Rechners, den der Benutzer zur Pflege und Ansicht der Tagebucheinträge nutzt Umgebungsanforderungen an den Serverrechner, der die Tagebuchdaten verwaltet

Tabelle 8 - Gliederung der Umgebungsanforderungen

13.3.1 Software Die folgenden Aufstellungen geben Aufschluss über die benötigte Software: 13.3.1.1 Entwicklungsrechner  Microsoft Visual Studio 2005 (Express oder Team Suite)  Microsoft SQL Server 2005 Express  Microsoft Project  FFMPEG Komponente (Build 2007-02-12) (vgl. [WWW05])  FLVTool Komponente 4.1 (vgl. [WWW06])  Flash Media Player 3.5 13.3.1.2 Clientrechner  Microsoft Windows, Linux mit X-Window-System, Apple MacOS oder eingebettetes Betriebssystem (z. B. Nintendo Wii)  Jeder „HTML 4.01“-fähige Internetbrowser mit Adobe Flash Player 8 oder höher und JavaScript 1.5 oder höher8 13.3.1.3 Serverrechner  Microsoft Windows XP, 2003 Server oder Vista  Microsoft Internet Information Server 7 8

Als Beispiele sind die aktuellen Versionen von Internet Explorer, Opera oder Mozilla-Firefox zu nennen.

Seite 102

Methoden des Projektmanagements in moderner Softwareentwicklung

 Microsoft SQL Server 2005 Express  Microsoft .NET Framework 2.0 13.3.2 Hardware Hardwareseitig sind auf den jeweiligen Rechnern die folgenden Voraussetzungen empfohlen9: 13.3.2.1 Entwicklungs- und Serverrechner  Prozessor Athlon XP 1900+ oder höher  512 MB Arbeitsspeicher oder mehr  10-MBit-Lan

oder

Breitbandverbindung

mit

einem

Upstream

(Sendegeschwindigkeit) von mindestens 512 Kbit/s 13.3.2.2 Clientrechner  PC mit einem Prozessor Athlon XP 1900+ oder höher und 512 MB Arbeitsspeicher oder mehr  Apple Macintosh iMac G5 oder höher  Nintendo Wii  MMS-fähiges Mobiltelefon10  jeweils eine 10-MBit-Lan oder Breitbandverbindung 13.3.3 Organisatorisches  Die freie Verfügbarkeit der Lizenzen der für die Entwicklung eingesetzten Software muss geprüft werden.

1 3 .4 F unk ti o na l i tä t 13.4.1 Verbindliche Merkmale 13.4.1.1 Pflege und Ansicht der Inhalte Mittels des Internetbrowsers wird die grafische Benutzungsoberfläche des Clients (siehe Abschnitt „13.7 Grafische Benutzungsoberfläche“) aufgerufen.

9

Ein Einsatz mit geringerer Ausstattung kann die Performanz des Produkts negativ beeinflussen.

MMS steht für Multimedia Messaging Service, d. h. die Versendung von Multimediainhalt mit einem Mobiltelefon. Hier: Mobiltelefon, das Multimediainhalte an E-Mail-Adressen senden kann, siehe Abschnitt „Teil VI Abkürzungsverzeichnis“.

10

Seite 103

Methoden des Projektmanagements in moderner Softwareentwicklung

Es gibt vier verschiedene Arten von Einträgen im plattformübergreifenden elektronischen Tagebuch. Texteinträge bestehen aus einer oder mehreren Zeilen natürlichsprachlichen

Inhalts.

Bildeinträge

beinhalten

Fotos

oder

Grafiken.

Multimediaeinträge lassen sich in Audio- und Videoeinträge untergliedern, die akustische bzw. audio-visuelle Inhalte tragen. Bild- und Multimediaeinträge werden nötigenfalls in eine adäquate Größe verkleinert. Jedem Eintrag ist ein Datum des Eintragstages zugewiesen. Ein Eintragstag kann mehrere Eintragungen enthalten. Über einen Link können Multimediainhalte im Vollbildmodus und Bildinhalte in Originalgröße dargestellt werden.

Nach dem Start des Clients werden sofort die bereits verfassten Tagebucheinträge des letzten Eintragstages angezeigt. Dabei werden pro Seite alle Einträge nur eines Tages angezeigt. Über entsprechende Navigationsschaltflächen oder einen Kalender kann tageweise rückwärts und vorwärts navigiert werden. Bei der Verwendung der Navigationsschaltflächen werden Tage, an denen keine Eintragungen stattgefunden haben, übersprungen.

Jeder Eintrag hat je eine Schaltfläche zum Bearbeiten oder Löschen des Inhalts.

Das Löschen wird vor der Durchführung durch eine Sicherheitsabfrage bestätigt. Eine weitere Schaltfläche erlaubt das Neuanlegen eines Eintrags. Dabei muss zunächst gewählt werden, ob es sich um einen Text-, Bild- oder Multimediaeintrag handelt.

Für die Bearbeitung oder Neuanlage eines Eintrags wird eine Eingabemaske angezeigt unter der sich zwei Schaltflächen zum Speichern und zum Abbrechen befinden. Die Eingabemaske für Texteinträge beinhaltet ein Textfeld in dem der Inhalt editiert werden kann. Die Eingabemaske für Bild- und Multimediaeinträge beinhalten einen Dateiauswahldialog um ein (neues) Element festzulegen.

13.4.1.2 Plattformübergreifende Nutzung Die Ansicht, jedoch auch die Erstellung und Bearbeitung von Texteinträgen soll mit den o. g. Browsern auf verschiedenen Plattformen möglich sein.

Seite 104

Methoden des Projektmanagements in moderner Softwareentwicklung

13.4.2 Optionale Merkmale 13.4.2.1 Passwortschutz für den Einzelbenutzer (Singleuser) Durch ein Passwort, das der Benutzer beim Start des Client eingeben muss, werden seine Einträge vor Betrachtung und Veränderung durch Dritte geschützt. Über eine Schaltfläche kann jederzeit eine Konfigurationsseite zur Änderung des Passwortes aufgerufen werden.

13.4.2.2 Veröffentlichung von multimedialen Inhalten über Mobiltelefone Die Anwendung kann für die Veröffentlichung von Bildern und multimedialen Inhalten konfiguriert werden. Dazu werden auf der Konfigurationsseite die Zugangsdaten eines POP3-Servers (Posteingangsserver für E-Mails) und ein Codewort angegeben. Wird von einem MMS-fähigen Mobiltelefon per MMS eine E-Mail mit einem Bild oder Multimediaelement an die konfigurierte Adresse gesendet, wird es entweder automatisch oder per Mausklick mit dem Datum des Versands in das Tagebuch aufgenommen.

13.4.2.3 Export der Inhalte auf einen Datenträger Über eine Export-Schaltfläche kann das gesamte elektronische Tagebuch im HTMLFormat

in

ein

frei

wählbares

Verzeichnis

exportiert

werden.

Bilder

und

Multimediainhalte werden dabei ebenfalls exportiert.

1 3 . 5 Da te n Die Anwendung sollte durchschnittlich ca. einen Texteintrag und einen Bild- oder Multimediaeintrag von ca. 250 kB pro Tag über mindestens drei Jahre Verarbeiten können.

Dies

bedeutet

insgesamt

etwa

2190

Einträge

plus

274

MB

Festplattennettonutzung.

1 3 . 6 P er for m a nz Sämtliche Funktionen und Einträge sollen innerhalb weniger Sekunden verfügbar sein.

Durch den Einsatz von Hochgeschwindigkeitsnetzwerken und einem einzigen Benutzer der Anwendung ist die Steigerung der Performanz weniger bedeutsam.

Seite 105

Methoden des Projektmanagements in moderner Softwareentwicklung

1 3 . 7 Gr a fi s che Be nut zu ng s o be r fl 채 che Die folgenden Bilder zeigen den groben Aufbau einiger Anzeigeseiten und Eingabemasken der Anwendung. Dem Produkt dienen diese Abbildungen (siehe Abbildung 28 bis Abbildung 30) als grober Leitfaden:

Seite 106

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 28 - Ansicht der Tagebucheintr채ge

Seite 107

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 29 - Eingabemaske f체r Texteintr채ge

Seite 108

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 30 - Eingabemaske für Bilder- und Multimediaeinträge

1 3 . 8 Q ua l i tä ts zi e l e Die Änderbarkeit und Wartbarkeit des Produkts spielt eine entscheidende Rolle für die Weiterentwicklung folgender Programmversionen.

Die Benutzerfreundlichkeit der Anwendung stellt ein weiteres Qualitätsziel dar, da sie die Akzeptanz11 deutlich erhöhen kann.

Da das Erzeugnis im Produktiveinsatz sensible Daten enthält, muss es ausreichend stabil sein, um einen anwendungsbedingten Datenverlust zu verhindern.

11

Gemeint ist der Wille des Anwenders, das Produkt tatsächlich kontinuierlich zu benutzen.

Seite 109

Methoden des Projektmanagements in moderner Softwareentwicklung

14 ANHANG B: BILDSCHIRMFOTOS

DER

ANWENDUNG

Zusätzlich zu den in diesem Kapitel abgebildeten Bildschirmfotos befinden sich auf der beiliegenden CD-ROM Videos, die das Programm zur Laufzeit zeigen.

1 4 .1 An ze i g e de r E i nträ ge Die folgenden Abbildungen (siehe Abbildung 31 und Abbildung 32) zeigen das plattformübergreifende elektronische Tagebuch, während Einträge dargestellt werden.

Abbildung 31 - Anzeige der Einträge vom 01.01.2008

Seite 110

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 32 - Anzeige der Eintr채ge vom 02.01.2008

Seite 111

Methoden des Projektmanagements in moderner Softwareentwicklung

1 4 .2 N e ua nl ege n ei ne s Au di o ei ntr a gs Um einen neuen Audioeintrag anzulegen, wird die Schaltfläche „Neu“ betätigt, bevor „Neuer Audioeintrag“ gewählt wird (siehe Abbildung 33).

Abbildung 33 - Neuanlegen eines Audioeintrags

In der daraufhin erscheinenden Ansicht (siehe Abbildung 34) kann eine Audiodatei von der Festplatte ausgewählt werden. Das Datum des Eintrags, sowie die Uhrzeit können dabei frei gewählt werden. Mit dem Betätigen der Schaltfläche „Speichern“ wird der Audioeintrag dem Tagebuch hinzugefügt.

Seite 112

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 34 - Auswahl der Audiodatei

Seite 113

Methoden des Projektmanagements in moderner Softwareentwicklung

1 4 .3 E di ti er e n eine s Te xt ei ntr a gs Die Schaltfläche „Bearbeiten“ bietet die Möglichkeit, den Texteintrag zu editieren (siehe Abbildung 35).

Abbildung 35 - Auswahl eines Texteintrages zur Bearbeitung

In der folgenden Ansicht (siehe Abbildung 36) kann der Text sowie der Zeitpunkt des Eintrages beliebig geändert werden. Mit dem Betätigen der Schaltfläche „Speichern“ wird der Texteintrag dem Tagebuch hinzugefügt.

Seite 114

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 36 - Bearbeiten eines Texteintrags

Seite 115

Methoden des Projektmanagements in moderner Softwareentwicklung

1 4 . 4 E di ti er e n eine s V i de o ei ntr a gs Die Schaltfläche „Bearbeiten“ bietet die Möglichkeit, den Videoeintrag zu editieren (siehe Abbildung 37).

Abbildung 37 - Auswahl eines Videoeintrages zur Bearbeitung

In der folgenden Ansicht (siehe Abbildung 38) kann die Datei ersetzt, oder der Zeitpunkt des Eintrages verändert werden. Mit dem Betätigen der Schaltfläche „Speichern“ wird der Videoeintrag dem Tagebuch hinzugefügt.

Seite 116

Methoden des Projektmanagements in moderner Softwareentwicklung

Abbildung 38 - Bearbeiten eines Videoeintrags

Seite 117

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL VIII QUELLENVERZEICHNIS 15 LITERATUR [AND04]

Andressen Andreas, Komponentenbasierte Softwareentwicklung , Carl Hanser Verlag, 2004

[BAL05]

Belzert Heide, Lehrbuch der Objektmodellierung, Elsevier-Spektrum Akademischer Verlag, 2005

[ECK05]

Eckert Claudia, IT-Sicherheit, Oldenbourg Wissenschaftsverlag, 2005

[COC03a]

Cockburn Alistair, Agile Software-Entwicklung, mitp-Verlag, 2003

[COC03b] Cockburn Alistair, Use Cases effektiv erstellen , mitp-Verlag, 2003 [DEM99]

DeMarco Tom, Lister Timothy, Peopleware, Dorset House Publishing, 1999

[DIJ65]

Dijkstra

Edsger Wybe, Programming Considered as a Human

Activity, 1965 [DIJ72]

Dijkstra Edsger Wybe, The humble programmer, Cummun.ACM 15, 1972

[DOC02]

Doctorow Cory et al., Essential Blogging, O'Reilly, 2002

[EVJ06]

Evjen Bill et al., Professional ASP.NET 2.0, Wiley Publishing, 2006

[FEY04]

Feyhl

Achim

W.,

Management

und

Controlling

von

Softwareprojekten, Gabler Verlag, 2004 [LUD07]

Ludewig Jochen, Lichter Horst, Software Engineering, dpunkt.verlag, 2007

[MAC05]

MacDonald Matthew, Beginning ASP.NET 2.0 in C#, APRESS - Springer Verlag, 2005

[OES01]

Oestereich Bernd (Hrsg.) et al., Erfolgreich mit Objekt-Orientierung, Oldenbourg Wissenschaftsverlag, 2001

[PLA83]

Platz Gerhard, Methoden der Software-Entwicklung, Carl Hanser Verlag, 1983 Seite 118

Methoden des Projektmanagements in moderner Softwareentwicklung

[ZAH05]

Zahrnt Christoph, Richtiges Vorgehen bei Verträgen über IT Leistungen, dpunkt.verlag, 2005

[ZEP04]

Zeppenfeld Klaus, Objektorientierte Programmiersprachen, ElsevierSpektrum Akademischer Verlag, 2004

[ZEP06]

Zeppenfeld Klaus, Generative Software-Entwicklung mit der MDA, Elsevier-Spektrum Akademischer Verlag, 2006

16 INTERNET-QUELLEN Sämtliche Internet-Quellen beziehen sich auf den Stand vom 03.06.2007.

[WWW01] http://www.v-modell-xt.de [WWW02] http://www.cocoo.de [WWW03] http://hood-group.com [WWW04] http://www.omg.org/mda [WWW05] http://ffmpeg.mplayerhq.hu [WWW06] http://inlet-media.de/flvtool2 [GNU12]

Diese Abbildung wurde unter der GNU-Lizenz für freie Dokumentation (http://www.gnu.org/copyleft/fdl.html) veröffentlicht. Es ist erlaubt, die Datei unter den Bedingungen der GNU-Lizenz für freie Dokumentation, Version 1.2 oder einer späteren Version, veröffentlicht von der Free Software

Foundation,

zu

kopieren,

zu

verbreiten

und/oder

zu

modifizieren. Es gibt keine unveränderlichen Abschnitte, keinen vorderen Umschlagtext und keinen hinteren Umschlagtext.

Seite 119

Methoden des Projektmanagements in moderner Softwareentwicklung

TEIL IX ERKLÄRUNG Dortmund, den 3. Juni 2007 Hiermit erkläre ich, dass die Thesis von mir selbstständig verfasst und angefertigt wurde, nur die angegebenen Quellen und Hilfsmittel benutzt wurden und Zitate kenntlich gemacht wurden.

Florian Alexander Michalik

Seite 120