ZIDline 18

The Making of TISS

Ruby on Rails

TUphone Telefonie morgen

Partner ACOnet

Bericht ZID-Day 08

Nr. 18 / Juli 2008

ISSN 1605-475X

ZEITSCHRIFT DES ZENTRALEN INFORMATIKDIENSTES DER TU WIEN

Seite 2 Juli 2008 ZIDline 18

Inhalt

The Making of TISS: Juni 2008 . . . . . . . . . . . . . . . . . . . 3

Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

TUphone die Zukunft der Telefonie an der TU Wien . . . . . . 12

ZID-Day 08:eine Nachlese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Gemeinsame Bibliotheks-Software Alephan der TU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Mit zwei Klicks zum neuen TUWEL-Kurs . . . . . . . . . 24

ACOnet, ein langjhriger, verlsslicherPartner der TU Wien . . . . . . . . . . . . . . . . . . . . . . . 27

CAE auf den Applikationsservern . . . . . . . . . . . . . . . . 30

OpenFOAMDie Open Source CFD-Toolbox . . . . . . . . . . . . . . . 31

IT-Webkurse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Ausknfte, Strungsmeldungen:Service Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Editorial

Im vergangenen halben Jahr sind neue spannendeThemen entstanden. Zwei groe Projekte knnen wir Ih-nen in dieser ZIDline vorstellen. Um ganz aktuell zusein, erscheint diese Ausgabe ein paar Wochen spter alssonst und ist eine Juli-Ausgabe geworden.

TISS ist der Name fr das hausinterne Entwicklungs-projekt der TU Wien zur Bereitstellung moderner Infor-mations- und Kommunikationssysteme fr die Admi-nistration von Lehre, Forschung und betrieblichenRessourcen. Die technische Basis ist Ruby on Rails. Inweiterer Folge wird die ZIDline regelmig Fachbeitrgezu diesem Projekt verffentlichen.

Der ZID betreibt auch die Telefonanlage der TUWien. Aufgrund ihres Alters wird die bestehende Ne-benstellenanlage in den nchsten zwei Jahren durch eineVoice over IP -Lsung ersetzt. Aus diesem Anlass gebenwir einen berblick ber die Telefonie an der TU Wienund stellen die geplanten Features vor.

Am 2. April haben wir mit groem Erfolg den erstenZID-Day veranstaltet. Lesen Sie einen ausfhrlichen Be-richt in diesem Heft.

Die Universittsbibliothek informiert ber die Mg-lichkeit fr Institute, die Bibliotheks-Software Aleph zurVerwaltung einer Institutsbibliothek einzusetzen.

Wie Sie mit zwei Klicks einen neuen TUWEL-Kursanlegen, erfahren Sie ab Seite 24.

ACOnet ist seit Jahren ein verlsslicher Partner derTU Wien. Zusammen mit dem ZID der Universitt Wienwird ein berblick gegeben.

OpenFoam ist eine Open Source CFD-Toolbox, frdie ein Teil des IBM Power5 Cluster unter Linux konfi-guriert wurde. Eine tabellarische bersicht stellt zusam-men, auf welchen zentralen Servern zurzeit welche CAE-Programme zur Verfgung stehen.

Schlielich sei auf das umfangreiche Angebot und dieVorteile der IT-Webkurse hingewiesen, die am ZID nicht nur fr die TU angeboten werden.

An dieser Stelle mchte ich mich bei allen recht herz-lich bedanken, die zum Gelingen dieser Zeitschrift beige-tragen haben.

Irmgard Husinsky

Impressum / Offenlegung gem 25 Mediengesetz:

Herausgeber, Medieninhaber:Zentraler Informatikdienstder Technischen Universitt WienISSN 1605-475X

Grundlegende Richtung: Mitteilungen des ZentralenInformatikdienstes der Technischen Universitt Wien

Redaktion: Irmgard Husinsky

Adresse: Technische Universitt Wien,Wiedner Hauptstrae 8-10, A-1040 WienTel.: (01) 58801-42014, 42001Fax: (01) 58801-42099E-Mail: [email protected]: http://www.zid.tuwien.ac.at/zidline/

Erstellt mit Corel VenturaDruck: HTU Wirtschaftsbetriebe GmbH,1040 Wien, Tel.: (01) 5863316

www.zid.tuwien.ac.at/zidline/

The Making of TISS:Juni 2008Wolfgang Kleinert, Thomas Grechenig, Thomas Kltringer,Mario Bernhart, Andreas Knarek, Franz Schnbauer

Wenn man Dachboden und Keller entrmpelt, dann fliegt so manches raus und einiges bekommtendlich seinen Ehrenplatz. Man wird Spannendes erleben dabei und nachher fhlt man sichwohler. Die TU Wien trennt sich von teilweise 40 Jahre alter Inhouse-Software.

Vorgeschichte und fachlicher Hintergrund

An der TU Wien erleben wir zurzeit hautnah eine Ent-wicklung mit, die bereits die letzten 15 Jahre der moder-nen betrieblichen Informationstechnik geprgt hat. Dabeisteigt der Bedarf aller Instanzen und Entscheidungstrger,den Grad der Interaktion und Integration und deren Ge-schwindigkeit im operativen Umfeld zu erhhen. DiesemDruck Folge leistend wurden und werden dabei weltweit

alte gute funktionierende Systeme auf neue Plattformenmigriert und laufend erweitert,

neue Schnittstellen zwischen den ber die Jahre oft auto-nom gewachsenen Einzelsystemen etabliert,

anlassbezogene Neuentwicklungen fr den akuten Be-darf gefordert,

neue Technologien systematisch angewendet und einge-pflegt.

Die kumulierten Effekte dieser sachlich zwingendenVorgehensweise sind im betrieblichen Umfeld seit eini-gen Jahren als Enterprise Application Integration (EAI)bekannt. EAI versucht dabei, das sattsam bekannte Pro-blem, dass die unterschiedlichen, historisch gewachsenenApplikationen und Schnittstellen sich jeder kontrollierten,planbaren und kostenmig verlsslich einschtzbarenWeiterentwicklung, Wartung oder Neueinfhrung aktuel-ler Technologien entziehen, durch einen informations-technisch strategischen Gesamtansatz zu lsen.

Fr die TU Wien lsst sich diese natrliche Enterprise-IT-Entwicklung wie folgt zusammenfassen:

Seit 1968 wird das Verwaltungssystem TUWIS betrie-ben und weiterentwickelt. Frhen COBOL-Entwicklun-gen wurden moderne Datenbanken hinzugefgt. MehrereZusatzentwicklungen wurden im Altsystem bzw. in meh-reren Neusystemen realisiert. Diese Arbeiten wurden biszum Inkrafttreten des UG2002 von der ADV-Abteilungauch fr den so genannten TUWIS-Verbund, dem ne-ben der TU Wien auch die Universitt fr Bodenkultur

Wien, die Veterinrmedizinische Universitt und dieUniversitt fr Musik und darstellende Kunst Wien ange-hrten, durchgefhrt.

TUWIS war eine klassische COBOL-Applikation, wo-bei die Daten in den heute schon legendren Common-Blcken gespeichert waren. In den 80er-Jahren wurde dieAnwendung auf Oracle umgestellt, d. h. die einzelnenCommon-Blcke wurden zu Oracle-Tabellen und dieCOBOL-Programme wurden einerseits auf Datenbankzu-griffe (mit so genannten Datenkapseln als Bausteinen,die Zugriffskonflikte ausschlieen sollten) umgestellt,bzw. teilweise durch Forms-Applikationen ersetzt. Frein umfassendes, integriertes Datenbankdesign und eingesamtes Redesign bestand nie ein akuter Bedarf, berJahrzehnte waren die Fehlerausbesserungen und die Im-plementierung neuer Features in der alten Technologiesowie die Etablierung aktueller Plattformen ein ausrei-chendes und Kosten sparendes Verfahren.

Die klassischen TUWIS-Applikationen standen zuerstausschlielich den Fachabteilungen (vor allem Personal-und Studienabteilung) zur Verfgung. Ende der 90er-Jah-re wurde mit Sides4mi eine Weblsung fr Studierende(Lehrveranstaltungsmanagement, -abhaltung und -anmel-dung, aber keine Prfungsanmeldung) durch Externe(unikat) als Web-Zusatz fr TUWIS realisiert. 2003 wur-de die mit ZOPE2 fr die Universitt fr BodenkulturWien realisierte LVA-Verwaltung BLIS (Boku-Lehr-In-formations-System) fr die TU Wien adaptiert. Das Pro-dukt wurde TUWIS++ genannt. Die dabei angedachteRe-Implementierung in einem modernen Programmierpa-radigma wurde damals nicht realisiert. Mit Anfang 2004wurde vom ZID darauf gedrngt, den alten COBOL-Code so rasch wie mglich zu ersetzen und das Daten-modell zu verbessern, damit mittelfristig die Altlasten be-seitigt werden knnen.

Von der Abteilung Standardsoftware des ZID wirdseit 1993 unabhngig von TUWIS ein Object Application

ZIDline 18 Juli 2008 Seite 3

Server auf Basis von GemStone/S betrieben. Ausgangs-punkt war dabei die Verwaltung der Campussoftwareli-zenzen (Zugriffsvergabe, Abrechnung). Damit war z. B.die Online-Bestellung von Campussoftware mglich ge-worden. Durch eine Reihe von Erweiterungen wurde derImport von Personal- und Studentendaten aus TUWIS in-tegriert. Bei diesem Vorgang werden zusammengehrigePersonal- und Studenteneintrge konsolidiert, um die er-wnschte einheitliche Sicht zu erhalten (ZID-PDB, Per-sonendatenbank). Hier wird auch eine Identifikations-nummer (object id, OID) vergeben. Die Daten werdendann anderen Benutzern innerhalb und auerhalb desZID zur Verfgung gestellt. Wichtige Anwendungen sinddie White Pages und das Mailrouting, sowie die zentraleAuthentifizierung mit dem TU-Passwort. In der Vergan-genheit wurde zwar immer wieder ber die notwendigeZusammenfhrung von TUWIS und der ZID-PDB ge-sprochen, aber die Realisierung nie wirklich in Angriffgenommen.

Nicht nur offizielle Statuserhebungen sondern auchder Vergleich mit dem wirtschaftlichen betrieblichenUmfeld haben deutlich gezeigt, dass hier dringenderHandlungsbedarf besteht. Weder die Fortfhrung derPflege der alten Systeme noch die angedachte schrittwei-se Anpassung der TU-Prozesse sind mit den heute vorlie-genden Entwicklungsbasen zweckmig machbar. Daszugrunde liegende systemische Risiko musste nachhaltigbeseitigt werden.

Um eine przise Anpassung an die Bedrfnisse derTU und die Erhaltung bereits etablierter Vorzge ge-whrleisten zu knnen, entschied man sich nach umfas-senden Analysen fr die Beseitigung der bestehendenRisiken mittels einer Eigenentwicklung. Diese Entschei-dung garantiert whrend der gesamten Entwicklungszeithchste Flexibilitt und rasche Reaktionsfhigkeit durchdas eigene Entwicklungsteam bei gleichzeitigem Aufbauund Erhalt von Expertenwissen.

Das im Herbst 2007 vom Rektorat beschlossene undim Jnner 2008 begonnene Projekt firmiert unter demNamen TISS (TISS steht fr TU Wien Informations-Systeme und -Services) und widmet sich der Etablierungeiner langlebigen IT-Strategie, die

a) eine gemeinschaftliche technische Architektur bereit-stellt,

b) ein modernes interagierendes Applikationsmanage-ment erlaubt,

c) die Altsysteme schrittweise ablst, wo, wenn undwann dies zweckmig ist,

d) die langfristige Wartung sicherstellt,e) das Einpflegen neuer Dienste organisch bereitstellt,f) benachbarten Systemen (z. B. VoIP, SAP, e-Learning)

einen qualifizierten Docking-Partner anbietet und die-sen als kompaktes Leitsystem dient.

Ziele und Umfang von TISS

Um den vorhin genannten Kriterien zu gengen unddie IT-Landschaft der Technischen Universitt Wien imBereich Forschung, Lehre und Verwaltung fr die zu-knftigen Anforderungen des Managements auszurichten,

wird daher eine Integration der betreffenden Einzel-systeme im Haus auf eine homogene und konsolidiertePlattform durchgefhrt.

Dabei ergeben sich folgende Ziele fr dieses Vorhaben:

Solides Informationssystem aus einem Guss mit denFunktionen aller 6 Einzel-Systeme: TUWIS-alt (kurz:TUWIS), TUWIS++, Projektdatenbank, ZID-PDB,White Pages und Publikationsdatenbank.

Aufbau eines einfachen und umfassenden relationalenDatenmodells durch Integration der einzelnen Applika-tionen zu einem Ganzen.

Attraktive Online-Recherche-Mglichkeiten in den Da-ten und benutzerkonfigurierbare Auswertungen (derzeitnicht mglich, wenn Daten nur applikationsbergreifendvorliegen).

Integrierte, einheitliche und einfach bedienbare Online-Benutzer-Dialogfhrung im Web mit konsolidierter Me-nstruktur.

Leichtere Erweiterbarkeit der geplanten Plattform umweitere Applikationen (z. B. Customer Relationship Ma-nagement, Facility-Management etc.).

Leistungsfhige Anbindung an das SAP-System der TUWien.

Offene und standardisierte Schnittstellen in verschiede-nen Technologien (XML, CSV, SOAP etc.) zur Anbin-dung von zustzlichen externen Systemen.

Einbindung von Vertretern der universitren Leitung,betroffenen Verwaltungsdienststellen, Mitarbeitern derUniversitt und Studierenden zur Optimierung einer effi-zienten und effektiven Benutzbarkeit.

Konzentration der Krfte auf nur ein Gesamt-Produkt aufnur einer Plattform mit hoher Qualitt und aktuellerTechnologie.

Reduktion des intensiven Pflege- und Wartungsaufwan-des fr die Einzelsysteme mit ihren oftmalig erweitertenQuellcodes, dadurch Entlastung des Personals.

Sicherung der Prozess- und Datenqualitt.

Schematisch wird dies in den Abbildungen 1 und 2dargestellt.


Abbildung 1: Schema der Systeme mit Stand Mai 2008

Bei der Konzeption von TISS wird auf die Umsetzungmehrerer systemischer Schwerpunkte besonders geachtet:

Einfache und intuitive Handhabung der Software mit in-tegriertem Online-Hilfesystem.

Bestmgliche Untersttzung und Optimierung von abtei-lungs-/instituts-internen sowie bergreifenden Work-flows (z. B. durch ToDo-Listen fr jeden einzelnenBenutzer).

Umfassende Bereitstellung von Berichten und Auswer-tungen fr das Rektorat, die Fachabteilungen sowie Per-sonen in Management-Funktionen (Dekane, Studien-dekane, Institutsvorstnde, Projektleiter etc.).

Fein gegliedertes Berechtigungsmodell mit der Mglich-keit, eigene Rechte an andere Benutzer zu delegieren.

Revisionssichere Protokollierung und Versionierungvon relevanten Daten-Eingaben/-nderungen.

Phasen und grober Aufbau

Die TISS-Entwicklung gliedert sich in drei strategi-sche Projektphasen:

2008, Phase I: Vorbereitung der Migration mit demFokus auf der Erhaltung/Wiedergewinnung der formalenund informellen Ablaufinformationen und der Integra-tion der verschiedenen Quellen. Diese Phase ist ein ite-rativer Prozess zur Etablierung eines Fachkonzeptes, derTechnologie-Basis und der Architektur.

2009, Phase II: Beginn der Migration mit dem Fokusauf der Ablse der ersten Altsysteme, Integration derFelderfahrungen in die Entwicklung, der Anpassung desFachkonzeptes aufgrund des gewonnenen Feedbacks,dem Freeze der Technologie-Basis und der Architektursowie der Etablierung der Release-, Schulungs- und Roll-out-Prozesse.

2010, Phase III: Vollbetrieb und Reifung mit dem Fo-kus auf der Ablse aller Altsysteme, Etablierung des lau-fenden Release- und Change-Management-Prozesses,Vorbereitung fr den laufenden Betrieb und fr eineadaptive und perfektive Wartung. Eine Konsolidierungder Technik und der Organisation wird gemeinsam mitder berfhrung in die Wartung die Phase III vervoll-stndigen.

Whrend dieser drei Phasen wird in regelmigen Ab-stnden das TISS Steering Committee (TISSSC) als Projekt-lenkungsgremium tagen. Als Vorsitzender des TISSSCfungiert der Rektor selbst. Fr das TISS-Team ist diesbesondere Ehre und Verpflichtung gleichzeitig. Weitersgehren dem TISSSC der Vizerektor fr Lehre, Vertreterder beiden Betriebsrte und der Hochschlerschaft, sowieDekan Frhlich und Prof. Dustdar an. TISS wird vomZentralen Informatikdienst der TU Wien ausgefhrt undumgesetzt. Die Gesamtleitung des Projektes obliegt demLeiter des ZID, Wolfgang Kleinert ([email protected]), der fachlich von Thomas Grechenig, dem Leiterder Forschungsgruppe fr Industrielle Softwaretechnik(INSO, [email protected]), und seinemTeam untersttzt wird.

Der Aufbau der Projektstruktur ist in Abbildung 3 er-sichtlich. Die Projektgruppe 1 ist dabei fr die Erstellungund Etablierung des Fachkonzepts verantwortlich.

Motivation und Ziele des Fachkonzeptes

In den kommenden Jahren soll mit TISS eine homoge-ne, zukunftsfhige Systembasis geschaffen werden, diedie TU-Systeme an den modernen betrieblichen State-of-the-Art der Informationstechnik heranfhrt. Eine sehr be-wusste und intensive Herangehensweise bei der Erstel-lung des Fachkonzepts und der daraus gewonnenenAnforderungsanalyse stellen langfristig die adaptive undperfektive Wartbarkeit sowie ein verlssliches Applika-tionsmanagement sicher. Das Fachkonzept wird eine le-bendige Dokumentenlandschaft sein, die auch nach dembergang von TISS von der Entwicklungs- in die Pro-duktionsphase weitergepflegt werden wird.

TISS strebt im Rahmen des Fachkonzeptes die Erar-beitung einer optimalen Lsung fr alle Angehrigen derTU an. Diese Lsung wird unter Einbindung aller Stake-holder das sind die Personen mit Leitungsfunktionen,die Mitarbeiter in Fachabteilungen, die Betriebsrte unddie Vertreter der Studierenden evaluiert. Die umfassen-de Anforderungserhebung geschieht in einem iterativenProzess, bei dem bereits zu Beginn grter Wert aufUser-centered-Design gelegt wird. Ablufe knnen soholistisch betrachtet werden, bestehende Probleme analy-siert und gelst, neue Anforderungen effizient umgesetztund eine hoch benutzbare Lsung garantiert werden. Teil


Abbildung 2: Zielschema von TISS

PLProjektleitung

PL, Projektleitung

W.Kleinert (TU, ZID, Integration)T.Grechenig (Softwaretechnik)j g

PMO, Projektmanagementoffice

PG 2 PG 3 PG 4 PG 5 PG 6 PG 7Prototyping,Applic.Devel.

TechnischeArchitektur

Migration,technisches

CM

Neue&Nachbar-s steme

Betrieb/Betriebs-

Inf ast kt

QS, Test-Management

h b kh

PG 1Fachkonzept

l

PG 3a PG 5a

CM systeme Infrastruktur

PG 6a

.F. Schnbauer A. KnarekM. BernhartT.KltringerJ. Eberhardtsteiner J. FrhlichG.SteinhardtA. HrmannM. KolassaW. Sommer

Migrations-analyse

Infrastruktur Development

TUWELDocking

Experts AreaLegende:

PG ProjektgruppeEG Expertengruppe

EG 1Usability

EG 2Security

Abbildung 3: Struktur des Projektes aus technischer Sicht

des Prozesses ist es, vor der eigentlichen Implementie-rung bereits mit Prototypen zu experimentieren, um mg-liche Probleme in der Handhabung dort schon abzu-fangen bzw. die Benutzbarkeit von TISS zu optimieren.Schlielich soll eine konsolidierte Benutzerfhrung, un-tersttzt durch ein modernes Look & Feel die Freude ander Benutzung unterstreichen. Ein weiterer wesentlicherBaustein bei der Erstellung des Fachkonzeptes ist die Do-kumentation der Ablufe und zugehriger Regelwerke.Basierend auf diesen Dokumenten kann nicht nur solideentwickelt werden, sondern auch der nderungsaufwandbei neuen oder genderten Anforderungen bei Analyseund Entwicklung gering gehalten werden.

Ziel des umfangreichen Fachkonzept-Prozesses ist einemglichst dichte Integration der bestehenden SystemeTUWIS, TUWIS++, Projektdatenbank, ZID-PDB, WhitePages, Publikationsdatenbank und weitgehende Integra-tion des e-Learning Systems zu einer einheitlichen Da-ten- und Servicebasis, die das neue Informationssystemin Zukunft als rasch agierenden, qualifizierten Docking-Partner fr externe und interne Nachbarsysteme darstellt.

Vorgehensweise bei der fachlichen Analyse

Zu den fachlichen Zielen des TISS zhlt sowohl derAufbau eines konsistenten und umfassenden Daten- undService-Bestandes aus bestehenden und neuen Anwendun-gen, als auch die Implementierung von neuen Workflows.

Im ersten Schritt wurden bestehende Features aus denLegacy Systemen zusammen mit bereits bekannten neuenFeatures aggregiert, um die Komplexitt und den Arbeits-aufwand von TISS abschtzen zu knnen. In diesemProzess wurden bisher schon ber 300 fachlicheFeatures identifiziert und thematisch gruppiert. Abbil-dung 4 veranschaulicht diesen Prozess. Ein Featureist ein fachlich abgeschlossener Teil, der eine greif-bare Gre hat und in wenigen Personentagen umge-setzt werden kann. Beispiele dafr wren u. a. dasAnmelden zu einer Lehrveranstaltung, das Anzeigeneines Lohnzettels oder das Reservieren eines Hr-saals. Neben den fachlichen Features gibt es auchtechnische Features, die als Enabler fr die fachli-che Logik dienen. Darunter sind z. B. ein Rollen-und Rechtesystem, E-Mail Newsletter oder SAP-Schnittstellen zu verstehen.

Im nchsten Schritt werden die Features in fachli-chen Workshops auf Vollstndigkeit der Anforderun-gen berprft bzw. weiterentwickelt. Einige Work-shops zu folgenden Themen fanden bereits statt: Reporting und Statistik Studierendenverwaltung und Studierendenservices Studienplne Gebude und Rume Personen und Organisation ZID-Services SAP-Schnittstellen/Integration Alumnimanagement und TU Career E-Learning Integration

Die erste, sehr breite horizontale Welle an Work-shops brachte sehr gut die Probleme, den Optimie-rungsbedarf, neue Anforderungen, aber auch positiveSeiten der aktuellen Systeme (siehe Fachkonzept

Workshops Erste Ergebnisse) hervor. Es hat sich auchgezeigt, dass die Dokumentation von Regelwerken undProzessen innerhalb der TU nicht oder nur teilweise vor-handen ist und das Fachkonzept von TISS diese Lckenschlieen muss. Diese Dokumentation wird nachhaltigdie Eigenschaften der Systeme festhalten und nderun-gen bzw. neue Anforderungen einfach und konsistentumsetzbar machen. Entsprechend der Priorisierung in derProjektplanung wird mit der detaillierten Ausarbeitungder einzelnen Themengebiete begonnen. Folgeworkshops,Interviews und hohe Einbeziehung der TU-Mitarbeitersollen das Projekt beschleunigen.

Einige Themen (z. B. Publikationsdatenbank, Projekt-datenbank) wurden in der ersten Runde der Workshopsnoch nicht behandelt, sie werden aber im Laufe des Pro-jektes sukzessive folgen.

Ein integraler Bestandteil des Fachkonzept-Prozesses istes, die bestehenden Anforderungen zu aggregieren und ge-meinsam mit den Angehrigen der TU einen Vorschlagfr eine Lsung zu erarbeiten. Dieser Vorschlag kann einDokument, aber auch schon ein Prototyp in unterschiedli-cher Ausprgung sein. Anhand von konkreten Lsungsva-rianten und ihrer Iteration in einem fachlichen Dis-kussionsprozess kommt man zu einer optimalen Lsung,die auch sehr frh zeigt, in welche Richtung sich TISSentwickeln soll. Die unterschiedlichen Methoden werdenje nach Themengebiet eingesetzt. Manche Themen erfor-dern die Einbindung aller Stakeholder an der TU wohin-gegen andere mit der Einbindung einer einzelnenAbteilung bearbeitet werden knnen. Der gewhlte Pro-zess ist jedoch immer sehr agil, sodass auf neue bzw. ge-nderte Anforderungen sehr schnell reagiert werden kann.


Abbildung 4:Fachkonzept Pipeline

Iteration

Fachkonzept

KonzeptionR li iAggregation

User InterfaceRegelwerke

WorkshopsKommentierung

Prototypen

Realisierung

DevelopmentTechnischeRegelwerke

Workflowyp

und fachliche Qualittssicher

ung

R ll tRolloutAbbildung 5: Fachkonzept Rollout

Fachkonzept Workshops Erste Ergebnisse

Wie erwhnt, fanden bereits einige Workshops mitdem Ziel statt, ein gemeinsames Verstndnis der Anfor-derungen zu schaffen. Durch das Zusammenbringen ver-schiedener Stakeholder gelingt es auch immer wieder,aktuellen Problemen nicht erst in TISS, sondern auchdurch geringen Aufwand bereits in den Altsystemen zubegegnen. Darber hinaus wird versucht, die drin-gendsten herauszufinden und diese in dem agilen TISS-Entwicklungsprozess vorzuziehen (Quick Wins). Eini-ge erste Ergebnisse hier im berblick:

Studierendenverwaltung und Studierendenservices

Beim Workshop zum Thema Studierendenverwaltungund Studierendenservices wurden die wesentlichen Ab-lufe in der Studienabteilung besprochen. Dabei hat sichdeutlich abgezeichnet, dass hier groes Potential fr eineVerbesserung der Systeme sowohl fr Mitarbeiter alsauch fr Studierende vorhanden ist.

Eines der wesentlichen Konzepte, die in TISS umge-setzt werden sollen, ist das One-Stop-Prinzip bei derInskription. Ein solches Konzept, das bereits an verschie-denen Universitten erfolgreich implementiert wurde,knnte mehrfache Besuche der Studierenden in der Stu-dienabteilung auf einen einzigen reduzieren.

Unter Einbeziehung von alternativen Daten-Erfassungs-mglichkeiten (z. B. durch Verstrkung der Online-Servi-ces oder Kiosk-Systeme) sollen Studierende Services ein-facher und schneller als bisher beziehen knnen.

Studienplne

Auch im Bereich der Studienplne sollen neue Servi-ces konzipiert werden. Eine strukturierte Darstellung derStudienplne, die sowohl den Studierenden als auch derStudienabteilung mehr Einblick in den jeweiligen Stu-dienfortschritt bietet, soll mit Hilfe von TISS ermglichtwerden. Eine besondere Herausforderung bei einer sol-chen Erweiterung ist die vollstndige Integration sowohlauslaufender als auch neuer und gesonderter Studien-plne und Lehrgnge.

Eine Konsolidierung der Daten erlaubt es weiters, ver-schiedene Ablufe zu automatisieren und manuelleSchritte wie z. B. das Einreichen von Zeugnissen ber-flssig zu machen.

Personen und Organisation

Die TU Wien beschftigt derzeit mehr als 3700 Perso-nen in verschiedenen Anstellungsverhltnissen. Der Ein-satz von zwei SAP-Personalverwaltungs-Systemen paral-lel zur Mitarbeiterverwaltung im TUWIS++ erschwertdurch die derzeit notwendigen Mehrfach-Dateneingabenden Verwaltungsprozess. TISS setzt sich das Ziel, eineeinheitliche, strukturelle Darstellung aller Organisations-formen der TU Wien zu konzipieren, und eine Anbin-dung an die vorhandenen SAP-Systeme zu ermglichen.

Die eigentliche Software-Entwicklung

TISS wird mit Hilfe moderner Software Engineering-Methoden in einem agilen Entwicklungsprozess auf dertechnischen Basis von Ruby on Rails (siehe den Artikelvon Andreas Knarek auf Seite 9) entwickelt.

Bei einer phasenbasierten Entwicklung muss die we-sentliche Rolle des Release- bzw. Rollout-Managers er-whnt werden, der die Koordination und Kontrolle vonsmtlichen synchronen und asynchronen Ablufen meh-rerer Arbeitsgruppen bernimmt. Die Aktivitten und derProjektfortschritt werden generell durch ein Project Ma-nagement Office (PMO) berwacht.

Neben der Projektstatus-Kontrolle ist die berwachungder Entwicklung und die damit verbundene Qualittssi-cherung des Endproduktes ein wesentlicher Teil des Pro-jektes. Die Nachverfolgbarkeit des Fortschritts des TISS-Entwicklerteams wird mit Hilfe eines Ticket-Systemsauf Basis eines Collective Code-Ownership in TRAC,einem freien webbasierten Projektmanagementwerkzeugzur Software-Entwicklung (trac.edgewall.org), realisiert.

Die Qualittssicherung ist ein zentraler Bestandteil derTISS-Softwareentwicklung. Die Qualittseigenschaften,die ein moderner Entwicklungsprozess bercksichtigenmuss, erstrecken sich dabei ber ein breites Spektrum.Benutzer erwarten ein sthetisches und effizient benutz-bares System, das mglichst frei von kritischen Fehlernist und ausreichend performant und mit hoher Verfgbar-keit seinen Dienst leistet. Zustzlich erfordert die langeLebensspanne eines zentralen Softwaresystems auch dieQualitt unter der Haube. Entsprechend sorgfltig undrigoros muss daher auf sauber ausgestalteten und doku-mentierten und damit wartbaren und evolutionsfhigenQuellcode Wert gelegt werden. Um diese breiten Quali-ttsanforderungen abzudecken, sind im Rahmen der TISS-Softwareentwicklung unter anderem folgende Aktivittenetabliert:

Coding Standards: Die Programmier- und Dokumen-tationsrichtlinien umfassen eine Reihe von Richtlinieninkl. Best Practices und Musterimplementierungen frRuby, HTML/CSS, Datenbank-Code und Testcode. DieseStandards dienen zur einheitlichen und fehlervermeiden-den Implementierung des TISS-Quellcodes und Testco-des. Die Coding Standards werden in einem Wiki-Systemlaufend vom Entwicklungsteam und Experten kollektivweiterentwickelt und deren Einhaltung systematischdurch Review-Verfahren geprft und dienen damit auchdem Collective Code-Ownership Prinzip.

Styleguide: Fr die Benutzerschnittstelle definiert einumfassender Styleguide die wesentlichen Eigenschaften,das Erscheinungsbild sowie die Interaktion und garantiertdamit eine hohe Qualitt des User Interfaces, effizienteBenutzbarkeit und ein einheitliches Look-and-Feel. DieUmsetzung des Styleguides wird durch Templates undwiederverwendbare Software-Komponenten untersttzt.

Templates: Templates und wiederverwendbare Soft-ware-Bausteine dienen der Vermeidung von Fehlerndurch Mehrfachimplementierung und der Vereinheitli-chung der Implementierung. Oftmals verwendete Funk-


tionen und Arbeitsschritte werden zentral implementiertund gewartet und sind damit von der Entwicklung der ei-gentlichen Geschftsfunktion entkoppelt. Dieses Verfah-ren untersttzt insbesondere das Qualittsprinzip Dontrepeat yourself.

Code-Reviewing: Systematisches Code-Reviewing desTISS-Quellcodes whrend des Entwicklungsprozesses er-mglicht die Konformittsprfung mit den Coding Stan-dards. Weiters werden durch Code-Review-Verfahrenviele Fehler identifiziert, die durch klassische Testverfah-ren oft nicht abgedeckt sind. Dies stellt damit eine opti-male Ergnzung zu den Testverfahren dar. Durch diefrhe Identifikation von Problemen knnen diese raschausgebessert werden und verschleppen sich nicht in einespte Projektphase. Das Review-Verfahren wird nicht nurauf den eigentlichen Quellcode, sondern auch auf denTestcode angewandt, um Fehler in den Tests zu vermei-den. Durch ein entsprechendes TRAC Plugin wird dasReview-Verfahren direkt in der Entwicklungsumgebunguntersttzt.

Whitebox Funktionales Testen: Diese Testverfahrenwerden direkt in der Entwicklungsumgebung erstellt undautomatisiert durchgefhrt. Zu den Whitebox Testverfah-ren zhlen im Ruby on Rails-Kontext Unit Tests, Func-tional Tests und Integration Tests, die allesamt in derTISS-Entwicklung umgesetzt sind. Zur berwachung derTestabdeckung wird derzeit die C0-Abdeckung (Line Co-verage des Quellcodes) gemessen. Alle Tests werden tg-lich in der Integrationsumgebung mit dem aktuellenEntwicklungstand durchgefhrt und die Ergebnisse aus-gewertet.

Blackbox Funktionales Testen: Die funktionale Kor-rektheit der implementierten Funktionen wird mit Hilfeder Spezifikation manuell geprft und dokumentiert. Diesgeschieht einerseits durch strukturierte Testszenarien undandererseits durch intuitive und explorative Testverfah-ren. Eine Kombination aus strukturierten und freien Ver-fahren ergibt eine breite Abdeckung bei der funktionalenPrfung.

Performance Tests: Die Leistungsfhigkeit der Archi-tektur, Betriebsinfrastruktur und Implementierung wird re-gelmig durch einen automatisierten Performancetestgeprft. Zur Simulation der fr den Performancetest erfor-derlichen Virtuellen Benutzer wird das University Gridder TU Wien (www.zid.tuwien.ac.at/zidline/zl14/grid.html)genutzt. Damit ist die Simulation einer hohen gleichzeiti-gen Benutzerzahl whrend der Nacht mglich. EventuellePerformance-Engpsse knnen identifiziert werden, bevorsie den Benutzer betreffen.

Usability Check: Durch Prfung der Konformitt zumStyleguide und Usability-Expertenevaluierungen wird dieeffiziente Benutzbarkeit und ein einheitliches Look-and-Feel festgestellt und gegebenenfalls werden Verbesse-rungsmanahmen eingeleitet.

Fachliche Validierung: Ob ein Softwaresystem letzt-endlich reif fr das geplante Einsatzszenario ist, kann nur

durch einen Domnen-Experten (blicherweise ein Inten-sivbenutzer des Softwaresystems) geprft werden. Hierzuwerden mehrfach im Entwicklungszyklus Vor-Validie-rungen am Prototyp oder teilentwickelten System durch-gefhrt. Eine abschlieende Validierung wird im Rahmender Abnahme eines TISS-Rollouts durchgefhrt.

Ausblick und TISS als TU-Mitarbeiter-zentriertes Projekt

Wie oben dargestellt wurde, ist TISS kein Big Bang-Projekt. TISS lst nicht an einem herbeigefrchtetenTag gegen Ende 2010 alle Altsysteme, die dann nichtmehr funktionieren, durch ein Neusystem ab. Diesem Ri-siko wird das TISS-Team das Haus TU natrlich nichtaussetzen. Die Altsysteme werden schrittweise migriertund TISS wird organisch wachsen. Einerseits werden eta-blierte Mechanismen und Ablufe sanft erfasst und so-weit wie mglich und zweckmig mitgenommen undsodann in die neue Systematik integriert. Andererseits be-steht TISS aus sehr vielen Teilapplikationen, die im Sin-ne der User, aber auch im Sinne eines vernnftigenorganischen Lernens und Wachsens mit TISS fr das De-veloper Team, Phase fr Phase und Facheinheit fr Fach-einheit an die Mitarbeiter herangetragen werden.

Einzelne kleine Teilsysteme, bei denen das TISS-Team Not an Mann/Frau vorgefunden hat, werden schonim Jahr 2008 sichtbar werden. Einen groen Schub anneuer Systematik werden die Mitarbeiter im Haus Mittedes Jahres 2009 vorfinden. Danach wird es bis zur Pro-jektberuhigung Ende 2010, wo TISS in eine modernePflege- und Wartungsphase bergeleitet wird, einen kon-stanten Strom an Rollouts von neuen Komponenten frunterschiedliche Verwaltungsbereiche im Haus geben.

Neben den modernen Software-Engineering Verfah-ren, die bei der Entwicklung von TISS zur Anwendungkommen und die z. B. sicherstellen, dass bei der Einfh-rung von neuen Releases von TISS-Teilsystemen immerauch alle alten Use- und Testflle automatisch geprftwerden, wird das TISS-Team soweit wie mglich undzweckmig mit den zuknftigen Usern gemeinsam dasneue System etablieren. In mehreren Fllen wird es dabeimglich sein, mit den zuknftigen Usern gemeinsam dieAnwendungen mittels Previews der Systeme zu prfen,anzupassen und weiterzuentwickeln, sodass der wirklicheVorteil einer Eigenentwicklung im Haus zur Gnzegenutzt werden kann, um dem stillen Projektziel vonTISS mglichst nahe zu kommen: TU Software-Servicesund -Systeme von allen Mitarbeitern fr alle Mitarbeiterim Haus.

Interessierte Leser seien auf TISS-inside (www.tiss.tuwien.ac.at) verwiesen, um aktuelle Zwischenstnde, Er-gebnisse, Projektfortschritte und -berichte aus ersterHand zu bekommen. Unabhngig davon wird die ZIDlinein den kommenden zwei Jahren in regelmigen Abstn-den mit einzelnen Fachbeitrgen ber TISS berichten.


Ruby on RailsAndreas Knarek

Ruby on Rails (kurz RoR oder Rails, www.rubyonrails.org) ist ein modernes, agiles Webframeworknach dem MVC-Prinzip (Model-View-Controller). Es baut auf der Skript-Sprache Ruby (www.ruby-lang.org) auf und zeichnet sich im Wesentlichen durch die ideologischen Grundstze Conventionover Configuration und DRY (dont repeat yourself) aus. Das Projekt TISS (siehe Seite 3) wirdauf der technischen Basis von Ruby on Rails entwickelt.

Die Sprache Ruby

Die objektorientierte Skript-Sprache Ruby wurde bis1995 von einem einzelnen Entwickler, Yukihiro Matsumoto(kurz Matz) aus Merkmalen von mehreren bestehendenSprachen wie Perl, Smalltalk, Eiffel, Ada und Lisp zu-sammengesetzt. Dabei wurde besonders darauf geachtet,eine sehr lesbare und einfache Sprache zu entwickeln, dieauch komplexe Vorgnge mit wenigen kurzen Befehlenumsetzen kann. Seit 1995 erfreute sich Ruby jhrlich im-mer grerer Beliebtheit und verbreitet sich seit dem Er-scheinen des Webframeworks Ruby on Rails auch immermehr im professionellen/kommerziellen Bereich. Auer-dem ist eine sehr groe OpenSource-Community umRuby entstanden, die die Sprache laufend verbessert undweiterentwickelt.

In Ruby ist prinzipiell alles ein Objekt. Dadurch sindzum Beispiel auch Iteratoren fr Datentypen wie Ganz-zahlen mglich, die im ersten Moment zwar merkwrdigerscheinen, jedoch sehr lesbar sind und gegenber her-kmmlichen for-Schleifen die natrlich auch mglichsind sehr viel kompakter sind:

3.times do { print Hello }

Ruby erlaubt es auerdem, jede Methode und jedenOperator (sind in Ruby nichts anderes als Methoden) zuberschreiben und offenbart dadurch ungeahnte Flexibili-tt. Vererbung ist fr eine objektorientierte Sprache natr-lich Pflicht. Zustzlich gibt es auch noch die Mglichkeitvon Mixins. Dabei handelt es sich um Code-Module/Frag-mente, die in beliebige Klassen und Objekte dynamischdazugeladen werden knnen um diese zu erweitern bzw.auch Funktionalitt zu ersetzen. Auch die Basisklassenvon Ruby knnen beliebig erweitert und verndert werden,ohne mittels Vererbung eingreifen zu mssen.

# Erweiterung des Datentypen Numericclass Numericdef addiere(x)self.+(x)

endend

# Resultat7.addiere 2=> 9

Es gibt mittlerweile unzhlige Module und Erweite-rungen fr Ruby, die es zu einer sehr mchtigen Sprachewerden lassen. Durch die interpretierte Ausfhrung wirdeine Plattformunabhngigkeit hnlich wie bei Java er-reicht. Aktuell ist Ruby fr GNU/Linux, viele UNIX-Va-rianten, Mac OS X, Windows 95/98/Me/NT/2000/XP,DOS, BeOS, OS/2 etc. verfgbar. Fr den Serverbetriebwird allerdings ein Linux-System empfohlen, da dort diebeste Performance erzielt wird.

Da Ruby mittlerweile auch ein groes Interesse in derJava-Community geweckt hat, existiert schon ein rechtausgereiftes Projekt namens jRuby (jruby.codehaus.org)das eine Ausfhrung von Ruby-Code in einer Java-VM er-laubt. Auerdem kann beliebig zwischen dem Kontext vonJava und Ruby gewechselt werden es ist also mglich,in Java Ruby-Bibliotheken zu benutzen und umgekehrt.

Um die Performance von Ruby weiter zu steigern,wird fr das nchste groe Ruby-Release bereits an einerJava-hnlichen Bytecode-Generierung gearbeitet.

Das Webframework Ruby on Rails

Rails wurde 2004 von David Heinemeier Hansson ver-ffentlicht. Im Gegensatz zu vielen anderen Webframe-works jedoch mit dem groen Unterschied, dass Railsaus einer bestehenden Business-Applikation extrahiertund nicht knstlich Schritt fr Schritt aufgebaut wurde.

Rails implementiert das so genannte MVC-Paradigma(Model-View-Controller), das eine Applikation auf dreiSchichten zerlegt:

Model-Layer: einfacher, zentraler Zugriff auf relationa-le Datenbanken (aktuell untersttzt: DB2, Informix, Fi-rebird, MySQL, Openbase, Oracle, PostgreSQL, SQLite,MS SQL Server, Sybase).

Controller-Layer: Steuerungsschicht zum Kapseln vonBusiness-Logik und Schnittstellen mit Untersttzungvon mchtigen Routing-Mechanismen zur einfachen Im-plementierung von pretty URLs.

View-Layer: Untersttzung von verschiedenen dynami-schen Ausgabeformaten wie HTML, XML/XHTML,JavaScript sowie Binrdaten.


Das vereinfachte Architektur-Bild, das wir fr TISSeinsetzen, kann wie folgt dargestellt werden:

Die blauen Bereiche stellen die Persistenzschicht (Model-Layer) dar, die grne Schicht die Steuerungsschicht(Controller-Layer) und die violette Schicht schlussendlichdie Templateschicht (View-Layer).

Model-Layer: ActiveRecord

Die Klasse ActiveRecord stellt in Rails das Datenbank-Backend dar. Es erlaubt neben den einfachen Daten-bankzugriffen SELECT, UPDATE, INSERT, DELETEauf einzelne Tabellen auch komplexe Darstellungen wieAggregationen, Assoziationen und bietet auch ein eigenesdatenbank-unabhngiges Migrationsframework an.

Beispiel fr die Darstellung von Personen Tasksmit ActiveRecord und Migrations:

# Anlegen der Datenbank-Tabellencreate_table :people do |t|t.column :name, :string, :limit=>50, :null=>false

endcreate_table :tasks do |t|t.column :person_id, :integer, :null=>falset.column :name, :string, :limit=>255, :null=>falset.column :todo_until, :datetime

end# ActiveRecord Models zum Datenbank-Zugriff aus der# Applikation herausclass Person < ActiveRecord::Basehas_many :tasksvalidates_presence_of :name

endclass Task < ActiveRecord::Basebelongs_to :personvalidates_presence_of :person_id, :name

end

Dieser Code reicht aus, um die notwendigen Daten-banktabellen in der konfigurierten Datenbank anzulegen,und alle mglichen Datenoperationen auszufhren:

# Auslesen aller Personen mit dem Namen Stefanpersonen = Person.find_all_by_name Stefan# Auslesen der Person mit der ID 2person = Person.find 2# Auslesen aller Tasks der Person mit ID 2person.tasks# Anlegen einer neuen Personperson_neu = Person.create :name=>Neue Person# Anlegen eines Tasks zu dieser neuen Personperson_neu.create_task :name=>Neuer Task# Suchen aller Personen mit einem Task namens Pausepersonen = Task.find_all_by_name(Pause).collect{ |p| p.person }

Neben den einfachen Relationen wie 1:1, 1:n, m:nuntersttzt ActiveRecord auch komplexere Konstruktewie STI (single-table-inheritance) und polymorphe 1:nund m:n Relationen. Ein ausgeklgeltes Validation-Inter-face erlaubt auerdem eine zentrale Prfung der Daten,

bevor sie in die Datenbank persistiert werden. MittelsCallbacks und Observers kann auf verschiedenste Ak-tionen in der ORM-Schicht direkt reagiert werden. ZumBeispiel ein E-Mail an alle Admins, sobald ein neuer Be-nutzer angelegt wird. blicherweise wrde eine solcheAktion in der Benutzer-Anlegen-Logik implementiertwerden. Wird dann von irgendwo anders aus ein Benut-zer angelegt, erfolgt kein E-Mail-Versand. Durch diePlatzierung direkt in der ORM-Schicht kann man diesesProblem elegant beseitigen.

Controller-Layer: ActionController

Die Klasse ActionController erlaubt das Implementie-ren von Funktionalitt, die mittels HTTP-Request aufge-rufen werden kann. Damit stellen die Controller-Klassendie zentrale Steuerung der Applikation dar. Mit ihnenknnen Webschnittstellen und dynamische Webseiten im-plementiert werden.

Fr obiges Personen-Tasks-Beispiel wrde der zuge-hrige Controller-Code fr das Anzeigen, Editieren undndern/Speichern eines Tasks folgendermaen aussehen:

class TaskController < ApplikationController# laden des referenzierten tasks, das dazugehrige# HTML-Template anzeigen.html.erb wird anschlieend# automatisch geladendef anzeigen@task = Task.find params[:id]

enddef editieren@task = Task.find params[:id]

end# laden und ndern des referenzierten Tasks wenn# nicht gespeichert werden kann Fehlermeldung anzeigendef aendern@task = Task.find params[:id]if @task.update_attributes(params[:task])flash[:error] = Speichern fehlgeschlagenredirect_to :action=>:editieren, :id=>params[:id]

elseflash[:info] = Task wurde gespeichertrender :action=>:anzeigen, :id=>params[:id]

endend

end

View-Layer: ActionView

Die Klasse ActionView wird vom ActionControllerverwendet, um eine Antwort an den HTTP-Request zu-rckzuschicken. Dabei kann es sich um ein HTML-Tem-plate, XML-Template etc. handeln. Das HTML-Templatefr die Seite anzeigen zu unserem Beispiel knnte wiefolgt aussehen:

Task-DetailsInhaber: Name des Tasks: :editieren,:id=>@task

Durch das modular aufgebaute System knnen mit Hil-fe der ActionView-Klasse nicht nur HTML-Seiten sondernauch andere Output-Formate wie xhtml, xml, javascript(fr AJAX-Funktionen), csv, xls u.v.a. auf die gleiche Arterzeugt werden. Auch Methoden fr wichtige Sicherheits-aspekte wie SQL-Injection, XSS (cross-site scripting),XSRF (cross-site request forgery) und Session-Hijackingwerden von ActionView zur Verfgung gestellt. Auer-dem bieten auch verschiedene Module/Plugins Mglich-keiten zur Internationalisierung (I18N) und Lokalisierung(L10N) der Applikation.


ORM ActiveRecordRDBMS

Model Validations

ActionController

Authentification/AuthorizationActionView

Templates(html, PDF etc.)

RailsDispatcherTemplate Caching

TemplateHelpers(Forms, Lists, AJAX etc.)

SessionHandler

ModelExtensions(acts_as_tree, act_as_list

acts_as_email etc.)

I18N, L10N

Client(Browser, WebService) Web Server

Action Caching

Static Content,Page Caching

Action Webservice

Action Mailer

Libraries & Tools

forwards

loads

redirects

uses

uses

usesqueries

delivers

delegates

renders

renders

displays

displays

responds

uses

uses

requests

Automatisierte Tests

Da groe Systeme auch groe Mengen an Sourcecodehervorbringen, ist es fr die Qualitt des Systems vonenormer Wichtigkeit, ein zuverlssiges und umfassendesQualittsmanagement durchzufhren. Rails untersttzt dieEntwicklung an dieser Stelle mit einem Framework frautomatisierte Whitebox-Tests. Diese sind direkt in dieApplikation eingebunden und bieten eine unkomplizierteMglichkeit, den entwickelten Code mit Test-Code zuverifizieren.

Rails bietet vier verschiedene Test-Arten an:

Unit-Tests: zum Testen der Model-Schicht und der da-ten-objekt-bezogenen Business-Logik.

Functional-Tests: zum Testen der Controller-Schicht mit-tels Simulation von HTTP-Zugriffen auf die Applikation.

Integration-Tests: zum Testen von komplexen Work-flows innerhalb der Applikation durch Untersttzungvon Multi-Session-Operationen.

Test-Mocks: zum Testen von externen, ber Schnittstel-len angebundenen Objekten und Simulation dieserSchnittstellen.

Neben den eigentlichen Test-Ablufen ist es natrlichauch notwendig, dafr geeignete Testdaten zur Verf-gung zu haben, damit die Tests immer mit definiertenDaten arbeiten knnen. Auch dazu bietet Rails in Formvon so genannten Test-Fixtures eine Lsung an. Diesedatei-basierenden Daten werden pro Datenbanktabelle ineiner YAML-Datei (yet another markup language) ge-speichert. Mit wachsender Applikation wachsen auch die-se Testdaten und erlauben so immer komplexere Tests.

TISS on Rails

Die Beweggrnde fr die Entscheidung, RoR fr dieEntwicklung von TISS zu verwenden, sind recht vielsei-tig. So hat sich in den vielen Jahren der Entstehung vonTUWIS, TUWIS++ und anderen TU Wien-Systemen ge-zeigt, dass es notwendig ist, ein sehr flexibles, einfachesund somit wartbares Campussystem zu entwickeln, da esim Universittsumfeld laufend zu nderungen und Er-weiterungen (neue Verordnungen, Gesetzesnderungen,Richtlinien sowie universitts-interne Umstrukturierun-gen) kommt. Viele von diesen Aspekten mssen auch imCampussystem umgesetzt werden. Deshalb spielt dieWartbarkeit des Systems eine groe Rolle.

Durch die unkomplizierte Abbildung von komplexenDatenstrukturen, Betriebsablufen sowie die integriertenund ebenfalls sehr einfach definierbaren Selbsttests ent-steht mit vergleichsweise wenig Aufwand ein umfangrei-ches System auf einer soliden Basis.

Um die Applikation auch fr den Benutzer modern zuprsentieren, wird bei der GUI-Erstellung besonders aufdie Einhaltung von HTML-Standards und speziell frTISS definierte Design-Guides geachtet.

Schnittstellen und Migration

Da TISS im Zuge einer sanften Migration in Betriebgenommen wird, mssen eine Menge an Schnittstellen zubzw. zwischen bestehenden Systemen erstellt werden, dienach vollstndigem Abschluss der Migration zu TISS

teilweise wieder deaktiviert werden. Der erste Migrations-Schritt kmmert sich grtenteils um die Stammdaten al-ler Personen, die an der TU Wien ttig sind bzw. mit derTU Wien in Berhrung kommen. Neben den hauseige-nen Studierenden, Mitarbeitern und Lehrenden sind dasz. B. auch externe Projekt-Mitarbeiter, Gastprofessoren,bis zu Kunden unserer Bibliothek.

Die erste sichtbare Erscheinung dieses Datenabbildswird als Preview des neuen TU Wien Adressbuchs dasRelease des TISS-Adressbuchs im Sommer 2008 sein.

Zahlen und Fakten zum aktuellen Entwicklungsstand

Aktuell (Stand per 10. 6. 2008) ist bereits eine MengeFunktionalitt in TISS entstanden. Die nachfolgende Ta-belle soll einen kurzen berblick darber zeigen:

Anzahl

Datenbank-Tabellen 171

Ruby-Klassen 297

Ruby-Codezeilen 11.506

Template-Dateien 312

Entwicklungsteam

Unser Kern-Entwicklungsteam besteht derzeit aussechs Entwicklern (alphabetische Reihung): BorovaliBeytur-Deniz, Frhwirth Roland, Glaser Florian, KnarekAndreas (Entwicklungsleitung), Rajkovats Alexander,Vargason Robert.

Wir werden dabei von einem Team der Forschungs-gruppe fr Industrielle Software unter der Leitung vonThomas Grechenig (www.inso.tuwien.ac.at) untersttzt,das im Last- und Bedarfsfall direkt mitarbeitet an derTISS-Source, Prototypen fr Requirements EngineeringWorkshops etabliert bzw. die Codierung in den Gesamt-rahmen eines greren Entwicklungsprojektes einbettet.Die konzeptiven Software Engineering Manahmen (wieQualittssicherung, Teststrategien, Releaseplanung, War-tung, Wiederverwendung), die ber die ohnehin in RoRfest eingebauten Mechanismen hinausgehen, fr dieLanglebigkeit und Beweglichkeit des TISS-Systems aberunabdingbar sind, werden von Mario Bernhart aus demINSO Team angefhrt.

Resmee

Die Beispiele stellen natrlich nur sehr einfache Fllevon Applikationslogik dar, zeigen aber sehr deutlich, mitwie wenig Source-Code man in Rails auskommt.

Rails ist jedoch bei weitem mehr als die Versammlungder drei Basis-Klassen fr das MVC-Paradigma. Es bein-haltet, wie bereits erwhnt, ein Framework zum automati-siert verwalteten Aufbau (Release-Management) derDatenbank, Internationalisierung der Applikation undvieles mehr.

Die Aufzhlung von allen Mglichkeiten, die Railsmittlerweile bietet, wrde den Rahmen dieser Zeitschriftbei weitem sprengen. Es gibt unzhlige Erweiterungenfr alle drei Schichten von Rails, die dem Entwickler dasLeben leichter machen und komplexe Vorgnge auf einMinimum an Aufwand reduzieren.


TUphone die Zukunft der Telefoniean der TU WienJohannes Demel

Die bestehende Nebenstellenanlage der TU Wien wird aufgrund ihres Alters durch eineVoice over IP

1- basierende Telekommunikationslsung ersetzt (2009/2010). Zugleich wird es zueiner Vereinfachung der Gesprchsverrechnung kommen. Noch 2008 werden die DECT-Gertedurch GSM-Mobiltelefone ersetzt.

Gestern

Bevor wir uns der Zukunft der Telefonie an der TUWien zuwenden, soll ein kurzer Rckblick ber die Ent-wicklung der Telefonie an der TU Wien und im Allge-meinen erfolgen.

Im Jnner 1981 wurde als Hauptanlage der TU Wien eineKapsch PKE in Betrieb genommen, die in den Jahren1987 und 1990-1992 um insgesamt 14 kleinere Anlagenergnzt wurde.

Im Jahr 1995 beauftragte die TU Wien ein Vorprojekt freine neue Telefonanlage. Der Bericht wurde Ende 1995vorgelegt und empfahl der TU Wien die Installation einereinheitlichen Telefonanlage. Die geschtzten Investitions-kosten betrugen damals 58 Mio. Schilling exkl. MwSt.

Am 24. 6. 1996 beschloss der Akademische Senat dieErstellung eines Konzepts fr eine neue Telekommuni-kationsanlage. Nach Freigabe durch das BMWF konnteam 4. Juni 1997 die Planung einer neuen Telefonanlagefr die TU Wien beauftragt werden. Die Verffentli-chung der EU-weiten Ausschreibung erfolgte nach Frei-gabe durch das BMWF Ende Dezember 1997.

Anfang 1998 begann die Diskussion, wer denn die neueTelefonanlage berhaupt betreiben soll. Bis dahin wardies die damalige Bundesbaudirektion. Ende Februar1998 wurde das damalige EDV-Zentrum (heute ZID),konkret die Abteilung Kommunikation, mit dem Betriebder neuen Telefonanlage beauftragt. Damit wandertedann auch die Vermittlung zum EDV-Zentrum.

Nach der Anbotserffnung am 11. 3. 1998, der Bewer-tung und einem Probebetrieb erfolgte am 8. 7. 1998 dieBeauftragung der Post und Telekom Austria AG als Ge-neralunternehmer mit der Errichtung der Telefonanlagedes Herstellers Ericsson, Type MD110, inklusive einemDECT-System.

Die Hauptumstellung erfolgte am Wochenende des 5. 9.1998. Dabei wurde auch die Umstellung des Nummern-plans von einem 4-stelligen gebudeorientierten auf ein5-stelliges organisationsorientiertes Nummernkonzeptvorgenommen. Nach Fertigstellung der Gebude Favori-tenstrae (1999) und Perlmooserhaus wurden die restli-chen Teilanlagen in Betrieb genommen.

Die formale Endabnahme des gesamten Projekts erfolgteam 31. 7. 2001. Die Endkosten betrugen ca. 51 Mio.Schilling (ohne Nebenkosten fr die Adaptierung der In-frastruktur, fr die Verkabelung neuer Anschlsse, sowiediverse Herstellungskosten von Amtsleitungen und sons-tige TU-interne Nebenkosten).

Technologisch war die Anlage aus dem Jahr 1981 einevorwiegend mechanische analoge Nebenstellenanlage.(Es gibt Meinungen, dass diese Anlage zum Zeitpunktder Installation eigentlich schon veraltet war.) Die Anla-ge aus dem Jahr 1998 ist eine vollelektronische digitaleAnlage, basierend auf ISDN-Technologie.

Ein anderer wichtiger Aspekt ist die Entwicklung derGesprchskosten zum ffentlichen Telefonnetz. So betru-gen alle verrechneten Telefonentgelte fr das Jahr 1999(Dienst-, Drittmittel- und Privatgesprche) umgerechnet


1 (VoIP []): Telefonieren ber Computernetzwerke, welche nach Internet-Standards aufgebaut sind. Dabei werden fr Telefonie typische Infor-mationen, d. h. Sprache und Steuerinformationen z. B. fr den Verbindungsaufbau, ber ein auch fr Datenbertragung nutzbares Netz bertragen.

knapp 400.000 Euro. Im Jahr 2007 ist dieser Betrag aufca. 135.000 Euro gesunken, also etwa auf 1/3. Die An-zahl der Gesprche ist im gleichen Zeitraum von ca. 1,6Mio. auf 840.000 gesunken, also eine Halbierung. ImJahr 1997 wurde auf Basis der damaligen Gesprchskos-ten ein ziemlich aufwndiges Verrechnungssystem konzi-piert und dann auch realisiert. Ca. 25% der damaligenInvestitionskosten sind dem Chipkartensystem zuzuord-nen. Eine Berechnung im Jahr 2002 hat ergeben, dass dieauf 10 Jahre umgelegten Investitionskosten und die War-tungs- und Personalkosten in Summe etwa gleich hochwaren wie die gesamten Gesprchskosten (die seit da-mals aber weiter deutlich gesunken sind).

Heute

Die derzeitige Nebenstellenanlage des Fabrikats EricssonMD110 besteht aus 24 LIMs (Teilanlagen) an 17 Stand-orten, die mittels eines redundanten Group-Switches zueiner Gesamtanlage mit einheitlichem Rufnummernplanzusammengefasst sind. Insgesamt existieren ca. 5.100Festapparate (digitale und analoge wie Fax) und ca. 600mobile Endgerte zur DECT-Infrastruktur mit ca. 380Sendern. Die Anlage ist mit 21 Multianschlssen (630Kanle) mit dem ffentlichen Netz verbunden. Die ein-zelnen Teilanlagen sind ber unterschiedliche Technolo-gien (Kupferverbindung, Glasverbindung, IP-Muxe,ATM) verbunden.

An einigen Standorten (Engerthstrae, Arsenal, Vet-Med, Wiedner Hauptstrae 76) gibt es lokale Lsungenoder GSM-Diensthandys.

Daneben sind ca. 220 Diensthandys im Rahmen desA1 Networks der TU Wien im Einsatz.

Die TU Wien nimmt an dem Pilotprojekt AT43(www.at43.at) mit VoIP SIP-Technologie teil, das Studie-renden und Mitarbeitern eine kostenlose persnliche SIP-Rufnummer inkl. Voicebox bietet. Weiters wird einAsterisk-Server betrieben, der aus dem AT43-Netz undvon anderen SIP/ENUM-fhigen Telefonapparaten bzw.Softphones den (kostenlosen) Zugang zur Nebenstellen-anlage der TU Wien bietet. ber diesen Asterisk-Serverist auch das experimentelle Fax/Mail-Gateway realisiert.

Handlungsbedarf

Die existierende Nebenstellenanlage wurde fr 10 Jah-re konzipiert. Das bedeutet natrlich zum Glck nicht,dass sie jetzt nicht mehr funktioniert es gibt auch frdie Anlage selber, nicht aber fr die Endgerte, einenentsprechenden Wartungsvertrag. Wir brauchen sie nochmindestens zwei Jahre! Aber genau im Endgertebereich,insbesondere bei der Chipkartenlsung, die neben der TUWien nur an der Universitt Wien (in einer einfacherenForm) existiert, gibt es bereits Probleme, entsprechendeErsatzteile zu bekommen. Auch die Stabilitt des Chip-kartenprogrammiergertes (auf das die dazugehrigeSoftware zugeschnitten wurde) bereitet immer wiederProbleme mit oft monatelanger Nichtverfgbarkeit. Auchwurde auf der Telefonanlage nie ein Software-Upgrade mit Ausnahme von Patches installiert. Aktuelle Versio-nen der MD110 Software wrden z. B. bereits VoIP beiEndgerten und zur Verbindung von Teilanlagen unter-

sttzen. Eine Aufrstung scheiterte aber an den hohenKosten (einige 100.000 Euro), die an den diversen Son-derpatches fr die TU Wien (wie das Chipkartensystem)liegen. Dadurch ist es insgesamt praktisch nicht mglich,die existierende Anlage z. B. bei Anmietung oder Errich-tung neuer Standorte (Lehartrakt, Science Center) durchdie TU Wien zu erweitern.

Das DECT-System war schon immer mit Mngeln be-haftet (deswegen auch eine Preisreduktion bei der Ab-nahme). Es kommt noch dazu, dass inzwischen mehrereGenerationen von DECT-Mobiltelefonen im Einsatz sind,die gerade bei den diversen Mngeln unterschiedlichePhnomene aufweisen. Fr die DECT-Gerte der Erstin-stallation gibt es keine Ersatzakkus mehr. Wenn derAkku also defekt ist nach ca. 8 Jahren nicht ungewhn-lich muss das gesamte Gert getauscht werden. ImHandy-Zeitalter ist es auch eher unhandlich, neben einemGSM-Handy (bei der Handy-Durchdringung in ster-reich hat praktisch jeder bereits eines) zustzlich noch einDECT-Gert herumzutragen.

Zu guter Letzt hat die Firma Ericsson mit Wirksam-keit vom 1. 5. 2008 das komplette Nebenstellengeschft(inklusive Personal) um ca. 70 Mio. Euro (bei einem Re-venue in 2007 von ca. 300 Mio. Euro) an die kanadischeFirma Aastra verkauft. Wir werden in den nchsten Mo-naten sehen, was das wirklich bedeutet!

Aus diesen Grnden wurde im Frhjahr 2007 die Fir-ma DTN Datenkommunikation, Telekommunikation undNetzwerktechnologie Planungs GmBH mit der Erstellungeiner Vorstudie fr eine neue Telekommunikationsanlagefr die TU Wien beauftragt. Im Zuge dessen wurden vonSeiten des ZID auch die notwendigen Infrastrukturma-nahmen, die fr eine VoIP-Anlage notwendig sind (TP-Verkabelung in allen Bereichen, Power over Ethernet,USV-Kapazitten fr alle Etagenverteiler), untersucht.Auch wurden Gesprche mit Mobilprovidern ber eineVerbesserung der GSM-Versorgung fr Sprachtelefoniein den Gebuden der TU Wien gefhrt.

Auf Grund der Ergebnisse all dieser Untersuchungenbeschloss das Rektorat am 15. April 2008

eine Vereinfachung der TU-internen Telefongesprchs-abrechnung (ab 2009),

den Ersatz der DECT-Infrastruktur durch GSM-Mobilte-lefone (4. Quartal 2008),

die Planung einer neuen Telefonanlage basierend auf ei-ner VoIP Softswitch-Lsung (Realisierungszeitraum2009/2010).

Morgen die Ziele

Welches sind nun die Ziele einer neuen Telekommuni-kationslsung fr die TU Wien?

State-of-the-Art: Die neue Telekommunikationslsungsoll auf einer Softswitch-Architektur und dem Voiceover IP -Konzept basieren. Praktisch keiner der heuteam Markt befindlichen Anbieter von Nebenstellenan-lagen in der fr die TU Wien notwendigen Gre bie-tet (bei Neuprojekten) noch die klassische ISDN-L-sung an.


Mobilkommunikation: Komfortable Einbindung derMobilkommunikation in die Nebenstellenanlage.

One-Number-Konzept: Die Erreichbarkeit und insbe-sondere die Steuerung der Erreichbarkeit soll durchErreichbarkeitsprofile (sollen ankommende Gesprcheam Festapparat angezeigt werden oder auf das Mobil-telefon umgeleitet werden oder in eine Sprachbox?) verbessert werden.

Verrechnung: Die TU-spezifische Gesprchskostenab-rechnung soll deutlich vereinfacht werden.

Unified Communications: Eine moderne Telekommuni-kationslsung soll als Service nicht nur das Telefonie-ren anbieten. Es soll ein Mehrwert durch einen ganz-heitlichen Ansatz fr die Bereiche Telefonie, Voice-Messaging, Unified Messaging, E-Mail, Fax, Prsenz-informationen, Collaboration, Conferencing gebotenwerden.

Softphones: Neben den Festapparaten (Hardphones)soll auch die Mglichkeit von Softphones (am PCoder Laptop) und die Steuerung des Festapparatesvom PC geboten werden.

Elektronische Verwaltung: Die bisher in der Regel berPapier erfolgenden Schritte bei Errichtung/nderungvon Telefonanschlssen oder A1 Network Anschls-sen sollen ber elektronisch untersttzte Workflows(hnlich den Lsungen bei Software-Lizenzen und Be-nutzerberechtigungen) erfolgen. In diesem Zusammen-hang soll auch ein TUphone-Freigabeberechtigter anden Organisationseinheiten definiert werden. Auch dieInformation ber die Gesprchskosten soll auf elektro-nische Wege umgestellt werden. Sinnvoll ist hier dieIntegration in TISS.

Gleitende Umstellung: Im Gegensatz zur Big-Bang-Umstellung im Jahr 1998 soll die Umstellung gebu-de- und/oder organisationsweise ber einen Zeitraumvon 6-12 Monaten erfolgen. Erst nach der komplettenUmstellung kann die alte Anlage abgeschaltet werden,da eine Rekonfiguration der Teilanlagenvernetzung zukomplex und fehleranfllig wre.

Der Weg

Nachdem das Rektorat den prinzipiellen Beschluss ge-fasst hat, sind eine Reihe von Aktivitten im Rahmen desProjekts TUphone erforderlich:

Die GSM-Versorgung in den Gebuden muss verbessertwerden, um dann im Herbst 2008 das DECT-Systemdurch das A1 Network zu ersetzen (siehe AbschnittDECT-GSM).

Ein neues Verrechnungsprinzip muss entwickelt, abge-stimmt und in Betrieb genommen werden (siehe Ab-schnitt Verrechnung).

Die Anforderungen an eine neue Telefonlsung mssenanalysiert und definiert werden. Auf dieser Grundlagekann dann die Beschaffung durchgefhrt werden.

Die Verkabelungsstruktur sowie die dazu notwendigeRauminfrastruktur (Platz fr/im Etagenverteiler, Strom-

versorgung inklusive USV, eventuelle Klimaanforde-rungen) mssen analysiert werden. Auf dieser Basis kanndann die Verkabelung ergnzt bzw. erneuert und dieRauminfrastruktur hergestellt werden. Das TUNET-Backbone muss voice-tauglich gemacht werden (d. h.Quality of Service, ...).

Um Erfahrung am eigenen Leib mit einer derartigenLsung zu gewinnen, wird schon seit ca. einem Jahr imBereich der Abteilung Kommunikation eine VoIP-Lsung im Parallelbetrieb erprobt. Dieser Versuch wirdnun auf den gesamten ZID ausgedehnt. Zustzlich solldie Unified Communications-Technologie ausprobiertwerden.

Und dann muss nur mehr die neue Lsung installiertwerden.

Ersatz von DECT durch A1 Network GSMMobiltelefone

Wie schon vorher erwhnt, muss aus einer Reihe vonGrnden die proprietre DECT-Lsung ersetzt werden.Dabei ist eine wichtige Randbedingung, dass dies vor In-stallation einer neuen Telefonanlage erfolgen muss unddass die Abschaltung fr alle Standorte gleichzeitig er-folgt es macht wenig Sinn, wenn jemand mit Arbeits-platz am Karlsplatz sein DECT-Gert z. B. im Freihausnicht mehr verwenden kann. Auerdem gibt es extremkomplexe Zusammenhnge zwischen den einzelnen Ge-buden bei der DECT-Versorgung.

Nachdem klar war, dass eine neue DECT-Lsung freine Installation in der Grenordnung der TU Wiennicht realistisch ist, da DECT heute eher eine Nischen-lsung ist, wurden als Alternativen eine GSM-Lsung so-wie die Variante Voice over WLAN untersucht. Eine Voi-ce over WLAN -Lsung wrde eine flchendeckendeWLAN-Versorgung erfordern, die voice-tauglich ist. Die-se Voice-Tauglichkeit bedeutet einen hheren Mindestpe-gel im WLAN und daraus resultierend ein Vielfaches beider Anzahl der Sender. Zustzlich mssen eine entspre-chende Quality of Service-Realisierung sowie eine Hand-over-Untersttzung im WLAN umgesetzt werden. Diesergibt nach groben Schtzungen Kosten von deutlichmehr als 1 Mio. Euro. Weitere Nachteile einer WLAN-Lsung sind die derzeit geringe Anzahl von Modellen amMarkt, die sowohl GSM als auch WLAN untersttzen,sowie der relativ hohe Energiebedarf eines WLAN-Tele-fons und damit die geringe Akku-Laufzeit.

Auch bei der Variante mit GSM ist die Verkabelungin den Gebuden zur Verbesserung der Empfangsqualittein wichtiger Faktor. Hier wurden Untersuchungen vonzwei Mobilbetreibern durchgefhrt, wobei zur Reduktionder Kosten auf eine UMTS-Versorgung in den Gebudenverzichtet wurde (dafr gibt es in den relevanten Berei-chen sowieso das WLAN). Aus kosten- und vergabe-rechtlichen Grnden wurde dann entschieden, mit demexistierenden A1 Network im Rahmen des BBG-Vertra-ges das bisherige DECT-System abzulsen. Der entspre-chende Vertrag fr die Inhouse-Versorgung (in der RegelVerstrker) wurde bereits vom Rektorat unterzeichnet.Die Detailplanung hat begonnen und die Realisierungsoll bis September 2008 erfolgen.


Da nun mit deutlich mehr Endgerten im A1 Networkzu rechnen ist, musste Ende Mai 2008 der Nummernplanim Handy-Netz erweitert werden. Die so genanntenKurzwahlen sind nun 4-stellig. Die Umstellung vonDECT auf GSM ist fr das 4. Quartal 2008 vorgesehen,sodass mit Jnner 2009 das DECT-System abgeschaltetund aus der Wartung genommen werden kann.

Im A1 Network sind noch einige weitere begleitendeManahmen erforderlich:

In nchster Zeit werden entsprechende Berechtigungs-profile definiert, sodass Dienstgesprche z. B. auf dasHaus (VPN + TU Nebenstellenanlage) beschrnkt wer-den knnen. (Bei Einsatz der Privatgesprchstrennunggibt es fr Privatgesprche natrlich keine Einschrn-kungen).

Die bei Anrufen aus der Nebenstellenanlage der TUWien zu einem A1 Handy signalisierte Rufnummer wirdvon der bisherigen Nummer des Direkt-Links (066467020nnnnn) auf die Festnetznummer der TU Wien ge-ndert (01 58801nnnnn).

Fr Dienstgesprche soll generell nicht mehr die so ge-nannte MSISDN (das ist die interne Nummer, die derSIM-Karte direkt zugeordnet ist), sondern die CorporateNumber, gefolgt von der 4-stelligen Kurzwahl (066460588kkkk) bei den Anrufern angezeigt werden. Damitwird insbesondere auch das Routing bei Rckrufen rich-tig gemacht (bei aus anderen Mobilnetzen portiertenNummern wichtig). Bei Privatgesprchen (Vorausset-zung Privatgesprchstrennung) wird weiterhin dieMSISDN-Nummer angezeigt. Dies ist z.B. auch bei derNummernportierung von anderen Netzbetreibern zur TUWien (bei Neueintritt) oder von der TU Wien zu anderenProvidern (beim Ausscheiden aus dem Personalstand)von Bedeutung.

Die bisher komplett hndische Abwicklung beim Ein-richten/ndern/Entfernen von A1 Network-Teilneh-mern soll ber einen elektronischen Workflow abge-wickelt werden.

Die Verrechnung der (dienstlichen) Gesprchsentgelte(zum Festnetz und den Mobilnetzen von A1 und T-Mobilepraktisch pauschaliert) erfolgt wie schon bisher im A1Network (aber im Gegensatz zum DECT) direkt von Mo-bilkom an die Institute. Dabei knnen die Institute fr dieRechnung auch Kostengruppen definieren, umdie Zuordnung zu Kostenstellen und Innenauf-trgen innerhalb der TU Wien zu vereinfachen.

Verrechnung

Wie bereits eingangs erwhnt, ist das derzei-tige Verrechnungssystem sehr komplex und derAufwand dem damit administrierten Volumennicht angemessen. Die derzeitige Chipkartenl-sung ist von Seiten der Hardware auch beiEricsson selber nicht auf eine neue Nebenstel-lenanlage 1:1 bertragbar. Es wre neben denlaufenden Kosten dafr wieder ein hoher Inves-titionsaufwand erforderlich.

Zustzlich ist das Gesprchsvolumen (in Euro) deut-lich im Sinken begriffen, wie die Entwicklung der letzten5 Jahre anschaulich zeigt. Anzumerken ist, dass im Ver-gleich dazu im A1 Network der TU Wien mit derzeit ca.200 Teilnehmern jhrliche Gesprchskosten von ca.80.000 Euro anfallen. Die Entwicklung zum Mobiltelefonist auch bei der Aufteilung der von der Nebenstellenanla-ge gefhrten Gesprche zu erkennen.

Die Aufteilung in Dienstgesprche und Drittmittelge-sprche ist eigentlich seit dem UG 2002 obsolet, hat aberauch schon vorher, wie den Statistiken leicht zu entneh-men ist, vom Gesprchsvolumen her nie eine wirklicheBedeutung gehabt. Auerdem gibt es so wie schon im-mer die Mglichkeit, pro Organisationseinheit mehrereTelefonentgeltkonten zu fhren.


0,00

50.000,00

100.000,00

150.000,00

200.000,00

250.000,00

2003 2004 2005 2006 2007

DrittmittelPrivatDienst

Entwicklung der Gesprchskosten

0%10%20%30%40%50%60%70%80%90%

100%

2003 2004 2005 2006 2007

AuslandInlandMobil

Verteilung nach Gesprchsanzahl

0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

900,00

1.000,00

1 6 11 16 21 26 31 36 41 46 51 56

Projekte

Einz

elbe

trg

e

Gesamtbetrag: 5407,18

0

20

40

60

80

100

1 6 11 16 21 26 31 36 41 46 51 56

Projekte

Proz

ent

Drittmittelgesprche 2007

Der Privatgesprchsanteil am gesamten Gesprchsvo-lumen ist zwar relativ gesehen recht hoch, absolut gese-hen hlt er sich aber auch in Grenzen (insbesondere inRelation zu dem dafr getriebenen Aufwand). Auch dasPrivatgesprchsvolumen ist im Sinken begriffen, wohlauch ein Zeichen der Mobilisierung der Telefongespr-che. Wenn man die Verteilung der Privatgesprchskostenansieht, erkennt man, dass 50% der Kosten aller Privat-gesprche von ca. 100 Personen getragen werden. Mankann wohl zu Recht vermuten, dass diese Kosten gro-teils durch Auslandsgesprche hervorgerufen werden.Hier hat eine kurze Recherche im Internet ergeben, dasses Calling Cards (z. B. von der Telekom Austria) gibt,die geringere Gesprchskosten aufweisen als der Tarif,den die TU Wien (und damit derjenige, der das Privatge-sprch fhrt) fr Auslandsgesprche im Rahmen des sehr gnstigen BBG-Tarifs zahlen muss.

Ziel eines neuen Verrechnungssystem fr die TU Wienist daher:

Deutliche Vereinfachung und Reduktion des Aufwands.

Ersatzlose Streichung der Chipkartenleser (es gibt nurmehr ganz wenige Stck fr Neuinstallationen oder alsErsatz bei Defekten).

Abrechnung von Privatgesprchen ber das vermutlichexistierende Privathandy, ber ein Diensthandy mit Pri-vatgesprchstrennung oder ber Calling Cards oder berSoftphone zu einem privaten SIP-Provider.

Festlegung eines Gebhrenmodells fr Dienstgesprchemit wenigen Zonen (z. B. Festnetz, Mobilnetze, Aus-land) statt des bisherigen Versuchs, die tatschlich verur-sachten Kosten beim Provider umzulegen, was bei densehr komplexen Gebhrenmodellen der Providersowieso scheitert.

Darstellung der Gesprchskosten auf Basis von Neben-stellen (zusammengefasst zu Telefonentgeltkonten) undnicht mehr nach Chipkarten. Diese Darstellung soll denOrganisationseinheiten primr elektronisch zur Verf-gung gestellt werden.

Da es nicht im Sinn einer gleichen Behandlung der Or-ganisationseinheiten und des Personals wre, unter-schiedliche Abrechnungsprinzipien anzuwenden, jenachdem, mit welcher Telefonanlage man whrend desParallelbetriebs telefoniert, muss das Verrechnungssys-tem groteils bereits vor Installation der neuen Anlagein Betrieb gehen. Ein weiterer Grund ist der Mangel anErsatzteilen. Als Termin ist hier der Beginn des Jahres2009 vorgesehen.

Leistungen einer VoIP-Anlage

Auch wenn die konkreten Anforderungen an eine neueTelefonanlage auf Basis von VoIP noch nicht definiertsind, kann man doch schon einiges dazu sagen, auch berEinschrnkungen:

Man erwartet sich als Grundforderung natrlich,dass man damit telefonieren kann. Bei der Sprach-qualitt sind da Aussagen schon etwas schwieri-ger, da im Gegensatz zum Datenbereich bei derSprachbertragung Verzgerungen oder fehlendePakete ohne weiteres hrbar werden. Es ms-sen daher entsprechende Manahmen, insbeson-dere bei Standorten mit schwcherer Anbindung,gesetzt werden, wie Quality of Service-Priori-sierung von Voice-Paketen und entsprechendeCodecs.

Zu erwarten sind auch entsprechende mehrzeiligeDisplays am Apparat, die unter Umstnden sogarTU-spezifische Informationen liefern knnen.Zumindest erwartet man sich ein Telefonbuch mitSuchfunktion (ein TU-Telefonbuch hnlich denWhite Pages und ein persnliches) sowie entspre-chende Anruflisten ber gefhrte und versumteGesprche.

Eine deutlich bessere Einbindung der Mobiltelefonie solldurch das One-Number-Konzept erfolgen. Dies bedeutetim Wesentlichen, dass man nur mehr eine Nummer (dieNebenstelle am Arbeitsplatz) bekannt gibt. Durch Akti-vierung von unterschiedlichen Erreichbarkeitsprofilenkann man dann z. B. steuern, ob ein Gesprch auf dasMobiltelefon umgeleitet wird oder dieses parallel lutensoll. Natrlich muss es auch einen Sprachspeicher geben(der die empfangene Sprachnachricht vielleicht gleichals E-Mail mit einem Voice-Attachment an die eigeneMail-Adresse schickt). So ist es fr den Anrufer trans-parent, wo man das Gesprch entgegen nimmt.

Bei Fax und Modem ist die Sache schwierig. Durch diemehrmalige Konversion zwischen analogem und digita-lem Signal und zustzliche Verzgerungen sind dieseDienste nur sehr eingeschrnkt mglich. Modem undISDN-Anschlsse wird es wohl nicht mehr geben kn-nen (bei einem flchendeckenden TUNET wohl auchnicht mehr notwendig). Fr Spezialanwendungen wer-den dann wohl Auenleitungen verwendet werden ms-sen. Abgehende Faxe sollten durch entsprechendeLeitungsfhrung so wie bisher mglich sein. Ankom-mende Faxe mssen aber durch einen Fax-Server abge-wickelt werden.


0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

400,00

450,00

500,00

1 51 101 151 201 251 301 351 401 451 501 551 601 651 701

Personen

Einz

elbe

trg

e

Gesamtbetrag: 21.666,49

0102030405060708090

100

1 101 201 301 401 501 601 701

Personen

Proz

ent

Privatgesprche 2007

Eine ganz spannende Frage ist, wie sich eigentlich dasArbeitsverhalten entwickeln wird. Erfolgen Telefonge-sprche am Festapparat oder am Mobiltelefon? Oder be-ntigt jemand gar keinen Festapparat, sondern fhrt alleGesprche ber den PC (mit einem Softphone und einemHrer am PC) oder ber das Mobiltelefon? Und wie wirdhier die Entwicklung ber die Jahre aussehen? Dies istein ganz wichtiger Parameter bei der Dimensionierungder Telefonanschlsse und der dahinter liegenden Infra-struktur und hat damit natrlich gravierende Auswirkun-gen auf die Kosten.

Infrastruktur-Manahmen

Um eine VoIP-Telefonanlage installieren zu knnen,sind eine Reihe von Manahmen in der Datenkommuni-kations- und Stromversorgungsinfrastruktur zu setzen.Der Grund liegt in der anderen Arbeitsteilung bei einemVoIP-System. Das klassische System, wie wir es derzeithaben, besteht aus mehreren Telefonanlagen, an die bereine dedizierte Leitung der Apparat am Arbeitsplatz an-geschlossen ist. ber diese Leitung geht nicht nur dasSprachsignal, sondern erfolgt auch die Stromversorgungdes Apparats (48V). Der Strombedarf ist relativ gering.Die USV-Kapazitt, damit man auch eine gewisse Zeittelefonieren kann, wenn der Strom ausgefallen ist, stehtdirekt bei der Telefonanlage in Form von entsprechendenBatterien.

Ein VoIP-Apparat ist eigentlich nichts anderes als einkleiner PC, der ber einen Ethernet-Anschluss mit demDatennetz verbunden ist, mit einem dedizierten Betriebs-system und vereinfachten Eingabegerten und Anzeigesowie einem Hrer. Dies bedeutet aber fr die Stromver-sorgung, dass man nicht nur den Telefonapparat (denMini-PC) mit Strom versorgen muss (hierfr gibt esdie Power over Ethernet -Technologie IEEE 802.3af),sondern es mssen auch die Switche im Etagenverteiler(der maximal 90 m entfernt sein kann, im Gegensatz zurklassischen Telefonanlage mit ca. 1 km) und das Backbo-ne entsprechend mit USV-Kapazitt versorgt werden. Zu-stzliche Erschwernis ist der je nach Ausstattung desTelefonapparats wesentlich hherere Strombedarf (6-10W).

Daraus folgt, dass die Infrastruktur entsprechend aus-gebaut werden muss, z. B:

Die letzten Thinwire-Bereiche und TP-Provisorien ms-sen bereinigt werden dies ist eng mit den Bauaktivittenan der TU Wien im Zuge des TU Univercity 2015-Pro-jekts verwoben.

Bereiche mit zu geringer Anschlusskapazitt mssen sa-niert werden. (Die VoIP-Telefonapparate haben zwarblicherweise gleich einen Ethernet-Switch eingebaut,an den man einen PC oder Laptop anschlieen kann, nursollte man sich dies eher fr Notflle reservieren.)

Es mssen viele zustzliche Switche in den Etagenvertei-lern installiert werden. Die 5000-6000 Telefonanschls-se enden ja jetzt nicht mehr direkt in der Telefonanlage,sondern auf einem Ethernet-Switch im Etagenverteiler.Dafr muss der Platz vorhanden sein oder erst geschaffenwerden. Zustzlich muss die entsprechende (unterbre-chungsfreie) Stromversorgung zur Verfgung stehen.Wir denken derzeit an eine berbrckungszeit von einerStunde. Unter Umstnden muss die Klimatisierung, ins-besondere bei den Batterien, deren Lebensdauer ganzwesentlich von der Umgebungstemperatur abhngt,verbessert werden.

Auch das Backbone muss entsprechend VoIP-fhig ge-macht werden, sofern es das nicht bereits ist. Dies bedeu-tet unter anderem schrfere Bedingungen bei derRedundanz und Ausfallsicherheit und Quality of Service-Priorisierung fr Voice-Pakete.

Nach den derzeitigen Kostenschtzungen werden dieInvestitionen in die Infrastruktur ca. 50% der gesamtenProjektkosten betragen.

Zusammenfassung

Infolge der zunehmenden Digitalisierung aller Kom-munikationstechniken wachsen Daten- und Telefonnetzezu einem Netz zusammen. Telefongesprche stellen dannnur mehr eine weitere Form des digitalen Datenaus-tauschs dar. Mit dem Projekt TUphone trgt die TUWien dieser Entwicklung Rechnung. Wir werden laufendber die Migrationsschritte informieren.

Web: www.zid.tuwien.ac.at/kom/telefonie/tuphone/


Neu als Campussoftware:

Acronis True Image Echo fr Workstation und ServerDie Acronis True Image Echo ist die optimale Lsung fr zentral verwaltete Datensicherung von PCs, Work-stations und Notebooks im Netzwerk von Instituten sowie Home Office. Das Backup kann lokal und auf vielfltige Speichermedienabgelegt werden. Die Wiederherstellung erfolgt auf das selbe System oder mit dem optionalen Zusatzmodul Acronis UniversalRestore auf abweichende Hardware und in eine virtuelle Maschine. Auf den verbundenen Systemen werden Backup-Aufgabenper Fernwartung gestartet und berwacht.

Der fr Windows ist am besten geeignet fr Institute, die nur wenige Windows-Server an einemOrt und mit begrenztem IT-Personal betreiben. Um einem System- und Datenausfall dieser wichtigen Server vorzubeugen und ei-nen institutsweiten Totalschaden zu vermeiden ist der Server fr Windows konzipiert worden. Er bietet umfassenden System-schutz und kann Windows-Server jederzeit wiederherstellen. So knnen Ausfallzeiten minimiert werden.

ZID-Day 08:eine NachleseIris Macsek

Am 2. April 2008 fand im Freihaus im Gangbereich vor dem ZID der erste ZID-Day statt, einePrsentation der Services des ZID in Form einer Ausstellung.

Im September letzten Jahres wurde die Idee geboren, imZID einmal einen Tag der offenen Tr zu veranstalten.Diese Idee, von einigen sofort mit Begeisterung aufgenom-men, entwickelte sich dann im Laufe einiger Wochen zu ei-nem konkreten Projekt. Rasch konnten wir uns auf einefachbezogene Veranstaltung ohne reierische Aufhnger ei-nigen, die an Institutsangehrige und Studierende gerich-tet praktisch alle Services des ZID abdecken sollte. Zielwar es, unser derzeitiges Angebot, aber auch unsere Zu-kunftsplne, im eigenen Haus noch besser bekannt zu ma-chen, und Besucher aufzufordern, sich mit offenen Fragenund Problemen an die Verantwortlichen zu wenden.

Irmgard Husinsky und ich wurden mit der Gesamtor-ganisation betraut, einer Arbeit, die wir sofort mit gro-em Enthusiasmus begannen. Primr musste natrlichfestgelegt werden, welche Services in welcher Form pr-sentiert werden. Dabei durften wir selbst erleben, wie sehrein derartiges Vorhaben praktisch alle unsere Kolleginnenund Kollegen begeisterte und wie viel an Ideen sie ein-brachten. Wir bedanken uns an dieser Stelle sehr fr ihregroartige Untersttzung!

Auerdem mussten viele offene Fragen geklrt werden und nicht zuletzt auf ein nicht sehr umfangreiches Bud-get Rcksicht genommen werden: Welche (Messe)-Stn-de sollten wir einsetzen, machen wir die Plakate selbst,wie sollte die Mblierung aussehen, mittels welcher Me-dien laden wir die TU-Angehrigen ein, bieten wirSnacks und Getrnke an?

Da wir frhzeitig mit allen Vorbereitungen begonnenhatten, brach in den Tagen vor dem ZID-Day kaum ber-triebener Stress und Hektik aus. Wie geplant stellte amSonntag drei Tage vor dem ZID-Day die Firmastand&co unsere fnfzehn Stnde auf. Am Tag zuvorfolgte dann die Mblierung. Die Plakate selbst konntenwir erst am Morgen des 2. April, des ZID-Days 08, be-festigen, da wir Vandalismus keine Chance geben woll-ten. Auch die fr alle Stnde unterschiedliche Konfigura-tion der Netzwerkdosen konnte erst zu diesem Zeitpunktaktiviert werden.

Pnktlich um 9:00 Uhr waren alle Stnde fr Kundengerstet:


Arbeitsplatz-Software

Helmut Mayer informierte Besucher ber Software,die ber den ZID von berechtigten Universittsbedienste-ten lizenziert werden kann, und bot eine Online-Bestell-mglichkeit an. Etliche Interessierte erkundigten sichnach neuen Releases.

Goodie Domain Service

Hier gab es die Mglichkeit, Open Source Softwarevom GDS-Server herunterzuladen und auf CD/DVD zubrennen. Hauptschlich waren Linux-Distributionen ge-fragt. Rudolf Ladner beantwortete Fragen zum Angebotdes Goodie Domain Services.

High Performance Computing

An diesem Stand fhrten Ernst Haunschmid und JosefBeiglbck interessierten Besuchern CAE- sowie Gaussian-Anwendungen vor. Einige Institutsangehrige, vor allemSystemadministratoren, die derartige Projekte derzeit pla-nen, nutzten die Gelegenheit, sich vor Ort zu informie-ren, insbesondere auch als Entscheidungsgrundlage, obsie ihr jeweiliges Projekt auf einem eigenen Rechner oderauf den ZID-Applikationsservern rechnen sollen.

Internet Services

Hier wurden klassi-sche Internet Services,wie das Mailbox- undWebspace-Service sowiealles rund um den Studen-tenaccount, prsentiert.Studierende konnten Wis-senswertes ber Internet-Rume, Kiosk- und Info-Terminals sowie ber Da-tentankstellen erfahren.An Institutsangehrigerichtete sich die Informa-tion ber die vom ZIDangebotene Untersttzungfr Lehrveranstaltungen,Kurse, Tagungen undKonferenzen. Die Stand-betreuer gaben an, bei Wiederholung der Veranstaltungwolle man verdeutlichen, dass an diesem Stand weniger diePrsentation der unter Studierenden grtenteils bekann-ten Services im Vordergrund stehe, sondern man vielmehreine Anlaufstelle fr etwaige Probleme mit diesen Servicesdarstelle.

IT Online-Kurse

Hier konnte man ganztgig aus dem breiten Spektrumder vom ZID online angebotenen Kurse aus dem Bereichder Informationstechnologie auswhlen und ausprobieren.Jadwiga Donatowicz beriet interessierte Besucher und in-formierte ber Bestellgepflogenheiten. Es war festzustel-len, dass die einzelnen Besucher vllig unterschiedlichesVorwissen um die IT Online-Kurse des ZID mitbrachten.Siehe dazu auch Seite 34, IT-Webkurse.

Mobiles Arbeiten im TUNET

Hier informiertenJohann Kainrath undWilhelm Koch Besu-cher ber VPN undWLAN im TUNET.Einigen Besuchernwurde bei technischenProblemen mit ihrenKonfigurationseinstel-lungen geholfen. Dassdie TU seit einemknappen Jahr aneduroam teilnimmt,das ermglicht, dassmit den Zugangsdatendes Heimatnetzwerks


die WLAN-Infrastruktur anderer Universitten verwendetwerden kann, wurde von allen begrt. Grundstzlich be-urteilten die Besucher die vom ZID angebotenen Connec-tivity-Mglichkeiten als sehr zufriedenstellend.

Service Center

Am Stand des Service Centers verkauften PhilippKolmann und sein Team IT-Handbcher, nahmen Feed-back entgegen und fungierten wie auch sonst immer als erste Anlaufstelle des ZID fr allgemeine Ausknfte,aber auch fr Beratungen bei TU Wien-spezifischenEDV-Problemen aller Art.

Services TU Bibliothek

Fritz Neumayer und Maria Strau (beide Universitts-bibliothek) beantworteten Fragen rund um das Biblio-thekssystem Aleph. Etliche Institutsangehrige lieensich ber den Einsatz von Aleph fr Institutsbibliothekenberaten und das Aleph-Client-Programm live vorfhren(siehe auch Artikel auf Seite 23). In der Zwischenzeitkonnten einige Institutsbibliotheken als neue Aleph-Clients eingerichtet werden.

Studentensoftware

Hier boten Gerald Wegmayer (LMZ) und BernhardSimon stark verbilligte Software fr Studenten der TUWien zum Ausprobieren und zum Kauf an.

Systempflege

Rudolf Sedlaczek informierte Besucher an diesemStand ber Mglichkeiten der Systempflege und Fernun-tersttzung fr Institutsrechner. Auerdem sollten Insti-tutsangehrige auf das fr Institute kostenlose Serviceder IT-Beratung vor einer Hardware-Anschaffung auf-merksam gemacht werden.

Telekommunikation

Regen Andrang konnte die Prsentation Telefonie ander TU Wien heute und morgen verzeichnen. VoIP-Telefonie wurde von Friedrich Blser und Thomas Eignerlive mittels zweier Hardphones und eines Softphones de-monstriert. Auerdem informierten sich natrlich vorallem Institutsangehrige ber die bevorstehende Er-neuerung der TU-Telefonanlage, im Speziellen ber Fea-tures, die die neue Anlage aufweisen wird (siehe auchden Artikel auf Seite 12). Zahlreiche Fragen musstenauch zur bevorstehenden Ablse des DECT-Systemsdurch GSM beantwortet werden.

TUNET Infrastruktur

Mittels einiger exemplarischer Komponenten von Netz-werkinfrastruktur, wie sie auf der TU im Einsatz sind,


wurde hier von Wolfgang Meyer Einblick in die TUNET-Infrastruktur gewhrt. Hostmasterarbeit, Einstieg und Ab-fragemglichkeiten in der TUNET-Datenbank, wurdemehrmals von Gerda Bruckner demonstriert.

TU Wien Informationssysteme

Edmund Dvorak bot einen berblick ber das beste-hende System TUWIS++, in welchem Informationen zuInstituten, Lehrveranstaltungen und Studienplnen abge-bildet sind, und zustzlich Studierende und Institutsange-hrige nach gltiger Validierung diverse personalisierteFunktionen (Prfungsanmeldung, LVA-Bewertung, Ge-haltsinformationen etc.) nutzen knnen. Parallel dazu gabAndreas Knarek Ausknfte ber das in Entwicklung be-findliche System TISS, welches TUWIS++ ablsen soll(siehe auch Seite 3).

White Pages

Hier demonstrierte JohannKlasek den Umgang mit denpersnlichen Kontaktin-formationen in den WhitePages. Schwerpunkte wur-den auf die ThemenAdressmanager, Daten-verantwortlichkeit, Gene-rische Adresse versus.Zustelladresse und TU-Passwort gesetzt. Auer-dem wurde den zahlreichenBesuchern umfangreichesWissen ber die vom ZIDangebotenen Anti-Spam-Manahmen sowie ber per-snliche Konfigurations-mglichkeiten vermittelt.

Museum

Regen Zulauf konnte das eigens fr diesen Tag einge-richtete Museum verzeichnen. Exponate zum ThemaSpeichermedien: Von der Lochkarte zum USB-Sticklockten viele Besucher. Vor allem diejenigen, die demStudentenalter bereits entwachsen sind und die rasanteEntwicklung der letzten Jahrzehnte selbst miterlebt hatten,erfreuten sich am Anblick von Lochstreifen, Lochkarten,Magnetbndern und Floppy-Disketten (8", 5.25" und 3.5").

Auerdem wurde eine bersicht ber smtliche Syste-me an den Rechenzentren der TU seit 1964 geboten: an-gefangen bei der Digitalrechenanlage IBM 7040 (ab1964), dem Analogrechner EAI 680 (ab 1969) und demProzessrechner IBM 1800 (ab 1970) bis zu den moder-nen Clusterlsungen (SUN Cluster ab 2005, IBM ICP5ab 2006).


Fhrung

Gut besucht waren auch unsere vier Mal angebotenenFhrungen, beginnend im ZID-Museum, durch den Maschi-nenraum und endend im NOC (Network Operation Cen-ter). Peter Berger begrte die insgesamt mehr als hundert

Gste im Museum und ffnete die sonst geschlossenen T-ren in den Maschinenraum, wo er berblicksartig Erklrun-gen zu unseren Systemen abgab. Fragen der Besucher vorwiegend Mitarbeiter der TU Wien betrafen hauptsch-lich Sicherheitsaspekte. Peter Hasler demonstrierte, mit wel-chen Methoden bzw. Tools die ZID-Mitarbeiter dieprimren Aufgaben des NOC, nmlich Erkennen und Erst-analyse einer Strung, erfllen.

Im Rckblick ist der ZID-Day 08, unser erster ZID-Day, als absolut gelungene Veranstaltung zu werten. Al-les hat wie geplant funktioniert. Abgesehen von der Pr-sentation des ZID nach auen, durften wir auch nachinnen hin positive Impulse eines gemeinsamen Projektserleben.

Das Ziel, das Wissen der TU-Angehrigen ber unsereServices zu erhhen, haben wir sicherlich erreicht. Zudemerhielten wir von so vielen Seiten positives Feedback, dasses eine Wiederholung des ZID-Days im nchsten Jahr ge-ben wird, allerdings zu einem anderen Zeitpunkt, und na-trlich mit einigen nderungen. Gedacht ist an denBeginn des Wintersemesters 2009/10. Damit wollen wiruns verstrkt auch an Erstsemestrige wenden.

Der ZID freut sich auf Ihren Besuch im nchsten Jahr aber Sie knnen natrlich jederzeit mit uns in Kontakttreten. Wenden Sie sich an unser engagiertes ServiceCenter. Dort wird man Ihnen gerne bei allen Ihren TUWien-bezogenen EDV-Anliegen weiterhelfen!


oben: Speichermedien unten: Steckbrett fr Analogrechner

GemeinsameBibliotheks-SoftwareAleph an der TUFritz Neumayer, Maria StrauUniversittsbibliothek

Derzeit verwenden ca. 30 Institute oder Abteilungen fr die Verwaltung ihrer Institutsbibliothekdie Bibliotheks-Software Aleph weitere Interessenten sind willkommen.

Fr die Verwaltung der Bibliotheksbestnde an Institu-ten werden an der TU unterschiedliche Programme, Tools,Listen, Verzeichnisse etc. eingesetzt (selbstentwickelte In-stitutsdatenbanken, Excel, Access und vieles mehr).

Bei diesen lokalen Anwendungen ergeben sich (zu-mindest) folgende Probleme:

Bcher, die ohnehin schon im TU-Bibliothekskatalog er-fasst sind, werden am Institut erneut bearbeitet,

Pflege und Korrektur der Daten wird ebenfalls doppeltgeleistet,

lokale Systeme sind oft nur an einem Rechner installiertund bieten daher nur sehr beschrnkten Zugriff, ...

Aleph als einheitliche Lsung

Mit zwei Funktionen von Aleph knnen die wichtigs-ten Bedrfnisse der Institute abgedeckt werden:

1. Exemplarverwaltung Standortverwaltung(Regalnummern, Systematik, Raumnummer etc.)

2. Entlehnung

Vorteile

keine Doppelerfassung

Standorte im Online-Katalog sichtbar und suchbar

entlehnte Bcher im Online-Katalog sichtbar

Vormerkung auf entlehnte Bcher

berblick ber entlehnte Bcher

keine eigene Benutzererfassung fr die Entlehnun

Documents

ZIDline 18