iteration++ - MediaArchiv

Transcription

ITERATION++
Projektperiodikum
Medien- und Kommunikationsinformatik
Hochschule Reutlingen
Ausgabe Juni 2009
ITERATION++
1
Vorwort
Uwe Kloos
Im Sommer 2009 endet die siebte
Iteration des Bachelorprojektes und es
erscheint die 4. Auflage des zugehörigen Journals, nun zum zweiten Mal
unter dem Namen Iteration++. Das
Projekt hat seine Anfangshürden längst
überwunden und sich seit Beginn erkennbar weiterentwickelt. Mittlerweile sind drei virtuelle Firmen gegründet
worden, welche sich die unterschiedlichen Aufgaben im Projekt aufteilen
– Trésor, als Auftraggeber und Serviceanbieter; ITer@, die Softwareentwicklungsfirma und ServIT, der Anbieter
der technischen Infrastruktur. Diese
Umstrukturierung brachte besondere
Herausforderungen für die Projektorganisation und die Kommunikation.
In den letzten beiden Semestern des
Bachelorstudiengangs Medien- und
Kommunikationsinformatik nehmen
alle Studierenden dieser Semester an
einem rollenbasierten Planspiel teil,
bei dem die Softwareentwicklung in
einem Unternehmensumfeld simuliert
wird. Dabei werden die verschiedenen
Rollen wie Projektmanager, Auftraggeber, Softwareentwickler, Tester,
Qualitätssicherung, Marketing und
Weitere durch die Studierenden besetzt. Die Neueinsteiger aus dem
Anfangssemester werden von ihren
erfahren Kommilitonen aus dem Ab-
schlusssemester in die Rollen eingeführt und angeleitet. Durch die Einführung von drei Firmen erfolgte eine
stärkere Bindung der Personen innerhalb der Firmen auf Kosten der Kommunikation und Abstimmung zwischen den Firmen. Hierdurch wurden
ähnlich Arbeiten teilweise mehrfach
durchgeführt.
Im Fokus dieser nun seit über drei Jahren stattfindenden Lehrveranstaltung
stehen das Ausfüllen der Rollen und
der Umgang miteinander, wodurch
neben den technischen Befähigungen Kommunikation, Teamfähigkeit,
Zeitmanagement und das Präsentieren praktisch gefördert werden. In den
beiden Projektsemestern wird klar,
dass Softwareentwicklung weit mehr
ist als Programmierung. Planungen
und Ergebnisse werden regelmäßig in
verschiedenen Foren diskutiert und
präsentiert. Neben den internen Besprechungen gibt es Reviews zu festen
Terminen und klar geregelten Entwicklungsstufen, bei denen die Ergebnisse vorgestellt und zur Diskussion gestellt werden. In Arbeitsgesprächen werden dedizierte Themen von
der Geschäftsleitung vertieft betrachtet und besprochen. Die Geschäftsleitung wird durch ein Professorenteam gebildet, welches die Leistungen
der Firmenmitarbeiter bewertet, die
Nachhaltigkeit sicherstellen soll und
die langfristige Strategie vorgibt. Eine
Aufgabe, die durch die Einführung der
drei Firmen nicht leichter, aber durchaus reizvoller geworden ist.
Mit der zweiten Ausgabe von Iteration++ haben Sie ein Fachjournal in
der Hand, bei dem die Studierenden
ein zu ihrer Rolle passendes Fachthema herausgegriffen und vertiefend
analysiert und beschrieben haben. Ein
Redaktionsteam steuerte die Erstellung
der Artikel, bei denen neben der fachlichen Thematik auch der Schreibstil
kritisch geprüft wurde. Das Ergebnis
von zwei Semestern Projekterfahrung
liegt nun vor Ihnen und ich wünsche
Ihnen eine anregende Lektüre. Den
Studierenden der siebten Iteration
wünsche ich eine erfolgreiche Zukunft
und dass sie sich im Berufsleben an die
eine oder andere Projekterfahrung erinnern.
Ihr
Prof. Dr. Uwe Kloos
Juni 2009
SOP JOURNAL HOCHSCHULE REUTLINGEN R6
2
ITERATION++
Inhaltsverzeichnis
Allgemein
Das Spiel zum Berufserfolg?........................................................................................................................................................................................4
Planspiele in der Wirtschaft - Samet Keser
Ein Projektteam lernt die Benutzer kennen.........................................................................................................................................................7
Fiktive Personen in einem Softwareprojekt - Patrick Gaßner
Projektorganisation
Achtung, Risiko!..............................................................................................................................................................................................................11
Mit der Einführung eines Risikomanagement im SOP zum Erfolg. - Manuela Di Laudo
Der Schritt zur Matrix‐Projektorganisation.......................................................................................................................................................14
Oder: „Wie bekommen wir die Mitarbeiter wieder zum Arbeiten?“ - Denis Merkle
Der beste Mann für diesen Job ist eine Frau......................................................................................................................................................17
Die Herausforderung der Frau im Softwareprojekt - Silke Link
Kostenschätzung im SOP............................................................................................................................................................................................20
Neue Methoden zur verbesserten Planung - Dominic Schwörer
Langzeitarchivierung
Im Kampf gegen das digitale Vergessen.............................................................................................................................................................24
Anforderungen und Strategien an ein Langzeitarchivierungssystem im SOP - Gerold Lacher
Kommunikation
Ein gutes Gespräch........................................................................................................................................................................................................27
Kommunikation im Softwareprojekt - Markus Jülich
Kommunikation zwischen Unsichtbaren............................................................................................................................................................29
Lösungsansätze für die Probleme in der internen Unternehmenskommunikation - Fabian Liedtke
Infrastruktur
Virtuelle Serverlandschaft.........................................................................................................................................................................................32
Die Vorteile eines Servers mit VMware ESX - Christian Kubat
LDAP und Typo3, passt das wirklich?....................................................................................................................................................................35
LDAP-Anbindung für jeden Projektteilnehmer - Dennis Riekert
Programmierung
1001 Funktion führen zur Entwicklerfrustration!...........................................................................................................................................38
Welche Funktionen benötigt ein Entwickler wirklich? - Simon Hänel
Eclipse-RAP – sinnloser Sprechgesang oder Hilfe im SOP ?.......................................................................................................................42
Wie man dem Web-Client neues Leben einhauchen könnte… - Marco Bischof
Eclipse RCP auf dem Vormarsch!.............................................................................................................................................................................45
Auch für den Einsatz im SOP geeignet? - Matthias Huber
ITERATION++
3
Programmierung
Java Sicherheit.................................................................................................................................................................................................................48
Warum behauptet wird, Java sei sicher und wie Java versucht, dieses Ziel zu erreichen - Torsten Lutz
GUI Toolkits für Java......................................................................................................................................................................................................51
Ein Vergleich - Thomas Staiger
Objekte im Winterschlaf..............................................................................................................................................................................................54
Wie kann Hibernate erfolgreich eingesetzt werden? - Eduard Tudenhöfner
Test
Von der „Friday Night Pizza Party“ zum automatisierten Lasttest.........................................................................................................58
Vererbung mal anders – Wie man erfolgreich Anforderungen des Kunden über Iterationen ignoriert - Mario Schwarz
Effektive Organisation des Abnahmetests..........................................................................................................................................................62
Die Rolle des Abnahmetests in einem iterativen Softwareentwicklungsprozess - Natalia Zyleva
Qualitätssicherung
Qualität erzeugen, nicht erprüfen!.........................................................................................................................................................................64
Audits im SOP - Durchführung und Notwendigkeit - Sarah Letzgus
Zertifizierung im Softwareprojekt.........................................................................................................................................................................68
Der lange Weg bis zur Zertifizierung! - Flavia Di Laudo
Marketing
Guerilla Marketing.........................................................................................................................................................................................................72
Raffinierte Marketingstrategie oder geschmacklose Werbetreiberei? - Stephanie Höhn
Gestaltung
User Interfaces und Ergonomie...............................................................................................................................................................................74
Mensch und Maschine ‐ Symbiose oder Kampf? - Jaroslaw Zawadzki
Wunsch nach einem neuen Zeichen?....................................................................................................................................................................77
Hier lernen Sie das erfolgreiche Logo kennen! - Zehra Türkkan
Logo kommt nicht von Logik....................................................................................................................................................................................76
Die kritische Auseinandersetzung mit der Entwicklung eines Logos innerhalb des Softwareprojekts - Daniel Wenhardt
Web
Welche Anforderungen sind für einen effektiven High-Fi-Prototypen erforderlich?....................................................................82
Eine Auseinandersetzung - Konstantin Adler
Content managen, aber sicher!................................................................................................................................................................................85
Typo3-Sicherheit für den SOP-Webauftritt - Wilfried Irßlinger
E-Learning im Softwareprojekt...............................................................................................................................................................................88
Sind die Rational-Werkzeuge noch zu retten? - Jochen Budzinski
4
ITERATION++
Das Spiel zum Berufserfolg?
Planspiele in der Wirtschaft
Samet Keser
Für das Studium der Medien- und
Kommunikationsinformatik
(MKI)
an der Hochschule Reutlingen spielt
ein bestimmtes Projekt eine wichtige Rolle – das SOP. Unter praxisnahen
Bedingungen
simulieren
Studenten des 5. und 6. Semesters
die Softwareentwicklung in einem
Systemhaus. Hierbei sollen Motivation,
Leistung und Arbeitsqualität der
Studenten und Mitarbeiter gefördert werden. Auch die Steigerung der
kommunikativen Kompetenz steht bei
diesem Projekt an hoher Stelle. Die
Akteure sollen sich hierbei auf das spätere Berufsleben vorbereiten.
Was genau ist SOP?
Erstmals wurde das SOP (Kürzel
steht für Softwareprojekt) im Wintersemester 2005/06, des erst 2003
entstandenen Studienganges, von
Professor Dr. Wolfgang Keller ins Leben gerufen. Zusammen mit Professor Dr. Uwe Kloos simuliert er auch
die Geschäftsleitung des Projekts.
Bestehend aus drei Firmen, die später vorgestellt werden, ist das Projekt
iterativ aufgebaut. Das heißt Lösungen zu bestehenden oder zu erwarSOP JOURNAL HOCHSCHULE REUTLINGEN R6
tenden Problemen sollen schrittweise, aber zielgerecht angenähert
werden. Der Entwicklungszyklus
eines Produkts (hier eine Langzeitarchivierungssoftware namens „tréstore“) sollte dabei möglichst vollständig aufgebaut sein. Um dem zu
entsprechen, werden die Studenten
des 5. Semesters von ihren Vorgängern des 6. Semester eingearbeitet.
Der Übergang erfolgt anschließend durch eine Abnahme und eine
Betriebseinführung.
Zu den leitenden drei Firmen zählen
die ITer@ Group, ein mittelständisches Softwareentwicklungsunternehmen, welches in sechs Abteilungen
unterteilt ist. Neben dem Projektmanagement, der Softwareentwicklung,
Testing und Qualitätsmanagement,
besteht die Firma auch noch aus jeweils einer Marketing und IT-Management Abteilung. Die Firma trésor Secure Systems, Softwareanbieter
des Produkts „tréstore“, besteht aus
dem Management, dem Marketing
und dem IT-Management. Vor einem
Jahr stieß die dritte Firma ServIT
dazu. Der große Zeitverlust der Server-Neuinstallationen in jedem neuen Semester brachte die Geschäftsleitung dazu, dieses neue Unternehmen
im SOP zu gründen. ServIT ist Be-
treiber und gleichzeitig Anbieter des
Hosting-Service für die einzelnen
Firmen des SOP. Sie besteht aus den
Bereichen des Projektmanagements,
des Marketings und des Softwareund Systemmanagements und wurde
aktuell um eine weitere Abteilung des
Webdesigns erweitert.
Planspiele aus der Praxis
Sei es während der Ausbildung, in der
Schule oder wie in unserem Fall an einer Hochschule: Planspiele werden in
den verschiedensten Bereichen eingesetzt und genutzt. Am meisten verbreitet sind sie bei den betrieblichen
Aus-, Fort- und Weiterbildungen in
den Bereichen Wirtschaft und Politik. Ein erfolgreiches Beispiel ist der
„Deutsche Gründerpreis für Schüler“
(vgl. [1]), das bundesweit größte Existenzgründer-Planspiel für Jugendliche. Dabei soll über vier Monate
hinweg ein Geschäftskonzept entwickelt werden. Das Ganze geschieht,
wie auch im SOP, im Rahmen einer
fiktiven
Unternehmensgründung.
Den Schülern wird nicht nur ein
Einblick in die Anforderungen der
freien Wirtschaft gewährt, das Planspiel zahlt sich wirklich aus und lockt
gleichzeitig mit hohen Geldpreisen.
Hier wird jedoch nicht wie im SOP
ITERATION++
darauf Wert gelegt, miteinander nach
Lösungen für ein bestimmtes Ziel zu
suchen. Die teilnehmenden Firmen
(jeweils zwischen 2-6 Personen) treten viel mehr in einem Konkurrenz-
funktioniert nicht. Nur gemeinsam
in Form von Absprachen, Meetings
und Einholung von Informationen
über das Unternehmen ist Erfolg zu
erwarten – so auch im SOP.
„Kreativität und Selbstständigkeit
fallen nicht vom Himmel, Verhaltensweisen müssen gelernt sein.“
Samet Keser, Marketing
kampf um einen möglichst hohen
Rang an. Ein ähnliches Vorgehen
spielt sich auch bei „Planspiel Börse“
(vgl. [2]) ab. Bereits seit dem Jahre
1983 (mittlerweile auch im europäischen Ausland) dürfen Schüler,
Studenten und auch Auszubildende
jährlich an einem Börsenplanspiel der
deutschen Sparkassen teilnehmen. Es
werden zu Beginn eigene Teams gebildet. Jedem Team wird ein Depot mit
50.000 Euro fiktivem Startkapital zur
Verfügung gestellt. Das Ziel dabei ist,
mit den richtigen Anlagestrategien
so viel Geld wie möglich zu verdienen. Aufgrund der turbulenten Zeiten an der Börse, ist es hierbei nicht
immer einfach, die richtige Strategie
zu finden. Um Börsenerfahrung zu
sammeln und gleichzeitig Teamgeist zu fördern, müssen, wie in der
Wirklichkeit, Streitigkeiten gelöst,
Überzeugungen geleistet und Absprachen eingehalten werden. Alleine
Entscheidungen zu treffen, welche
Aktien verkauft oder gekauft werden,
Was spricht für Planspiele und was
dagegen?
Es leuchtet ein, warum Planspiele
in den betrieblichen Weiterbildungen so beliebt sind. Kreativität und
Selbstständigkeit der Teilnehmer fallen nicht vom Himmel, Verhaltensweisen müssen gelernt sein, die uns
erlauben, selbstständig und kreativ
zu handeln. Ein Planspiel wie das
SOP, liefert dafür bereits gute Ansätze. Sei es die Marketing-Abteilung
(MA), die beispielsweise Kreativität
bei entsprechenden Corporate Identities (vgl. [3]) und Webseiten für
ihre Firmen aufbringen muss, oder
die Projektmanager (PM), die selbstständig für operative Planung und
Steuerung des gesamten Projekts verantwortlich sind. Auch die Förderung von sozialem Umgang (Teamarbeit) spricht für dieses Simulationsverfahren und wird im SOP groß
geschrieben. „Teams scheinen der
Garant für Spitzenleistungen zu sein,
da einerseits Motivation, Leistung
5
und Arbeitsqualität ganz allgemein
steigen sollen, (…)“ (vgl. [4], S. 9).
In den erwähnten Praxisbeispielen
ist die Beurteilung und Bewertung
der einzelnen Teilnehmer durch die
Gruppenarbeit schwierig. Gäbe es
im SOP die sogenannten Reviews
nicht, bei der jeder Teilnehmer seine
geleistete Arbeit präsentiert, wäre es
schwerer zu kontrollieren wer sich im
Endeffekt wirklich bemüht und sich
produktiv an einem solchen Projekt
beteiligt hat. Das SOP ist aber nicht
perfekt, das wohl größte Problem sind
gerade diese organisatorischen Anforderungen, die das Planspiel in ihrer
Durchführung benachteiligen. Vor
allem im sechsten Semester besteht
neben der Bachelor-Thesis ein enormer Zeitdruck. Zu erfüllende Aufgaben werden von den Teilnehmern mit
geringerer Priorität eingestuft und
auf die Schnelle kurz vor den Reviews
erledigt. Da hauptsächlich das eigene
Auftreten, sowie das Präsentieren bewertet werden, bleibt das eigentliche
Engagement für die Simulation gegen
Ende größtenteils auf der Strecke. Es
ist daher auch sinnvoll das SOP auf
den Wochenplan gerecht abzustimmen, um eventuelle Terminkollisionen, wie mit der Bachelor-Thesis, zu
vermeiden. Desweiteren besteht bei
einer zu großen Gruppe die Gefahr,
dass der Lerneffekt sinkt. Ein passendes Beispiel dazu ist aus der aktuellen
SOP-Iteration zu entnehmen. Das
Unternehmen ServIT besteht seit
dem Sommersemester 2009 zusätzlich aus einer Webdesign-Abteilung.
6
ITERATION++
Grund für die Erweiterung war nicht
nur das Präsentieren der Firmen nach
außen hin, durch entsprechend qualifizierte Webdesigner, sondern auch
die stetige Steigerung der teilnehmenden Studenten am Projekt. Die
Webseiten hätten im Grunde auch
von den Marketing-Abteilungen erstellt werden können, so war es anfangs zumindest auch geplant.
ders und wenig mit Planspielprojekten an Hochschulen zu vergleichen,
bieten die meisten Unternehmen, wie
das erwähnte Kreissparkassenprojekt,
lukrative Preisgelder für die Gewinner an. Spielen Spaß und der Reizfaktor des Gewinns eine größere Rolle,
als die Teilnahme und die Sammlung
von Berufserfahrungen?
Zuletzt stellt sich die Frage, wie es mit
Fehlern in Simulationsspielen aussieht. Kann aus diesen ohne wirklich
schmerzende Folgen gelernt werden?
Können daraus Konsequenzen erkannt werden? Zumindest wirkt das
Bachelorprojekt durch die Bewertung
in Notenform und als Pflichtprojekt
im Studium, als eine mehr ernst zunehmende Vor-Berufserfahrung. An-
Quellen
[1] http://www.dgp-schueler.de/toplevel/
[4] Willy Christian Kriz, Brigitta
Nöbauer: Teamkompetenz - Konzepte, Trainingsmethoden, Praxis, 2006
[5] Willy Christian Kriz: Systemkompetenz - Planspiele als Trainingsmethode, 2000
[6] Heinz Klippert: Planspiele - 10
Spielvorlagen zum sozialen, politischen und methodischen lernen in
Gruppen, 2008
[7] Ulrich Blötz: Planspiele in der
beruflichen Bildung, 2002
[2] http://www.planspiel-boerse.com
/toplevel/index.htm
[3]
http://de.wikipedia.org/wiki/
Corporate_identity
»Es gibt drei Möglichkeiten, eine Firma zu ruinieren: mit Frauen, das ist das Angenehmste; mit
Spielen, das ist das Schnellste; mit Computern,
das ist das Sicherste.«
Oswald Dreyer-Eimbcke, Unternehmer
ITERATION++
7
Ein Projektteam lernt die Benutzer kennen
Fiktive Personen in einem Softwareprojekt
Patrick Gaßner
Den Benutzer schon vor dem Entwickeln
einer Anwendung zu kennen ist ein
wichtiger Faktor um gute Software
entwickeln zu können. Schließlich ist
er es, der diese später kaufen soll und
damit arbeiten muss. Deshalb gibt es
in der Softwareentwicklung Methoden,
die auf die Definition der Zielgruppe
und ihre Anforderungen zielen. Eine
dieser Methoden sind fiktive Personen,
sog. Personas. Dieser Artikel verschafft
einen Überblick über dieses mächtige Werkzeug und seine vielfältigen Einsatzbereiche und bewertet die
Eignung im Softwareprojekt-Planspiel
der Hochschule Reutlingen.
„Der 31-jährige Franz ist Personalchef
einer Softwareentwicklungsfirma in
Berlin. Er ist ledig und hat keine Kinder. (…) Sein Auftreten innerhalb des
Unternehmens ist immer sehr professionell und seriös. (…) Auf der Suche
nach neuen Talenten besucht er regelmäßig die Webseiten von zahlreichen
Universitäten und Ausbildungsstellen.“ (vgl. [1])
Was sich auf den ersten Blick wie eine
Personenbeschreibung eines echten
Berliner Personalchefs anhört, ist in
Wirklichkeit die Beschreibung eines
fiktiven Besuchers der SOP-Webseite.
Franz gibt es nicht. Er ist erfunden.
Franz ist ein Beispiel für ein mächtiges
Hilfsmittel in der Softwareentwicklung: die Personas.
wicklern von Software und Benutzerschnittstellen einen wertvollen Einblick in die Sichtweise des Anwenders.
Fiktive Personen in der Informatik
Um die Anforderungen an eine Anwendung genau definieren zu können, muss eine Persona in erster Linie
wirklichkeitsnah sein und die Benutzergruppe möglichst realistisch abbilden. Demzufolge werden sie auf Basis
von Benutzerstudien, z.B. Interviews
oder Umfragen erstellt. Aus den Daten können Benutzergruppen abgeleitet werden, deren Eigenschaften als
Grundlage für die Persona dienen und
durch eigene Ideen der Entwickler
vervollständigt werden.
Personabeschreibungen
beinhalten
Angaben über Name, Geschlecht, Alter, Familienstand, Beruf, Sprach- und
Fachkenntnisse, Interessen, Charakter,
Erfahrung und Probleme im Umgang
mit Computern sowie Erwartungen
und Ziele, die an die Anwendung geknüpft sind. Ergänzende Zitate lassen
sie noch glaubhafter erscheinen (vgl.
[4], S. 72). Solange die eigenen Ideen
nicht den Benutzerdaten widersprechen, sind der Kreativität hierbei keine Grenzen gesetzt.
Der Erfolg von Computerprogrammen hängt neben der Funktionalität
auch von einer benutzerfreundlichen
Bedienung ab. Für die Entwicklung
eines Benutzerkonzepts oder einer Benutzerschnittstelle, die optimal auf die
Bedürfnisse der späteren Nutzer der
Anwendung ausgerichtet sind, muss
dem Entwickler schon vor dem Design der Schnittstellen bewusst sein,
wie der zukünftige Anwender aussehen wird.
Um diese Zielgruppen zu charakterisieren, bedient man sich diverser
Werkzeuge und Methoden, wie Benutzerrollen, Benutzerprofile oder
Marktsegmente. Seit ihrer Einführung
1999 durch Alan Cooper setzt man
bei der Anforderungsanalyse häufig
auch Personas ein (vgl. [2], S. 123 ff.).
Sie beschreiben detailliert den Charakter, die Kenntnisse und Fertigkeiten
der Benutzer und ihre Erwartungen
und Ziele, die sie an eine Anwendung
haben (vgl. [3]). Durch den Einsatz
von Personas gewährt man den Ent-
Grundlagen der Entwicklung einer
Persona
8
ITERATION++
Eine Beschreibung in einem Fließtext
ist wegen ihrer größeren Genauigkeit
einer Stichwortliste vorzuziehen und
soll zur Steigerung des Realitätsgehaltes durch ein Foto einer unbekannten Person ergänzt werden (vgl. [5]).
Dies ist auch bei der Identifizierung
der Persona hilfreich. Je nach Größe
der Projekte sollten zur Abdeckung
eines breiten Benutzerkreises mindestens drei, jedoch maximal sieben
Personas angefertigt werden (vgl. [6]).
Je mehr fiktive Personen existieren,
desto höher ist jedoch die Gefahr,
dass redundante Anforderungen formuliert werden. Daraus resultiert eine
vermeidbare Unübersichtlichkeit. Am
effektivsten ist es, nur so viele zu erstellen, wie die Entwickler sich im
Durchschnitt merken können.
Durch Ordnen nach Prioritätsstufen
wird die Wichtigkeit der Anforderungen ersichtlich und es lässt sich
ablesen, welche Funktionen die Anwendung unbedingt haben muss bzw.
welche wünschenswert oder gar vernachlässigbar sind. Das Anfertigen einer Prioritätenmatrix kann dabei sehr
hilfreich sein (siehe Abb. 1). Hierbei
erhalten die Personas entsprechend
ihrer Priorität eine feste Gewichtung.
Durch Bewertung der Funktionen
Gewichtung
Funktion 1
Funktion 2
Funktion 3
Funktion 4
etc.
Persona 1
50
0
2
-1
1
-
nach ihrer Relevanz (-1 = die Funktion ist für die Persona unwichtig bzw.
sie ist verwirrend, bis 2 = die Persona hält diese Funktion für unbedingt
notwendig) wird klar ersichtlich, welche letztendlich umgesetzt werden
müssen.
„Bei der Beschreibung von Personas sind der Kreativität fast keine
Grenzen gesetzt.“
Patrick Gaßner, Marketing & Redaktion
Die Geburtsstunde im Entwicklungsprozess
Zu welchem Zeitpunkt in einem
Entwicklungsprozess Personas erstellt werden können, zeigen Chang,
Ling und Stolterman in „Personas:
From Theory to Practices“ (vgl. [3])
an drei Modellen auf (siehe Abb. 2):
1. Personas werden direkt nach der
Durchführung von Benutzerstudien erstellt, sodass sie von Anfang an
Einfluss auf die Entwicklungsidee einer Anwendung haben.
2. Studien in [3] haben gezeigt, dass
eine Persona häufig nicht vor dem
Abschluss eines Projektes vollendet
Persona 2
25
1
1
1
1
-
Persona 3
15
2
1
0
1
-
Abb. 1: Prioritätenmatrix für Funktionen einer Anwendung
werden kann. Demnach entsteht
nach den Benutzerstudien eine unfertige Beschreibung, die im Laufe
einer Entwicklung ständig angepasst
wird, bis daraus am Ende eine vollständige Persona resultiert. Dieses
Modell birgt jedoch das Risiko, dass
Summe
55
140
-25
90
-
sich die Entwickler ihre Personas
nach ihren Wünschen zurechtlegen,
was jedoch dem Konzept widerspricht. Um dies zu vermeiden, muss
auf eine klare Trennung zwischen
Entwicklung der Software und der
fiktiven Personen geachtet werden.
3. Falls schon zu Beginn eines Projektes Entwicklungsideen bestehen,
werden Benutzerstudien und Personas erst später fertiggestellt. So kann
eine erste Idee an die Erkenntnisse
aus Befragungen und Personas angepasst werden.
Den einzig besten Zeitpunkt zum
Erstellen von fiktiven Personen in
einem Entwicklungsprozess gibt es
nicht. Je nach Projektart, -umfang
und -dauer eignet sich ein Szenario
besser als das andere. Dennoch stimme ich den Autoren von [3] zu, wonach sie so früh wie irgend möglich
in den Entwicklungsprozess eingebunden werden sollten. Nur so kann
ITERATION++
garantiert werden, dass der spätere
Benutzer der Anwendung im Fokus
der Entwicklung steht.
(1)
(2)
Neben der Softwareentwicklung
wird die Persona-Methode auch immer öfter im Marketing eines Unternehmens angewandt. Dort bilden
sie die Grundlagen für Web- und
Intranetseiten und bieten die Möglichkeit, Design und Inhalt gezielt
auf den Besucher abzustimmen (vgl.
[7]). Dabei können sie sich von
den Personas der Softwareentwicklung sehr unterscheiden. Denn im
Marketing zählt nicht unbedingt
der Benutzer des Programmes zur
Zielgruppe, sondern vielmehr der
Kunde. Zwar können Benutzer und
Kunde identisch sein, meist unterscheiden sie sich jedoch. Steht der
Käufer im Mittelpunkt, so sind etwa
Informationen über seine finanzielle Situation, seinen Lebensstil, oder
sein Kauf- oder Investitionsverhalten
interessant. Auch vollständige Werbekampagnen können mit dieser
Methode geplant werden. Sie helfen
bei der Wahl der geeigneten Werbemedien und Platzierung der Kampagnen.
Vorteile und Risiken
Durch Personas werden die Ziele
und Bedürfnisse der Benutzer oder
Kunden in den Fokus der Entwicklungsarbeiten gerückt. Dies bringt
Vorteile mit sich, birgt aber auch
Risiken.
(3)
Benutzerstudie
Benutzerstudie
Persona
unvollständige
Persona
Personas als fiktive Kunden
9
Entwicklungsidee
Entwicklungsidee
vollständige
Persona
Abb. 2: Entwicklungsmodelle für Personas (vgl. [3])
So steht beim Einsatz der PersonaMethode der Benutzer mit seinen
Zielen und Erwartungen im Zentrum des Entwicklungsprozesses
(vgl. [8]). Der Entwickler fragt sich
nicht, wie er selbst eine Aufgabe lösen würde, sondern wie Franz an die
Aufgabe heranginge. Dadurch erhält
er eine gewisse Distanz zum Projekt:
er entwickelt nicht für sich, sondern
für den Benutzer.
Das Entwicklungsteam kann sich
auf einige wenige „reale“ Charaktere
konzentrieren und muss sich nicht
über Bedürfnisse einer anonymen
Masse von Anwendern Gedanken
machen (vgl. [9]). Es ist ein kostengünstiges Instrument der Zielgruppendefinition und kann schnell und
unkompliziert entwickelt werden
(vgl. [7], S. 2). Entworfene Designs
können jederzeit gegen die Personas
getestet werden. Somit können aufwendige und teure Benutzbarkeitstests reduziert werden.
Die Herausforderung bei der Methode ist das Entwickeln der richtigen Personas. Bei der Auswahl der
Benutzergruppen bedarf es sehr viel
an Überlegung und Sorgfalt. Werden
hierbei Fehler gemacht, besteht die
Gefahr, dass eine Anwendung für jemanden entwickelt wird, der sie später gar nicht nutzen wird.
Da kein Projekt dem anderen gleicht
und darum jedes Projekt auch andere Ziele und Anforderungen an
eine Anwendung stellt, ist von einer Wiederverwendung der fiktiven
Personen abzuraten. Wird hingegen
eine neue Version einer Anwendung
entwickelt, kann durchaus eine Aktualisierung ausreichend sein.
10
ITERATION++
Personas im SOP-Umfeld
Im Softwareprojekt wird die PersonaMethode eingesetzt, um die Benutzer des Produktes tréstore und die
Besucher der Firmen-, Produktund Projektwebseiten zu definieren.
Allerdings haben die Erfahrungen
in diesem Projekt gezeigt, dass aufgrund mangelnden Informationsaustauschs unter den Abteilungen und
Firmen zum Teil redundante Personas erstellt wurden. So entwickelte
die Abteilung Softwareentwicklung
von ITer@ ihre Personas für ihre
Benutzerschnittstellen, während die
Firma trésor diese zeitgleich für die
Produktwebseite von tréstore in Auftrag gab. Beide gehören derselben
Benutzergruppen an und wurden somit doppelt erstellt. Zwar lässt sich
nicht eindeutig sagen, ob der Benutzer der Anwendung tréstore gleich
dem Kunden des Produktes ist, ein
Vergleich der Resultate zeigt jedoch,
dass sich die entwickelten Personen
in ihren Fertigkeiten und Erwartungen sehr ähneln. Je nach Sichtweise sind Benutzer und Kunden in
diesem SOP-Szenario verschieden
oder identisch. Aber wie lässt sich
ein solches Problem vermeiden?
Eine Möglichkeit wäre, beim Start
eines Projektes eine Arbeitsgruppe
aus wenigen Mitarbeitern der Abteilungen zu bilden, die sich später
mit den Personas auseinandersetzen
müssen. Im SOP-Kontext wären die
Abteilungen Projektmanagement,
Softwareentwicklung,
Marketing
und Testing geeignete Mitglieder
dafür. Im Team entscheidet man, ob
Benutzer und Kunde identisch sind
und entwickelt dann Personas. Diese
werden aufgrund der verschiedenen
Ziele der Abteilungen etwas ausführlicher sein, lassen sich dann aber abteilungsweise auf ihre relevanten Daten reduzieren. Dadurch spart man
die doppelte Entwicklungsarbeit
und alle Mitarbeiter sind auf dem
gleichen Kenntnisstand.
Hilfsmittel oder Mehraufwand?
Personas sind keineswegs ein Garant
für den Projekterfolg, sondern lediglich ein Hilfsmittel, das bei richtiger
Verwendung zum erfolgreichen Projektabschluss beitragen kann. Die
Entwicklung erfordert viel Erfahrung, die gerade in einem studentischen Planspiel sehr gut gewonnen
werden kann. Im Softwareprojekt
ermöglicht es den Mitarbeitern ein
Verständnis für die Benutzer und
Kunden zu erlangen, was gerade bei
diesem Planspiel, noch ohne reale
Benutzer und Kunden, umso wichtiger ist.
Ob der zu Beginn vorgestellte Franz
zum Erfolg der SoftwareprojektWebseite beiträgt, wird sich in den
nächsten Monaten zeigen.
Quellen
[1] Persona der SOP-Homepage, Softwareprojekt der Hochschule Reutlingen, Medien- und Kommunikationsinformatik, 2009.
[2] Cooper, A. “The Inmates are running the asylum“; Sams Publishing,
2004.
[3] Chang, Y. & Lim, Y. & Stoltermann, E. „Personas: From Theory to
Practices“; ACM International Conference Proceeding Series, Vol. 358,
ACM Press, New York, 2008.
[4] Herczeg, M. “Software-Ergonomie: Grundlagen der Mensch-Computer-Kommunikation”;
AddisonWesley, 2005.
[5] Aquino, P. & Filgueiras, L. „User
Modeling with Personas“; Proceedings
of the 2005 Latin American conference on Human-computer interaction, ACM Press, New York, 2005
[6] Blomquist, A & Arvola, M. „Personas in Action: Ethnography in an
Interaction Design Team“; Nordic
Conference on Human-Computer Interaction; Vol. 31; 2002.
[7] Calabria, T. „An introduction to
personas and how to create them“;
http://www.steptwo.com.au/files/
kmc_personas.pdf; 27. April 2009.
[8] Pruitt, J. & Grudin, J. “Personas:
Practice and Theory”; Designing for
User Experiences, ACM Press, New
York, 2003.
[9] Seibert, M. “Personas geben Zielgruppen Gesichter”; http://blog.
seibert-media.net/2008/09/arbeitstechniken/personas-geben-zielgruppen-gesichter/; 27. April 2009.
ITERATION++
11
Achtung, Risiko!
Mit der Einführung eines Risikomanagement im SOP zum Erfolg.
Manuela Di Laudo
Risikomanagement ist ein wichtiges
Werkzeug für den Erfolg eines Projekts.
Es hilft uns, Unsicherheiten und
Gefahren zu erkennen, bevor sie zu einem Problem werden. Schade nur, das
Risikomanagement in den wenigsten
Organisationen effektiv eingesetzt wird.
Die Projektmanager versuchen ihre
Projekte zu steuern, ohne deren Status
und Risiken zu kennen. Das führt dazu,
dass jedes vierte IT-Projekt abgebrochen
wird (vgl. [1]). Auch im Softwareprojekt
des MKI-Studiengangs wird bisher noch
kein Risikomanagement betrieben. Da
wir hier aber von einem Planspiel reden, das die reale Wirtschaft simulieren
soll, ist es wichtig das Risikomanagement
einzuführen.
Was steckt hinter Risikomanagement?
Das Ziel des Risikomanagements ist
es, mögliche Probleme zu erkennen
bevor sie auftreten, damit das Projektziel nicht gefährdet wird. Während des gesamten Zeitraums des
Projekts müssen nun Maßnahmen
ergriffen werden, die zur Behandlung
der Risiken beitragen. Mögliche Risikostrategien wären zum einen die
Akzeptanz, bei der das Risiko einfach in Kauf genommen wird. Denn
nicht gegen jedes Risiko muss aktiv
gehandelt werden. Zum Anderen
die Risikoverminderung, bei der die
Eintrittswahrscheinlichkeit reduziert
wird um den eventuellen Schaden
zu begrenzen. Eine weitere Möglichkeit wäre die Vermeidung, bei der die
Eintrittswahrscheinlichkeit auf Null
gesetzt wird. Sie wird hauptsächlich
bei Risiken, die sich durch einen
hohen Schaden kennzeichnen, angewandt. Einige der häufigsten Risiken
sind beispielsweise die unrealistische
Zeit- und Budgetplanung, ständige
Änderung der Anforderungen sowie
unzureichende Ressourcen in der
Mitarbeiterplanung (vgl. [2], S. 35).
Der Autor Barry B. Boehm stellte
schon sehr früh folgende Definition für das Risikomanagement auf:
„Software Risk Management is an
emerging disciplines whose objectives
are to identify, address and eliminate
software risk items before they become either threats to successful software operation or major sources of
software rework.” (vgl. [2], S. 1)
Dieses Zitat passt sehr gut zu unserem Projekt, da die Firma ITer@ auch
Software entwickelt. Hier spielt das
Risikomanagement eine entscheiden-
de Rolle - ganz klar um Zeit und Kosten einzusparen. Denn es dauert länger ein bereits eingetretenes Problem
wieder loszuwerden, als wenn man es
im Voraus eliminiert hätte.
Wie geht man mit Risiken um?
Um Risiken zu beherrschen, muss
man sie kennen. Der Risikomanagementprozess, der die genauen Aufgaben der Risikobehandlung
beschreibt, besteht aus vier Hauptbereichen (siehe Abb. 1). Wie auch
bei anderen Prozessen, sollten für
jeden Schritt Rollen und Verantwortlichkeiten sowie In- und Outputs definiert werden.
Abb. 1: Der Risikomanagementprozess
12
ITERATION++
Als Input bezeichnen wir die erforderlichen Voraussetzungen für einen
Prozessschritt. Das Output ist das Ergebnis daraus und bildet auch gleich
den Input des nächsten Schrittes.
Die Identifikation bildet den Anfang
des Kreislaufs. Eine schnelle und
einfache Art Risiken zu erkennen,
ist die Brainstorming-Technik. Hier
kann jeder Mitarbeiter seine Ideen
mit einbringen. Sobald Risiken identifiziert werden, durchlaufen sie den
Prozess – und zwar jedes Risiko für
sich.
dieser Risikomanagementprozess in
einem sich immer wiederholenden
Kreislauf abgebildet.
Einführung eines Risikomanagements im SOP
Bisher wird noch kein Risikomanagement in unserem Softwareprojekt betrieben. Ich bin in diesem
Projekt als Projektmanagerin tätig
und möchte das Risikomanagement
einführen. Ich finde, dass es sehr
hilfreich und nützlich ist. Zum einen spart man sich eine Menge Zeit,
„Risiken sind nicht immer negativ,
man kann sie auch als Chancen
betrachten.“
Manuela Di Laudo, Projektmanagement
Diese werden dabei analysiert, bewertet, gesteuert und nach ihrer
potenziellen Risikohöhe beurteilt.
Das Ziel der Risikoanalyse ist die
Aufbereitung der Risiken für die
Bewertung. Die Gleichung zur Bewertung des Schadensausmaß lautet:
Risiko = Eintrittswahrscheinlichkeit x Auswirkung. Anhand dieser
Bewertung werden die Risiken nun
unterteilt und deren Strategien festgesetzt.
Die 4 Risikostrategien sind Risikoakzeptanz, -verlagerung -verminderung und -vermeidung. Da im laufenden Projekt immer wieder neue
Risiken auftauchen werden, wird
wenn man schon im Voraus auf
plötzlich auftretende Risiken vorbereitet ist und somit sofort Maßnahmen zur Beseitigung dieser anwenden kann. Zum anderen verhindert
man natürlich unnötige, abrupt auf-
Abb. 2: Rational Unified Process
kommende Kosten, die sich aus den
Risiken ergeben.
Die Einführung des Risikomanagements im SOP wird eine wichtige
Aufgabe der Projektmanager aller
drei Firmen sein. Nachdem man
den Risikomanagementprozess definiert hat, folgt nun ein weiterer
Schritt, um das Risikomanagement
umzusetzen. Wir sprechen von
der Integration des Risikomanagementprozesses in unsere vorhandenen Prozesse. Wir arbeiten im
Softwareprojekt mit dem Vorgehensmodell RUP (Rational Unified
Process). Dieser besteht aus einem
kleinen, sich wiederholenden Wasserfall (siehe Abb. 2). Das zentrale
Produkt im RUP ist die Risikoliste,
in der alle Projektrisiken aufgelistet
werden. Zusätzlich gibt es den Risk
Management Plan, welcher Strategien, Maßnahmen und Verantwortlichkeiten dokumentiert.
Ein großer Kritikpunkt am RUP:
Das Risikomanagement gehört nur
zur Rolle des Projektmanagers und
tritt nur einmalig zur Iterationsplanung auf. Somit wird hier nur eine
ITERATION++
Grundversorgung sichergestellt. Um
dies zu verbessern, sollte man die
Aktivitäten des Risikomanagements
in den regulären Iterationsplan aufnehmen, der den Ablauf weiterer
Iterationen vorgibt. Auf diese Art
werden in Zukunft alle Risiken geregelt identifiziert, analysiert und
verfolgt werden. Außerdem ist hier
noch wichtig, gerade auch weil es
sich um ein iteratives Vorgehensmodell handelt, dass die Risiken mutig
angegangen und nicht in die nächste
Iteration verschoben werden.
„Risikomanagement muss im Projekt ‚gelebt‘ und von der Geschäftsführung ‚vorgelebt‘ werden.“ (vgl.
[3])
Fazit
Wie man sieht ist das Risikomanagement eine notwendige Maßnahme
in unserem Softwareprojekt. Es lässt
sich durch die Anlegung eines Risikokataloges sehr viel Zeit und die
damit verbundene Kosten einspa-
ren. Weiterhin sollten Meilensteine
gelegt werden, wie beispielsweise
eine Aktualisierung und Überarbeitung aller Risiken zu den jeweiligen
Projektreviews. Hier werden dann
neue Ziele festgelegt und mögliche
Änderungen vorgenommen. Außerdem sollte die Kommunikation im
Projekt verbessert werden, denn sie
spielt im Risikomanagementprozess
eine große Rolle. Denn nur wenn
alle Mitarbeiter intensiv mitarbeiten, mögliche Risiken aufspüren
und diese an die Projektmanager
weitergeben, können diese beseitigt
werden. Ein weiterer wichtiger Aspekt ist die iterative Schulung neuer Projektmanager. Dies könnte ich
mir mit Hilfe von Workshops zum
Thema Risikomanagement, jeweils
zu Beginn einer neuen Iteration,
vorstellen. In diesen Workshops
sollte u.a. bisheriges Wissen über die
Risiken transferiert werden. Denn
nur wenn auch jeder Mitarbeiter
und Projektmanager über die Ri-
13
siken informiert ist, kann man gemeinsam gegen sie vorgehen.
Quellen
[1] CHAOS Standish Group 2006
Survey Results – Resolution of Projects, www.standishgroup.com
[2] Boehm, Barry - „Die Top-10-Risiken nach Barry Boehm“, 1989
[3] www.gruenderleitfaden.de
[4] Giebel, Holger – „Risikomanagement junger Unternehmen“, VDM
Verlag Dr. Müller, 2007
[5] Ahrendts, Fabian und Marton,
Anita – „IT-Risikomanagement leben!“, Springer, 2008
[6] Prokein, Oliver – „IT-Risikomanagement“, Gabler, 2008
[Abbildungen] Beide aus „IT-Risikomanagement leben!“ Ahrendts, Fabian und Marton, Anita
»Je höher die Stellung eines Vorgesetzten, desto
mehr Fehler darf er machen, und wenn er nur
noch Fehler macht, dann ist das sein Stil.«
Fred Astaire, Schausspieler
14
ITERATION++
Der Schritt zur Matrix‐Projektorganisation
Oder: „Wie bekommen wir die Mitarbeiter wieder zum Arbeiten?“
Denis Merkle
„Die arbeiten doch nur wieder die
tausendste Neuauflage der Corporate
Identity heraus!“ (Keller, 2009)
Dieser Satz trifft die Iterationen
R5 und R6 im Softwareprojekt
des Studienganges Medien- und
der
Fachhochschule Reutlingen schwer. Der
Hintergrund ist allerdings eindeutig.
Mit mittlerweile drei Firmen ist es für
die einzelnen Mitarbeiter leicht geworden sich in ihren Abteilungen einzuschließen und stur vor sich hinzuarbeiten. Teilprojekte zwischen allen drei
Firmen scheinen nahezu stillzustehen,
solange kein Zeitdruck von außen besteht. Doch wo liegt das Problem und
wie kann man es lösen, um wieder gemeinsame Teilprojekte zu verwirklichen?
Hier ist das Projektmanagement gefragt.
Die Projektorganisationsformen im
Überblick
Bei der Linienprojektorganisation
werden die Projekte in die vorhandene Firmenstruktur übergeben.
Sie stellt daher keine eigenständige
Projektorganisation, welche die Leitung über die Projekte hat, sie umSOP JOURNAL HOCHSCHULE REUTLINGEN R6
Abb. 1: SOP Matrix-Projektorganisation
schichtet, verteilt, überwacht, usw.
dar. Diese Aufgaben werden hierbei
von den einzelnen Team- und Abteilungsleitern übernommen. Für den
Projektmitarbeiter ändert sich im
Vergleich zum Arbeiten ohne Projektbeteiligung nichts, da die Aufgaben
auf seinen normalen Aufgabenbereich
zugeschnitten sind. Genau betrachtet
handelt es sich hierbei deshalb nicht
um eine Projektorganisationsform,
sondern um eine reine Firmenstruktur mit festen Abteilungen (vgl. Corsten, 2000, p. 51ff).
Für kleinere Projekte wird die StabProjektorganisation, auch Stablinienprojektorganisation genannt, benutzt.
Wie der Name schon umschreibt,
wird hier der Linienprojektorganisation ein zusätzlicher „Stab“ hinzugefügt, der die Leitung über die Projekte
übernimmt. Diese Leitung ist jedoch
nur sehr eingeschränkt möglich, da
der Stab keine Weisungsrechte gegen-
über den Mitarbeitern hat und somit
nur eine beratende Person für die Unternehmensführung ist (vgl. Jenny,
2001, p. 106ff).
Die Matrix-Projektorganisation eignet sich dagegen für komplexere und
parallel durchgeführte Projekte. Ihre
Projektleiter haben das Weisungsrecht
gegenüber den Mitarbeitern, auch
wenn diese ihren Firmenabteilungen unterstehen. Die Konflikte, die
zwischen Projekt- und Abteilungsarbeit entstehen müssen dabei von den
Projekt- und Abteilungsleitern angegangen und durch Prioritätensetzung
minimiert werden (vgl. Fricke, Lohse,
1997, p.45ff).
Bei umfangreicheren Projekten wird
meist die Reine-Projektorganisation
eingesetzt. Hierbei werden alle Projektbeteiligten aus ihrem bisherigen
Arbeitsbereich bzw. Unternehmensbereich aus und in einen Projektbereich eingegliedert. Sie sind somit
ITERATION++
ausschließlich für dieses eine Projekt
zuständig, womit der Interessenskonflikt der Matrix-Projektorganisation entfällt (vgl. Corsten, 2000, p.
58ff).
Eine weiterführende Form der ReineProjektorganisation ist die Projektgesellschaft. Diese ist zusätzlich rechtlich vom Basisunternehmen getrennt
und somit kapitalunabhängig (vgl.
Corsten, 2000, p. 95ff).
Die bisherigen Organisationsformen
im Softwareprojekt
Es kann schwer sein, bestehende Projektstrukturen in Unternehmen einer
eindeutigen Projektorganisationsform
zuzuordnen, da sich viele Mischformen
bilden lassen. Deshalb müssen Hauptmerkmale in der bestehenden Struktur
mit den theoretischen verglichen werden, um eine Zuordnung zu treffen.
Am Anfang des Softwareprojektes
stand das Projektmanagement der
Iteration R0 mit einem Unternehmen
vor der schwierigen Aufgabe, die Arbeit
auf die verschiedenen Mitarbeiter aufzuteilen. Da das komplette Softwareprojekt damals innerhalb einer Firma
ablief, konnten Aufgaben ohne großen
Vertragsaufwand von einer Stelle zur
anderen übergeben werden. Die Softwareentwickler, das Marketing etc.
hatten deshalb auch andere Aufgabengebiete als sie die Unternehmensstruktur vorgaben, wenn Ressourcen frei waren. Da im Softwareprojekt das Projektmanagement Weisungsbefugnisse hat,
nahmen die Mitglieder die Rolle der
Unternehmensführung und des Stabes
zugleich ein. Es handelte sich deswegen
um eine Stab-Projektorganisation mit
Stab und Unternehmensführung innerhalb einer Personengruppe.
Mit der Zerschlagung dieses Unternehmens in die jetzigen drei Firmen
Trésor – Secure Systems, ITer@ Group
und ServIT wurde die Organisation
der Projekte erschwert. Jedes Unternehmen hat seinen speziellen Aufgabenbereich, so ist Trésor für den
Vertrieb des Produktes tréstore zuständig, während ITer@ die Software
entwickelt und ServIT Serverdienstleistungen für die Entwicklung und
den Betrieb von tréstore zur Verfügung stellt. Aufgrund dieser engen
Zusammenarbeit wurde ein Konsortium aus allen drei Unternehmen und
der SOP Holding Group gegründet,
welches die Softwareprojektbelange
regelt. Die SOP Holding Group ist
dabei die Dachgesellschaft und vereint
die Geschäftsführer aller drei Firmen
in sich. Die Teilprojekte, wie z.B. die
Redaktion oder Arbeitsgruppen für
Messen wie den „Tag der offenen
Tür“, die hierbei anfallen, sind nicht
einfach durchzuführen und erfordern
den Einsatz aller drei Firmen mit verschiedensten Mitarbeitern. Innerhalb
der Firmen läuft dagegen die Arbeit
abteilungsweise ab. Seit den letzten
beiden Iterationen beschränken sich
deshalb sehr viele Mitarbeiter aller drei
Firmen zu sehr auf ihre Abteilungsarbeit, wodurch die Projektbelange leiden (vgl. Keller, 2009). Die momentane Organisationsform ist aufgrund des
Konsortiums und kleiner Teilprojekt-
15
teams neben den eigentlichen Firmenabteilungen als Matrix-Projektorganisation zu bezeichnen. Dieser Wechsel
von der Stab-Projektorganisation zur
Matrix-Projektorganisation
vollzog
sich nahtlos und ohne aufzufallen.
Eine andere Organisationsform ergibt
momentan meiner Meinung nach
keinen Sinn, da die Stab-Linienorganisation aufgrund ihrer zu stark über
das Projektmanagement laufenden
Kommunikation zu sehr die Arbeitseffizienz einschränkt. Jeder Projektmitarbeiter müsste sich direkt an das
Projektmanagement wenden, was bei
den Teilprojekten im Softwareprojekt
zu viel Zeitaufwand bedeuten würde.
Um eine Reine-Projektorganisation
einzuführen, fehlt es im Softwareprojekt an Mitarbeitern. Diese werden
in dieser Organisationsform exklusiv
für das Projekt verwendet, und stehen
ihren Abteilungen somit nicht mehr
zur Verfügung. Außerdem sind hierzu
die Teilprojekte zu klein und von zu
kurzer Dauer.
Doch wie verbessern wir unsere vorhandene Matrixprojektorganisation,
um eine effizientere Arbeitsweise des
gesamten Softwareprojektes zu erlangen?
Der Entwurf zur verbesserten
Matrix-Projektorganisation im Softwareprojekt
Im Folgenden wird nun näher auf das
Konsortium, die Vergabe und den Abschluss der Teilprojekte eingegangen.
Das Konsortium ist momentan noch
eine Einrichtung ohne vertraglich
16
ITERATION++
festgelegten Hintergrund. An einem
Konsortialvertrag, welcher die Belange
und Rechte des Konsortiums regelt,
wird zurzeit gearbeitet. Sobald dieser
aufgesetzt und unterzeichnet ist, hat
das Projektmanagement im Konsortium rechtlich die Befugnis, Mitarbeiter aller Firmen für Teilprojekte
einzusetzen. Somit sind die Mitarbeiter auch vertraglich an die Bearbeitung der Teilprojekte gebunden und
können sich dieser nicht entziehen.
Eine Skizzierung der Situation zeigt
„Abb. 1: SOP Matrix-Projektorganisation“. Beschlossene Teilprojekte
erhalten einen Teilprojektleiter und
einige Mitarbeiter. Vom Konsortium
die Priorität im Vergleich zu Abteilungsarbeiten innerhalb der Firmen,
der momentane Status, und ein extra
E-Mail-Verteiler. Dieser wird für jedes
Teilprojekt angelegt, um die Kommunikation der Teilprojektmitarbeiter
untereinander zu erleichtern. So muss
man nur einmal in der Liste nach dem
Verteiler schauen, statt alle E-Mail
Adressen der Mitarbeiter herauszufinden. Außerdem wird zur Dokumentenverwaltung in dem Verzeichnis der
Teilprojektliste noch ein Ordner für
jedes Teilprojekt angelegt, welcher in
der Liste verknüpft wird.
Innerhalb der Teilprojekte soll die
Kommunikation zum Teilprojektleiter
„Mit verbesserter Projektorganisation zu höherer Produktivität!“
Denis Merkle, Projektmanagement
werden diese zwei Personengruppen
mündlich oder per E-Mail festgesetzt
und mit Informationen versorgt. Um
diesen Schritt sicherer zu gestalten
und die Teilprojekte zu protokollieren, wird der Ablauf dahingehend
geändert, dass eine Teilprojektliste
für alle Softwareprojektmitarbeiter
einsehbar auf dem BSCW1 verfügbar
ist. Diese Liste wird alle Teilprojekte
mit Mitarbeitern und Teilprojektleitern enthalten. Zusätzliche Informationen sind Beginn- und Enddatum,
1
http://www.bscw.de/ (26.04.2009)
fließen, sodass dieser über alles informiert ist und sich gegebenenfalls mit
dem Konsortium austauscht. Dies vermindert den Kommunikationsaufwand
der Konsortiumsmitglieder. Mit dem
Eskalationsplan, einer Auflistung der
zu gehenden Dienstwege bei Problemen, ist hierzu schon eine Richtlinie
für die Unternehmen vorhanden, welche für Teilprojekte erweitert werden
muss. Die gesamte Kommunikation
innerhalb dieser Teilprojekte läuft über
die E-Mail-Verteiler ab und jedes relevante Dokument wird in den dafür
angelegten Ordnern im Verzeichnis der
Teilprojektliste abgelegt, um jeden Mitarbeiter auf demselben Stand zu halten
und das Teilprojekt von außen einsehbar zu machen.
Den Abschluss eines Teilprojekts muss
der Teilprojektleiter dem Konsortium
mitteilen und einen kurzen Bericht
vorlegen.
Dieser Entwurf setzt auf Software, die
allen Softwareprojektmitarbeitern vertraut ist. Andere Entwürfe wären z.B.
mittels einer extra Groupware aufwändig zu installieren. Mit zusätzlicher
Software würde die Akzeptanz des Konzeptes allerdings stark leiden.
Die Umsetzung wird mit Sicherheit
nicht auf Dauer Bestand haben, da sich
das Projektmanagement auf die sich
häufig ändernden Gegebenheiten einstellen muss. Mit der Zeit werden also
weitere Änderungen einfließen, um die
bestehende
Matrix-Projektorganisation zu verbessern oder sie letztendlich
durch eine andere Organisationsform
zu ersetzen.
Quellen
[1] Keller, W.: Über die schlechte Arbeitsverteilung im SOP, Private Kommunikation, 2009
[2] Jenny, B.: Projektmanagement in der
Wirtschaftsinformatik, vdf, 2001
[3] Corsten, H.: Projektmanagement:
Einführung, Oldenbourg, 2000
[4] Fricke, G., Lohse, G.: Entwicklungsmanagement: Mit methodischer Produktentwicklung zum Unternehmenserfolg, Springer, 1997
ITERATION++
17
Der beste Mann für diesen Job ist eine Frau
Die Herausforderung der Frau im Softwareprojekt
Silke Link
„Der beste Mann für diesen Job ist
eine Frau“ lautet der Titel eines von
Esther Wachs Book verfassten Buches.
Die Autorin und Managerin aus
den USA schreibt darin über die
„Erfolgsgeheimnisse der Spitzenfrauen:
ihre Talente, ihre Fähigkeiten und ihr besonderes Führungswissen.“1 Auch in dem
Planspiel und Bachelor Softwareprojekt
des Studiengangs Medien- und
Kommunikationsinformatik an der
Fachhochschule
Reutlingen,
kurz
SOP, entscheiden sich Frauen immer häufiger für eine Rolle, bei der
Führungsqualitäten gefragt sind. Haben
auch sie Erfolgsgeheimnisse? Mit welchen Eigenschaften können sie überzeugen und das Projekt voranbringen und
vor allem, wie unterscheiden sich ihre
Fähigkeiten im Vergleich zu denen ihrer
männlichen Kollegen? Eine aktuelle und
eigens durchgeführte Umfrage mit einer
Auswahl an weiblichen Führungskräften
der derzeitigen und vergangenen zwei
Iterationen des Projektes stellt die
Grundlage zur Beantwortung dieser
Fragen dar.
1
http://www.amazon.de/beste-Mann-dieseneine-Frau/dp/3720522164/ref=sr_1_1?ie=UTF
8&s=books&qid=1240754995&sr=8-1
Das „Wir-Gefühl“
Persönliches Auftreten und Kommunikation sind zwei der wichtigsten Punkte innerhalb des Softwareprojektes. Sie
werden in den verschiedensten Situationen von den Studenten gefordert und
genau dadurch auch gefördert.
Bei den im Planspiel stattfindenden
Reviews (deutsch: „Rückblick/Besprechung“) kommt es vor allem auf das
Präsentieren von Ergebnissen an. Hier
lässt sich das Auftreten einer Person
besonders gut analysieren und mit anderen Vortragenden vergleichen. Angesprochen darauf, wie Frauen ihre Arbeit und sich selbst präsentieren, gaben
die Befragten - unabhängig davon ob
Projektmanagerin oder Leiterin einer
Abteilung – an, dass Frauen einen sehr
großen Wert auf die Darstellung der
Gruppe und die gemeinsame Arbeit legen. Die männlichen Kollegen wurden
hingegen als Personen beschrieben, die
sich gerne in den Mittelpunkt stellen
und dabei das „Wir-Gefühl“ verlieren
können. Diese von den Studentinnen
getroffenen Aussagen können auch aus
soziologischer Sicht bestätigt werden.
So heißt es, dass in Leistungs- oder
Wettbewerbssituationen soziale Beziehungen für Frauen einen höheren
Stellenwert haben, Männern hingegen
wird eine „singuläre Ausrichtung auf
Leistungsziele“2 nachgesagt. Dieser
Unterschied hängt wiederum mit einer
von den Soziologen Sutherland und
Veroff ausgearbeiteten Rollenerwartung zusammen. Sie besagt, dass die
Gesellschaft von Männern meist Überlegenheit und Stärke und von Frauen
soziale Fähigkeiten erwartet.
Aufgabenorientierung vs. Wettbewerbsorientierung
Die Frage, ob man sich deshalb als
Frau in einer Wettbewerbssituation
vor anderen, insbesondere männlichen, Gruppenmitgliedern beweisen
muss, wurde von allen an der Umfrage beteiligten Frauen jedoch verneint.
Ihrer Meinung nach ist es wichtiger,
die an sich selbst gestellten Erwartungen zu erfüllen und mit der eigenen
Leistung zufrieden zu sein. Frauen
arbeiten für sich selbst, heißt es auch
in der Soziologie. Sie verlassen sich
auf ihre eigenen Standards und haben
demnach eine stark ausgeprägte „Aufgabenorientierung“. Männer hingegen
suchen den Vergleich und erwarten für
ihre Leistung oftmals eine Belohnung.
Man spricht nach Joan Duda hierbei
von einer „Wettbewerbsorientierung“
oder auch „Ich-Orientierung“.
Dorothee Alfermann, „Geschlechterrollen und
geschlechtstypisches Verhalten“, S.100
2
18
ITERATION++
Was bedeutet dies für das Softwareprojekt? Ausgeprägte soziale Eigenschaften wie die zuvor erwähnte GruppenOrientierung der Frau und das damit
verbundene Zurückstellen der eigenen
Leistung in den Hintergrund sind ein
Zeichen von Zusammenhalt. Dies
wirkt sich nicht nur auf die Zusammenarbeit in einer Gruppe positiv
aus. Auch der Druck, dem man sich
in Wettbewerbssituationen oft selbst
aussetzt oder den man durch andere
auferlegt bekommt, lässt sich so verringern. Dennoch muss Druck nicht
immer etwas negatives sein. Oft kann
er in gewissem Maße eine positive
Auswirkung auf den eigenen Ehrgeiz
haben und so zu außerordentlichen
Leistungen führen. Und genau das ist,
egal ob Mann oder Frau, für die Arbeit
im Softwareprojekt wichtig.
sensstand daran teil. Eine gute Kommunikation unter den einzelnen Teilnehmern ist daher besonders wichtig.
Auf die Frage, wie es sich mit der Kommunikation zwischen Männern und
Frauen verhält, wurde mehrfach geantwortet, dass Frauen einen Sachverhalt
ausführlich beschrieben bekommen
wollen, Männer hingegen zum Verständnis meist nur Stichworte benötigen. Dieses Verhalten findet sich laut
Sprachwissenschaftler auch bei den geschlechtsspezifischen Gesprächsstilen
wieder. Während Männer dominant,
sachlich und kompetitiv sprechen,
neigen Frauen zu kommunikativen,
persönlichen und emotionalen Gesprächen. Nach dem Motto „Woman
relate and men report“ (Ruth Wodak,
deutsch: „Frauen erzählen, Männer
berichten“) spricht man laut Wissen-
„Die Gesellschaft erwartet von
Männern Überlegenheit und Stärke,
von Frauen soziale Fähigkeiten“
Silke Link, Projektmanagement
Kommunikation: Frauen erzählen,
Männer berichten
Bei den im Projekt regelmäßig angesetzten Besprechungen liegt der
Schwerpunkt auf dem Diskutieren
von Problemen und dem Ausarbeiten
von Lösungen. Je nach Anlass nehmen
Männer und Frauen aus den verschiedenen Firmen und Abteilungen des
Planspiels mit unterschiedlichem WisSOP JOURNAL HOCHSCHULE REUTLINGEN R6
schaftlerin Deborah Tannens auch von
einer „Berichtssprache“ beim Mann
und einer „Beziehungssprache“ bei der
Frau. Diese Unterschiede können in
Gesprächen zwischen Männern und
Frauen zu Unklarheiten und natürlich
auch im Softwareprojekt zu Missverständnissen zwischen den einzelnen
Teilnehmern führen. Umgehen kann
man dieses Problem nur, indem man
versucht auf den Kommunikationsstil
des Gesprächspartners einzugehen und
sich diesem anzupassen.
Unterschiede können für das Projekt
von Vorteil sein
Dennoch können Kommunikationsunterschiede auch eine positive Auswirkung haben. Glaubt man der Wissenschaft, so stellen Frauen drei Mal häufiger Fragen an ihre Mitmenschen als
Männer es tun. Dies kann nicht nur zu
einem leichteren Verständnis beitragen,
sondern auch neue Fragen aufwerfen
oder einen Sachverhalt, sowohl positiv
als auch negativ, in Frage stellen. Auch
Gesprächsunterbrechungen
müssen
nicht immer als dominantes Verhalten
oder eine Verletzung des Rederechtes
empfunden werden. Sie können ebenfalls
zur Bestätigung einer Aussage eingesetzt
werden oder dem Aufgreifen alter und
Einbringen neuer Fakten dienen. Diese
positiven Beispiele zeigen, wie wichtig
es für den Erfolg eines Projektes ist, dass
Menschen mit unterschiedlichen Arten
der Kommunikation zusammenarbeiten. Dies trifft selbstverständlich auch
auf unser Planspiel zu.
Fazit
Was sind also die Erfolgsgeheimnisse
der Frauen in unserem Projekt? Sicherlich lässt sich diese Frage aufgrund der
vielfältigen Persönlichkeiten der jeweiligen Iterationen nicht allgemein beantworten. Dennoch hat die Umfrage bei
den weiblichen Teilnehmern des Planspiels gezeigt, dass sie Qualitäten haben
und sie sich deren bewusst sind. So sind
ITERATION++
19
es besonders die sozialen Fähigkeiten,
wie das „Wir-Gefühl“ und das aufeinander zugehen bei Problemen, aber
auch die Stärke, bei der Bewältigung
von Aufgaben auf sich selbst zu vertrauen. Diese Eigenschaften setzen
Frauen bei ihrer Arbeit gezielt für den
Erfolg des Projektes ein. Unterschiede
zu den männlichen Kollegen fanden
sich in den Bereichen des Verhaltens
und der Kommunikation zur Genüge.
Und das ist auch gut so…
Quellen
Das Softwareprojekt auf der Informatics Inside
[1] Ruth Ayaß – „Kommunikation
und Geschlecht“, W. Kohlhammer
Verlag, 2008
Reutlingen. Zum ersten Mal in der
Geschichte der Hochschule fand
am 18. März 2009 die „Informatics
Inside ´09“ statt. Hierbei handelt
es sich um eine von den Masterstudenten organisierte Fachkonferenz.
Diese diente unter dem Thema
„Mensch.Maschine.Interaktion“
zum Wissensaustausch zwischen
den Studierenden und Experten
aus Industrie. So referierten die
Masterstudenten über Ihre wissenschaftlichen Arbeiten und stellten
diese zur Diskussion. Höhepunkt
dieser Vorträge war eine Liveübertragung aus China, in der eine Austauschstudentin ihre Arbeit präsentierte.
Zu entdecken gab es auch Informationsstände verschiedener namhafter Firmen wie der Soft- und Hardwarespezialisten Tisoware, iPoint,
der Firmen Innovative Communication Technologies für individuelle Präsentationslösungen (ict) und
IBM.
Auch das Deutsche Forschungszentrum für Künstliche Intelligenz
[2] Friederike Braun, Ursula Pasero (Hg.) - „Kommunikation von
Geschlecht / Communication of
Gender“, Pfaffen-weiler: CentaurusVerl.-Ges., 1997
[3] Dorothee Alfermann - „Geschlechterrollen und geschlechtstypisches Verhalten“, Kohlhammer Verlag, 1996
[4] Herrad Schenk - „Geschlechtsrollenwandel und Sexismus“, Beltz Verlag,
1979
[5] Andrea Suffa, Stefan Suffa – „Typisch Mann, typisch Frau! Die geschlechterspezifischen Verhaltensweisen im Vergleich“, Tectum-Verlag;
Auflage: 1 (Oktober 2006)
[6] Esther Wachs Book - „Der beste
Mann für diesen Job ist eine Frau“,
Sphinx Verlag (2001)
GmbH (DFKI), die Druckunternehmen Raisch und epubli und das
Fraunhofer Institut für Arbeitswirtschaft und Organisation standen
den Tagungsteilnehmern während
der Veranstaltung Rede und Antwort.
Die jetzige Iteration R6 nutze diese Konferenz als Plattform um das
Softwareprojekt nach aussen hin
präsentieren zu können. Dabei
hatte das Softwareprojekt einen eigenen Präsentationsstand, an dem
der aktuelle Stand des Projektes sowie Ziele vorgestellt wurden.
Trotz vieler interessanter Standpräsentationen schafften es die Projektmitarbeiter das Interesse für ihr
Projekt zu wecken.
Für die kommende „Informatics
Inside `10“-Veranstaltungen, die
mit dem 05. Mai 2010 schon terminlich feststeht, darf man sich
wohl aufgrund des Erfolges auf höhere Aussteller- und Besucherzahlen freuen.
-Redaktion
20
ITERATION++
Kostenschätzung im SOP
Neue Methoden zur verbesserten Planung
Dominic Schwörer
Eine Kostenschätzung spielt bei der
Planung von Software-Projekten eine
zentrale Rolle. Sie dient dazu die benötigte Zeit, Ressourcen und Mitarbeiter
zu ermitteln sowie festzustellen was das
Projekt letztendlich kosten wird. Es gibt
viele Methoden zur Kostenschätzung,
vom „übern Daumen gepeilt“ bis hin
zu algorithmischen Berechnungen. In
diesem Artikel werden einige Methoden
aufgezeigt und im Bezug auf das SOP
analysiert.
Warum man eine Kostenschätzung
braucht
Steuern und Planen der Kosten ist
ein wichtiger Punkt für den Erfolg
eines Projektes. Für eine akkurate
Planung ist jedoch eine zuverlässige Kostenschätzung erforderlich, da
man dadurch Informationen über
die genauen Zeit- und Kostenpunkte zu wichtigen Terminen und Abschnitten erhält.
Um die Kosten eines Softwareentwicklungsprojekts abzuschätzen bedarf es viel Wissen und Erfahrung
über das zu entwickelnde Produkt,
den Entwicklungsprozess und die zur
Verfügung stehenden Ressourcen.
Im SOP werden die Anforderungen
über den Entwicklungsprozess im
RUP fest vorgegeben. Die zur Verfügung stehenden Ressourcen ergeben
sich aus der Anzahl der Mitarbeiter
einer Iteration und dem Kostenvertrag mit der Kundenfirma. Das benötigte Wissen und die Erfahrung
stellen ein größeres Problem dar, lediglich die Vorgänger-Iteration fungiert als Ausgleich für das fehlende
Expertenwissen.
Kostenschätzung im SOP
Die Kostenschätzung im SOP setzt
sich zurzeit aus einer Mischung
aus dem Analogie-Verfahren und
dem Parkinson Grundsatz (engl.
Parkinson’s Principle) zusammen.
Das Analogie-Verfahren (vgl. [1],
S. 828) greift beim Prozentsatzverfahren auf früher durchgeführte
Projekte zurück und vergleicht dabei den prozentualen Anteil einzelner Phasen mit dem Gesamtaufwand. Diese Ergebnisse werden
auf das aktuelle Projekt übertragen
und hochgerechnet. Im SOP wird
dies durch die Errechnungen der
früheren Iterationen umgesetzt.
Der Parkinson Grundsatz (vgl. [2],
S. 3) besagt „work expands to fill the
available volume“.
Das wichtigste Merkmal im SOP ist,
dass die meisten Faktoren fest vorgegeben sind wie die Mitarbeiterzahl,
die abzuleistenden Stunden, die zeitliche Länge sowie die Termine der
einzelnen Phasen. Es bedarf also einer
Kostenschätz-Methode, welche die
Verwendung von fest vorgegebenen
Zeiten und Mitarbeiterzahlen zulässt.
Aufgrund der Vorgabe reichen die
simplen Verfahren, wie sie momentan verwendet werden, an sich vollkommen aus. Dennoch könnte eine
genauere Kostenschätzung im SOP
eingesetzt werden um eine Schätzung
der benötigten Gelder für die jeweils
nächste Phase zu erstellen, unabhängig der Gesamtkosten.
COCOMO und Function-Points
Die älteste Methode um die Größe und
dadurch weitergehend die Kosten und
den Zeitbedarf eines Software-Projekts
zu messen besteht darin die „Lines of
Code“ (kurz: LOC) zu schätzen.
„Nach Watts Humphrey (Autor von
The Personal Software Process) sind die
meisten Menschen nicht sehr gut darin, den Zeitaufwand direkt zu schätzen.
Stattdessen kann man aber erstaunlich
genau die Größe des Programmcodes
vorhersagen.“1
Zitat Wikipedia - http://de.wikipedia.org/wiki/
Aufwandssch%C3%A4tzung_(Softwaretechnik)
1
ITERATION++
Durch die Schätzung der LOC könnte man so im SOP auch genauer die
Verbesserungen und Erweiterungen
am Programm steuern, indem man
sie als Anhaltspunkt für die benötigte
Dauer der Programmierung nimmt.
Zwei der bekanntesten und aufwändigeren Kostenschätz-Methoden sind
das COCOMO-, und FunctionPoint-Verfahren.
Das
COCOMO
(Constructive
Cost Model) wurde 1981 von Barry
Boehm (vgl. [3]) vorgestellt. Es ist ein
algorithmisches Model mit dem die
benötigten Personenmonate sowie die
Gesamtdauer des Projektes in Abhängigkeit von Daten aus vergangenen
Projekten und aktuellen Projektcharakteristiken festgelegt werden können (vgl. [4], S. 16).
Der primäre Kostenfaktor bei der
COCOMO-Methode ist die DSI
(Delivered Source Instructions). Die
KDSI (1 KDSI = 1000 DSI) berechnen sich aus den LOC. Es werden
jedoch nur elementare Anweisungen
gezählt, Kommentare und generierter
Code werden ausgeschlossen (vgl. [4],
S. 12).
Weiterhin unterscheidet man 3 Klassen von Projekten (vgl. [4] S. 17, [5]
S. 14):
• Organic Mode
- Kleine Projekte (< 50.000 DSI)
- Stabile Entwicklungsumgebung
- Jeder Mitarbeiter kennt das Projekt
• Semidetached Mode
- Mittelgroße Projekte (zwischen 50.000 und 300.000 DSI)
- Jeder Mitarbeiter besitzt Spezial- wissen bezüglich der Entwicklung
- Das Team ist, was die Erfahrung betrifft, nicht homogen
• Embedded Mode
- Große Projekte (> 300.000 DSI)
- Noch stärkere Arbeitsteilung,
z.B.: nur kleine Anzahl von Analytikern und großes Entwicklerteam
(entnommen aus [4], S. 18)
Anhand einer Formel kann man nun
durch die ermittelte Klasse und die
errechneten DSI die Personenmonate
PM oder Entwicklungszeit D in Monaten errechnen. Durch den Faktor M
können weitere Attribute berücksichtigt werden wie z.B. Zuverlässigkeit,
Komplexität, etc.
Mit der Zeit wurden die Schätzergebnisse jedoch aufgrund neuer Lifecycle
Prozesse, Reengineering, Einführung
der Objektorientierung, etc. zu ungenau und so entwickelte Boehm Ende
der 90er Jahre das COCOMO II Model (vgl. [5] S. 14). Dieses ist vor allem
darauf ausgelegt sich an die Bedürfnisse
und Fähigkeiten des Projekts anzupassen und neue Einflussfaktoren zu berücksichtigen (vgl. [4] S. 30, [5] S. 14).
In COCOMO II existieren wieder 3
Klassen bzw. Submodelle:
• Application Composition Model –
Bei der Entwicklung entstehen keine
wiederverwendbaren Komponenten.
Komplexität des Projekts
Organic
Semidetached
Embedded
21
Die Erstellung ist meist mit Hilfe
von CASE-Tools möglich. Schwierigkeiten, die durch die Verwendung
von Tools auftreten, werden berücksichtigt.
• Early Design Model – Projekte, die
sich in der Prototyp/Analyse-Phase
befinden.
• Post-Architecture Model – Projekte, für die bereits eine fertige Software-Architektur fertiggestellt ist,
die nun implementiert werden muss.
(entnommen aus [5] S. 14)
COCOMO wird meistens im Zusammenhang mit der FunctionPoint-Methode verwendet. Entwickelt wurde die Methode um eine
bessere Alternative zur LOC-Schätzung zu haben, statt nur den Umfang zu messen sollte die Funktionalität berücksichtig werden (vgl. [6],
S. 43).
Anders als bei COCOMO liefert die
Function-Point-Methode nicht den
Aufwand für die einzelnen Phasen
sondern eine Maßzahl für die Größe
des Projekts (vgl. [5], S. 16).
Die Bereiche Eingabedaten, Abfragen, Ausgaben, Datenbestände und
Referenzdaten, werden nach Ermessen des Projektleiters in die Klassen
leicht, mittel und komplex eingeordnet. Diesen Klassen ist eine Anzahl an Function-Points zugewiesen.
Aufwand
PM = 2,4 (KDSI)1,05 M
PM = 3,0 (KDSI)1,12 M
PM = 3,6 (KDSI)1,20 M
Dauer
D = 2,5 (PM)0,38 M
D = 2,5 (PM)0,35 M
D = 2,5 (PM)0,32 M
22
ITERATION++
Anschließend werden noch 14 Einflussfaktoren (z.B.: Geschwindigkeit, Transaktionsrate, Anpassbarkeit, usw.) berücksichtigt und mit
dem Ergebnis verrechnet. Anhand
von Vergangenheitsdaten wurde eine
Tabelle ermittelt in der sich nachschauen lässt mit wie vielen Quellcodezeilen man bei seinem Ergebnis
rechnen muss.
Die COCOMO-Methode würde
sich auf das SOP anwenden lassen.
entwickelt welche „die Vorteile einer
erfahrungsbasierten Kostenschätzung
und der Auswertung von Kennzahlen
aus vergangenen Projekten kombiniert“2.
Anders als bei COCOMO lässt sich
die CoBRA-Methode (Cost Estimation, Benchmarking and Risk Assessment) auch einsetzen wenn nur wenige Messdaten zur Verfügung stehen.
Durch das Expertenwissen aus dem
eigenen Unternehmen werden Beson-
„Die CoBRA-Methode stellt eine
gute Möglichkeit zur Kostenschätzung im SOP dar.“
Dominic Schwörer, Projektmanagement
Man könnte für jede Phase die zu erwartenden Personenmonate errechnen um eine genauere Zeitplanung
zu erstellen und durch die Schätzung
der LOC lässt sich besser voraussagen
wieviel Zeit bestimmte Veränderungen am Programm in Anspruch nehmen. Ob sich die Function-PointMethode auf das SOP beziehen lässt,
erfordert weitere Untersuchungen.
Doch es sollte zumindest eine Hilfe
sein um die Größe für bestimmte Erweiterungen zu schätzen.
Die CoBRA-Methode
Das Frauenhofer-Institut für Experimentelles Software Engineering
(kurz: IESE) hat zur Kosten- und
Risikoschätzung die CoBRA-Methode
derheiten aus dem Unternehmen berücksichtigt und die wichtigsten Kostenfaktoren identifiziert. Zusätzlich
wird ein Kostenmodell aus Kenndaten
abgeschlossener Projekte erstellt.
Die Methode wird nun durch das Tool
CoBRIX unterstützt, in welchem es
möglich ist, das Expertenwissen und
die Kenndaten abgeschlossener Projekte zu verwalten.
„Das Werkzeug formalisiert die meist
subjektiven Kostenschätzungen und
kombiniert diese mit Simulationstechnik, um eine Wahrscheinlichkeitsverteilung der zu erwartenden Kosten
zu berechnen“3.
Zitat Frauenhofer IESE: http://www.
iese.fraunhofer.de/fhg/iese/press/newsletter/
vol0208/02_2008_eGov.jsp
2,3
Für das SOP würde sich diese Methode nicht zuletzt wegen dem Tool eignen, mit dem es möglich wäre, iterativ
die gesammelten Daten einheitlich
weiterzugeben und somit ein Modell
aus Kenndaten abgeschlossener Iterationen innerhalb des SOP zu erstellen.
Das Expertenwissen wird durch die
Vorgänger-Iteration dargestellt, in wie
weit dies zu einer genaueren Schätzung führt, lässt sich nicht genau
nachvollziehen. Es sollte jedoch helfen
die wichtigsten Faktoren zu erkennen.
Dass nur wenige Messdaten benötigt
werden ermöglicht dem Projektmanagement sogar fehlende Informationen über das Projekt auszugleichen.
Fazit
Die Besonderheiten des SOP, vor allem die Vorgaben des Zeitraums und
der Mitarbeiterzahlen, macht die
Kostenschätzung wie sie in der „freien Wirtschaft“ vorkommt leider nicht
möglich. Um die Kostenschätzung zu
verbessern würde sich eine Umstrukturierung der Gehälter und des Budgets im SOP eignen. Wenn man nicht
mit den zurzeit festen Gehältern rechnet und nur ein bestimmtes Budget
besitzt, würde man auch die Kostenschätzung sinnvoller anbringen können. Aber alleine schon die Berechnung der Kosten und besonders der
Personenmonate dürfte zu einer sichtlichen Verbesserung der Planung führen, da es dem Projektmanagement
erlaubt die Arbeitsvorgänge in den
einzelnen Phasen genauer zu planen.
Zu den Methoden lässt sich sagen,
ITERATION++
dass die COCOMO-Methode in
Verbindung mit den Function-Points
eine realisierbare Möglichkeit ist und
zu einer guten Schätzung führen sollte. Jedoch würde ich die Verwendung
der CoBRA-Methode empfehlen,
da sie auch mit wenigen Messdaten
auskommt und auch Besonderheiten
besser berücksichtigt werden können,
was ich im Bezug auf das SOP als
sinnvoll erachte.
Zudem stellt CoBRIX eine Möglichkeit der einheitlichen Datenvererbung
an die Nachfolger-Iterationen dar.
Schlussendlich lässt sich sagen, dass
die hier beschriebenen Methoden sicher zu einer Verbesserung im Kosten- sowie Zeitmanagement führen
sollten. Jedoch lässt es sich durch die
vom SOP bedingten Faktoren nicht
an der „freien Wirtschaft“ spiegeln.
Quellen
[1] Walter Masing, Tilo Pfeifer, Robert
Schmitt: Masing, Handbuch Qualitätsmanagement; 5. Auflage; Hanser
[2] Hareton K.N. Leung: Estimating
Maintenance Effort by Analogy; Volume 7, Number 2; Juni 2002; Springer
23
[5] Holger Gubbels: SAP R/3 – Praxishandbuch
Projektmanagement;
August 2006; Vieweg+Teubner
[6] Henner Diederichs: Komplexitätsreduktion in der Softwareentwicklung
– Ein Systemtheoretischer Ansatz; 1.
Auflage; Februar 2005; Books on Demand Gmbh
[3] Barry W. Boehm: Software Engineering Economics (Prentice-Hall
Advances in Computing Science &
Technology Series); September 1981;
Prentice Hall
[4] Klaus Werdenich: Seminararbeit,
COCOMO – Constructive COst
MOdel; Mai 2002; Universität Salzburg – Institut für Computerwissenschaften
»Im Computer kann man Unmengen von Daten
speichern, die man nicht bräuchte, wenn man
keinen Computer hätte.«
Erhard Blanck, Schriftsteller
24
ITERATION++
Im Kampf gegen das digitale Vergessen
Anforderungen und Strategien an ein Langzeitarchivierungssystem im SOP.
Gerold Lacher
Digitale Dokumente langfristig zur
Verfügung zu stellen, ist ein bislang ungelöstes Problem unserer
Informationsgesellschaft. Daten, die auf
digitalen Datenträgern gespeichert sind,
können in relativ kurzer Zeit nicht mehr
lesbar sein. Das sogenannte „digitale
Vergessen“ ist die Folge. Die Ursachen
für diesen Informationsverlust sind die
begrenzte Haltbarkeit der Trägermedien
und der schnelle Medien‐ und
Systemwandel. Heutige Lösungsansätze
ziehen sog. Langzeitarchivierungssysteme
(kurz: LAS) zur Problemlösung heran, mit deren Hilfe versucht wird,
diese Schranken, durch Kombination
verschiedener Archivierungsstrategien,
zu umgehen. Das Offene Archiv
Informations System (kurz: OAIS) ist
solch ein LAS. Dieser Artikel beschäftigt
sich mit den Strategien hinter diesem
und untersucht die Anforderungen, welche das Softwareprojekt an dieses stellt.
Drei Jahre sind nun schon vergangen,
seit dem das Softwareprojekt im Wintersemester 2006 an den Start ging.
Höchste Zeit also, um die bisher erzielten Ergebnisse im Bereich Langzeitarchivierung einmal genauer zu
betrachten. Alleine das neue Design
des Java- und C#- Clients lässt viel erhoffen, haben diese doch im Laufe der
Iteration R6 ein komplett neues Gesicht, angepasst an die aktuelle Trésor
CI, erhalten.
Zunächst müssen allerdings Anforderungen definiert werden, welche an
ein solches LAS gestellt werden müssen, um Daten auch über einen längeren Zeitraum hinweg effektiv speichern und verwalten zu können.
Das OAIS – Ein Modell für die Langzeitarchivierung nach ISO Norm.
„Dieses Referenzmodell beschreibt
ein Archiv als Organisation, in dem
Menschen und Systeme zusammenwirken,“ (Abbildung 1) „um einer
definierten Nutzerschaft Archivgut
verfügbar zu machen. Die Implementierung eines OAIS-konformen Archivs ist dabei jedoch nicht festgelegt“
[1].
Das Archiv selbst als Kern steht im
Mittelpunkt einer OAIS Umgebung.
Hier werden schließlich sämtliche Dokumente gespeichert und verwaltet.
Das Management sorgt im laufenden
Prozess für die Instandhaltung und
Überwachung des Archives. Desweiteren ist es verantwortlich für die Entwicklung und Implementierung neuer
Archivierungsstrategien. Der Producer
ist, ebenso wie der Consumer, unabhängig von den Entscheidungen des
Managements. Das Archiv ist eine Art
BlackBox, in welche er Daten zur Archivierung laden, wieder abrufen und
bearbeiten kann. Dies muss zu jeder
Zeit gewährleistet sein.
Diese Grundstruktur ist auch im Softwareprojekt (kurz: SOP) wiederzufinden. So dient dem Producer, wie
auch dem Consumer ein bedienungsfreundlicher Client als Schnittstelle
zum Archiv. Dieses liegt auf dem SOP
Server und wird durch das Management, derzeit die ITer@-Softwareabteilung, verwaltet.
SIP, DIP und AIP – Das Problem
mit den Formaten
Abb. 1: Modell einer OAIS-Umgebung
SIP steht für Submission Information
Package. Damit wird diejenige Datei
bezeichnet, welche vom Producer an
das Archiv übergeben wird. Ruft der
ITERATION++
Consumer nun eine Datei aus dem
Archiv ab, so wird ihm diese als sogenanntes Dissemination Information
Package (kurz: DIP), übergeben. Existieren also zwei unterschiedliche Namen für ein und dieselbe Datei? Für
die Antwort hierauf muss man den
zeitlichen Rahmen einer Archivierung,
sowie den damit einhergehenden Medien- und Systemwandel beachten. So
kann es vorkommen, dass eine dem
Archiv vor 10 Jahren als SIP übergebene Datei in einem Format vorlag,
welches im Laufe der Zeit durch ein
anderes abgelöst wurde. So muss das
Archiv dieses, je nach zugrunde liegender Archivierungsstrategie, unter
Umständen in dem nun aktuellen
Format wider als DIP dem Consumer
übergeben. In diesem Fall unterscheiden sich SIP und DIP. Während diese
beiden Packages nun für den Ein- und
Ausgabeprozess verwendet werden,
existiert ein weiteres Package, genannt
Archival Information Package, für die
Speicherung bzw. Ablage im Archiv.
Dieses stellt zugleich das wichtigste
der drei Packages dar und den Brennpunkt an der ganzen Sache.
Denn während sich die Formate, in
welchen das SIP und DIP vorliegen,
Abb. 2: SIP, DIP und AIP [2]
ständig ändern, muss das AIP ein besonders im Hinblick auf den zeitlichen
Gesichtspunkt beständiges Format besitzen.
Das AIP macht Probleme – Auf der
Suche nach dem passenden Format.
Auch im SOP Projekt wurde die Brisanz dieses Themas erkannt und als
Reaktion darauf eine Recherche gestartet, welche es zum Ziel hatte, für
das AIP geeignete Formate ausfindig
zu machen, welche für eine langfristige Archivierung geeignet sind.
25
des älteren beherrscht und umsetzen
kann. Das Resultat hierbei ist der Datenverlust durch Konvertierung.
Während die Recherche im Bereich
Audio- und Video-Formate eher erfolglos blieb, gab es im Bereich des
Text-Formates Erfolge zu vermelden
So ging das von Adobe eigenst für den
Zweck der Archivierung von Dokumenten entwickelte PDF/A Format,
ebenso wie das von Microsoft entwickelte OpenXML Format als sehr
leistungsfähige Formate hervor. Aber
auch das im Open Source Bereich an-
„Ein Format, welches von der Bevölkerung akzeptiert wird, hat meist eine hohe
Chance über einen längeren Zeitraum
hinweg zu existieren“
Gerold Lacher, IT-Management & Redaktion
Diese Formate mussten komplex genug sein, um das Layout bzw. den
Inhalt eines alten Formates 1:1 nachbilden zu können. Desweiteren sollte das neue Format natürlich auch
längere Zeit Bestand haben, da die
einzelnen Schritte einer Migration
(siehe „“Emulation und Migration“)
aufwendig und teuer sind. Ein Format, welches in der Bevölkerung stark
akzeptiert wird, hat meist eine hohe
Chance über einen längeren Zeitraum
hinweg zu existieren, wie man beispielsweise an den Worddateien oder
auch dem PDF-Format sehen kann.
Leider kommt es dennoch oft vor, dass
ein neues Format nicht alle Aspekte
gesiedelte Open Document Format
zeigte Potential. Eine Entscheidung
hierbei ist allerdings noch nicht gefallen, bieten sämtliche Formate doch
ihre Vor- und Nachteile.
Emulation und Migration
Obwohl im Softwareprojekt derzeit
noch die Implementation eines Zwischenformates für die Archivierung
fehlt, das SIP also quasi auch als AIP
zum Einsatz kommt, kann der Consumer für die Ausgabe des DIPs zwischen verschiedenen Ausgabeformaten
wählen. So ist es beispielsweise Möglich, eine als JPEG gespeicherte Datei
in das TIFF Format umwandeln und
26
ITERATION++
ausgeben zu lassen. Die Strategie hinter dieser Methode nennt sich Migration und ist eine der zwei heutzutage
gängigsten Methoden zur Langzeitarchivierung.
Dem gegenüber steht die Emulation,
welche einen komplett anderen Lösungsansatz verfolgt. Anstatt in ständig
neue, in Mode gekommene Formate
zu konvertieren, wird hier versucht, das
ursprüngliche System mittels Software
nachzubilden. Ein Beispiel für eine
funktionierende
Softwareemulation
stellt das Windows Betriebssystem dar.
Mit der jeweils aktuellen Version dieses
Betriebssystems kann man jede frühere
Version emulieren und so Dokumente
und Anwendungen ausführen, welche
das aktuelle Betriebssystem nicht mehr
unterstützt.
Beide Modelle haben ihre Daseinsberechtigung, ziehen aber auch Probleme
mit sich. Für eine Migration spricht vor
allem die relativ gute Realisierbarkeit
und die Unabhängigkeit von Emulatoren. Auch der Verfall von Speichermedien ist ein wichtiger Aspekt, welcher
eher für die Migration spricht, da somit
die Erhaltungskosten für die Zugriffshardware entfällt. Desweiteren kann
mit dieser Archivierungsstrategie besser
auf neu verfügbare Applikationen und
den daraus wachsenden Benutzeranforderungen eingegangen werden.
Für die Emulation spricht vor allem,
dass die Originalobjekte unverändert
bleiben. Probleme mit Datenverlust
existierten hier nicht. Jedoch ist die
Entwicklung eines Emulators sehr Kostenintensiv.
Im SOP Projekt selbst ist noch keine
dieser beiden Strategien richtig implementiert. Zwar ist durch die Möglichkeit der Formatsumwandlung der
Grundstein für eine Migrationsstrategie gelegt, da hierfür jedoch noch
langfristige Formate für die AIPs fehlen, haben diese Umwandlungen bestenfalls Beispielcharakter. Eine Emulation wird bisher nur für die Virtuellen
Maschinen eingesetzt, welche auf den
Servern laufen und die Umgebung für
das Archivierungssystem zur Verfügung stellen.
Quellen
Fazit
[4] Langzeitarchivierung digitaler
Daten: Fortschritt und Überlieferung
Kristian Kloth, Grin Verlag (Klebebindung ‐ Februar 2008)
Wie man sehen kann, so sind die
Anforderungen an ein LAS doch
recht komplex und im Rahmen einer Wirtschaftssimulation, in welcher
die Simulation eines kompletten Firmenkonsortiums im Mittelpunkt des
Interesses steht, nicht über Nacht realisierbar. Dennoch beinhaltet das SOP
Projekt schon grundlegende Ansätze
für die Implementation eines LAS, beispielsweise des in diesem Artikel vorgestellten OAIS. Die Hauptproblematik
hierbei ist allerdings die Umsetzung
einer guten Archivierungsstrategie,
wie die vorgestellte Daten- Migration
und Emulation bzw. eine Kombination aus beiden. Das OAIS selbst gibt
hierfür leider keine explizite Lösung
vor, schließlich handelt es sich hierbei
um ein Referenzmodell eines LAS und
keiner „To-Do-Anleitung“.
[1] Dagmar Ullrich – „Anforderungen
an die Langzeitarchivierung digitaler
Datenbestände“, http:// www.gwdg.
de
[2] Nestor ‐ Kompetenznetzwerk
Langzeitarchivierung
http://www.
langzeitarchivierung.de
[3] Langzeitarchivierung im digitalen
Zeitalter: Speichermedien, Strategien und Ausblicke Dr. Müller, VdM
Verlag (Klebebindung ‐ 15. Oktober
2007)
[5] www.wikipedia.de
[6] www.bka.gv.at: „Open Archival
Information System (OAIS) - Vorstellung“
ITERATION++
27
Ein gutes Gespräch...
Kommunikation im Softwareprojekt
Markus Jülich
Wenn man sich klar ausdrückt und seine Wünsche oder Anforderungen darüber
hinaus in ein Dokument verfasst, dann
kann man sich sicher sein, dass jeder
versteht, was man sagen will. Oder etwa
nicht? Kommunikation ist ein kompliziertes Thema, das auch im studentischen
Softwareprojekt für einige Probleme sorgt.
Jede Form von Verständigung, seien es
Gespräche, E-Mails oder Anforderungsdokumente, ist nur über den Umweg
der Interpretation möglich (vgl. [1]).
Das bedeutet, dass jedes Mal, wenn
wir mit jemandem in irgendeiner Form
kommunizieren, der Empfänger der
Nachricht diese neu interpretiert. Normalerweise ist das Ergebnis dieser Interpretation das, was der Sender ausdrücken wollte. Leider kommt es trotzdem
zu vielen falschen Annahmen. Gerade
im Softwarebereich, wo Informationen
zum Großteil komplex oder abstrakt
sind, ist die häufigste Form der Kommunikation das Missverständnis.
Eindeutig Zweideutig
Während einem Projekt könnte eine
Anforderung an die Softwareentwicklung zum Beispiel so lauten: ‚Jedes Mal,
wenn der Nutzer einen unpassenden
oder falschen Datensatz eingibt, soll
das System eine hervorstechende Warnmeldung ausgeben.‘ Diese Anforderung
mag zwar deutlich strukturiert aussehen
und es ist jedem klar, was erwartet wird.
Aber man überlege sich Folgendes:
Das System soll eine Warnmeldung
ausgeben. Ich soll auch dreimal am Tag
Obst oder Gemüse essen, ich mache es
deswegen trotzdem nicht. Auch wenn
es eindeutig ist, dass das System diese
Warnmeldung auf jeden Fall ausgeben
soll, birgt die schriftliche Sprache hier
Platz für Fehlinterpretation.
Ein weiteres Problem: Was für den einen hervorstechend ist, mag dem anderen vielleicht überhaupt nicht auffallen.
Wenn man diese Information nicht nur
schriftlich in einer Anforderung verpackt, sondern mit den betreffenden
Personen auch noch mündlich klärt,
so wird zumindest das mögliche Missverständnis von sollen und müssen gar
nicht erst auftreten können. Um das
zweite mögliche Missverständnis zu
Umgehen, sollte über die Vorstellungen
des Auftraggebers kurz geredet werden.
Selbstverständlich könnte man sagen,
dass es reichen würde, wenn man die
Anforderung einfach klarer formuliert,
etwa so: ‚Jedes Mal, wenn der Nutzer
einen unpassenden oder falschen Datensatz eingibt, gibt das System eine
Warnmeldung aus, die im Folgenden
beschrieben ist.‘, versehen mit einem
Anhang, der vielleicht eine Grafik und
eine Beschreibung enthält, wie die
Warnmeldung ihre hervorstechende
Wirkung erzielen soll.
Diese Vorgehensweise wäre in einem
Projekt, bei dem alle Parteien weit verstreut sind und keinen persönlichen
Kontakt haben, sicherlich angebracht,
um Fehler zu vermeiden. Im Softwareprojekt hat man aber die Möglichkeit, sich zu treffen und über alles direkt
zu sprechen.
Mündlich oder schriftlich?
Das es wichtig ist, miteinander zu reden,
soll keineswegs heißen, dass schriftliche
Statements schlecht oder überflüssig
sind. Im Gegenteil! In geschriebener,
also lesbarer Form sind Informationen
äußerst hilfreich gegen das Hindernis
des Kurzzeitgedächtnisses, gegen Ablenkungen und Unterbrechungen. Außerdem dienen sie als Erinnerung und
eingeschränkt auch als Beleg. Eingeschränkt deshalb, weil, wie oben gezeigt,
nicht alle Dokumente eindeutig sind.
In den meisten Fällen wäre es am Besten, wenn dem Empfänger der Nachricht die schriftliche Form vorliegt und
man dann direkt miteinander spricht.
Auf diese Weise können nicht nur viele
28
ITERATION++
Missverständnisse von vornherein ausgemerzt werden, sondern man schafft
dabei auch eine Basis für weitere Gespräche. Außerdem lernt der Nachrichtenempfänger etwas über die Kommunikation des Senders und kann dessen
schriftliche Anforderungen besser interpretieren.
Verständnis ist der Schlüssel
Häufige und klare Kommunikation ist
wichtig. Wenn es etwas wichtiges zu
sagen gibt, dann sollte es in einer Weise gesagt werden, dass es auf jeden Fall
jeder versteht. Das heißt, dass die Information nicht nur beiläufig erwähnt
oder mitten in ein großes Dokument
„Die größte Kunst der Kommunikation ist es, zu bemerken, wie viel die
anderen nicht wissen oder verstehen.“
Markus Jülich, IT-Management
Teamzusammenarbeit fördern
„Die Rolle der Teamzusammenarbeit
kann nicht überbetont werden.“ (vgl.
[2], S.10). Es geht hierbei nicht nur
um die Zusammenarbeit innerhalb eines Teams, sondern vielmehr um die
teamübergreifende Arbeit. Diese ist sehr
wichtig, da es die Motivation der Mitarbeiter verbessert, wenn sie nicht nur
strikt an ihrer Aufgabe werkeln, sondern
mehr mitkriegen. Höhere Motivation
resultiert in gesteigerter Produktivität
des Teams. Und nicht nur das, Mitarbeiter, die in verschiedenen Bereichen
Erfahrungen gesammelt haben, sind
viel flexibler einsetzbar und häufig auch
kompetenter, wenn es um neue Probleme geht. Bei großen Softwareprojekten
gilt außerdem, dass durch die teamübergreifende Arbeit ein erhöhtes Verständnis für das gesamte Projekt erzeugt wird.
Je intensiver das Verständnis, desto besser die Kooperation mit dem System.
verpackt werden sollte. Es reicht nicht,
wenn die Empfänger der Nachricht diese hören oder lesen, sondern sie müssen
sie auch verstehen. Nur auf diese Weise
kann sichergestellt werden, dass jeder
Beteiligte auf die Information richtig
reagiert (vgl. [3], S.236).
Das bedeutet, dass wenn eine E-Mail im
Softwareprojekt über den Mailverteiler
an alle geht, in der zum Beispiel eine
Terminänderung für eine wichtige Veranstaltung steht, so sollte dies eigentlich
reichen, wenn die Informationen vollständig sind. Trotzdem ist es Fakt, dass
diese Information besser verstanden
wird, wenn sie noch einmal während
einem Meeting wiederholt wird, da
mündliche Ankündigungen zu wichtigen Themen meist direkter bei den
Empfängern ankommen. In diesem Fall
kann der Verkündende auch sicherstellen, dass alle die Information verstanden
haben, indem er direkt danach fragt.
Zwar sind Studenten wie Schüler dafür
bekannt, auf die Frage: „Haben das alle
verstanden?“, mit Schweigen oder vorsichtigem Nicken zu antworten, trotzdem sorgt die Frage dafür, dass kurz darüber reflektiert wird, was meistens das
angestrebte Ziel zur Folge hat.
Von Angesicht zu Angesicht
Was für Schlüsse ziehen wir also daraus?
Dokumentation ist wichtig, da der Verfasser der Dokumentation nicht immer
für Fragen zur Verfügung steht. E-MailKommunikation ist wegen ihrem erinnernden Wert und der Möglichkeit,
kurzfristig Dateien zu verschicken,
unersetzlich. Trotzdem sollten wichtige Informationen immer auch noch
mündlich erfolgen. Des weiteren sollte
über jede Anforderung, die das Softwareprojekt betrifft, das heißt alles von
Änderungen am Programm bis hin zu
letzten Schliffen am Corporate Design,
von Angesicht zu Angesicht kommuniziert werden, wenn man so wenig
Missverständnisse wie möglich erzielen
möchte.
Quellen
[1] Wittgenstein, Ludwig. Philosophische Untersuchungen. Suhrkamp,
Frankfurt am Main, 1967
[2] Essigkrug, Andreas; Mey, Thomas
– Rational Unified Process Kompakt.
2. Auflage. München: Elsevier GmbH,
2007
[3] Cohn, Mike – Agile Estimating and
Planning. 7. Auflage. Boston: PearsonEducation, 2008
ITERATION++
29
Kommunikation zwischen Unsichtbaren
Lösungsansätze für die Probleme in der internen Unternehmenskommunikation
Fabian Liedtke
Die interne Kommunikation in einem
Unternehmen dient der Aufrechterhaltung
und Gestaltung des Informationsflusses
(vgl. [1]). Eine gut strukturierte interne
Kommunikation ist die Grundlage für
ein erfolgreiches Projektmanagement.
Ohne
einen
ausreichenden
Informationsfluss von „oben“ in Richtung
der Mitarbeiter und umgekehrt von
„unten“ in Richtung des Managements,
kann die Planung und Kontrolle eines
Projekts nicht zufriedenstellend funktionieren. Im Zusammenhang mit den
speziellen Eigenschaften des SOP ergeben sich Probleme in der internen
Kommunikation, die mit denen von internationalen Firmen vergleichbar sind.
In diesem Zusammenhang stellt sich die
Frage, wie internationale Firmen diese
Probleme lösen und inwiefern sich aus
diesen Lösungen Schlüsse für das SOP
ziehen lassen? Wie lässt sich dadurch
eine bessere interne Kommunikation
erreichen?
Die Ausarbeitung konzentriert sich vor
allem auf die asynchrone, also zeitverzögerte Kommunikation. Vorschläge zur
Optimierung von direkten Treffen finden
sich im Fachartikel von Thorsten Hampp
(vgl. [2]).
Der Status Quo
In den Organisationsrichtlinien der
ITer@ Group ist angegeben, welches
Kommunikationsmittel von einem
Mitarbeiter zu welchem Zweck einzusetzen ist. Die Regelungen betreffen
E-Mail-Nachrichten, Instant Messenger, Konferenz und den direkten persönlichen Kontakt. Es gibt eine Syntaxvorschrift für die Betreffzeile von
E-Mail-Nachrichten und durch die
Einrichtung von E-Mail-Verteilern besteht auch eine Infrastruktur für diese
Art der Kommunikation. Die grundlegenden Möglichkeiten für eine reibungslose Kommunikation sind also
gegeben. Allerdings sind diese nicht
ausreichend, wenn man die besondere
Firmenstruktur des SOP betrachtet.
Eine SOP-Firma ist in Abteilungen als
Teams organisiert, die jedoch nicht örtlich oder zeitlich gebunden sind. Somit
gibt es keinen gemeinsamen Arbeitsplatz und keine gemeinsamen Arbeitszeiten. Durch die verstärkte Nutzung
von asynchroner Kommunikation
werden allerdings die Mängel der bisherigen Richtlinien offenbart. Beispiele
hierfür aus dem SOP-Alltag sind, unter
anderem, unsachgemäße Nutzung der
E-Mail-Verteiler und die damit verbundene E-Mail-Flut. Außerdem zeigt
sich, dass Teamleiter und Manager
häufig zu „menschlichen“ E-Mail-Verteilern degradiert werden. Andererseits
kann es auch vorkommen, dass wichtige Informationen überhaupt nicht
übermittelt werden. Die asynchrone
Kommunikation verhindert zudem
ein Projektmanagement im klassischen
Sinn: ein Blick über die Schulter der
Mitarbeiter ist nicht möglich. Vielmehr ist daher entscheidender, dass
die Kommunikation auf allen Ebenen
richtig funktioniert.
In global agierenden, modernen Unternehmen werden als Kernkomponenten
sogenannte virtuelle Teams eingesetzt,
die sich durch den Einsatz von Kommunikationsmitteln zur Überbrückung
von räumlicher und zeitlicher Distanz
definieren (vgl. [3]).
Zu Projektbeginn werden die meisten
Besprechungen im SOP noch auf direktem Wege durchgeführt. Die Vorlesung Softwaretechnik bietet hierfür
den entsprechenden Rahmen. Später
wird die computervermittelte Kommunikation aufgrund von Anreisezeit
und Kostenvermeidung wichtiger. Da
beim SOP zumindest theoretisch auch
die Möglichkeit besteht auf Treffen
vor Ort zurückzugreifen, lässt sich das
SOP also am besten als Hybrid aus den
Unternehmenstypen lokal und virtuell
beschreiben.
30
ITERATION++
Der Status Unbekannt
Die Probleme, die aus der elektronischen
Kommunikation hervorgehen, sind für
SOP-Abteilungen, sowie für virtuelle
Teams besondere Herausforderungen.
Diese gilt es beim Management zusätzlich zu beachten. Aus einer Umfrage
des Instituts für Arbeitspsychologie an
der ETH Zürich geht hervor, dass 59%
der Probleme in der Führung virtueller
Teams auf „Probleme in der Kommunikation […] wie fehlende Informationen
und mangelnder Austausch unter den
Mitarbeitern“ hervorgeht (vgl. [4], Seite 39). Als ein Hauptverursacher dieses
Problems wird die Nutzung von neuen
Medien, wie E-Mail und asynchrone
Datenbanken genannt (vgl. [4], Seite
43). Als negative Aspekte werden unter
anderem identifiziert: „Unangemessene
Nutzung von E-Mails […]“, „Wahre
Information wird im offiziellen Meeting/Datenbank nicht genannt […]“,
„Gefühle, Stimmungen und Probleme
werden nicht vermittelt“, „Entstehen
von Missverständnissen, da keine direkte Nachfrage möglich ist“ und „Unklare
Kommunikationswege,
Missachtung
von Hierarchien, Grenzregulationsprobleme (z.B. gegenüber Kunden)“ (vgl.
[4], Seite 44).
Zu den Problemen in der Nutzung von
modernen Medien bei virtuellen Teams
kommen im Rahmen des SOP noch
spezifische Probleme hinzu. Das Fehlen eines gemeinsamen Arbeitsplatzes
bedeutet hier nicht nur die räumliche
Trennung der Mitarbeiter, sondern auch
eine unterschiedliche technologische
Basis an den verteilten Arbeitsplätzen.
Inkompatibilität von Werkzeugen, wie
Gruppen-Software oder Versionsmanagement zu verschiedenen Systemen,
vermindert deren Nutzen für das SOP.
Ein grundlegendes Problem für die
Abstimmung zwischen Abteilung und
Projektmanagement zeigt sich im SOP
durch den iterativen Charakter. Bei der
Einführung einer neuen Iteration werden die Abteilungen von ihren Vorgängern mit den nötigen Informationen
versorgt. Dadurch entsteht eine stärkere
Bindung an die Teams der VorgängerIteration als an das Projektmanagement.
Dies kann zu verminderter Qualität bis
zum Versiegen des Informationsflusses
an das Management führen.
Lösungen für virtuelle Teams
Laut der Interviewstudie von Christian
Liebig und Hans-Joachim Schütze wird
speziell die Initiierungsphase eines Projekts mit virtuell orientierten Teams als
„Grundsteinlegung für Erfolg oder auch
Misserfolg angesehen.“ (vgl. [5], Seite
86). „Gerade bei Teams, bei denen sich
die Mitglieder anschließend selten oder
nicht mehr sehen, wird diese Phase zur
Erhöhung der Transparenz, Teambuilding inklusive der Rollen und Aufgabenklärung und Einschwören auf das
Projektziel verwendet“ (vgl. [5], Seite
86). Besonders auch die Sozialisation
der Teammitglieder ist eine wichtige Voraussetzung für den Zusammenhalt und
eine gute Verständigung während der
Projektlaufzeit (vgl. [5], Seite 88).
Gleich zu Beginn sollte auch eine Abmachung über die Verwendung von
Kommunikationsmitteln während der
Projektlaufzeit getroffen werden (vgl.
[6]). Dazu gehört auch eine Festlegung
der Hierarchien für die elektronische
Kommunikation. Die Szenarien für die
richtige Wahl der Ansprechpartner bei
verschieden Problemen sollten in einer
Richtlinie festgelegt werden (vgl. [7]).
Spörri, Springall und Grote empfehlen
die Durchführung eines Kommunikations-Workshops zur Schulung der
Mitglieder eines virtuellen Teams und
Entwicklung einer gemeinsamen Kommunikationsstrategie (vgl. [4], Seite 91).
Die Face-to-Face Kommunikation,
also der direkte persönliche Kontakt,
ermöglicht einen schnellen Informationsaustausch (vgl. [8]) und wirkt so
den Missverständnissen, die aus der
computervermittelten Kommunikation
resultieren können, entgegen. Allerdings
erweist sich diese Art des Austausches
aufgrund der damit verbunden Kosten,
wenn überhaupt, nur in der Planungsphase eines Projekts als nützlich (vgl. [4],
Seite 86). Die richtige Auswahl und der
Umgang mit Technologien, die eine virtuelle Umgebung für die Kommunikation schaffen, ist daher notwendig (vgl.
[9]).
Lösungen für das SOP
Die Lösungen für virtuelle Teams zeigen,
dass die Anfangsphase eines Projekts für
den späteren Erfolg entscheidend ist.
Im SOP sind Teile der Anforderungen
an diese Phase aufgrund der anfänglich
stärker ausgeprägten Treffen vor Ort erfüllt. Allerdings wurde bisher von keiner
Iteration zu Beginn eine ausreichende
Kommunikationsstrategie ausgearbei-
ITERATION++
tet. Dies könnte daran liegen, dass die
SOP-Firmen erst im Verlauf des Projekts
zu verstärkt dezentralisierter Kommunikation tendieren. Zumindest sollte
ein Konzept für den Aufbau der Kommunikationshierarchien erarbeitet und
anschließend in den Organisations-
den Umfrage durch die Qualitätssicherung geprüft werden.
Eine Möglichkeit die unterschiedliche
technische Basis der Arbeitsplätze weniger relevant zu machen, ist der Einsatz
von Werkzeugen, die mit den verfügbaren Systemen, wie Email-Programmen
„Vielleicht wäre es sinnvoller, stattdessen einfach die Entwicklung einer
Zeitmaschine in Erwägung zu ziehen.“
Fabian Liedtke, Projektmanagement,
über die Komplexität von Langzeitarchivierungssystemen
richtlinien formuliert werden. Um den
korrekten Umgang mit den verfügbaren
Medien sicherzustellen, kann auf die
Idee eines Kommunikations-Workshops
zurückgegriffen werden. Inhaltlich sollte
geklärt werden wer, wann und mit welchem Mittel, welche Information mit
wem zu kommunizieren hat. Dies würde
auch für das Projektmanagement einen
besseren Einblick in die einzelnen Abteilungen gewährleisten. Als schwierig entpuppt sich allerdings die richtige Wahl
des Zeitpunkts für die Durchführung eines Workshops: Gleich zu Iterationsbeginn oder erst kurz bevor die verstärkte
Nutzung von asynchroner Kommunikation dies erfordert? Aus praktischen
Gründen könnte der Workshop dann in
eine der Mitarbeiterschulungen eingebunden werden.
Die Qualität der Kommunikation kann
durch Metakommunikation, die Kommunikation über die Kommunikation,
zum Beispiel mithilfe einer entsprechen-
und Webbrowsern zusammenarbeiten
(vgl. [8], Seite 116). Es sollte daher
untersucht werden, inwiefern sich die
Möglichkeiten des verwendeten Servers
dafür eignen und ob diese bei Bedarf
erweitert werden könnten. Ein interessanter Ansatz bietet hierfür der Einsatz
von Wikis oder Blogs für die interne
Unternehmenskommunikation.
Die
Einsetzbarkeit für das SOP sollte durch
zukünftige Recherche geprüft werden
(Einstiegsliteratur [10], [11]).
Quellen
[1] Meier, P.: Interne Kommunikation im
Unternehmen: von der Hauszeitung bis
zum Intranet, Zürich: Orell Füssli, 2002
[2] Hampp, T.: Prozessoptimierte Meetings durch professionelle Moderation,
Gibt es Moderationskonzepte für Meetings innerhalb des Softwareprojektes?,
SOP Journal Hochschule Reutlingen R5,
ITERATION++, Reutlingen 2009
31
[3] Lipnack, J., Stamps, J.: Virtuelle
Teams. Projekte ohne Grenzen, Wien:
Ueberreuter, 1998
[4] Spörri, M., Springall, L., Grote, G.:
Führung und Kommunikation in virtuellen Teams der IT-Branche - Projekt Telemanagement, ETH Zürich, 2003
[5] Liebig, C., Schütze, H-J.: Virtuelle
Projektteams. Projektverlauf und Kommunikation in räumlich verteilten Strukturen,
Mannheimer Beiträge zur Wirtschaftsund Organisationspsychologie 3, 2001
[6] Lipnack, J., Stamps, J.: Virtual Teams:
Reaching Across Space, Time, and Organizations with Technology. John Wiley &
Sons, New York, 1997
[7] Casey, V., Richardson, I.: Uncovering
the reality within virtual software teams,
Proceedings of the 2006 international
Workshop on Global Software Development For the Practitioner, China, 2006
[8] Dennis, A., Valacich, J.: Rethinking
Media Richness: Towards a Theory of
Media Synchronicity, Proceedings of the
32nd Hawaii International Conference
on System Sciences, Hawaii, 1999
[9] Nunamaker, J. F., Reinig, B. A.,
Briggs, R. O.: Principles for effective virtual teamwork, Communications of the
ACM 52, 4, 2009
[10] Fleck, M., Kirchhoff, L., Meckel,
M., Stanoevska-Slabeva, K.: Einsatzmöglichkeiten von Blogs in der Unternehmenskommunikation, Bauer H. H.,
Röster, J. (Hrsg.): Interactive Marketing
im Web 2.0+, München, Vahlen, 2007
[11] Gutwirth, A.: Trendforschung - Einsatzpotential für Blogs und/oder Wikis in
virtuellen Gemeinschaften, GRIN Verlag, 2007
32
ITERATION++
Virtuelle Serverlandschaft
Die Vorteile eines Servers mit VMware ESX
Christian Kubat
Dieser Artikel gibt einen Überblick
speziell über den VMware ESX Server
Hypervisor geben, der auch auf unserem SOP Server zum Einsatz kommt.
Er hat wichtige Funktionen die sehr
hilfreich sein können und uns hilft
den physikalischen Server optimal zu
nutzen und auch Kosten und Zeit zu
sparen.
Aber was genau bedeutet Hypervisor
und was ist so besonders am VMware
ESX Server? Wie unterscheidet es sich
von anderen Virtualisierungssoftware?
Wie kommt diese Software beim
Softwareprojekt zum Einsatz?
dass die ESX Server Software direkt
auf den physikalischen Server installiert wird, also hardwarenah, ohne
vorher noch ein Host-Betriebssystem
installieren zu müssen. Es gehört also
zu den Typ-1-VMM. Konventionelle Virtualisierungssoftware wie z.B.
Virtual PC oder VirtualBox gehört
zum Typ-2-VMM. Das macht den
ESX Server sehr leistungsstark, denn
aus diesem Grund verbraucht es nur
ca. 32 MB auf der Festplatte. Typ2-VMM verbrauchen sehr schnell
mehrere Gigabyte, gerade wegen dem
Betriebssystem auf dem sie laufen.
Das Herzstück des ESX Server ist
der VMkernel. Vereinfacht gesagt ist
es eine Art Mini-Betriebssystem. Es
verwaltet und teilt die Ressourcen
Hypervisor
Ein Hypervisor übernimmt die Steuerung der Ressourcenzuteilung zu
den einzelnen virtuellen Maschinen
und wird auch Virtual Machine Monitor (VMM) genannt. Es existieren
zwei Arten von VMM. Ein Typ-1VMM läuft direkt auf der Hardware.
Ein Typ-2-VMM setzt auf ein laufendes Betriebssystem auf. (vgl. [1],
Seite 2)
VMware ESX Server ist ein „BareMetal“ Hypervisor. Dies bedeutet,
Abb. 1: konventionelle Virtualisierungssoftware (Typ-2-VMM)
Was ist Virtualisierung?
Durch Virtualisierung kann einen einziger physischer Server
mehrere virtuelle Maschinen
gleichzeitig ausführen.
der physischen Hardware auf und
simuliert mehrere Kopien von virtueller Hardware für die virtuellen Maschinen. So kann man z.B. Windows
und Linux parallel und vollständig
voneinander isoliert betreiben.
Features
VMware ESX Server hat die Möglichkeit der Mehrfachvergabe von
Arbeitsspeicher. Das bedeutet, dass
der zugewiesene Arbeitsspeicher der
gesamten virtuellen Maschinen größer sein kann als die tatsächliche
physikalische Speichergröße des Servers. Damit kann der Arbeitsspeicher
effizienter ausgelastet werden. Wenn
z.B. ein Server mit 8 GB Arbeitsspeicher ausgerüstet ist, können alle
virtuellen Maschinen zusammen bis
zu 16 GB betragen. Dadurch kann
man den Arbeitsspeicher effizienter
auslasten. (vgl. [2] und [3] Seite 49)
Weiterhin besteht die Möglichkeit
dem Gast-Systemen bis zu 4 Prozessoren zuweisen zu können. Wie
auch beim Arbeitsspeicher können
ITERATION++
Abb. 2: VMware ESX Server (Typ-1VMM)
die zugewiesenen CPUs aller GastBetriebssysteme die tatsächliche Anzahl der physikalischen CPUs übersteigen. (vgl. [2] und [3], Seite 48)
ESX Server besitzt eine umfangreiche
Gast-Betriebssystemunterstützung,
Es können alle Windows Versionen,
angefangen von Win 95 bis Vista
und deren Servervarianten, installiert
werden. Selbst alle in der Serverwelt
gebräuchlichen Linux, Netware oder
Solaris Versionen werden unterstützt.
Somit hat man die maximale Flexibilität bei der Wahl des Betriebssystems.
Als letztes wäre da noch das ausgefeilte Ressourcenmanagement des
ESX Servers zu erwähnen. Es ist
Traffic Shaping implementiert. Das
bedeutet, es werden die Datenströme
der Netzwerkkarten und Festplatten
überwacht, sodass alle virtuellen Maschinen immer über die benötigte
Bandbreite verfügen. (vgl. [2])
Remote Konsole
Gesteuert, überwacht und konfiguriert werden die virtuellen Maschi-
nen mit der sogenannten Remote
Konsole. Es gibt 2 Versionen der Remote Konsole.
1. Webbasierte Remote Konsole:
Man öffnet die Hauptseite des ESX
Servers in dem man die IP-Adresse
seines physikalischen Servers eingibt
und mit einem Klick die webbasierte
Version startet
2. Installierbare Version:
Man lädt sich die Remote Konsole direkt von der oben genannten
Hauptseite runter und installiert es
auf seinen Rechner.
Vollen Zugriff auf alle Funktionen
hat man allerdings nur mit der installierbaren Version. Die webbasierte
Version dient in erster Linie nur dazu
um zu schauen ob noch alle VMs
ordnungsgemäß laufen.
Der Vorteil dieser Konsolen ist, man
kann von überall die Server administrieren und ist somit Standortunabhängig. Außerhalb des FH-Netzwerkes funktioniert das aber nur mit der
VPN-Verbindung. So kann man im
Notfall auch mal einen Fehler von
zu Hause beheben, ohne gleich zum
Standort des Servers fahren zu müssen. (vgl. [4])
33
hilfreich wenn man mehrere Server
einrichten muss, wie es im Softwareprojekt bald der Fall sein wird.
Man richtet eine virtuelle Maschine
ein, installiert und konfiguriert das
Betriebssystem sowie alle benötigten
Tools. Anschließen kann man diese
virtuelle Maschine beliebig oft klonen und spart so eine Menge Zeit.
(vgl. [2])
Nachteile und Einschränkungen
Dieses System hat viele Vorzüge,
doch hat es auch einige Nachteile.
„Single Point of Failure – Fällt der
Virtualisierungshost aus, dann laufen
gleich mehrere virtuelle Server und
Dienste nicht mehr. Durch mehrere
physische Server und Ausfallkonzepte wie Clustering und Redundanz
muss dieser Punkt in kritischen Umgebungen besonders abgesichert werden.“ (vgl. [3])
Da unsere Server im SOP-Projekt
nicht 24 Stunden und 7 Tage die
Woche benutzt werden und somit
die meiste Zeit im Leerlauf sind, ist
ein Ausfall nicht weiter kritisch.
Migration und Klonen von virtuellen Maschinen
VMware ESX Server ist in der Lage
virtuelle Maschinen von einem physikalischem Server (Host) zur Laufzeit auf einen anderen zu transferieren. Eine noch wichtigere Funktion
ist jedoch die virtuellen Maschinen
zu klonen. Diese Funktion ist sehr
Abb. 3: Quelle: VMware
34
ITERATION++
Die Server für die Webseiten werden
allerdings auf anderen physischen
Servern installiert und betrieben,
denn im Gegensatz zu den SOP-Servern müssen die Server für die Webseiten eine höhere Zuverlässigkeit
aufweisen.
Ein weiterer Nachteil ist die emulierte
Grafikkarte. Mit ihr ist meistens die
Grafikbeschleunigung eingeschränkt.
Aus diesem Grund kann man Spiele,
Videos und CAD-Anwendungen nur
bedingt oder gar nicht benutzen.
Doch dafür werden Server normalerweise auch gar nicht benutzt. Auch
im Softwareprojekt werden Grafikintensive Programme nicht verwendet.
Server möchte ich kurz Vorstellen.
Server Eins: Windows Server 2003
Hier sind alle IBM Rational Tools,
sowie Typo3, der Apache Server, die
Zeiterfassung, Votingsystem und
Wiki installiert.
Wie man sieht ist das der wichtigste
Server, da auf ihm alle Programme
für das SOP-Projekt laufen.
Server Zwei: Linuxserver
Das ist unserer Mailserver auf dem
alle Verteilerlisten gespeichert sind
und verwaltet werden.
Mit der Remotedesktopverbindung
von Microsoft kann auf die Server
zugegriffen werden und von jedem
Rechner aus gewartet werden.
Zusammengefasst kann man sagen, dass VMware ESX sehr sinnvolle Funktionen besitzt und sehr
Leistungsstark und stabil ist. Dank
virtueller Maschinen und der Klonenfunktion spart man viel Zeit,
Geld und Energie. Anstelle von zwei
physikalischen Servern, die im Softwareprojekt nie komplett ausgelastet
würden, verwenden wir nur einen
physikalischen Server und virtualisiert die beiden Server.
„Virtuelle Maschinen: Eine Möglichkeit seine Server kostengünstig
zu vermehren.“
[2] http://www.vmware.com/de/products/vi/esx Stand: 20.05.2009
Christian Kubat, Software- und Systemmanagement
Somit ist dieser Nachteil nicht relevant. (vgl. [3], Seite 28, 29)
Die Server
Für das Softwareprojekt steht momentan (Stand: April 09) einen physikalischen Server von IBM mit der
Bezeichnung IBM System x3550 mit
einem Dualcore Intel Xeon 5130 2x
2,0 GHz und 6 GB Arbeitsspeicher
zur Verfügung. Auf diesem Server
laufen zwei virtuelle Maschinen die
mit dem vorgestellen ESX-Server erstellt wurden. Diese zwei virtuellen
Ausblick und Fazit
In nächster Zeit wird die Serverkonfiguration aber komplett geändert. Für
die Webseiten der Firmen und des
Softwareprojektes ist ein Webserver,
Testserver und Entwicklungsserver
nötig. Da der Webserver aus dem Internet erreichbar sein muss, können
wir unseren jetzigen Server aus Sicherheitsgründen nicht verwenden.
Doch dank der Klonenfunktion des
ESX Servers ist die Erstellung nicht
sehr Zeitaufwändig.
Quellen
[1] IBM System Virtualization, IBM
Corporation, Version 2 Release 1
(2005) Description of basic concepts
Link: publib.boulder.ibm.com
[3]Sven Ahnert: Virtuelle Maschinen
mit VMware und Microsoft, Addison-Wesley, München; Auflage: 2.,
aktualisierte Auflage (19. November
2007)
[4] Artikel auf tecchannel.de von Jürgen Donauer: Workshop-VMware
ESX Server
ITERATION++
35
LDAP und Typo3, passt das wirklich?
LDAP-Anbindung für jeden Projektteilnehmer
Dennis Riekert
Kann LDAP in unserem Projekt eingesetzt werden und ist es vor allem
sinnvoll diesen Schritt durchzuführen?
Derzeit gibt es keine Möglichkeit das
Passwort ohne direkten Serverzugriff
im SOP-Projekt zu verändern. Jedes
Programm benötigt in der Regel
eine Authentifizierung, das wiederum bringt eine Zugangsdatenflut für
den Benutzer mit sich. Um solch eine
Problematik zu vermeiden, wurde hierfür im Softwareprojekt das LDAP von
Windows verwendet. Können wir im
SOP-Projekt mit dem Typo3-System
diesen komplexen und unkomfortablen
Weg deutlich vereinfachen?
Ist eine webbasierte Benutzerverwaltung das zeitgemäße Werkzeug?
Immer mehr Firmen greifen auf verschiedene LDAP-Systeme zurück,
selbst die Daimler AG, eines der
größten Unternehmen im europäischen Raum, hat sich ein eigenes
Intranet-Portal mit LDAP-Authentifizierung geschaffen. Durch die große
Mitarbeiterzahl kann dieser Prozess
einiges an Personal bzw. Arbeitsaufwand für jeden Einzelnen einsparen.
Derzeit wäre der personelle Aufwand
im Projekt für die Passwortverwaltung bei Benutzern und Administratoren um einiges höher als mit einer
LDAP-Anbindung. Diese Zeit fehlt
bei der Entwicklung des Langzeitarchivierungssystems.
Im SOP-Projekt verwenden wir für
die Verwaltung von Zeiten, Wissensverteilung, Informationsaustausch,
technischen Problemen, Anfragen
und Anforderungen unterschiedliche
Tools. Jedoch sind das Einzelsysteme, die wiederum nicht miteinander kompatibel sind. Bei den verschiedenen Themen handelt es sich
um vertrauliche Informationen, die
durch einen Passwortschutz gesichert
werden. Einzelsysteme sind aber im
Verhältnis zu Komplettsystemen
kostspielig und entwicklungsintensiv,
deshalb verwenden wir unterschiedliche Systeme. Durch die Zusammenlegung von einer Passwortverwaltung
wie das LDAP, versprechen wir, dass
aufwendig geführte Passwortlisten auf
der Benutzerseite entfallen. Durch
die Vielzahl der Passwörter, verwenden viele Benutzer Passwortlisten,
um den Überblick über die Passwörter zu behalten. Das Notieren dieser
vertraulichen Daten ist immer ein
Risiko. Mit dem Einsatz von LDAP
brauchen die Mitarbeiter nur noch
ein Passwort. Das spart viel Zeit bei
dem Verwalten der Passwörter. Auch
die Administratoren müssen nur
noch ein Passwort zurücksetzen. Um
jetzt noch den Kostenfaktor für das
Zurücksetzen von Passwörtern durch
einen Administrator zu minimieren,
kommt der Einsatz der Webplattform
Typo3 ins Spiel.
Über die LDAP-Funktion können
Windows-Passwörter, Login-Daten
und weitere Einstellungen vorgenommen werden. Webanwendungen
wie Typo3 können direkt über einen
Browser von verschiedenen Betriebssystemen dargestellt bzw. ausgeführt
werden. Also benötigt der Benutzer
kein zusätzliches Programm und ist
in der Lage über jeden PC die Seite
abzurufen. Es eignet sich ebenfalls
in unserem Projekt, da viele Mitarbeiter auf ihren Privat-PCs nicht nur
Microsoft-Betriebssysteme verwenden.
Benutzerverwaltung mit Typo3
In den letzten Jahren wurden
Webapplikationen immer interessanter. (vgl. [1], S. 82) Mittlerweile
hat sich die Idee von den führenden
Softwareherstellern
durchgesetzt,
36
ITERATION++
dass sie ihre Programme über die Internetplattformen zur Verfügung stellen. Zum Beispiel bietet Microsoft
Outlook die Software auch als Internetanwendung an. Die Aufgaben
können die Benutzer von jedem PC
mit der gewohnten Umgebung bearbeiten. Durch die hohe Flexibilität
haben die Hersteller ein großes Potenzial entdeckt und werden sich immer mehr auf die Plattform Internet
spezialisieren.
Über Typo3 werden wir unsere Firmenwebseiten publizieren. Es ist ein
sehr weitverbreitetes Open-SourceSystem. Das Open-Source-System
Typo3 steht den Kommerziellen in
nichts nach, aber im Gegensatz dazu
ist es gratis (vgl. [2], S. 23)]. Es wird
im Folgenden die Begründung für die
Verwendung des Typo3-Systems geliefert. Desweiteren sind die kompletten
Webseiten der FH mit dem Typo3 erstellt worden. Das Wichtigste ist, dass
auch das Wissen direkt über Hochschulmitglieder erfragt werden kann.
Ebenso können ohne externe Hilfen
Problemstellungen schneller gelöst
werden. Die Verwaltung soll im Detail so aussehen, dass die Benutzer ihre
kompletten Daten einsehen bzw. direkt über die Typo3-Homepage ändern
können. Um das System mit LDAP zu
verbinden benötigen wir eine spezielle Schnittstelle zu dem LDAP-Server,
der später die Daten der Benutzer verwaltet. Ein wesentlicher Faktor sollte
aber der Datenschutz sein, denn die
Passwörter der Benutzer dürfen auf
keinen Fall Plaintext (unverschlüsselt)
an den Server übertragen werden. Das
bedeutet, dass das Passwort komplett
mit wenigen Handgriffen ausgelesen
werden kann. Bei einer Verschlüsselung wird jedes Zeichen mit einem bestimmten Schlüssel umgeändert. Erst
über komplizierte Verfahren lässt sich
das Passwort ausspähen. Eine wichtige
Voraussetzung ist SSL (Secure Sockets
Layer, ein Verschlüsselungsprotokoll),
dieses Protokoll soll die Daten verschlüsselt übertragen.
Die Erweiterungen (Extensions) müssen auf Sicherheit und Datenschutz
geprüft werden, denn es könnten
eventuelle Sicherheitslücken enthalten
sein.
gestellt ist es in Wirklichkeit nicht,
denn die Erweiterungen haben meist
eigenwillige Installationsverfahren.
Dies wird auch im zweiten Buch (vgl.
[4], S. 525) deutlicher dargestellt.
Da es keine speziellen Richtlinien für
die Erweiterungen gibt, kann jeder
eine solche Erweiterung nach seinen
Vorstellungen entwickeln und in die
Typo3-Webseite einbinden (vgl. [5]).
Teilweise sind auch die mitgelieferten
Handbücher sehr kurz und unverständlich ausgeführt. Wir konnten
die Erweiterung „EU-LDAP“ nicht
ohne Expertenrat und Buchhilfen installieren.
„Webbasierende Anwendungen sind die
Themen von morgen, die Informationen
sollten wir uns schon heute besorgen.“
Dennis Riekert, Software- und Systemmanagement
Daraus resultiert die Frage: Typo3
und LDAP, passt das? Ja, sehr wohl.
Denn es gibt für Typo3 spezielle Erweiterungen. Die LDAP-Anbindung,
steht als Erweiterung auf der Typo3Webseite kostenlos zum Download
zur Verfügung. Typo3 ist modular
aufgebaut. Die Erweiterungen lassen sich per Knopfdruck installieren,
updaten und deinstallieren (vgl. [3],
S. 43). Das soll heißen, die Module
lassen sich recht leicht in das vorhandene System einbinden lassen.
Jedoch so einfach wie im Buch dar-
Typo3-Extensions
Bei unserer Recherche konnten wir 3
engere Erweiterungen für unsere Anforderungen ausfindig machen. Zum
einen wäre das „EU_LDAP“ (vgl.
[5]). Dieses Tool findet derzeit auch
im Infweb (Homepage der Fakultät
Informatik www.inf.reutlingen-university.de) seinen Einsatz. EU_LDAP
ist sehr einfach aufgebaut und kann
für Frontend (Websitelogin) und
auch für Backend (Typo3-Administrationstool) eingerichtet werden.
Einwandfrei ist die Verschlüsselung
ITERATION++
der Passwörter jedoch noch nicht.
Aus Sicht der Firma ServIT sollte der
Datenschutz in dieser Hinsicht nicht
außer acht gelassen werden. Sollte
es dennoch in unserem Projekt zum
Einsatz kommen, müsste es so angepasst werden, dass die Sicherheitslücken geschlossen werden.
Die nächste Erweiterung namens
„ccsvauthdemo“(vgl. [5]) ist nur ein
PHP-Skript und besitzt im Vergleich
zu EU_LDAP kein bedienbares Interface. Ohne weitere Programmierkenntnisse lässt sich diese Erweiterung nicht installieren. Die Webseite
der Hochschule Reutlingen wurde
mit dieser Erweiterung ausgestattet.
Da zu diesem Thema ein Grundwissen in der Hochschule vorliegt,
kommt dieses Tool ebenfalls in die engere Auswahl. Die Authentifizierung
erfolgt genau wie bei EU_LDAP über
die newloginbox (vgl. [5,6]) (Anmelde-Extension). Die eigentliche Authentifizierung erfolgt über cc_sv_
auth (vgl. [5,6]). Die Erweiterung
ist mittlerweile ab der Version 3.8
im Typo3-System eingebunden. Bei
allen LDAP-Tools wird cc_sv_auth
geändert, sodass bei der Anmeldung
an der newloginbox automatisch die
Frontenduser-Datenbank im Typo3System geprüft wird. Sobald keine
Daten gefunden werden, greift das
Modul auf die LDAP-Datenbank zu.
Derzeit prüfen wir noch die Verwendbarkeit der LDAP-Server-Erweiterung. Hier konnten wir noch
kaum Informationen herausfiltern,
sodass wir derzeit keine Erfahrungswerte zu diesem Thema besitzen.
Fazit
Abschließend können wir sagen,
Internetanwendungen sind flexibel
und zukunftsfähig. Typo3 ist das am
weitesten verbreitete Open-SourceSystem und die gesamten Hochschulwebseiten sind mit diesem System
gestaltet worden. LDAP ist definitiv
wichtig für ein effizienteres Arbeiten
an unserem Projekt. Da schon für
Typo3 und LDAP Erweiterungen
existieren und wir auch hierzu kein
zusätzliches Tool benötigen, ist diese
Möglichkeit für unser Projekt der optimale Lösungsweg.
Sollten die SOP-Anforderungen auf
diese Erweiterungen nicht zutreffen,
müssen wir eines der Tools auf unsere Bedürfnisse anpassen. Bei den
nächsten Recherchen sollte auch die
Einsatzfähigkeit des Open-LDAPs berücksichtig werden, denn die ProjektServer sollen bis Mitte Juni 2009 auf
das Betriebssystem-Linux umgestellt
werden. Solch eine Änderung sollte
möglichst im Hintergrund stattfinden, sodass die Mitarbeiter sich nicht
ständig auf die neue Gegebenheiten
einstellen müssen. Deshalb wäre es
hier ratsam, eine Erweiterung zu finden, die das Windows-LDAP und
auch das Open-LDAP unterstützt.
Dadurch kann der Änderungsaufwand gering gehalten werden.
37
Quellen
[1] Objektorientierte Programmierung mit PHP 5, Matthias Kannengiesser, 696 Seiten, Franzis Verlag,
2007
[2] Praxiswissen TYPO3, Robert
Meyer, 3. Auflage, 496 Seiten,
O‘Reilly Germany , August 2008
[3] Das Typo3 Anwenderhandbuch,
Studentenversion, Joscha Feth, 1.
Auflage, , 672 Seiten, Addison-Wesley, Februar 2008
[4] Einstieg in TYPO3 4.0, Andreas
Stöckl, Frank Bongers, 2. Auflage,
520 Seiten, Galileo Press, 2007
[5]
www.typo3.org
Stand
(03.04.2009), Erweiterungen
[6] http://www.mittwald.de Stand
(06.04.2009), Typo3 Unterlagen, Extensionbeschreibung
38
ITERATION++
1001 Funktion führen zur Entwicklerfrustration!
Welche Funktionen benötigt ein Entwickler wirklich?
Simon Hänel
Die
Entwicklungsumgebung
ist
das tägliche Arbeitswerkzeug eines
Softwareentwicklers im Rahmen des
Softwareprojekts an der Hochschule.
Doch
kaum
ein
Entwickler
kann heute noch deren gesamtes
Funktionsspektrum überblicken, geschweige denn nutzen. Dabei wäre
bei intensiver Nutzung eine deutliche
Beschleunigung der Entwicklungszeit
möglich. Im Detail wird auf die
aktuell im Softwareprojekt eingesetzten Umgebungen „Eclipse 3.4“
und „Visual Studio 2005“ eingegangen. Diese werden mit der kommerziellen Eclipse Variante dem
„Rational Application Developer“
verglichen. Dabei werden die wesentlichen Grundfunktionen, die eine
Entwicklungsumgebung bieten sollte,
aufgezeigt.
Was bietet also eine Entwicklungsumgebung? Sie besteht aus einer
Sammlung von Werkzeugen die den
Entwickler bei der Entwicklung von
Anwendungen unterstützen soll.
[1] Die meisten Entwicklungsumgebungen bieten Grundfunktionalitäten zur Fehlererkennung beim
Tippen, Automatisierung von sich
wiederholenden Aufgaben, Quellcode zu kompilieren (Übersetzung
des Quelltextes in Maschinensprache) und Funktionen die jeweilige
Dokumentation zu betrachten.
Die Qual der Wahl
Auf dem Markt gibt es heute jedoch
viele gute Entwicklungsumgebungen, die sich in den Grundfunktionalitäten kaum unterscheiden. Um
dabei die geeignetste zu finden, wurden diese nach dem folgenden Kriterium selektiert: Für das Softwareprojekt geeignete Umgebungen müssen
Was bietet eine Entwicklungsumgebung?
zwingend die Programmiersprachen
Zur Programmierung reicht zu Beginn ein einfacher Texteditor. Sobald Programmierer jedoch häufiger
einen längeren Quelltext programmieren müssen, wechseln Sie schnell
zu einer Entwicklungsumgebung.
ten, um eine Kompatibilität mit dem
Java und C-Sharp (C#) unterstützbisherigen Quelltext zu gewährleisten. Diese Voraussetzungen erfüllen:
„Eclipse“(Open Source), „Rational
Application Developer“(IBM), und
„Visual Studio“(Microsoft).
Nachteile der bisherigen Lösung
Bisher wird im Projekt für die Java-Entwicklung „Eclipse 3.4“ und
für die C#-Entwicklung die „Visual Studio 2005 Team Edition“
eingesetzt. Der Nachteil an dieser
Lösung ist, dass sich Entwickler
bisher in beide Entwicklungsumgebungen einarbeiten müssen. Auf
Grund der stark unterschiedlichen
Benennung gleicher Funktionen
und abweichender Menüstrukturen
ist dies aber zeitlich kaum möglich.
Die bisher praktizierte Alternative
ist, dass in zwei Teams getrennt in
C# und Java entwickelt wird und
sich die Entwickler so nur in eine
Umgebung einarbeiten müssen.
Allerdings führt dies schnell dazu,
dass die in den zwei verschiedenen
Teams entwickelten Softwarevarianten (C#- , Java-Version) komplett
auseinanderlaufen und kein einheitliches Produkt entsteht. Eine bessere Lösung wäre hier sicherlich eine
Entwicklungsumgebung für beide
Sprachen einzusetzen, so dass ein
Entwickler immer sofort beide Varianten einer neuen Softwarefunktion
implementieren kann. Doch ist dies
mit der bisherigen Software überhaupt möglich?
ITERATION++
„Eclipse“ bietet standardmäßig
keine C#-Unterstützung. Es kann
jedoch das Erweiterungsmodul
„Improve C#“ [5] nachinstalliert
werden. Allerdings bietet dieses
Modul bisher nur eine rudimentäre Unterstützung und es müsste
im Einzelnen evaluiert werden, ob
diese für das Softwareprojekt ausreichend sind.
Die perfekte Lösung: Visual J#?
„Visual Studio“ hingegen bietet die
Unterstützung von C# und J#. Auf
den ersten Blick scheint dies die
beste Alternative zu sein. Allerdings
ist J# nicht zu 100 % vergleichbar
mit Java. J# ist eine von Microsoft
entwickelte alternative Sprache, die
zwar die gleiche Syntax wie Java
bietet jedoch auf einer andere Laufzeitumgebung ausgeführt wird. Bei
J# kommt hier die „Common Language Runtime“, die in das .NetFramework integriert ist, zum Einsatz. Java hingegen verwendet das
„Java Runtime Environment“, das
in die „Java Virtual Maschine“ integriert ist. J# wurde ursprünglich
dazu entwickelt, Java-Entwicklern
den Umstieg auf C# zu erleichtern
und wird seit dem 10. Januar 2007
offiziell nicht mehr weiterentwickelt
[6]. Dadurch scheidet auch diese
Variante als Alternative aus.
Die Alternative: RAD 7.5
Der „Rational Application Developer 7.5“ von IBM ist die kostenpflichtige Variante zum Open-
Source-Projekt „Eclipse“. RAD
basiert auf der „Eclipse 3.4“-Entwicklungsumgebung und erweitert
diese um etliche Assistenten und die
Unterstützung für die Entwicklung
auf dem „Websphere Application
Server“ und dem „Portal Server“.
Bezogen auf das Softwareprojekt
bietet er integrierte Werkzeuge für
alle Entwicklungsrollen wie Web-,
Java-Entwickler, und Softwarearchitekten [3]. Da er jedoch auch auf
„Eclipse“ basiert, bietet er standardmäßig keine Unterstützung
für C#-Projekte an und es müsste
auch hier das Improve C# Plugin
genutzt werden. Somit bietet auch
der „Rational Application Developer“ keine Rundumlösung für die
gesamte Softwareentwicklung im
Softwareprojekt. Es muss deshalb
im Einzelnen geprüft werden, ob die
C# Unterstützung durch das Plugin
für das Projekt ausreichend ist.
Die 5 wichtigsten Funktionen der
Entwicklungsumgebungen:
Visualisierung mit UML
Zur schnellen Einarbeitung in den
Quelltext ist es wichtig vorhandenen Quelltext in Form von UMLDiagrammen zu visualisieren. Gerade im Softwareprojekt, bei dem sich
jedes Semester wieder ein Entwicklungsteam in den Quelltext einarbeiten muss, ist eine solche Funktion
unverzichtbar. Der „Rational Application Developer“ bietet hierzu
den Visualisierungsassistenten an.
39
Dieser ermöglicht es, automatisch
den vorhandenen Quelltext in Form
von Klassen– oder Sequenzdiagrammen darzustellen. Dabei werden automatisch die Vererbungshierarchie
und die Beziehungen der Klassen
zueinander ermittelt, so dass schnell
die Gesamtaufgaben der einzelnen
Klassen erkannt werden können.
Für Eclipse muss das Plugin „ObjectAid UML Designer“ [4] nachinstalliert werden, um diese Funktionalitäten zu erhalten.
„Visual Studio“ bietet den integrierten
Klassendiagrammassistenten,
der ähnlich dem RAD Assistenten,
Klassendiagramme automatisch per
Rechtsklick generieren kann.
Refaktorisierung
Zur Verbesserung der Struktur des
Quelltextes hinsichtlich der Verständlichkeit, Wartbarkeit und Erweiterbarkeit, ist es immer wieder nötig diesen
zu refaktorisieren [2]. Eine der häufigsten Aufgaben ist dabei das Umbenennen von Klassen und Variablennamen.
Hier bieten die Assistenten aller Entwicklungsumgebungen bereits eine
sehr gute Unterstützung an, indem
alle Referenzen auf die umbenannten
Klassen oder Variablen weitgehend
automatisch angepasst werden.
Besonders hervorzuheben ist hier der
Refaktorisierungsassistent von „Visual
Studio“. Er bietet zusätzlich noch das
Auslagern von Programmteilen in externe Funktionen, oder die automatische Erstellung von Schnittstellen zu
existierenden Klassen an.
40
ITERATION++
Quelltextformatierung nach Programmierrichtlinien
Um einen für alle Programmierer
gut lesbaren Quelltext zu erzeugen,
ist es wichtig sich an vorher vereinbarte Programmierrichtlinien zu
halten. Allerdings sind die meisten
dieser Richtlinien zumeist recht
umfangreich und beinhalten viele
Namens- und Formatierungskonventionen. Dieser Teil der Richtlinien kann recht einfach durch den
Quelltextformatierungsassistenten
umgesetzt werden, der sich durch
eine einfache Tastenkombination
auf den aktuellen Teil des Quelltextes anwenden lässt. Allerdings
muss hierfür zunächst einmal der
Aufwand betrieben werden, die
existierenden Richtlinien dem Formatierungsassistenten begreiflich zu
machen. Die Alternative, diesen Teil
manuell umzusetzen, würde jedoch
sicherlich das 10-fache der Zeit in
Anspruch nehmen. Einmal erstellte
Richtlinien können dann als XML
Vorlage abgespeichert werden und
so unter den Entwicklern verteilt
werden.
Automatisierte Quelltextgenerierung
Eine weitere sehr hilfreiche Funktion ist die automatisierte Quelltextgenerierung. So können zum
Beispiel zu existierenden privaten
Attributen automatisch Setter- und
Getter-Funktionen über einen simplen Rechtsklick erstellt werden.
Sehr wichtig ist hierbei auch die automatische Quelltextergänzung, die
in den getesteten Entwicklungsumgebungen mit „STRG + Leertaste“
aufgerufen werden kann. Sie listet
automatisch die vorhandenen Klassen, Methoden und Variablen auf
und ergänzt angefangene Namen.
So müssen lange Variablen und Methodennamen nie ganz ausgeschrieben werden. Auf diese Weise wird
ein schnelleres und effizienteres Arbeiten ermöglicht. Kryptische Klassen- oder Methodennamen gehören
nun endgültig der Vergangenheit
an.
Methoden aufzulisten, die die aktuell selektierte Methode aufrufen.
Diese Navigationsarten werden von
allen beschriebenen Umgebungen
unterstützt.
Fazit
Setzt man alle hier aufgezeigten
Funktionen der drei Entwicklungsumgebungen ein, erhält man eine
deutliche Verkürzung der Entwicklungszeiten im Vergleich zur
manuellen Umsetzung. Die hier
vorgestellten Entwicklungsumgebungen garantieren jedoch nicht
automatisch eine bessere Quelltext-
„Zu viele Funktionen der Entwicklungsumgebung führen nur zur
Frustration beim Entwickler!“
Simon Hänel, Softwareentwicklung
Schnellere Navigation
Zur schnelleren Navigation innerhalb des Quelltextes gibt es 4
wichtige Assistenten. Die für den
Entwickler geeignetsten sind hierbei der Paketexplorer bei „Eclipse“
und dem „Rational Application Developer„ und der Projektmappenexplorer bei Visual Studio. Zusätzlich
finden sich in den Programmen
noch jeweils verschiedene Suchassistenten. Am hilfreichsten ist hierbei
die Funktion direkt zur Deklaration
oder der Schnittstelle einer Klasse
zu springen, oder die Klassen und
qualität und es können auch nicht
alle Programmierrichtlinien automatisch umgesetzt werden. Zum
Beispiel gibt es noch keine Möglichkeit die Schreibweise von Klassenund Funktionsnamen automatisch,
ähnlich wie bei einer Rechtschreibkorrektur in Microsoft Word, den
Richtlinien entsprechend anzupassen. Aber richtig eingesetzt nehmen
sie dem Programmierer einige Aufgaben ab, so dass er sich auf das Wesentliche konzentrieren kann. Die
hier vorgestellten Entwicklungsumgebungen ähneln sich in ihren Funk-
ITERATION++
tionen stark. Die Open Source Variante „Eclipse“ muss aber teilweise
durch zusätzliche Erweiterungsmodule angepasst werden, um mit den
kommerziellen Vertretern mithalten
zu können. Eine Rundumlösung für
das Softwareprojekt ist bisher nur
ansatzweise vorhanden. Die Grundsteine dafür sind jedoch bereits gelegt. Speziell die C#-Unterstützung
für „Eclipse“ und „RAD 7.5“ mit
dem Plugin „Improve C#“ wird mit
der nächsten Version eventuell bereits soweit ausgereift sein, dass ein
kompletter Umstieg möglich sein
wird. Für das an der Hochschule
angewandte Softwareprojekt ist bis
jetzt sicherlich „Eclipse“ mit einigen
Erweiterungsmodulen ausreichend.
41
Um in Zukunft die Produktivität
der Softwareentwicklungsabteilung
zu steigern wäre es empfehlenswert
eine ein- bis zweitägige Schulung
zu der eingesetzten Entwicklungsumgebung abzuhalten, um so die
Einarbeitungszeit drastisch zu reduzieren. Durch den effektiven Einsatz
der vorgestellten Assistenten kann
so die Entwicklungszeit der Software deutlich reduziert werden.
[3] Wahli, U., Cui H., Fleming
C., Mehta M,Rohr,M., Ugurlu,
P,Gan,P., Gonzalez, C., Farrell, D.;
Heerdegen,A.: Rational Application
Developer V7 Programming Guide,
Riverton, NJ, USA, IBM Corp.,
2007
Quellen
[5] Improve C Sharp Plugin; http://
www.improve-technologies.com/alpha/esharp/ (26.04.2009)
[1] Nourie, D.: Getting Started
with an Integrated Development
Environment (IDE), SUN, 2005
[2] Fowler, M.: Refactoring: Improving the Design of Existing Code,
Addison Wesley, 1999
[4] ObjectAid UML Designer;
http://www.eclipseplugincentral.
com/Web_Links-index-req-viewlink-cid-1011.html (26.04.2009)
[6] J Sharp; http://msdn.microsoft.
com/de-de/vjsharp/default(en-us).
aspx (26.04.2009)
»Any fool can write code that a computer can
understand. Good programmers write code that
humans can understand.«
Martin Fowler, Informatiker
42
ITERATION++
Eclipse-RAP – sinnloser Sprechgesang oder
Hilfe im SOP ?
Wie man dem Web-Client neues Leben einhauchen könnte…
Marco Bischof
Der Web-Client des Langzeitarchivierungssystems „tréstore“ im
Softwareprojekt
der
Hochschule
Reutlingen wird sehr vernachlässigt.
Auch wenn Anforderungen dafür
existieren, wurde die Entwicklung
dieses Clients bisher auf sehr niedriger Prioritätsstufe vorangetrieben.
Deshalb und aufgrund der im Projekt
üblichen „Dokumentationsfaulheit“
der Software-Entwickler ist auch das
Wissen über den bisher erreichten
Fortschritt in dieser Richtung verloren
gegangen. Mehr als die Tatsache, dass
die Seiten des Clients wohl dynamisch
über Java Server Pages erstellt werden,
ist nicht bekannt. Eine Alternative,
den Web-Client ohne zu großen
Aufwand wieder auf einen annehmbaren Entwicklungsstand zu bringen und
dort zu halten ist die Eclipse Rich Ajax
Platform.
tigste: Es besteht eine entsprechende
Anforderung des Kunden zur Langzeitarchivierungssoftware „tréstore“.
Auch wenn die Anforderungen dazu
nicht genauer definiert sind, sind sie
trotzdem bindend für die Erstellung
der Software. Bei den Umfragen zur
Neuentwicklung der grafischen Bedienoberfläche (GUI) der Software,
durchgeführt bei möglichen künftigen Nutzern, war die Nutzung der
Software über eine Web-Schnittstelle
ebenfalls ein Punkt, der angekreuzt
wurde. Als Gründe dafür wurden
die Unabhängigkeit von Zeit und
Ort des Zugriffs auf das System genannt, sowie die dann nicht mehr
nötige Installation von Software auf
dem genutzten Rechner. Denn eine
Anwendung wie eine ArchivierungsSoftware ist geradezu prädestiniert,
über das Internet genutzt zu werden
und damit nicht nur vom eigenen
Rechner aus.
Was für ein RAP ?
Warum ein Web-Client ?
Die Entwicklung des Web-Clients
geht nicht so voran, wie es von Seiten des Kunden und der Geschäftsleitung gewünscht wird. Die Gründe, eine Web-Version des Clients zu
erstellen, sind vielfältig. Der WichSOP JOURNAL HOCHSCHULE REUTLINGEN R6
Um es gleich vorwegzunehmen: die
RAP hat natürlich nichts mit Musik zu tun. Die Rich Ajax Platform
ist eine Erweiterung (Plug-In) für
die Entwicklungsumgebung Eclipse,
mit der Web 2.0 Anwendungen auf
Java-Basis entwickelt werden kön-
nen. Das Produkt stammt von der
Firma Innopract in Karlsruhe, die
auf die Entwicklung von Eclipse-Erweiterungen spezialisiert ist. Wie bei
Java üblich ist das Programm quelloffen und steht unter der Eclipse
Public License zur freien Verfügung.
Im Unterschied zur Erstellung sonstiger Web 2.0 Anwendungen braucht
der Entwickler keine Kenntnisse der
üblichen Web-Sprachen wie HTML
oder JavaScript. Es wird ausschließlich ein Java-Programm entworfen
und dabei kann auf die bekannten
Java-Bibliotheken und Frameworks
zurückgegriffen werden.
Technische Basis
Als technischen Hintergrund für den
Betrieb einer Rich Ajax Platform lassen sich zwei Grund-Architekturen
erkennen. Das Wort Rich deutet darauf hin, dass man es mit einem Rich
Client zu tun hat, also einem erweiterten Fat-Client. Dort sind normalerweise zwei Architekturschichten
vorhanden: jeweils eine zur Datenverarbeitung und zur Darstellung
der Oberfläche. Dazu kommt bei
einem Rich-Client noch eine PlugIn-Schicht. Diese stellt eine einfache
Möglichkeit dar, die Funktionalitäten des Clients zu erweitern. Mit der
ITERATION++
Eclipse Rich Client Platform (vgl.
Artikel von Matthias Huber) existiert eine Entwicklungsumgebung,
mit der Rich-Clients erstellt werden
können. Diese können als Grundlage für das Aufsetzen einer RAP-Anwendung dienen. Die dabei entste-
Apache Tomcat bildet die Grundlage
für die Server-Seite der Anwendung,
die das Java-Programm ausführt. Die
benötigten Daten werden dann an
den Client in Form eines Browsers
geschickt und dort dargestellt.
„Mit der Eclipse-RAP könnte man
dem Web-Client neues Leben
einhauchen“
Marco Bischof, Softwareentwicklung
henden Programme sind mit vielen
Funktionen ausgestattet, lassen sich
aber trotzdem leicht über das Netz
verteilen und betreiben.
Die andere Architektur, auf der die
RAP aufbaut, ist Ajax, also Asynchrones JavaScript und XML. Ajax ist ein
Konzept zur asynchronen Datenübertragung bei Web-Seiten. Durch
das Zusammenspiel der bekannten
Web-Komponenten HTML, JavaScript und XML ist es möglich
innerhalb einer HTML-Seite einen
HTTP-Request
durchzuführen,
ohne dass die Seite komplett neu
geladen werden muss. Das reduziert
den Datenverkehr auf den Leitungen
und somit wird die Geschwindigkeit
der Anwendung erhöht.
Die Rich Ajax Platform kombiniert
nun die Vorteile der beiden Konzepte und stellt eine Möglichkeit dar,
Java-Programme per Client-ServerArchitektur ins Netz zu bringen. Ein
Was müsste getan werden?
Die wichtigste Bedingung für den
Einsatz der Eclipse RAP ist schon
erfüllt: im Projekt wird Java als Programmiersprache in der Entwicklungsumgebung Eclipse eingesetzt,
was als Grundvoraussetzung gilt.
Dann müsste aus dem bisherigen
Client ein Rich Client werden. Hierbei spielen dann Schlagworte wie
GUI-Entwicklung, Daten-Persistenz
und die Kommunikation zwischen
Client und Server eine Rolle. In der
aktuellen Iteration (R6) wird darauf
hingearbeitet, die Voraussetzungen
zu schaffen, aus dem vorhandenen
Client einen Rich-Client bauen zu
können.
Als Beispiele für diese Bemühungen
seien hier nur die Umstellung in der
Benutzeroberfläche von Swing-Komponenten auf das Standard Widget
Toolkit (SWT) genannt und die
Konzeption einer Persistierung per
43
Hibernate. Außerdem sind einige
Bedingungen für die Erstellung einer
RAP-Anwendung schon erfüllt, wie
z.B. die Kommunikation zwischen
Client und Server über Web-Services.
Bei der Portierung dieses Rich Clients zu einer Web-Anwendung wären dann mehrere Punkte zu beachten: Da die RAP andere Plug-Ins
benötigt, müssen alle Abhängigkeiten geändert werden. So werden z.B.
die genutzten SWT-Widgets durch
RWT, also die RAP-eigenen GrafikBausteine, ersetzt. Diese beinhalten
aber die meisten Standard-Widgets,
so dass hier keine großen negativen
Auswirkungen zu erwarten sind. Außerdem muss als Einstiegspunkt ein
anderer Extension-Point gewählt
werden, der die Besonderheiten der
Web-Entwicklung
berücksichtigt.
Anschließend werden durch Übersetzungsfehler z.B. fehlende Schnittstellen sichtbar, um die sich dann
der Entwickler noch gesondert kümmern muss. Als Zeitbeispiel sei hier
die Entwicklung eines wirtschaftlichen Softwaresystems genannt, wo
der Rich Client eine Produktionszeit
von ¼ Entwicklerjahr benötigte. Die
anschließende Portierung auf RAP
wurde innerhalb einer Woche abgeschossen.
Mögliche Probleme
Selbstverständlich können bei der
Portierung einer RCP-Anwendung
für die Nutzung im Web Probleme
auftreten. Mit dem größten Unterschied zwischen einer Desktop- und
44
ITERATION++
einer Web-Anwendung stellt sich
schon das Erste: Mehrere Benutzer
im Web greifen auf die gleiche Instanz der Anwendung zu. Somit muss
über eine Session sichergestellt werden, dass benutzerspezifische Daten
auch richtig zugeordnet werden. Das
Problem stellt sich beim Desktopclient nicht, da hier jede Installation
des Clients eine eigene Instanz der
Anwendung ist. Ein weiteres Problem ist, dass nicht für jedes Plug-In
der RCP eine Entsprechung in der
RAP existiert. Das bedeutet, dass es
manche Schnittstellen dort nicht gibt
und solche Aufgaben anders gelöst
werden müssten. Ein Beispiel hierfür ist die fehlende Unterstützung
von „Drag&Drop“, die aber durch
„Copy&Paste“ relativ leicht ersetzt
werden könnte und die in der aktuellen Software auch nicht zum Einsatz
kommt. Größtes Problem im Projekt wäre sicherlich das Fehlen von
Dialogen zur Datei-Verarbeitung.
Die RAP-Anwendung läuft auf dem
Server und hat damit keinen Zugriff
auf das lokale Datei-System, was das
Hochladen von Dateien sehr schwierig macht. Hier müssten andere Wege
gefunden werden, da eine Archivierungs-Software ohne Datei-Upload
nicht praktikabel ist. Teilweise werden diese Lücken in der Plattform
mit Version 1.2, die im Sommer
2009 erscheinen soll, gefüllt.
Fazit
Sicherlich gibt es viele Ansätze und
Möglichkeiten, die Entwicklung des
Web-Clients voranzutreiben bzw.
erst einmal wieder in den Vordergrund zu rücken. Aus Entwicklersicht ist der vorgestellte Ansatz eine
schnell umsetzbare Lösung, da auf
vorhandene Ressourcen zurückgegriffen werden kann (bestehender
Java-Client, Programmierkenntnisse aus Informatik 3) und nicht viel
„Neues“ (Web-Programmierung,…)
dazu kommt. Außerdem wäre die
Code-Basis bei Desktop- und WebClient die gleiche, was Änderungen
an beiden Versionen einfacher macht.
Die Vorarbeiten dazu nehmen bestimmt einige Zeit in Anspruch, aber
am Ende dieses Prozesses können
sich die Entwickler auf das Produkt
selbst konzentrieren, nicht auf die
vielen verschiedenen Technologien,
aus denen es sich zusammensetz.
Die Einarbeitung in diese hatte die
aktuelle Iteration viel Zeit gekostet.
Die oben genannten Probleme sind
aber Grund genug, sich die Nutzung
dieser Technologien gut zu überlegen
und Sie in einem entsprechenden
Konzept zu beachten.
Quellen
[1] Lange, Fabian: Eclipse Rich Ajax
Platform: Bringing Rich Client to the
Web, Springer, 2008
[2] Schäfer, Steffen: Einsatzmöglichkeiten der Eclipse RAP, Orientation in Objects GmbH, Mannheim, April, 2008
[3] Mücke, Roland: Eclipse RAP: Rich
Clients im Web, Präsentation für die
itemis AG, Wiesbaden, 2004
[4] Hohenbichler, Johannes: Entwicklung eines Referenzmodells für
Eclipse RCP/RAP mit dynamisch
austauschbarer Anwendungslogik für
das Designziel „online=offline“ in allen Ebenen einer 3-Tier-Architektur,
Hochschule Esslingen, 2009
[5] Webseite der Rich Ajax Platform,
URL: http://www.eclipse.org/rap/,
letzter Zugriff: 20.05.2009
[6] Webseite der Rich Client Platform, URL: http://www.eclipse.org/
rcp/, letzter Zugriff: 14.05.2009
ITERATION++
45
Eclipse RCP auf dem Vormarsch!
Auch für den Einsatz im SOP geeignet?
Matthias Huber
Lange Zeit konnte sich Java bei
Desktop-Anwendungen nicht durchsetzen. Mit der Eclipse Rich Client
Platform (RCP) steht nun eine
Technologie zur Verfügung, die einen
Einsatz von Java im Desktop-Bereich
attraktiver macht. Dies entdecken immer mehr Softwarehersteller und entwickeln Anwendungen, die auf Eclipse
RCP basieren (vgl. [1]). Sollte das
Softwareprojekt sich dieser Plattform
ebenfalls bedienen und auf den Zug
aufspringen?
Eclipse RCP – was war davor
Java wurde aufgrund der verfügbaren
GUI-Toolkits selten für DesktopAnwendungen verwendet. Daniel
Arndt sieht die Gründe bei den veralteten Grafikkomponenten von AWT
(Abstract Window Toolkit) und den
Leistungsproblemen von Swing. Die
Leistungseinbrüche von Swing resultieren aus der Trennung der Grafikkomponenten vom Betriebssystem.
Die Komponenten werden nicht
mehr vom Betriebssystem gerendert.
Zudem entfällt das „Look & Feel“
des Betriebssystems, welches Benutzer
vermissen (vgl. [2]).
Eclipse RCP setzt auf SWT
Eclipse RCP setzt als GUI-Toolkit
SWT ein. Die Abkürzung steht für
Standard Widget Toolkit. Es werden
native Oberflächenkomponenten eingesetzt, die im Vergleich zu Swing weniger Leistungseinbußen mitbringen,
da die Grafiken nicht von der Anwendung, sondern vom Betriebssystem
gerendert werden. Die Komponenten
sind nahe an das „Look & Feel“ des
Betriebssystems angelehnt. Im Vergleich zu AWT sind die verfügbaren
Grafikkomponenten moderner und
in größerer Zahl vorhanden. SWT
wird von vielen Betriebssystemen unterstützt.
Rich Clients und Andere
Eclipse RCP ermöglicht die Entwicklung von Rich Clients. Diese bieten
im Vergleich zu Thin-Clients mehr
Funktionalitäten. Thin-Clients, als
Beispiel der Webbrowser „Mozilla
Firefox“, beschränken sich auf die
reine Ein- und Ausgabe. Eine Verarbeitung von Daten findet nicht beim
Client selbst statt. Im Falle des Webbrowser werden die Eingaben des
Benutzers an einen Server geschickt,
dort verarbeitet und eine entsprechende Ausgabe beim Benutzer angezeigt. Ein Rich-Client hingegen,
kann selbst Daten verarbeiten. Er ist
eine Erweiterung des Fat-Client, da
er nicht nur ein Problem lösen kann,
wie es beim Fat-Client der Fall ist.
So könnte ein Rich-Client zusätzlich
zum Herunter- oder Hochladen von
Daten von einem Server, auch Videos
oder Musik abspielen. Ein Fat-Client
wäre auf den Austausch von Daten
oder das Abspielen von Videos oder
Musik beschränkt (vgl. [4]).
Eclipse RCP – die Entstehung!
Viele Benutzer der Entwicklungsumgebung Eclipse, nahmen Funktionalitäten des Programms wahr, die für
moderne Rich Client Anwendungen
benötigt werden. Daher trennte man
in der Version 3.0 das Framework, so
dass die Entwicklungsumgebung eine
Anwendung ist, die auf einem Kern
aufsetzt. Dieser Kern wird als Eclipse
Rich Client Platform bezeichnet. Er ist
der minimale Teil, der für eine Eclipse
RCP Anwendung benötigt wird (vgl.
[3], S.11 und [6]). Wenn nur die Rich
Client Platform als Anwendung ausgeführt wird, erhält man ein leeres Fenster. Durch diese Umstrukturierung
können Entwickler ihre Anwendungen
auf den Kern aufsetzen und die Funktionalitäten nutzen, die die Eclipse Rich
Client Platform bereitstellt (vgl. [5]).
46
ITERATION++
Einfach anstöpseln
Die Rich Client Platform zeichnet
sich durch eine flexible Architektur
aus. Eine RCP-Anwendung besteht
aus einer Laufzeitumgebung, dem
Kern und einer Ansammlung von
Plugins. Unter Plugin wird ein Modul
bezeichnet, das ein bestehendes System erweitert und zusätzliche Funktionalität bereitstellt (vgl. [8] und [9]).
Über das Plugin-System von Eclipse
RCP können Plugins hinzugefügt
und aktualisiert werden. Entwicklern
bietet sich somit die Möglichkeit, an
unterschiedlichen Stellen des Systems
zu entwickeln, ohne die Arbeit eines
anderen Entwicklers zu stören. Das
Plugin-System ermöglicht auch unterschiedliche Programmzusammensetzungen. Als Beispiel kann die Entwicklungsumgebung Eclipse selbst
aufgeführt werden. Sie wird in einer
festgelegten Version bereitgestellt,
kann aber durch Plugins erweitert
werden. Die Verteilung, Aktualisierung und Erweiterung erfolgt über
zentrale Server (vgl. [2]). Dies wäre
auch für das Softwareprojekt möglich. Ein entsprechendes Tutorial haben Dejan Glozic und Dorian Birsan
verfasst (vgl. [10]).
SWT - Der erste Schritt ist geschafft!
Die Iteration R6 des Softwareprojekts
führt derzeit einen Wechsel des GUIToolkits des Java Desktop Client von
Swing auf SWT durch. Diese Anforderung stellt das Unternehmen „Trésor Secure Systems“ an das Produkt
„tréstore“ (Anforderung STRQ 7.9).
Die Gründe für die Änderung des
zu verwendeten GUI-Toolkits, sind
wie schon vorher angesprochen, die
Leistungseinbußen und das fehlende
„Look & Feel“ von Swing. Durch den
Einsatz von SWT geht die Plattformunabhängigkeit von Java verloren,
da die Software für jedes Betriebssystems unterschiedliche Komponenten
benötigt. SWT ist für alle gängigen
Betriebssysteme verfügbar (Windows,
Unix-Distributionen, Mac OS). Es
entsteht somit kein Nachteil, da das
Produkt in verschiedenen Versionen
für die Betriebssysteme ausgeliefert
werden kann (vgl. [4]).
Die Umstellung wird mit dem Ausscheiden der Iteration R6 vollendet
sein. Nachfolgende Iterationen müssen für die Gestaltung des Java Clients zukünftig SWT nutzen. Eine
Einarbeitung ist somit unumgänglich.
Da Eclipse RCP das Standard Widget Toolkit verwendet, müsste sich
die Softwareentwicklung der ITer@
Group nicht in ein neues GUI-Toolkit einarbeiten. Vorhandenes Wissen
könnte über die Iterationen weitergegeben werden. Aus Sicht des GUIToolkits würde ein Wechsel zu einer
Eclipse RCP Anwendung nichts im
Wege stehen.
Wie ‚rich‘ darf es denn sein?
Nicht nur das GUI-Toolkit SWT
rechtfertigt einen Einsatz von Eclipse RCP, sondern vor allem der Rich
Client selbst. Er kann bei der Umset-
zung der Anforderung „STRQ 1.6:
Interpretierbarkeit der Daten“ helfen.
Die originale Beschreibung dieser
Anforderung lautet: „Daten müssen
interpretierbar sein, d.h. das eine bestimmte Hard/ Software dafür bereitgestellt wird, in dem die Datenobjekte
für den menschlichen Betrachter verfügbar gemacht werden. (Gilt vorerst
nur für Bilder, Audio und Video)“.
Ein Fat Client könnte nur das Archivieren von Daten lösen. Wird die
Anwendung als Rich Client gestaltet,
ließen sich auch Videos und Musik
abspielen. Auch zukünftige Anforderungen, die die Funktionalitäten eines
Rich Clients benötigen, sind umsetzbar. Als Beispiel wäre hier der OfflineBetrieb zu nennen. Es wäre möglich
eine Zusammenstellung an Daten
ohne Verbindung zum Server anzulegen. Diese wird automatisch persistiert, sobald eine Verbindung zum
Server besteht. Der Benutzer kann dadurch jederzeit und überall seine Daten, die er langfristig sichern möchte,
auswählen und zu einem späteren
Zeitpunkt persistieren (vgl. [3], S. 4).
Ein (nicht) endender Weg …
Bei all den Vorzügen muss auch ein
Haken sein. Wie bereits erwähnt steht
das GUI-Toolkit SWT für kommende
Iterationen auf dem Pflichtprogramm.
Doch SWT ist nur ein kleiner Teil,
der für eine Einführung von Eclipse
RCP nötig wäre. Auf das UI-Toolkit
JFace (vgl. [7]) sollte nicht verzichtet
werden. „Grundsätzlich könnte man
ITERATION++
ohne JFace auskommen, es erleichtert
die Arbeit aber ungemein.“(vgl. [4])
Dies würde eine zusätzliche Einarbeitung benötigen. Die größte und zugleich schwierigste Aufgabe ist jedoch
die Einarbeitung in den Aufbau der
Rich Client Platform. Die Plattform
nate Einführung kann bei der Entscheidung behilflich sein. Die Umsetzung konnte nicht in einer Iteration
durchgeführt werden, sodass die Iteration R6 versucht, die nachfolgende
Iteration auf denselben Wissenstand
zu bringen. Erfolgt die Umsetzung
47
[3] Daum, Berthold: „Rich-ClientEntwicklung mit Eclipse 3.2 - Anwendungen entwickeln mit der Rich
Client“ Platform, dpunkt.verlag, Heidelberg, 2. Aktualisierte Auflage
[4] Bendisposto, Jens; Jastram, Michael; Sippel, Heiko: „Thinking in
Plug-in (Teil 1)“, Java Magazin 76ff,
Dezember 2007
„Es muss nicht immer ‚rich‘ sein!“
Matthias Huber, Softwareentwicklung
[5] Rich Client Platform von Eclipse,
http://www.inventage.com/rich-
client-plattform-von-eclipse.html,
zuletzt besucht am 26.04.2009
[6] Rich Client Platform, http://
zeichnet sich zwar durch flexible Architekturen aus, aber bis solche möglich sind, müssen einige Kenntnisse
über Eclipse RCP vorhanden sein.
Aus eigener Erfahrung kann ich sagen, dass die Lernkurve nur langsam
steigt. Meiner Meinung nach zu langsam für die Umsetzung in einem Iterationszyklus.
Die Vergangenheit hat gezeigt, dass
Kenntnisse nicht über die Iterationen
weitergegeben werden konnten. Sollte dies auch in Zukunft nicht möglich
sein, würde ich von einer Einführung
von Eclipse RCP im Softwareprojekt
abraten.
von Hibernate im Iterationszyklus
von R7, sollte eine Einführung von
Eclipse RCP in Nachfolgeiterationen
möglich sein. Wichtigste Voraussetzung ist der Wissenstransfer über die
Iterationen. Ist der Transfer gewährleistet sollte nicht zu lange gezögert
werden. Der Zug wartet nicht ewig…
Entscheidung vertagt!
[2] Arndt, Daniel: „Eclipse RCP –
Derzeit muss die Entscheidung nicht
getroffen werden. Durch die Einführung von Hibernate sind aktuell keine
Kapazitäten für die Einarbeitung in
Eclipse RCP vorhanden. Die Hiber-
Entwicklung von Java Anwendungen
wiki.eclipse.org/index.php/Rich_Client_Platform, zuletzt besucht am
26.04.2009
[7]JFace, http://wiki.eclipse.org/JFace
[8]BSI für Bürger, http://www.bsifuer-buerger.de/glossar/glo_op.htm,
Quellen
[1] Ackermann, Laura; Moran, John:
“Second Annual Eclipse Global Enterprise Survey”, http://www.eclipse.org/
org/press-release/20060905rcp.php,
[9] Dimoco Glossar, http://www.dimoco.at/de/informationen/glossar.
html zuletzt besucht am 20.05.2009
[10] Glozic, Dejan; Birsan, Dorian:
“How To Keep Up To Date” http://
www.eclipse.org/articles/article.
php?file=Article-Update/index.html
für den Desktop“, http://www.pentasys-blickpunkte.de/index.php?qs000,
48
ITERATION++
Java Sicherheit
Warum behauptet wird, Java sei sicher und wie Java versucht, dieses Ziel zu erreichen
Torsten Lutz
„Warum Java? Weil es sicher ist.
Warum ist Java sicher? Weil Java in
einer Sandbox läuft.“
So ähnlich laufen die meisten Diskussionen wenn es um die
Programmiersprache Java und deren
Sicherheit geht. Aber was ist eigentlich
sicher? Ist Java sicher? Und wenn ja,
warum?
Dieser Artikel soll einen kleinen
Einblick geben, wie Java das Thema
Sicherheit behandelt und warum
behauptet wird, dass Java „sicher“
ist. Diese Sandbox ([3], S. 119) ist
zwar mit einer der Gründe für die
Sicherheit von Java, aber um sie zu realisieren sind einige Komponenten und
Voraussetzungen nötig, die wir gleich
kennenlernen werden.
Sprachsicherheit
Java ist eine streng typisierte Sprache. Im Gegensatz zu anderen Sprachen ist der Compiler strenger bei
der Umwandlung von Datentypen,
dem sog. „casten“. Kurz: In manchen Sprachen ist es möglich aus
Orangen Bananen zu erstellen – aber
auch eine Orange in Bananenform
bleibt eine Orange. Diese Möglichkeit bietet Flexibilität, kann aber zu
schwerwiegenden Fehlern führen.
Java prüft immer, ob eine Typumwandlung erlaubt ist oder nicht,
beim kompilieren und zur Laufzeit.
(vgl. [1], S. 50)
Zusätzlich beachtet Java immer die
Absichten eines Programmierers.
Eine als „private“ deklarierte Variable einer Klasse sollte unter keinen
Umständen von außen zugänglich
sein. Nehmen wir das klassische C++
als Gegenbeispiel: Durch die in C
verfügbaren Zeiger oder den direkten Zugriff auf den Speicher ist es
möglich, wenn auch über Umwege,
eine solche Variable dennoch zu verändern. (Der Leser sollte bedenken,
dass C aus einer anderen Ära stammt
und aus vielen Gründen nicht mit
Java zu vergleichen ist!)
Dieselben Regeln gelten für als „final“ markierte Variablen oder Funktionen, deren nachträgliche Änderung nicht mehr möglich sein sollte,
und in Java auch nicht ist.
Diese Merkmale dienen mehr der
Verhinderung von Fehlern, als der
Abwehr von Angriffen und gelten bei
vielen aktuellen Programmiersprachen
als Voraussetzung. (vgl. [2], S. 126)
Sicherheitsmanager
Der Sicherheitsmanager ist einer
der drei wichtigsten Bestandteile
der Java-Sandbox, er erlaubt oder
verbietet beispielsweise den Zugriff
auf Dateien, das Öffnen von Sockets
zur Benutzung des Netzwerks usw.
Kurz: Jeder entsprechende Aufruf in
der Java-Schnittstelle fragt erst den
Sicherheitsmanager, ob diese Aktion
erlaubt ist ([1], S. 59f ). Ein wichtiger Punkt, der vielen Lesern jedoch
unbekannt sein dürfte, ist der Unterschied beim Ausführen einer lokalen
Java-Anwendung im Vergleich zu
einem im Browser eingebetteten Applet. Die Applet-Variante garantiert,
dass der Sicherheitsmanager zum
Einsatz kommt – die lokale Ausführung nicht! Im letzteren Fall ist es
dem Programmierer überlassen, ob
und welche Art von Sicherheitsmanager genutzt wird. Der Benutzer
kann die Nutzung lediglich durch
zusätzlich angegebene Parameter erzwingen, die Voreinstellung aktiviert
ihn jedoch nicht.
Klassenlader
Der Klassenlader liest Java-Bytecode
in die virtuelle Maschine ein. Da Java
die Möglichkeit bietet, kompilierten
Code verteilt abzulegen und dyna-
ITERATION++
misch nachzuladen, müssen einige
Sicherheitsvorkehrungen getroffen
werden. Über den Sicherheitsmanager muss festgestellt werden, ob der
geladene Code die nötigen Berechtigungen besitzt. Desweiteren muss
der Namensraum der zu ladenden
Klasse definiert werden, um die Sicherheit der gekapselten Daten zu
garantieren. (vgl. [1], S. 112f )
diese keine Möglichkeit bieten, das
Programm zu destabilisieren oder zu
modifizieren, dennoch sollte ein Programmierer sicherstellen, dass nur
der richtige Benutzer die Möglichkeit hat, sich am System anzumelden und Aktionen durchzuführen.
Die Authentifizierung soll also einen
Benutzer anhand seiner Daten erkennen und eine Ausführung des Pro-
49
rung, bei der sensible Daten wie z.B.
Passwörter, Bankdaten, o.ä. involviert sind, verschlüsselt erfolgen sollten. Schließlich nützt jede Sicherheit
innerhalb eines Programmes nichts,
wenn ein potenzieller Angreifer sich
ohne großen Aufwand Zugriff auf
die gesamte Anwendung verschaffen
kann – möglicherweise sogar mit allen verfügbaren Rechten.
Zugriffskontrolle
Die Zugriffskontrolle erfolgt primär
über Genehmigungen („permissions“), die als Objekte gespeichert
und abgefragt werden können. Javainterne Klassen haben z.B. Rechte,
die andere Klassen nicht haben können oder dürfen. Im Zusammenspiel
mit Richtlinien („policies“), der
Herkunft der Klasse und den Genehmigungen kann die virtuelle Maschine unterscheiden, welche Rechte
vorhanden sind.
Diese Eigenschaft wird bei der erwähnten Möglichkeit, auf anderen
Rechnern verteilte Pakete nachzuladen besonders wichtig. Es erfolgt
eine Unterscheidung zwischen vertrauenswürdigen und anderen Quellen. (vgl. [1], S. 102)
Authentifizierung
Jede in einer Sprache eingebaute Sicherheit steht vor neuen Herausforderungen, sobald der Benutzer selbst
in Aktion tritt. Um ein Programm
sinnvoll bedienen zu können, müssen diesem entsprechende Rechte
eingeräumt werden. Zwar sollten
„Die Programmierer sollten ihre Konzentration eher auf gut entworfenen Code und eine
saubere Implementierung richten.“
Torsten Lutz, Softwareentwicklung
gramms in diesem Kontext ermöglichen, ohne dabei Lücken zu öffnen.
Die Programmierung dieser Lösung
ist im Normalfall der kleinere Teil.
Die Wartung der Benutzerdaten, die
meistens der Systemadministrator
übernimmt, kann viel Aufwand bedeuten. Java beherrscht viele Möglichkeiten, die Authentifizierung an
andere Komponenten weiterzugeben. Sie können als Plug-In nachgeladen werden. Ein Beispiel wäre
das von Windows genutzte „LDAP“.
(vgl. [1], S. 346f )
Verschlüsselung
Die sichere Verschlüsselung von Daten ist ein eigenes Kapitel und soll
hier nicht behandelt werden. Natürlich ist dennoch zu erwähnen, dass
jede Kommunikation oder Speiche-
Fazit
Für das Softwareprojekt ist die Sicherheit von Java relevant, um Einschränkungen bei der Ausführung,
insbesondere des Webclients, einschätzen zu können. Der andere
wichtige Teil ist die Authentifizierung von Benutzern und das Prüfen
deren Rechte vor der Ausführung einer Aktion. Zusätzlich ist die Sprachsicherheit, die der Vermeidung von
Fehlern dient, ein Vorteil. Weitere
Schritte würden die Komplexität im
momentanen Stand nur unnötig erweitern.
Die Programmierer sollten ihre Konzentration eher auf gut entworfenen
Code und eine saubere Implementierung richten. Ein übersichtliches,
gut wartbares Projekt vermeidet FehSOP JOURNAL HOCHSCHULE REUTLINGEN R6
50
ITERATION++
ler und die aus diesen entstehenden
Lücken und Probleme.
Java geht viele Wege, um Sicherheit zu garantieren. Dabei werden
auch Fehler bei der Programmierung
selbst verhindert. „Sicher“ ist die
Sprache trotzdem nicht. Ein böswilliger Programmierer baut immer
noch oft auf die Gutgläubigkeit der
Benutzer anstatt auf Lücken selbst,
und die ist, sobald das Wort „Java“
fällt, oft noch leichter zu haben als
sonst. Bisher unbekannte Lücken
finden sich, wie bei jeder Software,
auch immer wieder genug – und
nicht immer werden sie schnell und
zuverlässig behoben.
Zusätzlich gibt es noch andere Angriffsmöglichkeiten, wie z.B. die Daten in der virtuellen Maschine von
außen direkt im Speicher zu verändern, was diese selbst logischerweise
auch nicht verhindern kann. Ein anderes bekanntes Problem ist die Serialisierung von Daten, bei der Daten
aus dem Speicher persistiert werden
können – mitsamt sensiblen Informationen.
Kurz: „Sicher“ gibt es nicht. Der kurze, skeptische Blick auf die Herkunft
und den Zweck eines Programmes
lohnt sich immer, auch bei „sicheren“ Applets.
Quellen
[1] Scott Oaks:
O’Reilly, 2001
Java
Security,
[2] Hossein Bidgoli: Handbook of
information security, 2006
[3] Wolfgang Ehrenberger: Computer Safety, Reliability and Security,
1998
»C macht es einfach, sich selbst ins Bein zu Schießen; C++ erschwert es, aber wenn es dir gelingt,
bläst es dir das ganze Bein weg.«
Bjarne Stroustrup, Informatiker
ITERATION++
51
GUI Toolkits für Java
Ein Vergleich
Thomas Staiger
Grafische Benutzeroberflächen gehören heute zum de facto Standard
bei kommerziellen Programmen. In
der Entwicklung von Java haben
sich drei User Interface Toolkits zur
Entwicklung grafischer Oberflächen
durchgesetzt: AWT, Swing und SWT.
Laut Feigenbaum [http://www.ibm.
com/developerworks/grid/library/
os-swingswt/] besitzt jedes Toolkit
Vor- und Nachteile. Die Eignung
muss für jeden Einsatzzweck bestimmt werden, da keines der Toolkits
jegliche Anforderungen beliebiger
Projekte erfüllen kann. Feigenbaum
behauptet auch, dass sich das in näherer Zukunft nicht ändern wird. Der
Fachartikel analysiert die UI Toolkits
– darunter stellt SWT, das jüngste
für Java verfügbare UI Toolkit, eine
für das Softwareprojekt interessante
Entwicklung dar.
AWT – Der Anfang
Das 1996 erschienene Java Development Kit (JDK) 1.0 enthält das
Abstract Window Toolkit (AWT).
Dieses ermöglicht die Erstellung
einfacher, grafischer Benutzeroberflächen. Die Möglichkeiten von
AWT waren schon zum Zeitpunkt
seiner Einführung limitiert, die Entwicklung einer komplexen Benutzeroberfläche so gut wie unmöglich
(siehe auch [1], Seite 5). AWT bietet
beispielsweise keine Komponenten
für Tabellen, Bäume, Fortschrittsbalken oder Dateidialoge - diese müssen vom Entwickler implementiert
werden. Bedingt durch das “lowest
common denominator” -Prinzip, zu
deutsch kleinster gemeinsamer Teiler, besitzt AWT nur Komponenten,
die auf allen von der Java Virtual
Machine unterstützten Betriebssystemen vorhanden sind (vgl. [2], Kapitel „A look at AWT“).
Dies schränkt die Komponentenvielfalt ein. Dazu kommen noch Probleme bei der Portabilität, da AWT so
genannte „schwergewichtige“ (d.h.
native) Betriebssystemkomponenten zur Darstellung verwendet (vgl.
[2]). Im schlimmsten Fall verhalten
sich AWT Komponenten auf jedem
Betriebssystem unterschiedlich. Das
Verhalten ist abhängig von der nativen Implementierung im Betriebssystem und kann nicht einfach überschrieben oder erweitert werden (vgl.
[5], Kapitel 13). All das ist nicht im
Sinne des Entwicklers und auch
nicht im Sinne des “Write once, run
everywhere”-Java Prinzips.
Version 1.1 des JDKs behebt zwar
einige Probleme in Zusammenhang
mit AWT, es fehlen aber immer
noch die am Anfang dieses Absatzes
genannten Komponenten (vgl. [5],
Kapitel 13). AWT kann als veraltet angesehen werden und hat deshalb keine Bedeutung für das Softwareprojekt.
Sun reagiert: Swing
1997 reagiert Sun und kündigt die
Java Foundation Classes (JFC) an,
welche - neben AWT - auch das UI
Toolkit “Swing” enthalten. Swing ist
leichtgewichtig, da es komplett in
Java geschrieben ist. Das bedeutet
auch, dass es nicht auf native Komponenten des Betriebssystems zur
Darstellung zurückgreift (vgl. [3],
S.5), somit ist Portabilität gegeben.
Swing nutzt ein “pluggable look and
feel”, d.h. eine Benutzeroberfläche
kann auf jeder Plattform gleich aussehen (vgl. [1], Seite 858). Dies bedeutet nicht zwingend, dass sich die
Benutzeroberfläche in das Design
der Betriebssystemoberfläche integriert. Wird beim Softwareentwicklungsprozess eine komplett eigene
Oberfläche entwickelt, welche sich
von der Oberfläche des JVM Gastbetriebssystems unterscheidet, so kann
52
ITERATION++
dieser Punkt vernachlässigt werden.
Wird aber eine Oberfläche angestrebt, welche sich ideal in das Betriebssystem integriert, so erhält man
mit den Standardskins von Swing
möglicherweise keine befriedigende Lösung. Richtlinien wie z.B. die
Apple Human Interface Guidelines
(vgl. [4]) beschäftigen sich ausführ-
eines grafikintensiven Programms
muss also abgewogen werden, ob
der Einsatz von Swing sinnvoll ist.
Zum jetzigen Zeitpunkt besitzt die
Oberfläche der Langzeitarchivierungssoftware des Softwareprojekts
keine grafikintensiven Inhalte (z.B.
Anwendung von Hardwareshadern
in Echtzeit). In Zukunft könnte die
„Obwohl SWT nicht Teil der Java API
ist, bietet es Implementationen für
Windows, Mac OS X und Linux.“
Thomas Staiger, Softwareentwicklung
lich mit der stringenten Gestaltung
von grafischen Benutzeroberflächen.
Anordnung, Abstand und Verteilung von Beschriftungen, Knöpfen
und Menüs werden standardisiert
und wirken so unterstützend auf den
Endanwender beim Erlernen und
Bedienen des Programms. In Swing
kann das “look-and-feel” während
der Laufzeit geändert werden (vgl.
[5], Kapitel 15.5). Möglich sind
u.a. die Skins “Metal”, “Motif ” und
“Windows”. Aufbauend auf dem
Kern der AWT 1.1 und 1.2 Bibliotheken bietet Swing mehr Möglichkeiten. Ein Fallstrick von Swing kann
die Rendergeschwindigkeit der dargestellten Komponenten sein. Durch
Verwendung von leichtgewichtigen
Komponenten wird der Renderingprozess von der Java Virtual Machine
übernommen. Vor der Entwicklung
Langzeitarchivierung jedoch weitere
Vorschauoptionen für dreidimensionale Inhalte oder hochkomprimierte Videodaten enthalten. Moderne
Grafikkarten können beispielsweise
die Dekodierung von MPEG-4 Videodaten übernehmen . In Hinblick
auf die Zukunftsfähigkeit der GUI
ist das nur einer von wenigen Punkten.
Swing im SOP
Die Benutzeroberfläche des Java Clients des Softwareprojekts war vor
der Umstellung auf SWT in Swing
implementiert. Betrachtet man die
Benutzeroberfläche des Swing Java
Clients genauer, kann man u.a. an
den Dateidialogen und Drop-Down
Menüs feststellen, dass Swing eingesetzt wurde. Obwohl SWT nicht
Teil der Java API ist, bietet es Im-
plementationen für Windows, Mac
OS X und Linux. Die Komplette
Liste kann auf [http://download.eclipse.org/eclipse/downloads/drops/
S-3.5M6-200903130100/index.
php#swt] abgerufen werden.
SWT – Die Zukunft?
Eine eigene Entwicklung verfolgt die
Eclipse Foundation mit SWT, dem
Standard Widget Toolkit. Die Eclipse Foundation wurde Ende 2001
von IBM initiiert und stellt - neben
anderen Produkten - mit der Entwicklungsumgebung “Eclipse” ein
umfangreiches Werkzeug zur Softwareentwicklung bereit (vgl. [6]).
Die grafische Oberfläche von Eclipse ist mit SWT realisiert. Die Einleitung der SWT Webseite erläutert
kurz und bündig: “SWT is an open
source widget toolkit for Java designed to provide efficient, portable
access to the user-interface facilities
of the operating systems on which
it is implemented” (vgl. [7]). SWT
soll garantieren, dass sich GUI Komponenten auf jedem Betriebssystem
korrekt verhalten.
Der Anwender soll das Gefühl haben, dass die Oberfläche des Programms gezielt für sein Betriebssystem entwickelt wurde. Aus der Sicht
des Entwicklers wird jedoch nur eine
Oberfläche mit Hilfe des Standard
Widget Toolkits entworfen (vgl.
[3]). Das Konzept von SWT ist vergleichbar mit dem von AWT: Beide
sind schwergewichtig. Um das LCD
ITERATION++
Problem von AWT zu umgehen, definiert SWT eine Menge an Komponenten, welche für die Entwicklung
vielseitiger Anwendungen ausreicht
(etwa ein Dutzend mehr als im Standardset von Swing (vgl. [2], Kapitel
Swing/SWT Komponentenauflistung)). Nahezu alle Komponenten
können so vom Gastbetriebssystem
nativ dargestellt werden. Zwei Nachteile von AWT und Swing werden
dadurch eliminiert: Komponenten
zeigen sich in dem vom Gastbetriebssystem vorgegebenen Aussehen, beispielsweise Windows Aero,
Mac OS X Aqua oder GTK. Außerdem erfolgt das Rendering in nativer
Geschwindigkeit (vgl. [2]). Die Bibliothek JFace stellt zudem unterstützende Funktionen, für z.B. Event
Handling, bereit. Das Drücken eines Knopfes, das Auswählen eines
Menüpunktes oder ein Tastenkürzel
kann von JFace abgefangen und verarbeitet werden (vgl. [3]).
Aus der Sicht des Entwicklers gibt
es auch Nachteile beim Einsatz von
SWT. Eine Benutzeroberfläche kann
nur nach dem top-down Prinzip
erstellt werden, d.h. ein Kontrollelement kann ohne einen Elterncontainer nicht bestehen. AWT und
Swing ermöglichen eine Entwicklung nach dem top-down und bottom-up Prinzip. SWT Komponenten sind nicht Threadsicher (diesen
Nachteil besitzt auch Swing.), d.h.
der Entwickler muss deshalb kontrollieren, welcher Thread die Ober-
fläche des Programms aktualisiert.
Da SWT und JFace Entwicklungen
der Eclipse Foundation sind, gehören sie nicht zur Java API. Die Installation muss separat vorgenommen
werden und unterstützt eine breite
Auswahl an gängigen Betriebssystemen (Windows, Mac OS X, Linux,
diverse Unices) (vgl. [2], [7]).
Ein interessanter Aspekt ist die Möglichkeit, dass eine Oberfläche sowohl
Swing als auch SWT Komponenten
enthalten kann. Somit ist es möglich die Vorteile beider Toolkits zu
vereinen. Weiterführende Informationen über diese Idee können vom
Webauftritt der Eclipse Foundation
bezogen werden (siehe [8]).
Dieser Fachartikel hat die Java UI
Toolkits zu einem kleinen Teil geschichtlich, und zu einem größerem
Teil technisch erläutert. Die wichtigsten Unterschiede, Stärken und
Schwächen sind ermittelt. Die Transition (Swing nach SWT) der Implementierung der Benutzeroberfläche
des Softwareprojekts ist ausgeführt.
Nur der praxisnahe Einsatz der
Langzeitarchivierung kann zeigen,
ob der Einsatz von SWT letztendlich
die richtige Entscheidung war.
53
IBM (http://www.ibm.com/developerworks/grid/library/os-swingswt/), 2006
[3] Matthew Scarpino, Stephen Holder: SWT/JFace in Aciton, Manning
Publications, 2005
[4] Apple: Apple Human Interface
Guidelines, http://developer.apple.
com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html,
26.04.2009
[5] Pat Niemeyer, Jonathan Knudsen: Learning Java, O’Reilly, 2000
[6] Eclipse.org: About the Eclipse
Foundation, http://www.eclipse.org/
org/, 26.04.2009
[7] Eclipse.org: SWT: The Standard
Widget Toolkit, http://www.eclipse.
org/swt/, 26.04.2009
[8] Eclipse.org: Swing/SWT Integration, http://www.eclipse.org/articles/article.php?file=Article-SwingS W T- I n t e g r a t i o n / i n d e x . h t m l ,
26.04.2009
[9] Anandtech: NVIDIA GeForce
8600: Full H.264 Decode Acceleration, http://www.anandtech.com/
video/showdoc.aspx?i=2977
Quellen
[1] Robert Eckstein, Marc Loy, Dave
Wood: Java Swing, O’Reilly, 1998
[2] Barry Feigenbaum: SWT, Swing
or AWT: Which is right for you?,
54
ITERATION++
Objekte im Winterschlaf
Wie kann Hibernate erfolgreich eingesetzt werden?
Eduard Tudenhöfner
In den letzten Jahren erfreuten sich
objekt-relationale Mapper und speziell
Hibernate immer größerer Beliebtheit.
Bisher wurde im Softwareprojekt der
Hochschule Reutlingen kein objektrelationaler Mapper eingesetzt, ist nun
jedoch seitens des Kunden erwünscht.
Doch was ist objekt-relationales
Mapping? Was sind objekt-relationale
Mapper und welche existieren neben
Hibernate auf dem Open-Source Markt?
Wie kann Hibernate erfolgreich in das
Softwareprojekt eingebunden werden?
Im Softwareprojekt wird ein Langzeitarchivierungssystem für multimediale Inhalte entwickelt. Es wird jeweils
eine Version in Java und in C# programmiert. Dateien verschiedener Art
können durch den Benutzer auf einen
Server hochgeladen werden. Um eine
Datei später wieder zu finden, wird
sie mit Metainformationen (Beschreibung, Typ) versehen. Aus Sicht des
Softwareentwicklers müssen einer Datei Metainformationen eindeutig zugeordnet werden. Hierfür werden diese,
zusammen mit einem Datei-Identifikator, in einer Datenbank gespeichert
und dadurch der Bezug zur Datei hergestellt.
Bisher wird die objektorientierte Datenbank db4o eingesetzt. Geringer
Speicherverbrauch und eine native Implementierung für Java und .NET ermöglichen eine einfache Persistierung
von Objekten (Vgl. [14]). Allerdings
wurde diese Datenbank für eingebettete Systeme entwickelt und erlaubt
keine Administration außerhalb des
Quellcodes. Durch diese Tatsache ist
die Datenbank eng an die Anwendung
gekoppelt und eine Änderung an dieser bedeutet auch eine Anpassung der
Anwendung. Aus diesem Grund hat
die Firma Trésor Secure Systems die
Umstellung auf eine relationale Datenbank beauftragt. Weiterhin soll die
Anwendung von der Datenbank durch
den Einsatz eines objekt-relationalen
Mappers entkoppelt werden.
Objekt-relationales Mapping
Die Transformation vom objektorientierten zum relationalen Programmieransatz wird objekt-relationales
Mapping genannt (Vgl. [13]). Im Detail werden Objekte einer objektorientierten Programmiersprache in eine
Tabelle einer relationalen Datenbank
persistiert. Für das Abbilden der Objekte auf die Tabellen werden Metadaten, in Form von XML Dateien oder
Annotationen verwendet. Beziehungen
zwischen Objekten werden dadurch
auf entsprechende Relationen in der
Datenbank abgebildet.
Ambler ist der Auffassung, dass Mapper
wegen dem Strukturbruch zwischen
den Konzepten der objektorienterten
und der relationalen Welt benötigt
werden. Das objektorientierte Paradigma basiert auf Kohäsion, Kapselung
und Polymorphismus, wohingegen das
relationale Paradigma auf mathematischen Prinzipien wie der Mengentheorie basiert (Vgl. [9]).
Warum Mapper?
Durch einen objekt-relationalen Mapper ist die Anwendung nicht von der
Datenbank abhängig. Anfragen werden
nicht direkt an die Datenbank gestellt,
sondern zuerst an den Mapper. Dieser
übersetzt die Anfrage in den spezifischen SQL Dialekt der verwendeten
Datenbank und leitet die Anfrage weiter. Sendet die Datenbank eine Antwort, so wird diese zuerst an den Mapper und danach an die Anwendung
geleitet. Hier muss bedacht werden,
dass durch den Einsatz eines Mappers
zusätzliche Verzögerungen bei Datenbankoperationen auftreten können.
Durch die zusätzliche Abstraktionsschicht steigt der Grad der Komplexität.
ITERATION++
Abb. 1: Hibernate Architektur
Objekt-relationale Mapper
Welche objekt-relationalen Mapper
existieren auf dem Markt?
OpenJPA ist eine Open-Source Implementierung der Java Persistence API
und wird unter der Apache 2.0 Lizenz
angeboten. OpenJPA ist in Applikationsservern, wie IBM WebSphere und
BEA WebLogic vertreten.
EclipseLink wird von der Eclipse
Foundation kostenlos zur Verfügung
gestellt und ist aus Toplink entstanden. Toplink ist die kommerzielle
Version von Toplink Essentials und
war im Glassfish Applikationsserver
vertreten.
Hibernate wurde von Gavin King als
Open-Source Projekt entwickelt. Das
Ziel war die Publikation eines Frameworks für das objekt-relationale Mapping in Java. Hibernate ist im Umfang
des JBoss Applikationsservers enthal-
Abb. 2: Die Klassen der Metainformationen
ten, kann aber auch ohne Applikationsserver verwendet werden.
In [10] werden die vier meistgenutzten Mapper auf ihre Performance verglichen. Der Autor ist der Meinung,
dass es keinen klaren Sieger bezüglich
der Performance gibt. Einige Mapper
führten zu einer geringen Belastung
der CPU oder des Hauptspeichers,
andere konnten Einfüge- oder Abfrageoperationen schneller ausführen
(Vgl. [10]). Allerdings sind EclipseLink, Toplink Essentials und OpenJPA ausschließlich für Java erhältlich.
Dadurch müsste für .NET ein anderer
Mapper eingesetzt werden, was eine
zusätzliche Einarbeitung und Belastung für die Softwareentwicklung bedeuten würde.
Hibernate ist das einzige Framework,
das sowohl für Java als auch für .NET
zur Verfügung steht. Hibernate hat
eine umfangreiche Entwicklergemeinde und umfassende Literatur.
Rajshekhar ist der Meinung, dass sich
Hibernate durch Flexibilität und Einfachheit von anderen Mappern abgrenzt und dadurch in vielen Projekten eingesetzt wird (Vgl. [13]). Durch
den Einsatz von Hibernate für die Java
und .NET Variante des Langzeitarchivierungssystems, kann die Einarbei-
55
tungszeit auf Hibernate beschränkt
werden. Aus diesen Gründen wird
dieser Mapper für das Softwareprojekt
gewählt.
Hibernate im Einsatz
Hibernate besteht aus Properties und
Metadaten – in Form von XML Dateien oder Annotationen – für das
Mapping. Die grobe Architektur von
Hibernate ist in der Abbildung 1 dargestellt.
Für den Einsatz von Hibernate müssen
die in der Datenbank zu speichernden
Objekte zuerst identifiziert werden.
Im Softwareprojekt sollen die Metainformationen einer Datei persistiert
werden. Ein Auszug aus den entsprechenden Klassen ist in Abbildung 2
dargestellt.
Um Attribute einer Klasse in der Datenbank zu speichern, muss eine Mapping Datei erstellt werden, welche
die entsprechenden Attribute auf die
Spalten einer Tabelle abbildet. MetaInformation hat eine unidirektionale
1:1 Relation zu der Klasse MetaTag (s.
Abb. 2). Mak ist der Ansicht, dass eine
1:1 Relation in Hibernate am einfachsten durch ein <many-to-one> inklusive
dem Schlüsselwort unique umgesetzt
werden kann. (Vgl. [8]).
Abb. 3: Konfigurationsdatei hibernate.cfg.xml
56
ITERATION++
Bevor Klassen persistiert werden können, muss Hibernate durch Properties konfiguriert werden. Es müssen
der verwendete SQL Dialekt, Verbindungsdaten und andere Einstellungen
vorgenommen werden. Als Dialekt
wird PostgreSQLDialect definiert, da
eine PostgreSQL Datenbank verwendet wird. Es werden der Benutzername
und das Passwort, der zu verwendende
Classpath und konfiguriert Hibernate
mit den definierten Einstellungen. Das
Codebeispiel ist unten dargestellt.
Eine typische Anwendung verfügt
laut Minter und Linwood über ein
Configuration-Objekt, das nur bei
der Initialisierung von Hibernate eingesetzt wird. Eine SessionFactory wird
während des gesamten Lebenszyklus
der Anwendung verwendet. Session-
„Durch Persistierung werden Objekte
in den Winterschlaf versetzt“
Eduard Tudenhöfner, Softwareentwicklung
Treiber und die Adresse zur Datenbank angegeben. Zusätzlich werden die
Mapping Dateien der zu persistierenden Klassen definiert (MetaInformation.hbm.xml und MetaTag.hbm.xml).
Die komplette Konfigurationsdatei ist
in Abbildung 3 dargestellt. Wichtig ist,
dass die Konfigurationsdatei im Wurzelverzeichnis des Classpath gespeichert wird, da ansonsten eine Ausnahme ausgelöst wird.
Sessions
Persistenz-Operationen (Abfragen und
Speichern von Objekten) können in
Hibernate mit Session-Objekten ausgeführt werden. Ein Session-Objekt wird
von einer SessionFactory erstellt. Die
SessionFactory wird durch die Configuration Klasse erzeugt. Configuration
sucht die hibernate.cfg.xml auf dem
Objekte werden je nach Bedarf angefordert, um Operationen auf der Datenbank auszuführen (Vgl. [3], S. 35).
Persist It!
Mit einer Session wird ein Objekt in
die Datenbank persistiert. Im unteren
Codebeispiel werden Attribute auf einem MetaInformation-Objekt gesetzt
und danach über die Session gespeiMetaInformation meta =
new MetaInformation();
meta.setMetaValue(metaValue);
meta.setMetaTag(metaTag);
session.save(meta);
session.flush();
session.connection.commit();
session.close();
chert. Durch die Methode save() wird
das übergebene Objekt für die Speiche-
rung markiert. flush() forciert eine Synchronisierung zwischen Session und
Datenbank. Alle neuen oder geänderten Objekte werden dadurch gespeichert. Danach werden die Operationen
bestätigt und die Session geschlossen
(Vgl. [3], S. 88 - 98).
Suchen und Abfragen
Laut Bauer und King gibt es in Hibernate drei verschiedene Möglichkeiten,
um Daten aus der Datenbank abzurufen (Vgl. [6]).
Die Hibernate Query Language (HQL)
ist eine objektorientierte Abfragesprache. Sie ähnelt SQL, arbeitet aber nicht
mit Tabellen und Spalten, sondern mit
persistenten Objekten und ihren Eigenschaften. Um Portabilitätsprobleme
zu vermeiden, sollte HQL für Abfragen
bevorzugt werden (Vgl. [3], S. 221).
Native SQL-Anweisungen können
auch in Hibernate verwendet werden.
Minter und Linwood sind der Auffassung, dass SQL nur nativ genutzt werden sollte, wenn die verwendete Datenbank spezielle Funktionen unterstützt,
die von HQL nicht angeboten werden
(Vgl. [3], S. 239).
Das Hibernate Criteria API erlaubt
das Erzeugen von dynamischen Abfragen zur Laufzeit. Reichert ist der Auffassung, dass das Criteria API speziell
dort eingesetzt werden sollte, wo die
Datenbankabfrage zur Ladezeit noch
nicht feststeht, sondern sich erst dynamisch zusammensetzt (Vgl. [16]).
Allerdings spricht Ferguson Smart die
Probleme an, die mit dem Criteria API
entstehen. Seiner Meinung nach wird
ITERATION++
Quelltext erzeugt, der im Vergleich zu
HQL schwerer lesbar und wartbar ist
(Vgl. [17]).
Fazit
Der Einsatz von Hibernate im Softwareprojekt bedeutet eine nicht zu unterschätzende Mehrbelastung der Softwareentwicklung. Diese Mehrbelastung
bringt jedoch die Vorteile der Entkopplung und erlaubt die Datenbank außerhalb des Quellcodes zu administrieren.
Für nachfolgende Iterationen muss
sichergestellt werden, dass das Wissen
und die Erfahrungen mit Hibernate
weitergegeben werden. Ein erfolgreicher
Wissenstransfer könnte über den Einsatz eines Wikis oder über Schulungen
realisiert werden. Auch wenn Hibernate schnell erlernbar ist, hat es doch eine
hohe Lernkurve, die nicht unterschätzt
werden sollte.
Laut Plöd herrscht in vielen Softwareprojekten der Eindruck, dass Datenbankzugriffe nur durch objekt-relationale Mapper zu implementieren seien.
Plöd ist der Meinung, dass es abseits der
komplexen Mapper auch Alternativen
gibt. Er erwähnt, dass Mapper Extraaufwand und zusätzliche Komplexität insbesondere bei der Integration in
bestehende Systeme – erzeugen (Vgl.
[15]).
Meines Erachtens ist Hibernate die richtige Wahl für das Softwareprojekt der
Hochschule Reutlingen. Der Einsatz
von Hibernate zahlt sich spätestens bei
einem Wechsel der verwendeten Datenbank aus. Damit Hibernate integriert
werden kann, muss allerdings eine Auf-
wandsschätzung stattfinden, damit eine
termingerechte Umsetzung garantiert
werden kann. Zusätzlich sollte die Softwareentwicklung bereits über entsprechende Kenntnisse verfügen.
Quellen
[1] db4objects Inc.: „db4o Datenbank“, http://www.db4o.com, zuletzt
besucht am 13.04.2009
[2] A.P. Rajshekhar: „Managing Transactions with Hibernate“, http://www.
devarticles.com/c/a/Java/ManagingTransactions-with-Hibernate/, zuletzt
besucht am 13.04.2009
[3] Dave Minter, Jeff Linwood: „Einführung in Hibernate“, Heidelberg,
2007
[4] Robert F. Beeger, Arno Haase, Stefan Roock, Sebastian Sanitz: „Hibernate“, Heidelberg, 2007
[5] Michael Plöd: „Objektrelationales
Mapping in der Praxis“, JavaMagazin
03/2006
[6] Christian Bauer, Gavin King: “Java
Persistence with Hibernate”, Greenwich, 2007
[7] Hibernate Team: „Hibernate”,
http://www.hibernate.org, zuletzt besucht am 13.04.2009
[8] Gary Mak: “Hibernate Tutorials:
Many To One and One To One Association”, http://www.metaarchit.com/
hibernate_tutorials/Hibernate%20Tutorial%2004.pdf, zuletzt besucht am
13.04.2009
57
[9] Scott W. Ambler: „Mapping objects to relational databases“, http://
www.ibm.com/developerworks/webservices/library/ws-mapping-to-rdb/,
[10] „JPA comparison: Hibernate, Toplink, OpenJPA, Eclipselink“, http://
www.theserverside.com/news/thread.
tss?thread_id=53142, zuletzt besucht
am 16.04.2009
[11] Apache Foundation: “Apache
OpenJPA”,
http://openjpa.apache.
org/, zuletzt besucht am 16.04.2009
[12] Eclipse Foundation: “EclipseLink”, http://www.eclipse.org/eclipselink/, zuletzt besucht am 16.04.2009
[13] A.P. Rajshekhar: “Introducing
Hibernate”,
http://www.devarticles.
com/c/a/Java/Introducing-Hibernate/,
[14] Ted Neward: “db4o: Introduction
and Overview”, http://www.ibm.com/
developerworks/java/library/jdb4o1.
html, zuletzt besucht am 18.04.2009
[15] Michael Plöd: „Lightweight Persistence: Alternativen zu EJB, Hibernate und JDO“, JavaMagazin 03/2007, S.
18-22
[16] Stefan Reichert: „Hibernate Criteria API: Komplexe Datenbank-Abfragen elegant und flexibel implementieren“, JavaMagazin 03/2007, S. 23-25
[17] John Ferguson Smart: “Hibernate
Querying 102: Criteria API”, http://
www.javalobby.org/articles/hibernateq
uery102/?source=archives, zuletzt besucht am 24.04.2009
58
ITERATION++
Von der „Friday Night Pizza Party“ zum
automatisierten Lasttest
Vererbung mal anders – Wie man erfolgreich Anforderungen des Kunden über
Iterationen ignoriert
Mario Schwarz
Die „Friday Night Pizza Party“, die
den manuellen Test einer Anwendung
mit vielen Benutzern meint, ist laut
Weichselberger [1, Seite 39] klar abzulehnen. Er ist nicht nachvollziehbar, unwirtschaftlich und obendrein
ermüdend für die Tester. Doch warum
wird er dann im Rahmen des Lasttests
immer noch im Softwareprojekt fabriziert? Und weshalb wurde dessen
Automatisierung über Iterationen
weitergereicht? Gibt es hierfür keine Anforderung des Kunden? – Und
ob! Ist es zu komplex? – Nicht unbedingt! Dieser Artikel wird Licht in
das Dunkel bringen, die Vorteile einer Automatisierung aufzeigen, unterstützende Testwerkzeuge auswählen
und evaluieren und Konzepte vorstellen, mit der die Automatisierung des
Lasttests zum Kinderspiel wird.
Bei der Einführungsveranstaltung
warnten uns die Vorgänger, die Automatisierung in unserer Iteration
anpacken zu müssen. Beim initialen
Stöbern durch die erhaltenen Dokumente stachen deshalb besonders die
lasttestbezogenen Inhalte ins Auge.
Hier wurde irgendwann versucht, für
den Wirkbetrieb repräsentative LastSOP JOURNAL HOCHSCHULE REUTLINGEN R6
testszenarien zu definieren. Doch ist
eine an zwei Händen abzählbare zu
simulierende Benutzeranzahl wirklich repräsentativ? – Wohl kaum.
An anderer Stelle waren für den
Lasttest angeblich eingesetzte Testwerkzeuge aufgeführt, von denen jedoch weder die Testabteilung, noch
die Geschäftsleitung wusste, ob und
inwiefern diese jemals zum Einsatz kamen. Im Abnahmetest wurde
letztendlich wie schon so oft schließlich nur ein manueller Test der Last
durchgeführt – Hier bestand dringend Handlungsbedarf.
Warum Automation?
Die im Einleitungsteil angesprochenen Nachteile eines manuellen Tests
berücksichtigen nach [1, Seite 39]
bisher nur den lasttreibenden Aspekt
des Lasttests. Ignoriert wurden bisher
essentielle Funktionen eines Lasttests. Hierunter fallen zum Beispiel
die Steuerung des Lastlaufverhaltens
(Ramp-Up bzw. Ramp-Down), die
Überwachung der Systemkomponenten (Monitoring) sowie die Analyse gesammelter Kennzahlen.
In der Vergangenheit wurden all
diese Komponenten im Lasttest des
Softwareprojektes vernachlässigt. Es
wurde mehr oder minder nur wild
auf den Tastaturen und Mäusen
mehrerer Rechner herum gehämmert
und geklickt. Falls die Anwendung
noch irgendwie reagierte, war der
Lasttest mit Bravour gemeistert. Eine
automatisierte Variante hingegen
wäre nachvollziehbar. Anhand des
automatisch ausgeführten Testplanes
ist penibel jedes Detail des Testlaufs
festgelegt und ersichtlich. Zudem
können gemessene Kennzahlen gegen die Kundenanforderung, z.B. im
Hinblick auf das Antwortverhalten
bei der zu erwartenden Benutzeranzahl, verglichen und objektiv entschieden werden ob der Test bestanden wurde oder nicht.
Return On Investment
Halili greift in [2] einen Artikel von
Rex Black auf, der anhand eines Fallbeispiels den Return On Investment
(ROI) potenzieller Teststrategien,
also die Rentabilität der jeweilig notwendigen Investitionen, analysiert.
Im Original werden manuelles und
automatisiertes Testen mit kostenpflichtigen Werkzeugen gegeneinander aufgewogen.
Sie erweitert die automatisierte Teststrategie unter Berücksichtigung von
kostenfreien
Open-Source-Werkzeugen. Dies maximiert den ROI
ITERATION++
einer automatisierten Teststrategie
und resultiert somit in einer raschen
Amortisation der angefallenen Kosten. Die angenommenen Daten im
Fallbeispiel übersteigen zwar bei weitem den Rahmen des Softwareprojektes. Dennoch kann hieraus das
Fazit gezogen werden, dass sich eine
Automatisierung, insbesondere unter
Einsatz kostenloser Testwerkzeuge
lohnt und folgenden Iterationen zu
Gute kommt.
Vergleichsmethodik der Testwerkzeuge
Nach [3] sind mehrere Methoden
zum Vergleichen von Alternativen
geläufig:
• Der vollständige Vergleich, bei
dem eine jede Alternative mit
allen anderen im direkten Vergleich gegenübergestellt wird
• Die Vereinigung, bei der alle
Funktionen aller Lösungen in
einem Quasi- Standard zusammengeführt werden und gegen
welchen dann jede Alternative
verglichen wird
• Der auf projektbezogenen Anforderungen basierende Vergleich
Als für das Softwareprojekt zutreffendste Methodik stellte sich letztere
heraus, da es sich um ein gewöhnliches Projekt mit vom Kunden gestellten Anforderungen handelt. Der
iterative Ansatz kann hier vernachlässigt werden.
Anforderungen an das Testwerkzeug
Mit Anforderungen sind in diesem
Kontext nicht nur die des Kunden,
sondern auch die architektonischen
Gegebenheiten der zu testenden
Langzeitarchivierungssoftware
gemeint.
Die Langzeitarchivierungssoftware
basiert auf einer Service-orientierten
Architektur (SOA). Axis (v.1) wird
hierbei als Java-Servlet innerhalb des
Servlet-Containers Apache Tomcat
betrieben. Dieser bietet die Web Services zur Verwendung von Clients
an. Selbstverständlich ist die Unterstützung von WebServices deshalb
unerlässlich für das Werkzeug. Darüberhinaus wurden in [1] genannte
Bewertungskriterien aufgegriffen und
angepasst:
• Minimale Anschaffungskosten
• Hoher Marktanteil
• Aufzeichnen und einfache Anpas-
sung eines Testplanes
• Steuerung des Lastlaufs
• Monitoring des Zielsystems
• Analyse der Kennzahlen
59
sind Open-Source und stehen kostenfrei zum Herunterladen bereit. Sie
besitzen den gleichen Funktionsumfang und decken beide die Anforderungen vollständig ab. Beide bieten
eine Programmierschnittstelle (API),
über die Erweiterungen implementiert werden können.
Aus der Performance-Studie der Firma CodeCentric [4] geht die Marktführerschaft von JMeter unter den
Befragten hervor. Ein weiterer Pluspunkt für JMeter ist die Erstellung
eines Testplanes mittels der Benutzeroberfläche. Bei The Grinder werden
diese in der Skriptsprache Jython
programmiert, was für die Erlernbarkeit nachteilig ist. Aus den ausgeführten Gründen fiel die Wahl letztlich
auf JMeter.
JMeter
JMeter ist eine auf Java-basierte
Desktop-Anwendung und zeichnet
sich durch die grafische Erstellung
eines Testplans aus. Ein solcher Testplan besteht aus einem oder mehreren der folgenden Elemente:
Die mögliche Verteilung der Lastgeneratoren wird darüberhinaus vorausgesetzt. Zudem sollten Automatisierungsmechanismen umsetzbar
sein und eine schnelle Erlernbarkeit
gewährleistet sein.
Evaluation
In die nähere Auswahl gelangten das
Sourceforge-Projekt The Grinder und
Apache JMeter. Beide Alternativen
60
ITERATION++
In der ThreadGroup werden die Anzahl der virtuellen Benutzer und das
Lastlaufverhalten (Ramp-Up) definiert. Sie stellt den Wurzelknoten eines Testplans dar.
Listener erlauben den Zugriff auf
gesammelte Informationen. Sampler
senden Anfragen an den zu testenden
Server. Deren Logik kann mittels Logical Controllers angepasst werden.
Timer werden für Verzögerungen,
z.B. als Simulation von Denkzeiten
Informationen aller Generatoren zentral zur Analyse ein. Eine Automatisierung lässt sich in Verbindung mit
dem Build- Werkzeug Apache Ant,
wie in [5] ausgeführt, erreichen.
Arbeitsverweigerung oder nicht?
Doch woher rührt nun die bisherige
Quasi-Arbeitsverweigerung der Testabteilung im Bezug auf die Lasttestautomatisierung – sind die Tester zu
faul?
„Der geeignete Zeitpunkt muss zuerst
geschaffen werden!“
Mario Schwarz, Softwareentwicklung
eingesetzt. Assertions ermöglichen
die Überprüfung der tatsächlichen
Rückgabewerte der Anwendung gegen erwartete Rückgabewerte. Configuration Elements können Anfragen
von Samplern modifizieren.
Konzept
Mit Hilfe der Sampler-Komponente
WebService(SOAP)Request können
Anfragen an WebServices gesandt
werden. Über das Starten von JMeter von der Kommandozeile kann das
Programm mit Parametern versorgt
werden. Hierüber können mehrere
entfernte Lastgeneratoren anhand
ihrer IP-Adresse identifiziert werden.
Der aufrufende Rechner dient dann
als Steuerzentrale und sammelt die
Aus meiner Erfahrung in der Testabteilung und aus Gesprächen mit
Vorgängeriterationen gibt es einfach
keinen geeigneten Zeitpunkt für dessen Umsetzung. Der iterative Ansatz
des Softwareprojekts macht einem
hier das Leben schwer. Im ersten
Semester macht einem der ungenügende Kenntnisstand über die Architektur einen Strich durch die Rechnung - die Einarbeitungszeit in die
in der Langzeitarchivierungssoftware
verwendeten Technologien ist hoch.
Als Seniors machen sich dann meist
hochmotivierte Softwareentwickler
daran, den Code umzukrempeln, den
sie nach einem Semester nun verstehen.
Diese Implementierungsdauer zieht
sich erfahrungsgemäß bis wenige Wochen vor Semesterende hinaus. Das
macht eine Lasttestautomatisierung
danach unmöglich. Hätte man andererseits die Automatisierung zuvor
fertiggestellt, wäre sie gewiss nicht
mehr lauffähig.
Fazit
Es gibt nur einen Lösungsansatz wie
der Lasttest in naher Zukunft doch
noch automatisiert werden kann:
Einen lauffähigen Versionsstand des
Backends für ein Semester einfrieren
und Refactoring währenddessen zu
unterbinden!
In dieser Zeitspanne könnte die gesamte Test-, sowie Mitglieder der
Softwareentwicklungsabteilung an
der Umsetzung des automatisierten
Lasttests mitwirken. Die Vorgängeriteration könnte ihr gesammeltes
Wissen praktisch einbringen; die
Nachfolger würden von der engen
Zusammenarbeit und dem dabei
stattfindenden Wissenstransfer profitieren. Beim Iterationswechsel wären die Nachfolger für ein künftiges
Refactoring samt notwendiger Änderungen am automatisierten Lasttest
gewappnet und die Tester und die
Entwickler wären durch die gemeinsame Arbeit zusammengeschweißt.
Quellen
[1] Weichselberger, Alexander – „A
Fool with a (Loadtest-) Tool is still a
Fool! “, JavaMagazin, 08/2005
ITERATION++
[2] Halili, Emily H. – „Apache JMeter “, Packt Publishing, 2008
[3] Barcia, Roland / Hambrick
Geoffrey / Brown, Kyle – „Persistence
in the Enterprise: A Guide to Persistence Technologies“, Prentice Hall
International, 2008
[4] Dr. rer. nat. Raymond Georg
Snatzke – „Performance Studie
2008”, http://www.codecentric.de/
export/sites/www/_resources/pdf/
performance-studie-2008-web.pdf
[5a] Duvall, Paul – „Persistence in
the Enterprise: “Automation for the
people: Hands-off load testing - Use
Apache JMeter with Apache Ant to
run load tests frequently”, http://
www.ibm.com/developerworks/java/
library/jap04088/index.html
[5b] Harrold, Mary Jean / Jones,
James A. / Li, Tongyu / Liang, Donglin / Orso, Alessandro / Pennings,
Maikel / Sinha, Saurabh / Spoon, S.
Alexander / Ashish, Gujarathi – „Regression Test Selection for Java Software“, ACM Digital Library, 2001
[6] Nevedrov, Dmitri – „Using
JMeter to Performance Test Web
Services“,citeseerx.ist.psu.edu, 2006
61
[10] Linwood, Jeff – „JMeter: Performance Testing Server-Side Java“,
http://www.ddj.com/linux-opensource/184405128, 2002
[11] Hansen, Kelt – „Load Testing
your Applications with Apache JMeter
“,http://javaboutique.internet.
com/tutorials/JMeter/, 2004
[12] JMeter Homepage , jakarta.apache.org/jmeter/
[7] Dobson, Jamie – „Performance
Testing on an Agile Project “,IEEE
Computer Society, 2006
[8] Weichselberger, Alexander –
„Wie viel ist viel? 42! “, JavaMagazin,
08/2005
[9] Heider, Martin – „Hochseetauglich
mit JMeter “, JavaMagazin, 08/2005
»The nice thing about standards is that there are
so many of them to chose from.«
Andrew S. Tanenbaum, Informatiker
62
ITERATION++
Effektive Organisation des Abnahmetests
Die Rolle des Abnahmetests in einem iterativen Softwareentwicklungsprozess
Natalia Zyleva
Der Abnahmetest ist ein wichtiger
Bestandteil eines Softwareprojekts.
Dieser Test dient dazu, dem Kunden
mit dem Probelauf eines entwickelten Softwareprodukts zu zeigen, dass
seine Anforderungen an das Produkt
erfüllt sind und das Produkt übernommen werden kann. Welche
Erwartungen sollten bei einem idealen Abnahmetest erfüllt werden?
Wie kann man die Kunden dazu
bringen, die erstellte Software ohne
Zeitverzögerungen abzunehmen? Ist
dies möglich und wie viele Ressourcen
würde das Entwicklungsunternehmen
investieren müssen? Lohnt es sich, die
Qualität immer auf einem hohen
Niveau zu halten oder darf man ab
und zu die Softwarequalität etwas
vernachlässigen? Wie sollte ein effizienter Abnahmetest in einem iterativen
Projekt durchgeführt werden? Alle gestellten Fragen sind Meilensteine des
Projekts, die das Testing-Team zum
Nachdenken und späteren erfolgreichen Realisation des Abnahmetests
bringen sollen.
Der Softwareentwicklungsprozess
ist normalerweise mit dem Bestehen des Abnahmetests und der ProSOP JOURNAL HOCHSCHULE REUTLINGEN R6
duktübergabe beendet. Die Software
wird während ihrer Verwendung
qualitative Veränderungen benötigen, was natürlich vom Kundenbedarf her in direkter Abhängigkeit
steht. Dabei entsteht eine Reihe von
Softwareversionen. Weil jede neue
Programmerscheinung auch vom
Kunden abgenommen werden sollte, muss in jeder Iteration der Inhalt
und die Strategie des Abnahmetests
von der Softwareentwicklung verändert werden. Man kann diese Tests
in drei Kategorien unterteilen:
- Testen nach Softwarewartung
(Produkt wird an neue Einsatzbedingungen angepasst)
- Testen nach Weiterentwicklung
(Produkt wird weiterentwickelt
oder verändert)
- Testen bei inkrementeller Entwicklung (Produkt wird als geplante Abfolge von Versionen erstellt) (vgl. [3])
Je nach Priorität werden diese für die
Herstellung des Endprodukts eingesetzt und die jeweilige Folge der
Abläufe beim Abnahmetest durchgeführt.
Im iterativen Softwareprojekt (SOP)
sollten alle obengenannten Gründe
vorkommen. Die Studierenden jeder
Nachfolgeriteration werden veränderte Kundenanforderungen an das
Produkt stellen, wodurch die Funktionalität ständig erweitert wird und
Fehler und Ausfälle somit vermieden
werden. Die Durchführung des Abnahmetests am Ende jeder iterativen
Projektphase erlaubt die frühzeitige und regelmäßige Anpassung an
Kundenerwartungen und ermöglicht
somit die Rückmeldung der Verbesserungsvorschläge an die kommende
Iteration.
Der Abnahmetest gilt als ein Abschlusstestverfahren.
„Ein
Abnahmetest ist ein von dem/den
Anwender(n) und Systemadministratoren in einer möglichst „produktionsnahen“ Umgebung ausgeführter Test, der nachweisen soll, dass das
entwickelte System den funktionalen und qualitativen Anforderungen
entspricht“.(vgl. [2]) Im Rahmen des
Softwareprojekts können die folgenden Testarten bei der Produktübergabe durchgeführt werden:
- Hardwaretest (prüft die Geltung
der technischen Bedingungen für
den reibungslosen Softwareablauf ),
- Installationstest (prüft die Korrektheit des Installationsvorgangs),
ITERATION++
- Benutzbarkeitstest (Test auf Benutzerakzeptanz),
- Lasttest (prüft die Lastmöglichkeiten des gesamten Systems),
- Abnahmetest (Test auf vertragliche Akzeptanz).
Bei der Produktübergabe geht es
nicht nur um die Qualität und Feh-
Freiraum für Akzeptanztestherstellungen gibt (vgl. [4]).
Um die volle Effektivität des Tests zu
erzielen, sollten auch nichttechnische
Aspekten berücksichtigt werden, wie
beispielsweise Zeitbedarf, Kommunikationsaspekte (zwischen Kunden
und Anwender, Entwicklern und
„Testing hat ähnliche Wurzeln wie Management.
Die Testverfahren sollen gut geplant werden, damit unsere Produkte sich gut verkaufen lassen.“
Natalia Zyleva, Testing
lerfreiheit der Software, sondern
auch um Kostenfragen. Im Abnahmetest werden alle gegebenen Kundenanforderungen
berücksichtigt
und überprüft, ob diese in der abgenommenen Produktversion erfüllt worden sind. In solch einem
Fall sind die eventuell vorhandenen
Fehler in der Implementierung nicht
von Bedeutung. Theoretisch müssten diese Fehler bereits von Softwareentwicklern beseitigt worden
sein. Der Gesamteindruck des Softwareproduktes ist hierbei von entscheidender Bedeutung. Dabei spielt
das Managementvorhaben für das
Entwicklungsprojekt schon in der
Planungsphase eine große Rolle. Der
Abnahmetest sollte schon während
der Designphase eingeplant werden,
da zu diesem Zeitpunkt bereits ein
grobe Entwurf des Produktes besteht
und Kunden sowie Management den
Testern, Testern und Management),
Zielsetzung des Projekts, persönliche
Fähigkeiten und Kenntnisse der Tester und der Einsatz von verschiedenen Werkzeugen.(vgl. [4]).
Auch bei der Produktübergabe spielt
der Abnahmetest eine große Rolle.
Von der rechtzeitigen, inhaltlichen
und zeitlichen Planung dieses Tests,
hängt der gesamte Entwicklungsprozessablauf ab. Besonders gut
kann man dies bei dem iterativen
Softwareprojekt der Hochschule
betrachten. Die Mängel des Testvorbereitungsprozesses spiegeln sich
später bei der Produktübergabe im
Bezug auf Kostenerhöhung für das
Entwicklungsunternehmen
und
Stammkundenbildung wider. Der
Abnahmetest sollte die Philosophie
des Unternehmens im Sinne der Effizienz und Qualität repräsentieren.
63
Quellen
[1] Orgel, Thomas. Testcasemanagement. Testen von Softwareprodukten in Projekten, Saarbrücken:
VDM Verl. Dr.Müller, 2008.
[2] Pol, Martin,: Management und
Optimierung des Testprozesses: ein
praktischer Leitfaden für erfolgreiches Testen von Software mit TPI
und TMap/Martin Pol; Tim Koomen; Andreas Spillner. – 2., aktual. Aufl.,Heildelberg: dpunkt-Verl.,
2002.
[3] Spillner, Andreas. Basiswissen
Softwaretest - Testmanagement:
Aus- und Weiterbildung zum Certified Tester - Advanced Level nach
ISTQB-Standard, 3., überarb. und
aktual. Aufl., Heidelberg: dpunktVerl., 2005.
[4] Thaller, Georg Erwin. SoftwareTest: Verifikation und Validation, 2.,
aktual. und erw. Aufl..-Hannover:
Heise, 2002.
64
ITERATION++
Qualität erzeugen, nicht erprüfen!
Audits im SOP - Durchführung und Notwendigkeit
Sarah Letzgus
kann ein Zustand der Verbesserung
erreicht werden (siehe Abb. 1). Denn
Ein Audit ist nicht einfach nur eine
wenn die Zeitabstände zu groß wer-
Prüfung. Es gibt einem Unternehmen
den, kann nur das Qualitätsniveau
die Möglichkeit, Schwachstellen zu er-
erreicht werden, das anhand des vo-
kennen und daraufhin Verbesserungen
rigen Audits entstanden ist und man
vorzunehmen. Auch im Softwareprojekt
erzielt keine andauernde Verbesse-
(SOP) der Hochschule Reutlingen wer-
rung (siehe Abb. 1).
den in jeder Iteration Audits durchgeführt. Im Folgenden wird näher auf
Audits im SOP
die Durchführung der Audits im SOP
Auch im Rahmen des Softwarepro-
eingegangen, sowie die Relevanz und
jekts (SOP) wurden bereits von drei
mentationsanforderungen, wie z.B.
Notwendigkeit von Audits erläutert.
Vorgängeriterationen
regelmäßig
die Lenkung von Aufzeichnungen
Verbesserungsvorschläge sollen helfen,
Systemaudits und von der letzten Ite-
und Dokumenten. Die vorhande-
die Audits besser in das Softwareprojekt
ration auch ein Prozessaudit durch-
nen Dokumente, wie Richtlinien,
zu integrieren.
geführt. Dabei legt jedes Audit sei-
müssen nach Gültigkeit, Wieder-
nen Schwerpunkt auf verschiedene
auffindbarkeit und Angemessenheit
Nach [3, S.9] gibt es drei verschie-
Bereiche. Bei der Durchführung des
bewertet werden. Auch die „Verant-
dene Arten von Audits, die mit dem
Systemaudits im SOP stand die Be-
wortung der Leitung“ wird über-
allgemeinen
Qualitätsaudit
urteilung des Qualitätsmanagement-
prüft und behandelt, u.a. mit den
bezeichnet werden: Das System-,
systems, anhand der ISO 9001:2000
Punkten Kundenorientierung und
Prozess- und Produktaudit. Um die
[2] im Mittelpunkt der Bewertung.
Qualitätspolitik. Ein Punkt der Qua-
Zertifizierung eines Unternehmens
Um einen Überblick über den Zu-
litätspolitik wäre, zu ermitteln, ob
zu erreichen, wird ein funktionie-
stand der jeweiligen Unternehmens-
das QM-Handbuch des Projekts alle
rendes Qualitätsmanagementsystem
bereiche zu erlangen, wurden rele-
Qualitätsziele beinhaltet. Ein weite-
(QMS) vorausgesetzt. Audits tragen
vante Bereiche des Projekts, die zur
rer wichtiger Bereich der Überprü-
dazu einen wichtigen Teil bei, da sie
Zertifizierung nach der ISO-Norm
fung liegt in der Arbeitsumgebung/
zur Verbesserung, sowie auch zur
dienen, von der Qualitätssicherung
Infrastruktur und der Bereitstellung
Instandhaltung eines Management-
festgelegt und überprüft. Dazu ge-
von Ressourcen. Es soll sichergestellt
systems dienen. Doch nur durch die
hören die allgemeinen Anforderun-
werden, dass alle benötigten Arbeits-
regelmäßige Ausführung von Audits
gen an das QMS, sowie die Doku-
geräte und Anforderungen in jeder
Titel
Abb. 1: Erfolg der Audits, Sägezahneffekt
ITERATION++
65
Abteilung vorhanden sind und ein er-
zu erstellen, wurde über zwei Iterati-
sichergestellt und auch auf Schwach-
folgreiches Arbeiten ermöglicht wird.
onen nicht erfüllt und man sieht kei-
stellen hin überprüft werden. Dafür
Der letzte Punkt dient der „Messung,
ne Verbesserung der Situation. Dies
wurden zwei, von der Vorgängeritera-
Analyse und Verbesserung“. Dazu
liegt in erster Linie an der fehlenden
tion schon festgelegte Prozessmodelle
zählen beispielsweise die Kunden-
Kommunikation innerhalb der ver-
verwendet, die bei Änderungsmaß-
und Mitarbeiterzufriedenheit, die
schiedenen Abteilungen. Doch auch
nahmen eingesetzt werden. Im SOP
anhand von Befragungen überprüft
nach den ersten Versuchen, mit den
wurde damit der Änderungswunsch
werden können. Zusätzlich werden
entsprechenden Abteilungen eine
der Testing-Abteilung, eine neue GUI
abgeschlossene Tätigkeiten der Qua-
Auswahl des geeigneten Systems zu
(grafische Benutzeroberfläche) zu er-
litätssicherung und deren Ergebnisse
finden, wurde keine endgültige Ent-
stellen, überprüft. Doch um die Pro-
mit den vorliegenden Normen abge-
scheidung getroffen. Die Recherche
zessaudits zu vervollständigen, müssen
glichen. So muss die Durchführung
der benötigten Informationen als
noch weitere Prozesse innerhalb des
und Auswertung einer Mitarbeiter-/
Entscheidungshilfe, wurde aufgrund
SOP definiert und festgehalten wer-
Kundenzufriedenheit oder die Teil-
mangelnder Motivation vernachläs-
den. Desweiteren wäre es noch denk-
nahme an einem Abnahmetest, sowie
sigt und es kam zu keinem Ergeb-
bar, das Produktaudit hinzu zu ziehen,
das Erstellen des Abnahmeprotokolls
nis. Wie also geht man vor, um den
bei dem die „fertigen Produkte auf
auf Richtigkeit kontrolliert werden.
gewünschten Effekt eines Audits zu
Übereinstimmung mit den vorgegebe-
Bei der Betrachtung der letzten Sys-
erzielen und die Audits besser in das
nen Spezifikationen“ [3, S.11] unter-
tem-Audit-Ergebnisse wurden in den
Softwareprojekt zu integrieren?
sucht werden. Dabei könnte im SOP
meisten Bereichen die geforderten
aus Sicht der Kunden geprüft werden,
Verbesserungsmaßnahmen erfüllt. So
Es ist sinnvoll, das Systemaudit, je
ob alle Anforderungen an das Produkt
wurden beispielsweise wichtige Do-
nach Umfang der Anforderungen,
erfüllt worden sind.
kumente, wie das Qualitätshandbuch
mehr als einmal pro Iteration durch-
von der Vorgängeriteration verfasst
zuführen. Ein zweites Audit bietet die
Doch macht es überhaupt Sinn, in
und der Fragebogen zur Mitarbeiter-/
Möglichkeit, die ausgeführten Verbes-
einem Planspiel, wie dem SOP, Au-
Kundenzufriedenheit
vervollstän-
serungen noch einmal zu überprüfen
dits durchzuführen? Wie in jedem
digt. Vorhandene Richtlinien wurden
und zu bestätigen, aber auch um neue
anderen Unternehmen, arbeiten auch
erweitert und in jeder Iteration wur-
Mängel aufzudecken. Doch um die
im SOP alle verschiedenen Abteilun-
den immer wieder neue Richtlinien,
Zertifizierung nach der ISO-Norm
gen an dem Fortschritt des Projekts.
zum reibungsloseren Ablauf des Pro-
9001:2000 zu erhalten, mit der die
Durch die verschiedenen Aufgaben,
jektes, verfasst. Auch bei der Über-
Anforderungen an ein funktionieren-
die jede Abteilung zu erfüllen hat,
wachung von Prozessen wurden neue
des QMS nachgewiesen werden kön-
treten auch hier immer wieder Män-
Messziele mit den Kunden festgelegt.
nen [3, S.27], müssen noch weitere
gel oder Schwachstellen auf. So ist es
Andererseits wurden auch Bereiche
Audits ausgeführt werden. Der erste
auch im SOP sinnvoll, regelmäßig
außer Acht gelassen und erschweren
Schritt in diese Richtung wurde mit
Audits durchzuführen und effektive
so den Entwicklungsprozess im Pro-
der Ausführung des Prozessaudits ge-
Verbesserungsmaßnahmen vorzuneh-
jekt. Beispielsweise die Anforderung,
macht. Dabei soll die Wirksamkeit
men, um das Projekt kontinuierlich
ein Dokumentenmanagementsystem
der eingesetzten Prozesse im Projekt
zu optimieren und voranzutreiben.
66
ITERATION++
Verbesserung der Audits
litätshandbuches. Es erleichtert den
mit den Verbesserungsvorschlägen
Doch durch den ständigen Wechsel
Projektteilnehmern das Arbeiten im
konfrontiert werden, sondern auch
der Iterationen im SOP wird das Er-
SOP, da sie es als Nachschlagewerk
mit den positiven Auswirkungen, zu
reichen einer andauernden Verbes-
benutzen können um die benötigten
denen die Audits verholfen haben.
serung erschwert. Und zwar in Hin-
Informationen zu erhalten. Doch im
Bei der Durchführung eines Au-
sicht darauf, dass das Risiko besteht,
SOP ist die Wichtigkeit von Audits
dits kann auf verschiedene Unter-
dass Audit-Ergebnisse und somit
zu den Projektteilnehmern noch
suchungsmethoden zurückgegriffen
auch die erforderlichen Verbesse-
nicht vollständig durchgedrungen.
werden [1, S.53]. Bisher wurde im
rungsmaßnahmen nicht vollständig
Man weiß zwar von den Schwachstel-
SOP nach der Element bzw. Kapitel-
an die abzulösende Iteration überge-
len und hört von den Verbesserungs-
orientierung auditiert [1, S.57]. Das
ben werden. So sollten noch ausste-
vorschlägen, doch wenn man nicht
heißt, dass sich der Fragenkatalog
hende Verbesserungen gleich zu Beginn an die neue Iteration übergeben
werden, um das Beheben der Mängel
so schnell wie möglich zu beseiti-
„Wer fragt, der führt!“
gen. Doch dort könnte das Problem
Sarah Letzgus, Qualitätssicherung
entstehen, dass sich die Bearbeitung
dieser Mängel zu sehr in die Länge
zieht. Nämlich aus dem Grund, dass
die Studenten der neuen Iteration
sich erst einmal in ihre Rolle im SOP
selbst davon betroffen ist oder davon
an die ISO 9001:2000 anlehnt und
zurechtfinden und einarbeiten müs-
profitieren kann, wird der Effekt der
die Wirksamkeit und Funktionalität
sen. So wäre es sinnvoll, die Audits
unternommenen Aktionen gar nicht
des QMS anhand dieser Norm ge-
gleich am Anfang jedes zweiten Pro-
wahrgenommen. Ein gutes Beispiel
prüft wird. Wie bereits im Abschnitt
jektsemesters durchzuführen, damit
dafür wäre die Bereitstellung von
„Audits im SOP“ erwähnt, werden
noch genügend Zeit für diese Itera-
Ressourcen für die Softwareentwick-
dabei alle Bereiche, die für das SOP
tion besteht, die Schwachstellen in
ler. Werden in dieser Abteilung dem-
relevant sind, abgedeckt. Denkbar
den Griff zu bekommen.
entsprechende
Verbesserungsmaß-
wäre auch die Methode, in denen
nahmen vorgenommen, profitiert auf
das Audit differenziert nach Abtei-
„Interne Audits lohnen sich erst,
den ersten Blick nur die Softwareab-
lungen durchgeführt wird [1, S.58].
wenn etwas mit ihnen im Unterneh-
teilung davon. Doch natürlich pro-
Dabei werden die Ergebnisse der ein-
men bewirkt und verbessert wird“ [4,
fitiert das ganze SOP davon, denn
zelnen Abteilungen erstellt und da-
S.1]. Erst nach dem Eintreten dieser
wenn alle benötigten Einrichtungen
nach für das gesamte Unternehmen
Aussage und dem Feststellen der Ver-
vorhanden sind, um erfolgreiche
zusammengetragen. Ein für das SOP
besserungen, wird ein Unternehmen
Produkte herzustellen, führt dies zur
ebenso vorstellbares Konzept wäre
die Audits loben. Ein Beispiel dafür
Kundenzufriedenheit und somit zum
in Form eines Workshops [1, S.59].
wäre die Erstellung von neuen Richt-
Erfolg eines Unternehmens. Darum
Hierbei findet das Audit in einer Art
linien, sowie das Aufbauen des Qua-
sollte das komplette SOP nicht nur
Review statt, wovon ein Auditbericht
ITERATION++
mit den zu erfüllenden Maßnahmen
Denkbar wäre ebenso der Versuch,
erstellt wird. Der Unterschied zu ei-
eine andere Auditform in das SOP
nem normalen Review besteht darin,
mit einzubeziehen. Dadurch könn-
dass nicht alle Projektbeteiligten der
te erreicht werden, dass durch diese
Iteration anwesend sind, sondern nur
neue Untersuchungsform die Forde-
die Personen die beispielsweise an ei-
rungen schneller umgesetzt werden.
nem Prozess beteiligt sind. So kön-
Doch diese Punkte erreichen nur
nen auftauchende Schwachstellen
dann ihren vollen Nutzen, wenn alle
besser von den Auditoren innerhalb
Projektteilnehmer diese Verbesse-
dieser Runde hinterfragt werden und
rungsvorschläge ernst nehmen. Jeder
effektivere
Verbesserungsmaßnah-
sollte daran mitarbeiten den jewei-
men eingeholt werden. Gerade bei
ligen Zustand zu verbessern, sowie
Produktentwicklungen oder bei der
die Entwicklung danach weiterhin
Einführung von neuen Prozessen
zu verfolgen. Denn „Hauptsache ge-
wird dieses Verfahren bevorzugt.
prüft“ ist nicht der Sinn eines Audits.
Fazit
Quellen
Es ist durchaus sinnvoll, in einem
[1] Gietl Gerhard, Lobinger, Wer-
Planspiel wie dem SOP, Audits
durchzuführen. Es sollte weiterhin
daran gearbeitet werden, die Zertifizierung nach ISO 9001:2000 zu
erreichen. Dafür müssen in naher
Zukunft, zusätzlich zu den System-
ner: Qualitätsaudit: Planung und
Durchführung von Audits nach
DIN EN ISO 9001:200, München
/ Wien: Carl Hanser Verlag, 2003
[2] Qualität & Norm - ISO
und Prozessaudits, in regelmäßigen
9001:2000, www.iso9001.qmb.info
Abständen Produktaudits hinzugezo-
[3] Kamiske Gerd F., Brauer Jörg-
gen werden. Wichtig ist, dass auf die
regelmäßige Ausführung der Audits
Wert gelegt wird, denn nur so kann
ein Zustand der Besserung erreicht
werden. Je nach Bedarf und Umfang
der Anforderungen können Systemaudits auch zweimal pro Iteration
durchgeführt werden. So kann überprüft werden, ob Verbesserungsmaß-
67
Peter: ABC des Qualitätsmanagements, München: Carl Hanser Verlag, 2008
[4] Interne Audits, www.qm-online-forum.de/sub2/download/12_
Das_Kompendium_zum_QM_
STUFEN-MODELL_Kapitel_5_1.
pdf
nahmen angestrebt wurden und es
können, wenn vorhanden, auch neue
Schwachstellen aufgedeckt werden.
68
ITERATION++
Zertifizierung im Softwareprojekt
Der lange Weg bis zur Zertifizierung!
Flavia Di Laudo
Die Zertifizierung ist mittlerweile zum
Standard geworden, um zu zeigen und
zu bestätigen, dass das Unternehmen
fähig ist, ein Qualitätsprodukt oder
eine -dienstleistung zu liefern.
Durch eine Zertifizierung zeigt
der Betrieb, dass er sich in Sachen
Qualität kundig gemacht hat und über
Verfahren verfügt, die zu einer bestmöglichen Qualität für Produkte und
Dienstleistungen führt. Ebenfalls müssen
die Prozessabläufe so ausgelegt sein, dass
sie die Kundenzufriedenheit verbessern.
Wie könnte so eine Zertifizierung im
SOP aussehen und ablaufen?
Wofür ein QM-System?
Ein
Qualitätsmanagementsystem
(QM) stellt Anforderungen, die auf
alle Bereiche des Geschäftsprozesses
anzuwenden sind. Sie zeigen die Anforderungen an ein Qualitätshandbuch und auf welche Weise Dokumentationen sowie Aufzeichnungen
angewendet und gelenkt werden
sollen. Neben den gestellten Forderungen und Spezifikationen an das
zu liefernde Produkt wird heutzutage zusätzlich ein Nachweis über
ein funktionierendes QM-System
verlangt. Diesen Nachweis kann das
Unternehmen beispielsweise durch
ein Systemaudit erbringen, welches
vom Kunden durchgeführt wird.
Von größerer Wichtigkeit ist in dieser Relation allerdings die von einer
unabhängigen, glaubwürdigen Stelle vorgenommene Bewertung der
Effektivität des QM-Systems. Eine
staatlich zugelassene Zertifizierungsstelle führt das sogenannte Zertifizierungsaudit durch. Nach Bestehen
dieses Audits erhält das Unternehmen ein entsprechendes Zertifikat.
Aufgrund dieses Verfahrens ist es
einem Unternehmen möglich, mehreren Kunden durch nur ein Audit
Vertrauen in sein QM-System zu geben. Die Zahl der Unternehmen die
sich nach diesem Verfahren zertifizieren lassen ist in den letzten Jahren
stark angestiegen. Eine genaue Zahl
lässt sich hier nicht festmachen, da
es einige Zertifizierungen in den
Bereichen der Automobilindustrie,
Umweltmanagement, Gesundheitswesen etc. gibt. Es gibt unterschiedliche Anlässe, warum sich ein Unternehmen zertifizieren lässt. Ein
häufig genanntes Argument ist, dass
Unternehmen durch den Druck der
Kunden angetrieben werden eine
Zertifizierung zu veranlassen, d.h.
es werden nur Aufträge an Unternehmen vergeben, die auch zertifiziert sind. Aber auch einige andere
Gründe spielen hierfür eine Rolle,
wie zum Beispiel Vorteile im Marketingbereich, indem sie mit ihrer Zertifizierung in Zeitschriften werben
können. Dies wirkt vertrauenserweckend und wird gerade auch deshalb
gut sichtbar in Firmen an Eingangshallen platziert. Ein weiterer Grund
ist die Organisation. Durch die Vorbereitung auf die Zertifizierung wird
das QM-Systems überarbeitet und
sorgt für bessere Prozessabläufe im
Unternehmen. Dies erweist sich als
gute Option, um frühere Fehler und
Unvollständigkeiten wieder in Ordnung zu bringen. Einer der wichtigsten Aspekte ist die Steigerung der
Qualität. Auch wenn die Qualität
des Produktes nicht im Mittelpunkt
eines QM-System steht, kommt es
dennoch auch hier zu Verbesserungen. Das liegt daran, dass Fehlerursachen erkannt werden, eine höhere
Mitarbeiterbeteiligung und die daraus schließenden gestiegenen Qualitätsbewusstsein oder an leichteren
und folglich sicheren Abläufen. Ein
Qualitätsmanagementsystem einzuführen hat daher gute Gründe und
ITERATION++
Vorteile für ein Unternehmen. Dennoch besteht die Möglichkeit, dass
bei der Durchführung Probleme auftreten. Denn in der Norm DIN ISO
9001 sind Forderungen und Hilfestellungen allgemein formuliert und
diese somit nicht auf die Besonderheiten eines Betriebes abgestimmt.
Dadurch wird eine Auslegung der
Normforderungen auf einzelne Unternehmen nicht immer leicht.
Die Zertifizierungsstelle sendet dem
Unternehmen einen Fragenkatalog,
der zur Selbstbeurteilung ausgefüllt
werden soll. Dieser zeigt die bisherigen Qualitätsmanagement – Aktivitäten des Unternehmens, wie z.B.
ob die Mitarbeiter den Inhalt der
sie betreffenden QM-Dokumente
kennen und die dort beschriebenen Maßnahmen auch anwenden.
Dieser dient als Vorbeurteilung, ob
„Qualität muss man denken,
dann umsetzen.“
Flavia Di Laudo, Qualitätssicherung
Zertifizierung eines QM-System
Nach erfolgreicher Einführung eines
Qualitätsmanagementsystems
kommt nun die Zertifizierung. Abb.
1 beschreibt den allgemeinen Ablauf
einer Zertifizierung. Um das Zertifizierungsverfahren zu beginnen, muss
das Unternehmen eine staatlich akkreditierte Zertifizierungsstelle auswählen
und dort einen Antrag auf Zertifizierung stellen. Wenn ein Vertrag zustande kommt, versichert sich die Zertifizierungsstelle, das Unternehmen
während des Verfahrens zu begleiten
und auch zu beraten. Die Zertifizierungsstelle verschafft sich vorab einen
Überblick über den Betrieb und seinen Zustand hinsichtlich dessen QMSystem. Der Zertifizierungsprozess
kann 1 bis 2 Jahre dauern.
69
Verfahren auch wirklich praktisch
umgesetzt werden. Anhand der ISO
9001:2000 als Zertifizierungsnorm
erfolgt das Audit. Jedoch variieren
die Punkte je nach Unternehmen,
da hier die erstellten Leistungen
und Produkte genauer betrachtet
werden und demnach dann entschieden wird, was für den Betrieb
von Nutzen ist und welche Punkte
nicht zutreffend sind. Es wird bei
diesem Audit eine stichprobenartige
Prüfung aller Prozesse und Bestandteile des Qualitätsmanagementsystems analysiert. Der Zertifizierer
verwendet zusätzlich eine spezielle
Auditfragenliste, die alle Forderungen der Norm enthält. Wenn während der Abarbeitung der Fragenlis-
ein Unternehmen auch die Grundvorrausetzungen für ein Zertifizierungsaudit erfüllt.
Die Vorbeurteilung hat den Zweck,
dass Schwachstellen eines QMSystems frühzeitig erkannt werden
und das weitere Vorkehrungen zur
Zertifizierung getroffen werden.
Das Unternehmen könnte sich
auch zusätzlich für ein Voraudit
entscheiden. Hierfür wird das
QM-System geprüft und eventuell
offenstehende Fragen würden
dadurch geklärt werden.
Zertifizierungsaudit
Bei einem Zertifizierungsaudit wird
geprüft, ob ein Unternehmen die
im Qualitätshandbuch und in anderen Unterlagen dokumentierten
Abb. 1: Schema der Zertifizierung eines
QM-Systems
70
ITERATION++
te Schwachstellen auftreten, werden
diese in Abweichungsberichten aufgezeichnet und folgend mit dem Unternehmen durchgesprochen. Der
Abweichungsbericht ist in kritische,
nicht-kritische Abweichungen und
Anmerkungen zu unterscheiden.
Kritischen Abweichungen müssen
vor Ausgabe des Zertifikats behoben
werden, dagegen hat man bei nichtkritischen Fehlern 6 Monate Zeit
die Fehler zu beheben. Zusätzlich
können erforderliche Nachaudits
zur Prüfung der Korrekturmaßnahmen bestimmt werden.
Zertifizierung im Softwareprojekt
Ich habe mir bereits einigen Gedanken gemacht, wie wir im SOP eine
Zertifizierung realisieren können.
Leider gibt es einige Schwierigkeiten bei der Umsetzung. Gerade bei
dem Punkt, sich für eine Zertifizierungsstelle zu entscheiden, müssen
wir im SOP eine Alternative finden.
Eine Idee wäre, eventuell der Testing-Abteilung diesen Job anzuvertrauen und neben den eigentlichen
Aufgaben der Abteilung auch bei
der Zertifizierung mitzuarbeiten.
Gemeinsam mit der Qualitätssicherung könnte dann ein Fragenkatalog ausgearbeitet werden. Da
eine Zertifizierung nur alle 3 Jahre
durchgeführt wird, wäre es möglich
jede Iteration stichprobenartig alles
zu prüfen, sozusagen eine reduzierte
Zertifizierung zu machen, die einen
kleineren Umfang hat. Die QualiSOP JOURNAL HOCHSCHULE REUTLINGEN R6
tätssicherung prüft jede Iteration
durch Audits die Abläufe im Unternehmen. Eine zusätzliche Prüfung
wäre deshalb vorteilhaft um versteckte Fehler zu finden und diese
schnellstmöglich zu beheben.
Fazit
Theoretisch wurde jetzt alles Wichtige besprochen. Jetzt geht es darum,
dies auch in der Praxis umzusetzen.
Um der Zertifizierung näher zu
kommen, werden die kommenden
Iterationen eine neue Aufgabe hinzu bekommen. Das Softwareprojekt
ist zwar ein Planspiel, dennoch wird
versucht, es so real wie nur möglich
zu gestalten. Hierfür darf eine Zertifizierung nicht fehlen. Die Idee, wie
die Zertifizierung im SOP aussehen
könnte, bezieht sich bisher nur auf
Theorie und eigener Vorstellung.
Eine Garantie, dass dies so zu realisieren ist, gibt es nicht. Durch Absprachen mit der Geschäftsleitung
könnte man Ideen zusammentragen, wie im SOP die Zertifizierung
gemacht wird.
Quellen
[1] Kamiske Gerd F., Brauer JörgPeter – „ABC des Qualitätsmanagements“, München : Hanser, 2008
[2] Kalny Edith, Pusterhofer Rudolf
– „ISO-Management : Chancen und
Risiken bei der Zertifizierung nach
ISO 9001:2000“, Wien : Linde, 1999
[3] Bernd Stauss – „Qualitätsmanagement und Zertifizierung; Von
DIN ISO 9000 zum Total Quality
Management“, Wiesbaden, Gabler,
1994
[4] Ekbert Hering, Werner Steparsch, Markus Linder – „Zertifizierung nach DIN EN ISO9000“,
Springer Verlag, 1997
ITERATION++
71
Guerilla Marketing
Raffinierte Marketingstrategie oder geschmacklose Werbetreiberei?
Stephanie Höhn
Sie schlendern gemütlich durch ihren
Lieblingspark, genießen die Sonne und
die frische Luft. Plötzlich schrecken
sie auf! Sie starren ungläubig auf den
Schachtdeckel unmittelbar vor ihnen.
Ragen da tatsächlich Hände aus dem
Schacht? Sie rufen, ob sie helfen können. Keine Antwort. Ängstlich treten
sie näher und erkennen, dass auf den
Händen etwas deutlich eintätowiert ist.
„Kritische Zeitungsberichte“? Erleichtert
und überrascht zugleich erkennen sie,
dass die Hände nur aus Plastik sind...
...Sie sind Opfer einer GuerillaMarketingkampagne von AmnestyInternational geworden, die mit dieser
Aktion auf unschuldig Inhaftierte aufmerksam machen wollten.
In diesem Artikel wird die Strategie des
Guerilla Marketing erklärt und sowohl
Vor- wie auch Nachteile aufgezeigt.
Außerdem wird eine Guerilla Aktion
entwickelt, mit der das Softwareprojekt
der Hochschule Reutlingen diese
Marketingstrategie für sich nutzen könnte, um die Öffentlichkeit und speziell die
Zielgruppe der Schulabgänger auf den
Studiengang und das Projekt aufmerksam zu machen. Dies könnte zu mehr
Interessenten am Studiengang Medienund
führen.
Von der Kriegsstrategie zur Marketing Strategie
Der Ausdruck „Guerilla“ kommt aus
dem Spanischen und bedeutet übersetzt „kleiner Krieg“. Nach der klassischen Definition wird damit der
Kampf irregulärer Verbände gegen
eine Fremd- oder Gewaltherrschaft
bezeichnet. Sie kämpfen verstreut in
beweglichen Einheiten und bevorzugen die Methoden des Überraschungsangriffs, des Hinterhalts und der Sabotage1. Definiert wurde der Begriff
„Guerilla“ als erstes im spanischen Unabhängigkeitskrieg (1807-1814). Die
Kämpfer sind meist Zivilisten ohne
militärische Ausbildung. Sie gehen
mit der sogenannten Nadelstichtaktik
vor. Dabei werden gezielte kurze Angriffe auf taktisch wichtige Standorte
des Feindes durchgeführt um diesen
verzweifeln zu lassen.
Ein sehr bekannter Vertreter dieser
Taktik war der kubanische Revolutionär Che Guevara. Er veröffentlichte
1960 das weltberühmte Buch „Guerilla Warfare“, in dem er die Gueril1
vgl. o.V.: Brockhaus 1994, S. 270
la-Kriegsführung thematisiert. Die
Grundidee des Buches ist der Kampf
gegen eine Übermacht mit wenigen
Ressourcen, durch den Vorteil der Flexibilität und schnellem überraschenden Handeln.
1965 waren amerikanische Forscher
auf der Suche nach einer Methode,
die den Markt grundlegend verändern sollte. Sie fassten die Ideen aus
Che Guevaras Buch auf, entwickelten
diese weiter und übertrugen sie auf
das Marketing. Beeinflusst wurden
die Wissenschaftler ebenfalls durch
den zeitgleich stattfindenden Vietnam
Krieg, in dem die Vietkongs durch gezielte Guerilla Angriffe dem amerikanischen Militär zu schaffen machten.
Guerilla Marketing heute
„Bieten Sie den Verbrauchern eine
Botschaft, die es wert ist, dass man sich
darüber unterhält und sie wird sich
von alleine verbreiten. Das liegt in der
menschlichen Natur.“2
Guerilla Marketing ist eine noch relativ junge Form des Marketing und
basiert vor allem auf der Mundpropaganda. Der Mensch in der heutigen
2
Aussage aus: Buzz: Harness the Principles of
Influence and Create Demand von Marian Salzman, Ira Matathia und Ann OReilly
72
ITERATION++
Zeit wird über Radio, TV, und durch
Plakate auf Werbeflächen von Werbung überhäuft. Überall versuchen
Verkäufer auf ihre Produkte aufmerksam zu machen. Dadurch sind die
Menschen der westlichen Gesellschaft
von Werbung übersättigt und nehmen herkömmliche Werbeaktionen
oft nicht mehr wahr. Ziel der Guerilla
Strategie ist es die Aufmerksamkeit der
Konsumenten durch originelle und
außergewöhnliche Werbeaktionen zu
gewinnen.
ten dazu zu verleiten, das Erlebte weiter zu verbreiten. So soll ein möglichst
großes Publikum und eine nachhaltige
Kommunikation erreicht werden.
Populär wurde die Strategie Anfang
der 80iger Jahre durch Jay Conrad Levinson, der das erste Buch zu Guerilla
Marketing veröffentlicht hat und seitdem als Guerilla-Guru gilt.
Ursprünglich wurde diese provokante Form des Marketings als Waffe im
Kampf der kleinen Unternehmen gegen die Großen verwendet. Heutzu-
„Nur wer sich von der Masse abhebt wird wahr genommen!“
Stephanie Höhn, Marketing
Dabei werden die unterschiedlichsten Medien für die Verbreitung einer Werbebotschaft genutzt. Guerilla
Marketing ist laut Thorsten Schulte,
dem bekannten Marketing Manager
und Fachbuchautor, „unkonventionell, überraschend, originell/kreativ,
frech/provokant, kostengünstig/effektiv, flexibel, ungewöhnlich/untypisch,
witzig, spektakulär, ansteckend.“ Im
Wesentlichen zielt Guerilla Marketing
darauf ab, sich von den Marketingaktivitäten der Wettbewerber abzugrenzen, anders zu sein und aufzufallen.
Die Werbeaktionen sollen schockieren, amüsieren oder zum nachdenken
anregen, um Passanten und JournalisSOP JOURNAL HOCHSCHULE REUTLINGEN R6
tage nutzen allerdings auch „Global
Player“ wie beispielsweise Nike diese
Methode, um das werbeüberflutete
Publikum zu begeistern. Ein Beispiel
hierfür ist die Aktion „Go Heinrich
Go“, bei der Nike am Berlin Marathon einen Marathonläufer ins Rennen schickte, dessen Alter mit 80
Jahren weit über dem Durchschnitt
der anderen Sportler lag. Er beendete
den Marathon erfolgreich. Dadurch
wurde um den alten Herren und auch
um Nike ein enormes Medieninteresse
ausgelöst. Da Adidas der Hauptsponsor dieses Marathons war, stellte Nike
mit dieser Aktion seinen Konkurrenten auf originelle Weise in den Schatten.
Es gibt jedoch durchaus auch kritische Stimmen zum Guerilla Marketing. Gerade bei Sportveranstaltungen
wird die Ethik von solchen Strategien
stark diskutiert. Einer der bekanntesten Kritiker ist Tony Meenaghan. Er
ist Professor am „College of Business
& Law“ in Dublin und hat sich ausführlich mit dem Thema auseinander
gesetzt. Meenaghan kritisiert, dass
manche Firmen den Medienrummel
bei Sportevents für ihre Werbezwecke
ausnutzen, ohne viel Geld zu investieren. Durch Guerilla Taktiken wird
versucht, die Konsumenten irrezuführen. So werden die tatsächlichen Sponsoren in den Hintergrund gedrängt.
Da dem Hauptsponsor, der viel Geld
in einen Event investiert hat, die Aufmerksamkeit der Medien entzogen
wird, bezeichnet Meenaghan diese Art
des Werbetreibens als stehlen. Ein
solches Verhalten führe dazu, dass die
„echten“ Sponsoren abspringen, was
eine negative Auswirkung auf die Finanzierung von solchen Events hat. Er
ist der Meinung, dass allein das Unternehmen, das die Gebühren zahlt, auch
von einem Event profitieren dürfe.
Da Guerilla Marketing-Aktionen aufsehenerregend und schockierend sein
sollen, greifen viele Unternehmen
auch zu Mitteln, welche man durchaus als geschmacklos bezeichnen kann.
Das Beispiel von Amnesty International könnte Menschen verärgern, oder
sogar Angst machen.
ITERATION++
Guerilla Marketing und das SOP
Da diese Form des Marketings mit
sehr wenig Geld umzusetzen ist, könnte auch ein Hochschulprojekt wie das
Softwareprojekt auf diese Weise auf
sich aufmerksam machen. Alles was
benötigt wird, ist eine medienwirksame kreative Idee und den Mut sie umzusetzen. Denkbar wäre eine Aktion
über die die Zeitungen und beispielsweise das RTF (Reutlinger Tübinger
Fernsehen) berichten würden.
Für das Softwareprojekt wurde ein
Film gedreht, in dem das Hochschulprojekt anhand eines Schachspiels
erklärt wird. Des Weiteren existiert
eine Webseite zum Softwareprojekt, in
dem allgemeine Informationen zum
Planspiel, wie auch der Film zu finden
sind. Für eine Guerilla Aktion könnten diese Informationsmedien genutzt
werden. Man könnte beispielsweise
menschengroße Schachfiguren aus
Pappmaché oder Karton modellieren.
Diese müsste man über Nacht, nach
einem bestimmten Muster, in ganz
Reutlingen aufstellen. Wichtig hierbei
wäre, dass man Figuren auch vor Gymnasien aufstellt, um die Zielgruppe der
Schulabgänger zu erreichen. Auf jeder
Spielfigur müsste deutlich die Adresse
der SOP-Webseite lesbar sein. Eine
solche Aktion würde Passanten neugierig machen und höchstwahrscheinlich dazu verleiten, die SOP-Webseite
zu besuchen. Der Film auf der Internetseite sorgt dann für Aufklärung, da
die Zuschauer eine Analogie zwischen
den Schachfiguren im Film und den
lebensgroßen Vertretern in der Stadt
herstellen können. Zusätzlich werden
auf der Seite Informationen zum Studiengang Medien- und Kommunikationsinformatik bereit gestellt.
Um die Besuche der SOP-Webseite
noch weiter in die Höhe zu treiben,
wäre es denkbar, ein Gewinnspiel in
die Aktion zu integrieren. So könnten
die Schachfiguren neben der Webseitenadresse auch mit unterschiedlichen
Nummern beschriftet sein. Die Interessierten treffen beim Besuch der
Webseite auf ein Gewinnspiel, das mit
der Eingabe einer gesuchten Zahl beendet wird.
Sinnvoll wäre eine solche Werbeaktion
kurz vor einer Informationsveranstaltung, wie dem „Tag der offenen Tür“.
In diesem Fall sollte auf der Webseite
ebenfalls auf diese Veranstaltung hingewiesen werden.
„Führen all diese Erkenntnisse zum
Tod der Werbung? Nicht im Geringsten. Ist dies das Ende der Werbung,
wie wir sie heute kennen? Auf jeden
Fall.“
Quellen
Weblinks:
http://www.guerilla-marketing-portal.de
Letzter Zugriff: 24.05.09
http://www.guerilla-marketing-blog.de/
http://www.guerilla-marketing-blog.de/
info/guerilla-minilexikon.html/Letzter
Zugriff: 22.04.09
73
http://www.4managers.de/themen/
guerilla-marketing/
http://de.wikipedia.org/wiki/Guerilla/
http://www.marketing-trendinformatio-nen.de/werbung/news-archiv/
heilsamer-schock-7-guerilla-ideendie-grenzen-ueberschreiten.html/
http://www.murdoch.edu.au/elaw/
issues/v8n2/kendall82_text.html/
http://guerillamarketingbuch.com
/category/about/
http://www.guerillamarketingbuch.
com/ebook/ebook-guerilla-marketing-online-mobile-crossmedia.pdf/
Literatur:
[1] Jay C. Levinson, Seth Godin, Das
Guerilla Marketing Handbuch, Ver-lag
Heyne Campus.
[2] Jay Conrad Levinson (2006), Die
100 besten Guerilla-Marketing-Ideen,
Campus Verlag, ISBN 3593381702
[3] Ralf Kreutzer (2006), Praxisorientiertes Marketing: Grundlagen, Instrumente, Fallbeispiele:[Bachelor geeignet], Springer, ISBN 3409143343
[4] Marian Salzman, Ira Matathia, Ann
OReilly, Buzz: Harness the Principles of
Influence and Create Demand
[5] Meenaghan, Tony : Ambush marketing – a threat to corporate sponsorship,
SLOAN MANAGE-MENT REVIEW,
Heft: 1, 1996, Vol. 38, S. 103
74
ITERATION++
User Interfaces und Ergonomie
Mensch und Maschine ‐ Symbiose oder Kampf?
Jaroslaw Marek Zawadzki
„Technische Systeme werden an die
Fähigkeiten des Menschen angepasst,
nicht umgekehrt.“ (vgl. [1])
Inwieweit diese Aussage bei der
Gestaltung und Evaluation der im
Softwareprojekt (SOP) erstellten grafischen Benutzeroberfläche für die
Langzeitarchivierungssoftware,
genannt Tréstore, eine Rolle spielt, soll in
diesem Artikel nachgegangen werden.
GUI vs. Ergonomie
Im Jahr 1973 wurde eine neue Generation von Computern entwickelt,
die sich einer grafischen Oberfläche
bedienen. Ein wichtiger Schritt in
Richtung Produktergonomie für
Computernutzer wurde dadurch getätigt. Ergonomie beschreibt hierbei
den Zweig der Wissenschaft, der sich
mit der Anpassung von Mensch an
Maschine befasst. Wichtig ist dabei
die Variabilität des Menschen zu
kennen und in der Entwicklung zu
berücksichtigen. Das Produkt muss
benutzerfreundlich im Umgang und
schnell zugänglich sein. Werden diese Anforderungen erfüllt, wird laut
Aussage der TU München, die BeSOP JOURNAL HOCHSCHULE REUTLINGEN R6
lastung für den Menschen reduziert
und die gesamte Leistungsabgabe optimiert (vgl.[2]). Die Anforderungen
an eine grafische Benutzungsschnittstelle im Rahmen der Mensch-Computer-Kommunikation sind in der
europäischen Norm EN ISO 9241110 ff. geregelt (vgl. [3]).
Das 1973 entwickelte System war
damals ein Vorgänger der heutigen,
weit verbreiteten Bedienungsweise, wie man sie vom Windows PC
kennt. Statt komplexer Steuerung
über Tastatur und Kommandozeile,
wurde eine völlig neue, mit Maus
steuerbare Oberfläche geschaffen.
Das „Graphical User Interface“ stellt
dabei eine Benutzerschnittstelle für
Anwendungssoftware da, mit deren
Interface eine einfache Bedienung
realisiert wird.
ISO Norm 9241-110: Benimmregeln für interaktive Systeme
Auch die Internationale Organisation für Normung (kurz: ISO) hat sich
mit dieser Thematik auseinandergesetzt und in der Norm ISO 9241-110
Dialogprinzipien aufgestellt, welchen
interaktive Systeme im Umgang mit
Menschen folgen sollten. Die wichtigsten dieser Prinzipien sind:
• Selbstbeschreibungsfähigkeit
• Aufgabenangemessenheit
• Erwartungskonformität
• Fehlertoleranz
• Steuerbarkeit
• Individualisierbarkeit
• Lernförderlichkeit
Der von Britta Hofmann 2008 veröffentlichte „Dialogknigge“ beschäftigt
sich mit eben diesen Prinzipien und
beschreibt Anwendungsfälle dieser in
heutigen Softwaresystemen (vgl. [4]).
Der Weg zum Ziel
Aufgabe dieser Iteration war es, der
im Zuge des Softwareprojekts entstandenen
Archivierungssoftware
(Tréstore) eine benutzerfreundliche
Oberfläche zu geben.
Um ein besseres Bild von den Anforderungen an und Fähigkeiten für
eine solche Benutzeroberfläche aus
Kundensicht zu bekommen, lagen
der Softwareabteilung verschiedene,
von der Firma Trésor angefertigte,
Personas vor, welche stellvertretend
für die Benutzergruppe standen.
Eine der hieraus direkt ersichtlichen
Anforderungen war es, selbst unerfahrenen Usern eine einfache Bedienung zu ermöglichen.
ITERATION++
Um das von den Personas gewonnene Bild der potentiellen Kundengruppe weiter zu verschärfen, wurde
ein detaillierter Umfragebogen zu
diesem Thema gestartet. Dieser wurde u.a. von Mitarbeitern der in der
Wirtschaft tätigen Unternehmen,
wie auch von Studenten und Auszubildenden bearbeitet.
Bei der Auswertung der Fragebogen
kam ein Problem zum Vorschein,
welches folgendes Zitat ziemlich genau beschreibt:
„Ein kluges Design mag für eine Benutzergruppe passen, aber für eine
andere ist es unangemessen“ (vgl.
[5], S.26).
oberfläche interessierten. Komplexe
Entscheidungen sollten hierbei weitest gehend von der Software selbst
übernommen werden.
Die zum Teil doch sehr unterschiedlichen Anforderungen resultieren, wie
aus der Umfrage ersichtlich, aus dem
ebenso unterschiedlichen Wissensstand der Benutzer im Umgang mit
informationstechnischen Systemen,
wie beispielsweise einem Computer.
Die beste Lösung, um beiden Anforderungen gerecht zu werden, schien
hierbei der Einsatz einer Rollenverwaltung. Diese erlaubt es nun, direkt
schon beim Login zwischen verschie-
„In der heutigen Zeit kann sich nun
einmal nicht jedes Unternehmen eine
teure GUI Entwicklung leisten.“
Jaroslaw Marek Zawadzki, Testing
So kristallisierte sich sowohl bei der
in der Wirtschaft tätigen Befragten,
wie auch bei den Studierenden und
Auszubildenden eine größere Gruppe heraus, welche sich eine komplexere Benutzeroberfläche wünschte,
die Ihnen die Freiheit gibt, über Einstellungen und Veränderungen von
Zuständen in der Software selbst entscheiden zu können. Im Gegensatz
dazu gab es jedoch auch eine nicht
zu unterschätzende Gruppe derer,
welche sich für eine eher schmalere
und einfach aufgebaute Benutzer-
denen Rollen zu wählen. So gibt es
in naher Zukunft eine Rolle „Beginner“, wie auch eine Rolle „Professional“, welche den Usern, ihrem jeweiligen Wissensstand entsprechend,
Rechte zuweisen oder verweigern.
Gleichzeitig dient diese Rollenverwaltung der Auswahl zwischen einem
ausgebauten oder in der Bedienung
eingeschränkten Benutzerinterface.
Auf diese Problematik geht auch die
ISO Norm 9241-110 ein, indem
Sie eine Anpassung des Systems an
die Fähigkeiten und Bedürfnisse der
75
jeweiligen User fordert. Britta Hofmann nennt in Ihrem Knigge als
Beispiel hierfür die Vergrößerung der
Schrift als ein gängiges Beispiel für
diesen Grund der Individualisierbarkeit (vgl. [3]).
Die in der ISO Norm als Selbstbeschreibungsfähigkeit geforderte Anforderung verlangt eine Gestaltung
der Oberfläche dahingehend, dass
sich ein Benutzer zu jeder Zeit leicht
darin orientieren kann. Dies beinhaltet das Wissen darüber, wohin beispielsweise ein Button den Benutzer
führt, wie auch das Wissen darüber,
woher dieser gekommen ist und wie
er wieder dahin zurückkehren kann.
In der Praxis sieht das nun so aus,
dass der Benutzer durch eine stets
sichtbare Navigationsleiste, in welcher der für den aktuellen Teilbereich zuständliche Button besonders
hervorgehoben ist, genau weiß, in
welchem Zustand der Software er
sich befindet. Große, übersichtlich
angeordnete Buttons tragen eindeutige Beschriftungen wie beispielsweise „Speichern“, „Abbrechen“ etc., aus
denen ersichtlich ist, welche Funktionalität sie bewirken. Desweiteren
trägt die Farbgebung zur besseren
Übersicht bei. So sind sämtliche
Buttons in passenden Kontrastverhältnissen zur restlichen Oberfläche
gehalten. Die Navigationsleiste selbst
ist stets einfarbig gehalten und zeigt
durch eindeutige Icons den Weg auf,
wohin diese den Benutzer führen.
76
ITERATION++
Hiermit wurden auch gleich die in
der ISO Norm angesprochenen Fähigkeiten der Aufgabenangemessenheit,
Selbstbeschreibungsfähigkeit
und Steuerbarkeit von Interaktiven
Systemen abgedeckt.
Gerade für die etwas unerfahrenere
Gruppe von Benutzern ist das Thema Fehlertoleranz sehr wichtig. Laut
ISO Norm ist hierbei darauf zu achten, dass das System den Benutzer
Fazit: Vor- und Nachteile einer per-
zwar von Fehlern bewahrt, wie dies
beispielsweise durch klar verständliche Sicherheitsabfragen gegeben ist,
ihm aber auch die Chance gibt, bei
Auftreten eines Fehlers diesen selbstständig beheben zu können.
tionsweise der Software besser ist, als
„Der SOP Software selbst liegt ein
detaillierter Interaktionsgraph zugrunde“ (vgl. [6]), welcher jede
durch den Benutzer mögliche Aktion, wie auch die darauf folgende
Reaktion des Softwaresystems abbildet. Ein solcher Graph stellt eine
große Hilfe dar, wenn es darum
geht, kritische Bereiche ausfindig zu
machen, welche dann gezielt abgefangen werden können. So wird ein
falsches Passwort beim Login Prozess
beispielsweise in der Art behandelt,
dass der Benutzer durch ein AlertFenster darauf aufmerksam gemacht
wird. Dieser kann nun nach Bestätigung der Meldung, den Fehler durch
eine Korrektureingabe selbstständig
lösen. Dieses Prinzip kommt in der
gesamten SOP-Software zum Einsatz
und umspannt sie somit wie eine Art
Sicherheitsnetz.
sonalisierten GUI
Doch warum betreibt man eigentlich
diesen ganzen Aufwand? Ziel ist es,
den Kunden auch langfristig an die
Softwarelösung zu binden oder sogar
für neue Produkte zu gewinnen. Eine
ergonomische GUI kann im Idealfall
einen Wettbewerbsvorteil gegenüber
anderen Konkurrenten bieten, wenn
die Bedienung, Logik und Funkdie der Konkurrenz. Durch immer
wieder kehrende Designs und Bedienungskonzepte erreicht man einen
hohen Wiedererkennungs- und Akzeptanzwert, wie die beispielsweise
bei der gesamten Softwarepalette von
Microsoft der Fall ist. Allerdings dürfen bei der ganzen Thematik auch die
zum Teil hohen Aufwands- und Zeitkosten, welche bei der Entwicklung
einer solchen GUI entstehen, nicht
außer acht gelassen werden. In der
heutigen Zeit kann sich nun einmal
nicht jedes Unternehmen eine teure
GUI-Entwicklung, mit sämtlichen
dazugehörigen Teilaspekten, wie Interaktionsgraphen, Userbefragungen
etc. leisten. Die Konkurrenz ist groß
und so findet man sich schnell auf
einem schmalen Grat zwischen einer
professionellen
GUI-Entwicklung
und dem kostengünstigen Vertrieb
dieser mit dem späteren Produkt.
Quellen
[1] http://www.steinrisser.at
[2] http://www.ergonomie.tum.de/
lehrstuhl/ergonomie.htm
[3] http://www.beuth.de/langanzeige/N+EN+ISO+9241-110/
110514174.html
[4] http://www.fit-fuer-usability.de/
archiv/einfuehrung-in-die-iso-9241110/Britta Hofmann - Einführung
in die ISO 9241-110, 13. Februar
2008
[5] Ben Shneiderman: User Interface
Design, 3.Auflage 2002, Mitp-Verlag Bonn
[6] Wagner, Rainer; „Interaktionsgrafen im Softwareprojekt“, Fachjournal „Iteration++“, Januar 2009,
MKI Hochschule Reutlingen
ITERATION++
77
Wunsch nach einem neuen Zeichen?
Hier lernen Sie das erfolgreiche Logo kennen!
Zehra Türkkan
außen abgestimmt eingesetzt wird.
Doch was beinhaltet das Corporate
Doch wie wird eine Corporate Iden-
Design im Unternehmen?
„Unternehmen wachsen und verän-
tity zum Leben erweckt? Dies ge-
Ein Corporate Design beinhaltet Ge-
dern sich, Mitarbeiter kommen und
schieht durch ihre Anwendung auf
staltungskonstanten: Logo, Hausfar-
gehen, die Corporate Identity je-
Geschäftspapieren. Dabei sollte die
ben, Hausschrift, Gestaltungsraster
doch ist etwas, das bleibt und eine
Anwendung durchdacht sein, damit
und Stilvorgaben für Abbildungen,
kontinuierliche, wenngleich flexible
die Geschäftsausstattung nicht in der
Fotos und Internetauftritt. Von die-
Konsistenz bietet.“ (vgl. [1], S. 27).
grauen Masse von Briefbögen und
sen Konstanten wird zunächst ein
Ein Firmenzeichen ist die Grundlage
Visitenkarten versinkt und das Design-
Firmenlogo erstellt, das die Gestal-
der visuellen Erscheinungsbilder. Der
konzept am Ende aufgeht (vgl. [1],
tung sämtlicher visueller Äußerun-
Wunsch nach einem neuen Zeichen
S. 112). Der Hauptteil der Corpo-
gen eines Unternehmens von Kom-
entsteht, wenn das bestehende Zeichen
rate Identity ist das Corporate De-
munikationsmitteln bestimmt (vgl.
veraltet oder verbesserungsbedürftig ist
sign, welches das Erscheinungsbild
[2], S. 61).
(vgl. [5]).
Damit das Softwareentwicklungsunternehmen ITer@ Group im Projekt erfolgreich in allen Branchen
dargestellt werden kann, wird eine
Marketing-Abteilung benötigt. Aus
„Erfolg im Unternehmen, wenn
das Firmenzeichen modern aber
nicht modisch wirkt!“
Zehra Türkkan, Marketing
diesem Grund wurde diese in der
Iteration R6 schließlich eingeführt.
Um das Erscheinungsbild des Un-
der Firma ITG nach außen hin re-
Wirkung von Firmenlogo-Design
ternehmens „ITer@ Group“ [ITG]
präsentiert (s. Abb. 3). Das Projekt
Logos sind Zeichen, die charakteris-
zu präsentieren, wird die Entwick-
beschränkt sich zunächst nur auf die
tische Merkmale enthalten und einen
lung einer Corporate Identity er-
Geschäftsausstattung, später wird
Bezug zum Unternehmen herstellen.
stellt. Corporate Identity bedeutet
auch eine Homepage gemäß des Cor-
Beim Softwarprojekt [SOP], das ein
Unternehmens-persönlichkeit
porate Designs erstellt.
bei
dem das Verhalten, die Kommunikation und das Erscheinungsbild
sowohl nach innen als auch nach
Abb. 1: altes und neues Logo
78
ITERATION++
Grafikprogramm-Datei gekommen.
Logo sollte man sich sofort mindes-
Desweiteren gibt es keinerlei Richtli-
tens an einen Element erinnern kön-
nien, Dokumentation über das Logo
nen und es somit identifizierbar ma-
wie es verwendet werden darf: auf
chen. Im Gegensatz zum alten Logo
farbigem Hintergrund, Graustufen,
enthält es keine überflüssigen De-
die Platzierung und die Farbwerte
tails wie Schrift-Schatten und Farb-
des Logos. Die Marketing-Abteilung
verlauf. Beim alten Logo handelt es
hat zunächst drei Logo-Entwürfe
sich um eine Wortmarke, die nur aus
bei den Projektmanagern vorge-
dem Namen „iter@ group“ besteht.
stellt und deren Bedeutung näher
Vermutet wird nämlich, dass das alte
erläutert. Anschließend wurde ein
Logo ohne professionelle Hilfe er-
Logo vom Projektteam als das neue
stellt worden ist und ohne Gedanken
Logo ausgewählt (s. Abb. 1, rechts).
an eine spätere Wiederverwendbar-
Unternehmens-Rollenspiel an der
Das Marketing-Team, das aus zwei
keit.
Hochschule Reutlingen ist, wird ein
Leuten besteht, hat das neue Logo
Logo entwickelt (vgl. [1], S. 14). Das
als Wort-Bild-Marke kreiert, die
Grundlagen der Gestaltung
ITG-Logo soll dabei Aufmerksam-
aber eine Wiederkennung des al-
Alle Elemente sind in einer Richt-
keit wecken, Signalwirkung haben,
ten Logos in sich birgt, und einen
linienbroschüre namens „Corporate
informieren, erinnerungsstark sein
grafischen Bezug mit dem Begriff
Design: Grundlagen der Gestaltung
und einen eigenständigen und lang-
„Iteration“ zur Firma hat. Das erste
bei ITer@ Group“ festgehalten.
lebigen, ästhetischen Wert besitzen
Wort des Firmennamens „ITer@“
Das Corporate Design umfasst die
(vgl. [2], S. 61).
steht für Iteration und bedeutet
Beschreibung des Unternehmens-
„wiederholen“, das durch einen gra-
zeichens (Verwendung auf Hin-
Neues Firmenlogo ist notwendig!
fischen Ring um den Firmennamen
tergrundfarben,
Bevor ein neues Logo skizziert wird,
ITer@ Group bildlich dargestellt
Fließtexteinsatz), Gestaltungsraster,
fordert der Geschäftsführer eine
wird.
Hausschrift, Hausfarben. Um ITG
Designelemente
Wort-Bild-Marke
Hausschrift
Hausfarbe
Gestaltungsraster
Anwendungsfälle
Geschäftspapier Broschüren
Briefkopf
Anzeigen
Visitenkarten
Mailing
Abb. 2: Die konstanten Elemente des CD
Positionierung,
optisch wiederzuerkennen wird ein
detaillierte Begründung von der
Marketing-Abteilung, warum das
Die Überlegung bei diesem Entwurf
Gestaltungsraster verwendet. Im
bestehende Logo verändert werden
richtete sich hauptsächlich um ein
Raster sitzen Logo, Text und Bil-
soll. Die Begründung lautet, dass das
einfaches und markantes Logo, nach
der an fest vorgegebenen Stellen.
alte Firmenlogo (s. Abb. 1, links) in
dem Motto „weniger ist mehr”. Am
Die Hausschrift von ITG ist die
einer JPG-Datei in schlechter Qualität vorliegt. Daher ist auch eine
Wiederverwendbarkeit
des
Logos
auf Printdesign nur mit erheblichen
Qualitätsverlusten möglich. Trotz
umfangreicher Recherche ist man
nicht in den Besitz der originalen
Vorteile von Corporate Identity (CI) und Corporate Design (CD)
CI
CD
verbessert Selbstverständnis
höhere Wiedererkennbarkeit
klares inneres Firmenprofil
höherer bekanntheitsgrad
klare Marktpositionierung
klare Abgrenzung gegenüber Mitbewerbern
Abb. 3: Vorteile von CI und CD, Quelle: vgl. ihk-bonn.de
ITERATION++
„Calibri“. Die Schrift ist auf Standardsystemen vorhanden und ist
ein moderner Font. Das ITG Logo
wird in zwei Farbtönen, Grau und
Orange
präsentiert.
Die
Farbe
Orange ist eine sehr lebendige und
frohe Farbe und Grau signalisiert
Quellen
[5] Vgl. http://clearinghouse.hbi-
[1] Vgl. Rivers, C.: Corporate
Design: Briefkopf, Logo und Vikenentwicklung. Stiebner Verlag,
Handbuch. Springer Verlag, Heidel-
München: 2003
berg 2000
und Neutralität (vgl. [6], S.133, S.
Corporate Imagery. Wie Ihr Unter-
143). Zusätzlich sind Abbildungen
nehmen ein Gesicht bekommt. Ber-
der Geschäftsausstattung zu finden
lin: 2004
schüre).
Zusammengefasst: wer einen Namen hat, bekannt ist und ein positi-
cicd.php (19.04.2009, 16:00)
[6] Vgl. Thissen, F.: Screen Design:
[2] Vgl. Herbst, D.; Scheier, C.:
mensschild, Masterfolie, Imagebro-
stuttgart.de/projekte/websitepr/
sitenkarte als Elemente der Mar-
Eleganz und assoziiert Sachlichkeit
(Geschäftspapier, Visitenkarte, Na-
79
[3] Vgl. Tabelle1: www.Ihk-bonn.
de/fileadmin/dokumente/Downloads/Presse/Vortrag_Corporate_
Design.pdf (11.04.2009, 20:00)
ves Image zeigt erreicht somit einen
[4] Vgl. www.rkw-bw.de/pdf/ratio/
Wettbewerbsvorteil (vgl. [5]).
ratio_3_2001.pdf
(17.04.2009,
15:30)
»Ein Logo ist dann gut, wenn man es mit dem
grossen Zeh in den Sand kratzen kann«
Kurt Weidemann, Typograph
80
ITERATION++
Logo kommt nicht von Logik
Die kritische Auseinandersetzung mit der Entwicklung eines Logos innerhalb
des Softwareprojekts
Daniel Wenhardt
Das Logo bildet den essentiellen Kern
einer jeden Corporate Identity und ist
dadurch auch das Aushängeschild einer
Marke. Kaum eine Firma, unabhängig von ihrer Größe, kann es sich leisten
auf ein imageprägendes Auftreten nach
außen hin zu verzichten. Infolge dessen stellt sich also die Frage, wie man
so ein zentrales Merkmal einer Firma
erstellt und welche Anforderungen und
Strategien es gibt, die man bei der
Entwicklung eines Logos innerhalb des
Softwareprojekts beachten soll. Darüber
hinaus gilt es zu klären, wie es sich mit
diesen Kriterien verhält, wenn man
sie anhand von Erfahrungen aus dem
Arbeitsalltag und den anderer Experten
überprüft.
Obwohl die Erstellung eines Logos
ein Prozess ist, der sich über weite
Strecken darauf beschränkt mit ästhetischen Fragen der optischen Wahrnehmung – Farbwirkung, Kontraste,
Proportionen, etc. – auseinanderzusetzen, dürfen dennoch maßgeblichen
Faktoren, die auf die Entwicklung
und Vollendung eines Logos einwirken nicht aus dem Fokus unserer
Betrachtung rücken. Nach Michael
Bernd Siegles Buch „Logo - Grundlagen der visuellen Zeichengestaltung“
sind die Arbeitsabläufe zur Erstellung
eines Logos streng in verschiedene
Schritte unterteilt. Zum einen in die
arbeitsvorbereitenden Phasen, die
sich aus einem Briefing, Ideensuche,
Skizzieren zusammen setzen und zum
anderen in die abschließenden Umsetzung, bestehend aus Layout, Präsentation und Reinzeichnung. Diese
starre Unterteilung ist zwar inhaltlich
richtig und auch andere Logodesigner
nutzen sie, wie auch David Airey auf
seiner Homepage beispielhaft aufzeigt
(vgl. [2]). Jedoch wird sie der praktischen Anwendung im Arbeitsalltag
nicht gerecht, da sie von einem idealen Ablauf bei der Logo Entstehung
ausgeht. Hier wird also außer Acht gelassen, dass es durch Verzögerungen,
neu eingebrachten Ideen und verspäteter Kritik zur Vermischung der Arbeitsschritte kommen kann. So wird
auch innerhalb des Softwareprojekts
deutlich, dass das Zusammenspiel von
Kunde und Gestalter keinesfalls an
festgeschriebene Regeln gebunden ist
und ein fertig ausgearbeiteter Entwurf
zu jeder Zeit verworfen werden kann.
Dennoch ist festzuhalten, dass man
diese Richtlinien zur groben Orientierung verwenden kann.
Somit zeigt sich, dass es festgelegte
Verfahrensweisen gibt, anders sieht es
bei den Zeitvorgaben aus. Wenn man
bedenkt, dass das weiß blaue sonnenartige Logo der Olympischen Som-
merspiele 1972 in München bei seiner
Entwicklung ganze fünf Jahre in Anspruch nahm (vgl. [3]) , könnte man
schnell den Eindruck gewinnen, dass
es innerhalb der weitaus kürzeren Zeit
des Softwareprojekts sehr schwer ist, zu
einem Ergebnis zu gelangen. Jedoch ist
diese ausgiebige Entwicklungszeit kein
Regelfall und so verrät Creative Director Sol Sender, der für das aus dem
letzten amerikanischen Wahlkampf
bekannt gewordene Logo Barack Obamas verantwortlich ist, dass „das ganze
Unterfangen (...)“ trotz sieben bis acht
Ausgangsentwürfen „(...) in weniger als
zwei Wochen“ abgeschlossen werden
konnte (vgl. [4]). Dieses zeigt, dass man
sich bei großzügigen Zeitvorgaben sehr
detailverliebt und langwierig mit dieser
Thematik auseinandersetzen darf und
kann, mit der nötigen Arbeitsmoral
aber auch innerhalb von einem, wie im
Softwareprojekt, knapp eingegrenzten
Zeitrahmen mit einem konsensfähigen
Produkt aufwarten kann.
Ob das Produkt tatsächlich zufriedenstellend ist, hängt in hohem Maß
von der Zielsetzung und deren Erfüllung ab. Für den Logodesigner
Miles Newlyn, verantwortlich für
die Logos von Marken wie Unilevers und Honda, ist es beispielsweise „(...) das Wichtigste einen guten
Eindruck davon zu erhalten was für
eine Person der Kunde ist“ (vgl. [5]).
ITERATION++
So führt auch Michael Bernd Siegle in
seinem Buch eine Reihe von Kriterien auf, die in einem Briefing mit dem
Kunden fest zu legen sind. Präzisiert
setzen sich diese zusammen aus der
Definition einer Zielgruppe, der Wesensart des Unternehmens oder Produkts und der gewünschten Wirkung
nach außen hin. Folglich hat der Gestalter die Aufgabe, den Wünschen des
makes a Great Mark“ wirft, findet man
weitere Kriterien, die es bei der Logo
Entwicklung zu beachten gilt (vgl. [7]).
Der Schöpfer von Logos, wie dem des
amerikanischen Fernsehsenders NBC,
gibt Anforderungen, die sich eindringlicher auf das eigentliche Logo-Aussehen konzentrieren und fordert in 6
Punkten: Zweckmäßigkeit, Lesbarkeit,
Einprägsamkeit, Flexibilität im Ein-
„Kreativ sein bedeutet, aus Chaos
Ordnung zu erschaffen.“
Daniel Wenhardt, Marketing
Kunden zu entsprechen. Jedoch gibt
es auch Stimmen, die dieser Sichtweise einer Arbeitsgrundlage widersprechen. So legt einem die Leitlinie des
Medien Design Büros Farrow: „Die
Aufgabe eines Designers liegt darin
den Kunden so weit wie Möglich an
seine Grenzen zu treiben.“ nahe, nicht
nur kritiklos auf Vorgaben einzugehen
(vgl. [6]), sondern die eigenen Vorstellungen vehement zu vertreten, dem
Kunden verständlich näher zu bringen
und einladend zu präsentieren. Innerhalb des Softwareprojekts bewahrheitet sich die Aussage Farrows, da man
sich sowohl im Umgang mit Kunden
als auch mit firmeninternen Vorgaben
kritisch auseinandersetzen muss und
erst durch diesen konstruktiven Prozess zu einem für beide Seiten vollendeten Ergebnis kommt.
Wenn man ein Blick auf Steff Geissbuhlers Publikation mit dem Titel „What
satz, Beständigkeit, und Dauerhaftigkeit eines Logos. Wobei man anmerken
muss, dass diese Punkte ein solides und
fast schon konservatives Verständnis
von Logos vermitteln und mit keinem
Wort auf die in diesem Punkt wichtigen ästhetische Aspekte eingehen.
Dementsprechend steht dann auch der
Leitsatz des „Büro für Form“ in München: „gutes Design ist das Ergebnis der
endlosen Suche nach der Schönheit in
Dingen“ in krassem Gegensatz zu den
Geissbuhler aufgeführten Punkten (vgl.
[6]). Nach den Erfahrungen im Softwareprojekt kann man aber zu dem
Schluss kommen, dass beide Ansichten
einen wahren Wert besitzen und sich
gegenseitig nicht ausschließen, sondern
im Idealfall sogar ergänzen sollten. Das
heißt, dass selbst strenge Vorgaben dennoch Freiräume lassen, in denen sich
ein Gestalter künstlerisch ausleben und
selbst verwirklichen kann.
81
Bei allen erwähnten formalen Rahmenbedingungen, die mit der Entwicklung eines Logos einhergehen,
darf ein Kriterium nicht vernachlässigt
werden: die Fantasie oder der Ideenreichtum. Sie ist die Triebfeder, mit der
es erst möglich wird, aus ungreifbaren
Vorgaben ein anschauliches Logo zu
entwickeln und sie ist es auch mit der
es einem Gestalter möglich wird sich
während des Arbeitsprozesses flexibel
auf veränderte Ausgangsbedingungen
einzustellen und diese in Neues umzusetzen. Reglementierungen, Kriterien und Anforderungen helfen also bei
der Orientierung im Entwicklungsprozess, können letztendlich aber nur
Werkzeuge sein, die Kreativität nicht
ersetzen, diese aber in produktive
Bahnen lenken und dadurch zum Ziel
führen.
Quellen
[1] Michael Bernd Siegle - Logo,
Grundlagen der visuellen Zeichengestaltung, 2005
[2] http://www.davidairey.com/mylogo-design-process/
[3] http://www.guardian.co.uk/sport/
2007/jun/05/uknews
[4] http://campaignstops.blogs.nytimes.com/2008/11/20/the-o-in-obama/
[5] http://www.logolounge.com/
featureddesigner/default.asp?Archive=
True&ArticleID=375
[6] Charlotte & Peter Fiel - Graphic
Design for the 21st Century, 2005
[7] http://www.logosdesigners.com/
How_Conference_Steff_Geissbuhler.pdf
82
ITERATION++
Welche Anforderungen sind für einen effektiven
High-Fi-Prototypen erforderlich?
Eine Auseinandersetzung
Konstantin Adler
Das
Softwareprojekt
des
Studiengangs
Medienund
an
der Hochschule Reutlingen ist mit
Laufzeit über zwei Semester groß angelegt. Im sogenannten Planspiel werden die Arbeitsplätze von drei Firmen
von den Studierenden übernommen
und nachgespielt. Auf den sogenannten Reviews werden die Firmen und
deren Aufgaben präsentiert. Was allerdings bisher vernachlässigt wurde: die
Präsentation nach außen – durch eine
Webseite.
Die Webseite und der Prototyp
Die jetzige Iteration R6 ist deshalb
beauftragt worden, eine Webseite
über das Projekt zu konzeptionieren,
zu gestalten und zu programmieren.
Für die geplante SOP-Webseite benötigt man eine Übersicht, ein Konzept über den Inhalt, damit die Webseite entstehen und den weiter unten
aufgeführten Anforderungen gerecht
werden kann. Nur dann kann sie
veröffentlicht werden.
Ein wichtiger Schritt dabei: Der Prototyp. Nur er führt zu einer professionell
umgesetzten
Webseite.
Er zeigt im Low-Fi-Zustand skizzenhaft, wie die Webseite aussehen
könnte, im High-Fi-Zustand sind
die Funktionen, die die Webseite
später besitzen wird, mit eingebunden und aktiviert.
Es stellt sich dabei allerdings die Frage, was gegeben sein muss, damit
ein finaler Prototyp entstehen kann
und vor allem, welche Kriterien zu
erfüllen sind, damit ein Prototyp
überhaupt als final bezeichnet werden kann.
Ein Low-Fi-Prototyp ist ein skizzenhafter Prototyp, welcher einige
Eigenschaften des Zielproduktes hat.
Dabei kann er einfach gestaltet und
schnell angefertigt werden. Die danach ausgeführten Tests geben einen
ersten Eindruck über die Struktur
und den Aufbau des Endprodukts.
Welchen Zweck genau hat ein Prototyp? Er soll dazu dienen, unter realistischen Bedingungen zu testen –
das heißt, hierbei muss der Benutzer
die ganzen Funktionen wie Buttons
oder auch Links ausführen können.
Dabei wird das Verhalten der Benutzer untersucht. Ist ihnen klar, was
sie auf der Seite tun können? Wird
die Struktur klar? Verstehen sie die
Bezeichnungen und die Funktionen
der Navigationselemente?
Low-Fi-Prototyp
Ein Low-Fi-Prototyp ist ein
skizzenhafter Prototyp, welcher
einige Eigenschaften des Zielproduktes hat. Dabei kann er
einfach gestaltet und schnell
angefertigt werden. Die danach
ausgeführten Tests geben einen
ersten Eindruck über die Struktur und den Aufbau des Endprodukts.
Anforderungen und Personas
Der Low-Fi-Prototyp ist fertiggestellt.
Die Skizzen können dann in PowerPoint mit Hyperlinks versehen werden, der Benutzer wiederum kann
sich nun durch eine erste Version der
Webseite durchklicken. Dabei bekommt man eine bessere Vorstellung
des finalen Prototyps. Hierbei kommt
es allerdings häufig „zu unnötigen
Diskussionen über die Gestaltung und
Anforderungen einzelner Elemente,
obwohl diese auch durch den Prototyp
noch nicht festgelegt sind.” (vgl. [1],
Seite 299)
Ein Denkanstoß also, welche Anforderungen in den finalen Prototyp eingebaut werden müssen. Dabei kann die Anforderungsliste lang
werden. Aber ist es von Vorteil, die
Anforderungen einfach aufzulisten?
ITERATION++
Ist es nicht besser, durch Befragung
der Benutzer herauszufinden, welcher dieser Anforderungen essentiell sind? Welche sollte man besonders beachten? Welche sind weniger
wichtig?
Die SOP-Webseite soll bestimmte
Zielgruppen ansprechen: Studierende, Geschäftsleute und Schulabgänger. Dafür werden Personas erstellt.
Personas stellen verschiedene Personen dar, zum Beispiel Studierende
oder Professoren. Dabei werden deren Interessen, Hobbies und berufliche Werdegänge dargestellt. Diese
Informationen sind sehr hilfreich,
um die Zielgruppen und Anforderungen der Webseite zu bestimmen.
Ein High-Fi-Prototyp ist nahe dem
Zustand des Endprodukts, mit vielen Details und Funktionen. Hierbei
ist sehr gut zu sehen, wie sich das
Verhalten des Benutzers auf das Verwenden des Endprodukts auswirken
wird.
Sind die Personas erfolgreich erarbeitet, geht es weiter mit den Anforderungen. Diese sehen folgendermaßen
aus: Fokus, Realismus, Benutzer und
High-Fi-Prototyp
Ein High-Fi-Prototyp ist nahe
dem Zustand des Endprodukts,
mit vielen Details und Funktionen. Hierbei ist sehr gut zu sehen, wie sich das Verhalten des
Benutzers auf das Verwenden des
Endprodukts auswirken wird.
die gängigen Standards des Web 2.0.
Dabei handelt es sich bei den Web
Standards um Structural Languages
(XHTML1.1, XML1.1), Presentation Languages (CSS), Object Models
(DOM), Scripting Languages (ECMAScript 262, die Standardversion
von Java) und Additional Presentation Languages - auch Markup (MathML 2.0) genannt (vgl. [2]).
83
Ein Punkt, der häufig missverstanden und dadurch falsch angewendet
wird.
Desweiteren ist zu beachten, richtige
Schlüsselwörter und Mikrocontent
- Betreffzeilen und Absenderangaben bei Emails, Überschriften und
Zwischenüberschriften bei Artikeln,
Titelleisten oder auch URLs - einzusetzen. Viele Benutzer beachten die-
„Was mir einfällt, wenn ich an Prototypen und Anforderungen denke? Übersichtlichkeit und daraus entstehende
Zufriedenheit.“
Konstantin Adler, Marketing & Redaktion
Der Prototyp und sein Benutzer
Auch bei der SOP-Webseite ist die
bereits erwähnte Zielgruppe von
großer Bedeutung. Man muss dabei
darauf achten, ein breites Publikum
anzusprechen. Programmierer und
Entwickler gehören klar definiert zur
Zielgruppe bei Prototypen. Andere
Gruppen dagegen werden in der Praxis gerne vergessen. Man spezialisiert
sich zu sehr auf eine Gruppe. Die
Besucherzahlen bleiben klein. Häufig ein Grund für herausgeschmissenes Geld.
Realismus: Wichtig ist hierbei, darauf zu achten, verschiedene Anwendungsfälle abzubilden. Das Verhalten zwischen Anwender und System
wird untersucht. Die große und entscheidende Frage dabei ist nicht, wie
etwas passiert, sondern, was passiert.
se zwei Punkte nicht, was sich später
auf die Suchmaschinenoptimierung
auswirkt. Die Webseite wird von
den Suchrobotern von Google nicht
beachtet und landet somit nicht auf
der ersten Suchseite. Um solche Szenarien zu verhindern, ist es wichtig,
diese im Prototypen darzustellen.
Bei Auftreten können vorhandene
Probleme dann ausgemerzt werden.
Konzentration auf das Wesentliche
Ein Prototyp dient dem Zweck, dem
Benutzer einen Eindruck zu geben,
wie die Seite später aussieht, aber vor
allem, wie er welche Funktionen zu
verwenden hat. Fällt es ihm leicht,
sich durch die Webseite zu klicken,
ist man auf dem richtigen Weg. Hat
er dagegen Schwierigkeiten, ist es
Zeit, den Prototypen zu überarbeiSOP JOURNAL HOCHSCHULE REUTLINGEN R6
84
ITERATION++
ten. Um dies zu verhindern, ist es
wichtig, sich auf das Wesentliche zu
konzentrieren. Viele Webseiten sind
vollgestopft mit Schnickschnack,
zum Beispiel viele Werbebanner,
umfangreiche
Flashanimationen
oder zu viele Hyperlinks. Das alles
sieht toll aus, kann aber bei zu häufigem Auftreten irritierend und als
unübersichtlich oder störend empfunden werden. Wer möchte zum
Beispiel im Sekundentakt eingeblendete Werbebanner immer wieder
wegklicken?
Die Sache mit den Standards
Beispiel Button und seine Standards:
Ein Button reagiert beim Rollover,
bei einem Klick, sowie beim Loslassen. Je nach Programmierung verändert sich dabei die Farbe, die Schrift
etc. Hier handelt es sich um ein Verhalten eines Buttons, das wir kennen und selbstverständlich erwarten.
Diese und weitere Standards müssen
bei einem finalen Prototypen enthalten sein, denn nur so wird er auch
benutzerfreundlich und die daraus
entstehende Seite erfolgreich.
Fazit
Man sieht also: Durch genaues Hinterfragen, welche Anforderungen
wichtig und welche weniger wichtig
sind, entsteht der richtige finale Prototyp. Dadurch kann eine professionelle, übersichtliche Webseite – wie
die SOP-Webseite - entworfen werden. Lässt man sie weg, ist der Weg
zum finalen Prototypen und der
nachfolgenden Webseite gescheitert.
Der Schritt von einem skizzenhaften
Low-Fi-Prototyp zum funktionsfähigen High-Fi-Prototypen scheint klar.
Die Beispiele zeigen allerdings, wie
wichtig es ist, nicht irgendwelche
Anforderungen aufzustellen. Flashanimationen können eine Seite schön
aussehen lassen. Was ist allerdings,
wenn diese zu häufig auftreten? Vor
allem aber: Wie sieht es mit der Barrierefreiheit aus? Eine der wichtigsten
Anforderungen! Viele Leute machen
den Fehler, nach ihren persönlichen
Geschmack Anforderungen aufzustellen, aber nicht nach den Richtlinien des Webdesigns. Man muss sich
über folgende Fragen im Klaren sein:
Zu welchem Themenbereich soll die
Webseite gehören? Welche Benutzer
werden die Webseite besuchen? Wie
kommen diese mit den Funktionen
zurecht? Werden auch Benutzer mit
körperlichen Einschränkungen die
Webseite besuchen? Die Zielgruppe
und Anforderungen müssen genau
feststehen. Dabei gehören die angesprochenen Anforderungen zu den
wichtigsten überhaupt (vgl. [3]).
Setzt man Anforderungen sinn- und
wahllos ein, kann der Prototyp nicht
als final bezeichnet werden.
Quellen
[1] Jacobsen, Jens: Website-Konzeption: Erfolgreiche Web- und Multimediaanwendungen entwickeln,
Pearson Education, 2005
[2]http://www.w3.org/QA/2002/
04/Web-Quality#Standard,
[3] http://www.w3.org/WAI/intro/
accessibility.php,
ITERATION++
85
Content managen, aber sicher!
Typo3-Sicherheit für den SOP-Webauftritt
Wilfried Irßlinger
Das SOP geht online! Für das SOP
und die drei Firmen des Konsortiums
sind Webauftritte geplant. Diese sollen
mit Hilfe des Content Management
Systems Typo3 realisiert werden. Welche
Sicherheitsmaßnahmen sind hier zu
ergreifen? Wie sicher kann das SOPWebportal gemacht werden?
Typo3 im SOP-Webportal
Die Ausgangslage
lichkeit von Angriffen aus dem Internet, sowohl auf Typo3 als auch auf den
Apache Webserver.
Typo3 ist in der Version 4.2.3 auf dem
Webserver Apache Version 2.2.10 installiert, der wiederum auf dem oben
erwähnten Windows Server installiert
ist. Die somit öffentlichen Teile also
Typo3 und der Apache Webserver
müssen durch die Software- und Systemmanager (SSM) von ServIT geschützt werden.
–
Im SOP wird ein Windows Server
2003 eingesetzt, auf dem sowohl die
Werkzeuge zur Versionsverwaltung,
als auch die Webservices wie Zeiterfassung und Typo3 laufen. Da sich
der SOP-Server im Hochschulnetz
befindet, ist das Typo3 nur über eine
VPN-Verbindung oder vom Campusnetzwerk der Hochschule erreichbar.
Für die Webauftritte der einzelnen Firmen, welche nicht für jeden über das
Internet zugänglich sein sollen ist diese
Konstellation passend. Die Webseite
des Softwareprojekts sollte allerdings
für jeden erreichbar sein. Die dafür
notwendig Freischaltung wird durch
das Rechenzentrum der Hochschule
vorgenommen. Sobald dies geschehen
ist, erhöht sich auch die Wahrschein-
Angriffe und Gegenmaßnahmen
Da die SOP Webseite im Internet
für jeden zur Verfügung stehen wird,
muss auch mit dem ganzen Spektrum an Angriffsvarianten gerechnet
werden. Aber welche Angriffsvarianten gibt es überhaupt und wie kann
der SOP Webauftritt davon betroffen
sein?
Im folgenden Abschnitt werden beliebte Angriffsvarianten für webbasierte Dienste (vgl. [3]), wie Typo3
im SOP, beschrieben.
Brute-Force-Attacke: Allgemein wird
darunter das Herausfinden von Passwörtern, durch ausprobieren verschiedener Zeichenkombinationen
verstanden (vgl. [3]). Dabei wird oft
auch auf Wörterbücher zurückgegriffen, aus denen die Begriffe entnom-
men werden. Beim SOP Webportal
kann dieser Angriff an zwei Stellen
stattfinden:
1. Ein Angriff auf den Typo3-Backendzugang. Dabei ist vor allem der
Administrator-Zugang und das Installations-Tool gefährdet, denn über das
Installations-Tool können neue Administratoren und zentrale Typo3-Einstellungen geändert werden (vgl. [1]).
2. Ein Angriff auf die Zugänge der
Frontend-Nutzer, denn hier Arbeiten
auch weniger Typo3 erfahrene Nutzer
wie Stakeholder oder Projektmanager,
die sich der Thematik um sichere Passwörter evtl. nicht bewusst sind.
Eine Maßnahme um erfolgreiche Brute-Force-Attacken zu verhindern, ist
das Wählen sicherer Passwörter. Dabei
gibt es drei Punkte zu beachten (vgl.
[1]):
• Mindestens acht Zeichen
• Keine semantischen Wörter, sondern lose Kombinationen
• Zahlen und wechselnd Groß- und
Kleinschreibung verwenden
Im SOP könnte dies in einer Richtlinie
der Qualitätssicherung festgeschrieben
werden.
Eine weitere Gefahr für den SOPWebauftritt ist ein so genannter Manin-the-Middle-Angriff. Dabei kann
86
ITERATION++
über ein Paketsniffer, wie Wireshark,
bei der Kommunikation das Passwort
ausspioniert werden.
Um dies zu verhindern wird der
Backend-Zugang nur über eine verschlüsselte SSL Verbindung zugelassen. Die Webentwickler und SSM von
ServIT melden sich dann über diese
sichere Verbindung an. Dazu benötigt der Apache Webserver das Modul
mod_ssl. Zusätzlich muss in Typo3 die
Option [lockSSL] aktiviert werden.
Hier stehen vier verschiedene Einstellungen zur Verfügung, wobei für das
SOP die Variante „Anmeldung nur
über SSL-Verschlüsselung“ gewählt
werden sollte, um höchste Sicherheit
zu gewährleisten.
konkrete IP-Adressen über die Option
[IPmaskList] an eine Session gebunden
werden. Eine Übernahme der Session
ist somit nicht mehr möglich.
Auch die Angriffsmöglichkeit der
SQL-Injektion könnte für das SOPWebportal eine Gefahr sein. Hierbei
wird über ein Formular, wie beispielsweise die Suche, versucht, manipulierte Befehle in die Datenbank zu schleusen, um so Daten auszuspionieren
(vgl. [3]). Dies kann jedoch verhindert
werden indem ungeprüfte Benutzereingaben vermieden werden. Bei einem erfolgreichen Angriff könnten
im SOP beispielsweise Unbefugte an
die Passwörter und Zugangsdaten zum
Typo3-System gelangen.
„Sicherheit kann teuer sein, bei einem Angriff jedoch unbezahlbar.“
Wilfried Irßlinger, Software- und Systemmanagement
Neben dem Ausspähen von Passwörtern ist der SOP-Webauftritt auch
durch Cross-Site-Scripting gefährdet.
Dabei wird durch einen Angreifer
Java-Script oder ActiveX-Code in die
Webseite eingeschleust (vgl. [2]), um
beispielsweise eine Session in Typo3
zu übernehmen. Im SOP sollte deshalb die Typo3 Session an eine IP-Adresse gebunden werden. Da im Softwareprojekt nur die Webentwickler
und SSM von ServIT einen Zugang
zum Backend haben, können deren
Weitere Maßnahmen zur Absicherung des SOP-Webportals
Da im SOP Typo3 auf einem Apache
Webserver läuft, ist dessen Sicherheit
auch relevant. Er muss vor Denialof-Service-Angriffen (DoS) geschützt
werden, denn im SOP wird auf dem
Webserver neben Typo3 auch Subversion sowie weitere Dienste angeboten. Bei einem erfolgreichen Angriff
auf den Apache Webserver wäre es
zum Beispiel möglich, auf Subversion zuzugreifen und Daten zu steh-
len. Auch das Lahmlegen des Servers
durch eine DoS-Attacke würde für das
Softwareprojekt große Probleme verursachen, weil dann wichtige Werkzeuge,
wie das Zeiterfassungstool nicht mehr
zur Verfügung stehen würden. Deshalb
wird neben den Sicherheitsmaßnahmen für den Apache Webserver, wie
mod_evasive (vgl. [4]) zum Abwehren
von Denial-of-Service-Angriffen, bei
ServIT an einer grundlegende Änderung der Serverarchitektur gearbeitet.
Der Schaden bei einem erfolgreichen
Angriff kann zum Beispiel dadurch
verringert werden, dass der außerhalb des Campusnetzwerkes sichtbare
SOP-Webauftritt auf einem eigenen
Apache Webserver läuft. Somit sind
nur die wirklich benötigten Dienste,
wie Typo3 von Außen zugänglich. Das
Sicherheitsrisiko, das Subversion, das
ServIT interne Wiki oder die Zeiterfassung von Außen angreifbar wird,
wird so minimiert (vgl. [1]). Neben
den genannten Sicherheitsmaßnahmen gibt es noch weitere allgemeine
Typo3-Sicherheitseinstellungen. Diese
werden in Ebner/Schuster (2007) beschrieben.
Welchen Sicherheitsstand kann erreicht werden – Wie sicher ist das
SOP-Webportal?
Neben den oben beschriebenen technische Sicherheitsmaßnahmen ist vor
allem auch die richtige Administration
für die Sicherheit von Typo3 und des
SOP Webauftritts entscheidend. Denn
nach Ripfel/Meyer/Höppner (2008)
hängt die Sicherheit von IT-Projekten
ITERATION++
nicht nur von hoher Programmierqualität ab, sondern wird auch stark
von organisatorischen und menschlichen Faktoren bestimmt. Oft wird das
Thema Sicherheit auch nicht betrachtet, da die Aufwände für Sicherheit
nicht sofort im Ergebnis des Projekts
sichtbar sind (vgl. [3]).
Besonders im SOP können durch die
wechselnden Iterationen und somit
wechselnde Administratoren, organisationsverschuldete Fehler und dadurch
Sicherheitslücken entstehen. So sind
auch nicht ausreichend qualifizierte
Mitarbeiter, sowohl der Dienstleister,
d.h. wir bei ServIT, als auch der Auftraggeber (vgl. [3]), ein Risiko für die
Sicherheit. Die Sicherheit des SOPWebportals ist somit von einer guten
Dokumentation und der Wissensweitergabe der Iteration an die nachfolgende Iteration abhängig. Denn im
SOP kann nicht immer gewährleistet
werden, dass die Mitarbeiter bereits
Wissen und Erfahrung im Umgang
mit Typo3 haben. Um trotzdem die
nötigen Informationen bereitzustellen, bietet sich neben Dokumenten
im BSCW vor allem auch das ServIT
Wiki an um aktuelle Informationen
auf Seiten des Dienstleisters weiterzugeben.
Ausblick
Mit der Umstellung auf die neu geplante Serverarchitektur wird sich
auch für den SOP Webauftritt und
Typo3 einiges Ändern: Die Zeiterfassung sowie das geplante Ticketsystem
kann mit Typo3-Extensions realisiert
werden. Hier müssen sich die Webentwickler und SSM von ServIT mit
der Sicherheit von Extensions und
gegebenenfalls mit dem Melden von
Sicherheitslücken beschäftigen. Dazu
wird das Einspielen von Patches aber
auch das Installieren von Sicherheitsupdates für Typo3 gehören.
Fazit
Eine Garantie für die Sicherheit des
SOP-Webauftrittes kann nicht gegeben werden, da ständig neue Angriffsvarianten entwickelt werden und auch
immer wieder Sicherheitslücken in
Typo3 auftreten. Außerdem versuchen
immer häufiger auch professionelle
Cracker ins System einzudringen (vgl.
[1]) und es für ihre Zwecke zu nutzen.
Wenn eine absolute und totale Sicherheit hergestellt werden soll, „benötigen
Sie einen messbaren Abstand zwischen
Ihrem Computer und jedem anderen
Gerät“ (vgl. [5]). Abstand im obigen
Zitat bedeutet nach Nemeths (2009)
überhaupt keine Verbindung zu einem
Netzwerk. Manche Experten argumentieren sogar, dass man den Computer in einem speziellen Raum einschließen müsste, beispielsweise einem
Faradayschen Käfig, um elektromagnetische Strahlung abzuhalten (vgl. [5]).
Da es sich bei Typo3 jedoch um eine
Anwendung für ein Netzwerk handelt
sind diese Maßnahmen nicht umsetzbar. Die Sicherheit eines Systems hängt
aber auch von der Funktionalität und
dem Einsatzgebiet ab (vgl. [6]). Um
eine Einschätzung des Gefahrenrisikos
des SOP-Webauftrittes zu bekommen
87
wäre es deshalb sinnvoll eine Bedrohungs- und Risikoanalyse, wie sie
in Eckert (2007) beschrieben wird,
durchzuführen. Die Ergebnisse könnten dann in einer Sicherheitsstrategie
bzw. Sicherheitsrichtlinie (vgl. [6]) dokumentiert werden und würden zu einer nachhaltigen Verbesserung der Sicherheit des SOP Webportals führen.
Quellen
[1] Ebner, Alexander / Schuster, Patrick:
TYPO3 und TypoScript - Kochbuch.
Lösungen für die TYPO3-Programmierung mit TypoScript und PHP; Carl
Hanser Verlag, München, 2007.
[2] http://www.rrzn.uni-hannover.de/fileadmin/it_sicherheit/LV-WS0809/LV20090116.pdf , Stand: [15.04.09].
[3] Ripfel, Franz/Meyer, Melanie/Höppner, Irene: Das Typo3 Profihandbuch,
der Leitfaden für Entwickler und Administratoren zu Version 4.1; AddisonWesley, München, 2008.
[4] Andreas/Rieser, Christoph/Ehscheidt: Typo3, aber sicher!: Sicherheitsmaßnahmen für Typo3-Administratoren ; t3n open source & web – online
im WWW unter URL: http://t3n.yeebase.com/magazin/typo3-sicher-sicherheitsmassnahmen-typo3-administratoren-219377/ [16.04.09].
[5] Nemeth/Evi, Snyder/Garth, Hein/
Trent: Linux-administrationshandbuch;
Pearson Education, 2009.
[6] Eckert/Claudia: IT-sicherheit: Konzepte - Verfahren - Protokolle; Edition 5;
Oldenbourg Wissenschaftsverlag, 2007.
88
ITERATION++
E-Learning im Softwareprojekt
Sind Rational-Werkzeuge noch zu retten?
Jochen Budzinski
Die
IBM-Rational-Werkzeuge
dienen in vielfältiger Weise dem
Projektmanagement und bilden einen
umfangreichen Datenbestand auf dem
Server der Firma ServIT. Aufgrund
der schwierigen Installation sinkt jedoch die Nachfrage dieser Tools, was
ein iterationsübergreifendes Problem
darstellt. Als Ausweichstrategie der
Mitarbeiter werden andere, unterschiedliche Werkzeuge auf unterschiedlichen Servern verwendet. Die
Konsistenz bzw. der Zusammenhang
der Daten, erzeugt und verwaltet von
den Rational-Werkzeugen, droht verloren zu gehen. Ein eigens entwickeltes e-Learning-Programm soll nun die
Installationshilfe vereinfachen, damit
die Installation für jeden umsetzbar
wird und somit der Einsatz bzw. die
Nachfrage der Programme steigt. Doch
stellen sich damit die Fragen: Lässt sich
überhaupt ein Programm dieser Art
entwickeln? Und viel wichtiger: Führt
es zum Erfolg?
Probleme mit den Rational-Tools?
Im Softwareprojekt nichts Neues!
Zu Beginn der Iteration R6 wurde das
Bereitstellen der Rational-Tools beSOP JOURNAL HOCHSCHULE REUTLINGEN R6
kannt gegeben, was unter den Aufgabenbereich des Teams Software- und
Systemmanagements (SSM) der Firma ServIT fällt. Diese eigenständigen Werkzeuge dienen in Form von
Versionsmanagement
(ClearCase),
Anforderungsmanagement (RequisitePro) und Änderungsmanagement
(ClearQuest) als Konfigurations- und
Änderungsmanagement-System. Zusammenfassend gesagt, ist das Anwendungsspektrum der IBM Tools groß,
da es nicht nur für die Mitarbeiter der
Softwareentwicklung zur Versionsverwaltung von Programmen und CodeDateien dient, sondern auch von den
Projektmanagern eingesetzt werden
kann, um Anforderungen an Projekte
und Mitarbeiter zu erstellen und zu
verwalten.
Das Problem: Die Nachfrage an die
IBM Werkzeuge ist sehr niedrig, und
„niedrig“ heißt, durchschnittlich unter 10 Personen pro Iteration. Dabei
sind die Mitglieder nicht abgeneigt ein
neues Programm zu erlenen, sondern
scheuen sich vor der Installation. Die
Ursache hierfür liegt in der Anmeldung an einer Domäne (ClearCase)
und in der aufwendigen Konfiguration (RequisitePro), um die Datenbestände im System zu integrieren.
Installationshilfe PDF zwecklos
Laut Mitarbeitererfahrungen, waren
es unerwartete Ereignisse wie Fehlermeldungen oder Warnungen, welche
die Benutzer zum Abbruch zwangen. PDF-Dokumente wurden dabei
als Installationshilfe eingesetzt. Die
Ursache lag dabei oft am flüchtigen
Lesen der Dokumente, wodurch falsche Eingaben betätigt wurden oder
man sich nicht, wie als Vorbedingung
beschrieben, über den Cisco VPNClient im Hochschulnetz befand.
Die Iteration R5, setzte als Alternative
zum PDF-Dokument, die Idee einer
„Installationsparty“ um, bei der unter
direkter Anleitung eines Softwareund Systemmanagers, die Installation
der Rational-Tools schrittweise begleitet wurde. Der Veranstalter SSM
R5 sagte, dass die Erfolgsquote, die
Werkzeuge zu installieren, hoch war.
Das Problem war aber eine geringe
Teilnehmeranzahl. SSM R5, sahen die
Ursache eher am organisatorischen
Aufwand als an fehlender Motivation, da bei einer steigenden Anzahl
an Teilnehmern sich die Wahrscheinlichkeit verschlechterte, für alle einen
passenden Termin zu finden. Aus diesem Grund fand eine Veranstaltung
dieser Art für die Mitarbeiter der Iteration R6 nicht mehr statt.
ITERATION++
Subversion und Trac als Ersatz der
Rational-Tools
Einfacher sind Installation und Umgang mit Subversion (SVN) der Firma CollabNet, ein Versionsmanagement Tool und Open Source Pendant
zu ClearCase. Zusammen mit dem
Werkzeug TortoiseSVN, lässt sich der
Zugriff auf die abgelegten Daten auf
dem SVN Server über Explorer-Integration einfach umsetzen (vgl. [1]).
Aber nicht nur ClearCase, sondern
als ein zusammenarbeitendes Konfigurations- und Änderungsmanagement-System.
Zweiter Kritikpunkt: Die Geschäftsleitung warnt vor einem eigensinnigen Verhalten im Softwareprojekt,
bei dem jeder zum eigenen Vorteil,
Software oder Hardware Lösungen
unterbreitet und das Gegenteil eines gemeinschaftlichen Prozesses bewirkt.
„Die Konsistenz bzw. der Zusammenhang der Daten, erzeugt und verwaltet
von den Rational-Werkzeugen, droht
verloren zu gehen.“
Jochen Budzinski, Software- und Systemmanagement
auch der Gebrauch von RequisitePro
könnte durch das Open-Source-Tool
Trac ersetzt werden. Trac hingegen
bietet in Form eines Wikis einen
deutlich geringeren Funktionsumfang an, als das IBM-Tool und ist
somit auch kein vollständiger Ersatz
für ein AnforderungsmanagementInstrument. Mit dem Einsatz der
beiden Werkzeuge kommen daher
zwei Kritikpunkte auf:
Erster Kritikpunkt: „ClearCase ist
ein Zahnrad des IBM Rational-Systems, ersetzt man es, so greifen die
Zahnräder nicht mehr ineinander“
(vgl. [1]). Im Sinne dieses elementaren Bauteils besitzen die 3 RationalWerkzeuge ihre Daseinsberechtigung
Subversion und Trac wurden von
der Softwareabteilung (Iteration R6,
Firma ITer@) eingeführt und werden bereits firmenintern für die Versions- und Codeverwaltung eingesetzt. Gesetz dem Fall, andere Abteilungen und Firmen würden ebenfalls
unterschiedliche Programme als Ersatz für die Rational-Tools verwenden, drohen die Daten, erzeugt und
verwaltet von den Rational-Werkzeugen, verloren zu gehen. Um der zurückgehenden Nachfrage der Rational-Tools entgegen zu wirken, muss
an zwei Punkten gearbeitet werden:
Zum einen muss gegen Fehler vorgebeugt werden, die während der Installation aufkommen und zum anderen muss man die Motivation bei
89
dem Mitarbeiter erhöhen, sich mit
diesen Tools auseinander zu setzen.
Folgedessen muss eine neue Methode der Installationshilfe angewendet
werden, die ein Mittelstück zwischen
Textform und Schulung ist und bei
Bedarf abrufbar ist. Dies kann durch
eine einfache Lernplattform bewirkt
werden.
Lösungsansatz - Der Begriff Lernplattform und die Eingrenzung auf
die „einfache Lernplattform“
Eine allgemeine Definition einer
Lernplattform wird von Peter A.
Henning gegeben. Demnach ist eine
Lernplattform ein „komplexes Softwaresystem“ welches „Lerninhalte
bereitstellt und den Lernprozess organisiert“. Neudeutsch wird dieser
Begriff auch mit „Learning Management System, LMS“, gleichgesetzt.
Das Organisieren des Lernprozesses
schließt dabei eine direkte Verständigung der Lernenden und Lehrenden mit ein, folglich bietet ein LMS
Funktionen zum Nachrichtenaustausch an, mittels „Chat-Räumen“
oder Foren (vgl. [8]). „Relax“, der
Hochschule Reutlingen ist ein Beispiel für eine Lernplattform diesen Umfangs (vgl. [7]). Der Begriff
Lernplattform ist nach dieser Definition Umfangreich und muss auf den
SOP-Kontext eingeschränkt werden.
Angestrebt wird ein e-Learning-Programm, das Videos bereitstellt, die
den Ablauf der Installation vorführen
und auch mit Audiokommentaren
versehen sind – einem sog. VideoSOP JOURNAL HOCHSCHULE REUTLINGEN R6
90
ITERATION++
Tutorial. Das Programm wird also
keine Funktion zum Nachrichtenaustausch anbieten und vereinfacht
sich auf die Videos als Lerninhalt
und einer Navigation zur Videoauswahl. Für den Nachrichtenaustausch
wird hierbei auf die Organisationsrichtlinie 1.5 verwiesen, welche die
Programme zur Kommunikation im
SOP vorgibt und für Kurzmitteilungen, Kommentare oder Fragestellungen zu verwenden ist. Als Beispiele
sind zu nennen: Instant Messenger
(bsp. ICQ), E-Mail oder Skype (Telefonie) (vgl.[9]).
Die Frage nach Qualität
Die Qualität einer digitalen Lernunterstützung kann anhand von Kriterienkatalogen gemessen werden.
Ulrike Rockmann, definierte für die
Qualitätssicherung 370 Kriterien
und unterteilte diese in sieben Bereiche, wie beispielsweise Rahmenbedingungen (Zielsetzung, Zielgruppe), Technische Aspekte (Nutzer,
Betreiber, Produkt) oder Funktionalitäten (Steuerung, Steuerungsunterstützung)(vgl. [6]).
Für das Softwareprojekt wird eine
einfache Lernplattform in Form einer Anwendung zur Steuerung von
Video-Tutorials mit den Trägern Bild
und Audio verwendet. Der Kriterienkatalog von Ulrike Rockmann, wird
hinsichtlich des e-Learning-Produktes für das SOP als Orientierung
und als Hilfe für die Konzeptionierung, sowie der Anforderungsanalyse verwendet. Bei Peter A. Henning
werden Fragen zur Auswahl eines
geeigneten LMS gestellt und in die
Konzeptionierung miteinbezogen.
Der Lösungsvorschlag
Sinnvolle Benutzer-Aspekte als Basis
für die Umsetzung des e-LearningProgramms nach Ulrike Rockmann:
Wie gelangt der Benutzer an die Tutorials (gemäß: Technische Aspekte)?
Sind die Informationen auf dem aktuellen Stand (gemäß: Kodierung
der Informationen)? Werden die
Lösungsvorschläge kommentiert (gemäß: Kodierung der Informationen)?
Kann der Benutzer das Lerntempo
und Reihenfolge selbst steuern (gemäß: Funktionalität)? (vgl. [6]).
Angelehnt an die Auswahlkriterien
von Peter Henning werden desweiteren Anforderungen an die Administration gestellt:
Welche Kosten entstehen bei der
Entwicklung? Wie wird das Pflegen
von Daten ermöglicht? Wie viel Personen/Administratoren werden für
die Verwaltung wie Aktualisierung
benötigt? Wie hoch sind die Verwaltungskosten? (vgl. [8], S. 586f ).
Gemäß dieser Kriterien wird die
Qualität und der Erfolg des e-Learning-Programms nicht nur durch
den Lerninhalt, den Video-Tutorials
und Audiokommentaren bestimmt,
sondern auch durch die Verfügbarkeit der Videos und deren Aktualität. Desweiteren ist für die Güte
bestimmend, mit welchem Aufwand
und Kosten die administrative Verwaltung zu bewältigen ist, damit beispielsweise eine einfache Lerninhalterweiterung ermöglicht wird (bsp.
neue Video-Tutorials).
Die Ursachen der Installationsprobleme werden in zwei gleichgewichteten Aspekten erfasst, die durch das
e-Learning-Programm gelöst werden
sollen: Mangelnde Motivation und
Fehler durch Eigenverschuldung.
Durch optimale Umsetzung der Kriterien, ist das einzusetzende e-Learning-Programm technisch sowie pädagogisch geeignet – theoretisch, um
die Motivation der Mitarbeiter zu
erhöhen (durch einfache Verfügbarkeit, bildhafte Darstellung der Installation, gute Strukturierung der Videoreihenfolge) und die Fehler durch
Eigenverschuldung zu reduzieren
(durch Vorzeigen der Installation,
muss der Benutzer nur diese Schritte
zur erfolgreichen Installation nachmachen). Folglich würde das den
Gebrauch der Rational-Werkzeuge
aufrecht erhalten.
Kritikpunkte
1. Bei Fehler durch Systemverschuldung oder bei Fehler oder Warnung
die unerwartet aufkommen (die
nicht in den Video-Tutorials vermerkt sind) ergibt das e-LearningProgramm keinen Vorteil, gegenüber
der traditionellen PDF-Installationshilfe. Der Installateur muss bei solchen Ereignissen nach wie vor Hilfe
vom SSM Support beanspruchen.
ITERATION++
2. Es gibt viele Kriterienkataloge.
Welchen Katalog man für welche
Anforderungen einsetzt, steht im
Zusammenhang mit der resultierenden Güte. Ist der Kriterienkatalog
ungeeignet oder betrachtet man die
falschen Kriterien als Basis für die
Entwicklung des e-Learning-Programmes, so kann dies Qualitätsverlust verursachen und führt somit
zu einem Misserfolg des e-LearningProgrammes als Installationsunterstützung der IBM-Werkzeuge.
Zusammenfassung und Ausblick
Ein Kriterienkatalog wird als Konzeptorientierung eines e-LearningProgrammes
verwendet.
Dabei
wurden die Kriterien nach eigenem
Ermessen herausgefiltert und als
Anforderungen an das e-LearningProgramm deklariert. Ziel ist es, die
Installation der IBM-Werkzeuge den
SOP-Mitglieder anhand von VideoTutorials verständlich zu übermitteln. Der Lerninhalt wird als Anwendung in Form einer eingeschränkten
Lernplattform bereit gestellt. Die
herausgefilterten Kriterien, verglichen mit den momentanen Installationsproblemen, ergaben einen
theoretischen Nutzungserfolg für
das darauf basierende e-LearningProgramm. Jedoch ist zu kritisieren,
dass die Filterung der Qualitätskriterien nach eigenem Ermessen stattfand und das e-Learning-Programm
nach wie vor gegenüber unerwartete Ereignisse im Installationsverlauf
nutzlos ist.
Ob der theoretisch ermittelte Erfolg
eintritt, kann erst dann gezeigt werden, wenn ein e-Learning-Programm
auf Basis der ausgearbeiteten Qualitätskriterien eingesetzt wird. Ist dies
der Fall, so könnten neben Installationshilfen der Rational-Werkzeuge,
auch Anwendungs-Tutorials für
Anfänger und Fortgeschrittene entwickelt und zur Verfügung gestellt
werden. Eines von vielen Beispielen
wäre ein Video-Tutorial, welches
Schritt für Schritt die Benutzung eines Programmes erklärt. Tatsächlich
muss abgewartet werden, ob solche
Installationshilfen in der Zukunft
angewendet werden.
91
[7]Lernplattform Relax, Hochschule
Reutlingen: https://relax.reutlingenuniversity.de/
[Stand 15.04.09]
[8] Peter A. Henning, Taschenbuch
Multimedia, Carl Hanser Verlag,
München, 2007.
[9] SOP-internes Richtliniendokument, nicht veröffentlicht.
Quellen
[1] Ulf Maier, Der schnelle und
einfache Weg zur gemeinsamen Dateiablage, In: Iteration++ S. 50-52,
Hochschule Reutlingen, 2009.
[2] http://www.open.collab.net/products/subversion/ [Stand 03.04.09].
[3] http://tortoisesvn.tigris.org/
[Stand 03.04.09].
[4] http://trac.edgewall.org/
[Stand 03.04.09].
[5] http://www.ihk-ostbrandenburg.
de/res.php?id=35>
[Stand 05.04.09].
[6] Ulrike Rockmann, e-Learning:
Forschung & Qualitätssicherung /
eL- Qualitätskriterien
ITERATION++
93
Softwareprojekt R6 / Sommersemester 2009
hinten v. l.: Thomas Staiger, Patrick Gaßner, Flavia Di Laudo, Fabian Liedtke, Wolfgang Keller, Peter Hertkorn, Daniel Wenhardt,
Uwe Kloos, Konstantin Adler, Dominic Schwörer, Jaroslaw Zawadzki
mitte v. l.: Manuela Di Laudo, Christian Kubat, Zehra Türkkan, Sarah Letzgus, Natalia Zyleva, Markus Jülich, Jochen Budzinski,
Denis Merkle, Silke Link, Matthias Huber, Marco Bischof, Wilfried Irßlinger
vorne v. l.: Stephanie Höhn, Gerold Lacher, Simon Hänel, Torsten Lutz, Samet Keser, Mario Schwarz, Eduard Tudenhöfner
auf dem Bild fehlt: Dennis Riekert
Impressum
Inhalt und Organisation
Patrick Gaßner
Gerold Lacher
Konstantin Adler
Verleger
Fabian Liedtke
Dominic Schwörer
Denis Merkle
Silke Link
Manuela Di Laudo
Redaktionsberatung
Franziska Strobusch
Fotografie
Stephanie Höhn
Alteburgstraße 150
72762 Reutlingen
94
ITERATION++
Alteburgstraße 150
72762 Reutlingen
SOP
Iteration R6

iteration++ - MediaArchiv

Transcription

Documents pareils

1. Stellungnahme des AK PCR-Analytik von 2013

Beach: ...Symphonie aus Land und Meer SOP

Mathenachhilfe in Reutlingen

nichts wie weg. - Evangelische Kirchengemeinde Sondelfingen

Projektmitarbeiters (m/w)

Träger Johannes-Kepler-Gymnasium Reutlingen Ansprechpartner

PR- und Marketing Mitarbeiters (m/w)

Die Besten aus 14 Gewerken - Handwerkskammer Reutlingen