kunden (cu) - MediaArchiv

DIE KELLER’SCHE ROCHADE
Journal der fünften Iteration (R4) des Softwareprojekts im Studiengang
Medien- und Kommunikationsinformatik an der Hochschule Reutlingen
Fakultät Informatik
Medien- und Kommunikationsinformatik
Alteburgstraße 150
72762 Reutlingen
Deutschland
© Juni 2008
VORWORT
VORWORT
Dieses Journal zum Softwareprojekt erscheint zum
Abschluss der Iteration R4. Es ist das Zweite seiner Art und
es ist ein Journal mit neuen Vorzeichen. In diesem fünften
Durchgang des Projektplanspiels wurde ein Film über das
Planspiel selbst gedreht. Er hat das Rollenverständnis der
Teilnehmer des Projektes verändert. Er wird das Rollenverständnis zukünftiger Iterationen verändern. Und er wird
das Journal beeinflussen.
Ein Filmteam - ins Projekt integriert - bestehend aus
Mitarbeitern der Kundenfirma trésor secure systems drehte
den Film. Es war ein Projekt im Projekt und das hatte Einfluss
auf den eigentlichen Projektverlauf, weil alle Teilnehmer
ihre Rolle im Projekt zweimal lernen mussten: nach den
Regeln der Softwaretechnik - als Mitarbeiter der Entwicklerfirma ITera Group oder von trésor secure systems - und
nach den Regeln des Regisseurs - als Darsteller der Rolle im
Film -, wussten alle, wo sie im Projekt stehen. Da waren die
Bauern der Softwareentwicklung, die ihrer Königin huldigten, die wiederum ihrem König Kunden treu ergeben war.
Die anderen Figuren des filmischen Schachspiels standen
sich in ähnlich tragend tragischen Rollen gegenüber.
Das Journal ist vor diesem Hintergrund neu konzipiert
worden. Es wird keine geschlossenen Beschreibungen des
Planspiels, keine Vorstellungen des Projektes und keine
Rollenbeschreibungen liefern. Es wird auch keinen roten
Faden geben. Das SOP-Journal ist ein Forum geworden,
in dem sich die Figuren des Spiels kritisch akzentuiert zu
einzelnen, herausgehobenen Bereichen des SOP äußern.
Sie werden aus dem Projektgeschehen, dem Projektalltag
oder zu den Projektinhalten berichten. Sie werden kritisieren und in Frage stellen. Sie werden vergleichen und
Die Geschäftsleitung bietet Schach. [Film]
bewerten. Was sagt die Fachliteratur, was sagt die Praxis
zum Thema? Sie werden sich dem Fachkontext öffnen,
Aussagen aus der Fachliteratur an ihrer Projekterfahrung
reflektieren oder umgekehrt.
Wer genau sind diese Figuren? Es bleibt der Fantasie
des Lesers überlassen, ob er den Qualitätssicherer der
ITera Group, den Turm des Schachspiels oder Studierende
des sechsten Semesters der Medien- und Kommunikationsinformatik der Hochschule Reutlingen als Autor ansieht. Der Qualitätssicherer ist nun mal der Turm in der
Schlacht ums Dokument. Der Spielplan des Planspiels
beschert ihm seine Rolle, das Drehbuch des Films seine
Metarolle und ausbaden muss es der Student persönlich.
Er muss die Arbeit schaffen und er wird seinen Lohn nach
Hause tragen.
Viel Spaß beim Lesen!
Wolfgang Keller, Geschäftsleitung
SOP JOURNAL R4
3
EDITORIAL
ZUG UM ZUG
Das Planspiel der Medien- und Kommunikationsinformatik
Zweimal im Jahr, stets zu Beginn eines jeden Semesters, wird sie an der Hochschule Reutlingen vollzogen: die
Keller’sche Rochade. Die Figuren werden getauscht, einige
verschwinden komplett vom Brett, andere wechseln die
Stellung und die Dritten betreten die Spielfläche neu als
unwissende aber hochmotivierte Studenten der Medienund Kommunikationsinformatik.
Den Überblick über das Geschehen im Spiel, welches
den Titel „Softwareprojekt“ trägt, behält kein Schachcomputer, sondern die Geschäftsführer Prof. Dr. Wolfgang
Keller und Prof. Dr. Uwe Kloos. Sie achten darauf, dass
die Spieler bzw. Studenten ihre eingenommenen Rollen
ausführen und bewerten zusammen mit ihren Kollegen die
Resultate.
Ziel des Spiels ist es, den Studenten möglichst realistisch zu vermitteln, wie die spätere Arbeit in einem Projektteam aussehen kann. Als studienspezifischer Rahmen
dient die Entwicklung einer Langzeitarchivierungssoftware.
Hierzu erfolgt die Aufteilung in zwei virtuelle Firmen, die
Entwicklerfirma und die Kundenfirma. Die Studenten müssen sich selbst organisieren, Entscheidungen treffen und
Verträge aushandeln.
Das Spiel besteht aus sich wiederholenden Phasen, die
Spieldauer ist also praktisch endlos. Es wird über sogenannte Iterationen gesprochen, von denen sich jede über
die Dauer des fünften und sechsten Semesters erstreckt. Es
laufen also immer zwei Iterationen parallel.
Wie aber genau funktioniert dieses Spiel „Softwareprojekt“? Welche Positionen gibt es, welche Strategien und
wo lauern die Probleme und Herausforderungen?
Antworten auf diese Fragen finden Sie in diesem Projektjournal. Die Artikel wurden von Studenten der fünften
Iteration des Spiels verfasst und geben einen Rückblick
über den Zeitraum von Oktober 2007 bis Juni 2008.
Wie wir auf die Assoziation zum Schachspiel gekommen sind? Im Grunde unterscheidet sich das Softwareprojekt nur durch lebende Figuren und ein räumliches Spielbrett: die Figuren sind Studenten, das Spielbrett ist die
Hochschule. Der Rest ist bei beiden gleich:
Zwei Spieler – zwei Professoren, zwei Farben – zwei
Iterationen, sechs Figuren – sechs Teams:
Kunde
Königin Projektleiter
Läufer Konfigurationsmanager
Springer Tester
Turm Qualitätssicherer
Bauer Softwareentwickler
König
Logisch oder?
Die Spieler stellen die verwirrten Figuren auf das Brett,
machen Züge und bewerten diese. Es treten bedrohliche
Situationen und Momente der Entspannung auf. Ein ständiges auf und ab.
Nach Ende der Partie nehmen die Spieler die Figuren
vom Brett und entlassen sie gut vorbereitet auf das größte
Spielbrett, welches in dieser Welt bekannt ist:
Das Berufsleben.
In diesem Sinne: Eine schöne Partie, viel Spass beim Lesen!
Tobias Ripperger, Chefredakteur
SOP JOURNAL R4
5
I N H A LT
INHALTSVERZEICHNIS
03
VO RW OR T
05
E D I T O R IA L
08
PE O PL E
Die Teilnehmer in Wort und Bild
10
D E R PE R S ON A LF Ü HR E R
Diktatur ist keine Lösung
12
K E I NE S T R U K T U R - K E IN P LA N !
Einführung einer systematischen Projektstrukturplanung
KUNDEN (CU)
15
D I E GR AT WAN DE R UN G
Das Softwareprojekt zwischen Anspruch und Realität
18
K O M MU N IK AT ION W ILL G E L E R N T SEIN
K O N FIG U RATIO N S - U N D ÄNDERUNGSMANAGEMENT ( CM)
21
GE K L O N T E G R Ü N E S E RV E R
Der Einsatz von Virtualisierungstechnologie im Softwareprojekt
24
A L L E D E N K E N R AT ION A L
Werkzeuge von IBM - Eine Hilfe für das Softwareprojekt?
27
T RO U B LE S HOOT IN G
Der Weg zur Lösung eines Problems
6
PROJEKTMANGEMENT (PM)
S O F T WA R E E N T W I C K L U N G ( S E )
30
NI CH T S A LS D IE WAH R HE IT ?
Die Kommunikation im Softwareprojekt
33
T. E . A . M.
Toll, Ein Anderer Macht’s?
SOP JOURNAL R4
I N H A LT
INHALTSVERZEICHNIS
IMPRESSUM
Sitz der Redaktion
Hochschule Reutlingen
Alteburgstraße 150
D-72762 Reutlingen
Telefon: +49 (0)7121 271-0
www.hochschule-reutlingen.de
36
PL A N UN G OD E R C H AOS ?
Die Rolle der Planung bei der Einführung der “Model Driven Architecture”
40
SO P WAR S : K R IE G D E R A B T E ILU NG EN
Die Zusammenarbeit der Softwareentwicklung mit anderen Abteilungen
43
PRO B LE ME B E I DE R K OLL A B OR ATION IN D ER SOF TWA REEN TWICKL U N G
. . . und das Chaos bei der Verwaltung gemeinsamer Arbeitsmittel.
46
RAT I O N AL R OS E
Sinn und Unsinn eines UML-Werkzeugs
49
L E BT D E R K U N D E IN E IN E R T R AU MWELT?
Kundenanforderungen an die Hardware des Langzeitarchivierungssystems
52
H I L F E IC H B IN E IN S OF T WA R E E N TWICKL ER - H OLT MICH H IER RA U S!
55
58
TESTING (TE)
U NT E R S C HÄ T Z ME IN N IC HT
Irrtum und Ignoranz beim Testen
E I N P R OJ E K T Z WIS C H E N MODE LL U N D BERU F SA L LTA G
Kann ein Planspiel eine gute Vorbereitung für das Berufsleben sein?
QUALITÄTSSICHERUNG (QS)
61
D A S S Y S T E MAU DIT IM S OFT WA R E PROJ EKT
64
Z W I SC H E N C HE F U N D LA UF B U R S CH E
Die Qualitätssicherung im Softwareprojekt
67
FILMTEAM (KUNDEN)
D A S H E E R D E R D IN G E
Drei Studenten auf dem Weg des Filmemachens
70
D E R WAH N S IN N S D R E H
oder: Was das Filmen so schwierig macht.
73
H E RR D E R A N IMAT ION
Einmal “Gott spielen”
74
H erausgeber
Hochschule Reutlingen
Fakultät Informatik
Medien- und Kommunikationsinformatik
Softwareprojekt Iteration R4
Chefredakteu r
Tobias Ripperger
Redaktion
Philipp Becker
Chrstine Heberle
Markus Leyrer
Wencke Schulz
Kha Tran
Satz und Layout
Tobias Ripperger
Fotografie
Kha Tran
Redaktionsbera t erin
Franziska Strobusch
D ruck
Frick Digitaldruck
Brühlstraße 6
86381 Krumbach
www.online-druck.biz
A utoren
Marc Amon, Philipp Becker, Laura Böhm,
Fabian Flohr, Michael Garcorz, Daniel
Grbavac, Diana Hauser, Christine Heberle,
Jacqueline Jonigkeit, Robert Krüger,
Achim Lang, Markus Leyrer, Alexander
Paharukov, Tobias Ripperger, Sebastian
Schulz, Wencke Schulz, Thomas Sellner,
Patrick Theurer, Tobias Thieme, Kha Tran,
Armin Wälder, Emre Yay
Kein Teil dieser Publikation darf ohne
ausdrückliche schriftliche Genehmigung
der Redaktion in irgendeiner Form reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt
oder verbreitet werden.
Die Rechte an den einzelnen Artikeln verbleiben bei den jeweiligen Autoren.
A D RE S S E N LIS T E
SOP JOURNAL R4
7
PEOPLE
PEO
PLE
8
Die Teilnehmer der Iteration R4 in Wort
und Bild. In Klammern das Team, welchem
sie angehörten und ihr Statement zum
Softwareprojekt.
Prof. Uwe Kloos (Geschäftsleitung):
„be hard in facts and soft in act”
Prof. Wolfgang Keller (Geschäftsleitung):
„Diese Iteration hat die Schranken zwischen
Gedöns und Kommunikation erfolgreicher
geöffnet, wie ich das erhofft hatte.”
Philipp Becker (PM): „Das Kindermädchen,
das an alles denken und sich um alles kümmern muss.“
Kha Tran (PM): „Wenn die Software nicht
funktioniert, nennen wir sie einfach Beta!”
Armin Wälder (CM): „Diese Bugs in der
Software schafft kein Kammerjäger.”
Jacqueline Jonigkeit (CM): „CM ist cool nicht nur wegen der Klimaanlage im Serverraum.”
Marc Ammon (CM): „IBM Rational: Das
Gammelfleisch unter den Entwicklungstools.“
Laura Böhm (TE): „Ist der Abnahmetest gut
gelaufen, wird es der Kunde gerne kaufen.“
Christine Heberle (TE): „ Zeig mir dein
Programm und ich zeig die seine Fehler.“
Daniel Grbavac (QS): „Das Projekt ist wie
eine Wundertüte, man weiß nicht, was einen
erwartet“
Patrick Theurer (QS): „Entscheidend ist nicht
was man tut, sondern wie man es tut!“
SOP JOURNAL R4
PEOPLE
Diana Hauser (SE): „Läuft!“
Sebastian Schulz (SE): „Im SOP geht es
primär darum sich gut zu präsentieren, das
ist schade.”
Thomas Sellner (SE): „Wer zuletzt lacht, hat
im Vitero den höchsten Ping.“
Alexander Paharukov (SE): „Die Kundenanforderungen im SOP entsprechen vollkommen
denen in der Wirtschaft- unpräzise und auf
den ersten Blick vollständig.“
Michael Garcorz (SE): „Das macht dann die
nächste Iteration und schuld ist die Letzte.”
Tobias Thieme (SE): „Als Entwickler gehör ich
zur Gruppe derer, ohne die das Projekt keines
wäre, da der Kern fehlen würde.”
Emre Yay (SE): „Der Job eines Softwareentwicklers ist warten, warten, warten.“
Robert Krüger (SE): „SOP: Sicheres Auftreten
bei völliger Ahnungslosigkeit.”
Wencke Schulz (CU):
„Es wird viel erzählt und noch viel mehr
verschwiegen!“
Achim Lang (Film): „Ohne Dokumentation ist
ein Projekt verloren ... und den Dokumentationsfilm machen wir!“
Markus Leyrer (CU):
„Gut Ding will Weile haben - Entwicklung
braucht seine Zeit“
Tobias Ripperger (Film): „Entertainment XXL“
Fabian Flohr (Film): „Die Kamera war nicht an
- bitte das Ganze noch einmal!“
SOP JOURNAL R4
9
PROJEKTMANAGEMENT
DER PERSONALFÜHRER
Diktatur ist keine Lösung
Bei der Personalführung wird
zwischen zwei Führungsstilen unterschieden: dem autoritären und dem
kooperativen Führungsstil. Der kooperative Führungsstil bezieht Mitarbeiter in den Entscheidungsprozess mit
ein, im Gegensatz zum autoritären
Stil. Wie bei einer Diktatur gilt beim
autoritären Stil die uneingeschränkte
Herrschaft eines Einzelnen. Vorgesetzte treffen ihre Entscheidungen
alleine, ohne Begründung und häufig
willkürlich. Doch ist dies der Weg zum
Erfolg? Und welche Faktoren sind zu
beachten um den „richtigen Ton“ zu
wählen?
Ein autoritärer Führungsstil kann Misstrauen erzeugen, da Entscheidungen
nicht begründet werden und zu Unselbstständigkeit führen, wenn keine
Eigeninitiative gefordert wird. Die Arbeitszufriedenheit und Leistungsbereitschaft
sind gering. Der Vorgesetzte verfügt über
besseres Fachwissen und die höhere
Einsicht, durch welche er alle Aufgaben
überblickt und verteilt. Der Mitarbeiter
erhält nur die Informationen welche er für
die Durchführung seiner Arbeit benötigt
(vgl. [1]).
Innerhalb des autoritären Führungsstils
unterscheidet man aufgrund der Rechtfer-
10
SOP JOURNAL R4
tigung der Führungsrolle folgende Stilarten
(vgl. [2]):
• Patriarchalischer Führungsstil: Der
Vorgesetzte ist in jeder Hinsicht überlegen
(z.B. Fachwissen, Erfahrungen,…)
• Autokratischer Führungsstil: Statt
einem Vorgesetzten gibt es einen ganzen
Führungsapparat, welcher eine Trennung
von Entscheidung und Durchsetzung erlaubt.
• Bürokratischer Führungsstil: Der
Vorgesetzte ist kein Alleinherrscher,
sondern ist ein Teil einer hierarchischen
Struktur. Führungsaufgaben und Befugnisse
sind aufgeteilt.
Die
Vorteile
des
autoritären
Führungsstils liegen in der hohen Entscheidungsgeschwindigkeit, in der Übersichtlichkeit der Kompetenzen und in der
guten Kontrolle bei der Bewältigung von
standardisierten Arbeiten und Prozessen.
Die Probleme: Anfälligkeit für Fehlentscheidungen, es kann zu Rivalitäten kommen
und ein Ausfall des Vorgesetzten führt
zum Stillstand.
Was bedeutet dies in Bezug auf das
Softwareprojekt? Gegen den patriarchalischen Führungsstil spricht, dass es
theoretisch keine Überlegenheit in Bezug
auf Kompetenzen geben dürfte, da alle Studenten des Softwareprojekts den gleichen
Studienstand haben sollten. Eine klare
Trennung von Entscheidung und Durchsetzung ist personell nicht möglich da
die Anzahl der Projektteilnehmer zu gering ist. Somit scheidet auch der autokratische Führungsstil aus. Ein bürokratischer
Führungsstil beruht auf einer existierenden
Hierarchie und Vorschriften welche in der
Iteration R4 aber nicht gegeben sind.
Aufgrund
fehlender
Druckmittel
scheidet ein rein autoritärer Führungsstil
aus. Abmahnungen, wovon zwei in der
Regel zu einer Entlassung führen, haben
im Projekt keine direkten Konsequenzen,
da der Ausschluss eines Einzelnen vom
Softwareprojekt nicht möglich ist.
Das Informieren der Geschäftsleitung
lässt die Interpretation zu selbst in seiner
Führungsrolle versagt zu haben.
Der kooperative Führungsstil erzeugt
Vertrauen und Selbstständigkeit. Die
Arbeitszufriedenheit
und Leistungsbereitschaft sind hoch (vgl. [1]). Der
Vorgesetzte bezieht seine Mitarbeiter in
den Entscheidungsprozess mit ein und
erwartet sachliche Unterstützung. Der
Vorgesetzte wird entlastet. Offene Kommunikationsstrukturen führen in der Regel
zu einem angenehmen Arbeitsklima. Auch
die Mitarbeiter profitieren von den Einblicken in die Aufgabengebiete der anderen Abteilungen, sie erlernen dadurch
eventuell neue Fähigkeiten und entwickeln
PROJEKTMANAGEMENT
Abbildung 1 (vgl. [1])
Verständnis für die Probleme der anderen
Abteilungen.
Die Probleme: nicht jeder Mitarbeiter
kann selbstständig arbeiten. Ebenso werden Distanzen zwischen Vorgesetzten
und Untergeben abgebaut und für den
Prozessablauf wichtige Hierarchien können verwischen. Auch die Geschwindigkeit des Arbeitsprozesses ist viel langsamer und auch teurer, da die Meetings
zum Informationsaustausch Geld kosten.
Hinsichtlich des gemeinsamen Ziels,
mit dem Erfolg des Softwareprojekts eine
gute Note zu erzielen, scheint ein kooperativer Führungsstil der richtige Weg zu sein.
Der erfolgreiche Abschluss der Iteration
bietet meist schon genügend Motivation
zur Mitarbeit. Für das Projektmanagement
entwickelt sich dadurch eine angenehme
Eigendynamik. Die Gruppe selbst übt aus
Angst vor einer schlechten Benotung,
Druck auf diejenigen aus, welche den Erfolg des Projekts gefährden könnten.
Das Softwareprojekt ist in seinen
Grundstrukturen bereits auf einen kooperativen Führungsstil ausgelegt. Zwei
Meetings pro Woche sorgen für einen
ständigen Kontakt zwischen den Vorgesetzten und den Mitarbeitern. Bereits in
der von der Geschäftsleitung veröffentlich-
ten Beschreibung des Statusgespräches
steht, dass die Abwicklung des Projekts
be-sprochen werden soll. Diese Dinge
wären bei einem autoritären Führungsstil
unnötig, da die Projektabwicklung für die
Mitarbeiter nicht zur Debatte stände und
die Aufgabenverteilung und deren Statusabfrage auch per E-Mail erfolgen könnte.
Ein
autoritärer
Führungsstil
ist
aufgrund der sich ständig ändernden Aufgabe und einer limitierten Fachkompetenz
des Vorgesetzten schwer zu realisieren.
Zwar kann durch den autoritären Stil viel
Zeit und Geld durch weniger Meetings
und einem geringeren Kommunikationsaufwand gespart werden, wiederum ist
die Projektleitung auf das Fachwissen
seine Mitarbeiter angewiesen, um die sich
ständig ändernden Anforderungen bewerten und bearbeiten zu können.
Die Wahl des richtigen Führungsstils
hängt auch von den Teammitgliedern der
jeweiligen Iteration ab. Mitarbeiter, die
sich schwer motivieren lassen und nicht
in der Lage sind eigenverantwortlich zu
arbeiten, erfordern einen eher autoritären
Führungsstil. Durch weniger Meetings und
Diskussionen kann zudem Geld gespart
werden. Damit hängt jedoch der Erfolg
der jeweiligen Iteration allein von der
Kompetenz der Projektleitung ab, da diese
die Entscheidungsgewalt hat. Die Projektleitung hat einen Mehraufwand durch die
Aufgabenkontrolle seiner Mitarbeiter.
Motivierte und verantwortungsbewusste Mitarbeiter entlasten die Projektleitung durch weniger Kontrollmaßnahmen
und eine geringere Wahrscheinlichkeit
von Fehlentscheidungen. Der kooperative
Führungsstil bezieht die Mitarbeiter in den
Entscheidungsprozess ein, jedoch entstehen durch viele Meetings erheblich höhere
Kosten und auch die Geschwindigkeit von
Entscheidungs- und Arbeitsprozessen
wird gedrosselt.
Der Projektleiter muss abhängig von
seinem Team ein gesundes Mittelmaß
zwischen kooperativem und autoritärem
Führungsstil finden. Er muss durch die offenen Strukturen eines kooperativen Stils
motivieren und von dem Wissen seiner
Mitarbeiter profitieren, aber auch erkennen
können, wann er schnelle Entscheidungen
alleine treffen und durchsetzen muss.
Philipp Becker, Projektmanagement
Quellen
[1] May/Fuß/Beer „Allgemeine Wirtschaftslehre für Büroberufe“ 10. Auflage 2007, S.61 ff.
[2] Hartmann/Härter, „Spezielle BWL der Industrie“ Merkur Verlag Rinteln, 12. Auflage 1995, S.244 ff
SOP JOURNAL R4
11
PROJEKTMANAGEMENT
KEINE STRUKTUR - KEIN PLAN!
Einführung einer systematischen Projektstrukturplanung
Aller Anfang ist bekanntlich schwer,
dies gilt insbesondere für Softwareprojekte. Erfahrungswerte müssen nicht zwingend von Nutzen sein, da sich Softwareprojekte stark voneinander unterscheiden.
Gerade erfahrene Mitarbeiter scheinen mit
dem Gedanken konfrontiert zu werden,
ein Projekt durch Erfahrung in kürzerer Zeit
schaffen zu können. Nach Thaller ([1],
S.39) tritt bei Mitarbeitern und Projektleitung häufig der Wunschgedanke auf, ein
Softwareprojekt in kürzerer Zeit realisieren
zu können, aufgrund von Erfahrungswerten
und Projekte unter ähnlichen Bedingungen
in der Vergangenheit. Sofern die Firma
die Anzahl der Entwickler nicht erheblich
gesteigert hat und den Entwicklungsprozess zu vergangenen Projekten verbessert
hat, spricht nichts für eine schnellere Realisierung eines Projektes.
Um eine solide Ausgangslage für die
Planung und Durchführung eines Softwareprojektes bewerkstelligen zu können,
benötigt das Projektmanagement eine
fundierte systematische Herangehensweise bei der Planung.
Gesucht ist nach einem Leitfaden,
welcher die Struktur eines Projektes abbilden soll.
Dabei ist der Umfang eines Softwareprodukts für den Komplexitätsgrad der
Strukturierung im Projekt verantwortlich.
12
SOP JOURNAL R4
Für die Projektleitung heißt das:
Sorgfältige Planung der einzelnen Projektphasen, dazu die Definition von Aufgaben
erstellen und diese für die Koordination
strukturieren.
Schwierig wird es jedoch dann, wenn
ein Projekt nicht neu beginnt, sondern
weitergeführt werden soll.
Dieser Fall trifft auf das Softwareprojekt an der Hochschule Reutlingen zu,
welches die Zusammenarbeit in größeren
Softwareprojekten simulieren soll. Dabei
ist das Vorgehen iterativ, also Schritt für
Schritt. Dies spannt sich über mehrere
Semester, sodass nach jeder Iteration das
Softwareprojekt mit all seinen Artefakten,
Entwicklungen, Dokumenten und Problemen an das nächste Semester übergeben
wird.
Um das Softwareprojekt weiterzuführen ist die Einarbeitung in das Projekt,
also die Ermittlung des aktuellen Stands
unumgänglich. Dazu gehören Aufgaben,
wie Dokumente sichten, Gespräche mit
Vorgängeriterationen führen und sich in
die Artefakte vergangener Phasen einzuarbeiten.
Im Unterschied zum Neuanfang eines
Softwareprojekts, wird man regelrecht
von Dokumenten überflutet. Durch die
hohe Anzahl verschiedenster Dokumente
und die unstrukturierte Dokumenten-
haltung in unserem Softwareprojekt sehen
Projekteinsteiger „vor lauter Bäumen den
Wald nicht mehr“. Dokumente können in
den seltensten Fällen korrekt priorisiert
werden.
Das Chaos gilt nicht nur für den Projektstart, sondern kann auch auf den gesamten
Entwicklungsprozess projiziert werden.
Insbesondere für die Projektleitung
ist der Gesamtüberblick über das Softwareprojekt ein MUSS. Dies stellte sich
in unserem Softwareprojekt als äußerst
schwierig dar, denn kein Artefakt oder
Dokument enthielt Informationen über die
Struktur im Projekt.
Nur mühsam ist die Ermittlung des
aktuellen Stands über Projektpläne und
andere Dokumente. Thaller1 [SoPM03,
S.34] erwähnt im Zusammenhang mit
„klassischen Fehlern“ auch das Problem
einer „zu ausführlichen und detaillierten
Spezifikation“. Dies bezieht sich zwar auf
die Entwicklung der Software, aber ein
ähnliches Problem tritt bei der Übergabe
des Softwareprojektes an die Nachfolgeiteration auf: Es gibt viele Dokumente,
aber kein Dokument das die Struktur des
Softwareprojektes visualisiert, welches
bei der Einarbeitung einen großen Wert
hätte.
PROJEKTMANAGEMENT
Weiß und ahnungslos - Ein neues Semester wird auf das Spielfeld gestellt. [Film]
Struktur im Softwareprojekt!
Die Einführung eines neuen Artefakts
ist daher empfehlenswert. Die Rede ist
von einem sogenannten Projektstrukturplan (PSP), welcher von Projektmagazin.
de [2] folgendermaßen definiert wird:
„Die Praxis der Projektstrukturplanung
präzisiert den PSP allerdings gemeinhin als
die vollständige hierarchische Anordnung
aller Elemente eines Projektes.“
Die Definition präzisiert den Projektstrukturplan im Gegensatz zur Definition
nach DIN 69901, als eine hierarchische
Anordnung der Elemente in einem Projekt.
Netzplan und Balkenplan, welche in der
DIN-Definition zu PSPs zählen, sind somit
in der Praxis nicht zwingend als Projektstrukturpläne anzusehen.
Es gibt verschiedene Ansätze bei
der Erstellung eines Projektstrukturplans.
Meines Erachtens schöpft eine visualisierte
Form des Projektstrukturplans das Potential
eines solchen am Besten aus. Durch die
Visualisierung sind Struktur und kritische
Pfade schnell zu erkennen.
Das Projekt wird als Gesamtaufgabe
gesehen, das aus verschiedenen Arbeitspaketen besteht. Diese Arbeitspakete
lassen sich wiederum in Teilarbeitspakete
unterteilen.
Dadurch lassen sich Teilaufgaben
konkret definieren. Der Hauptzweck des
Strukturplans ist die Prozess-Übersicht:
welche Abteilung muss zuarbeiten?
Welche Teilarbeitspakete bauen auf anderen auf? Durch diese Beziehungen und
Abhängigkeiten zwischen den Arbeits-/
Teilarbeitspaketen wird die Struktur im
Projekt ersichtlich.
Durch den Projektstrukturplan kann
eine effizientere Einarbeitung gewährleistet, Probleme/Konflikte (nicht persönlicher Natur) schnell ausfindig gemacht
und Zuständigkeiten klar ermittelt werden.
Dies führt zu einer effizienteren Einarbeitung für alle Abteilungen, nicht nur für die
Projektleitung.
Wie beim Projektplan kann der Projekt-
strukturplan auch teaminterne Strukturen
visualisieren. Dadurch können Abteilungen, die phasenabhängig zusammenarbeiten, sich einen schnellen Überblick über
die Struktur der jeweiligen Abteilungen
machen. Für Projektleiter ist der Projektstrukturplan ein sehr nützliches Werkzeug,
wenn dieser so funktioniert wie er soll.
Wie entsteht ein Projektstrukturplan?
Der Projektstrukturplan ist das Resultat
einer Projektstrukturplanung. Hierzu kann
der Projektstrukturplan in 10-Schritten
nach Strobusch [3] erstellt werden.
Die 10-Schritte-Planung wurde in das
Konzept einer systematischen Projektstrukturplanung übernommen [4]. Dabei
galt es für unser Softwareprojekt, ein
Konzept zu erstellen, die die Planung durch eine systematische Herangehensweise
unterstützen soll. Ein Leitfaden für die Projektleitung, um ein Projekt systematisch zu
planen ist uns gelungen. Weiter sollten die
Teilprozessen (Schritte 1-10) verfeinert
SOP JOURNAL R4
13
PROJEKTMANAGEMENT
Projektmanagement ist wie Poker spielen. [Film]
werden. Hinzu kommt, dass die Planung
in 10-Schritten nur dann erfolgreich sein
kann, wenn ein solides Anforderungsmanagement vorausgegangen ist. Denn
darauf basieren alle Planungen und Ziele,
die es in unserem Softwareprojekt zu erfüllen gilt.
Schwerpunkt des Konzeptes ist die
Projektstrukturplanung. Diese beschreibt
die Vorgehensweise für einen konkreten
Projektstrukturplan.
Fazit
Zusammengefasst sehe Ich ein Defizit in der Strukturgestaltung in unserem
14
SOP JOURNAL R4
Softwareprojekt. Angedacht von der
Geschäftsleitung war die Idee einen Projektstrukturplan für dieses Softwareprojekt
einzuführen. Als Projektleiter möchten wir
dieses Konzept aufnehmen und weiter
ausarbeiten. Vorteile und Mehraufwand
sollen ermittelt und gegenübergestellt
werden. Wir sehen vor allem in der Übergabe des Projektes einen erheblichen Informationsverlust, der nicht mittels hoher
Anzahl von Dokumenten wett zu machen
ist. Ganz im Gegenteil, sollten nur finale
Dokumente, die qualitativ hochwertig
sind, strukturiert weitergegeben werden.
Zudem ist es wichtig Prozesse, wie
etwa die Gesamtplanung des Projektes
nach einer fundierten Methode festzuhalten und für die weiteren Iterationen
verfügbar zu machen. Neben dem Projektstrukturplan gehört der Prozess Projektstrukturplanung, welcher wichtige Punkte
für die Planung des Projektes systematisch
darstellt.
Hierzu gehören auch Informationen,
die vor allem das Projekt an sich betreffen,
sprich Kommunikationsstruktur, Projektstruktur und Dokumentenstruktur.
Durch Übersichtlichkeit und bessere
Einschätzbarkeit des Softwareprojektes
kann vor allem in der Anfangszeit einer
Phase durch einen Projektstrukturplan die
Einarbeitungszeit verkürzt werden. So
können sich Iterationen schneller auf das
wesentliche, nämlich der Entwicklung des
Produktes konzentrieren.
Die Einführung des Projektstrukturplans ist meiner Meinung nach richtig.
Die Abwägung welches Produkt, hierzu
verwendet werden soll bleibt allerdings
noch offen. Das Konzept für eine systematische Projektstrukturplanung soll diese
Frage beantworten und hoffentlich schon
in der nächsten Iteration noch als festes
Artefakt einführen.
Kha Tran, Projektmanagement
Quellen
[1] „Software-Projektmanagement“: Georg Erwin Thaller, (S&S/2003)
[2] Aus dem Glossar von Projektmagazin.de: http://www.projektmagazin.de/glossar/gl-0093.html
[3] „Projektmanagement @ Siemens Vortrag“: Friedrich Strobusch, (Siemens/2008)
[4] Siehe hierzu Dokument „Projektstrukturplanung_080527_PM.docx“
K U N D E / S TA K E H O L D E R
DIE GRATWANDERUNG
Das Softwareprojekt zwischen Anspruch und Realität
Kann eine Hochschule ein reales
Projekt der freien Wirtschaft nachbilden? Der Bachelor-Studiengang Medien- und Kommunikationsinformatik
(MKI) an der Hochschule Reutlingen
wagt diesen Versuch mit einem Softwareprojekt, das Studienschwerpunkt
im fünften und sechsten Semester ist.
Die Diskrepanz zwischen Anspruch
und Realität ist jedoch hoch. So wird
die Flexibilität und Dynamik eines
realen Projektes in der Wirtschaft nie
erreicht. Warum dies so ist und welche
Verbesserungsmöglichkeiten es gibt,
soll aus der Sicht des Kundenteams
(interne Abkürzung [CU]) des Projektes untersucht werden.
Projektbeginn: Die Einteilung des neuen fünften Semesters in die verschiedenen
Teams bedeutet den Start für das einjährige Projekt. Obwohl die Wahl der Positionen in den Teams auf freiwilliger Basis
beruht, müssen bestimmte Positionen im
Projekt mit einer vorgegebenen Anzahl an
Personen besetzt werden. Deshalb können nicht alle Personen die ihren Vorstellungen und vor allem Ihren Fähigkeiten
entsprechenden Positionen besetzen,
was zu erstem Unmut führt. Hat sich dann
trotz Startschwierigkeiten ein Kundenteam
gebildet, stellt sich normalerweise
zunächst die Frage: Wie schreibe ich das
Projekt aus, welche Firmen bitte ich um
eine Angebotsabgabe? Zumindest in der
Theorie. Im Softwareprojekt hingegen sind
die Vertragspartner der Softwareentwicklung bereits mit der Teambildung festgelegt, ob gewollt oder nicht. Das wirft die
Frage auf: Warum soll eine Ausschreibung
erfolgen, wenn bereits feststeht, wer den
Auftrag erhält? Die Antwort kann hier nur
lauten: „Nicht zur Strafe, nur zur Übung!“.
Durch diese Herangehensweise werden
die Grundlagen vermittelt um diese später
in der Arbeitswelt einsetzen zu können.
Anhand dieses Beispiels wird deutlich, dass das Projekt sehr gute Ansätze
verfolgt, da es an die Gegebenheiten
eines realen Wirtschaftsprojektes heranführt. Einige dieser Ansätze sind jedoch
von Beginn an zum Scheitern verurteilt.
Es wird sich innerhalb des Projektes keine
vergleichbare Dynamik wie in der freien
Wirtschaft entwickeln. Dafür gibt es mehrere Gründe: Selbst wenn die Geschäftsleitung, gestellt von Professoren, versucht,
Konfliktpotential in das Projekt mit einzubringen, wird der Umgang zwischen
Kunde und Projektleitung nie den Stand
erreichen, der in der Wirtschaft üblich
ist. Der Kunde würde in der Entwicklungsphase mehr Druck auf die Projektleitung
ausüben, bereits in der Angebotsphase
würde härter verhandelt werden. Dies ist
im Projekt kaum möglich, da andere Faktoren entgegenwirken: Die Studierenden
kennen sich seit langem, sie sind teilweise
gut befreundet. Man kennt die Arbeitslast
der Anderen und wird nicht versuchen
den Druck durch Forderungen und Konflikte im Projekt zu erhöhen. Die Gefahr ist
groß, den Aufwand für das Projekt auf ein
gemeinsam abgestimmtes Mindestmaß
zu reduzieren. Dies hängt vom jeweiligen
Semester ab. Dass man auch gemeinsam
versuchen kann, etwas motiviert zu erreichen, zeigt zum Beispiel die Iteration fünf.
Diese Iteration hat bewiesen, dass durch
eine gute Zusammenarbeit ohne unnötige
Konflikte der Abteilungen untereinander
ein produktives Arbeitsklima im Projekt
entstehen kann. Durch Kommunikation und
ständige Gesprächsführung miteinander
konnte das Projekt einen entscheidenden
Schritt voran getrieben werden. Dies könnte jedoch mit zusätzlichen Freiheiten für
das Kundenteam noch weiter gesteigert
werden.
Der Kunde braucht ein Ziel: Was
soll entwickelt werden? Ein Langzeitarchivierungssystem. Nur im Softwareprojekt gilt nach eigener Erfahrung der Grundsatz „der Weg ist das Ziel“. Jede Iteration
erledigt nahezu dieselben Aufgaben, die
Fortschritte sind im Vergleich zur freien
SOP JOURNAL R4
15
K U N D E / S TA K E H O L D E R
Die Kunden lassen es sich gut gehen. [Film]
Wirtschaft gering. Unter anderem liegt es
daran, dass die Wege zum Ziel durch die
Geschäftsleitung vorgegeben sind.
Die Zielsetzung dieser Vorgehensweise ist klar, jedes Semester soll die gesamte Bandbreite der Aufgaben kennenlernen. Dahinter verbirgt sich ein Nachteil:
Eigene Ideen können nur schlecht eingebracht werden, die Flexibilität ist stark
eingeschränkt. Radikale Änderungen am
Projekt (zum Beispiel Beschränkung auf
die Java-Implementierung) sind ausgeschlossen.
In realen Projekten können solche
Änderungen durchaus mitten im Projekt
16
SOP JOURNAL R4
auftreten, wie ich aus eigener Erfahrung
bei der Firma BMW bestätigen kann. In
einem Projekt über den Zeitraum von
einem Jahr wurde die Zielsetzung mehrfach geändert, Anforderungen ständig
erweitert und ausgetauscht. Die Art der
Professoren, an das Projekt heranzugehen,
hat aber auch seine Vorteile:
Die Studierenden werden nicht überfordert, der pädagogische Aspekt wird
berücksichtigt. Die Studenten werden
langsam an die Abläufe in der freien
Wirtschaft herangeführt. Wie werden
Verträge geschlossen, welche Dinge
müssen beachtet werden, wie soll der
Dialog zwischen Kunde und Projektleitung
geführt werden? Es werden Einblicke in
die Abläufe eines sogenannten „ServiceLevel-Agreement“ gegeben, welche in
der Wirtschaft üblich sind. Hervorzuheben ist auch die Förderung der sogenannten „Soft-Skills“ (Kommunikationstechnik,
Präsentationstechnik, sicheres Auftreten)
jedes einzelnen innerhalb des Projektes,
welche in der heutigen Wirtschaft notwendig sind.
Das Projekt über zwei Semester bewegt sich also auf einem schmalen Grat
zwischen Realitätsnähe und pädagogischem Anspruch.
K U N D E / S TA K E H O L D E R
Da das Projekt jedoch auf Abläufe
in der freien Wirtschaft vorbereiten soll,
gibt es noch Verbesserungspotential.
Studenten hinterfragen oft die vorgegeben Wege der virtuellen Geschäftsleitung.
Viele bringen aus den Praxisphasen in der
Wirtschaft andere Erfahrungen mit, welche
sich nicht mit denen des Projekts decken.
Als Lösung für dieses Problem wäre es
wünschenswert, ausgewählten Vertretern
aus der Wirtschaft das Projekt vorzustellen
und deren Meinung darüber einzuholen.
Dadurch ist es möglich, Schwachstellen
im bisherigen System zu erkennen und
diese zu beseitigen. Was erwartet die
Wirtschaft wirklich von ihren zukünftigen
Angestellten, was sollte in einem solchen
Projekt umgesetzt werden? Wenn das Projekt durch Vertreter der Wirtschaft Zustimmung erfährt, bekommen die Studierenden eine andere Motivation an diesem
Projekt engagiert mitzuarbeiten. Es ist
auch wünschenswert, einzelne Vertreter
der Wirtschaft für Vorträge zu gewinnen.
Softwareentwickler der freien Wirtschaft
können dem Softwareteam Informationen
über den tatsächlichen Ablauf dieser Arbeit liefern. So können die Studenten ihre
Arbeitsweise am Projekt derer der Wirtschaftspraxis angleichen. Somit ist auch
die Möglichkeit gegeben, die Praxisnähe
des Projektes zu prüfen. Hier schlägt das
Projekt einen richtigen Weg ein. Friedrich
Strobusch, ein Projektleiter der Siemens
AG, wurde für einen Vortrag gewonnen,
welcher tiefe Einblicke in die Realität
des Projektmanagements eines großen
Unternehmens gewährt. Herr Strobusch
gab eine wertvolle Rückmeldung zu dem
Projekt selbst und regte zum Nachdenken
über Kommunikationswege an. Solche
Vorträge müssen zukünftig begleitend
zum Projekt realisiert werden.
Durch die positiv hervorzuhebende
Selbständigkeit im Projekt entwickelt jeder
einzelne auch seine eigene Herangehensweise an verschiedene Aufgaben. Durch
den Abgleich mit den Gegebenheiten in
der Wirtschaft kann ein einzelner seine
eigene Arbeitsweise prüfen und wenn
notwendig anpassen. Vorträge, wie der
von Friedrich Strobusch, sind der richtige
Weg zu einer Verbesserung des Projekts.
Dies sind nur ausgewählte Vorschläge, die
das Softwareprojekt interessanter und effizienter gestalten würden.
Dass das Projekt bereits einen richtigen
Weg geht, zeigt auch die Neuschaffung
der Marketing-Abteilung in unserer Iteration. So kann das Angebot innerhalb des
Projektes sinnvoll erweitert werden und
die Vermarktung eines Softwareproduktes
wird betrachtet und integriert. Es müssen in jeder Iteration Neuerungen in das
Projekt integriert werden, wenn dieses
kontinuierlich verbessert werden soll. Es
liegt im Interesse der Studenten dieses
voranzutreiben und weiterzuentwickeln.
Auch die Geschäftsleitung sollte sich an
den Innovationen beteiligen und Studenten Anregungen geben oder sie ermutigen
neue Ideen in das Projekt einfließen zu lassen. Dass die Professoren nicht abgeneigt
sind, neue Ideen umzusetzen, zeigte die
erstmalige Einführung von zwei virtuellen
Firmen in dieser Iteration. Durch diesen
Schritt ist eine weitere Annäherung an die
Gegebenheiten der Wirtschaft und eine
klare Trennung zwischen Auftraggeber
und Auftragnehmer erreicht worden.
Zusammenfassend ist das Softwareprojekt an der Hochschule Reutlingen eine
interessante Abwechslung zum normalen
Studienalltag. Rückblickend auf die letzten fünf Iterationen haben die Professoren
einen Ansatz für eine gelungene Lehrveranstaltung geschaffen, welche aber einen
fortwährenden
Verbesserungsprozess
durchlaufen muss. Die nachfolgenden
Iterationen können sich weiterhin um
den vorgeschlagenen Abgleich mit der
Wirtschaft bemühen. Dadurch wird das
gesamte Projekt auf ein höheres Niveau
gehoben, was wiederum den Studierenden selbst zugute kommt. Da die Professoren selbst ein Interesse daran haben,
die Lehrveranstaltung bzw. das Projekt zu
verbessern, wären sie dem einen oder anderen begründeten Vorschlag wohl nicht
abgeneigt. Was letztendlich im Projekt
selbst in dieser Hinsicht umgesetzt wird,
liegt zum Großteil an der Motivation der
nachfolgenden Studenten.
Es ist aber möglich aus dem schmalen
Grat, auf dem sich das Projekt bewegt
einen breiten Weg zu machen.
Markus Leyrer, Kunde/Stakeholder
(Leitung)
Quellen
[1] David Cannon, David Wheeldon: Service Operation u. a. aus der ITIL Version 3, 2007
(Service-Level beschreiben die Dienstleistungsgüte; Vereinbarung die wiederkehrende Dienstleistungen für den
Auftraggeber in den Kontrollmöglichkeiten transparenter gestaltet)
SOP JOURNAL R4
17
K U N D E / S TA K E H O L D E R
KOMMUNIKATION WILL GELERNT SEIN
Hier mal ein Treffen, da mal ein paar
Worte wechseln. Doch was verbirgt
sich hinter all den Gesprächen. Was
wird geklärt und was wird vorgestellt?
Was erhoffen sich Auftraggeber und
Auftragnehmer von den vielen Meetings und was bleibt besser unausgesprochen?
“Die Musik ist die gemeinsame Sprache
aller Nationen dieser Erde.” [1]
Gesungen wird im Softwareprojekt der
Hochschule Reutlingen zwar nicht, aber
es gibt trotzdem viele Wege miteinander
zu kommunizieren. Für eine einwandfreie
Verständigung ist es wichtig eine gemeinsame Sprache zwischen Auftraggeber
und Auftragnehmer zu finden. Die gemeinsame Sprache versucht man in den
gemeinsamen Meetings aufzubauen. In
den wöchentlich stattfindenden Treffen, wird berichtet, auf welchem Stand
jeder einzelne aus dem Projekt ist. Das ist
wichtig für die Kommunikation. Es wird erläutert, welche Aufgaben getätigt worden
sind und weitere Vorhaben werden vorgetragen. Doch was man wirklich getan
hat, bleibt meist im Verborgenen für den
Auftraggeber. Wie man das Problem lösen
könnte wird im Folgenden beschrieben.
Die Teams haben von vielen Dingen
18
SOP JOURNAL R4
eine verschiedene Auffassung und Arbeitsmoral. Um Problemen und Missverständnissen vorzubeugen ist es wichtig,
sich häufig untereinander auszutauschen.
Hinzu kommen die unterschiedlichen
Arbeitsauffassungen. Detailierte Arbeitsanweisungen sind für einige von besonderer Bedeutung und anderen reicht eine
Grobanweisung. Im Projekt können solche
Unterschiede zu Komplikationen führen,
da man eventuell Grobanweisungen für
alle verteilt, die nicht für alle verständlich
sind. Um das zu vermeiden, werden
nicht nur die allgemeinen Statusmeetings einberufen, sondern hinzu kommen
Arbeitsgespräche untereinander und die
Audio-Konferenzen via Vitero. Vitero ist
eine Software die eingesetzt wird, um
virtuelle Audio-Konferenzen abzuhalten.
Das ermöglicht den Teams, von zu Hause
daran teilzunehmen und ihre Arbeiten
den anderen Mitgliedern mitzuteilen.
Statusmeetings finden statt, um Informationen auszutauschen, dies allerdings
nur sehr oberflächlich. Man kommt in
einer „geselligen“ Runde mit allen Beteiligten zusammen und Antworten auf
Fragen wie: „Liegen wir im Zeitplan?“ oder
„Läuft alles so wie es geplant war?“ lauten
grundsätzlich „Ja“. Die Projektleiter holen
sich Rückmeldungen von ihren Kollegen
ein und zeigen dem Auftraggeber, wie
souverän gearbeitet wird. Die Geschäftsleitung hält sich vornehmlich zurück und
lauscht den Gesprächen. Selten kommt es
vor, dass Kritik geübt wird. Somit müssten
alle rundum zufrieden sein. Eine Annahme
ist, dass die Auftraggeber nur das erfahren
sollen, was positiv zu werten ist. Die Frage
„WIE“ gearbeitet wird, kann man pauschal
nicht beantworten. Man muss dem Team
die Freiheit geben so zu arbeiten, wie sie
es wünschen. Auftretende Probleme werden schnell gelöst, ohne Auswirkungen
(Zeitverlust) herbeizurufen.
Schwerwiegende Probleme sollten in
Arbeitsgesprächen geklärt werden. In den
Gesprächen, die entweder untereinander
geführt werden oder Team-übergreifend
sind, versucht man entsprechende Lösungen zu finden. Zum Teil sind es zeitliche
oder finanzielle Angelegenheiten, die
überarbeitet werden müssen. Ziel des
ganzen Gesprächs ist es, eine effiziente
Lösung zu finden, um das Projekt nicht unnötig aufzuhalten.
Arbeitsgespräche, wie diese kommen selten vor, da jeder annimmt, im
Allgemeinen Statusmeeting schon alles
berichtet zu haben. Ein paar Tage später
kommt doch noch die eine oder andere
Frage auf. Für ein ausführliches Gespräch
ist es nun zu spät. Um das Problem oder
Fragen doch noch aus dem Weg zu räu-
K U N D E / S TA K E H O L D E R
men, muss man Team-Intern, schnellst
möglich Antworten finden. Dadurch
wird die Team-übergreifende Arbeit eher
wenig gefördert und führt zu persönlichen
Diskrepanzen, da andere Projektteilnehmer annehmen, dass der- oder diejenige,
mögliche Aufgaben nicht ernst genug
nimmt.
Vitero Meetings sind ebenso Besprechungen, die wöchentlich von zu Hause,
via Internet stattfinden. Diese Meetings
finden zum Abschluss der Woche statt,
um mögliche, neue Aufgaben über das
Wochenende zu verteilen. Das heißt, am
Freitag hat man noch einmal die Chance,
Fragen zu stellen oder sich einfach nur
auszutauschen. Dies ist sehr wichtig,
denn viele nutzen das Wochenende, um
noch einiges aufzuarbeiten. Somit wird
im nächsten Statusmeeting ergänzt, was
bereits wieder getan wurde. Dieser Zyklus
sollte einwandfrei funktionieren, wenn
man sich richtig aufteilt und seine Kollegen wissen lässt, an welchen Aufgaben
man arbeitet.
Viele Teammitglieder tragen nur Dinge
vor, von denen sie denken, dass diese
auch andere interessieren könnten. Interne
Dinge werden auch nur untereinander
diskutiert. Wenn ein Teammitglied Hilfe
benötigt und sich nicht offenbart, kann es
zu Komplikationen kommen. Sobald sich
diese Probleme auf andere Arbeitsschritte
im Projekt auswirken, werden erste Fragen
gestellt, wie es dazu kommen konnte.
Unterstützung kann nur dann erfolgen,
wenn die Projektleitung weiß, wo sie gebraucht wird. Ein Zeitverlust oder andere
Konsequenzen werden vermieden, wenn
Alle Extra-Wünsche müssen erfüllt werden. [Film]
Probleme offenbart werden.
Transparentes Arbeiten heißt auch
Vertrauen in die Mitglieder des Projekts.
Insgesamt kann ein Projekt nur erfolgreich
sein, wenn jeder einzelne seine Aufgaben ernst nimmt. Einzelne Teammitglieder
erzählen viel über eventuelle Aufgaben,
aber die Praxis steht im Hintergrund. Das
heißt in der Theorie würde viel erreicht
werden, aber das Handeln fällt eher wenig
aus. Somit wird wenig Arbeit als viel mehr
verkauft, als eigentlich getan wurde und
müsste. Unter diesen Umständen, müsste
insgeheim viel aufgeholt werden, um das
Projekt nicht aufzuhalten, wird dies geschafft, ohne Komplikationen bekommt
der Auftraggeber nichts davon mit.
Die Auftragnehmer versuchen so
gut es geht, sich selbst zu verkaufen, so
werden keine Details gegenüber dem
Auftraggeber genannt, es sei denn der
Auftragnehmer wünscht es. Das heißt,
die Arbeitsweise sollte und müsste dem
Auftraggeber egal sein, das Resultat am
Ende ist entscheidend.
Es gibt genug Kommunikationsmöglichkeiten im Projekt und es gibt genug
Gelegenheiten, kundzutun, woran man arbeitet oder was eventuell fehlt, um voranzukommen. Viele jedoch nutzen nicht das
Angebot und arbeiten selbstständig, ohne
an die eventuellen Folgen zu denken.
Im Softwareprojekt hat man sich auf
eine Sprache einigen können. Das heißt
technische Inhalte werden so verständlich wie möglich formuliert und auch in
Schriftform dem Kunden zur Verfügung
gestellt. Die Dokumentation einzelner Arbeiten zeigen dem Auftraggeber Details
der Entwicklung und der Projektplan bestimmt den Rahmen für die gesamte Projektdauer. Auftragnehmer und Auftraggeber kommunizieren auf einer sachlichen
Ebene miteinander. Die Gelegenheit,
SOP JOURNAL R4
19
K U N D E / S TA K E H O L D E R
ihre Arbeiten offen darzulegen sollten
die einzelnen Mitglieder öfter nutzen.
Damit erhalten Geschäftsleitung und alle
weiteren Mitglieder mehr Einblick in das
Projektgeschehen.
Dokumentation ist ein Bestandteil des
Projekts, was viele für überflüssig halten,
aber von enormer Bedeutung ist. So kann
man nach einem längeren Zeitraum in
Dokumenten oder Protokollen nachlesen,
was, wann, wie festgelegt worden ist. Das
bedeutet, man kann sich selbst ein Bild
machen, wie gearbeitet wurde und kann
dadurch schneller auf Details reagieren.
Der Schriftverkehr, der durch Versenden
von täglichen Emails entsteht, gehört auch
dazu. Man schickt diverse Artefakte an
einzelne Teammitglieder weiter und unterstützt somit, das transparente Arbeiten.
So werden Dokumente, wie Verträge oder
Änderungsanträge, zwischen Auftraggeber und Auftragnehmer ausgetauscht. Anmerkungen von den beiden Partnern können sofort ausgesprochen werden. Jeder
hat die Chance schnelle Informationen zu
beziehen und es müssen keine Extratreffen einberufen werden.
Gemeinsame Unterlagen werden für
anstehende Reviews [2] versendet, um
sicher zu gehen, dass man nichts doppelt
nennt oder sogar abweicht von den anderen Teams. Es wird sichergestellt, dass
alle Dokumente fehlerfrei sind und dass
alle Aufgaben nach Plan erledigt worden
sind. Dabei sollte erwähnt werden, dass
nicht alle Projektteilnehmer jede Email
erhalten. Es gibt keine Regelungen, wann,
wer, welche Email bekommt, aber aufgabenspezifische Sachverhalte werden
20
SOP JOURNAL R4
auch nur an das entsprechende Team
versendet.
Dass es auch zu Fehlern kommen kann,
ist nichts Unnatürliches. Wenn Termine
oder Meilensteine aus diversen Gründen
nicht eingehalten werden können, ist das
noch keine Gefährdung für das Projekt.
Diese Probleme und Risiken die hervorgerufen werden, sind nicht vorher abzusehen. Dennoch gilt, dass die Arbeitsweise
eine Menge damit zu tun hat. Zusammen
wird dann, nach der Ursache geforscht
und überlegt wie man es in Zukunft besser
arrangieren könnte. Ziel ist es, ein Projekt
an die nächste Iteration so abzugeben,
in dass sich die Nachfolger/in schnell
einarbeiten kann und ein Programm zu
übergeben, welches fehlerfrei läuft.
Der Kunde bestimmt die Anforderungen. Welche Aufgaben bis wann zu erledigen sind, legt der Projektleiter fest. Was
dazwischen passiert lässt sich teilweise
nur erahnen, da man als Kunde nur das
sieht was der Auftragnehmer zulässt. In der
freien Wirtschaft erfährt der Auftraggeber
auch nicht alle Details, aber er wird immer
darüber informiert, wie es voran geht.
Da dieses Projekt noch nicht in der
freien Wirtschaft stattfindet und alle Studenten ihre ersten Erfahrungen sammeln,
wie man zusammen arbeiten könnte,
gelten hier noch andere Regeln. Hier
empfehlen sich ein ständiger Austausch
mit der Geschäftsleitung und eine lückenlose Dokumentation zur Nachverfolgung.
Auch in der freien Wirtschaft, insbesondere in großen Firmen kommt es öfter zu
Kommunikationsproblemen. „Innerhalb
größerer Firmen sind heute eine Vielzahl
unterschiedlicher, nicht kompatibler
Systeme, Programme und Dokumentenformate in Gebrauch. Deshalb ist es
nahezu unmöglich, Dokumente zwischen
unterschiedlichen Dokumentationssystemen auszutauschen bzw. Informationen
aus externen Quellen einzulesen und
aufzubereiten.“ [3] Dabei geht es primär
um die Daten- und Dokumentenaufbereitung, aber es entstehen Probleme, weil
man nicht ein und dasselbe Programm
verwendet. In unserem Projekt sind es die
Terminologie und die Sprachbarrieren die
überwunden werden müssen.
Es kann nie garantiert werden, dass
durch die Einhaltung diverser Regeln, es zu
einem reibungslosen Ablauf des gesamten Projekts kommt. Aber es wird vereinfacht. Fragen werden leichter beantwortet
und der Kunde wird zufriedengestellt. Ein
Projekt kann nur so gut werden, wie das
schwächste Glied in der Kette. Dieses Mitglied sollte nicht nur überwacht sondern
unterstützt werden, so dass das Projekt
nicht aufgehalten wird.
Wencke Schulz, Kunde/Stakeholder
Quellen
[1] http://www.zitate-aphorismen.de/zitate/thema/Kommunikation/232 (Stand: 28.05.08)
[2] Review ist ein Kurzvortrag, der jedes Teammitglied hält und indem berichtet wird was man in einen bestimmten Zeitraum erarbeitet hat.
[3] http://www.tekom.de/index_neu.jsp?url=/servlet/ControllerGUI?action=voll&id=444 (Stand: 28.05.08)
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
Im Serverraum des Studeingangs. [Film]
GEKLONTE GRÜNE SERVER
Der Einsatz von Virtualisierungstechnologie im Softwareprojekt
Die Virtualisierung von Servern
erfreut sich wachsender Beliebtheit.
Unternehmen wie Kunden setzen
zunehmend auf die V-Technologien.
Deren Einsatz im Softwareprojekt wird
ebenso stetig ausgebaut. Der Erfolg
basiert jedoch nicht nur auf geschicktem Marketing der Hersteller. Für eine
virtuelle Infrastruktur im Projekt gibt
es handfeste Gründe.
Dass die Virtualisierungstechnologie
einen großen Wachstumsmarkt innerhalb
der IT-Branche stellt, bestätigen die Geschäftszahlen des Spezialisten Vmware.
Mit einer Umsatzsteigerung um 88 Prozent
auf 1,33 Milliarden Dollar im abgeschlossenen Geschäftsjahr 2007, erfreut der
Marktführer seine Aktionäre (vgl. [1]). Aber
welche Leistungen bieten Vmware oder
Konkurrenten wie Virtual PC und Parallels
ihren Kunden eigentlich genau?
Die Virtuelle Maschine
Vereinfacht ausgedrückt, lassen sich
mit Hilfe von Virtualisierungstechnologien mehrere Betriebssysteme gleichzeitig
auf einem PC betreiben. Bei der Systemvirtualisierung wird dabei auf einem
physischen, realen Rechner eine virtuelle
Umgebung eingerichtet. Dies kann auf
einem gastgebenden Betriebssystem oder
direkt in der Hardware erfolgen. Die Umgebung wird als „Virtuelle Maschine“ (VM)
SOP JOURNAL R4
21
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
bezeichnet. Die VM emuliert einen kompletten PC mit Prozessor, Arbeitsspeicher,
Netzwerkkarte etc. Auf dieser virtuellen
vorgetäuschten Hardware kann nun ein
weiteres Betriebssystem als sogenannter
Gast betrieben werden. Die Verwaltung
der VMs übernimmt ein „Virtual Machine
Monitor“ (VMM) genanntes Programm. Es
teilt die realen Ressourcen zwischen den
Virtuellen Maschinen auf.
Die Vorteile bei konsequentem Einsatz der Technologie sind vielfältig und
unterstützen die Arbeit aller Mitarbeiter
und Abteilungen des Softwareprojekts.
Neue Iteration - neuer Server?
Die Projektregularien sehen für jede
Iteration einen neuen Server als aktive
Entwicklungsumgebung vor, obgleich
bereits ein einsatzbereites System der
vorrangegangenen Iteration besteht. Dies
führte zu kontroversen Diskussionen. Von
„Zeitverschwendung“ und „unnötiger Arbeit“ war die Rede. Warum also nicht den
alten und funktionierenden Server weiterbenutzen? Dafür gibt es gute Gründe:
Eine bessere Schulung des Konfigurations- und Änderungsmanagements (CM)
sowie eine sukzessive Weiterentwicklung
vorhandener Anleitungen. Darüber hinaus
geht das Wissen um die Installationen und
Konfigurationen nicht verloren. Freilich viel
Arbeit - in der Gesamtbetrachtung aber
eine durchaus richtige Entscheidung.
Die bisher bereitgestellte Hardware
konnte allerdings nur die anspruchslosesten Administratoren befriedigen.
Desktop-PCs der Mittelklasse, welche bei
mehreren aktiven Serveranwendungen be-
22
SOP JOURNAL R4
reits in Schwitzen kamen, begründen die
hohe Anzahl dedizierter Hosts im Projekt.
Wo ein bisheriger großflächiger Einsatz
von Virtuellen Maschinen an mangelnder
Leistung scheiterte, ist für die Zukunft dank
spezieller Server-Hardware eine komplette
virtuelle Infrastruktur geplant.
Die Vorteile für CM sind vielfältig. Alle
benötigten Server können auf den Virtuellen Maschinen eines einzigen physischen
Hosts aufgesetzt werden. Neben einfacheren Installationen unterschiedlicher
Betriebssysteme werden auch Backups
zur automatischen Sicherung der Server
und Datenbestände verbessert. Eine VM
wird auf dem Host als eine einzige große
Datei gespeichert, welche per Skript automatisch kopiert werden kann. Im Notfall
reicht das Zurückkopieren der gesicherten
Datei aus, um weiterarbeiten zu können.
Eine komfortable und sichere Lösung.
In der aktuellen Iteration mussten Server
hierfür noch außer Betrieb genommen
und manuell gesichert werden. Virtuelle
Maschinen steigern somit die Effizienz
des Konfigurations- und Änderungsmanagements.
Die Frage nach der Domäne
Für die Softwareentwicklung mit
dem Dateiverwaltungs-Programm Rational
ClearCase bestand eine besondere Installationshürde. Durch eine zwingende
Domänenanmeldung beim Windowsstart
standen viele Mitarbeiter vor der Neuinstallation ihres privaten Betriebssystems,
da diese nur mit dem wenig verbreiteten
Windows XP Professional möglich ist.
Ein erheblicher Aufwand. Die einfachste
Lösung hierfür bietet wieder eine VM.
Auf das vorhandene System wird das
benötigte Betriebssystem mit allen Rational-Anwendungen installiert. Welches
gastgebende System dabei auf dem Rechner läuft, spielt keine Rolle. Beide Systeme sind voneinander unabhängig, wie
auch die VMs untereinander. Auf einem
Windows-System kann Linux installiert
werden und umgekehrt, Unterstützung
durch die VMM vorausgesetzt.
Testen ohne Risiko
Um bei bisherigen Tests Serverkapazitäten einzusparen, wurden von CM
hier bereits Virtuelle Maschinen mit der
Software Vmware Server (vgl. [2]) eingesetzt. Bei täglichen Tests während der
Entwicklung wäre es ein hoher Aufwand
für CM stets frische Testumgebungen bereitzustellen. Mit Unterstützung von VMs
wird dieser Aufwand auf ein Minimum
reduziert. Ein einmal aufgesetztes und gesichertes System kann unbegrenzt oft geklont werden. Nur die Hardware schränkt
die Anzahl ein. Die Vorteile bestehen in
der risikolosen Testumgebung und den
exakt selben Bedingungen bezüglich System und Hardware. Das noch fehlerhafte
Softwareprodukt kann auf einem frischen
Betriebssystem installiert und auf Fehler
getestet werden. Parallele Tests auf mehreren VMs sind ebenso möglich. Sollte das
System beschädigt werden, wird es durch
einen neuen Klon ersetzt.
Es grünt so grün
Nicht nur Spaniens Blüten blühen in
strahlendem grün, auch die IT-Branche
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
hat die Farbe für sich entdeckt. Unter
dem Begriff „Green IT“ ist die ökologische
Neuausrichtung der Branche, spätestens
seit der CeBIT 2008 bekannt. Nur 10 bis
30 Prozent der verfügbaren Rechenleistung werden im Schnitt von den Servern
genutzt, wobei sich der Stromverbrauch
meist nahe der Volllast bewegt (vgl. [3]).
In den USA stellten die Rechenzentren im
Jahr 2006 knapp 1,6 Prozent des gesamten
Energieverbrauchs. Dies entspricht Energiekosten von 4,5 Milliarden Dollar. „Was
gut für die Umwelt ist, ist ein Muss für das
IT-Geschäft der Zukunft. Die Kosten um
Server zu betreiben, werden die Anschaffungskosten in den nächsten fünf Jahren
übertreffen. […]“, erklärt Dave Douglas,
von Sun Microsystems. (vgl. [4])
Das Potential von Einsparungen durch
den Einsatz von Virtualisierungstechnologien ist hoch. Das Teilen von Ressourcen
und ein geringerer Kühlungsaufwand
ermöglichen bessere Auslastungen und
einen effizienteren Betrieb. Die Unternehmen haben vielerorts die Zeichen der Zeit
erkannt und bemühen sich nachhaltig um
ein ökologisches Image. Sicherlich nicht
ganz uneigennützig wird die derzeitige
Stimmung für den Umweltschutz genutzt,
um Kosten zu sparen und besonders „saubere“ bzw. energiesparende Produkte zu
vermarkten. Über diese kommerziellen
Motive lässt sich streiten. Letztendlich
ist die Entwicklung aber richtig und auf
einem guten Weg. Auch die Hochschule
sollte hier als eine staatliche Einrichtung
die Virtualisierung von Servern weiter forcieren. Das Softwareprojekt geht hier mit
gutem Beispiel voran.
Virtueller Desktop der Zukunft
Mit dem Kauf einer Desktop-Virtualisierungstechnologie plant der Studiengang
MKI derzeit den Ausbau seiner virtuellen
Infrastruktur. Damit wird es möglich sein,
eine einmalig eingerichtete VM mit allen
Rational-Anwendungen jedem Mitarbeiter
zur Verfügung zu stellen. Deren Desktops
und Daten liegen vollständig virtualisiert
auf dem Server. Der Zugriff erfolgt ähnlich
eines Remote-Desktops von jedem PC aus
– auch von zuhause. Bisherige Probleme
der Softwareentwickler beim Serverzugriff entfallen, da ausschließlich auf dem
Server gearbeitet wird. Die Installation
und Konfiguration wird somit zentralisiert.
Für CM ein Segen: Aufwendige Hilfestellungen für missglückte Installationen entfallen. Aktualisierungen können zentral für
alle aufgespielt werden. Außerdem sind
die VMs vor Systemausfall, Angriff oder
Diebstahl geschützt (vgl. [5]).
Der Erfolg der Virtualisierungstechnologien liegt nicht zuletzt an der meist kostenlosen Bereitstellung der Software. Die
Zukunft liegt ohnehin in der Verwaltung
der VMs. Laut Diane Greene, der Präsidentin von Vmware, sorgt dieser Bereich bereits für 80 Prozent der Einnahmen. Blickt
man auf die zukünftigen Entwicklungen
wird das Potential der Technologie deut-
lich: Ein Server, der in dem Moment einspringt in dem ein anderer Server ausfällt
oder Datenbanken, die den PC wechseln
während auf sie zugegriffen wird. Komplette Virtuelle Maschinen im laufenden
Betrieb umzuziehen ist währenddessen
keine Zukunftsmusik mehr. Dies gibt es
schon heute. (vgl. [6])
Für die künftige Projektarbeit ist also
ein noch stärkerer Einsatz von Virtuellen
Maschinen in Planung. Die Vorteile für
ein effizientes interdisziplinäres Arbeiten
sprechen für sich. Mit diesem Weg gehen
das Softwareprojekt und die Ausbildung
der Studenten einen zukunftssicheren und
richtigen Weg.
Bei den Herstellern ist der Kampf
um die Kunden indes neu eröffnet. Die
lukrative und gewinnträchtige Branche
veranlasst derzeit die IT-Riesen Microsoft
und Oracle deren Anstrengungen auf der
Jagd nach Marktanteilen in dieser Sparte
kräftig auszubauen. Bei einem geschätzten Jahresvolumen von 5,5 Milliarden
Dollar wollen derzeit viele ein Stück vom
virtuellen Kuchen abbekommen. Der
Markt dürfte davon profitieren. Nur die
Aktionäre von Vmware werden enttäuscht
sein. Die Aktie verlor daraufhin trotz guter
Quartalszahlen um 34 Prozent (vgl. [1]). Es
bleibt spannend.
Armin Wälder, Konfigurations - und
Änderungsmanagement (Leitung)
Quellen
[1] http://www.zdnet.de/itmanager/kommentare/0,39023450,39161636,00.htm (Stand: 02.05.2008)
[2] http://www.vmware.com/de/products/server/ (Stand: 02.05.2008)
[3] http://www.cebit.de/bin/greenit/index.html (Stand: 02.05.2008)
[4] http://www.zdnet.de/itmanager/tech/0,39023442,39159819-1,00.htm (Stand: 02.05.2008)
[5] http://www.vmware.com/de/company/news/releases/02_28_08_demo.html (Stand: 02.05.2008)
[6] Beier, Andreas: Schöne virtuelle Welt, in c’t 21/2007, S.45.
SOP JOURNAL R4
23
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
ALLE DENKEN RATIONAL
Werkzeuge von IBM - Eine Hilfe für das Softwareprojekt?
Befragt nach dem Einsatzzweck der
Werkzeuge von Rational erklärt der Hersteller IBM, dass „[…] Sie mit den Rational-Entwicklungstools Ihre Softwareentwicklung
optimieren können. (vgl. [1])“ Die Verifikation dieser Werbeaussage übernimmt der
harte Projektalltag.
Entwicklung IT-Produkte der DSV-Gruppe,
bildet RequisitePro die ideale Basis zur
Softwareentwicklung (vgl. [2]).
RequisitePro wird im Projekt von
Kunden und Projektmanagement genutzt.
Vertraglich definierte Anforderungen können einfach und übersichtlich verwaltet
und mit Attributen wie Priorität oder Status
versehen werden. Weiterhin ist es möglich
Abhängigkeiten durch Verknüpfungen zu
beschreiben. Ein auf dem Server zentral
verwaltetes Projektverzeichnis bietet
jedem Mitarbeiter Zugriff. Paralleles Arbeiten wird somit ermöglicht. Nützlich
an RequisitePro ist ebenfalls die Definition
beliebiger neuer Attribute, mit welchen
eine Anforderung versehen werden kann.
Die Historie eines Dokuments ist ein weiterer Vorteil.
Der Kunde stellt die Anforderungen
Anforderungen stehen zu Beginn
der Softwareentwicklung. Für einen effizienten Entwicklungsprozess muss die
Effizienz aller Teilprozesse gewährleistet
werden. Ein schlechtes Anforderungsmanagement beeinträchtigt nachhaltig
die komplette Kette der Entwicklung.
Nicht optimal verwaltete Anforderungen
führen zu fehlerhaften Umsetzungen und
geringer Qualität des Produktes. Nach André Koschinowski, dem Abteilungsleiter
Ein Projekt steckt voller Änderungen
Im Laufe jedes Entwicklungsprozesses treten Änderungen an der zu
erstellenden Software auf. Sie können
sowohl das Produkt, als auch die eingesetzten Entwicklungswerkzeuge betreffen. Änderungsanträge werden auch
Change Requests genannt. Diese können
in zwei Kategorien eingeteilt werden:
Wichtige und dringende Änderungen,
welche eine sofortige Umsetzung benötigen oder Änderungen, die bei Zeitmangel
Um eine effiziente Arbeit im Softwareprojekt zu ermöglichen, ist die
Nutzung von projektunterstützender
Software notwendig. Der Einsatz der
professionellen Rational-Werkzeuge
der Firma IBM sorgt für Kontroversen.
Sind sie wirklich vorteilhaft für das
Softwareprojekt? Oder bedeuten sie
nur einen unnötigen Mehraufwand
und stehen in keinem Verhältnis zum
Nutzen?
24
SOP JOURNAL R4
der nächsten Iteration übergeben werden
können. Um diese Change Requests zu
verwalten bedarf es einer Software für das
Änderungsmanagement. ClearQuest ist
hierfür optimiert und wird auch vielfach
im realen Business eingesetzt. Nach Wim
Geerdink, Gruppenleiter für Softwareentwicklungswerkzeuge bei Philips ASA Laboratory, bietet es eine einfache Anpassung
an den existierenden Prozess. Dies macht
es den Entwicklern einfach auf ClearQuest
umzusteigen. (vgl. [3])
Im Projekt wird ClearQuest von allen
Abteilungen genutzt, um Änderungsanträge zu stellen. Es kann der komplette
Lebenszyklus einer Änderung verfolgt und
geändert werden. Für die verschiedenen
Änderungskategorien gibt es einzelne
Prozessmodelle. In diesen sind die
Zustände und Aktionen des Lebenszyklus
eine Änderung definiert. Mit ClearQuest
kann der aktuelle Stand einer Änderung
von jedem Mitarbeiter abgerufen werden.
Ebenfalls können Berichte und Diagramme
generiert werden. Damit kann dem Projektmanagement beispielsweise aufgezeigt
werden, wie lange eine Änderung noch
bis zur Fertigstellung benötigt.
Artefakte müssen verwaltet werden
Im Verlauf des Projektes entstehen
zahlreiche zu verwaltende Dokumente
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
Immer konzentriert bleiben und die Nerven behalten, wenn alle zu einem laufen. [Film]
und Artefakte. Es ist außerdem erforderlich, verteilt programmierten Quellcode
zusammenzufügen. Für diese Aufgaben
ist ein Werkzeug zur Dateiverwaltung
nötig. Hierfür gibt es Open-Source
sowie kommerzielle Produkte. Laut der
Fachzeitschrift „manage it“ sind die
Open-Source-Produkte im Vergleich zu
kommerziellen Lösungen als qualitativ
hochwertige Alternativen anzusehen. Dies
ist auf die große Entwicklergemeinde
zurückzuführen, welche neue Funktionen
zeitnah realisiert. Bei kommerziellen Herstellern wird die Umsetzung meist in den
nächsten Release verschoben. Weiterhin
sind die Open-Source-Varianten kostenlos verfügbar und beanspruchen keine
Wartungskosten. (vgl. [4])
Ein
Open-Source-Werkzeug
zur
Dateiverwaltung, welches bereits in früheren Iterationen im Projekt eingesetzt wurde ist Subversion. Die Ablösung erfolgte
durch das kommerzielle Rational ClearCase. Wieso wird an dieser Stelle nicht
weiterhin die Open-Source-Lösung eingesetzt? Trotz der vielen Vorteile ist der Vorzug von ClearCase gegenüber Subversion
gerechtfertigt. In allen Bereichen des Projektes wurden die Werkzeuge von Rational
eingeführt. ClearCase bietet mit diesen
eine hervorragende Integration. Dies bedeutet, die Programme sind aufeinander
abgestimmt und Prozesse lassen sich
miteinander verknüpfen. Ebenso lässt es
sich direkt in die Entwicklungswerkzeuge
Eclipse und Visual Studio integrieren.
ClearCase wird zur zentralen Verwaltung von Artefakten eingesetzt. Derzeit
bestehen dafür noch mehrere Plattformen, wie BSCW oder Sharepoint. Diese
sollen in Zukunft komplett von ClearCase
als Dateiverwaltung abgelöst werden.
Somit erhält das Projekt eine einheitliche
Ablage für alle Artefakte. Inkonsistenzen
oder Duplikate im Datenbestand können
so vermieden werden.
Probleme gibt es überall
Durch die Nutzung der Rational-Software entstehen jedoch nicht nur Vorteile
für das Projekt. Der erste Kritikpunkt ist
die Einrichtung und Administration. Diese
Aufgabe wird von der Abteilung Konfigurations- und Änderungsmanagement (CM)
übernommen. Hierbei ist es sehr kompliziert jedes Werkzeug betriebsbereit zu
konfigurieren. Dies liegt an der zeitaufwen-
SOP JOURNAL R4
25
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
digen Installation und der unübersichtlichen Anleitungen und Hilfestellungen
von IBM. Auch Prof. Dr. Stefan Schöf von
der Fachhochschule Oldenburg kritisiert
dies bei seiner „Evaluation der Rational
Suite Enterprise“. RequisitePro ist mit einer
„aufwändigen Installation, die auch etwas
tiefer in das System eingreift“ verbunden,
erklärt er. Weiterhin ist „die Installation
von ClearCase im Vergleich zu anderen
Konfigurationsmanagement-Werkzeugen
extrem aufwändig“. (vgl. [5]) Der Import
aller Daten aus den Vorgängeriterationen
und das Einrichten der Zugänge sind weitere umfangreiche Vorgänge.
Es ist zu überlegen, ob jede Iteration
alle Werkzeuge wieder komplett neu installieren sollte. Der daraus resultierende
Vorteil ist, dass es in jeder Iteration geschulte Mitarbeiter gibt. Diese können bei
Ausfällen die Aufgabe der Neuinstallation
übernehmen, sowie das notwendige Wissen an die Folgeiteration kompetenter vermitteln. Andererseits entsteht durch die
komplette Neuinstallation der Werkzeuge
ein erheblicher Zeitaufwand. Dadurch ist
die Abteilung CM in der Anfangsphase
des Projektes ausgelastet und kann erst
danach neue Aufgaben übernehmen.
Ein weiterer Kritikpunkt ist die aufwändige Installation der Werkzeuge auf dem
Client-Computer. Hierfür muss gegebenenfalls das Betriebssystem Windows
XP Professional neu installiert werden.
Auch kommt es oft zu Komplikationen,
welche nicht vorhergesehen werden können. Beispielsweise gab es Fehler bei der
Verbindung zur RequisitePro-Datenbank.
Die für die Einwahl ins Hochschulnetz
26
SOP JOURNAL R4
benötigte VPN-Verbindung (Virtual Private
Network) führte, wie auch die Domänenanmeldung, ebenfalls mehrfach zu Problemen. Durch diese Installationshürden
nahmen nur wenige Mitarbeiter die Dienste der Rational-Werkzeuge in Anspruch.
Aufgrund der langen Einarbeitungs- und
Einrichtungszeit können diese ohnehin
erst in der zweiten Hälfte des Projektes
effektiv genutzt werden. Prof. Schöf bestätigt in seiner Evaluation: „Es stellte sich
bei der ersten Nutzung bereits heraus,
dass die verschiedenen Werkzeuge zwar
sehr mächtig sind, dafür aber teilweise
einer sehr gründlichen Einarbeitung und
entsprechenden Vorwissens bedürfen“
(vgl. [5]).
Um das Problem der aufwändigen
Installation auf dem Client-Computer und
des damit verbundenen Zeitaufwandes
zu lösen, ist es sinnvoll zukünftig die Webschnittstellen der Werkzeuge zu benutzen. Sie sind für alle drei im Projekt eingesetzten Rational-Werkzeuge vorhanden
und ermöglichen den Mitarbeitern einen
einfachen Zugriff per Browser. Dies macht
die Client-Installationen überflüssig und
dürfte zu einer erhöhten Akzeptanz der
Werkzeuge führen. Ebenso wird eine Plattformunabhängigkeit erreicht.
Fazit
Für die Zukunft des Softwareprojektes
ist ein wichtiger Punkt sicherlich der verstärkte Einsatz der Rational-Werkzeuge. Sie
wurden erstmals von CM in dieser und der
letzten Iteration eingerichtet. Zum jetzigen
Zeitpunkt nutzen lediglich 12 der 22 Iterationsmitglieder das Werkzeug ClearCase,
was auf die komplizierte Einrichtung
und Installation zurückzuführen ist. Eine
verstärkte Nutzung der bisher nur wenig
eingesetzten Werkzeuge ist anzustreben.
Dadurch können die Vorteile, welche die
Werkzeuge mit sich bringen, in Zukunft
besser ausgeschöpft werden. Ein Lösungsansatz hierfür ist beispielsweise die Nutzung der Webschnittstellen.
Der Einsatz der Werkzeuge von
Rational bietet eine zentrale Plattform
für den Softwareentwicklungsprozess
und die Mitarbeiter. Hier werden alle
Artefakte und Prozesse verwaltet. Die
einzelnen Applikationen sind aufeinander
abgestimmt und wechselseitig integriert. Generell bedeutet der Einsatz der
Rational-Werkzeuge eine Optimierung der
Softwareentwicklung. Der Mehraufwand
durch lange Installationen und Konfigurationen steht durchaus im Verhältnis zum
späteren Nutzen. Eine konsequente und
effiziente Einarbeitung und ein qualifizierter Einsatz der Mitarbeiter ist allerdings
Voraussetzung.
Jacqueline Jonigkeit, Konfigurations und Änderungsmanagement
Quellen
[1] http://www-306.ibm.com/software/de/rational/ (Stand: 03.05.2008)
[2] ftp://ftp.software.ibm.com/software/emea/de/rational/P6280_HiR_oB_GK12-4521-00.pdf (Stand: 29.05.2008)
[3] ftp://ftp.software.ibm.com/software/emea/de/rational/philips.pdf (Stand: 29.05.2008)
[4] http://www.ap-verlag.de/Download-Dateien/mit%207-8%202005/mit%207-8-2005-220a_LV.pdf (Stand: 29.05.2008)
[5] www.fh-oow.de/forschungsdatenbank/docs/Forschungsbericht_30032006012310.pdf (Stand: 29.05.2008)
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
TROUBLESHOOTING
Der Weg zur Lösung eines Problems
Wer sich ohne praktische Vorkenntnisse im Bereich Server-Administration
für die Rolle Konfigurationsmanagement entscheidet, wird mit zahlreichen Problemen zu kämpfen haben.
Denn das Hauptproblem der fehlenden praktischen Erfahrung bringt zahlreiche weitere Teilprobleme mit sich.
Hierbei ist insbesondere überdachtes
strategisches Vorgehen wichtig, denn
die „Trial and Error“ [1] – “mit-demKopf-durch-die-Wand“-Methode führt
häufig zu weiteren Problemen.
Konfigurationsmanagement:
Aufgaben & Probleme
Das weite Aufgabenspektrum des
Konfigurationsmanagement beginnt bei
der Serverinstallation. Neben einem Betriebssystem werden hierbei Datenbanken, Webserver und Anwendungen wie
z.B. Rational ClearCase, ClearQuest oder
RequisitePro installiert und konfiguriert.
Methoden wie VPN [2], DNS [3], Domänencontroller[4] und Active Directory [5]
machen den simplen Host zur Serverplattform, die allen Mitarbeitern über das
Internet zugänglich ist. Dadurch können
sämtliche Ressourcen zentral gespeichert
und verwaltet werden.
Hier wird man mit zahlreichen verschiedenen Technologien und Systemen
konfrontiert. Es gibt viele Installations-,
Konfigurations- und Administrationsmöglichkeiten und dadurch ein hohes
Fehler- und Problempotential.
Problemlösen geschieht zwischen
zwei möglichen Extremen: „Trial and Error“ und strategisches Vorgehen. Ersteres
setzt keinerlei Intelligenz voraus, da verschiedene Lösungswege „ausprobiert“
werden und die Lösung durch Zufall gefunden wird. Das schafft allerdings häufig
weitere Probleme, da oft Fehler gemacht
werden. Deshalb muss insbesondere hier
das System vor jeder Änderung gesichert
und jeder Schritt dokumentiert werden.
Das andere Extrem ist das strategische
Vorgehen, wobei durch Einsicht gelernt
wird. Das setzt allerdings umfangreiche
Kenntnisse voraus. Insbesondere zu Beginn des Projektes machte sich eine starke
Tendenz zu „Trial and Error” bemerkbar.
Jedoch sollten Probleme bei einem intakten Server immer strategisch bearbeitet
werden, damit nicht andere funktionsfähige Dienste gefährdet werden.
Die Phasen des Troubleshooting lassen
sich grob in drei Teile gliedern: Erfassen
des Problems, Analyse der Lösungsverfahren und Erreichen des gewünschten
Soll-Zustandes. Basierend auf der
methodischen Problemlösungsstrategie
„S.P.A.L.T.E.N“ [6], die an der Universität
Karlsruhe entwickelt wurde, werden diese
Phasen verfeinert und auf das „SOP“-Konfigurationsmanagement angewendet [7].
Phase 1: Erfassen des Problems
Die Problemsituation muss zuerst
exakt analysiert werden. Daraufhin kann das
Problem eingegrenzt werden. Das kann
unter Umständen aber sehr aufwändig
sein: Bekommt der Benutzer beispielsweise keine Verbindung zum Server, können viele Ursachen dahinterstehen, sodass
eine Eingrenzung schwer fällt. Denn der
Fehler kann am Server, am Client oder am
darunterliegenden Netzwerk liegen.
Ein Fehler auf Server-Seite, dessen Behebung viel Zeit in Anspruch nahm, war
beispielsweise eine falsch eingestellte
DNS-Adresse. Dabei wurde trotz bestehender Verbindung zum Server die
Domäne „sopr4.hochschule-reutlingen.
de” nicht gefunden. In der Dokumentation
befand sich eine falsche DNS-Adresse,
was die Fehlererkennung erschwerte.
Zudem gab es keinen direkten Ansprechpartner, der sich mit dem System auskannte und sofortige Unterstützung leisten
konnte. Auch Hilfsanleitungen und Foren
halfen nicht weiter, da man das Problem
nicht konkret erfassen konnte. Letztendlich
SOP JOURNAL R4
27
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
wurde der Fehler dank Unterstützung eines
hilfsbereiten Mitarbeiters der Hochschule
entdeckt. Eine „2” wurde durch eine „4“
ersetzt und das Problem war behoben.
Der Support der Mitarbeiter erfolgt
häufig über Internettelefonie, Email oder
Nachrichtendienste wie ICQ. Da man
hier nicht selbst nach der Problemquelle
suchen kann, ist es wichtig, dass diese ihr
Problem konkret schildern und Anweisungen befolgen. Die Problemquellen sind
dabei häufig unterschiedliche Betriebssysteme oder Programmversionen sowie
Netzwerkeinstellungen. Erfahrungsgemäß
können Probleme auf Client-Seite einfacher eingegrenzt werden, da man einen
direkten Vergleich mit anderen funktionierenden Clientkonfigurationen hat.
Phase 2: Lösungsverfahren
Wichtige Voraussetzung: Das Problem
wurde erfasst, eingegrenzt und exakt
beschrieben. Nun werden verschiedene
Wege und Schritte zur Lösung des Problems untersucht und geplant.
Laut Professor Keller müssen bei jeder
Aufgabe erst Probleme analysiert werden.
Dann muss der Aufwand darauf geprüft
werden, ob dieser im gesteckten Rahmen erfüllbar ist. Anschließend sollen
Aufgabe in Teile zerlegt und das Ganze
rekursiv wiederholt werden. Wenn bei der
Ausführung dann unvorhergesehene Probleme auftreten, so Keller, muss sofort die
Tragweite abgeschätzt und bei geringstem
Verdacht auf Verzögerungen die Leitung
gewarnt werden. Erst dann darf versucht
werden, das Problem zu beheben.
Dr. Otto Buchegger ist im Artikel
28
SOP JOURNAL R4
Vor dem Review muss die Technik laufen. [Film]
„Problem - Lösungstechniken“ ähnlicher
Meinung, allerdings erkennt er einen
Nachteil in der Zerteilung von Problemen:
„Zum Beispiel kann es beim Unterteilen zu
Schnittstellenproblemen kommen, etwa
durch unzureichende Kommunikation.
So wird das Teilen selbst eine Ursache
von Problemen.“ Nichtsdestotrotz ist die
Zerteilung der Probleme sehr erfolgreich
und weit verbreitet [8].
Alternativen aufzeigen
Viele Wege führen nach Rom - deswegen muss man verschiedene Vorgehensweisen analysieren, um zu wissen, welche
letztendlich die Beste ist.
Beispielsweise wurde festgestellt,
dass die Client-Konfiguration und die
Arbeit an der Server-Domäne vielen
ClearCase-Benutzern zu umständlich ist.
Zudem kann man sich mit dem Standard-
K O N F I G U R AT I O N S - U N D Ä N D E R U N G S M A N A G E M E N T
betriebssystem Windows XP Home nicht
an einer Domäne anmelden, weshalb ein
anderes Betriebssystem verwendet werden muss.
Eine Alternative wäre der Betrieb
einer virtuellen Maschine. Damit kann ein
weiteres „Gast“-Betriebssystem auf dem
eigenen Host installiert, konfiguriert und
im Fenstermodus ausgeführt werden.
Auf diesem könnte man alle benötigten
Werkzeuge so installieren und konfigurieren, dass der Benutzer lediglich diese
virtuelle Maschine installieren muss. Dieser
muss sich dann nicht mehr um das lästige
Installieren aller Werkzeuge kümmern und
kann direkt mit seiner Arbeit beginnen.
Eine andere Alternative wäre der
Verzicht auf die Verwendung von
ClearCase und den damit verbundenen
Workarounds. Zur Verwaltung könnte man
Werkzeuge wie Subversion oder Sharepoint verwenden. Allerdings würde dann
ein mächtiges und bereits erworbenes
Werkzeug überflüssig. Zudem haben die
anderen genannten Werkzeuge ein kleineres Funktionsspektrum.
Lösungsauswahl
Vor- und Nachteile verschiedener
Lösungsansätze müssen gegeneinander
abgewägt werden. Dabei sollte auf
folgende Fragen eingegangen werden:
Welcher Weg ist der einfachste, effizienteste und kostengünstigste? Welche
Chancen und Risiken existieren? Wird
das Problem vollständig behoben oder
entstehen dadurch weitere?
Ein weiterer wichtiger Faktor ist die
Zeit. Nach Professor Keller gilt hierbei:
„Wenn sie eine Aufgabe in der Zeit x
erledigen sollen, dann gilt: Wer nach dem
Zeitpunkt x/2 noch Probleme feststellt
oder Verzögerungen erzeugt, ist zu entlassen.“
Dieser Leitsatz hört sich in der Theorie
sinnvoll an, konnte in der Praxis teilweise
jedoch nur schwer angewendet werden.
Zu Beginn des Projektes war diese Zeitplanung kaum möglich, da man wegen fehlender rollenspezifischer Vorkenntnisse
nicht wusste, mit welchen Problemen die
anstehenden Aufgaben verknüpft sind.
Traten Probleme auf, konnten sie nur mit
großen Umständen erfasst und gelöst
werden.
Phase 3: Erreichen des Soll-Zustandes
Einführung und Umsetzung
Sicheres Vorgehen ist bei Veränderungen am Server sehr wichtig. Führen die
Änderungen nicht zum Erfolg, sollen dies
rückgängig gemacht werden. Es hat sich
bewährt, jede Veränderung am System
schriftlich oder mit Screenshots zu dokumentieren. Somit können auch andere Per-
sonen das Problem und die eingeleiteten
Lösungsschritte nachvollziehen. Für den
Notfall ist zudem eine durchdachte
Backupstrategie erforderlich. Diese sollte
ohnehin funktionieren, nichtsdestotrotz ist
es empfehlenswert vor den Veränderungen das komplette System zu sichern.
„Never change a running system“.
Veränderungen am laufenden ServerSystem sind risikobehaftet und müssen
mit Vorsicht durchgeführt werden. Denn
hier befindet sich der logische Knotenpunkt, an dem alle Ressourcen zusammengefügt und verwaltet werden. Verfügt
man über die nötigen Ressourcen, kann
das komplette System auf die Festplatte
eines anderen Host gespiegelt werden,
sodass man ohne Risiko die geplanten
Veränderungen testen kann.
Nachbearbeitung und Lernen
„Aus Fehlern lernt man“. Da aber auch
die Nachfolgeiterationen aus diesen
lernen sollten, ist es sinnvoll, diese zu dokumentieren, sodass die Arbeit nur einmal
erbracht werden muss.
Marc Ammon, Konfigurations - und
Änderungsmanagement
Quellen
[1] Versuch und Irrtum
[2] Virtuelles Netzwerk dem sich Clients anschließen
[3] Namensauflösungsdienst im Internet
[4] Ermöglicht zentrale Authentifizierung und Authorisierung von Clients
[5] Verzeichnisdienst von Microsoft Windows Server 2003
[6] Situationsanalyse, Problemeingrenzung, Alternativen aufzeigen, Lösungsauswahl, Tragweite analysieren,
Einführung und Umsetzung, Nachbearbeitung und Lernen
[7] Albers, A.; Saak, M.; Burkardt, N.; Schweinberger, D.: Gezielte Problemlösung bei der Produktentwicklung
mit Hilfe der SPALTEN-Methode, 47. Internationales Wissenschaftliches Kolloquium, Technische Universität
Illmenau, 23.09.2002
Nähere Informationen zur SPALTEN-Methode unter:
a) http://www.ipek.uni-karlsruhe.de/medien/veroeffentlichungen/ICED05_albers_SPALTEN_Full_pa
per.pdf,
offizielles Dokument, 2005
b) http://de.wikipedia.org/wiki/Problemlösen Kapitel: „Methodische Problemlösung“, 2008
[8] Buchegger, Otto: Problem – Lösungstechniken, http://www.praxilogie.de/problemloesung.html, Tübingen, 2007
SOP JOURNAL R4
29
S O F T WA R E E N T W I C K L U N G
NICHTS ALS DIE WAHRHEIT?
Die Kommunikation im Softwareprojekt
Zu Beginn des fünften Semesters
erhalten die Studenten in der Vorlesung
eine grobe Übersicht über den Ablauf
des Softwareprojekts. Detaillierte Informationen zur Aufgabenstellung und den
gewünschten Arbeitsergebnissen liefert
jedoch die direkte Vorgängeriteration, die
sich im sechsten Semester befindet.
Die neuen Kunden werden mit den
Anforderungen an die Software und
mit den bestehenden Verträgen vertraut
gemacht, die Projektleiter erfahren, wie sie
einen Projektplan erstellen, die Tester erhalten die Testfälle, der Qualitätssicherung
werden die Richtlinien vorgelegt und
die Vorgänger des Konfigurations- und
Änderungsmanagements erklären ihren
Nachfolgern, wie die Server zu verwalten
sind.
Uns Entwickler interessiert vor allem
die Software. Wie funktioniert die Quellcodeverwaltung, welche Anforderungen
der Kunden wurden bereits umgesetzt,
welche Dokumente existieren diesbezüglich und wo sind sie zu finden? Die
Fragen sind oft zu detailliert, um von der
Geschäftsleitung beantwortet werden zu
können. Man ist hier ausschließlich auf das
Vermögen der Vorgänger angewiesen, die
Sachverhalte richtig weitergeben zu können und deren Gnade, dies neben ThesisStress auch noch zu tun.
Natürlich besteht auch die Möglichkeit, Antworten selbst zu finden. Ein Blick
30
SOP JOURNAL R4
in den Quellcode könnte z.B. verraten, in
wie weit Anforderungen bereits umgesetzt wurden. Doch das Sichten mehrerer
tausend Codezeilen kostet Zeit - und die
ist knapp im Softwareprojekt. Deshalb ist
es oft weniger aufwändig, die Vorgänger
zu fragen. Allerdings war es bei diesen
nicht anders und so beziehen sie ihre Antworten meist auch auf die Aussagen ihrer
Vorgänger. So entsteht über die Iterationen hinweg ein Informationsgerüst,
dass ähnlich einer Volkssage durch mündliche Weitergabe wächst und letztendlich
auf den Angaben derjenigen basiert, die
das Projekt einmal begannen: der ersten
und zweiten Iteration. Dadurch ist jedoch
der ursprüngliche Kontext oft nicht mehr
ersichtlich und Informationen werden
nicht sinngemäß überliefert, was auf lange
Sicht den Ruin für jedes Unternehmen
bedeutet.
Wege der Kommunikation
Der Informationsaustausch zwischen
den jeweiligen Abteilungen unterschiedlicher Iterationen erfolgt auf verschiedene
Arten:
Als den höchst offiziellen Kommunikationsweg lassen sich die Reviews bezeichnen. In ihnen werden die Ergebnisse der
vorangegangenen Arbeitsphase und die
kommenden Aufgaben präsentiert. Hier
haben die Nachfolger die Möglichkeit sich
Notizen zum Vortrag zu machen. Außer-
dem kann nachträglich ein Blick in die
Powerpoint-Folien oder das Handout, das
die Folien in ausformulierter Form enthält,
geworfen werden.
Eine weitere Grundlage für den Wissensaufbau bilden außerdem die erstellten Artefakte der Vorgängeriterationen.
Unter diesen Begriff fallen Dokumente
jeglicher Art: Installationsanleitungen, Beschreibungen von Problemen und deren
Lösungsansätzen, Richtlinien, aber auch
Klassen- und Anwendungsfalldiagramme.
Zu finden sind die Artefakte auf dem
Sharepoint Server, dem BSCW [1] Server
oder iterationsinternen Plattformen. Doch
hier herrscht nur sehr wenig Übersicht.
Allein auf dem Sharepoint befinden sich
193 Entwickler-Artefakte der letzten vier
Iterationen. Eine Strukturierung, z.B. durch
Ordner, ist meist nicht vorhanden. Auch
sind die Titel der Dateien in den meisten
Fällen nicht aussagekräftig, so dass auch
hier sehr lang nach entsprechenden Informationen gesucht werden muss. Durch
die fehlende Übersicht entstanden über
die Iterationen auch oft redundante Dokumente. Erstellt wurden diese Artefakte, da
nicht bekannt war, dass sie bereits existieren. Beispiel hierfür wären die Klasseniagramme, welche Aspekte des aktuellen
C#-Codes der Microsoft-Architektur darstellen. Erstmals wurde das Diagramm von
der Iteration R2 erstellt. Zum zweiten Mal
dann von unserer Vorgängeriteration.
S O F T WA R E E N T W I C K L U N G
Während die Suche nach den passenden Artefakten viel Zeit in Anspruch
nimmt, werden vor allem dringende Fragen meist direkt den Vorgängern gestellt.
Sei es nach Statusmeetings, bei zufälligen
Treffen auf dem Hochschulcampus oder
von zu Hause aus über Instant Messanger
wie z.B. ICQ. Grund für die Dringlichkeit
sind meist nahende Reviews, wenn sich in
letzter Minute noch Fragen zum Präsentationsthema ergeben. Da man größtenteils
zufriedenstellende Antworten erhält, bevorzugen viele diesen Kommunikationsweg auch für weniger brennende Fragen.
Abhängigkeit von der Richtigkeit der
Informationen
Der Zeitfaktor spielt während des
Softwareprojekts eine entscheidende
Rolle. Bei den Statusmeetings sollen
Zwischenergebnisse präsentiert werden,
die Reviews kommen schneller als man
denkt und auch in andere Vorlesungen
muss Zeit investiert werden. Dadurch ist
es unmöglich jede vorliegende Information zu prüfen. Stattdessen muss man sich
auf deren Richtigkeit verlassen.
die Vorgänger missverstanden? Hat man
Dokumente falsch interpretiert? Können
diese Fragen mit einem Nein beantwortet
werden, ist klar, dass es sich um Fehlinformationen handelt. Dabei muss zwischen
zwei Arten von Fehlinformationen unterschieden werden:
Im ersten Fall handelt es sich um
unbewusst weitergegebene Fehlinformationen. Dies geschieht, wenn Aussagen
oder Dokumente von anderen für wahr gehalten werden, sich aber später als fehlerhaft herausstellen. Dadurch sind natürlich
auch wahre Aussagen betroffen, die sich
auf diese falschen Informationen beziehen.
Zum Beispiel gaben wir in Statusmeetings
die Information unserer Vorgänger weiter,
die beiden Architekturen der Software
seien sehr unterschiedlich und machten
auf dieser Basis weitere Aussagen über
den Projektverlauf. Tatsache war jedoch,
dass sich die Architekturen, bis auf sprachspezifische Unterschiede, sehr ähneln.
Im zweiten Fall ist sich die Person bewusst darüber, dass in Gesprächen oder in
Schriftform weitergegebene Informationen
falsch sind. Zum Beispiel befindet sich in
den „MDA [2] Richtlinien“ der Iteration R3
der Hinweis, dass eben dieses Dokument
unserer Qualitätssicherung vorliegt. Dies ist
nicht der Fall. Auch im Dokument „Systemstruktur“ stießen wir auf Unstimmigkeiten:
„das Exception Handling ist im Object
Layer“. Das trifft jedoch nur auf die Microsoft-Architektur zu. Auf unsere Nachfrage,
ob die Metasuche bereits implementiert
und funktionsfähig sei, erhielten wir ein
klares „Ja“ als Antwort. Später mussten wir
jedoch feststellen, dass dies nicht so ist.
Auch das Verschweigen wichtiger
Details kann bei den Nachfolgern zu falschen Annahmen führen. So gingen wir
während des fünften Semesters davon
aus, die Vorgänger würden am MDAAnsatz für Server und Clients arbeiten. In
den Präsentationen erhielten wir keinen
Hatte Ihr Team von sieben Männern im Griff. [Film]
Auftreten von Fehlinformationen
Doch vor allem im sechsten Semester,
wenn man sich in das Projekt eingearbeitet
hat, stößt man immer häufiger auf Widersprüche zwischen den Informationen der
Vorgänger und der Realität. Um die Verantwortlichen damit zu konfrontieren ist
es oft zu spät, denn der Abschluss ist in
der Tasche, die Festplatte formatiert und
das Projekt aus dem Gedächtnis verdrängt.
Deshalb fragt man sich selbst: Wurden
SOP JOURNAL R4
31
S O F T WA R E E N T W I C K L U N G
Hinweis darauf, dass nur am Server gearbeitet wird. Wir bekamen lediglich die Information, dass der MDA Ansatz bei den
Clients schwieriger umzusetzen sei, da
sich Web- und Desktop-Clients im Aufbau
sehr unterscheiden.
Die Gründe
Gründe für das absichtliche Verbreiten von Fehlinformationen sind meist
Zeitmangel und der Druck, Ergebnisse zu
präsentieren. Fehlt die Zeit, werden Aussagen gemacht oder Dokumente verfasst,
ohne die Grundlagen noch einmal nachzulesen oder zu überprüfen. Von bloßer
Faulheit soll hier nicht ausgegangen werden. Begrenzt wird die vorhandene Zeit
durch Statusmeetings und Reviews, an
denen Arbeitsergebnisse und Leistungen
präsentiert werden sollen. Denn ohne
vorgestellte Leistung keine gute Note – so
die Annahme. Und die ist das primäre Ziel
der Studenten. Zählt doch die Note für
das Softwareprojekt mehr als die Thesis.
Lösungsansätze
Eine Möglichkeit das Problem der
Fehlinformationen zu lösen, wäre eine
inhaltliche Kontrolle der Artefakte und Informationen. Bisher werden Schriftstücke
von der Qualitätssicherung nur nach der
Form bewertet und der Tatsache, ob sich
der Schreiber an die Richtlinien hielt. Es
wäre jedoch notwendig, dass auch der
Inhalt kontrolliert wird. Deshalb müsste
die Qualitätssicherung durch zusätzliche
Mitarbeiter aufgestockt werden. Diese
sollten sich in den technischen Bereichen
des Softwareprojekts auskennen, um In-
32
SOP JOURNAL R4
formationen auch überprüfen zu können.
Richtige, vollständige Artefakte sollten
dann ebenfalls in die Benotung einfließen.
Durch diese zusätzliche Note würde auch
etwas Leistungsdruck von den Statusmeetings und Reviews genommen werden.
Außerdem sollte vermieden werden,
dass Dokumente allein aus dem Grund
verfasst werden, um sie als Arbeitsergebnis präsentieren zu können. So befinden
sich z.B. auf den unterschiedlichen Plattformen zum Thema „Systemarchitektur“
acht Dokumente. Alle mit fast identischem
Inhalt. Beim Interview am Ende des sechsten Semesters, welches ein Drittel der
Gesamtnote ausmacht, lässt sich solch ein
Dokument dennoch als Arbeitsergebnis
vorzeigen. Die Überflüssigkeit des Dokuments wird wahrscheinlich nicht bemerkt.
Allerdings bewirkt es, dass die Plattformen
immer unübersichtlicher werden.
Abhilfe könnte diesbezüglich auch
dadurch geschaffen werden, dass alle
Iterationen ihre Artefakte auf nur einer und
natürlich derselben Plattform speichern.
Allerdings wären zwei Bereiche empfehlenswert: ein Offizieller und ein Interner.
Im offiziellen Bereich werden alle Dokumente gespeichert, die qualitätsgeprüft
und für die nächsten Iterationen von
Bedeutung sind. Im internen Bereich,
sollen Dokumente abgelegt werden, die
ausschließlich für die aktuelle Iteration von
Interesse sind, wie Protokolle von Bespre-
chungen, Entwürfe für Problemlösungen
oder unterschiedliche Versionen eines
Dokuments. Nach dem sechsten Semester
könnten diese iterationsinternen Daten
dann gelöscht werden.
Durch übersichtlichere Plattformen
mit richtigen und vollständigen Artefakten
kann die Projekteinarbeitungszeit deutlich verringert werden. Auch müssen die
Vorgänger nicht mehr so oft kontaktiert
werden, weshalb sich diese ihren Aufgaben sowie der Thesis widmen können
und nur angesprochen werden, wenn
Fragen aufgrund fehlender Informationen
auftreten. Natürlich müssen die Vorgänger
zu Beginn des Projekts grundlegende
Abläufe erklären. Damit dieser Informationsaustausch strukturiert verläuft, sollten
die Richtlinien zur Kommunikation [3]
eingehalten werden. Voraussetzung ist
natürlich, dass diese auch den Mitarbeitern außerhalb der Qualitätssicherung
bekannt sind, was bei unserer Iteration bis
Mitte des sechsten Semesters nicht der
Fall war.
Diese Lösungsansätze bilden ein
grundlegendes Konzept für ein erfolgreiches Informationsmanagement. Durch den
Ausschluss von falschen oder veralteten
Informationen und die Zeitersparnis beim
Informationsaustausch sowie bei der Recherche nach existierenden Dokumenten
lässt sich die Effizienz eines Unternehmens um 50% bis 250% steigern[4].
Diana Hauser, Softwareentwicklung
(Leitung)
Quellen
[1] Basic Support for Cooperative Work, Serversoftware zur Dokumenten- und Projektverwaltung
[2] Model Driven Architecture, Ansatz zur Verbesserung von Softwareentwicklung
[3] Siehe Kapitel „Verwendung der Kommunikationsmittel“ der Organisationsrichtlinien (BSCW)
[4] Quelle: Büscher, Jens (2004). Informationsmanagement in Unternehmen. In: Contentmanager.
S O F T WA R E E N T W I C K L U N G
T.E.A.M.
Toll, Ein Anderer Macht’s?
Wenn ich das Wort „Teamarbeit“
höre, denke ich an meine Grund- und
Realschulzeit: Eine Gruppe von vier bis
fünf Schülern sitzt um zwei zusammengeschobene Tische, soll ein Problem
diskutieren und anschließend Ergebnisse
präsentieren. Eigentlich haben diese
Gruppen jedes Mal dieselbe Konstellation. Es gibt Personen die nichts sagen,
jene, die destruktiv „Müll“ beisteuern
und vom Thema ablenkten und andere,
die versuchen das, was ein einzelner in
5 Minuten erörtert hätte, noch irgendwie
bis zur Präsentation vernünftig hinzubekommen. Vortragen will dann jedes Mal
keiner.
Da standen wir nun. Das Team „Software-Entwicklung“: 8 Studenten. Eingeteilt
für ein Projekt, von dem wir bislang keine
Ahnung hatten. Sollte diese „Mannschaft“
meine frühere Erfahrung zur Teamarbeit
erneut bestätigen? Wir stellten mit unseren
8 Leuten das größte Team des Projekts.
Alle anderen Bereiche von der Projektleitung bis zur Qualitätssicherung waren
zwischen 2 und 3 Personen groß. So
eine große Gruppe erschien mir anfangs
allerdings trotz meiner bisherigen, eher
negativen Erfahrungen sehr angenehm: Es
gab mir irgendwie Sicherheit. Falls man
scheitert, steht man nicht alleine da. Dann
geht der ganze Kahn unter. Das Problem
bei dieser Geschichte ist jedoch die Gefahr, dass keiner etwas gegen das Sinken
des Schiffes tut. Jeder denkt: „Ein anderer
wird’s schon richten“. Das erscheint vor allem dann praktisch, wenn man sich nicht
auskennt.
Wissenschaftlich nennt man so etwas dann „soziales Faulenzen“ oder
auch den „Ringelmann-Effekt“ (vgl. [3]).
Maximilian Ringelmann, ein französischer
Agraringenieur fand bereits vor über 100
Jahren beim Tauziehen heraus, dass die
körperliche Leistung eines einzelnen in
der Gruppe geringer ist, als die Leistung,
die jeder für sich alleine bringen würde.
Die individuelle Leistung nimmt dabei
mit zunehmender Gruppengröße, laut
Ringelmann, weiter ab. 8 Sportler würden
demnach in einem Team beim Tauziehen
nur jeweils eine Eigenleistung von 49%
aufbringen (vgl. [4]). Wie wirkt sich diese
Erkenntnis auf 8 Studenten im Team „Softwareentwicklung“ aus?
In unserem Team gab es so etwas in
den wöchentlichen Statusmeetings zu
beobachten. Wenn eine Frage von Seiten
der Geschäftsführung, der Kunden oder
der Projektleitung an unsere Gruppe ging,
fühlte sich keiner angesprochen. Da in
einer großen Gruppe nicht ein einzelner
exemplarisch an den Pranger gestellt
wird, kann man sich hinter den anderen
verstecken. Dieses Verhalten konnte man
auch in unserem Team beobachten.
Als Herausforderung stellte sich auch
die Teamorganisation heraus. Durch die
täglichen Hochschulveranstaltungen sah
man sich zwar, meist wurde aber nur
geplänkelt und keine klaren Ziele bis zu
bestimmten Stichtagen vereinbart. So
verschob man einfach die Aufgaben
und einigte sich darauf, sich erst einmal
einzuarbeiten. Dies geschah ohne eine
klare Aussage zu machen, bis wann man
denn mit diesen Tätigkeiten fertig sei und
wann man dann definitiv mit der eigentlichen Arbeit beginnen könne. Warum auch
mehr tun, als die anderen 7 Kollegen? So
antworteten wir stets: „Wir sind noch bei
der Einarbeitung“. „Einarbeitung“ wurde
aber zu grob definiert. Kleine Schritte
wie „Entwicklungsumgebung installieren“
und „Verstehen der Software-Architektur“
hätten, mit einem Datum versehen, Fortschritte kenntlich gemacht und für klares
Feedback gesorgt.
[1] (S. 65 ff) beschreibt diese erste
Phase als Testphase, in der jedes Mitglied
sich auf seinen sozialen Status zurückzieht
und Maske zeigt. Gruppenmitglieder
testen in dieser Phase die gegenseitigen
Verhaltensweisen. In dieser Phase laufen
auch die Themensuche, die Themenfindung und die Aufgabendefinitionen
SOP JOURNAL R4
33
S O F T WA R E E N T W I C K L U N G
„Wer macht die Arbeit?” [5]
ab. Jedes Team bekommt deshalb eine
mehrwöchige Einfindungszeit, um sich
mit dem Projekt vertraut zu machen. Nach
dieser Zeit werden dann aber gewisse
Ergebnisse und Fortschritte erwartet.
Wir erkannten, dass, um diesen Erwartungen zu entsprechen, eine bessere
Organisation notwendig war. Nachdem
der Vorschlag eines wöchentlichen Treffens gefallen war entschied sich das Team
mehrheitlich für dieses Meeting. So bot
der Montagnachmittag fortan Zeit für gemeinsames Arbeiten und Diskussionen.
Die ersten Treffen verliefen allerdings nicht sehr effektiv: Alle redeten
34
SOP JOURNAL R4
wild durcheinander, einige schauten in
den Laptop, anstatt der anderen Person
zuzuhören oder man befand sich statt
im Besprechungsraum draußen beim
rauchen. Oft dauerte solch eine Sitzung
vier bis fünf Stunden. Anschließend war
aber kaum etwas besprochen.
Bei einer großen Gruppe ist deshalb
eine leitende Person zwingend nötig.
Dem Teamleiter fallen nach [1] (S. 102 ff)
die Aufgaben: moderieren, koordinieren,
organisieren, integrieren, repräsentieren,
balancieren, kommunizieren und motivieren zu. Mit zunehmend erhöhtem Entwicklungsstand und Reifegrad des Teams
können aber Bereiche auf die Teammitglieder verteilt werden. Die Rolle des Leiters nahm fortan unsere Entwicklerin Diana
Hauser ein, die diese Aufgaben über den
Verlauf des Projekts immer besser meisterte
und durch ihre strukturierte Organisation
der Meetings zunehmend an Autorität
innerhalb des Teams gewann. Die Treffen
verliefen nun weitaus ertragreicher, da vor
allem durch die Moderation die Themen
nicht durcheinander, sondern nacheinander abgearbeitet wurden. Zudem beschlossen wir ein Laptopverbot für die ersten 30 Minuten während der Gesprächsrunde. Wir definierten auch feste Stichtage,
S O F T WA R E E N T W I C K L U N G
an denen Ziele erreicht sein mussten
(Milestones). So eine Aufwandsschätzung
ist nicht einfach, wenn derartige Aufgaben
noch nie zuvor gemeistert wurden. Sie ist
trotzdem nötig, um den Projektleitern und
sich selbst einen klaren Überblick über die
Situation zu verschaffen.
Für architektur- und programmiertechnische Aufgaben stellte sich jedoch
heraus, dass bei einer Anzahl von acht
Personen keine effektive Arbeitsweise erreicht werden konnte, da zu viel Zeit für
die interne Kommunikation anstatt für die
Problemlösung benötigt wurde. Für die
meisten Aufgaben teilten wir uns deshalb
in Zweiergruppen ein. So eine innere
Gruppenstrukturierung ist dann sinnvoll,
wenn man kleine Arbeitspakete aus der
großen Aufgabe „herausbrechen“ kann,
welche dann unabhängig voneinander
parallel bearbeitet werden können – in
unserem Fall einzelne Komponenten der
Software. Unter der Woche konnten wir
Teilergebnisse in den Zweiergruppen erzielen, welche dann im Meeting diskutiert
und konsolidiert wurden.
Den „Ringelmann Effekt“ konnte ich
fortan, nicht mehr feststellen. Ganz im Gegenteil empfinde ich in unserem Team nun
eine anspornende Atmosphäre. Es existiert der verbundene Gedanke gemeinsam
unser Ziel zu erreichen. Auch verbesserte
sich der soziale Umgang untereinander.
Hat ein Entwickler Probleme bei einer Aufgabe, bekommt er nun Hilfe angeboten.
Hält ein Entwickler nicht den vereinbarten
Stichtag für eine bestimmte Aufgabe ein,
wird er vom Rest des Teams getadelt, um
das gemeinsame Ziel weiterhin erreichen
zu können. Fühlt er sich jedoch beleidigt,
verletzt oder zu Unrecht kritisiert kann
die Situation schnell zu einem Streitfall
eskalieren. Wichtig ist deshalb, dass diese
Kritik Mängel aufzeigt und trotzdem einen
motivierenden Effekt auf den Mitarbeiter
hat, da mit ihr eine Besserung seiner Arbeitsweise erreicht werden soll. Man sitzt
eben im selben Boot, daher gibt es nicht
nur den Gedanken der eigenen Leistung,
sondern auch den der Teamleistung, denn
wenn der Kahn zu sinken droht, kann ein
Team mit richtiger Planung und Koordination mehr erreichen als ein einzelner.
Umso größer die Teilnehmerzahl des
Teams ist, umso extremer kann die Situation in beide Richtungen (gegenseitiger
Ansporn, aber auch Ringelmann Effekt)
ausschlagen.
Exkurs: Als Beispiel für die Begeisterung und Zielstrebigkeit für eine gemeinsame Sache, die innerhalb einer Gruppe
erreicht werden kann, möchte ich an das
deutsche Verbundenheitsgefühl der WM
2006 erinnern. Wie wir allerdings wissen,
kann dieses Gruppenphänomen auch,
wie in den 40ger Jahren, zu einem sehr
unschönen Ergebnis führen. Dies stellte
auch jüngst der deutsche Kinohit „die
Welle“ von Dennis Gansel wieder unter
Beweis.
Ich habe durch dieses Projekt für mich
das Arbeiten im Team in ein positiveres
Licht rücken können. Außerhalb des Bildungswesens gibt es kaum Aufgaben,
die ein Einzelner vollständig alleine lösen
kann. Ob im Sport, in der Familie oder in
der Firma, Teamfähigkeit ist stets gefragt.
Daher ist es sinnvoll Teamarbeit an der
Hochschule zu fördern. Anfangsschwierigkeiten im Team sind normal. Jede Person
trägt verschiedene Instanzen, Tendenzen
und Persönlichkeitselemente in sich (vgl.
[2]). Gerade das macht aber ein gutes
Team aus. Dinge sollten von unterschiedlichen Blickwinkeln betrachtet werden.
Natürlich dauert es immer eine gewisse
Zeit, bis ein Team richtig aufeinander
abgestimmt ist und effektiv arbeitet. Da
die meisten Aufgaben für uns erst in den
späteren Phasen des Projekts angefallen
sind, hatten wir die nötige Einarbeitungszeit zur Verfügung. Durchdachte Planung,
Konsequenz, Hierarchien und Untergruppierungen innerhalb der Gruppe sind für
einen effektiven Arbeitsverlauf allerdings
unabdingbar. Mitgebrachte Erfahrungen
der Mitglieder durch Gruppenarbeit aus
jeglichen anderen Gebieten sind wünschenswert.
Robert Krüger, Softwareentwicklung
Quellen
[1] Haug, Christoph V.: Erfolgreich im Team – Praxisnahe Anregungen für effiziente Team- und Projektarbeit, deutscher Taschenbuch Verlag GmbH & Co. KG, 3. Auflage, München 2003
[2] Pohl, Michael/Witt, Jürgen/Pohl, Gudrun: Innovative Teamarbeit zwischen Konflikt und Kooperation, Sauer I.H.
Verlag GmbH 2000, S.47 ff
[3] http://www.business-wissen.de/personal/teamarbeit/anwenden-umsetzen/teamarbeit-mitarbeiter-organisierensich-selbst-im-team.html, (Stand: 24.5.2008)
[4] http://de.wikipedia.org/wiki/Ringelmann-Effekt, Ringelmanneffekt (Stand: 28.05.08)
[5] www.4managers.de, (Stand: 28.05.2008)
SOP JOURNAL R4
35
S O F T WA R E E N T W I C K L U N G
PLANUNG ODER CHAOS?
Die Rolle der Planung bei der Einführung der “Model Driven Architecture”
„Model Driven Architecture“ ist
ein standardisiertes Konzept für die
Softwareentwicklung. Es wurde von der
„Object Management Group“ ausgearbeitet, einem Konsortium aus Firmen
der IT-Branche. Dieses Verfahren soll im
Softwareprojekt bei der Softwareentwicklung angewendet werden. Dafür ist eine
Eingliederung der „Model Driven Architecture“ in den Entwicklungsprozess notwendig. Die Vorgängeriteration hat diesen
Prozess begonnen und die Aufgabe der
Entwicklungsabteilung war es ihn fortzusetzen. Hierfür mussten Einzelaufgaben
festgelegt und umgesetzt werden. Verlief
die Umsetzung wie beabsichtigt und war
die Vorgehensweise dabei richtig?
Einführung
Im Rahmen des Softwareprojekts wird
ein Langzeitarchivierungssystem entwickelt um Daten automatisiert zu archivieren.
Um größere Lerneffekte zu erzielen wird
die Entwicklung in einer Java - und in einer
NET - Plattform vorgenommen. Dadurch
entstehen zwei Produkte, jeweils bestehend aus einem Server und zwei Clients.
Die beiden Produkte besitzen die
gleichen Funktionsweisen, die aber unterschiedlich umgesetzt werden. Eine
Angleichung soll erreicht werden, in dem
die beiden Produkte auf eine gemeinsame
Basis gestellt werden. Von dieser ausge-
36
SOP JOURNAL R4
hend, lassen sich dann beide Produkte
entwickeln. Die „Model Driven Architecture“ bietet hierfür Modelle an. In einem
gemeinsamen
plattformunabhängigen
Modell wird das Zusammenspiel der
Elemente der Produkte vereinigt ohne
auf technische Bestandteile einzugehen.
Wird das plattformunabhängige Modell
um technische Bestandteile der beiden
Plattformen erweitert, so ergibt sich je ein
plattformspezifisches Modell für die NETund die Java-Plattform. Mit Hilfe dieser
Modelle lässt sich die Logik der Softwaresysteme erarbeiten. Hinterlegt wird
die Logik dann in Softwarequelltexte, die
in die benutzbaren Produkte überführt
werden. In der Entwicklungsabteilung
wurde dieser Prozess ausgehend von
einem unvollständigen plattformunabhängigen Modell durchgeführt. Dazu bezieht
sich der Prozess nur auf die Server der
Produkte. Die Clients wurden hierbei nicht
berücksichtigt.
Planung der Vorgehensweise
und Umsetzung
Zuerst musste eine Gesamtplanung
des Vorgehens durchgeführt werden.
Dabei wurden die einzelnen Arbeitsschritte erarbeitet und geplant. Die Entwicklungsabteilung war demokratisch
organisiert. Das bedeutet, alle Mitarbeiter
nahmen an der Planung teil. Laut [2] hat
die Abteilungsleiterin dabei die Aufgabe
regulierend in die Planung einzugreifen.
Dies ist notwendig, wenn gemeinsam
kein Konsens oder keine Entscheidung
gefunden werden kann. [2] sieht bei
der demokratischen Organisationsform
das Problem, dass der Kommunikationsaufwand hoch ist, da sich die Mitarbeiter
häufig absprechen müssen. In der Entwicklungsabteilung zeigte sich das gleiche
Problem. Dazu erwies es sich als schwierig
gemeinsam eine Lösung zu finden. Die
Vorschläge der Mitarbeiter waren teilweise
zu unterschiedlich. Erschwerend kam
hinzu, dass die Abteilungsleiterin oft nicht
regulierend eingriff. Während der Gesamtplanung wurden erarbeitete Vorgehensweisen auch oft überworfen. Da manche
Entwickler später bewiesen, dass nicht
wie geplant vorgegangen werden kann.
Deswegen wurde kurzfristig eine neue
Strategie erarbeitet. Dadurch entstanden
Unsicherheiten bei den anderen Entwicklern. Sie waren sich nicht mehr sicher,
wie nun vorgegangen werden soll. Das
führte dazu, dass Entwickler während der
Umsetzung der Einzelaufgaben Teilergebnisse lieferten, die nicht dem entsprachen,
was benötigt wurde. Beispielsweise sollte
die Vervollständigung des plattformunabhängigen Modells nach definierten Regeln
erfolgen. Jedoch hielten sich manche
Entwickler nicht an diese Regeln. Somit
S O F T WA R E E N T W I C K L U N G
war der offizielle Fertigstellungstermin
des plattformunabhängigen Modells gefährdet. Es mussten teilweise kurzfristig
und sehr chaotisch die Mängel in den
fehlerbehafteten Teilergebnissen bereinigt
werden. Dabei wurden neue Fehler verursacht und es gab viel Streit zwischen den
einzelnen Entwicklern.
[2] zeigt auf, dass neben der demokratischen Organisationsform auch eine hierarchische gewählt werden kann. Dabei
plant der Leiter der Abteilung die durchzuführenden Aufgaben selbstständig.
Somit lässt sich der Kommunikationsaufwand während der Gesamtplanung
vermeiden. Allerdings sieht [2] dabei das
Problem, dass der Leiter der Abteilung
dieser Aufgabe nicht gewachsen sein
könnte. Dies kann zu einem Scheitern
des Projekts führen. Um die entstandenen Probleme zu vermeiden, sollte
eine Organisationsform gewählt werden,
die an die hierarchische Organisation
anlehnt. Die Gesamtplanung wird hierbei
jedoch von einer kleinen Expertengruppe
übernommen. Beispielsweise aus der
Abteilungsleiterin und einem oder zwei
Spezialisten. Ein Spezialist ist ein Entwickler, der einen hohen Erfahrungsschatz im
Bereich Softwaremodellierung aufweist.
Die Expertengruppe findet schneller
ein Konsens bei der Gesamtplanung,
da weniger Mitarbeiter beteiligt sind. Es
entstehen keine Unklarheiten, da die Expertengruppe einmalig das Gesamtvorgehen definiert und dies den Mitarbeitern
mitteilt. Und die Abteilungsleiterin wird
von der alleinigen Entscheidungsverantwortung entlastet.
Nach der Gesamtplanung wurden
die Einzelaufgaben umgesetzt. Bei der
Ergänzung des plattformunabhängigen
und der Erstellung der plattformabhängigen Modelle wurde eine Einzelaufgabe an ein Zweier-Team vergeben.
Diese bestand darin, die fehlenden Elemente einer Schicht des Servers in die
entsprechenden Modelle zu übertragen.
Diese Vorgehensweise wurde gewählt,
da die beiden Server aus den gleichen
5 Schichten bestehen. In einer Schicht
sind zusammengehörige Elemente eines
Servers gebündelt. Die Einzelaufgaben
wurden entsprechend der Vorkenntnisse
der Teams verteilt. Deswegen wurde jede
Schicht der Server auf die Schwierigkeit
der Modellübertragung untersucht. Als
Maß wurde hierbei die Komplexität und
Funktionalität gewählt. Nach der Umsetzung der Einzelaufgaben zeigte sich, dass
die Kriterien falsch bemessen waren. Es
kommt eigentlich darauf an, wie unterschiedlich die gleichen Schichten der
Server programmier sind. Somit waren die
Einzelaufgaben ungleich verteilt. Manche
Teams waren schnell mit der Umsetzung
fertig, andere Teams hingegen erst kurz
vor der Abgabefrist. Für diese Teams
musste unter Zeitdruck noch eine Lösung
gefunden werden, wohingegen die anderen Teams schon fertig waren. Durch
das Arbeiten unter Zeitdruck entstanden
Fehler, die erst nach der Abgabefrist der
Einzelaufgaben entdeckt wurden. Somit
mussten die betreffenden Teams im Nachhinein diese Fehler bereinigen.
Dies hätte vermieden werden können.
Laut [1] kann vor der Einführung der Model
Driven Architecture in den Entwicklungsprozess ein Pilotprojekt durchgeführt
werden. Das Pilotprojekt dient dazu, anhand eines Testprojekts Erkenntnisse über
die Werkzeuge und Prozesse zu gewinnen. Durch ein Pilotprojekt hätte sich
gezeigt, wie man die Einzelaufgaben bei
der Vervollständigung und der Ergänzung
richtig verteilen kann.
Fazit
Damit keine chaotischen Zustände
während der Integration der Model
Driven Architecture in einen Entwicklungsprozess entstehen, muss richtig geplant
werden. Während der Planung kommt
es darauf an, dass die Arbeitslast gleich
verteilt wird. Dazu ist es hilfreich, bereits
in einem Pilotprojekt die Methoden und
Verfahren der Model Driven Architecture
kennen zu lernen. Somit lassen sich Fehler
bei der Planung vermeiden, da bereits aus
Projekterfahrungen geschöpft werde kann.
Der Planungsprozess sollte so gestaltet
werden, dass er nicht zu viel Zeit braucht.
Dazu muss das Vorgehen, das aus dem
Planungsprozess resultiert, klar erkenntlich
sein. Fehlplanungen können vermieden
werden. Das sollten sie auch, denn die
Planung beeinflusst den Erfolg der Integration der Model Driven Architecture.
Sebastian Schulz, Softwareentwicklung
Quellen
[1] Gruhn, Pieper, Röttgers „MDA – Effektives Software- Engineering mit UML 2 und Eclipse“ Springer Verlag 2006
[2] Ludewig, Lichter „Software Engineering – Grundlagen, Menschen, Prozesse, Techniken“ dpunkt Verlag 2007
SOP JOURNAL R4
37
Softwareprojekt Iteration R4 (Juni 2008)
S O F T WA R E E N T W I C K L U N G
SOP WARS: KRIEG DER ABTEILUNGEN
Die Zusammenarbeit der Softwareentwicklung mit anderen Abteilungen
„Wann tut denn endlich der
Server?“ – diese Frage wurde von den
Entwicklern in den letzten Monaten
an die Abteilung Konfigurations- und
Änderungsmanagement oft gestellt.
Denn ohne Server können sie nicht
arbeiten. Diese Abhängigkeit bringt
die
Softwareentwicklung
immer
wieder in Schwierigkeiten. Doch auch
die Zusammenarbeit mit anderen
Abteilungen fällt den Entwicklern
nicht immer leicht.
Die Arbeit der Softwareentwicklung
verzögert sich immer wieder, weshalb die
Entwickler gegen Ende des Projektes unter
Zeitdruck geraten. Es gibt verschiedene
Gründe für die Verzögerungen: ein wesentlicher Bestandteil ist die Abhängigkeit der Entwickler von verschiedenen
Abteilungen, da nur diese die Mittel
haben spezielle Probleme zu lösen.
Häufig müssen ausgefallene Server oder
Software wieder zum laufen gebracht
werden. Doch es gibt nicht nur technische
Störungen, die behoben werden müssen,
auch das Problem der Arbeitsüberlastung
muss gelöst werden.
Die Softwareentwicklung benötigt
Unterstützung, denn sie wird immer
wieder mit kleinen Aufgaben von anderen
40
SOP JOURNAL R4
Abteilungen aufgehalten. Diese brauchen
Informationen, die sie nur von den Entwicklern bekommen können, und gehen
dabei den Entwicklern mit ihren ständigen
Anfragen hin und wieder auf die Nerven.
Qualitäts… wer?
Der
Kontakt
zwischen
Qualitätssicherung und Softwareentwicklung
ist sehr selten. Die Entwickler ordnen
der Qualitätssicherung Aufgaben zu,
wie beispielsweise Dokumente auf ihre
Qualität zu überprüfen. Diese schicken
die Dokumente, die nicht dem Qualitätsanspruch gerecht werden, an die
Entwickler zur Nachbesserung zurück. Da
die Qualitätssicherung viele Dokumente
überprüfen muss, können Wochen vergehen, bis ein Feedback den Entwickler erreicht. Wenn das Dokument von der Qualitätssicherung freigegeben wurde, kann es
auf der entsprechenden Dokumentenablage veröffentlicht werden. Des Weiteren
muss sich die Softwareentwicklung an
die von der Qualitätssicherung erstellten
Programmierrichtlinen halten.
Ansonsten hat die Softwareentwicklung mit der Qualitätssicherung nichts zu
tun.
Testing, teste!
Die Abteilung Testing wird oft in die
Softwareentwicklung integriert, denn sie
prüft die Software auf Fehler. Damit das
Testen ohne Probleme abläuft, wird die
Abteilung Testing von den Entwicklern
über die Zusammenhänge der Software
aufgeklärt. Je nach Kenntnisstand des
Testingteams, ist hier der Zeitaufwand
sehr unterschiedlich.
Nach dieser Einlernphase werden die
Tester von den Entwicklern „gezwungen“
die Clients und Server zu testen, sofern
diese von den Entwicklern bearbeitet
wurden. Beim Testen entdeckte Fehler
werden den Entwicklern mitgeteilt, sodass diese den Fehler schnellst möglich
ausbessern können. Durch das Delegieren
der Fehlersuche an eine andere Abteilung
werden die Entwickler erheblich entlastet
und haben so mehr Zeit für die Implementierung.
Die Arbeitsvermittlung
Projektmanagement
Jede Aufgabe bezüglich der Softwareentwicklung im Projekt, wird vom
Projektmanagement entsprechend weitergereicht. Ebenfalls teilt das Projektmanagement Ressourcen für die Aufgaben
ein, dies bedeutet, sie legen fest wie viele
S O F T WA R E E N T W I C K L U N G
Manchmal heißt es: Schwitzen, Zähne zusammenbeißen und durchhalten! [Film]
Entwickler eine Aufgabe erledigen sollen
und fordern von diesen eine Zeitplanung
ein. Die Projektleiter sind zufrieden, wenn
der abgegebene Zeitplan eingehalten
oder unterschritten wird. Nach Erledigung
einer Aufgabe werden die Ressourcen
neu verteilt, je nach Aufgabe die das
Projektmanagement für die Softwareentwicklung hat.
Wenn die Entwickler unter Zeitdruck
stehen und es den Anschein erweckt, dass
die Arbeit nicht zum genannten Termin
fertig wird, werden vom Projektmanagement Personen aus anderen Abteilungen
der Softwareentwicklung zur Verfügung
gestellt. Diese Aushilfen unterstützen
die Entwickler meist in der Entwicklung-
sphase, in der die geplanten Änderungen implementiert werden, da dies den
größten Aufwand im gesamten Projekt
darstellt.
Quälgeist Kunde
Auch der Kunde kontaktiert die
Softwareentwicklung und verursacht dadurch Mehrarbeit. Es sind meist kleinere
Aufträge: Prüfung der Change Requests
und Anforderungen, Auflistung der benutzten Werkzeuge. Diese Aufträge können zeitintensiv werden, wenn der Kunde
noch mehr Informationen wünscht.
Sehr mühsam ist das Prüfen der
Anforderungen und Change Requests
im Quellcode, um die nicht erledigten
zu identifizieren. Aufgrund von zwei
Architekturen - C# und Java - ist diese
Aufgabe für die Entwickler noch beschwerlicher. Jede Architektur ist verschieden,
weshalb man auf jedes Detail im Quellcode, der jeweiligen Architektur, achten
muss. Jedoch ist es den Entwicklern nicht
möglich, jede Anforderung oder Change
Request im Quellcode zu überprüfen, da
diese teilweise sehr unpräzise ausgedrückt
sind. Eine Anforderung lautet: „Jeder Benutzer klickt alle 5 Sekunden auf einen Link
und erzwingt somit eine Antwort des Systems“. Bei dieser Anforderung weiß man
nicht, was gemeint ist. Aus diesem Grund
ist die Anforderung nicht überprüfbar. Der
Kunde muss sich schließlich damit abfin-
SOP JOURNAL R4
41
S O F T WA R E E N T W I C K L U N G
den, dass nicht nach allen Anforderungen
und Change Requests geforscht werden
kann.
Konfigurations- und Änderungsmanagement und die Softwareentwicklung:
eine Hassliebe
Die engste Zusammenarbeit mit der
Softwareentwicklung besteht zwischen
der Abteilung Konfigurations- und
Änderungsmanagement. Diese ist für die
Installationsanleitungen der Software, die
Wartung und die Einrichtung der Server
zuständig.
Sie wird kontaktiert, sobald ein Server
nicht funktioniert oder man Schwierigkeiten bei der Konfiguration des eigenen
Computers hat, so dass man auf den
Servern arbeiten kann.
Bei der Installation von Programmen
und dabei auftretenden Problemen, wird
gemeinsam nach der Ursache gesucht.
Dies verzögert die Arbeit der Entwickler,
da für beide Parteien ein passender Termin
gefunden werden muss, um das Problem
aus der Welt zu schaffen. In dieser Zeit
sind die anderen Aufgaben des Entwicklers eingeschränkt, da er die für die Arbeit
vorgesehenen Programme nicht nutzen
kann. Eine weitere Verzögerung tritt ein,
wenn der Fehler nicht behoben werden
kann. In diesem Fall muss der Entwickler
versuchen mit anderen, umständlicheren
Methoden, zu arbeiten. Ein Beispiel hierfür
ist, wenn ein Problem mit ClearCase [1]
auftritt und der Entwickler nicht auf das
Repository [2] zugreifen kann. Hier wird
meist der Quellcode per Email an einen
Entwickler gesendet, der den veränderten
42
SOP JOURNAL R4
Quellcode wieder in ClearCase einpflegt.
In der Abteilung in der ich gearbeitet
hatte und meine Erfahrungen sammeln
konnte, verzögerte sich die Arbeit der
Entwickler durch Serverumstellungen und
die daraus resultierenden Neuinstallationen der Software. Hierbei traten Fehler
auf, die von den Entwicklern nicht gelöst
werden konnten und so mussten sie sich
wieder an die Abteilung Konfigurationsund Änderungsmanagement wenden.
Diese probierten das Problem zu lösen,
das jedoch manchmal nicht lokalisiert
werden konnte und man auf gut Glück versuchte die Software auf den Computern
der Entwickler noch einmal zu installieren
- in manchen Fällen half das. Doch eine
Software neu zu installieren benötigt Zeit
und Nerven und von beidem hatten die
Entwickler zu wenig. Vor ihnen stand ein
Berg voller Arbeit, konnten jedoch nicht
arbeiten, denn nichts funktionierte wie
es sollte. Nach Tagen ohne lauffähige
Software, kam endlich die Erlösung in
Form einer Installationsanleitung, das die
Abteilung Konfigurations- und Änderungsmanagement geschrieben hatte. Nach
dem die Entwickler die Installationsanleitung befolgt hatten, konnten sie mit ihrer
Arbeit beginnen.
Zusammenarbeit ist wichtig
Das Zusammenarbeiten mit anderen
Abteilungen ist für die Softwareentwick-
lung nicht immer leicht, weil es immer
wieder zu Kommunikationsschwierigkeiten
kommt. Sehr oft werden Emails nicht gelesen, an falsche Personen geschickt, oder
ein Problem mündlich mit einer Person
zwischen Tür und Angel besprochen.
Diese Probleme können gelöst werden,
wenn jeder das eigene Emailpostfach
täglich prüft und die geschriebenen
Emails über definierte Verteiler an die
Abteilungen versendet. Meetings sollten
protokolliert werden und das Protokoll
anschließend als Email an die teilnehmenden Personen versendet werden. So
kann verhindert werden, dass getroffene
Absprachen vergessen und deshalb nicht
eingehalten werden. Diese Unannehmlichkeit wird von den Entwicklern gerne in
Kauf genommen, wenn dadurch Probleme
gelöst werden können.
Trotz der vielen Anfragen, stehen
sie anderen Abteilungen immer zur Verfügung, wenn diese Hilfe benötigen.
Zwangsläufig führt das jedoch zu einer
Überbelastung, weswegen man in Zukunft mehr Entwickler einsetzten sollte, die
diese Flut an Arbeit unter sich aufteilen
können.
Trotz Überbelastung und Kommunikationsschwierigkeiten, ist eine gute
Zusammenarbeit für das Vorrankommen
des Projektes unerlässlich, weswegen die
Softwareentwicklung Anfragen anderer
Abteilungen gerne bearbeitet.
Emre Yay, Softwareentwicklung
Quellen
[1] Versionisierungssoftware
[2] zu Deutsch: Lager oder Depot; Es werden hier Dateien (in diesem Fall Quellcode) abgelegt
S O F T WA R E E N T W I C K L U N G
PROBLEME BEI DER KOLLABORATION IN
DER SOFTWAREENTWICKLUNG
. . . und das Chaos bei der Verwaltung gemeinsamer Arbeitsmittel.
Bei der Entwicklung von Software
im Rahmen eines Projektes in dem viele
Projektmitglieder gemeinsam einen Arbeitsauftrag wahrnehmen, ist eine gute
und effektive Verwaltung der gemeinsamen Arbeitsmittel [1] unverzichtbar. Im
Folgenden werde ich auf die Probleme
eingehen, welche diese Herausforderung
im Software-Projekt an der Hochschule
Reutlingen mit sich bringt.
Das Software-Projekt ist auf Basis des
RUP [2] in verschiedene Teams unterteilt.
Da ich zum Team der Softwareentwickler
gehöre, beziehen sich die folgenden Ausführungen auf die Sicht der Softwareentwickler.
Zunächst eine kurze Beschreibung der
Situation. Das SE-Team [3] greift gemeinsam hauptsächlich auf folgende Arbeitsmittel zu:
- Diverse Dokumente
(Anleitung, Dokumentationen)
- Programmcode-Dateien
- Diagramm-Dateien
- Entwicklungswerkzeuge und Plugins
Zum Zeitpunkt der Erstellung dieses
Dokuments sind diese Arbeitsmittel auf
verschiedenen Systemen aus dem Bereich Computer gestützte Zusammenarbeit (CSCW [4]) und Versionsverwaltung
verteilt.
BSCW Shared Workspace System
Das BSCW ist eine webbasierte Anwendung zur Unterstützung der Zusammenarbeit über das Intranet oder Internet.
Es bietet eine umfangreiche Rechte- und
Zugriffsverwaltung. Es lassen sich Dokumente in gemeinsamen Arbeitsbereichen
ablegen und austauschen. Das BSCW
ermöglicht unter anderem auch Unterstützung zur gemeinsamen Terminplanung,
Kommunikation und Aufgabenplanung.
Dabei benötigt man auf der Seite des Client nicht mehr als einen Webbrowser. Das
BSCW gehört zur Kategorie der Groupware-Systeme. Groupware sind Anwendungssysteme, die die Zusammenarbeit
von Gruppen unterstützen [5, S.138]. Dazu
zählt man unter anderem auch Videokonferenz- sowie E-Mail-Systeme.
Microsoft Windows Sharepoint-Services
Auch dieses System bietet ähnlich
wie das BSCW eine Infrastruktur, welche
Zusammenarbeit unterstützt, und lässt
sich ebenfalls der Kategorie Groupware
zuordnen.
IBM Rational ClearCase und Subversion
Rational ClearCase und Subversion sind Versionskontrollsysteme. Ein
solches System unterstützt das Zusammenarbeiten an gemeinsamen Dateien
und Verzeichnissen. Typischerweise
sind es Quellcode-Dateien. Grundsätzlich können es aber auch andere auf
dem ASCII-Code basierende Dokumente
sein. Versionskontrollsysteme bieten die
Nachvollziehbarkeit von Veränderungen
an Dateien. Diese Veränderungen können einem Zeitpunkt und einer Person
zugeordnet werden. Sie bieten auch die
Möglichkeit, Veränderungen die nicht vorhersehbare Konsequenzen hatten, wieder
rückgängig zu machen. In der Softwareentwicklung gehört ein solches System heute
zum Standard.
Die Verwendung mehrerer Gruppenarbeit unterstützender Systeme führt
jedoch zu folgenden Problemen: Es gibt
keinen Konsens über eine einheitliche
Struktur oder Methodik zur Ablage von
Arbeitsmitteln. Zudem hat jedes Semester
sein eigenes System favorisiert, was das
Auffinden der Arbeitsmittel zu einem
zeitaufwendigen Prozess macht. Die
Idee hinter dem Einsatz von Systemen
zur Unterstützung von Kollaboration und
Kooperation ist gut. Allerdings scheint die
Auswahl und Kombination der Werkzeuge
eher historisch gewachsen zu sein.
Denn es ist sinnlos mehrere, sich nicht
ergänzende, sondern in ihren Funktionen
überschneidende Systeme einzusetzen.
So haben wir z.B. zwei Groupware-Sys-
SOP JOURNAL R4
43
S O F T WA R E E N T W I C K L U N G
aktuellste Version eines Dokuments ist,
denn es könnte an einem anderen Ort eine
aktuellere Version liegen.
Durch die chaotischen Zustände ist
die Einarbeitung des alterierenden „Projekt-Personals“ sehr zeitaufwändig. Dieser
unnötige Zeitaufwand wirkt sich negativ
auf die Motivation aus.
Und zieh! [Film]
teme im Einsatz. Das erhöht den Koordinationsaufwand erheblich und wirkt sich
negativ auf die Effizienz der Projektarbeit
aus. Hinzu kommt noch, dass mit jedem
Semester eine neue Iteration beginnt. Es
müssen also mit jedem Semesterbeginn
neue Zugänge eingerichtet werden. Dies
erhöht den Verwaltungsaufwand auf Seiten
der Administratoren dieser Werkzeuge
enorm. Auch die Benutzer haben keinen
Überblick wo sie welches Arbeitsmittel
finden und verlieren sehr viel Zeit durch
Suche und Anmeldung in verschiedenen
Systemen. Die Gefahr von inkonsistenten
und redundanten Daten steigt. Zudem ist
schwer nachzuvollziehen, welches die
44
SOP JOURNAL R4
Der Weg in die richtige Richtung
Momentan gehen die Absichten in
die folgende Richtung: Alle Arbeitsmittel
sollen einheitlich im Versionskontrollsystem (ClearCase) verwaltet werden. Richtet
man dort eine logische und nachvollziehbare Ordnerstruktur ein, so führt dieses
System sicher zu einer Verbesserung der
Situation und erhöht die Effizienz der
Projektarbeit. Die Navigation in ClearCase
entspricht jedoch der eines gewöhnlichen Dateisystems, und bietet bis auf die
Zugriffskontrolle und Versionsverwaltung
keine weitere Unterstützung der Zusammenarbeit.
Groupware als Ergänzung
Ergänzend sollte man sich deshalb
für EIN Groupware-System entscheiden.
Nur so lassen sich Kommunikation, Koordination und Kooperation angemessen
unterstützen. Das BSCW beispielsweise,
als eines der Groupware-Systeme, hat
viele weitere Möglichkeiten wie Kontaktlisten, Diskussionsforen und gemeinsame
Kalender. Auch die Navigation durch
eine einfache Dateistruktur, wie sie von
einem Versionskontrollsystem in der Regel
geboten wird, wird mit zunehmendem
Umfang des Repositorys [6] schwierig.
So könnte ein Werkzeug wie das BSCW,
zusätzlich als Navigations- und Kommunikationsunterstützung genutzt werden.
So machen es die Profis
Eine andere Möglichkeit ist, eine Wissensdatenbank einzurichten, wie es z.B.
die Firma IBM getan hat [7]. IBM hat ein
weltweites Intranet, in dem sehr viele Informationen stecken. Allerdings erschwert
die Größe des Intranets das Auffinden der
Informationen. Zur Lösung des Problems
hat IBM ein Wiki-System eingeführt welches den Einstieg mit einem Lexikoneintrag
und dazugehörigen Intranet-Links vereinfachen soll. Die Einträge erfolgen ohne
große Zugangseinschränkungen durch
die Mitarbeiter selbst, ganz im Stil des
Wikipedia-Projekts. Informationen lassen
sich dadurch ähnlich wie in einem Lexikon
mit vielen Querverweisen suchen. Da ein
Wiki-System ein leichtes und schnelles
editieren ermöglicht, können die IBMMitarbeiter selbst für die Aktualität der
Inhalte sorgen. Wenn die Information
nicht schon direkt im Wiki steckt, verweist
dieses weiter auf das Intranet.
Installieren ist nicht alles
Ein solches System muss angemessen
eingeführt werden.
„Unter Einführung wird die Summe
aller Aktivitäten verstanden, mit denen
erreicht wird, dass Informationssysteme
in einer Anwenderorganistation genutzt
werden“ [8, S.395-412]
Das Ziel eines Einführungsprozesses
ist die Nutzung des Systems. Engel et
al. nennt drei Aufgaben die bei der Ein-
S O F T WA R E E N T W I C K L U N G
führung erfüllt werden müssen, damit
dieses Ziel erreicht wird:
1. Installation und Anpassung des
technischen Systems
2. Qualifizierung zur Nutzung im
Arbeitsprozess einschließlich
Akzeptanzsicherung
3. Organisatorische Einbettung
Dabei blieb es im Softwareprojekt
bei der Erfüllung der ersten Aufgabe. Die
wichtigste dieser drei Aufgaben unter dem
Punkt 2 blieb bisher auf der Strecke. Den
Benutzern müssen durch Schulungs- und
Betreuungsmaßnahmen qualifikatorische
Voraussetzungen angeeignet werden.
Wird diese Aufgabe bei der Einführung
nicht erfüllt, ist die Folge eine fehlende
Akzeptanz. Jeder Aufwand für die Einarbeitung und Benutzung des neuen Systems wird gescheut. So bringt in unserem
Projekt die Ergänzung um das BSCW oder
alternativ eines Wiki-Systems, nicht den
gewünschten Erfolg. Als Besonderheit
im Softwareprojekt kommt hinzu, dass
das „Projekt-Personal“ jedes Semester
ausgewechselt wird. Für jedes Semester
sollte das System deshalb, besonders
auch unter Beachtung des oben genannten 2. Aufgabenpunktes, erneut eingeführt
werden.
Eine Tatsache, welche die Nutzung der
oben erwähnten Systeme behindert, ist
die Struktur des Hochschul-Netzwerkes,
welche aus Sicherheitsgründen nicht
ohne weiteres außerhalb der Hochschule
genutzt werden kann.
Die meisten Projektmitglieder arbeiten
überwiegend von zuhause aus, dadurch
entstehen zusätzliche Hürden die überwunden werden müssen. Die Systeme
werden auf Servern innerhalb des Hochschulnetzes installiert und können nicht
ohne zusätzlichen Aufwand von extern
erreicht werden. Die Lösung ist eine VPN
-Verbindung [9] mit dem Hochschulnetzwerk. Erst diese VPN-Verbindung
ermöglicht den Zugriff auf Serverdienste
innerhalb des Hochschulnetzwerkes. So
z.B. bei der Anmeldung an einem Versionskontrollserver. Die Einrichtung läuft
leider, bedingt unter anderem durch
Betriebssystem- und Netzwerkkonfigurationen, oft nicht reibungslos. Speziell in
der Iteration der ich angehöre habe ich
folgende Erfahrungen gemacht.
Anfangs galt es den Zugriff auf ein
SVN-Repository [10] einzurichten. Dort
befanden sich der Programmcode und
die Entwicklungsumgebung. Schon kurze
Zeit später ist die SVN-Versionsverwaltung im Projekt aber obsolet. Die open
source Software SVN wird durch Rational
ClearCase ersetzt. Die Einrichtung eines
ClearCase-Clients wird nötig. Aber auch
damit ist es nicht getan. Bald wird ein
neuer ClearCase-Server aufgesetzt. Und
das erfordert ein erneutes Einrichten des
ClearCase-Clients. Dazu lief die Einrichtung
des ClearCase-Clients in beiden Fällen
leider nicht reibungslos und war äußerst
zeitraubend.
Zusammenfassend muss man sagen,
dass der Zeitaufwand für organisatorische
Belange im Softwareprojekt sehr groß
ist. Einer der Gründe ist, dass sich jede
Iteration von neuem mit den Werkzeugen
vertraut machen muss. Die Menge der Dokumente in welchen nützliche Informationen stehen, die auf der Erfahrung vorangegangener Iterationen basieren, ist relativ
klein und schwer auffindbar. Mit jedem
Iterationswechsel geht Wissen verloren.
Meiner Meinung nach ist es deshalb sehr
wichtig ein gutes und flexibles Konzept für
die Wissenserhaltung, die Unterstützung
der Kommunikation, der Kooperation und
der Koordination innerhalb des Projekts zu
entwickeln. Es gibt viel zu tun!
Michael Garcorz, Softwareentwicklung
Quellen
[1] Arbeitsmittel sind Dokumente und Werkzeuge, welche gemeinsam genutzt oder bearbeitet werden können.
[2] RUP ist ein Vorgehensmodell in der Softwareentwicklung
[3] Team der Softwareentwickler
[4] Computer Supported Cooperative Work ist ein Forschungsgebiet, dass sich mit Informations- und Kommunikationstechnologien befasst, welche Gruppenarbeit unterstützen.
[5] Unland R., Datenbankunterstützung für CSCW-Anwendungen in: Schwabe et al.: CSCW-Kompendium Berlin,
Heidelberg 2001
[6] Die Menge aller Dateien der Projekte die durch ein Versionskontrollsystem verwaltet werden und deren
Informationen zur Versionierung.
[7] http://www.computerzeitung.de/loader?path=/articles/2008007/31395755_ha_CZ.html&art=/articles/2008007/31395755_ha_CZ.html&thes=8012,9867,9868,9869&pid=ee54f3c7-0de1-40f5-bb23-2cfdf022aee5 (Stand: 28.05.08)
[8] Engel A. et al. Einführung und Betrieb in: Schwabe et al.: CSCW-Kompendium Berlin, Heidelberg 2001
[9] Virtual Private Network ist eine Verbindungstechnologie , welche die Verbindung zwischen zwei unterschiedlichen Netzwerken ermöglicht
[10] Subversion wird häufig auch als SVN abgekürzt
SOP JOURNAL R4
45
S O F T WA R E E N T W I C K L U N G
RATIONAL ROSE
Sinn und Unsinn eines UML-Werkzeugs
Rational Rose dient im Projekt
als Werkzeug zur Erzeugung von UMLDiagrammen. Diese beschreiben das
Softwaresystem und dienen als Basis zur
Codegenerierung. Welche Erfahrungen hat
das Softwareentwicklungsteam mit Rational Rose gemacht? Welche Hindernisse und
Probleme beschert dieses Werkzeug?
Insgesamt zeigte sich Rational Rose
wenig benutzerfreundlich. Eine intuitive Bedienung ist nur teilweise möglich,
so dass eine nicht unwesentliche Einarbeitungszeit vonnöten war. Es gibt viele
kleine Fallen, die die Benutzung erheblich
erschweren. Auf einige besonders hervorstechende Beispiele wird nun detaillierter eingegangen werden.
Rational Rose bietet diverse Sichten
auf das Softwaremodell. Die „Browser“
getaufte Ordneransicht ähnelt dem
Windows Explorer. Im Gegensatz zum
üblichen Verhalten bei Exploreransichten
öffnet ein Doppelklick auf einen Ordner
dessen Eigenschaftsfenster, nicht den Ordner selbst. Dies ist an sich nur ein kleiner
Umstand, der sich jedoch insbesondere
in der Einarbeitungsphase als ärgerlich
herauskristallisierte, da man intuitiv ein anderes Verhalten erwartet. Jedes Mitglied
des Softwareentwicklungsteams hat somit
anfangs mehr als einmal ungewollt das
Eigenschaftsfenster zu sehen bekommen.
46
SOP JOURNAL R4
Ist dies noch ein Umstand, der sich
nach einer Eingewöhnungsphase schnell
legte, ist der nächste Punkt schon deutlich
ärgerlicher: Die vielfältigen Funktionen von
Rational Rose werden dem User durch
eine Reihe von Fenstern zugänglich
gemacht, die über Kontextmenüs zu
erreichen und teils ineinander verschachtelt sind. Zum Beispiel sind folgende
Schritte notwendig, um einer Klasse eine
neue Funktion samt Argumenten und
Ausgabeparameter hinzuzufügen: Rechtsklick auf die Klasse im UML-Diagramm
zum Aufruf des Kontextmenüs > „Open
Standard Specification“ > (Fenster mit 9
Reitern erscheint) > Auswahl des Reiters
„Operations“ > Rechtsklick in Tabellenansicht der Funktionen > Kontextmenü >
„Insert“ > Name für die Funktion eingeben
> Rechtsklick auf neu angelegte Funktion >
Kontextmenü > „Specification“ > (Fenster
mit 8 Reitern erscheint) > Eingabe des
Ausgabeparameters im Reiter „General“,
Eingabe der Argumente im Reiter „Detail“.
Das Eingeben einer Klasse mit vielen
Funktionen wird so zu einer längeren Angelegenheit.
Glücklicherweise zwingt Rational Rose
den Benutzer nicht, diesen umständlichen
Weg zu gehen; er ist aber der einzige
Weg, über den eine Methode auch garantiert richtig angelegt wird. Der zweite,
deutlich einfachere Weg ist die direkte
Eingabe der Methode ins UML-Diagramm.
Hierbei muss aber sehr konzentriert gearbeitet werden, da Rational Rose bei der
Eingabe keinerlei Fehlererkennung bietet
– auch syntaktischer Blödsinn wird anstandslos akzeptiert, führt bei der später
erfolgenden Codegenerierung aber zu
wenig hilfreichen Fehlermeldungen, die
eine langwierige Fehlersuche notwendig
machen.
Die Funktion, die uns bei der Arbeit
die meisten Nerven gekostet hat, war aber
die „Zurück“-Funktion. Diese ist bei Rational Rose die meiste Zeit ohne ersichtlichen
Grund deaktiviert. Wie häufig man diese
Funktion nutzt, fällt erst auf, wenn sie nicht
mehr zur Verfügung steht. Bei der Arbeit
mit Rational Rose muss daher konzentriert
gearbeitet werden. Fehler von Hand rückgängig zu machen ist äußerst heikel, da
man nicht immer weiß, welche versteckten Auswirkungen eine Aktion hat, also ungewollte Artefakte irrtümlich ausgeführter
Aktionen zurückbleiben können.
Auch beim Verwenden von „Copy &
Paste“ ist Vorsicht geboten. Kopiert man
beispielsweise mehrere Klassen, gehen
schnell die Beziehungen zwischen diesen
Klassen verloren, bzw. werden nicht mit
kopiert. Es muss genau darauf geachtet
werden, alle Beziehungen mit zu ko-
S O F T WA R E E N T W I C K L U N G
Abbildung 1: Kein Weg zurück: Rational Rose
pieren. Hier fällt das inkonsequente Design der Anwendung auf: Das Kopieren
von Klassen ist nur aus einem Diagramm
heraus möglich, nicht aber aus der Exploreransicht. Existiert also von einem
Element, das kopiert werden soll, keine
Instanz in einem Diagramm, muss es erst
in ein Diagramm gelegt werden, um das
Kopieren zu ermöglichen.
All diese Punkte werfen kein allzu
positives Licht auf Rational Rose. Den negativen Eindruck verstärkt die antiquierte
Oberfläche - die Benutzeroberfläche des
Programms erinnert an eine Windows 95
Anwendung, die Dialogfelder sind teils
ungewohnt aufgebaut. Dies hat zwar keine
direkte Aussagekraft über die Qualität
des Programms, aber es erweckt schon
beim ersten Start das Gefühl, mit einem
veralteten Programm zu arbeiten. Die
umständliche und wenig benutzerfreundliche Bedienung verstärkt den negativen
Eindruck aber rasch.
Und wir stehen mit unseren Erfahrungen nicht alleine da: In einer von Rose
Shumba durchgeführten Umfrage wurde
Rational Rose im Hinblick auf Bedienbarkeit
und Benutzerfreundlichkeit klar schlechter
bewertet als das Vergleichsprodukt Microsoft Visio. Unter anderem heißt es zur
Diagrammerstellung: „In Rose wird eine
Menge Auskundschaften, Raten und Glück
benötigt, um einige der Diagramme zu
erstellen“. Auch wurde das Programm als
„mühsam und schwierig zu bedienen“ beschrieben . Ähnliche Probleme schildern
Aydaen Lynch et al.: „Die Mehrheit der
Studenten fanden einige der Funktionen
schwer zu benutzen, andere waren nicht
leicht verfügbar“ .
Was sind die Vorteile bei der Arbeit
mit Rational Rose?
Rational Rose ermöglicht die Erzeugung der kompletten Coderümpfe. Diese
enthalten schon alle im Modell angelegten
Beziehungen, so dass die Entwickler nur
noch die Funktionen selbst implementieren müssen. Dies spart viel Zeit und stellt
obendrein sicher, dass der Code dem
im MDA -Ansatz festgelegten Konzept
entspricht. Rational Rose beherrscht die
Codegenerierung in einer Reihe von
Sprachen, darunter Ada 83, Visual Basic,
C++ und Java. Die Java-Entwicklung pro-
SOP JOURNAL R4
47
S O F T WA R E E N T W I C K L U N G
Gewichte und Probleme stemmen. [Film]
fitiert somit deutlich von der Arbeit mit
Rational Rose.
Andererseits:
Die zweite im Projekt verwendete
Sprache, C#, wird nicht unterstützt. Somit
muss, um auch in C# MDA-konformen
Code zu erhalten, die im Rosemodell
festgelegte Spezifikation von Hand in C#
umgesetzt werden. Zwar vereinfacht die
syntaktische Ähnlichkeit von C# und Java
hier einiges, aber dieses Vorgehen ist
unnötig umständlich. Ein Werkzeug, das
beide Sprachen unterstützt, wäre deutlich hilfreicher. Auch bietet Rose keinerlei
Hilfestellungen, die sich direkt auf MDA
beziehen. Es wäre z.B. eine Funktion denkbar, die aus einem PIM automatisch ein
PSM in verschiedenen Sprachen erstellt,
das dann von den Entwicklern weiter
bearbeitet werden kann. Bei Rational Rose
muss dieser Schritt manuell vorgenommen
48
SOP JOURNAL R4
werden.
Es kann somit die Frage gestellt werden: Inwieweit ist es sinnvoll, Rational
Rose im Projekt zu verwenden? Die genannten Nachteile sollen hier nicht den
Blick auf das Wesentliche versperren - ein
Werkzeug zur Verwaltung und Bearbeitung
der MDA-konformen UML Diagramme ist
vital. Die Möglichkeit, aus den Diagrammen Code zu erzeugen, ist sehr hilfreich
– auch wenn es nur bei Java funktioniert.
An dieser Stelle kann und muss jedoch
die Frage gestellt werden, wieso nicht vor
Erwerb der Lizenzen für die Rational Tools
überprüft wurde, ob beide im Projekt verwendeten Sprachen unterstützt werden.
IBM bietet mit dem Rational Systems Developer ein Werkzeug an, dass dieselben
Funktionen wie Rational Rose bietet, und
Java und C# unterstützt.
Rose bringt für die Entwicklung in
Java aufgrund der vollen Unterstützung
einigen Nutzen. Auf C# Seite ist wie erwähnt einiges an Handarbeit nötig. Hier
ist die mangelnde Fehlerkontrolle des
Programms sogar von einem gewissen
Nutzen. Da Rose keine Unterstützung für
C# bietet, wurde das C#-PSM in Rose als
Java Modell aufgebaut. Da die Eingaben
nicht auf Übereinstimmung mit den Java
Konventionen überprüft werden (z.B.
werden in C# Package-Namen groß geschrieben, in Java jedoch klein), konnte
es entsprechend den C# Konventionen
aufgesetzt werden.
Die wenig komfortable Bedienung
ist ärgerlich, aber mit entsprechender
Einarbeitung zu meistern. Das antiquierte
Äußere hat ohnehin keinen Einfluss auf
Wert und Nutzen des Programms.
Es sollte allerdings in Betracht gezogen werden, nach Ablauf der Lizenzen
auf ein anderes Tool umzusatteln, das
beide Sprachen unterstützt (z.B. den
erwähnten Rational Systems Developer).
Solange aber die Lizenzen vorhanden
sind, stellt die Weiterarbeit mit Rational
Rose wohl das kleinere Übel dar. Trotz
aller Widrigkeiten kann man mit Rose arbeiten, die Probleme bei der Bedienung
sind Gewöhnungssache. Und die Handarbeit auf C#-Seite kann man auch als gute
Übung auffassen.
Tobias Thieme, Softwareentwicklung
Quellen
[1] Versionisierungssoftware
[2] zu Deutsch: Lager oder Depot; Es werden hier Dateien (in diesem Fall Quellcode) abgelegt
S O F T WA R E E N T W I C K L U N G
LEBT DER KUNDE IN EINER TRAUMWELT?
Kundenanforderungen an die Hardware des Langzeitarchivierungssystems
In der gegenwärtigen Konsumgesellschaft werben viele Firmen mit
der Aussage: „Kunde ist König“.
Auch das Softwareprojekt lebt unter
diesem Motto. Aber in wie weit kann
man diese Zusicherung vertreten.
Kann man dem Kunden wirklich die
freie Hand bei der Gestaltung der
Anforderungen lassen? Und wie hoch
ist dabei das Risiko lediglich eine unscharfe Traumbeschreibung, der zu erbringenden Leistungen, zu erhalten?
Ist es realistisch, an dem Auftreten
des Geschäftspartners abzuwägen,
ob dieser in einer Traumwelt lebt oder
wirklich konkrete Vorstellungen über
das Produkt mitbringt?
Auch in der fünften Iteration des Softwareprojektes stellen zwanzig Studenten
unter Beweis, dass sie teamfähig und engagiert einen Softwareentwicklungsprozess planen und umsetzen können. Ebenso
wie in den letzten Iterationen, wurden
auch diesmal Grundaufgaben festgelegt.
Dazu zählen zum Beispiel die Umsetzung
des MDA [1] - Konzeptes und das Bearbeiten der Change-Requests zählen.
Eine besondere Herausforderung lag
in der Recherche nach einer geeigneten
Hardware zum Betrieb des Langzeit-
archivierungssystems. Da die Beschaffung
der Komponente von der Kundenseite
übernommen werden sollte, musste auch
die Recherche in enger Kooparation mit
diesem durchgeführt werden. Bereits
beim Studium der, von der Vorgängeriteration erstellten, Anforderungen konnten
einige Widersprüche ausfindig gemacht
werden. Hierzu zählte unter anderem die
technische Ausstattung der Zielklientel.
Laut den Anforderungen sollten beispielsweise die zukünftigen Kunden der trésor
GmbH keine eigene Serverinfrastruktur besitzen. Trotz der Abwesenheit der Datenserver sollte jedoch eine Archivierung von
Videorohdaten ermöglicht werden. Stellt
man diese zwei Anforderungen gegeneinander wird man bereits bei der oberflächlichen Analyse feststellen, dass diese
sich widersprechen. Der Hauptwiderspruch resultiert daraus das Videorohdaten auch bei kurzen Filmesequenzen
sehr groß werden können. Diese Tatsache
würde früher oder später den Einsatz eines
lokalen Datenservers erfordern. Der Grund
hierfür liegt darin das der Speicherplatz
auf einem Arbeitsplatzrechner, in Hinsicht
auf solche Datenmengen, sehr beschränkt
ist. Aber nicht nur die Datenmengen
schließen die Abwesenheit einer Serverstruktur aus. Des Weiteren besteht das
Risiko, dass das Langzeitarchivierungssystem als ein Serverersatz missbraucht wird.
Diese Gefahr wächst mit der Anzahl des
Personals, einer Kundenfirma, die eine
Zugriffsberechtigung erhalten.
Die genannten Beispiele zeigen bereits jetzt die Problematik, mit der die
Auftragnehmer immer wieder konfrontiert
werden. Zum einen soll der Kunde das Gefühl haben das seine Wünsche anstandslos umgesetzt werden und zum anderen
sollte er ja das optimale Ergebnis erhalten.
Würde man nun im Falle des Softwareprojektes die Kundenwünsche so erfüllen, wie
sie auch gestellt worden sind, dann wäre
der Kunde zunächst befriedigt. Die Folge
wäre jedoch das er unter Umständen ein
Hardware Paket erworben hätte, das sich
entweder wirtschaftlich nicht rentiert oder
jedoch so unflexibel wäre, dass ein Wachstum der Firma gefährdet werden könnte.
Würde man hingegen eine optimale Hardware liefern wollen so müsste der Kunde
sein Geschäftsmodell von Grund auf überdenken und anpassen. Dies widerspricht
aber dem Grundsatz „Kunde ist König“
vollkommen. Aber woher kommen die
genannten Probleme? Ist der Kunde nicht
in der Lage seine Wünsche präzise auszudrücken? Oder ist es eher so, dass der
Auftragnehmer derart unflexibel ist, dass
SOP JOURNAL R4
49
S O F T WA R E E N T W I C K L U N G
er sich nicht auf unterschiedliche Kundenwünsche einstellen kann? Die Frage kann,
wie so oft, nicht pauschal beantwortet
werden. In der aktuellen Iteration wurden
erhebliche Mängel in den Anforderungen
aufgedeckt. Diese konnten jedoch in
Kooperation mit dem Kunden beseitigt
werden. Im Anschluss wurde eine Hardwarerecherche durchgeführt und eine
Empfehlung zum Kauf eines Hardwarepakets erstellt.
Um zukünftig die Anforderungen
schneller und effizienter bearbeiten zu
können empfiehlt es sich einige grundlegende Regeln zu beachten:
- Seitens des Kunden wäre es z.B. sinnvoll, bereits bei der Konzeption des Geschäftsmodells [2] einen Experten hinzu
zu ziehen. Diese Maßnahme würde zur
Abschalten ist nicht . . .
. . . das SOP ist überall DAS Thema. [Film]
Folge haben, dass das Geschäftsmodell
bereits im Vorfeld keine Widersprüche
aufweist und somit eine gute Grundlage
für die weitere Bearbeitung bietet.
- Die Anforderungen sollten hinsichtlich
der entstehenden Kosten realistisch überprüft werden.
- Allgemein sollten sämtliche Zahlenangaben auf ihre Plausibilität überprüft werden.
Hierzu ein Beispiel:
Ein neugegründetes Unternehmen
spezialisiert sich auf die Archivierung von
Rohdaten. Hierzu wird festgelegt, dass die
Anzahl der Zugriffsberechtigten Personen
maximal drei Angestellte pro Kundenunternehmen betragen darf. Gibt man dann
jedoch die Anzahl der gleichzeitigen
50
SOP JOURNAL R4
S O F T WA R E E N T W I C K L U N G
Zugriffe auf das Archivierungssystem
mit 3000 an kann man sofort erkennen,
dass solche Dimensionen für ein neues
Unternehmen unrealistisch sind. Unrealistisch deshalb weil 3000 Gleichzeitige
Nutzer bedeuten würde, dass bereits
mindestens 1000 Kunden existieren oder
in einer relativ kurzen Zeit angeworben
werden müssen.
Es sollte jedoch beachtet werden,
dass diese Regeln lediglich auf meinen
persönlichen Erfahrungen basieren.
Trotz präzise formulierten Anforderungen kann es dennoch zu Schwierigkeiten
bei der Erfassung kommen. Nämlich dann
wenn die beteiligten Parteien zwar dieselben Begriffe verwenden jedoch nicht
dasselbe meinen. Um solchen Problemen
aus dem Weg zu gehen empfehlen Experten schon sehr früh ein gemeinsames
Glossar zu erstellen (vgl. [5]). Dass dies
nicht immer beachtet wird zeigte sich
auch während den Vorgesprächen zur
Hardwarerecherche. Dort Diskutierten
zwei Parteien darüber wie das Geschäftsmodell des Kunden zu interpretieren ist.
Die Kundenfraktion, bestehend aus zwei
Kundenvertretern und dem Geschäftsführer, beharrte darauf, das Geschäftsmodell
so aufzubauen, dass die zukünftigen Nutzer des Langzeitarchivierungssystems nicht
über eigene Datenserver verfügen sollten.
Dementsprechend sollte der Zugriff auf
Einzeldateien jeder Zeit möglich sein.
Die Gegenseite, bestehend aus zwei Softwareentwicklern, einem Geschäftsführer
und einem Hardwareexperten, versuchte
diesen Ansatz zu Aufzugreifen und ihn
mit dem Langzeitarchivierungssystems
zu vereinbaren. Dieser Versuch gelang
nur schwer da immer wieder Probleme
auftraten. Die meisten beruhten, wie es
sich später herausstellte, darauf das ein
gemeinsames Glossar fehlte. Uneinigkeit
herrschte beispielsweise in der Definition
des Begriffs Langzeitarchivierungssystem:
Die Auftragnehmer favorisierten die klassische Archivansicht – abgeschlossene
Daten verwalten und im besten Fall nie
wieder antasten; die Kunden bevorzugten das Prinzip eines Datenhoster‘s,
wo die Daten modifiziert und in kleineren
Mengen heruntergeladen werden können. Bekräftigt wurde diese Vorstellung
durch den Wunsch auch Rohdaten zur
Archivierung zuzulassen. Das Problem
in diesem Fall besteht darin, dass Rohdaten einen sehr viel größeren Platzbedarf
haben als fertig formatierte Daten. Nimmt
man beispielsweise einen fertigen Videofilm mit einer Spielzeit von 90 min und
einer DVD-Qualität so ergibt sich ein Platzbedarf von ca. 4.7 Gigabyte. Würde man
jedoch die gesamten Rohdaten des Filmes
archiveren dann würde man es mit schätzungsweise 10 - 15 Stunden Filmmaterial
in Rohqualität zu tun haben. Diese Daten
schlagen mit einem Platzbedarf von bis zu
1000 Gigabyte, je nach Format, zu Buche
und verlangen andere Techniken um diese
zu archivieren. Um trotzdem auch diesen
Marktbereich abzudecken, wurde dem
Kunden vorgeschlagen zwei separate Geschäftsmodelle zu entwickeln. Ein solches
Marketingmodell würde die Bedürfnisse
beider Zielgruppen abdecken und man
könnte sich sehr gut auf dem Markt positionieren. Dieser Vorschlag wurde jedoch
abgelehnt.
Die genannten Fehlinterpretationen
führten dazu dass Zeit und somit unnötig
Geld verschwendet wurde. Glücklicherweise konnte diese Missstände schnell erkannt und beseitigt und somit eine erfolgreiche Hardwarerecherche gewährleistet
werden.
Alexander Paharukov
Softwareentwicklung
Quellen
[1] MDA: Die Model Driven Architecture (deutsch: Modelgetriebene Architektur) ist ein Verfahren um die
Softwarearchitektur präskriptiv auf mehreren Ebenen in Modellen zu beschreiben. Dabei findet schrittweise eine
zunehmende Verfeinerung und Detaillierung der höheren abstrakten Ebenen bis hin zum Programmcode statt. [3]
auch [4]
[2] Geschäftsmodell: “Ein Geschäftsmodell ist eine modellhafte Beschreibung eines Geschäftes. Ein Geschäftsmodell besteht aus drei Hauptkomponenten: Value Proposition, Architektur der Wertschöpfung und dem
Ertragsmodell.“ (Stähler, 2001)
[3] Alan Brown IBM. (2004, Februar 14). An introduction to Model Driven Architecture. Retrieved Mai 28, 2008,
from Developer Works: http://www.ibm.com/developerworks/rational/library/3100.html
[4] Fraunhofer IESE. (2001-2008). Einführung in MDA. Retrieved Mai 28, 2008, from Virtuelles Software Engineering
Kompetenzzentrum: http://www.software-kompetenz.de/?5348
[5] IBM. (1987-2006). Aufgabendeskriptor: Gemeinsames Vokabular erfassen. Retrieved April 24, 2008, from RUP
for small Projects: SmallProjects/rup/capabilitypatterns/capture_common_vocabulary,_8_pYkEogEdqrjq4i3fchvA.
html?proc=_vCtak0JHEdq4z9xc-r201w&path=_vCtak0JHEdq4z9xc-r201w,_vChNR0JHEdq4z9xc-r201w,_vCtaiEJHEdq4z9xc-r201w,_rnmKIJ4_Edq7s5zuJVEAAw,_8_pYkEogEdqrjq4i3fchvA
[6] Stähler, P. (2001). Geschäftsmodelle in der digitalen Ökonomie: Merkmale, Strategien und Auswirkungen. KölnLohmar: Josef Eul Verlag.
SOP JOURNAL R4
51
S O F T WA R E E N T W I C K L U N G
HILFE ICH BIN EIN SOFTWAREENTWICKLER HOLT MICH HIER RAUS!
Im Studiengang Medien- und Kommunikationsinformatik an der Hochschule Reutlingen sind 160 Studenten
immatrikuliert. Da der Schwerpunkt
dieses Studiengangs auf der Informatik liegt, sollte man annehmen, dass
jeder dieser Studenten prädestiniert
für die Rolle des Software-Entwicklers
im Software-Projekt ist. Diese Annahme ist auch naheliegend, weil die
meisten Anforderungen an die Software-Entwickler den Vorlesungsinhalten entsprechen. Wie beliebt ist
jedoch tatsächlich die Rolle des Software-Entwicklers bei den Studenten?
Und was denken die Professoren bzw.
die Geschäftsführung über die Software-Entwickler im Software-Projekt?
Diese und weitere Fragen werden im
folgenden Artikel durch Umfragen
und Interviews mit betroffenen Personen beantwortet.
Als zu Beginn des Wintersemesters
2007 die Studenten der Iteration 5 sich
ihre Rollen untereinander aufteilen sollten,
zeichnete sich ein unerwarteter Trend
ab: Gegen die Annahme, dass die Rolle
des Software-Entwicklers gefragt ist, gab
es Schwierigkeiten alle Positionen zu
besetzen. Dies löste eine Diskussion aus,
worauf sich betroffene Studenten wie
52
SOP JOURNAL R4
Diagramm 1: Ergebnis der Umfrage
folgt äußerten: „Ich habe mit Programmierung nichts am Hut!“, „Das ist mir viel
zu technisch.“ oder „…zu viel programmieren, ich kann das einfach nicht.“ (Kommentare von MKI-Studenten).
Projektleitung und Geschäftsführung
stellen sich bei solchen Äußerungen die
Frage: Ist die Rolle des Software-Entwicklers nicht so populär wie angenommen?
Um eine Antwort zu finden, wurde eine
Umfrage durchgeführt. Jeder Student des
Studiengangs MKI hatte die Möglichkeit,
sich über die Rolle des Software-Entwicklers zu äußern. Das Ergebnis der Umfrage
bestätigt den Negativtrend. An dieser Umfrage [1] beteiligten sich 73 Studenten.
Abbildung 1 zeigt, dass 52% der
befragten Studenten sich nicht in der
Rolle des Software-Entwicklers sehen
könnten. Auf die Frage: „Warum würden
sie sich nicht für die Rolle des SoftwareEntwicklers entscheiden?“, wurden unter
anderem folgende Aussagen getroffen:
„Weil ich mich mit etwas befassen will,
was mir Spaß macht und von dem ich
mir vorstellen kann, es auch weiterhin zu
machen. Da ich mein Praktikum im Managementbereich gemacht habe, würde ich
lieber was mit Marketing machen.“, „weil
meine Fähigkeiten in anderen Bereichen
deutlich besser sind und dort auch meine
Interessen liegen.“ und „Ich kann nicht
programmieren und traue mir diese Aufgabe nicht zu.“ (Antworten von Studenten
aus der Umfrage). Dieses Ergebnis zeigt,
dass bei vielen Studenten die Interessen
S O F T WA R E E N T W I C K L U N G
Interview mit Prof. Dr. rer. nat. Uwe Kloos, Geschäftsführung
Denken Sie, dass die Rolle des Software-Entwicklers eine beliebte Rolle im
Software Projekt ist?
„Ich denke zu Beginn auf jeden Fall. Die Studenten die neu in das Projekt kommen,
können sich unter dieser Rolle am meisten vorstellen. Vor allem Studenten die eine Affinität zum Programmieren entwickelt haben, sehen sich gerne in der Rolle des Entwicklers.
Anschließend, im Laufe der zwei Semester, kann es sich bei dem einen oder anderen
ändern, weil er vielleicht merkt, dass Software-Entwicklung nicht nur reines programmieren ist. Diese Erkenntnis kann einige Studenten frustrieren, obwohl andere wichtige
Aufgaben umgesetzt wurden. Denn auf den ersten Blick scheinen diese Aufgaben nicht
Teil der Rolle des Software-Entwicklers zu sein.“
Welche Erwartungen stellen zukünftige Software-Entwickler an das
Softwarprojekt?
„Ich könnte mir vorstellen, dass die Erwartung darin besteht Software zu entwickeln
und zu programmieren. Vor allem aber das Produkt vom Kern aus anzutreiben indem
man neue Methoden und Module für das Projekt entwickelt.“
Geschäftsleiter Prof. Kloos
überdenkt die Strategie. [Film]
Glauben Sie, dass diese Erwartungen erfüllt werden?
„Zum Teil ja, zum Teil nein. Es tauchen immer wieder unerwartete Elemente auf, wie
z.B. der MDA-Ansatz an welchem seit über 2 Semestern modelliert wird. Dieser Ansatz
wurde mit Sicherheit von keinem in dieser Form erwartet. Er führt bei den Studenten
zu Überraschung bis hinzu Frustration, weil man eben nicht zum Entwickeln gekommen ist, sondern man sich mit anderen Dingen beschäftigen muss bevor man wieder
weiterkommt. Die Erwartungen werden sicherlich nach Beendigung des MDA-Ansatzes
erfüllt, wenn wieder implementiert wird.“
Welche Erfahrungen haben Sie mit dem Softwareentwicklungsteam im SoftwareProjekt gemacht?
„Viele Studenten sind zu Beginn sehr motiviert und wollen gleich anfangen zu entwickeln, werden aber enttäuscht weil am Anfang andere Aufgaben im Vordergrund stehen. Der andere Punkt ist, dass jede Iteration unterschiedliche Vorlieben hat, in welcher
Programmiersprache entwickelt werden soll. Es ist schwierig eine Kontinuität in das
Projekt zu bringen, da das eine Semester lieber die „Microsoft-Schiene“, das nächste
Semester lieber die „Open-Source-Schiene“ fahren will. Das erfordert auch einiges an
Diskussion, damit beide Projekte gleich vorangetrieben werden.“
SOP JOURNAL R4
53
S O F T WA R E E N T W I C K L U N G
in anderen Bereichen liegen und dass sich
der eine oder andere mit der Rolle als
Software-Entwickler überfordert fühlt.
Die Qualitätssicherung führte in der Iteration 5 eine Mitarbeiterbefragung durch.
Bei dieser Befragung hatten die Mitarbeiter
des Software-Entwicklungsteam die Gelegenheit sich über ihre Rolle zu äußern.
Das Ergebnis war, dass zwei von acht
Software-Entwicklern sich für eine andere
Rolle entscheiden würden, wenn sie
könnten. Ein Rollenwechsel ist möglich,
jedoch müssen Gründe der Geschäftsund Projektleitung genannt werden, um
diesen zu ermöglichen. Bei der Bewertung der Rolle gaben nur zwei Entwickler
die Note „gut“. Der Rest bewertete seinen
Arbeitsbereich mit „befriedigend“ bis
„ausreichend“. Dies zeigt, dass selbst das
existierende Entwicklungs-Team nicht geschlossen hinter der Rolle steht.
Aus der Sicht der Studenten wurden
bereits mehrere Gründe genannt, warum
die Rolle wenig Akzeptanz findet. Desweiteren soll gezeigt werden, wie die Geschäftsleitung (Professoren) über die Rolle
des Software-Entwicklers denkt. Auf eine
der Folien von Herrn Professor Keller, ist
der Satz „Der Manager ist nicht informiert.“
[3] zu lesen. Dieser besagt, dass das Management, nicht über den Arbeitsfortschritt
und die interne Arbeitsweise Bescheid
weiß. Dies gibt Anlass bei der Geschäftsleitung nachzufragen, in wie weit sie
ihr Software-Entwicklungsteam kennen.
Zusätzlich soll in Erfahrung gebracht werden, ob sie annehmen, dass die Erwartungen der Studenten an die Rolle erfüllt
werden. Dazu wurde ein Interview mit
54
SOP JOURNAL R4
Herrn Professor Kloos durchgeführt.
Aus diesem Interview geht hervor,
dass Herr Professor Kloos dieselbe Meinung wie die meisten Studenten vertritt.
Die Motivation viel zu programmieren
überwiegt am Anfang des Projekts, weil
die Studierenden noch nicht wissen, dass
andere Aufgaben berücksichtigt werden
müssen. Ebenso zeigen zukünftige Entwickler viel Engagement das Projekt voran
zu treiben. Dass das Programmieren erst
zu einem späteren Zeitpunkt erfolgen
kann oder sogar entfällt, ist vielen nicht
bekannt. In den ersten Phasen des Projekts
sind die Hauptaufgaben Planung und
Modellierung der Software. Dies führt unter Umständen zu Frustration bei einigen
Entwicklern, weil viele Studenten Planung
und Modellierung nicht mit SoftwareEntwicklung in Verbindung setzen. Dieser
Aspekt könnte für andere wiederum der
Grund sein, sich für diese Rolle zu entscheiden. Schließlich gaben Studenten bei
der Online-Befragung an: „Erfahrung sammeln in der Software-Modellierung.“ und
„Tiefer in die Modellierung der Software
zu tauchen.“
Doch was ist Software-Entwicklung
eigentlich? Software-Entwicklung umfasst alle Ressourcen und Tätigkeiten,
die zur Herstellung und Entwicklung von
Software notwendig sind. Prof. Dr. Martin
Glinz, Professor an der Universität Zürich,
beschreibt die Software-Entwicklung wie
folgt: „Die Umsetzung der Bedürfnisse
von Benutzern in Software umfasst: Spezifikation der Anforderungen, Konzept
der Lösung, Entwurf und Programmierung
der Komponenten, Zusammensetzung
der Komponenten und ihre Einbindung
in vorhandene Software, Inbetriebnahme
der Software sowie Überprüfung des Entwickelten nach jedem Schritt.“ [2]
Software-Entwicklung ist also mehr als
nur „reines Programmieren“. Würde diese
Erkenntnis in den unteren Semestern mitgeteilt werden, dass oft in der Rolle des
Software-Entwicklers nicht das Programmieren im Vordergrund steht, könnten
sich eventuell mehr Studenten diese Rolle
vorstellen. Diese Behauptung wird dadurch bestärkt, dass einige der Befragten
sich nicht mit der Rolle identifizieren können, weil sie annehmen es drehe sich alles
um das Programmieren. Die meisten Studenten haben ein falsches Bild haben von
der Rolle des Software-Entwicklers. Um
dieses aus dem Weg zu räumen wäre es
sinnvoll, die Rollen im Einzelnen und das
gesamte Software-Projekt in den unteren
Semestern ausführlich darzustellen. Ziel ist
es, die Studierenden nicht von der Rolle
abzuschrecken, sondern sie zu ermutigen
diese Rolle anzunehmen. Der Leitsatz:
„Hilfe ich bin ein Software-Entwickler
– Holt mich hier raus!“ sollte nicht zum
Motto werden.
Thomas Sellner, Softwareentwicklung
Quellen
[1] Online-Umfrage: Rolle Software-Entwickler im Software-Projekt
[2] Glinz M.: Software Engineering. [Online Dokument] URL:
http://www.ifi.unizh.ch/req/courses/se/, WS 2005/2006, letzter Zugriff: 18.05.2008.
[3] Was will Softwaremanagement, Folie 4, Vorlesung Softwaretechnik 2, W. Keller
TESTING
UNTERSCHÄTZ MEIN NICHT
Irrtum und Ignoranz beim Testen
Ende 2004 wurde die Überweisung
des neuen Arbeitslosengeld II gefährdet. Schuld daran war ein Fehler in der
Überweisungssoftware. So wurden die
eingetragenen Kontonummern der
Empfänger, die aus weniger als zehn
Zeichen bestanden, von hinten mit
Nullen aufgefüllt und nicht, wie erforderlich von vorne.[1]
Wäre es möglich gewesen, diesen
Fehler schon vorher zu bemerken?
Wurde hier die Überweisungssoftware
nicht ausreichend überprüft? Wurde es
unterschätzt, wie wichtig gerade hier das
ordnungsgemäße Prüfen dieser Sache ist?
Um das Thema „Test“ ranken sich zum
Teil falsche Vorstellungen. Die Auffassung,
es sei ausreichend, das Programm zufällig
auf seine Funktionen „durchzuklicken“, ist
gerne vertreten. Auch wird oft die Wichtigkeit dieser Tätigkeit unterschätzt. Doch
nicht ausreichend getestete Systeme können viel Geld kosten, wenn sich später bei
deren Einsatz ein Fehler zeigt, den man
hätte finden müssen. Gut wird dies durch
das obige Beispiel aus dem Jahr 2004
veranschaulicht.
Im Folgenden wird untersucht, welche
Bedeutung Testing für das Softwareprojekt
der Hochschule Reutlingen (kurz: SOP)
haben könnte und warum der Irrtum auch
vor dem Tester selbst nicht halt macht.
Testing im SOP
Im SOP sind die schlimmsten Folgen
nicht die Gefährdung von Menschenleben.
Doch überträgt man dieses Projektplanspiel auf die Praxis, so erkennt man, dass
es hier zumindest zu hohen finanziellen
Schäden kommen kann. Man stelle sich
folgendes Szenario vor:
Der Anbieter will das Produkt als Ganzes verkaufen: Software + Hardware. Die
erbrachte Leistung wird pro übertragenes
Gigabyte berechnet.
Der Server fällt aus, weil er nicht genügend auf seine Belastbarkeit untersucht
wurde und die Kunden können für einige
Stunden diesen Dienst nicht in Anspruch
nehmen. Rechnet man mit einem Ausfall
von einem Tag, mit 15 Euro Kosten pro Gigabyte und einem Übertragungsvolumen
von 30 Gigabyte in dieser Zeit, so folgen
daraus entgangene Einnahmen in Höhe
von 700 Euro für den Anbieter. Und das
an einem Tag.
Hier erkennt man die Bedeutung, die
einer ausreichenden Überprüfung des
Systems, zukommt.
Was denken andere über Test?
Um zu erfahren, was andere Semester
über Testing denken, wurde eine Umfrage
an alle Medien- und Kommunikationsinformatik (Abk.: MKI) Bachelor-Semester
geschickt. Insgesamt antworteten 23 Stu-
denten darauf. Alle Semester (1. – 6. Semester) waren vertreten. Die Auswertung
erfolgte anonym, so dass durch die Ergebnisse kein Rückschluss auf die beteiligten Personen gezogen werden kann.
Die Teilnehmer wurden dazu aufgefordert, spontan zu nennen, was ihnen
einfällt, wenn sie das Wort „Tester/Testing“
hören. Hier ist bemerkenswert, dass die
Semester, die bisher noch keine Erfahrung
mit dem Softwareprojekt gesammelt
haben (Semester 1 – 4), häufig das Thema
„Benutzerfreundlichkeit“ nannten. Desweiteren war ihnen bewusst, dass die Tester
sich mit der Fehlersuche beschäftigen.
Die Semester 5 und 6 hingegen
nannten konkretere Begriffe wie zum
Beispiel „Validierung“, „Testpläne“ oder
„Anforderungen“. Auch wurden hier
Äußerungen zur Relevanz der Abteilung
Test gemacht; unter anderem „[…] Arbeit,
die unerlässlich ist“ oder „sehr wichtig.“
Eine weitere Aufgabe war es, die Relevanz von Tests in einem Softwareprojekt
zu benennen. Das Ergebnis zeigt, dass
dem Testing eine hohe Bedeutung zugesprochen wird. Zwölf der Teilnehmer
bewerteten es als „sehr wichtig“, elf als
„wichtig“.
Weiterhin wurden die Studenten dazu
befragt, welche der folgenden aufgelisteten Testarten sie kennen: Whitebox-,
Blackbox-, Modul-, Regressions-, System-,
SOP JOURNAL R4
55
TESTING
Abnahme-, Last-, Verfügbarkeit-, Installations-, WEB- und Benutzbarkeitstest. Am
bekanntesten waren System- und Benutzbarkeitstest mit jeweils 20 Stimmen. Der
WEB-Test ist mit 10 Stimmen die unbekannteste dieser Testarten.
Die letzte Frage verlangte von den Teilnehmern, dass sie angeben, in welchen
der Bereiche Projektmanagement, Konfigurations-und Änderungsmanagement,
Softwareentwicklung, Qualitätssicherung
und Test sie bereits Erfahrungen gesammelt hatten. 12 Teilnehmer gaben die
Softwareentwicklung an. Am wenigsten
Erfahrung wurde beim Testing gesammelt
(4 Studenten). Projektmanagement, Konfigurations- und Änderungsmanagement
und Qualitätssicherung lagen mit jeweils 6
Stimmen gleich auf.
Die niedrige Resonanz auf die Umfrage lässt darauf schließen, dass dem
Testen, testen, testen . . . [Film]
56
SOP JOURNAL R4
Überprüfen von Software eine geringe
Bedeutung zugestanden wird, wenn man
sich damit noch nicht befasst hat. So gingen von den Semestern 1 – 4 insgesamt
sechs Antworten ein, während es aus den
Semestern 5 und 6 total 17 waren.
Auch der Tester ist vor Irrtum nicht
gewappnet
Nicht nur Personen, die sich mit
der Materie „Test“ noch nicht vertraut
gemacht haben, unterliegen im Bezug
darauf Irrtümern. Auch die Mitglieder der
Abteilung Test haben zum Teil falsche
Vorstellungen von ihrer Disziplin. Woran
liegt das?
Im Folgenden werden die falschen
Annahmen, die ich selbst von dieser
Abteilung und ihrer Arbeit hatte, die
Wahrheiten dazu und die Gründe, warum
diese Irrtümer entstehen, genannt.
Irrtum 1: Testing bedeutet Testen und
sonst nichts. Die Tests werden von Anfang
an und über die gesamte Iteration hinweg
durchgeführt.
Fakt: Bevor überhaupt mit der Durchführung der Tests begonnen werden kann,
werden diese bis ins Detail geplant. Diese
Vorbereitungsphase zieht sich über die
ersten ¾ des Softwareprojekts. Es wird
ein Testplan erstellt, der die Testarten und
das Vorgehen ausführlich beschreibt. Auf
Basis der Kundenanforderungen erstellen
die Tester die sogenannten Testfälle, die
einzelne Szenarien der Anwendung mit
Eingabe, der Reaktion und dem gewünschtem Endzustand des Testobjekts
beschreiben.
Irrtum 2: Test ist gleich Test und jeder
Test wird gleich durchgeführt.
Fakt: Es gibt eine Menge verschiedener Tests. Beispiele hierfür sind: Modultest,
TESTING
Abnahmetest und Benutzbarkeitstest.
Jede Testart erfordert ein eigenes
Vorgehen. So werden für Modultests Testmethoden geschrieben. Der Abnahmetest
wird anhand einer Checkliste durchgeführt. Beim Benutzbarkeitstest liegt das
Augenmerk auf den Beobachtungen, die
die Testperson macht.
Irrtum 3: Es soll die Abwesenheit von
Fehlern festgestellt werden. Werden keine
Fehler gefunden, ist das Produkt qualitativ
hochwertig.
Fakt: Aufgabe des Testers ist es,
Fehler zu finden. Ein Test, der keine Fehler
findet, ist ein erfolgloser Test. Eine fehlerfreie Überprüfung des Testobjekts garantiert keine Fehlerfreiheit dieses Objekts.
Möglicherweise wurde der Test nicht
ausreichend durchdacht und kann keine
Fehlerquellen aufdecken.
Ziel ist es, Fehler aufzudecken. Nur
gefundene Probleme können behoben
werden
Irrtum 4: Qualitätsmessung ist Sache
der Qualitätssicherung. Die Abteilung Test
hat damit nichts zu tun.
Fakt: Die Qualität der Software wird
anhand der Ergebnisse, die die durchgeführten Tests liefern, gemessen. Wurden
die Tests ausreichend geplant und ergaben
sie wenig Fehler, so kann man daran erkennen, dass das Produkt den Ansprüchen
gerecht entwickelt wurde.
Irrtum 5: Beim Testen von Software ist
es nicht nötig, sich mit deren Architektur
oder mit Programmieren auszukennen.
Fakt: Gerade bei der Erstellung von
Modultests braucht derjenige, der diese
erstellt, Kenntnis vom Code, da hier Test-
skripte geschrieben werden müssen.
Dass der Irrtum 5 ein generelles Problem darstellt, haben auch T. Beaubouef,
P. McDowell vom Department of Computer
Science and Industrial Technology, Southeastern Louisiana University, festgestellt.
So beobachteten sie, dass einige der
Studenten, welche sich zwar allgemein
für das Thema Informatik interessieren,
aber behaupten, Programmieren zu hassen, angaben, dass sie eventuell Software
testen könnten. Diesen Studenten fehlt
die Erkenntnis, dass „Programmieren ein
bedeutender Aspekt“ des Testens ist. (vgl.
[2], S. 47)
Gründe der Irrtümer und
Lösungsvorschläge
Erst in der Vorlesung „Softwaretechnik
II“ erhält der Student einen umfangreichen Überblick über die verschiedenen
Testaktivitäten/-phasen. Kritisch hierbei
ist auch, dass nur in dieser Vorlesung das
Thema behandelt wird und auch nur als
ein Aspekt der gesamten Veranstaltung.
Desweiteren wird hier nur theoretisch
auf die Thematik eingegangen, aber die
Praxis nicht geübt. Vor dieser Vorlesung
wurden von den Studenten oft keine
ausreichenden Überlegungen zur Sache
vorgenommen, weil das Thema Test in
den unteren Semestern von MKI nicht
oder nur oberflächlich behandelt wird.
Zwar kennt man das „was“ eines Tests (das
Überprüfen einer Sache), aber nicht das
„wie“ (wie überprüft man die Sache?).
Meiner Meinung nach ist es wichtig,
bereits in den unteren Semestern auf die
Thematik von Softwaretests einzugehen
und ihre Durchführung und Relevanz
für die Studenten darzulegen. So könnte möglicherweise verhindert werden,
dass die Studenten ein „Trial-and Error“Vorgehen beim Testen entwickeln. Auch
sollte die praktische Anwendung von
Tests geübt werden.
Stephen H. Edwards vom Virginia
Tech, Dept. of Computer Science kritisiert
ebenfalls, dass trotz der Relevanz des
Themas Test die meisten Informatiklehrpläne nur eine minimale Abdeckung des
Themas bieten. (vgl. [3]). Er schlägt vor,
Softwaretesting in einer Art zu unterrichten, die die Studenten selbst dazu ermutigt, ihre Fähigkeit zu testen zu trainieren.
Auch sollten die Studenten eine konkrete
Rückmeldung dazu bekommen.
Desweiteren sollte den Studenten veranschaulicht werden, welche negativen
Auswirkungen unzureichend getestete
Systeme in der Praxis haben können.
Es können nämlich nicht nur finanzielle
Schäden entstehen. Im schlimmsten Fall
kann es Menschenleben kosten.
Christine Heberle, Testing (Leitung)
Quellen
[1] http://www.spiegel.de/wirtschaft/0,1518,335124,00.html
[2] T. Beaubouef, P. McDowell; Computer Science: Student myths and misconceptions; Journal of Computing
Sciences in Colleges (Juni 2008); ACM
[3] Stephen H. Edwards; Improving Student Performance by Evaluating - How Well Students Test Their Own
Programs; ACM Journal of Educational Resources in Computing, Vol. 3, No. 3, September 2003, Article 01
SOP JOURNAL R4
57
TESTING
EIN PROJEKT ZWISCHEN MODELL UND BERUFSALLTAG
Kann ein Planspiel eine gute Vorbereitung für das Berufsleben sein?
Im Rahmen des Softwareprojekts
(SOP) wird die Zusammenarbeit von
Personen mit unterschiedlichen Rollen zur
Entwicklung einer komplexen Software
geübt. Ziel ist es, Erfahrungen zu sammeln, um diese im späteren Berufsleben
verwenden zu können.
Was sind dabei gute Vorgehensweisen und was kann man anders oder besser
angehen?
Das SOP läuft über mehrere Iterationen.
In jeder Iteration arbeiten Studenten über
zwei Semester an dem Projekt. Es wird
von dem früheren Semester übernommen
und später an das nachfolgende Semester
übergeben.
Jeder Student soll in seiner Funktion
zum Gelingen beitragen. Dabei kann sich
jeder zwischen folgenden Rollen entscheiden:
• Softwareentwickler
• Projektmanager
• Qualitätssicherer
• Tester
• Konfigurationsmanager oder
• Kunde
Die Geschäftsleitung wird von zwei
Professoren mit Projekterfahrung eingenommen. Dies ist eine gute Einrichtung,
da nur durch eine erfahrene Geschäftslei-
58
SOP JOURNAL R4
tung ein realistisches Vorgehen gesichert
ist.
Eine
Softwareentwicklungsfirma
wird detailgenau nachgebildet und von
Semester zu Semester im Hinblick auf
die zu entwickelnde Software optimiert.
Die Kunden setzen den Vertrag auf und
stehen in engem Kontakt mit der Firma. Es
werden Verträge gemacht, Teilzahlungen
beglichen, Recherchen durchgeführt, Statusmeetings abgehalten und Zwischenergebnisse in Reviews vorgestellt.
Es stellt sich die Frage, wie gut ein solches Projekt die Probleme und Situationen
des späteren Berufslebens nachbilden
kann.
Während der zwei Semester ist es
möglich einen Einblick in Geschäftsprozesse und Arbeitsabläufe zu bekommen. Jeder beschäftigt sich intensiv mit
seiner Rolle. Die Studenten holen sich
Informationen und Ratschläge von der
Vorgängeriteration. Alles wird durch die
Projektleiter koordiniert und durch die
Geschäftsführung kontrolliert. Die Arbeitsprozesse sind für alle Beteiligten durch
regelmäßige Meetings transparent.
Das Ziel unserer Iteration ist die Restrukturierung und Modularisierung einer
angefangenen
Archivierungssoftware.
Dem Kunden soll ein Architekturvorschlag
einer Implementierung mit Zeitplan und
Kosten geliefert werden.
Meine Spezialisierung
in diesem
Projekt ist die Rolle des Testers. Ich werde
im Folgenden meine Erfahrungen aus dem
Projekt schildern.
Der Arbeitsablauf ist durch das
vorgegebene Ziel, einen festen Terminplan und die Rollenverteilung festgelegt.
Der Ablauf ist strukturiert, was sich positiv
auf die Koordination der Einzelaktivitäten
auswirkt. Schon am Anfang des Semesters
stehen alle Termine fest und jeder kann
gezielt auf die Meilensteine hinarbeiten.
Jedes Teammitglied ist über die Gesamtaufgabe wie auch über seine Rolle im
Detail informiert. Missverständnisse und
unterschiedliche Zielvorstellungen sind
hierdurch auf ein Minimum beschränkt.
Jedes Mitglied muss sich an die Vorgaben
halten, was durch die Qualitätssicherung
überprüft wird.
Ein gemeinsames Verständnis und
eine vollständige Information helfen bei
der Bewältigung gemeinsamer Aufgaben!
Da es beim Abnahmetest durch neue
Vorgaben der Geschäftsführung eine
Änderung gab, musste der Projektplan
überarbeitet werden. Diese Umstrukturierung hat für uns Tester zu einer vorgezogenen Einarbeitung in den Abnahmetest
geführt. Die Vorbereitungen mussten
in wenigen Stunden erledigt werden.
TESTING
Den Projektplan durch neue Vorgaben
gestört zu bekommen, verringert die
Motivation des Projektteams, konnte hierbei festgestellt werden. Statt erfolgreich
absolvierter Meilensteine erzielt man nur
kleine oder manchmal nicht nach außen
sichtbare Projektergebnisse. Erst wenn die
Konzepte so überarbeitet sind, dass die
neuen Vorgaben enthalten sind, können
wieder Fortschritte erzielt werden.
Wir haben jedoch auch positive
Erfahrungen mit der Überarbeitung der
Pläne machen können. Es ist wichtig konkrete Absprachen mit den Vorgängern zu
treffen. Dies wurde von den Projektmanagern gut koordiniert und wir konnten in
einen geordneten Projektmodus zurückzufinden.
In dieser Situation haben wir erfahren,
dass eine gute Zusammenarbeit zwischen
den Teams von großer Bedeutung ist.
Ein weiteres Problem war, dass nicht
die vollständige Infrastruktur zur Verfügung gestellt wird. Jeder Student ist für
seine Arbeitsumgebung verantwortlich.
Bei der Beschaffung der Installationsdateien gab es Zugangsprobleme und
deshalb mussten wir die Dateien von den
Softwareentwicklern anfordern.
An diesem Beispiel kann man erkennen, dass oft kurzfristig außerplanmäßige
Wege beschritten werden müssen. Ein
guter Plan reicht nicht aus, um an das Ziel
zu gelangen. Eine gewisse Flexibilität ist
ebenso wichtig.
“IT-Fachleute müssen sich heutzutage
nicht nur mit der Technik auskennen,
sondern auch den Umgang mit Kunden
oder Mitarbeitern und Führungskräften in
Erfüllt die Software alle Anforderungen? [Film]
der eigenen Firma beherrschen. Sie wirken
an Projekten mit und müssen die richtigen
Entscheidungen für die Zukunft treffen”[1],
so sieht es Michael Kuhrts als erfahrener
Projektleiter.
Projekte, die nach Plan verlaufen sind
selten, wie ich auch bei meinem Praxiseinsatz bei einem großen Softwarehaus
erfahren habe. Dort habe ich das Arbeiten
in internationalen Testteams kennengelernt.
Bei einem Projekt ist es wichtig ein
gutes Projektmanagement und eine gute
Kontrolle zu haben, da das Projekt sonst
unkoordiniert, viel langsamer oder in eine
falsche Richtung läuft. Das Projektmanagement in unserem Projekt hat gut funktioniert
und sichergestellt, dass wir die Projektziele erreichen. Wir hatten aber auch die
Situation, dass es beim Abnahmetest eine
Umstrukturierung der Aufgabenverteilung
gab. Dies hätte durch eine rechtzeitig
abgestimmte Planung vermieden werden
können.
Die parallelen Aktivitäten bei der
Übergabe von einem Studententeam an
das andere beim Iterationswechsel waren
für uns etwas gewöhnungsbedürftig. Der
SOP JOURNAL R4
59
TESTING
Abstimmungsaufwand durch die parallel
tätigen Teams ist sehr hoch. Wir haben
erfahren, dass Einarbeitung, Zusammenarbeit und die Übergabe des Projekts
wichtig ist. Der parallele Ablauf ist eine
Besonderheit und Herausforderung zugleich. Dies ist –denke ich- eine wichtige
Erfahrung für das spätere Berufsleben.
Am Beispiel der Testrolle kann die
Wichtigkeit von geordneten Übergängen
und dem Abschluss von Projektmeilensteinen dargestellt werden. Der Tester ist
für die Durchführung des Abnahmetests
verantwortlich. Dieser dient dazu den
Stand und die Funktionstüchtigkeit des
Produktes bei der Übergabe an die nächste Iteration zu überprüfen und zu dokumentieren. Er ist die Voraussetzung, dass
das Projekt von der Nachfolgeriteration
übernommen und weitergeführt werden
kann.
Es ist wichtig, die Vorgehensweise,
die Tests und die Ergebnisse genau zu
dokumentieren. Den Nachfolgern wird
der Einstieg erleichtert, wenn die bisherige Durchführung transparent und nachvollziehbar ist. Die ständige Weitergabe
von Iteration zu Iteration ist nach meiner
Meinung ein gutes Modell. Dadurch ist
man gezwungen Nachfolger einzuarbeiten, alles zu dokumentieren und von den
Vorgängern zeitnah alle Informationen zu
erfragen, da diese nach Beendigung des
Projekts meist nicht mehr zu erreichen
sind. Nach jeder Iteration muss eine Übergabedokumentation erstellt werden.
Auch später im Beruf kann es sein,
dass Personen ihre Arbeitsstelle oder
Abteilung wechseln, wodurch es für den
60
SOP JOURNAL R4
Nachfolger schwierig ist, die Arbeit ohne
Bruch fortzuführen, wenn diese nicht
ordnungsgemäß dokumentiert ist.
In dem Bereich „Test“ ist es wichtig vergangene Testergebnisse festzuhalten, um
sie mit späteren Ergebnissen vergleichen
zu können. Nur so kann der Fortschritt
erkannt und jeder Test reproduzierbar
gemacht werden. Frühere Testergebnisse
sind die Grundlage für die zukünftigen
Tests.
Um Meinungen aus dem Berufsleben
zu erhalten, wurden frühere Absolventen
der Medieninformatik, die berufstätig sind,
zu ihren Erfahrungen befragt. Hierbei wird
klar, dass man auch im Berufsleben immer
wieder an Stellen kommt, bei denen es
zu stocken scheint. Man soll also nicht
denken, dass „das Arbeiten später ein
Vergnügen sei. Man wird immer wieder an
Stellen ankommen, an denen es wichtig
ist, sich selber motivieren zu können“, so
ein früherer Student.
Ein Anderer meinte, „dass nicht immer die Besten die Führungspositionen
besetzen, sondern die, die am lautesten
schreien.“ Auch bei dem Projekt konnte
man feststellen, dass, wenn man aktiv
mitgestalten und seine Meinung kund tun
will, man nicht zurückschrecken darf diese
deutlich zu vertreten.
Die Äußerungen der früheren Stu-
denten stimmen mit unseren Erfahrungen
aus dem Projekt überein.
Auch andere Hochschulen sehen
einen großen Wert in der Durchführung
eines Planspiels. „Die Entwicklung des
Planspiels der Hochschule Luzern ist aus
der Überlegung entstanden, dass das
gegenseitige Verständnis für die Herausforderungen anderer Leistungsträger
sowie eine optimale Kommunikation
innerhalb einer Destination wesentliche
Voraussetzungen sind für eine einheitliche
Strategie und den wirtschaftlichen Erfolg.
Im Planspiel nehmen die Elemente Kommunikation zwischen den Leistungsträgern
und die Entwicklung gemeinsamer Strategien und Ziele einen wesentlichen Platz
ein, neben der Optimierung der eigenen
Unternehmensziele.“[2]
Die Frage ob sich ein Modell auf die
Wirklichkeit übertragen lässt, kann dahingehend beantwortet werden: Ein Planspiel
kann das Berufsleben nicht vollständig
nachbilden. Dennoch stimmen die Projekterkenntnisse mit Erfahrungen aus der
Arbeitswelt überein. Sicherlich kann die
Komplexität und Vielfältigkeit der Realität
nicht nachgestellt werden, aber es ist eine
sehr gute Möglichkeit für Studenten realitätsnahe Erfahrungen zu sammeln. Es ist
eine gute Methode, um den Einstieg in
den Beruf zu erleichtern.
Laura Böhm, Testing
Quellen
[1] IT Security Manager; ITK Journal
itk.mittelstandswiki.de/2007/07/weiterbildungsangebot-zum-itsecurity-manager
[2] Erfolgreicheres Destinations-Management dank neuem Planspiel; HS Luzern
www.hslu.ch/wirtschaft/w-weiterbildung/w-weiterbildung-aktuelles/w-weiterbildung-aktuell-destinationsmanagement-link.htm
QUALITÄTSSICHERUNG
DAS SYSTEMAUDIT IM SOFTWAREPROJEKT
Qualität beschreibt die Beschaffenheit oder die Güte eines materiellen oder
immateriellen Produktes. Sie hängt dabei
nicht unwesentlich von der Konjunktur
ab. Ist die Nachfrage nach einem Produkt
groß und das Angebot klein, kann es sein,
dass die Qualität keine so wichtige Rolle
spielt, wenn eine dementsprechende
Kaufkraft vorhanden ist. Produktionskosten
werden auf Kosten der Qualität gesenkt,
um die Gewinne zu erhöhen. Anders sieht
es aus, wenn der Markt hart umkämpft ist.
Denn hier zählt jeder Kunde. In diesem Fall
entscheiden Faktoren wie Preis, Leistung
aber auch Qualität, ob sich das Produkt
durchsetzt. Als Softwareentwicklungsfirma muss man mit den großen „Softwareschmieden“ der Welt mithalten können
und in der Lage sein bessere Software zu
entwickeln, als die Open Source Entwickler, die den Markt mit ihren kostenlosen
Programmen ständig auf Trab halten.
Das Qualitätsmanagement
und das QMS
Um in diesem Softwareprojekt (SOP)
ein gewisses Niveau an Qualität zu erreichen, ist es wichtig, ein Qualitätsmanagementsystem (kurz: QMS) aufzubauen.
Dieses System soll gewährleisten, dass
das Qualitätsniveau, welches durch die
Anforderungen der Kunden und der eigenen Anforderungen (des SOPs) an die
Firma und an das Produkt definiert ist, erreicht und auch ständig weiter entwickelt
wird. Dies ist die Aufgabe der Abteilung
Qualitätssicherung (QS) des SOPs. An
dieser Stelle sollte man jedoch festhalten,
dass die Bezeichnung Qualitätssicherung
nur ein Teil der Aufgaben beschreibt, die
im Projekt zu bewältigen sind. Einige dieser Aufgaben fallen in Bereiche der Qualitätsplanung, Qualitätslenkung oder Qualitätsverbesserung. Somit wäre die korrekte
Bezeichnung für diese Abteilung eigentlich
Qualitätsmanagement. Der Einfachheit halber wird hier also nur von Qualitätsmanagement gesprochen, welches alle vorhin
genannten Bestandteile umfasst.
Audits
Unter Audits versteht man ein Konzept
zur systematischen Überprüfung von Prozessen und Systemen. Diese sollen zur
Verbesserung der (Management-)Systeme
führen, was sich nicht zuletzt auch auf die
Qualität der erstellten Produkte auswirken
kann. Anhand von Checklisten, Richtlinien
und Dokumentationen werden Fehler,
Missstände und Abweichungen aufgedeckt und dokumentiert, um die nötigen
Lenkungsentscheidungen treffen zu können und Fehlentwicklungen entgegenzusteuern. Audits können sowohl intern
(Selbstüberprüfung) als auch extern durchgeführt werden. Externe Systemaudits
(oder auch Zertifizierungsaudits) werden
von anerkannten Zertifizierungstellen wie
z.B. TÜV, Dekra, VdS oder der Bundesnetzagentur durchgeführt. Man unterscheidet
zwischen Prozessaudit und Systemaudit.
Das Prozessaudit legt sein Augenmerk auf
einen einzelnen Prozess, während das
Systemaudit das gesamte QM-System
überprüft. Einem Systemaudit liegt die
DIN EN ISO 9001:2000 zugrunde, welche
die Vorgaben und Anforderungen an ein
Qualitätsmanagementsystem definiert.
Systemaudit im Projekt
Kommen wir nun im Speziellen zum
Systemaudit im Softwareprojekt. Dabei
stellt sich als erstes die Frage, ob das
Durchführen eines solchen Audits im SOP
notwendig ist. Diese Frage kann man aus
den folgenden Gründen klar mit einem JA
beantworten:
1. Es wird von der Geschäftsleitung ein
QM-System auf Basis von DIN EN ISO
9001 verlangt
2. Konkurrenzfähigkeit und Wettbe-werbsvorteil durch ein zertifiziertes QMS
3. Bessere Struktur und Planungsmö-glichkeiten im Projekt durch Richtlinien und
einheitliche Prozesse
4. Erkennung des Ist-Zustandes und Überführung in den Soll-Zustand
Obwohl es sich im SOP um ein sehr
kleines Projekt handelt, rechtfertigen diese
Gründe den Aufwand für die Erarbeitung
und Durchführung eines Systemaudits im
Softwareprojekt.
Seit Beginn des Projekts gibt es schon
vorsichtige Versuche, ein vernünftiges
QMS aufzubauen. Aber erst ab Iteration 3
SOP JOURNAL R4
61
QUALITÄTSSICHERUNG
wurden hierzu die DIN-Normen des Qualitätsmanagements als Grundlage eingeführt. Ebenfalls wurde das erste Teil-Systemaudit durchgeführt, welches sich auch
auf diese Normen bezieht. Wir befinden
uns momentan in Iteration 4. Somit wird
deutlich, dass sich der Aufbau des QMSystems noch in der Anfangsphase befindet. Umfangreiche Dokumenta-tionen und
Richtlinien zu verschiedensten Bereichen
des Projekts wie z.B. Kommunikation, Organisation, Programmierung sind durchaus
vorhanden, aber welche Anforderungen
an das QMS bisher erfüllt sind, ist noch
relativ unklar. Dies liegt daran, dass es
bis jetzt noch kein vollständig durchgeführtes Systemaudit gab und viele Bereiche des Systems nicht annähernd der
Norm entsprechen. Als Beispiel kann man
hier die Forderung 4.1 aus der ISO 9001
nennen. Diese verlangt, dass alle Prozesse
im Projekt identifiziert und deren Wechselwirkungen bekannt sind. Im Projekt
herrschen hier zum Beispiel noch große
Defizite. Solche Missstände kann man
jedoch durch ein vernünftig durchgeführtes Systemaudit herausarbeiten, um
diese dann zu bereinigen.
Die Checkliste des Systemaudits
Anhand der DIN ISO 9001:2000 haben
unsere Vorgänger eine Checkliste erstellt,
welche alle Aspekte der 9001er Norm abdeckt. Diese Liste ist in ihrer Struktur soweit
komplett und inhaltlich sehr ausgereift.
Der Aufbau sieht wie folgt aus:
1. Definition
2. Teilnehmer des Systemaudits
3. Prozessbeschreibung
4. Übersicht über die auditierten
Elemente
5. Fragenkatalog
6. Ergebnis des Systemaudits
7. Zusammenfassende Bewertung
Der Fragenkatalog bildet das Herzstück
der Checkliste und ist dementsprechend
sehr umfangreich. Er beinhaltet alle wichtigen Ergebnisse und Erkenntnisse aus
den Audits. Diese werden im letzten
Teil ausgewertet, bewertet und zusammengefasst. Die Fragen selber könnten an
manchen Stellen noch optimiert werden.
Einige sollten mehr präzisiert werden und
umfangreiche Fragen in einzelne Teilfragen
aufgeteilt werden, um die Arbeit mit dem
Katalog zukünftig einfacher zu gestalten
und die Ergebnisse deutlicher sichtbar
zu machen. Tabelle 1 soll dies an einem
Beispiel verdeutlichen.
Durchführung des Systemaudits
Mit der obengenannten Checkliste,
dem Qualitätsmanagementhandbuch und
den Richtlinien des Qualitätsmanagement
ist der zuständige Auditor, im Normalfall
der Qualitätsmanager oder ein QMBeauftragter, nun in der Lage, das Audit
durchzuführen. Zuerst wird festgelegt,
welche Bereiche des QMS überprüft
Tabelle 1
Alter Fragenkatalog
Überarbeiteter Fragenkatalog
4.2.3 Lenkung von Dokumenten:
4.2.3 Lenkung von Dokumenten:
- Lenkung von Dokumenten die vom QMS
In welcher Form werden die für das QM-System erforderlichen internen und externen
gefordert werden
Dokumente gelenkt?
- Einführung eines dokumentierten Verfahrens:
In wie weit ist ein dokumentiertes Verfahren festgelegt und wie werden nachfolgende
- Genehmigung der Dokumente
Maßnahmen geregelt:
- Bewertung der Dokumente
o Genehmigung der Dokumente vor ihrer Herausgabe bezüglich ihrer Angemessenheit;
- Kennzeichnen von Änderungen
o Überprüfung, Aktualisierung (bei Bedarf) und Neu-Genehmigung der Dokumente;
- Verfügbarkeit
o Kennzeichnung von Änderungen und des aktuellen Überarbeitungsstatus der Dokumente;
o Sicherstellen, dass gültige Fassungen zutreffender Dokumente an den jeweiligen
Einsatzorten verfügbar sind;
o ...
62
SOP JOURNAL R4
QUALITÄTSSICHERUNG
werden sollen. In unserem Projekt wird
momentan noch bewusst darauf verzichtet, ein komplettes Systemaudit durchzuführen. Dieses wäre zwar durchaus
möglich, macht jedoch wenig Sinn, da
sich das QM-System noch in einem frühen
Entwicklungsstadium befindet. Daher ist
es effektiver, sich bei der Überprüfung
auf zwei bis drei Kernpunkte der Norm
zu beschränken. So können während der
kurzen Projektdauer die Ergebnisse der
Überprüfung noch in derselben Iteration
umgesetzt werden. Man verhindert damit,
dass durch den Iterationswechsel Wissen
verloren geht, welches sich trotz guter Dokumentation und reibungsloser Übergabe
nicht 100prozentig vermeiden lässt. Um
dem ganzen einen roten Faden zugeben,
beginnen wir in unserer Iteration mit auditieren der ersten zwei Anforderungen
aus der ISO (Allgemeine Anforderungen,
Verantwortung der Leitung). Alle weiteren
Iterationen sollten darauf aufbauen und
sich an die gleiche Reihenfolge halten,
wie sie auch in der Norm zu finden ist.
Das Audit hilft dabei das QM-System
Schritt für Schritt aufzubauen und weiter
zu entwickeln, bis sämtliche Aspekte der
Norm erfüllt sind.
Die DIN EN ISO 9001:2000 ist bewusst
sehr allgemein gehalten worden, damit sie
nicht nur auf Softwareentwicklungsfirmen
anwendbar ist, sondern auch auf andere
Bereiche und Gewerbe. Dadurch sind
manche Anforderungen der DIN EN ISO
9001:2000 momentan noch nicht relevant
für das Projekt. Zum Beispiel werden im
Projekt weder Produkte beschafft, noch
steht man im Kontakt mit Lieferanten, daher
Qualitätssicherung - nichts wird dem Zufall überlassen. [Film]
ist das Kapital 7.4 „Beschaffung“ in dieser
Form auf das Projekt nicht anwendbar und
muss somit nicht auditiert werden.
Die eigentliche Prüfung sieht so aus,
dass der Auditor den Fragekatalog nach
und nach durcharbeitet und zu jeder
Frage notiert, in wie weit die Anforderungen erfüllt sind. Des Weiteren wird noch
festgehalten, wo dies dokumentiert ist
bzw. wo das relevante Dokument zu
finden ist. Die Ergebnisse werden zum
Schluss zusammengefasst, bewertet und
an die verantwortlichen Stellen weitergeleitet. Die Verantwortlichen können dann
die nötigen Maßnahmen einleiten.
Resümee
Das Systemaudit ist deshalb so wichtig für das Erarbeiten und das Anwenden
eines Qualitätsmanagementsystems, weil
es eine Art Motor darstellt, welches den
Kreislauf des prozessorientierten Modells
(siehe dazu Schaubild „Modell eines Prozessorientierten Qualitätsmanagementsystems“) antreibt und am Leben hält. Die
einzelnen Stationen des Kreislaufs werden
somit in regelmäßigen Abständen durchlaufen, was dazuführt, dass das QMS
ständig überprüft und weiterentwickelt
wird. Das Systemaudit sollte, wenn
möglich, ein- bis zweimal pro Iteration
durchgeführt werden. Bei regelmäßigen
Audits ist aber darauf zu achten, dass
sich keine Routine einschleicht, was zu
einer Verminderung der Akzeptanz und
Verunsicherung gegenüber den Audits
führen kann. Ein komplettes Systemaudit
ist zurzeit nicht zu empfehlen, sollte aber
mit Fortschreiten des Systems in Zukunft
stattfinden.
Patrick Theurer, Qualitätssicherung (Leitung)
Quellen
[1] Herausgegeben Dezember 2000 vom Normausschuss Qualitätsmanagement, Statistik und Zertifizierungsgrundlangen (NQSZ) im DIN Deutschen Institut für Normung e.V.
[2] Siehe dazu den Fachartikel: „Mit Fallbeispielen ein höheres Qualitätsniveau der Audits erreichen“ auf http://
qm-web.de/fachwissen/fachartikel/mit-fallbeispielen-ein-hoheres-qualitatsniveau-der-audits-erreichen/ von
Torsten Moch, Senior Quality ManagerPrograms;
SOP JOURNAL R4
63
QUALITÄTSSICHERUNG
ZWISCHEN CHEF UND LAUFBURSCHE
Die Qualitätssicherung im Softwareprojekt
Durch die Erstellung von Richtlinien
ist es möglich, anderen Abteilungen
Anweisungen zu geben, an welche sie
sich halten müssen. Es ist sozusagen
möglich, den „Chef“ zu spielen.
Allerdings kommt es vor, dass diese
Richtlinien nicht eingehalten werden
und man muss die Betroffenen immer
wieder darauf aufmerksam machen.
Dadurch und durch die Erledigung
zusätzlicher Aufgaben, bekommt man
das Gefühl eines „Laufburschen“.
Das Bachelor-Projekt ist völlig anders
konzipiert als die sonstigen Vorlesungen.
Wurde der Unterricht in den vorherigen
Semestern größtenteils von den Professoren gehalten, wird der „Spieß“ im Bachelor-Projekt umgedreht. Dadurch kommen neue Aufgaben und Herausforderungen auf die Studenten zu, welche sie
meistern müssen. Die Studenten sind zum
Beispiel für die Organisation und Gestaltung des Unterrichts verantwortlich.
Es gibt sechs unterschiedliche
Abteilungen im Bachelor-Projekt (Kunden,
Projektmanagement, Konfigurations- und
Änderungsmanagement,
Softwareentwicklung, Test, Qualitätssicherung),
die das gemeinsame Ziel verfolgen, ein
Langzeitarchivierungssystem zu entwickeln.
64
SOP JOURNAL R4
Da in der Abteilung Qualitätssicherung
Erfahrungen gesammelt werden konnten,
werden in diesem Artikel die Aufgaben
und Probleme dieser Abteilung erläutert.
Qualitätssicherung oder doch
Qualitätsmanagement?
Der Begriff der Qualitätssicherung
wird im Bachelor-Projekt etwas anders
verwendet, als es in manchen Unternehmen der Fall ist. Diese Beobachtung konnte durch Gespräche mit Verwandten und
Bekannten gemacht werden, die in einer
Firma als Qualitätssicherer tätig waren. Als
Aufgabe hatten sie beispielsweise nur, die
erstellten Produkte zu überprüfen und dabei zu beachten, dass die vom Qualitätsmanagement festgelegten Richtwerte für
Größe, Form, Gewicht etc. des Produktes,
nicht überschritten werden.
Allgemein gilt, dass im Falle einer
Überschreitung von Richtwerten, die
Qualitätssicherung alle bisher beteiligten
Prozesse stoppen muss, um weitere Fehler
zu verhindern. Durch eine anschließende
Analyse der beteiligten Prozesse, gilt es
die Fehlerhaften ausfindig zu machen und
zu verbessern. Der Idealfall ist, dass Fehler erkannt werden, bevor sie überhaupt
entstehen.
Neben dieser Aufgabe die Qualität
zu sichern, muss man sich im Projekt auch
um das Qualitätsmanagement kümmern.
Dazu müssen Verfahren und Richtlinien
festgelegt werden, welche notwendig
sind, um eine bestimmte Prozess- und
Produktqualität zu erreichen.
Diese sogenannten Verfahrensanweisungen legen fest, wie bestimmte
Tätigkeiten auszuführen sind. In den Verfahrensanweisungen werden die einzelnen Schritte und Vorgaben für Prozesse
dokumentiert, um einen definierten Qualitätsstandard zu erreichen bzw. zu halten.
Außerdem gibt es sechs spezielle Verfahrensanweisungen, welche von der DIN EN
ISO 9001:2000 gefordert werden.
Die Begriffe Qualitätsmanagement
und Qualitätssicherung sorgen auch in
der Wirtschaft für etwas Verwirrung: „In
Deutschland war seit 1968 bis Mitte 1994,
(…) „Qualitätssicherung“ die offizielle
deutsche Benennung für das Qualitätsmanagement“ ([1], S.23). Erst durch die
Einführung internationaler Normen wurde
dies geändert.
Trotzdem gibt es heute noch Institutionen und Vorträge, in denen von Qualitätssicherung gesprochen wird, obwohl
das Qualitätsmanagement gemeint ist (vgl.
[1], S.23).
Die Abteilung auf einer anderen Ebene
Während die Kunden und Projektman-
QUALITÄTSSICHERUNG
ager auf der selben Ebene stehen und die
jeweiligen Abteilungen wie Softwareentwicklung, Test, Konfigurations- und
Änderungsmanagement der Projektleitung
unterstehen, hat die Qualitätssicherung
eine eigene Stellung. Dadurch, dass auch
die Aufgaben des Qualitätsmanagements
übernommen werden, ist die Qualitätssicherung den Projektmanagern nicht
unterstellt. Diese spezielle Rolle wurde
durch Herrn Strobusch, der ein Projektleiter bei der Firma Siemens ist, bestätigt.
In der Iteration 5 war diese Stellung
dadurch erkennbar, dass die zu erledigenden Aufgaben größtenteils selbst
ausgesucht wurden. Weiterhin wurden
Richtlinien erstellt, an die sich selbst die
Projektmanager halten müssen, obwohl
sie das Projekt lenken und die höchste
Stellung in der ITERA Group haben. Durch
die Erstellung von Richtlinien hatte man
die Möglichkeit seinem eigenem „Chef“
Anweisungen zu geben, an welche er sich
auch halten musste!
muss und welche Inhalte in den einzelnen Reviews zu präsentieren sind. Durch
diese Richtlinien werden die jeweiligen
Prozesse klar definiert, um so für einen
optimalen Arbeitsablauf zu sorgen. Dabei
ist zu beachten, dass die Regeln klar und
verständlich geschrieben sind, so dass sie
von jedem Mitglied einfach verwendet
werden können – denn laut einer Mitarbeiterumfrage vom 03. April 2008 wünscht
man sich Richtlinien, welche sehr strukturiert und leicht zu handhaben sind. Des
Weiteren müssen die Qualitätsrichtlinien
an Änderungen im Projekt angepasst werden. Treten Änderungen auf, müssen alle
Mitarbeiter darüber informiert werden,
um Fehler zu vermeiden. Die Aufdeckung
bzw. Verhinderung von Fehlern, ist eine der
Hauptaufgaben der Qualitätssicherung.
Traten zum Beispiel bisher Probleme bei
der Benennung von Dokumenten auf, so
gibt es klare Richtlinien, wie fertiggestellte
Dokumente benannt werden müssen.
Ob sich die Mitarbeiter an die Richtlinien
Präsentation der Richtlinien. [Film]
Die Richtlinien
In jeder Iteration tauchen bei Projektmitgliedern Fragen und Probleme auf, die
eventuell Grundlage neuer Richtlinien sind.
Zum Beispiel könnte es Probleme bei der
Erstellung und Veröffentlichung von Dokumenten, oder beim Einsatz von Kommunikationsmitteln geben. So liegt es im
Aufgabengebiet der Qualitätssicherung,
dafür klar definierte Richtlinien zu erstellen, die Regeln für die bestimmten Prozesse beschreiben. In den Richtlinien wird
u.a. festgehalten, wie zum Beispiel ein
Arbeits- bzw. Statusgespräch aussehen
SOP JOURNAL R4
65
QUALITÄTSSICHERUNG
halten, muss ständig geprüft werden. Aus
diesem Grund werden Verstöße dokumentiert und bei Wiederholungen kommt
es zu Punktabzügen bei der Artefakt- und
Prozessqualität bzw. bei schwerwiegenden Verstößen zu einer Mahnung.
So viel zur Theorie über die Richtlinien.
Schön wäre es, wenn sich alle Mitarbeiter an die Richtlinien halten würden.
In der Iteration 5 gab es, wie in wahrscheinlich jeder Iteration, Verstöße gegen
Richtlinien. In diesen Fällen mussten die
Qualitätssicherer die Mitarbeiter auf ihre
Fehler aufmerksam machen. Bei groben
Verstößen, wie zum Beispiel beim unentschuldigten Fehlen an einem Meeting,
haben die Projektmanger diese Aufgabe
übernommen, da die Meetings von ihnen
protokolliert wurden.
Ein Problem bei der Einhaltung der
Richtlinien war, dass sie nicht von jedem
gelesen wurden. So wussten die Mitarbeiter nicht, auf was sie alles zu achten
hatten. Obwohl in Meetings auf manche
Richtlinien aufmerksam gemacht wurde,
wurden sie trotzdem nicht eingehalten.
Mehrfaches Nachhaken bei den Betroffenen war die Folge. Auch zur Kommunikation im „Virtual Team Room“ (Vitero),
wurden neue Richtlinien erstellt und an
alle Abteilungen verschickt. Auch hier war
bei den ersten Meetings erkennbar, dass
nur manche Mitarbeiter die neu erstellten
Richtlinien gelesen haben.
Ein möglicher Lösungsansatz, dass
Richtlinien zukünftig gelesen werden, wäre
die Einführung von mündlichen Abfragen
seitens der Qualitätssicherung. Werden
66
SOP JOURNAL R4
die Richtlinien wieder ignoriert, könnte es
vorerst zu einer mündlichen und später zu
einer schriftlichen Ermahnung kommen.
Außerdem wurden der Qualitätssicherung
zu Beginn des Projektes einige Grenzen
aufgezeigt, wieweit man bei der Erstellung
von Richtlinien gehen darf. Denn durch die
Richtlinien dürfen die Mitarbeiter nicht zu
sehr bei ihrer Arbeit eingeschränkt sein.
Auch als „Chef“ muss man auf manche
Meinungen und Bedürfnisse der Mitarbeiter eingehen und sie respektieren.
Mitarbeiterzufriedenheit
Wie in jeder Firma ist das Arbeitsklima
ein wichtiges Kriterium für eine erfolgreiche Arbeit. Aus diesem Grund werden
Mitarbeiterbefragungen durchgeführt, um
so brenzlige Situationen zu erkennen. Da
sich die Mitarbeiter direkt an Fehlerquellen
befinden, tragen sie wesentlich zu Fehlererkennung bei. Deshalb ist es wichtig,
dass die Bedürfnisse der Mitarbeiter vom
ganzen Unternehmen ernst genommen
werden.
Umfragen sollten daher regelmäßig
durchgeführt werden, denn sie dienen
zur Vorsorge für ein optimales Betriebsklima und zur Sicherung der Qualität im
Kommunikations- und Arbeitsablauf.
Andere Aufgaben
In der fünften Iteration des BachelorProjektes übernahm die Qualitätssicherung
Quellen
[1] Walter Geiger; Willi Kotte: Handbuch Qualität, 2008
[2] Trauboth: Softwarequalitätssicherung, 1993
einige Aufgaben der Abteilung Konfigurations- und Änderungsmanagement. So
wurden zum Beispiel neue Dokumentund Präsentationsvorlagen erstellt. Diese
Formatvorlagen definieren den Stil, die
Farben und die Formatierung eines Dokumentes. Dadurch wird ein einheitliches
Aussehen jedes Schriftstücks definiert und
die Arbeit aller Abteilungen erleichtert.
Die Mitarbeiter konnten sich somit bei der
Erstellung von Dokumenten ganz auf den
Inhalt konzentrieren.
Die beschriebenen Aufgaben liegen
normalerweise nicht im Bereich der Qualitätssicherung. Allerdings hatten die Kollegen des Konfigurations- und Änderungsmanagements anfangs viel zu tun, sodass
man diese Aufgaben übernahm.
Fazit
Allgemeine Aufgaben der Qualitätssicherung bzw. des Qualitätsmanagements wurden im Bachelor-Projekt
berücksichtigt. Sie sind laut der DIN 55
350, Teil 11 folgendermaßen definiert:
„Qualitätssicherung ist die Gesamtheit der
Tätigkeiten der Qualitätsplanung, -lenkung
und -prüfung“ ([2], S.275). Allerdings wurden auch andere, abteilungsübergreifende
Aufgaben erledigt. Dadurch erinnert dies
immer wieder an einen Laufburschen,
welcher mal hier und dort zur Verfügung
stehen und anderen nachrennen muss.
Daniel Grbavac, Qualitätssicherung
FILMTEAM (KUNDE)
DAS HEER DER DINGE
Drei Studenten auf dem Weg des Filmemachens
Die Welt ist im Wandel. Im Zeitalter
des deutschen Sommermärchens und des
YOUTUBE-Kultes drängen Filmemacher
in bis dato unberührte Gefilde vor. Zum
ersten Mal in der Geschichte der Menschheit sollte in der fünften Iteration das
Softwareprojekt filmisch dokumentiert
werden. An diese Aufgaben wagten sich
drei Studenten und hielten ein Jahr lang
die Erlebnisse Ihrer Kommilitonen mit der
Kamera fest. Ein Heer an Aufgaben und
Dingen mussten sie bewältigen. Dies ist
ihre Geschichte:
Erster Teil - Die Gefährdeten
Anfangs kamen wir uns wie drei
Aussätzige vor. Während die anderen von
Ihren Rollen im Softwareprojekt zumindest die Bezeichnungen wussten, wurden
wir belächelt als „das Filmteam“. Uns
war nur bekannt, dass wir der Kundenfirma untergeordnet sind und das Ziel
hatten, einen Dokumentarfilm über das
Softwareprojekt zu drehen. Dafür gab es
allerdings kein Vorgehensmodell wie den
RUP (Rational Unified Process), der einem
erklärt, welche Positionen und Aufgaben
zu besetzen sind. Stattdessen war Eigeninitiative gefragt.
Weil wir zu dritt waren, teilten wir
zunächst die unserer Meinung nach wichtigsten Rollen in einer Filmproduktion auf:
Kamera (Fabian Flohr), Ton (Achim Lang)
und Regie (Tobias Ripperger). Nebenbei
waren wir dann noch Drehbuchautoren,
Produzenten, Beleuchter, Cutter, 3D-Artists, Requisiteure, Locationscouts, etc.
Angesichts dieser Anzahl von eigentlich zu vergebenen Jobs sahen wir unser
Vorhaben etwas gefährdet. Waren wir zu
dritt wirklich in der Lage, all diese Aufgaben zu bewerkstelligen? Wer nicht wagt
der nicht gewinnt; wir begannen mit unserer Arbeit.
Im ersten Review stellten wir der
Öffentlichkeit
die Rahmendaten für
den Film vor: „Ein 10 bis 20 minütiger
Dokumentarfilm in HDV (High Definition
Video, 16:9 Format: 1280 x 720 Pixel) zur
Vorführung vor Studieninteressierten und
auf dem Webportal des Softwareprojekts
sowie bei allgemeinen Veranstaltungen.
Zusätzlich wird ein maximal ein minütiger
Trailer geschnitten, der als kleiner Werbefilm zum Beispiel am Tag der offenen Tür
eingesetzt werden kann und auf die Vorführung des gesamten Films hinweist.“ [1]
Mit dieser Zielsetzung im Hinterkopf
machten wir uns auf die Suche nach der
zündenden Idee, wie wir das Softwareprojekt in Bild und Ton wiedergeben
konnten. Dies erwies sich schwieriger als
gedacht.
Zweiter Teil - Die zwei Stürme
Die Wolken an unserem Ideenhorizont
zogen sich zusammen. Wir sahen uns
einem Sturm der Einöde gegenüber, in
dem junge Menschen vor Ihren Rechnern
zu sehen waren und in die Tastaturen hackten; ohne viel Worte, ohne Emotionen.
Stellen Sie sich vor, Sie müssten eine
Partie Schach so in einen Actionfilm verpacken, dass der zwölf jährige Sohnemann
voller Überzeugung sagt: „Boah Papa, ich
will lieber doch kein Fußballprofi werden,
Schachspieler sind ja noch cooler! Wie
kann ich das werden?“. Unsere Situation
war ähnlich, bloß dass die Partie Schach
das Softwareprojekt, der zwölfjährige
Sohnemann die Studenten und der Actionstreifen ein Dokumentarfilm waren.
Wie bereitet man ein bildtechnisch
eher langweiliges Thema so auf, dass der
Zuschauer nicht eine Viertelstunde lang
die gleichen Bilder zugemutet bekommt?
Im Falle der oben genannten Schachpartie
wäre eine Möglichkeit, die Figuren in die
Geschichte einer anderen Welt zu übertragen. Eine mittelalterliche Kulisse mit Rittern, Burgen, Königen, Prinzessinnen und
dem hart arbeitenden Bauernvolk kommt
einem hierfür sofort in den Sinn. Das fände
mit Sicherheit auch der Sohnemann spannender als Holzfiguren, die auf dem Spielbrett hin und her geschoben werden.
SOP JOURNAL R4
67
FILMTEAM (KUNDE)
„SOPMovie, Szene Y, die Xte . . . “ [Film]
In unserem Fall suchten wir für das
Softwareprojekt eine Bildmetapher: Der
Bau eines Hauses von der Planung bis zu
Fertigstellung, ein Fußballverein mit seinen
verschiedenen Mannschaftsteilen, ein Orchester und das Zusammenspiel seiner Instrumente . . . Alles Ideen, die theoretisch
ausgebaut werden konnten, aber von
denen uns keine überzeugte; bis auf eine:
Das Schachspiel („von persisch: Schah, für
‚König‘ – daher die stehende Metapher:
‚das königliche Spiel‘ “ [2]).
Schach ist Strategie, das Softwareprojekt ist Strategie; zwei Farben stehen sich
gegenüber, zwei Iterationen laufen parallel; sechs Figurentypen spielen miteinander, sechs Teams arbeiten zusammen;
die Spieler ziehen die Figuren, die Professoren fungieren als Geschäftsführer.
Die Grundidee für unseren Film war
geboren. Die Professoren bzw. die Geschäftsführer sollten in einer übernatürlichen Umgebung quasi wie Heilige zusam-
68
SOP JOURNAL R4
men sitzen und Schach spielen. Aus
Ihrer erhabenen Position konnten Sie alle
Vorgänge im realen Softwareprojekt sehen
und die Studenten durch die Schachfiguren kontrollieren. Durch Ziehen einzelner
Figuren konnten bedrohliche Situationen
herbeigeführt oder taktische Spielereien
vorgenommen werden.
Jede Figur repräsentierte ein Team.
Der Kunde war der König, wie im richtigen
Leben. Die Projektleitung verkörperte die
Königin, welche dem König gefallen muss
und im Vergleich zu Ihren Untertanen die
größte Bewegungsfreiheit besitzt. Für das
Konfigurationsmanagement, welches für
jede Hardwareeinrichtung das Rechenzentrum aufsuchen musste, stand der
Läufer. Die Tester ritten auf allen Fehlern
herum, symbolisiert durch den Springer.
Den Handlungsspielraum grenzten die
Qualitätssicherer ein, wie die Ecktürme
einer Festung. Als letztes die Entwickler, welche für die eigentliche Arbeit
zuständig waren, wie die Bauern.
Jedes Team sollte im Film episodenweise vorgestellt werden. Dies sollte nicht
in der Umgebung Hochschule geschehen,
um eine Bildtristesse zu vermeiden. Stattdessen fanden wir Situationsmetapher.
Z.B. schwitzten die Softwareentwickler
an den Geräten im Fitnessstudio wie bei
Ihren Programmierproblemen; die Kunden
genossen ein feines Geschäftsessen und
Ihre Position als Auftraggeber; die Projektleitung setzte am Pokertisch ihr Pokerface
auf und sortierte Ihre Chips wie die Aufgaben der einzelnen Teams . . . Der Sturm
der Bildeinöde zog vorüber.
Unser Konzept, welches bis jetzt
in unseren Köpfen existierte und grob
in einem Exposé festgehalten wurde,
musste in Form eines Drehbuchs zu Papier
gebracht werden.
Den Ablauf der in sich geschlossenen Episoden konnten wir uns gut
vorstellen und festhalten. Die Übergänge
dazwischen führten uns dagegen in
Sackgassen. Wie sollte z.B. eine logische
Verknüpfung zwischen dem Pokertisch
und den Heiligen aussehen? Sollten sich
die Protagonisten begegnen? Wo sollte
dies geschehen? Über was sollten Sie
sprechen? Wir saßen teilweise drei bis vier
Stunden vor dem Drehbuch und hatten
keinen einzigen Satz auf Papier geschrieben. Der Sturm der Verzweiflung suchte
uns heim. Wir mussten lernen: „Drehbuch
schreiben ist nichts für Sprinter, sondern
etwas für Langtreckenläufer.“ ([3], S.114)
Im Kopf sieht man den fertigen Film;
versucht man, den Ablauf schriftlich zu
fixieren, läuft nichts mehr zusammen.
FILMTEAM (KUNDE)
Vielleicht kann Philip Parker mit seiner
Software, die das Schreiben automatisiert, irgendwann einmal auch Drehbücher
verfassen (vgl. [4]). Der Erstellungsprozess
würde sicherlich um einiges beschleunigt
werden. Kreativ werden diese Drehbücher,
die durch mathematische Formeln entstehen, allerdings nicht mehr sein. Und das
ist ja, was beim Schreiben Spaß macht.
Auch uns brachten kreative Geistesblitze, die auf unerklärliche Weise nie
zum gewünschten Zeitpunkt eintraten,
auf einfache Lösungen von komplexen
Problemen. Im genannten Fall z.B., dass
der Projektleiter vom Pokertisch aus die
Geschäftsleitung anrief, während diese
am Schachbrett saß.
Nach der sechsten komplett überarbeiteten Version des Drehbuchs beruhigte
sich auch der Sturm der Verzweiflung
wieder. Alle 22 Szenen waren durchgespielt, miteinander verknüpft und zu
Papier gebracht. Wir konnten mit den
Dreharbeiten beginnen.
Dritter Teil - Das Rücken der Könige
Nach einem halben Jahr Vorbereitung
stürzten wir uns also endlich in die lang
ersehnte Schlacht um spannende Bilder
und emotionale Interviews. Taktisch
aufgestellt wie oben beschrieben nahm
jeder seine Rolle ein. Wir waren schnell
eingespielt und jeder konnte sich auf
seine Aufgabe konzentrieren.
Die Arbeit des Regisseurs besteht
darin, das Drehbuch in einzelne Einstellungen aufzulösen. Die wichtigsten
Fragen, die hierbei beantwortet werden
müssen: „Wo platziere ich die Kamera?“
und „Was sage ich den Schauspielern?“
(vgl. [5], S.15/16 ) Ersteres fand immer in
Absprache mit dem Kameramann statt, für
die Schauspieler war ich verantwortlich.
Einmal im Leben durfte ich also die Professoren diktieren, sozusagen die Könige
des Studiengangs ins rechte Bild rücken.
Ausnahmsweise mussten sie meinen Anweisungen folgen und nicht umgekehrt.
Zugegeben war mir die Situation anfangs
suspekt, aber an Macht gewöhnt sich der
Mensch bekanntlich schnell.
Den Ablauf der einzelnen Szenen gab
ich stichpunkartig vor, um den Professoren
nicht jedes Wort in den Mund zu legen
und Ihnen einen Handlungsspielraum zu
geben. Diesen wussten sie allerdings nicht
zu nutzen. Die sonst so wortgewandten
Herren rangen nach der perfekten Formulierung. Exaktere Anweisungen wurden
gewünscht. Die versuchte ich zu geben.
Teilweise waren sie aber wohl zu ausgefallen. Sie glauben nicht, wie schwer es
einem Akademiker fällt, den Satz „Ja dann
müssen die (Studenten) sich halt auch mal
zu Hause auf Ihren Arsch hocken“ über
die Lippen zu bringen. Nach der siebten
Klappe war das schlechte Gewissen überwunden und die Einstellung so im Kasten,
dass der Satz glaubwürdig erschien. Die
Geschäftsführung hatte das „harte Brot
eines Drehtags kennen gelernt“ [6], dieses
aber mit Geduld über sich ergehen lassen.
Im Vergleich dazu waren die Dreharbeiten mit den Studenten anstrengender.
Die Meckerschwelle und die Disziplin
waren geringer, konnten aber auch durch
einen gesunden Spaßfaktor ausgeglichen
werden. Ausführliches über die Drehtage
mit unseren Kommilitonen verrät Fabian
Flohr in seinem Artikel.
Das Heer der Dinge, v.a. deren Zeitaufwand, hatten wir bei unserer Arbeit
unterschätzt. Eine Aufstockung auf vier
oder fünf Personen wäre sicherlich zu
empfehlen, wenn es das nächste Mal ein
Filmteam im Softwareprojekt geben wird.
Durch gegenseitige Motivation und
Investition von Überstunden wirkten wir
dem Zeitproblem entgegen, getreu dem
Keller’schen Leitsatz [7]: „Die [Studenten]
haben sieben Tage die Woche. Die können
das schaffen, die müssen das schaffen.“
Und aller Gefährdungen und Stürmen zum
Trotz konnten wir unseren Film bis zum
Premierentermin fertigstellen.
Nach 248 Tagen waren wir am Ziel
unseres Weges angekommen. Entspannt
konnten wir uns in den Kinosessel lehnen
und das Heer der Dinge, die wir bewältigt
hatten, Revue passieren lassen; zusammengefasst in 22 Minuten Film.
Tobias Ripperger, Film (Regie)
Quellen
[1] Flohr, Lang, Ripperger: Exposé zum Dokumentarfilm des Softwareprojekts, Reutlingen 2007
[2] http://de.wikipedia.org/wiki/Schach (Stand: 28.05.08)
[3] Robert McKee, STORY. Die Prinzipien des Drehbuchschreibens, Alexander Verlag Berlin 2007
[4] http://www.ftd.de/lifestyle/outofoffice/353773.html (Stand: 28.05.08)
[5] David Mamet, Die Kunst der Filmregie, 4. Auflage, Alexander Verlag Berlin 2006
[6] E-Mail von Prof. Dr. Uwe Kloos nach dem Drehtag der Heiligenszene
[7] Filmzitat Prof. Dr. Wolfgang Keller zu der Zeiteinteilung der Teams
SOP JOURNAL R4
69
FILMTEAM (KUNDE)
Rennen für die Kamera. [Film]
DER WAHNSINNSDREH
oder: Was das Filmen so schwierig macht.
Schweißgebadet und in grellstem
Scheinwerferlicht jagen acht Informatiker der Bewegung des Laufbandes
entgegen. So grotesk und paradox
dieses Bild auf Außenstehende wirken
mag: für das Filmteam war diese Szene
essenziell um das Softwareprojekt zu
erklären.
70
SOP JOURNAL R4
Im Fitnessstudio McFit (Reutlingen)
wurde eine der insgesamt 4 inszenierten
Szenen für den SOP-Film gedreht. Insgesamt 9 Stunden ermüdende Dreharbeit
für volle 2 Minuten geschnittenen Film.
Bevor sich aber die Programmiererbeine in
Bewegung setzen konnten, mussten vom
Filmteam einige Vorkehrungen getroffen
werden.
Licht an
Für die Vorbereitung eines Drehortes
müssen mehrere Stunden eingeplant
werden. Bei einem dokumentarischen
Dreh wird der Drehort, meist einige Tag
vorher, zum ersten Mal besichtigt. Unter
Beachtung des Drehbuches beraten sich
Regisseur und Kameramann über geeignete Einstellungen, Lichtpositionen und
FILMTEAM (KUNDE)
Requisiten. Technische Begebenheiten
des Drehortes (z.B. Steckdosen) werden
untersucht und organisatorische Fragen
mit den zuständigen Personen geklärt. Vor
dem eigentlichen Dreh ist es die Aufgabe
des Kameramannes, das Licht zu setzen.
Für den dokumentarischen Film ist im Freien oft die Sonne als einzige Lichtquelle
ausreichend. In Innenräumen wird dagegen sehr viel Zeit benötigt, um gezielt
Akzente in der Beleuchtung zu setzen. Es
gilt zu beachten, dass das Licht mehr als
nur ein Mittel zur Erhellung des Raumes
ist. „Es schildert das Milieu, charakterisiert
und dramatisiert“ [1] . Im Fitnessstudio
wurde eine sehr breitflächige Beleuchtung eingesetzt, um die Sterilität und
Unpersönlichkeit des Raumes zu erhalten.
Eine Standard-Ausleuchtung einer Szene
erfolgt durch die „3-Punkt-Beleuchtung“.
(Abbildung 1)
Das Führungslicht bezeichnet das logische Licht einer Szene. Es ist jenes Licht,
welches der Zuschauer auch im Bild identifizieren kann. In Innenräumen kann dies
eine sichtbare Deckenlampe sein, oder
die Sonnen-, bzw. Mondeinstrahlung
durch ein Fenster. Die Beleuchtung sollte
nach dem Führungslicht ausgerichtet sein.
Ist beispielsweise eine Schreibtischlampe
das für den Betrachter hellste Licht in einer
Szene, so müssen auch sämtliche Personen oder Objekte im Umfeld der Lampe
sichtbar von dieser angestrahlt werden.
Da eine Schreibtischlampe nur eine geringe Leistung hat (<50 Watt), muss künstliches Licht eingesetzt werden, um die
Lichtabstrahlung der Lampe zu simulieren.
Das Führungslicht erzeugt gravierende
Abbildung 1: 3-Punkt-Beleuchtung
Kontrastunterschiede, welche durch die
Aufhellung ausgeglichen werden müssen.
Die Kante sorgt dann noch für einen räumlichen Tiefeneindruck. Wird eine Person
zusätzlich von hinten angestrahlt, hebt sie
sich durch den entstehenden Lichtkranz
vom Hintergrund ab.
Wer das McFit in Reutlingen kennt,
weiß dass es sich hierbei um ein großes
Spiegelkabinett mit vielen Fenstern
handelt. Was schön aussieht, ist für die
Filmarbeit mehr als hinderlich. Da der
Dreh im Fitnessstudio nachts stattfand,
konnte das Filmteam, ohne Rücksicht auf
einfallende Sonnenstrahlen, den Lichtaufbau gestalten. Hätte der Dreh tagsüber
stattgefunden, wären später im Schnitt,
die unterschiedlichen Lichtverhältnisse
der Szenen aufgefallen. Dies hätte man
nur, durch abkleben, der der Sonne zugewandten Fenster, verhindern können.
So trivial es sich auch anhört: Spiegel
und Fenster reflektieren das Licht! Bestimmte Kamerapositionen werden aufgrund
der Spiegelungen unmöglich. Ständig
müssen Scheinwerfer und Darsteller umgestellt werden, um zu verhindern, dass
unerwünschte Reflektionen im Bild zu
sehen sind. Es gilt das einfache physikalische Gesetz: Einfallswinkel gleich Ausfallswinkel. Wer im Spiegel die Kameralinse sieht, kann sich sicher im Bild wissen.
Andererseits machten die vielen Spiegel
sehr außergewöhnliche und abstrakte
Bilder möglich. So entstanden Bilder mit
sehr großer Tiefe und schönen Schärfeverlagerungen, für welche man sich gerne
zusätzliche Mühe macht.
Kommando Rakete
Während des Drehs galt es die Kontrolle und Übersicht zu behalten. Bei
acht mitwirkenden Schauspielern keine
einfache Aufgabe für das Drei-Mann-
SOP JOURNAL R4
71
FILMTEAM (KUNDE)
Filmteam. Nach einer Pause mussten die
Schauspieler wieder genau an ihre Ausgangspositionen zurückkehren. Verändert
sich nämlich ungewollt, von einer Einstellung zur Nächsten, die Position oder das
Aussehen von Objekten oder Menschen
im Bild, spricht man von so genannten
Kontinuitätsfehlern. Ein Kontinuitätsfehler
ist also eine gezeigte Information, die
einer zuvor gezeigten Information widerspricht. Solche Fehler entstehen im Durcheinander eines Drehs sehr schnell.
Um diese Fehler zu vermeiden sollte die
Position und das Aussehen von Objekten
und Personen genauestens, in einer Kontinuitätsliste, festgehalten werden.
Große Hollywood Produktionen haben
mit solchen Fehlern genauso zu kämpfen.
Smithee sammelte diese in seinem Buch:
„Filmfehler – Hollywoods peinlichste
Leinwand-Patzer“ [2] . So machte es sich
beispielsweise ein Tonmann in „Fluch
der Karibik“, auf dem Schiff des „Captain
Jack Sparrow“, so gemütlich, dass er die
Klappe nicht hörte. Der Tonmann mit Jogginghose und Turnschuhen (voll im Bild!)
wurde erst von Kinobesuchern entdeckt.
Auch Michael Douglas Zusammenprall
mit einem Gummiberg in „Auf der Suche
nach dem grünen Diamanten“ wurde von
Kinobesuchern entdeckt. Anstatt hart
und unnachgiebig zu sein, wölbte sich
der Granitfels nach innen und bescherte
Douglas einen weichen Aufprall [2].
Bemerkenswert ist, dass HollywoodProduktionen meist mit mindestens 2 Kontinuitätsmitarbeitern am Set ausgestattet
sind, deren einzige Aufgabe es ist, solche
Patzer zu vermeiden. Und schon hier schlei-
72
SOP JOURNAL R4
chen sich diese Fehler ohne Scham ein.
Das SOP-Filmteam musste diese Aufgaben
ohne weitere Unterstützung erledigen.
Dass das nicht geklappt hat, sollte später
dann im Schnitt festgestellt werden. Allein
in der Fitnessszene entstanden, bei mehr
als 120 Klappen, viele kleine und große
Filmfehler. Der aufmerksame Betrachter
wird diese Fauxpas später entdecken und
darüber schmunzeln.
Dilemma Dokumentare
Moment! Warum werden in einem
Dokumentarfilm eigentlich überhaupt
Szenen nachgespielt? Nach J. Gierson
[3] soll diese Filmgattung „die Wirklichkeit beobachten und in eindrucksvolle,
dramatische Form gekleidet werden“ [4] .
Eine Situation wird aber keineswegs von
unterschiedlichen Personen gleich interpretiert. Vielmehr ist die„ dokumentarische
Wiedergabe der Wirklichkeit […] abhängig vom ideologischen Standpunkt des
Filmdokumentaristen“ (nach F. Zöchbauer)
[Kandorfer]. Ein Film, egal ob Spielfilm
oder Dokumentarfilm, will eine Geschichte
erzählen. Bekanntlich ist es nicht verboten
eine Geschichte auszuschmücken. Das
wurde schon vor 2000 Jahren mit der
Bibel gemacht. Ausschmückung bedeutet keinesfalls eine Verschleierung der
Wahrheit, sondern dient dem Betrachter
als ästhetische und verständliche Stütze.
In der Realität kommt es wohl eher selten
vor, dass sich das gesamte Entwicklerteam
zur Beratung im Fitnessstudio trifft. Hier
hat das Filmteam gezielt übertrieben. Die
Sportszenen sollten später die Anstrengungen der Softwareentwickler im Projekt
verdeutlichen. Mit Hilfe von Metaphern
(Gewichte u.a. Fitnessgeräte) wurde die
Situation der Entwickler unterstützt.
Eine weitere Schwierigkeit besteht
nun darin, dass bestimmte Stichworte für
die Geschichte, welche der Film erzählen
soll, unumgänglich sind. Kompliziert wird
das Ganze, wenn man beginnt, den Protagonisten bestimmte Sätze vorzukauen.
Hierbei verliert man einen wichtigen Teil
der dokumentarischen Arbeit, nämlich
die Authentizität und die Natürlichkeit der
Personen. Leider musste das Filmteam den
Verlust dieser so wichtigen „Schnappschuß-Qualität“[ Kandorfer] der Interviews
in Kauf nehmen. Die gestellten Interviews
werden den aufmerksamen Betrachter
später nicht täuschen können.
Der Dreh an diesem Tag sollte noch bis
zum Sonnenaufgang dauern. Die Menge
an Filmteam feindlichen Äußerungen
schoss Stunde für Stunde exponentiell
in die Höhe. Noch vor der drohenden
Meuterei wurden alle Darsteller um 6 Uhr
morgens in die Freiheit entlassen. Eine
Wahnsinnsleistung! Kompliment an die
Beteiligten.
Fabian Flohr, Film (Kamera)
Quellen
[1] Hilmar Mehnert, Das Bild in Film und Fernsehen S.120, VEB Fotokinoverlag Leipzig 1986
[2] Alan Smithee, Filmfehler: Hollywoods peinlichste Leinwand-Patzer S.16/32, Books on Demand GmbH 2004
[3] John Grierson (* 26. April 1898 in Deanston bei Doune, Schottland; † 19. Februar 1972 in Bath, England)
war ein britischer Dokumentarfilmregisseur und -produzent. Er gilt als „Vater des britischen und kanadischen
Dokumentarfilms“. Ihm wird die Einführung des Begriffes „documentary“ zugeschrieben.
[4] Pierre Kandorfer, DuMont’s Lehrbuch der Filmgestaltung S.32/33, DuMont Buchverlag Köln 1984
FILMTEAM (KUNDE)
HERR DER ANIMATION
Einmal “Gott spielen”
Mit der vierten Iteration des Softwareprojekts entstand eine neue Sparte
in der Kundenabteilung – das Film-Team.
Die Aufgabe der Filmgruppe lautet, eine
Iteration über gesamte zwei Semester
zu begleiten und deren Tätigkeiten in
Bild und Ton festzuhalten. Drei Personen
bilden das Film-Team, die ihre Arbeit in
drei verschiedene Kategorien aufgeteilt
haben: Regisseur/Postproduktion, Kamera/
Licht und Ton/Animation. Das Vorhaben
besteht darin, einen Dokumentarfilm zu
drehen, der einen Einblick in das Softwareprojekt gibt. Bestandteil davon wird
eine 3D-Computeranimation sein, die
anhand eines Schachspiels Verläufe im
Projekt leichter verständlich machen soll.
Was ist überhaupt Animation?
Animation leitet sich vom lateinischen
Wort „animare“ ab, das ins Deutsche übersetzt „zum Leben erwecken“ bedeutet.
Viele einzelne Bilder werden aneinandergereiht und bilden eine Filmsequenz. Eine 3D-Animation basiert auf dem
gleichen Verfahren. Allerdings handelt es
sich hierbei nicht nur um aufeinanderfolgende Fotografien, sondern um Bilder, die
im Computer erstellt wurden. Szenarien
oder ganze Landschaften werden im dreidimensionalen Raum nachgebaut. Es ist
dann möglich, sich mithilfe von Kamera-
fahrten durch diese selbsterstellten Räume
zu bewegen und diese als Animation zu
speichern.
Im Film werden die Figuren eines
Schachspiels zum Leben erweckt. Parallel dazu soll später eine Sprecherstimme
verschiedene Abläufe im Softwareprojekt
erklären. Es ist wichtig, die Animation an
ein vorgegebenes Zeitlimit anzupassen,
damit diese Stimme Platz findet. Es ist
zwar nicht immer leicht, aber es ist alles
machbar, da man die Kontrolle darüber
hat, wie jedes Bild auszusehen hat und
wieviele Bilder aufeinander folgen sollen.
Man kann deshalb auch selbst bestimmen, wie die Schachfiguren zum Leben
erweckt werden sollen, was für eine Stimmungslage sie haben, wie sie sich bewegen und wenn es im Drehbuch vorgesehen
ist, wie sie wieder sterben sollen.
Die Animation beginnt mit einer
Kamerafahrt, die einen Gesamtüberblick
über das ganze Schachbrett gibt. Anschließend erwacht die weiße Königin
zum Leben und sorgt dafür, dass sich die
anderen weißen Figuren formieren und
ihre Position auf dem Schachfeld einnehmen. Die schwarzen Figuren stehen schon
formiert an ihrem Platz. Der Kommentar
wird erst im Nachhinein hinzugefügt,
sodass auf diesen vorerst keine Rücksicht
genommen werden muss. Es muss aber
die im Drehbuch vorgesehene Handlung,
sowie mit dem Autor abgesprochene und
vorgegebene Animationsdauer eingehalten werden.
Es gibt verschiedene Programme mit
denen man „Gott spielen“ kann. Speziell für die Arbeit an diesem Film wird
Cinema 4D der Firma Maxon verwendet.
Es unterscheidet sich von den anderen
Programmen besonders dadurch, dass
die Steuerung innovativ und gleichzeitig
auch leicht zu erlernen ist. Beispielsweise
werden alle Objekte die in einer Szene
vorhanden sind in einer Ordnerstruktur
aufgelistet und können dort direkt modifiziert werden. Mit sogenannten Schlüsselbildern (engl. „keyframes“) kann festgelegt
werden, wann Objekte sich wo befinden
sollen oder wie stark zum Beispiel die
Lichtstärke nach fünf Sekunden Animation
sein soll.
Bei diesem Filmprojekt muss den Schachfiguren Leben eingehaucht werden.
Dies ist mithilfe von sogenannten Bones
möglich. In die modellierten Figuren wird
ein Knochengerüst, das sogenannten Rig
eingesetzt, das dann mit der Figur verschmolzen wird. Wird dann ein Knochen
bewegt, ändert sich die Form der Figur
ebenfalls. Doch wie sieht das Skelett einer
Schachfigur aus? In diesem Fall recht einfach – drei Knochen, die senkrecht über-
SOP JOURNAL R4
73
FILMTEAM (KUNDE)
einander stehen. Der Untere steuert die
Fußpartie, der mittlere den Rumpf und der
Obere die Kopfbewegungen. Die Knochen können nicht nur gekippt, sondern
auch in sich gedreht werden, sodass auch
eine Art „Zur-Seite-Schauen“ des Kopfes
möglich ist.
Das Animieren der Bones bzw. der
Figuren ist vom technischen Aufwand
her überschaubar und relativ leicht zu
bewerkstelligen. Tipps und Techniken
dazu können direkt von der Herstellerseite
heruntergeladen werden [1]. Hingegen ist
die Umsetzung von dem, was man sich
vorstellt zu dem wie es später aussehen
wird, sehr kompliziert. Oft sehen Bewegungen unrealistisch aus, da sie entweder
zu schnell, zu langsam oder zu abgehackt
animiert sind. Es ist dann viel Feinarbeit gefragt, die auch den meisten Zeitaufwand
erfordert.
„Rigging ist ein spannendes und
hochinteressantes Fachgebiet der 3DAnimation, das es sehr zeitaufwändig ist.
Es gibt einfache Anforderungen und einfache Lösungen, welche in vielen Fällen
genügen.“ [2]
Die Feinarbeit macht sich insofern
sichtbar, dass die einzelnen Keyframes
verschoben werden und deren Eigenschaften geändert werden müssen. Als
Eigenschaft bezeichnet man in diesem
Fall, ob eine Beschleunigung des Objektes
zwischen zwei Keyframes stattfinden soll
oder nicht.
Durch die Verwendung von Bones
ist zwar die Bewegung der Figur in sich
selbst gegeben, doch muss zusätzlich
auch angegeben werden, wohin sie
74
SOP JOURNAL R4
laufen soll. Dazu gehört auch, wie schnell
sie beschleunigen soll, in welche Richtung
sie sich orientiert, wo sie pausiert oder wo
sie Luftsprünge macht. Dies kann auf zwei
verschiedene Arten umgesetzt werden:
Entweder man setzt an bestimmten Positionen auf der Zeitachse Schlüsselbilder,
zwischen denen die anderen Keyframes
berechnet werden oder man verwendet
Pfade, sogenannte Splines, an denen sich
das Objekt orientiert.
Was sind Splines und welche Vorteile
hat man von ihnen? Splines sind mathematische Kurven, die anhand einzelner
Punkten im Raum berechnet werden. Diese
sind besonders dazu geeignet, Pfade
vorzugeben, auf denen sich Objekte bewegen sollen. Harte Kursänderungen oder
Geschwindigkeitsschwankungen werden
damit umgangen, da die Bewegung auf
den Verbindungslinien interpoliert wird.
Zusätzlich besteht die Möglichkeit einer
tangentialen Ausrichtung, sodass in unserem Fall zum Beispiel das Pferd die richtige
Laufrichtung hat und nicht rückwärts läuft.
Bei dieser Technik kann es passieren,
dass die Figur plötzlich auf dem Kopf steht
und trotzdem die richtige Laufrichtung hat.
Die Verwendung von Spline-Pfaden stößt
hiermit an ihre Grenzen, da sie keine Information über die Ausrichtung der Y-Achse
enthält. Es wird deshalb eine Erweiterung
benötigt – sogenannte Rail-Splines. Es
handelt sich hierbei zwar um die selbe
Art von Kurven, allerdings werden diese
anders interpretiert. Die Position der Rails
gibt an, in welche Richtung sich die YAchse ausrichten soll. Kombiniert man
Spline-Verfolgung mit Rail-Splines, so hat
man eine gute Kontrolle über den Verlauf
einer Pfad-Animation.
Um es zu veranschaulichen, hier ein
kleines Beispiel anhand eines Flugzeuges:
Ein Sportflieger möchte von Punkt A nach
Punkt B fliegen, einen Looping machen
und anschließend eine Schraube vollziehen. Seine Position und auch der Looping werden anhand eines tangentialen
Splinepfades definiert. Die Schraube
hingegen, bei der sich das Flugzeug um
die eigene Achse dreht, wird mithilfe des
Rail-Pfades verwirklicht.
Das Ziel während der gesamten Animation ist, das Material später im Film zu
verwenden. Es muss deshalb zu jederzeit
darauf Acht genommen werden, ob und
wie es sich im Schnitt integrieren lässt.
Die Hauptanimation, bei der sich die
Teams in Form von Schachfiguren zusammenfinden sollen, wird relativ früh im Film
eingebettet. Der Übergang findet durch
die Überblende einer realen Szene in
die Animation statt. Dabei wird nur das
Schachbrett und der König sichtbar sein,
um die Komplexität möglichst gering zu
halten. Der Winkel der Aufnahme wird
vorerst nicht berücksichtigt da dieser
später in der Animation angepasst wird.
Deshalb ist auch keine weitere Absprache
mit dem Kameramann notwendig.
Im Drehbuch steht, dass die Überblende als „nicht sichtbar“ umgesetzt
werden soll. Bei der Erstellung trat jedoch
das Problem auf, dass die Realszenen mit
einem Makro-Effekt aufgenommen wurden und zu Verzerrung der Perspektive
führten. Es konnte in der virtuellen Welt
ohne Werte über Kamerawinkel und
FILMTEAM (KUNDE)
Die modellierten Schachfiguren. [Film]
über Makroeinstellungen kein passendes
Ebenbild im vorgesehenen Zeitrahmen
geschaffen werden, sodass umgeplant
werden musste. Der Fehler macht sich
besonders auf dem Schachbrett bemerkbar, da hier Überlagerungsunterschiede
besonders auf den schwarz-weißen
Felder sichtbar werden.
Abhilfe gibt eine Änderung im Drehbuch, die den Übergang nun so regelt,
dass zuerst nur die Geometrie übereinstimmen muss. Sobald die Kamera ihre
Fahrt beginnt und das Schachbrett mit den
anderen Figuren sichtbar wird, erscheinen
auch langsam Texturen und Lichtreflexionen aller Objekte. Realisiert wird dies
wieder mithilfe von Keyframes die mit den
Materialeigenschaften belegt sind.
Dieser Fachartikel liefert zwar anhand eines einfachen Beispiels nur einen
kurzen Einblick in die Welt der Animation,
aber man sollte im Hinterkopf behalten,
dass diese genannten Techniken Grundbausteine für aktuelle Computerspiele und
auch für Hollywood-Streifen in Kinos, wie
zum Beispiel „Der Herr der Ringe“ sind.
Das Setzen und Bedienen von Splines
sowie der Umgang mit Bones ist in den
Programmen schon sehr fortgeschritten,
sodass die Veränderungen in Echtzeit
dargestellt werden können und die Arbeit dadurch sehr erleichtern. Abgesehen
davon spielt Kreativität bei der Erstellung
des Modells und bei der Animation auch
eine große Rolle. Trotz vieler Anleitungen,
die es für diese Schritte gibt, entscheidet
letztendlich der Objektmodellierer, wie
eine Figur auszusehen hat. Derjenige, der
für die Animation zuständig ist, entscheidet desweiteren, welche Emotionen ausgestrahlt werden. Zusammen geben diese
beiden Schritte der Figur eine individuelle
Persönlichkeit, die anhand einer Anleitung
nur schwer nachzubilden ist. Zum „Gott
spielen“ benötigt man also nicht nur ein
Programm und eine Anleitung, sondern
auch Kreativität!
Achim Lang, Film (Ton)
Quellen
[1] http://www.maxon.de > Tips and Techniques
[2] Funktionsweisen von Bones und Riggingtechniken, Marco Marterer, Facharbeit März 2008
SOP JOURNAL R4
75
ADRESSEN
Diana Hauser (09.01.1985)
Bannmattstr. 38
79650 Schopfheim
eMail: diana.hauser@gmx.de
ICQ: 133924279
Sebastian Schulz (23.06.1984)
Seestraße 34
72658 Bempflingen
eMail: sebl84@gmx.de
ICQ: 233728040
Christine Heberle (10.06.1984)
Vorstadtstraße 42
72108 Kiebingen
eMail: christine.heberle@gmx.de
ICQ: 139854208
Wencke Schulz (24.09.1984)
Saarstraße 43a
16225 Eberswalde
eMail: joinwencke@arcor.de
ICQ: 191221686
Marc Ammon (08.08.1984)
Frühlingsweg 9
72229 Rohrdorf
eMail: marc.ammon@web.de
ICQ: 149777572
Jacqueline Jonigkeit (03.07.1985)
Lerchenstr. 10
71254 Ditzingen
eMail: jacqueline.jonigkeit@gmx.de
ICQ: 104666571
Thomas Sellner (11.11.1984)
Ferdinand-Porschestr. 37
72760 Reutlingen
eMail: t.sellner@arcor.de
ICQ: 107425804
Philipp Becker (22.06.1979)
Mozartstr. 40
72762 Reutlingen
eMail: info@websites-online.org
ICQ: 432733459
Robert Krüger (04.11.1984)
Hardtstraße 61/3
73431 Aalen
eMail: rob_bert@gmx.de
ICQ: 120464874
Patrick Theurer (14.03.1985)
Rohrhaldenstr. 36
72108 Rottenburg
eMail: patth@gmx.de
ICQ: 106719175
Laura Böhm (24.07.1985)
Paul-Lincke-Str. 35
71069 Sindelfingen
eMail: laura@boehm-bb.de
ICQ: 213827470
Achim Lang (11.01.1985)
Im Winkel 20
78658 Flözlingen
eMail: achim@langw.de
ICQ: 89262860
Tobias Thieme (24.01.1984)
Greutweg 41
73733 Esslingen
eMail: tobias_thieme@gmx.de
ICQ: 124969491
Fabian Flohr (24.05.1985)
Im Egarten 2
88433 Schemmerhofen
eMail: befalu@gmx.de
ICQ: 345175135
Markus Leyrer (07.08.1984)
Untere Hardtbergstr. 17
72813 St. Johann
eMail: markus_leyrer@web.de
ICQ: 305268268
Kha Tran (01.08.1984)
Reutlingerstraße 4
72810 Gomaringen
eMail: khamui.84@gmail.com
ICQ: 286182950
Michael Garcorz (24.06.1980)
Alte Steige 18
72124 Pliezhausen
eMail: michaelgarcorz@genion.de
ICQ: 423480159
Alexander Paharukov (19.03.1985)
Heppstr. 67
72760 Reutlingen
eMail: a.paharukov@gmx.de
ICQ: 277603307
Armin Wälder (13.11.1983)
Karlstraße 2
72829 Engstingen
eMail: armin-waelder@web.de
ICQ: 296442503
Daniel Grbavac (26.03.1984)
Sülchenstraße 12
72108 Rottenburg
eMail: d-grbavac@gmx.de
ICQ: 442985399
Tobias Ripperger (20.06.1985)
Kolpingstr. 10
63773 Goldbach
eMail: design@remb.de
ICQ: 127230089
Emre Yay (15.01.1987)
Gögginger Str.22
73575 Leinzell
eMail: yayemre@aol.com
ICQ: 11005051
ADRESSEN
LISTE
76
SOP JOURNAL R4
„Das Schachspiel ist ein See, in welchem eine Mücke baden und ein Elefant ertrinken kann“
Indisches Sprichwort