close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

D4.5.1.2-SLM_C3Grid - ENES

EinbettenHerunterladen
C3Grid-INAD: towards an INfrastructure for
general Access to climate Data
D4.5.1.2: Ein Rahmen fu
¨r das
Softwaremanagement in C3Grid-INAD
Author(s):
Markus Kemmerling, Benny Br¨auer, Tassilo Galonska,
Ulrike Golas, Christian Grimme
EMail:
markus.kemmerling@udo.edu, benny.braeuer@awi.de,
tassilo.galonska@udo.edu, golas@zib.de,
christian.grimme@udo.edu
Editor(s):
C. Grimme, M. Kemmerling
Partner(s):
AWI, DKRZ, RRZK, TUDo, ZIB
Lead Partner:
TU Dortmund
Workpackage:
AP4.5.1: Production-Grade Infrastructure and Operations
Deliverable:
D4.5.1.2
Version Identifier:
2.0
Date:
28. September 2012
Document Classification: Public
Project: C3-INAD: Towards an INfrastructure for general Access to climate Data
Gef¨ordert vom BMBF, F¨
orderkennzeichen: 01LG1004A-I
Laufzeit: Oktober 2010 – September 2013
Abstract
In diesem Dokument wird ein gemeinsames Vorgehen f¨
ur das Softwaremanagement im
Rahmen des C3Grid-INAD Projektes vorgeschlagen. Dabei werden Releasezyklen, die
Aufnahme von Nutzerfeedback, der Betrieb von Testumgebungen sowie die Durchf¨
uhrung von Systemtests adressiert.
¨
Anderungen
Version
0.1
Date
23.08.2011
Name
C. Grimme
0.2
0.3
1.0
1.1
1.2
1.3
07.09.2011
14.09.2011
29.09.2011
24.08.2012
27.08.2012
27.08.2012
M.
M.
M.
M.
M.
M.
1.4
28.08.2012
M. Kemmerling
1.5
1.6
1.7
1.7.1
1.8
1.8.1
1.8.2
29.08.2012
31.08.2012
10.09.2012
14.09.2012
21.09.2012
25.09.2012
26.09.2012
M. Kemmerling
T. Galonska
U. Golas
B. Br¨
auer
B. Br¨
auer
B. Br¨
auer
M. Kemmerling
2.0
28.09.2012
M. Kemmerling
Kemmerling
Kemmerling
Kemmerling
Kemmerling
Kemmerling
Kemmerling
Brief summary
Grundstruktur und Ergebnisse der Diskussionen
zwischen C. Grimme (TuDo), A. Papaspyrou
(TuDo) und M. Kemmerling (TuDo).
Diverse Erg¨anzungen.
¨
Anderungstabelle.
Deckblatt.
Umfang von Releases.
Konkretisierung der Artefakte eines Release.
Umstrukturierung des Release-Abschnitts, Reviewing von Doku.
Umsetzung der Release-Anforderungen f¨
ur den
WSS.
Reviewing von Dokumentation.
Korrekturen.
1.3.4, 1.3.5, Korrekturen.
Portalzeile in Tabelle 2.1.
Releasedefinition Portal.
Update Releasedefinition Portal.
Deckblatt Aktualisiert, Tippfehler Korrigiert,
Zeilenumbr¨
uche.
–
Inhaltsverzeichnis
1 Projekt¨
ubergreifende Umsetzung
1.1 Anforderungsanalyse und Definition von Features
¨
1.2 Ubergreifende
zeitliche Festlegungen . . . . . . .
1.3 Releases . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Umfang allgemein . . . . . . . . . . . . .
1.3.2 Portal-Releases . . . . . . . . . . . . . . .
1.3.3 WSS-Releases . . . . . . . . . . . . . . . .
1.3.4 DMS-Releases . . . . . . . . . . . . . . . .
1.3.5 Vold/ADiS-Releases . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
7
8
10
12
14
15
2 Reviewing von Dokumentation
17
3 Aufnahme und Vermittlung von Nutzer-/Entwicklerfeedback
19
4 Lokale Umsetzung
21
5 Betriebsumgebungen f¨
ur Produktion und Test
23
4
1 Projekt¨
ubergreifende Umsetzung
Das globale Softwaremanagement beschr¨ankt sich in dem vorliegenden Vorschlag auf
die Zurverf¨
ugungstellung eines Rahmens f¨
ur die geordnete Umsetzung der Projektziele
und richtet sich dabei stark nach den Vorschl¨agen des WissGrid-Projektes, das einen
Leitfaden f¨
ur einen generischen Softwareprozess zur Verf¨
ugung stellt. Das dort als evolution¨arer, Meilenstein-getriebener Prozess beschriebene Vorgehen basiert auf der Annahme, dass sich die Infrastruktur iterativ in einem zyklischen Vorgehen von Meilenstein
zu Meilenstein entwickelt, siehe Abbildung 1.1. Dabei wird auf dem Antragsdokument
des Projektes aufgebaut, es ist jedoch in jeder Iteration m¨oglich, die Entwicklung durch
neue Anforderungen in Form von ausf¨
uhrlich spezifizierten Meilensteinen in ihrer Ausrichtung zu korrigieren. Dieses Vorgehen versucht einerseits der weitgehend entkoppelten
Zusammenarbeit von Projektpartnern in Gridprojekten einen einheitlichen Rahmen zu
geben, und gleichzeitig eine relativ kurzschrittige Generationenfolge von Infrastrukturversionen sicherzustellen. Außerdem erlaubt dieser Ansatz, allgemeine Anforderungen
aus dem Projektantrag erst in bestimmten Iterationen zu konkretisieren und umzusetzende Funktionalit¨
aten mit Priorit¨
aten zu versehen.
Einige der vorgeschlagenen Konzepte werden hier auf C3Grid-INAD u
¨bertragen und
angepasst. Da die einzelnen Softwarekomponenten in C3Grid-INAD sicherlich in lokalen
Prozessen entwickelt werden, umfasst das globale Softwaremanagement insbesondere die
Analyse von Anforderungen und Definition von Gesamtzielen einer Produktiteration
(im Folgenden ”Projektmeilenstein” genannt) sowie die Aufnahme und Vermittlung von
Nutzer-/Entwicklerfeedback, das dann in lokale Entwicklungsstr¨ange zur¨
uckfließen kann.
Beide Punkte werden im Folgenden diskutiert.
1.1 Anforderungsanalyse und Definition von Features
Als Grundlage f¨
ur die weitgehend verteilte Entwicklung von Softwarekomponenten f¨
ur
das Gesamtsystem (C3Grid Portal, C3Grid WSS, C3Grid DMS, Datenanbindung, . . . )
muss ein Anforderungs- und Funktionskatalog (eine Art Lastenheft) erstellt werden, der
einerseits die vom Antrag vorgegebenen Ziele abdeckt und andererseits die Nutzeranforderungen (sowie ggf. auch sp¨
ater hinzukommende Anforderungen) aufnimmt und detailliert darstellt.
Dieser Katalog soll jedoch nicht das Endprodukt nach Projektende beschreiben, sondern die Entwicklungsschritte der Infrastruktur und Plattform in sogenannten Projektmeilensteinen darstellen, die iterativ entwickelt werden. Zugleich sind diese Projektmeilensteine die Grundlage f¨
ur projektweite Integrations- und Nutzungstests. Weiterhin
muss ein jeder Meilenstein auf schnelle Umsetzbarkeit ausgerichtet sein und daher verschiedene Anforderungen erf¨
ullen:
Begrenzter Umfang und kurze Entwicklungsphase: Um einen Projektmeilenstein weit-
5
Abbildung 1.1: Meilensteinbasierter, iterativer Entwicklungsprozess aus dem WissGridProjekt.
gehend planbar zu halten, sollte der Funktionsumfang, der bei jeder Iteration hinzukommt, begrenzt werden. Daraus ergibt sich jedoch direkt, dass mehrere zeitlich u
¨berschaubare Meilensteine definiert werden. Ein zu großer Funktionsumfang
w¨
urde hingegen zu erheblicher Planungsunsicherheit im Projektverlauf f¨
uhren, da
die lokalen Entwicklergruppen einen sehr großen Funktionsumfang pro Iteration
abdecken m¨
ussten. Gleichzeitig f¨allt die Beschreibung eines detaillierten Funktionsumfangs sehr schwer und ist nicht flexibel auf neue Anforderungen anpassbar.
Detaillierte Beschreibung: Eine detaillierte Beschreibung der Anforderungen eines Projektmeilensteins ist essentielle Voraussetzung f¨
ur die noch detailliertere Planung
auf Ebene der lokalen Entwicklergruppen. Diese Gruppen identifizieren aus der
Beschreibung die entsprechenden, sie betreffenden und ihrem Softwareprodukt hinzuzuf¨
ugenden Features.
¨
1.2 Ubergreifende
zeitliche Festlegungen
Um iterativ und regelm¨
aßig die Funktionalit¨at der C3Grid-Infrastruktur zu erweitern
und einen dem Antrag entsprechenden produktiven Status zu erreichen, ist es sinnvoll die Projektlaufzeit in verschiedene Projektmeilensteine einzuteilen. Diese sollen als
funktionsf¨
ahige Zwischen- oder Teill¨osungen erreicht werden. Im Projektverbund muss
daher definiert werden, welche Ziele wann zu erreichen sind. Eine entsprechende Beschreibung ist in Form eines Meilensteinlastenheftes anzufertigen. Diese Ziele bilden dann die
Grundlage f¨
ur die individuelle Planung von Releases der einzelnen Entwicklergruppen
(Development-Teams – DT) und f¨
ur sp¨atere Tests.
Dabei kann jedes lokale Entwicklerteam seinen eigenen Releasezyklus festlegen. Der
lokale Releasezyklus muss erheblich k¨
urzer als ein Projektmeilensteinzyklus sein, eine
Gleichheit der L¨
ange der lokalen Zyklen ist jedoch nicht Voraussetzung. Um die Konsis-
6
1
Projektende
DT1
DT2
DT3
Projektlaufzeit + x
M1
M2
M3
M4
M5
Abbildung 1.2: Schematische Darstellung des zeitlichen Verlaufes der Projektentwicklung inklusive Projektmeilensteine (M1-M5) und individueller Releasezyklen der einzelnen Entwicklergruppen (Development Teams - DTs).
Beispielhaft ist an Zeitpunkt (1) die Abh¨angigkeit des Releases von DT2
zu den Releases der Gruppen DT1 und DT3 dargestellt.
tenz der Releases bei unterschiedlichen Releasezyklen zu gew¨ahrleisten, baut jedes Team
im Rahmen seines Releasezyklus auf den zum eigenen Releasezeitpunkt aktuellen Releases anderer Entwicklungsteams auf. Damit ist auch ausschließlich die Kompatibilit¨at zu
diesen Releases gegeben. Implizit heißt dies, dass ein Release bereits vor oder sp¨atestens
zu dem Zeitpunkt des Projektmeilensteins die Funktionalit¨at des Meilensteins erf¨
ullen
muss. Darauf ist bei der Festlegung der Zielsetzungen der Projektmeilensteine und Releases auf globaler wie lokaler Ebene zu achten. Als alternative Variante zu der sehr
restriktiven Planung von Releases, kann zum Zeitpunkt des Meilensteins ein Zwischenrelease eingeplant werden. Hier sind dann sp¨atestens die Funktionen des Meilensteins
verf¨
ugbar.
Durch dieses Vorgehen ist klar festgelegt, auf welchen Releases einzelner Komponenten
ein Projektmeilenstein basiert. Dieser Zusammenhang ist in Abbildung 1.2 beispielhaft
dargestellt. Zu einem Zeitpunkt (1) wird der lokale Releasezyklus der Entwicklergruppe
DT2 fertig. Da DT1 und DT3 erst nach dem Zeitpunkt (1) ein neues Release freigeben,
basiert das Release von DT2 auf alten Releases der Teams DT1 und DT3.
1.3 Releases
Dieser Abschnitt beschreibt, welche Artefakte ein Release umfasst. Abschnitt 1.3.1 beschreibt den allgemeinen Umfang, w¨
ahrend in den Abschnitten 1.3.2-1.3.5 f¨
ur die in
C3Grid entwickelten Softwarekomponenten detailliert beschrieben wird, wie und in welcher Form die geforderten Artefakte bereitgestellt werden.
¨
Die in diesem Abschnitt benutzten Schl¨
usselworte MUSS /MUSSEN
und
SOLL/SOLLTE sind im Einklang mit RFC-2119 [1] zu interpretieren.
7
1.3.1 Umfang allgemein
Ein Release MUSS die folgenden Artefakte umfassen.
• README
• Changelog
• Softwarelizenz
• Software in Bin¨
arform
• Quellcode
• Dokumentation
– Bedienungsanleitung f¨
ur Nutzer
– Administrationsanleitung f¨
ur Betreiber
– Entwicklerdokumentation
Weiter SOLLTE ein Release die folgenden Artefakte beinhalten.
• Unittests
• Lizenzen von Dritten
¨
Die zu einem Release geh¨orenden Artefakte MUSSEN
f¨
ur jeden, der auf das Release
der Softwarekomponenten zugreifen soll, ohne zus¨atzlichen Aufwand verf¨
ugbar sein.
README
Die README MUSS den Namen der Softwarekomponente und eine kurze funktionale
Beschreibung enthalten. Weiter muss in ihr erkl¨art werden, wo die anderen Artefakte
des Releases zu finden sind.
Changelog
¨
¨
In der Changelog MUSSEN
alle Anderungen
am Quellcode der Softwarekomponente seit
¨
dem letzten Release genannt werden. Dar¨
uber hinaus ist eine Nennung der Anderungen
an anderen, nicht zum Quellcode geh¨orenden Dateien m¨oglich.
Softwarelizenz
Die Lizenz, unter der die Software ver¨offentlicht wird, MUSS vollst¨andig ausgeliefert
werden. Die Lizenz MUSS definieren, unter welchen Bedingungen die Software genutzt,
weitergegeben und ver¨
andert werden darf.
8
Software in Bin¨
arform
Die Software MUSS in einer in Maschinensprache u
¨bersetzten Form ver¨offentlicht wer¨
den. Besteht die Software nach der Kompilierung aus mehreren Dateien, MUSSEN
diese
in einem geeigneten und verbreiteten Archivformat (z.B. zip, tar.gz etc.) gepackt werden.
Quellcode
Der Quellcode inklusive Build-Skript einer Softwarekomponenten MUSS im zentralen
Subversion Repository1 ver¨
offentlich werden. Vorgaben, wo und wie ein Release im SVN
abzulegen ist, ist im Dokument Richtlinie f¨
ur die Ablage von Softwareentwicklungen im
Projekt C3Grid-INAD definiert.
Dar¨
uber hinaus SOLLTE der Quellcode inklusive der Build-Skripte in einem geeigneten und verbreiteten Archivformat (z.B. zip, tar.gz etc.) gepackt und zum Download
angeboten werden.
Bedienungsanleitung f¨
ur Nutzer
Unter dem Nutzer einer Softwarekomponenten ist nicht immer der Endnutzer des C3Grid
gemeint. Ein Nutzer einer Softwarekomponente kann auch der Entwickler einer anderen
Softwarekomponente sein, wenn dessen Softwarekomponente die Dienste der zu dokumentierenden Komponente benutzt.
Die Bedienungsanleitung MUSS f¨
ur jede Art von Nutzer (Endnutzer, Entwickler anderer Komponenten) beschreiben, wie die Software zu benutzen ist. Das beinhaltet u.a.
alle vorbereitenden Schritte wie z.B. die Installation eines Clienten oder Softwarebibliotheken. Die Anleitung MUSS die Konfiguration und Benutzung des Clienten/der
Bibliotheken beschreiben, das Kommunikationsprotokoll erkl¨aren sowie die Syntax und
Semantik von Dateien, die zur/von der Komponente gesendet werden, definieren und
erkl¨aren.
Die Bedienungsanleitung SOLLTE Screenshots und Kommandozeilenaufrufe sowie Benutzungsbeispiele beinhalten.
Administrationsanleitung f¨
ur Betreiber
Die Administrationsanleitung MUSS eine Schritt f¨
ur Schritt Erkl¨arung der Installation
und der Konfiguration der Softwarekomponente beinhalten. Hat die Komponente Anfor¨
derungen an die Hardware, MUSSEN
diese genannt werden. Ebenfalls sind Abh¨angigkeiten zu anderen Programmen und Bibliotheken zu nennen. M¨
ussen diese separat von
der eigenen Softwarekomponente installiert und konfiguriert werden, MUSS das ebenfalls beschrieben oder auf die Dokumentation des jeweiligen Drittanbieters verwiesen
werden. Eine spezielle Konfiguration der Drittsoftware zur Benutzung mit der eigenen
Komponente MUSS in jedem Fall beschrieben werden.
1
http://aforge.awi.de/svn/c3grid
9
Weiter MUSS beschrieben sein wie die Software zu warten ist. Das MUSS die Beschreibung einer Adminstrationsschnittstelle (z.B. Kommandozeilenaufrufe), von Parameterund von Logdateien umfassen.
Die Administrationsanleitung SOLLTE Screenshots und Kommandozeilenaufrufe sowie Beispiele beinhalten.
Entwicklerdokumentation
Die Entwicklerdokumentation dient der Erleichterung des Einstiegs neuer Entwickler
in das Projekt sowie der Unterst¨
utzung der Weiterentwicklung und sollte an erfahrene
Entwickler (wenn auch unerfahren mit der konkreten Softwarekomponente) gerichtet
sein.
Die Entwicklerdokumentation MUSS die folgenden Punkte umfassen:
• Beschreibung der Struktur des Quellcodes
• Liste der verwendeten Bibliotheken
• Liste der verwendeten Entwicklungswerkzeuge und deren Konfiguration
• Anleitung zur Integration des Quellcodes in eine Entwicklungsumgebung
• Anleitung zum Kompilieren
• Beschreibung der Verantwortlichkeiten, Aufgaben, Funktion und Benutzung von
Programmelementen (z.B. Klassen, Methoden etc.)
Unittests
Unittests SOLLTEN im Rahmen des Quellcode ver¨offentlicht und in der Entwicklerdokumentation betrachtet werden.
Sie SOLLTEN nicht Bestandteil der Softwarever¨offentlichung in Bin¨arform sein und bei
der Installation, wie sie in der Administrationsanleitung beschrieben ist, nicht ben¨
otigt
werden.
Lizenzen von Dritten
Die Lizenzen aller verwendeten Bibliotheken und Software von Drittanbietern SOLLTEN
in geeigneter Form in einem Release enthalten sein.
1.3.2 Portal-Releases
Hier wird beschrieben, wie die Anforderungen aus Abschnitt 1.3.1 f¨
ur das C3Grid-Portal
umgesetzt werden.
10
README
Ein README wird beigef¨
ugt. Die Datei dient als kurze Zusammenfassung des Pakets
und verweist auf die ausf¨
uhrlicheren Beschreibungen / Anleitungen.
Changelog
Das Changelog muss auf der Portalseite selbst verf¨
ugbar sein und sollte der Software bei
Ver¨offentlichung als Text-Datei beiliegen.
Softwarelizenz
Eine passende Lizenz muss noch ausgew¨
ahlt werden.
Software in Bin¨
arform
Die Software wird in der zuletzt als lauff¨ahig bekannten Version in Bin¨arform (konkret:
als WAR-file f¨
ur das Deployment im Liferay-Portalframework) ausgeliefert.
Quellcode
Der Quellcode wird im AForge
abgelegt.
http://aforge.awi.de/svn/c3grid/portal/c3grid
Bedienungsanleitung f¨
ur Nutzer
Eine Bedienungsanleitung muss auf der Portalseite selbst bereitstehen, wie auch im SVN
abgelegt sein.
Administrationsanleitung f¨
ur Betreiber
Eine Bedienungsanleitung muss im SVN abgelegt sein.
Entwicklerdokumentation
Eine Bedienungsanleitung muss im SVN abgelegt sein.
Unittests
Unittests wesentlicher Komponenten sollten Bestandteil sein.
Lizenzen von Dritten
Software und Bibliothenken Dritter m¨
ussen samt ihrer Lizenzen zur Verf¨
ugung stehen
bzw. in der Dokumentation Erw¨
ahnung finden. Haben diese Lizenzen keine weitergehenden Anforderungen an die Erw¨
ahnung bzw. die Weitergabe, gen¨
ugt eine Auflistung in
der README.
11
1.3.3 WSS-Releases
Dieser Abschnitt definiert, wie die Anforderungen aus Abschnitt 1.3.1 f¨
ur die SchedulingKomponenten des C3Grid, den Workflow Scheduling Service (WSS), umgesetzt werden.
README
Die Einstiegsseite von
http://forge.it.irf.tu-dortmund.de/projects/c3inad/
dient als README. Von dort gelangt man, wenn es im Text nicht explizit erw¨
ahnt
wird, u
u auf der linken Seite zu weiteren Artefakten.
¨ber das Men¨
Wird die Software und Dokumentation lokal kompiliert (mvn package site:stage),
befindet sich die Einstiegsseite unter ./target/site/index.html.
Zus¨
atzlich gibt es unter ./src/documentation/README eine kurze README-Datei.
Diese wird beim ver¨
offentlichen der Sourcen im AForge im Hauptverzeichnis platziert.
Changelog
¨
Die funktionalen Anderungen
am Quellcode von einem Release zum n¨achsten werden auf
http://forge.it.irf.tu-dortmund.de/projects/c3inad/changelog aufgelistet.
Zudem gibt es eine f¨
ur alle Projektpartner zug¨angliche Wiki-Seite unter https://
redmine.dkrz.de/collaboration/projects/c3grid/wiki/WSS, auf der alle Features
des WSS, die bei einem Release neu hinzugekommen sind, ver¨offentlicht werden.
Softwarelizenz
Die Lizenz des WSS ist unter http://forge.it.irf.tu-dortmund.de/projects/c3
inad/license.html zu finden.
Software in Bin¨
arform
Der WSS ist in Java geschrieben und besteht aus mehreren Modulen. Jedes Modul wird
als JAR-Datei ausgeliefert. Alle Module des WSS werden als komprimiertes TarballArchiv (tar.bz2) unter http://forge.it.irf.tu-dortmund.de/projects/c3inad/w
ss-a.b.c.tar.bz2 (a.b.c muss durch die Versionsnummer ersetzt werden) zum Download angeboten.
Alle Module des WSS sind dar¨
uber hinaus im Nexus-Repository http://forge.
it.irf.tu-dortmund.de/nexus abgelegt und k¨onnen in Build-Management-Tools wie
Maven verwendet werden, um die Module des WSS als Abh¨angigkeiten zu definieren und
¨
durch das Tool aufzul¨
osen. Uber
ein Webinterface kann der Quellcode, der Javadoc und
die Bin¨
arform, jeweils als JAR-Datei gepackt, herunter geladen werden.
Quellcode
Der Quellcode des WSS wird im AForge
uling ver¨
offentlicht.
12
http://aforge.awi.de/svn/c3grid/sched
Zus¨atzlich ist der Quellcode jedes Moduls als JAR-Datei gepackt im Nexus-Repository
http://forge.it.irf.tu-dortmund.de/nexus verf¨
ugbar.
Bedienungsanleitung f¨
ur Nutzer
Der Nutzer“ des WSS ist das Portal, welches Workflows beim WSS einreicht. Um die
”
Kommunikation mit dem WSS zu erm¨oglichen, wird eine Client-Bibliothek zur Verf¨
ugung gestellt. Die Integration der Client-Bibliothek wird in
http://forge.it.i
rf.tu-dortmund.de/projects/c3inad/javaclient.html beschrieben. Die Client-Bibliothek und ihre Benutzung ist als Javadoc im Code selbst dokumentiert. Zus¨atzlich
ist sie unter http://forge.it.irf.tu-dortmund.de/projects/c3inad/c3inad.ui
/c3inad.ui.jaxrs/c3inad.ui.jaxrs.client/javadoc/index.html einsehbar.
Administrationsanleitung f¨
ur Betreiber
Die Installation, Konfiguration und Administration des WSS ist unter http://forg
e.it.irf.tu-dortmund.de/projects/c3inad/administration.html beschrieben.
Entwicklerdokumentation
Die Strukturierung des WSS ist unter http://forge.it.irf.tu-dortmund.de/pro
jects/c3inad/modules.html beschrieben.
Wie das Softwareprojekt in die Entwicklungsumgebung Eclipse integriert wird kann
unter http://forge.it.irf.tu-dortmund.de/projects/c3inad/eclipse_integra
tion.html nachgelesen werden. Dort wird ebenfalls auf die Verwendung des BuildManagement-Tools Maven eingegangen. Die Konfiguration des Build-Prozesses erfolgt,
wie bei Maven u
¨berlich, durch die pom.xml-Dateien in den jeweiligen Modulordnern.
Da der WSS ein Maven-Projekt ist, werden die Abh¨angigkeiten (Bibliotheken etc.)
jedes Moduls in der zugeh¨
origen pom.xml definiert.
Die Dokumentation der Programmelemente erfolgt mittels Javadoc direkt im Quellcode.
Unittests
Die Module des WSS werden mit JUnit2 getestet. Die Tests sind nicht Bestandteil der
Softwarever¨offentlichung in Bin¨
arform. Sie sind in allen Ver¨offentlichungen des Quellcode
enthalten.
Lizenzen von Dritten
Die Lizenzen von Drittanbietern werden auf der Projekthomepage des WSS bei den
Abh¨angigkeiten der Module genannt.
2
http://www.junit.org/
13
1.3.4 DMS-Releases
In diesem Abschnitt wird beschrieben, wie die Anforderungen aus Abschnitt 1.3.1 f¨
ur
die Datenmanagement-Komponente des C3Grid, das GNDMS, umgesetzt werden.
README
Die Einstiegsseite des GNDMS http://gndms.zib.de/ dient als README. Von dort
gelangt man, wenn es im Text nicht explizit erw¨ahnt wird, u
u auf der rechten
¨ber das Men¨
Seite zu weiteren Artefakten.
Wird die Software und Dokumentation lokal kompiliert, gibt es direkt im Hauptverzeichnis eine kurze README-Datei.
Changelog
¨
Die funktionalen Anderungen
am Quellcode von einem Release zum n¨achsten werden in
der CHANGELOG-Datei im Hauptverzeichnis aufgef¨
uhrt.
Softwarelizenz
Die Lizenz des GNDMS ist unter
http://gndms.zib.de/license/ zu finden.
Software in Bin¨
arform
Das GNDMS ist in Java geschrieben und besteht aus mehreren Modulen. Jedes Modul wird als JAR-Datei ausgeliefert. Alle Module des GNDMS werden als komprimiertes Tarball-Archiv (tgz) unter https://github.com/zibhub/GNDMS/downloads zum
Download angeboten.
Quellcode
Der Quellcode des GNDMS wird unter
fentlicht.
https://github.com/zibhub/GNDMS ver¨
of-
Bedienungsanleitung f¨
ur Nutzer
Die Nutzer“ des GNDMS sind das WSS sowie die Computeprovider. F¨
ur diese wer”
den verschiedene Clients bereit gestellt, deren Benutzung als Javadoc im Code selbst
dokumentiert ist. Zus¨
atzlich ist sie unter http://gndms.zib.de/VERSION/develope
r-guide/doxygen-client/html/index.html einsehbar, wobei VERSION durch die aktuelle GNDMS-Version ersetzt werden muss. Zus¨atzlich ist unter http://gndms.zib.
de/VERSION/developer-guide/doxygen/html/index.html die gesamte Javadoc-Dokumentation des GNDMS zu finden.
In der lokalen Installation werden im Ordner taskflows wichtige Clients bereitgestellt,
die auch als Prototypen f¨
ur die weitere Client-Entwicklung dienen.
14
Administrationsanleitung f¨
ur Betreiber
Die Installation, Konfiguration und Administration des GNDMS ist unter den Links
Installation Guide und Monitor Shell Guide beschrieben.
Entwicklerdokumentation
Die Strukturierung des GNDMS ist unter dem Link Architecture Primer beschrieben.
Wie das Softwareprojekt in die Entwicklungsumgebungen IntelliJ Idea oder Eclipse
integriert werden kann, wird unter dem Link Developer Guide beschrieben.
Die Dokumentation der Programmelemente erfolgt mittels Javadoc direkt im Quellcode.
Unittests
Die Module des GNDMS werden mit JUnit getestet. Die Tests sind nicht Bestandteil der
Softwarever¨offentlichung in Bin¨
arform. Sie sind in allen Ver¨offentlichungen des Quellcode
enthalten.
Lizenzen von Dritten
Die Lizenzen von Drittanbietern werden auf der Projekthomepage des GNDMS bei den
Abh¨angigkeiten der Module genannt.
1.3.5 Vold/ADiS-Releases
In diesem Abschnitt wird beschrieben, wie die Anforderungen aus Abschnitt 1.3.1 f¨
ur
die Volatile Directory Service (VolD) des C3Grid umgesetzt werden.
README
Die Einstiegsseite des VolD http://zibhub.github.com/VolD dient als README.
Von dort gelangt man, wenn es im Text nicht explizit erw¨ahnt wird, u
u auf
¨ber das Men¨
der rechten Seite zu weiteren Artefakten.
Wird die Software und Dokumentation lokal kompiliert, gibt es direkt im Hauptverzeichnis eine kurze README-Datei.
Changelog
¨
Die funktionalen Anderungen
am Quellcode von einem Release zum n¨achsten werden in
der CHANGELOG-Datei im Hauptverzeichnis aufgef¨
uhrt.
Softwarelizenz
Die Lizenz des VolD ist unter
http://zibhub.github.com/VolD/license/ zu finden.
15
Software in Bin¨
arform
VolD ist in Java geschrieben und besteht aus mehreren Modulen. Jedes Modul wird als
JAR-Datei ausgeliefert. Alle Module des VolD werden als komprimiertes Tarball-Archiv
(tgz) unter https://github.com/zibhub/VolD/downloads zum Download angeboten.
Quellcode
Der Quellcode des VolD wird unter
https://github.com/zibhub/VolD ver¨offentlicht.
Bedienungsanleitung f¨
ur Nutzer
F¨
ur die Nutzung des VolD in C3Grid wird unter https://github.com/zibhub/ADiS
der Client ADiS bereitgestellt, der das Schema definiert sowie Getter und Setter f¨
ur alle
benutzten Keys bereit stellt. Die Dokumentation f¨
ur ADiS ist als Javadoc im Code selbst
dokumentiert sowie unter http://zibhub.github.com/ADiS/ verf¨
ugbar.
Unter dem Link API Reference ist die gesamte Javadoc-Dokumentation des VolD zu
finden.
Administrationsanleitung f¨
ur Betreiber
Die Installation, Konfiguration und Administration des VolD ist unter den Links Configuration und REST/HTTP Interface beschrieben.
Entwicklerdokumentation
Die Strukturierung des VolD ist unter dem Link Architecture beschrieben.
Die Dokumentation der Programmelemente erfolgt mittels Javadoc direkt im Quellcode.
Unittests
Die Module des VolD werden mit JUnit getestet. Die Tests sind nicht Bestandteil der
Softwarever¨
offentlichung in Bin¨arform. Sie sind in allen Ver¨offentlichungen des Quellcode
enthalten.
Lizenzen von Dritten
Die Lizenzen von Drittanbietern werden auf der Projekthomepage des VolD bei den
Abh¨
angigkeiten der Module genannt.
16
2 Reviewing von Dokumentation
Abschnitt 1.3 definiert drei Arten von Dokumention als Teil eines Releases. Um die Qualit¨at der Dokumente sicherzustellen wird f¨
ur C3Grid ein Reviewingprozess vorgeschlagen.
Bevor die Dokumente ver¨
offentlicht werden, soll jedes von einem Partner, der nicht an
der Erstellung der Dokumentation beteiligt war, begutachtet werden. Die Verbesserungsvorschl¨age werden von den Autoren gepr¨
uft und sollen vor der Ver¨offentlichung in die
Dokumentation einfließen. Ein st¨
andiger Austausch zwischen den Gutachtern und den
Autoren w¨arend des Prozesses ist einem schlichten Schreiben eines Gutachtens vorzuziehen.
Um praxisnahe Vorschl¨
age f¨
ur die Verbesserung der Dokumentation zu erhalten, sollten die begutachtenden Partner derart gew¨ahlt werden, dass sie die Dokumentation f¨
ur
ihre Arbeiten ben¨
otigen. Z.B. sollte ein Projektpartner, der die Clientsoftware eines Services benutzt, die Bedienungsanleitung begutachten.
Weiter ist bei der Auswahl der begutachtenden Partner darauf zu achten, dass die
t¨
agliche Arbeit m¨
oglichst nahe an dem Thema der zu begutachtenden Dokumentation
liegt. Z.B. sollte die Entwicklerdokumentation f¨
ur einen in Java entwickelten Service von
einen Partner begutachtet werden, der ebenfalls einen Service in Java entwickelt.
Bei der Begutachtung sollten die folgenden Punkte beachtet werden:
• Vollst¨andigkeit
• Verst¨andlichkeit
• Nachvollziebarkeit
¨
• Ubersichtlichkeit
Insbesondere bei Bedienungs- und Administrationsanleitungen sollten die Anleitungen
direkt ausprobiert werden. Das bedeutet, dass ein Client/Dienst nach Anleitung installiert und u
uhrt werden.
¨bliche Administrationsschritte ausgef¨
Tabelle 2.1 zeigt eine m¨
ogliche Zuordnung von Gutachtern zu Dokumenten, wie sie im
F¨orderzeitraum umgesetzt werden k¨
onnte.
17
Tabelle 2.1: Zuordnung der Partner zu den zu begutachtenden Dokumenten der
Komponenten.
Portal
WSS
DMS
VolD/ADis
18
Bedienungsanleitung
Administrationsanleitung
Entwicklerdokumentation
FUB/IGMK
AWI
TuDo
TuDo
RRZK
RRZK
DKRZ
DKRZ
ZIB
ZIB
TuDo
TuDo
3 Aufnahme und Vermittlung von Nutzer-/Entwicklerfeedback
Entwickler- und Nutzerfeedback beschreibt im Projektverlauf den R¨
uckfluss von Informationen bez¨
uglich neuer Anforderungen, Funktions¨anderungen oder festgestellter Fehler
an die technischen Partner in C3Grid. Dazu wird den Anwendern ein zentraler Anlaufpunkt in Form eines Redmine-Systems zur Verf¨
ugung gestellt. Darin k¨onnen Tickets bez¨
uglich entsprechender Fehler und Anforderungen angelegt werden und, falls m¨oglich, einer Komponente, einem Entwicklerteam oder einem bestimmten Thema zugeordnet werden. Der Weiterleitungsprozess der Tickets in die lokale Managementstruktur der Ent¨
wicklungsteams erfolgt dann u
der Tickets des Redmine-Systems
¨ber aktive Ubernahme
in lokale, feiner granulierte Tickets mit Zuordnungen innerhalb der Entwicklergruppe.
Dieser Prozess muss jedoch manuell durch die jeweilige Benutzergruppe durchgef¨
uhrt
werden. Zur Unterst¨
utzung des manuellen Prozesses kann jede Benutzergruppe themenbezogen u
¨ber die Eintragung eines neuen Tickets in das zentrale System benachrichtigt
werden (Redmine stellt einen entsprechenden Benachrichtigungsmechanismus zur Verf¨
ugung).
Anwender
Globales Ticketing System
(Redmine)
T
T
T
stellt Ticket in
globales System ein
Ticketzuordnung
manuell durch DT3
Überführung in
lokale Tickets
T
Lokales Ticketing
System 1
T T
T
LTS2
T T
T
LTS3
Rückkopplung nach
Fertigstellung der
lokalen Tickets
Abbildung 3.1: Vorgehen der Ticketdelegation von der globalen zur lokalen Ebene der
Development Teams (DT).
Nach der Benachrichtigung u
¨ber ein entsprechendes Ticket muss die lokale Gruppe
entscheiden, ob das Ticket eine vom Team betreute Komponente betrifft. Ist dies der
Fall, m¨
ussen im lokalen Ticketingsystem entsprechende Eintragungen und Zuweisun-
19
gen vorgenommen werden, die eine interne Bearbeitung unterst¨
utzen. Zus¨atzlich m¨
ussen
ausreichende Abh¨
angigkeitsbeschreibungen zum zentralen Redmine-Ticket hinzugef¨
ugt
werden, um dieses in der Folge einer abschließenden lokalen Bearbeitung des Tickets
auch auf globaler Ebene wieder schließen zu k¨onnen. Abbildung 3.1 stellt diesen Delegationsprozess f¨
ur globale Tickets und die entsprechende R¨
uckkopplung dar.
Der vorgeschlagene Prozess erm¨oglicht ein weitgehend entkoppeltes Management von
Ticketanfragen und zugleich eine einzelne Anlaufstelle f¨
ur den Nutzer.
20
4 Lokale Umsetzung
Unter lokalem Softwaremanagement werden diejenigen Prozesse zusammengefasst, die
f¨
ur die technischen Arbeiten eines Partners oder f¨
ur die Entwicklung einer einzelnen Softwarekomponente (durchaus unter Beteiligung mehrerer Partner) einen festen SoftwareLifecycle festlegen. Dies umfasst schwerpunktm¨aßig Release- und Testprozesse. Grunds¨atzlich werden diese Prozesse im C3Grid pro entwickelter Komponente, bzw. pro Partnerverbund (der mit der Entwicklung einer Komponente betraut ist) festgelegt. Die
Partner sind in der Wahl ihrer Methoden (Konzepte und Technologien) weitgehend frei,
haben jedoch folgende Voraussetzungen sicherzustellen:
Releasezyklus: Es soll eine Regelung geben, die funktionale und nicht-funktionale Charakteristika einer Softwarekomponente u
¨ber die Zeit sicherstellt. Dies bedeutet,
dass es grundlegende Festlegungen bez¨
uglich Funktionsumfang und Qualit¨at f¨
ur die
regelm¨aßige Zurverf¨
ugungstellung von Versionen einer Softwarekomponente gibt.
Es m¨
ussen also feste zeitliche Abst¨ande definiert werden, in denen ein ebenfalls
festgelegter Funktionsumfang fehlerfrei (getestet) dem Gesamtprojekt zur Verf¨
ugung gestellt wird. Die Festlegung eines solchen Zeitraums kann individuell f¨
ur jede
Komponente erfolgen. Die Festlegung des Funktionsumfanges f¨
ur ein Release soll
sich zumindest w¨
ahrend der Laufzeit des Projektes nach den Vorgaben des Projektplans und ¨
außeren Einfl¨
ussen (siehe Tests, Bugtracking und Ticketing) richten.
Zus¨atzlich zum festgelegten Releaseplan f¨
ur eine Softwarekomponente k¨onnen f¨
ur
lokale Entwicklungen Snapshots angeboten werden, die keine offiziellen Releases
sind und auch eine entsprechende Qualit¨at und einen solchen Status nicht zusichern. Sie k¨
onnen genutzt werden, um Weiterentwicklungen, die erst f¨
ur sp¨atere
Releases vorgesehen sind, bereits zu Testzwecken zur Verf¨
ugung zu stellen oder den
aktuellen Status der Entwicklung zu verfolgen. Eine Bereitstellung von Snapshots
oder ”nightly builds” steht jedem lokalen Entwicklungsteam frei.
Tests: Software, die dem Gesamtprojekt (also anderen Arbeitsgruppen) im Rahmen eines Releases zur Verf¨
ugung gestellt wird, muss interne Komponententests und Integrationstests erfolgreich bestanden haben. Damit soll eine grundlegende Softwarequalit¨at sichergestellt werden. Die Testverfahren und eingesetzten Technologien
obliegen wiederum der lokalen Arbeitsgruppe. Es muss jedoch sichergestellt sein,
dass die formulierten Anforderungen an ein Release jeweils von der ver¨offentlichten
Version erf¨
ullt werden. Abstriche von der geforderten Funktionalit¨at sind bekannt
zu geben.
Dokumentation: Der Status eines Releases ist bei seiner Ver¨offentlichung zu dokumentieren. Dabei soll angegeben werden:
• Wie die Komponente zu benutzen oder zu installieren ist.
21
¨
• Welche Anderungen
es zur vorherigen Version gibt.
• Ob alle (funktionalen) Anforderungen an das Release erf¨
ullt wurden. Im Falle
der Nichterf¨
ullung ist dies darzustellen.
• Ob es bekannte Einschr¨ankungen gibt, die aber das Release nicht grunds¨
atzlich behindern.
Versionierung und internes Ticketing: Grunds¨atzlich sollte eine Gruppe Werkzeuge zur
Unterst¨
utzung des internen Entwicklungsprozesses einsetzen. Hier ist einerseits eine
Versionierung des Quellcodes (Beispiele: SVN, GIT), andererseits eine Kommunikationsund Managementplattform f¨
ur Entwickler vorzusehen. Ein Ticketingsystem kann
dazu genutzt werden Probleme mit der Software festzuhalten, in ihrer Schwere
zu dokumentieren und Aufgaben innerhalb des Entwicklerteams zuzuordnen (Beispiele: Redmine, Trac). Eine konkrete Umsetzung wird nicht projekt¨
ubergreifend
vorgegeben.
Beispielumsetzung Workflowmanagement: In Dortmund besteht das Entwicklerteam
aus 2-4 Mitarbeitern. Die Softwareversionierung wird u
uhrt. Das sich
¨ber SVN durchgef¨
damit integrierende Ticketingsystem Trac erm¨oglicht die Erfassung von Problemen, die
w¨
ahrend der Softwareentwicklung oder im laufenden Betrieb der produktiven Software
auffallen. Entsprechend der Priorit¨at und Schwere der Fehler wird eine Klassifizierung
der Eintr¨
age vorgenommen und diese dem zust¨andigen Entwickler zugewiesen. Zudem
ist jeder Entwickler verpflichtet im projekt¨
ubergreifenden Redmine-Ticketingsystem von
Nutzern und anderen Entwicklerteams er¨offnete Tickets in das lokale System zu u
¨bertragen, zu kommentieren und zuzuweisen (siehe projekt¨
ubergreifende Umsetzung).
22
5 Betriebsumgebungen f¨
ur Produktion und Test
F¨
ur den produktiven Betrieb und die Entwicklungsarbeiten m¨
ussen im C3Grid zwei
unabh¨angige Systeme zur Verf¨
ugung stehen. Das Produktivsystem betreibt jeweils die
stabile Version der C3Grid-Infrastruktur, die dem zuletzt fertiggestellten Projektmeilenstein entspricht. Sie muss zuvor in der Testumgebung hinreichend viele Tests durchlaufen
haben, um von dort in die Produktivumgebung migriert zu werden (Projektrelease). F¨
ur
die Produktivumgebung gilt, dass sie regelm¨aßg gewartet wird, um unvorhergesehene
Ausf¨alle (etwa durch das Ablaufen eines Zertifikats) m¨oglichst ausgeschlossen werden
k¨onnen. Da die produktive Umgebung von verschiedenen Partnern dezentral betrieben
wird, sollten die Wartungszeitr¨
aume weitgehend synchronisiert und rechtzeitig angek¨
undigt werden. F¨
ur die Ank¨
undigung einer Wartung hat sich bereits im C3Grid der ersten
F¨orderphase ein Prozess aus folgenden Schritten entwickelt, der u
¨bernommen werden
kann:
1. Ank¨
undigung der Wartung mit dem voraussichtlichen Wartungszeitraum durch
den Betreiber des Dienstes oder der Ressource. Die Ank¨
undigung soll 3 Tage vor
der Wartung an das Konsortium geschickt werden, aber auch den Nutzern u
¨ber
entsprechende Kan¨
ale (Mailinglisten usw.) bekannt gemacht werden.
2. Erinnerung an die Wartung kurz vor deren Beginn (¨
uber alle Kan¨ale der Ank¨
undigung).
3. Durchf¨
uhrung der Wartung zum vorgesehenen Zeitpunkt. Im Falle einer Verz¨ogerung soll dies dem Konsortium und den Nutzern umgehend mitgeteilt werden.
4. Mitteilung u
¨ber den Abschluss der Wartung (ebenfalls u
¨ber alle Kan¨ale der Ank¨
undigung).
Die Testumgebung ist die zur Produktivumgebung parallel betriebene Umgebung in
der die von den Entwicklergruppen fertiggestellten und bereits lokal getesteten Komponenten miteinander integriert werden. Diese Integration sollte sich nach dem Releasezyklus richten und zum Projektmeilenstein mit einer konsistenten Version schließen, die
anschließend in den Produktivbetrieb u
¨bernommen werden kann.
Insgesamt m¨
ussen f¨
ur die Testumgebung einzelne Testf¨alle basierend auf den Anforderungen f¨
ur den Projektmeilenstein definiert sein. Diese Testf¨alle m¨
ussen in Integrationstests und Systemtests/Nutzungstests umgewandelt werden, die idealerweise automatisch
durchgef¨
uhrt werden k¨
onnen.1 Diese definieren die Grundlage f¨
ur eine ”Zertifizierung”
der getesteten Komponenten f¨
ur eine Integration in den Produktionsbetrieb von C3GridINAD.
1
Dazu k¨
onnen Continuous Integration Tools (z.B. Hudson/Jenkins) und Automatisierungstools f¨
ur
Nutzungstests (z.B. Silenium) genutzt werden.
23
Die Testumgebung soll parallel zu der Produktivumgebung durch die gleichen Partner
betrieben werden. Da die betreibenden Partner gew¨ohnlicherweise auch die diese Komponente oder diesen Dienst entwickelnden und pflegenden Partner sind, sollte durch
den parallelen Betrieb kaum zus¨atzlicher Aufwand entstehen. Bisher betreiben die meisten Partner sowieso bereits eine Testinstanz der Dienste und Komponenten. Die klare
Trennung von Produktiv- und Testsystemen muss daher nur im Konsortium festgelegt
werden. F¨
ur diese Festlegung und die Dokumentation der Test- und Zertifizierungsprozesse und Anforderungen wird ein zus¨atzlicher Leitfaden auf Grundlage eines erstellten
Anforderungsdokumentes vorgeschlagen.
24
Literaturverzeichnis
[1] S. Bradner.
Key words for use in RFCs to indicate requirement levels.
http://www.ietf.org/rfc/rfc2119.txt, 1997. Zugriff am 27. August 2012.
25
Document
Kategorie
Internet
Seitenansichten
4
Dateigröße
839 KB
Tags
1/--Seiten
melden