Post on 17-Sep-2018
transcript
SollspezifikationProjekt
derWIRTSCHAFTSUNIVERSITÄT WIEN
Grobkonzept Projekt
INHALTSVERZEICHNIS
1 EINLEITUNG.....................................................................................71.1 Auftrag........................................................................................................71.2 Warenzeichen..............................................................................................71.3 Redaktionelle Behandlung der Geschlechtlichkeit........................................7
2 PROJEKTDURCHFÜHRUNG.................................................................92.1 Ziele des Projekts........................................................................................92.2 Projektpartner...........................................................................................112.3 Projektorganisation....................................................................................12
2.3.1 Lenkungsausschuß...............................................................................142.3.2 Kernteam.............................................................................................14
2.4 Projektablauf.............................................................................................152.4.1 Sitzungen des Kernteams.....................................................................152.4.2 Sitzungen des Lenkungsausschusses....................................................152.4.3 Einbezogene Organisationseinheiten....................................................15
2.4.3.1 Einbezogene Institute/Abteilungen.................................................152.4.3.2 Einbezogene Verwaltungsstellen und sonstige Stellen....................162.4.3.3 Übersicht über die Interview- und Abstimmungstermine.................16
2.4.4 Präsentationen und Workshops............................................................192.4.5 Plakataktion.........................................................................................20
3 METHODIK UND VORGEHEN............................................................213.1 Die Phasen der Konzeption........................................................................213.2 Architektur integrierter Informationssysteme.............................................23
3.2.1 Hintergrund und Idee...........................................................................243.2.2 Die ARIS-Ebenen..................................................................................253.2.3 Die ARIS-Sichten...................................................................................26
3.3 Grundsätze ordnungsmäßiger Modellierung...............................................33
3.4 Projekt-/Modellierungskonventionen..........................................................363.4.1 Verwendung aufbauorganisatorischer Elemente...................................363.4.2 Aufbau der Modellhierarchie.................................................................36
3.4.2.1 Ablaufbeschreibung versus Funktionalitätsbeschreibung................36
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 171
INHALTSVERZEICHNIS
3.4.2.2 Bildung von Szenarien....................................................................373.4.2.3 Integration von Daten und Funktionalitäten....................................37
3.4.3 Detaillierungsgrad................................................................................373.4.3.1 Datenmodelle.................................................................................373.4.3.2 Prozeßmodelle................................................................................37
3.4.4 Übersicht der Methodenverwendung....................................................38
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“........................434.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung...........43
4.1.1 Übersicht..............................................................................................454.1.2 Studien.................................................................................................47
4.1.2.1 Zulassung Studium.........................................................................484.1.2.2 Rückmeldung Studium...................................................................514.1.2.3 Zusatzstudium/Wechsel des Studiums............................................534.1.2.4 Beendigung Studium......................................................................544.1.2.5 Erstellung Diplomzeugnis...............................................................56
4.1.3 Lehrveranstaltungen............................................................................574.1.3.1 Planung von Lehrveranstaltungen..................................................584.1.3.2 Aufnahme von Lehrveranstaltungen...............................................624.1.3.3 Lehrveranstaltungen administrieren...............................................65
4.1.4 Prüfungen............................................................................................664.1.4.1 Planung von Prüfungen...................................................................674.1.4.2 Leistungsfeststellung......................................................................69
4.1.5 Diplomarbeiten/Dissertationen.............................................................724.1.5.1 Diplomarbeiten/Dissertationen vereinbaren....................................744.1.5.2 Diplomarbeiten/Dissertationen betreuen........................................754.1.5.3 Diplomarbeiten/Dissertationen abschließen....................................76
4.1.6 An- und Abmeldungen..........................................................................774.1.6.1 LV-Anmeldungen............................................................................784.1.6.2 Prüfungsanmeldungen....................................................................804.1.6.3 Abmeldungen.................................................................................82
4.1.7 Anerkennungen....................................................................................844.1.7.1 Anerkennungen erzielen.................................................................854.1.7.2 Nostrifikationen erzielen.................................................................87
4.1.8 Abrechnungen......................................................................................884.1.9 Evaluierung der Lehre..........................................................................89
4.1.9.1 Beurteilung von Lehrveranstaltungen.............................................914.1.9.2 Arbeitsberichte erstellen................................................................92
4.1.10 Allgemeine Funktionen.......................................................................934.1.10.1 Chipkartenverwaltung..................................................................934.1.10.2 Hörsaaladministration..................................................................954.1.10.3 Stammdatenverwaltung...............................................................95
Seite 4 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.10.4 Auswertungen/Ausdrucke.............................................................964.1.11 Allgemeine Systemfunktionen – Grundfunktionalitäten.......................97
4.2 Anregungen der verschiedenen Organisationseinheiten...........................1004.2.1 Studien- und Prüfungsabteilung..........................................................1004.2.2 Institute/Abteilungen..........................................................................1014.2.3 Studiendekanat..................................................................................108
4.3 Konzeptionelles Datenschema.................................................................1104.3.1 Intention.............................................................................................1104.3.2 Semantische Datenmodelle................................................................110
4.3.2.1 Studium.......................................................................................1114.3.2.2 Studienplan..................................................................................1134.3.2.3 Lehrveranstaltung........................................................................1154.3.2.4 Vorlesungsverzeichnis..................................................................1164.3.2.5 Prüfungen....................................................................................1164.3.2.6 An- und Abmeldung......................................................................1184.3.2.7 Diplomarbeiten und Dissertationen..............................................1194.3.2.8 Anerkennung................................................................................1204.3.2.9 Abrechnung..................................................................................1214.3.2.10 Hörsaalverwaltung.....................................................................1224.3.2.11 Evaluierung................................................................................1234.3.2.12 Adresse......................................................................................124
5 MENGEN- UND WERTGERÜST........................................................125
6 DATENSCHUTZ UND DATENSICHERHEIT.........................................1276.1 Schutzbedarfsermittlung..........................................................................127
6.1.1 Schutzstufenkonzept..........................................................................1286.1.1.1 Stufe I..........................................................................................1286.1.1.2 Stufe II.........................................................................................128
6.1.2 Schutzbedarf im Projekt „2gether“.....................................................1306.2 Chipkarten...............................................................................................1316.3 Internet...................................................................................................135
7 MIGRATIONSKONZEPT..................................................................1377.1 Allgemeines.............................................................................................1377.2 Ablöse STEPDB und INSTDB.....................................................................138
7.2.1 Datenübernahme...............................................................................1387.2.2 Anmerkungen zur Synchronisation von Datenbanken.........................139
7.3 Zeitlicher Aspekt.....................................................................................1397.4 Schnittstellen..........................................................................................140
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 171
INHALTSVERZEICHNIS
7.4.1 Vorlesungsverzeichnis........................................................................1407.4.2 Hörsaalbelegung................................................................................141
7.5 Übergangszeitraum.................................................................................1417.5.1 Historische Daten der Studenten........................................................1417.5.2 Selbstbedienungsfunktionen...............................................................142
7.6 Zeitlicher Ablauf......................................................................................1427.6.1 Datenüberleitung...............................................................................1447.6.2 Stammdatenerfassung.......................................................................1447.6.3 Phase 1..............................................................................................1457.6.4 Weitere Phasen..................................................................................145
7.7 Zuordnungen alte/neue Datenbank..........................................................145
8 WIRTSCHAFTLICHKEITSBETRACHTUNG..........................................1518.1 Anmerkungen zum Nutzen des neuen Systems........................................151
8.1.1 Qualitative Verbesserungen................................................................1528.1.2 Quantitativ meßbare Verbesserungen................................................153
8.1.2.1 Studien- und Prüfungsabteilung....................................................1558.1.2.2 Institute/Abteilungen....................................................................157
8.2 Kosten-/Nutzenrechnung..........................................................................162
Anhang A: VerzeichnisseAnhang B: DatenfelderAnhang C: ARIS-Datenbank/Modell-ListeAnhang D: ARIS-Datenbank/wichtigste ModelleAnhang E: ARIS-Datenbank/AuswertungenAnhang F: Wirtschaftlichkeitsbetrachtungen (ZID)
Seite 6 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
1 EINLEITUNG
1.1 AuftragAm 27. November 1997 erteilte das
Zentrum für Informatikdienste der Wirtschaftsuniversität Wien
im Auftrag der Vergabekommission der
Secur-Data Betriebsberatungsgesellschaft
gemäß deren Angebot vom 30. Oktober 1997 den Zuschlag für die im offenen Verfahren (in der öffentlichen Ausschreibung) ZID/SW1/97 enthaltenen Leistungen mit der Auflage, eine herstellerneutrale Sollspezifikation zu erstellen.
Gemäß deren Angebot vom 4. Februar 1998 wurde die Secur-Data beauftragt, über den vereinbarten Projektumfang hinaus 6 weitere Institute bzw. Abteilungen sowie verstärkt das Zentrum für Auslandsstudien und die Hochschülerschaft in das Projekt einzubinden; gleichzeitig wurde die Secur-Data verpflichtet, insgesamt 4 Workshops zu veranstalten, an denen die Projektergebnisse vorgestellt und diskutiert werden konnten.
Beide Aufträge wurden am 15. April 1998 mit Übergabe des vorliegenden Sollkonzepts abgeschlossen. Die Abnahme durch den Lenkungsausschuß ist für den 30. April 1998 vorgesehen.
1.2 WarenzeichenDie Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenzeichen u.s.w. in diesem Dokument berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, daß solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären.
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
1.3 Redaktionelle Behandlung der Geschlechtlichkeit
Aus Gründen der Vereinfachung und damit zur Verbesserung der Lesbarkeit des Textes wurde an den Stellen, an denen von Personen die Rede ist, teilweise auf die explizite Nennung beider Geschlechter verzichtet. Wenn also beispielsweise von Mitarbeitern gesprochen wird, sind damit Mitarbeiter beiderlei Geschlechts gemeint. Es soll somit in keinem Fall der Gleichbehandlungsgrundsatz, so wie er im UOG ’93 oder auch in der Satzung der Wirtschaftsuniversität Wien (WU Wien) formuliert wird, untergraben werden.
Seite 8 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
2 PROJEKTDURCHFÜHRUNG
2.1 Ziele des ProjektsZiel des Projekts war die Erstellung einer detaillierten Sollspezifikation auf Basis des Grobkonzepts, das unter Federführung des Zentrums für Informatikdienste der Wirtschaftsuniversität Wien erstellt wurde.
Die Sollspezifikation soll der WU einerseits Entscheidungsgrundlagen über eine schrittweise Implementierung des Systems liefern, andererseits als Leistungsverzeichnis für eine weitere Ausschreibung betreffend Entwicklung und Implementierung des neuen Systems verwendet werden.
Bei der fachlichen Konzeption des Systems „2gether“ zur Unterstützung der Studien- und Prüfungsverwaltung wurde größtmögliches Gewicht auf die Offenheit und Transparenz aller Projektschritte sowie die Einbeziehung möglichst vieler WU-Mitarbeiter gelegt. Dies liegt zum einen in dem besonderen Aufbau einer Universität mit ihrer eher netzwerkartigen Struktur und zum anderen in den Vorbehalten der Mitarbeiter begründet, die zum Teil aus vorherigen, anderen Projekten stammen.
Daher ist es eine wesentliche Aufgabe des Projektteams gewesen, Verständnis für bzw. Klarheit über das zu erwartende neue System letztlich bei allen WU-Mitarbeitern zu erreichen. Die große Zahl an Interviews, respektive Interviewpartnern, ist ein Indiz hierfür.
Schließlich münden die unterschiedlichen, teilweise diametral gegenüberstehenden Anforderungen der Interviewpartner und Workshopteilnehmer in dem in den Bericht integrierten Anforderungskatalog.
Die bei der Wirtschaftsuniversität Wien vorgefundene Ausgangssituation sowie das vom „2gether“-Projekt erwartete Verbesserungspotential ist in Abbildung 1 festgehalten.
Erstellt gemeinsam mit 15. April 1998 Seite 9 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Abbildung 1: Ist-Situation und Ziele des Projektes „2gether“
Des weiteren waren folgende Aspekte des Studien- und Prüfungsverwaltung zu berücksichtigen:
Seite 10 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Institute Studien- und Prüfungsabteilung Quästur
Rechts- undOrganisations-
abteilungStudenten
PowerPhone/PowerCard/WWW
WU - FIS
Studiendekanat
Studenten/Zulassung
Studien-plan
Lehrveran-staltungen
Vorlesungs-verzeichnis
An- undAbmeldung
Hörsaal-verwaltung
Evaluierungder Lehre
Prüfungs-verwaltung
Diplom-arbeiten/Dis-sertationen
Anerken-nungen
Abrech-nung
Studien- und Prüfungs-verwaltungssystem
Abbildung 2: Aspekte der Studien- und Prüfungsverwaltung in „2gether“
2.2 ProjektpartnerDie Durchführung des Projekts wurde der Firma Secur-Data Betriebsberatungsgesellschaft m.b.H. übertragen, die vornehmlich ihre (auf die Abwicklung komplexer IT-Projekte bezogene) Management-Kompetenz einbrachte, sich jedoch der Modellierungskompetenz des ARIS-Herstellers IDS Prof. Scheer GmbH bediente, der als Subunternehmen beigezogen wurde. Der vorliegende Bericht ist das Produkt dieser engen Partnerschaft sowie der engen Zusammenarbeit mit allen involvierten Stellen der Wirtschaftsuniversität, für deren engagiertes Mitwirken wir an dieser Stelle herzlichen Dank sagen wollen.
Erstellt gemeinsam mit 15. April 1998 Seite 11 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Abbildung 3: Partner im Projekt „2gether“
2.3 ProjektorganisationDie Aufbauorganisation des Projekts ist in Abbildung 4 dargestellt.
Seite 12 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Abbildung 4: Projektaufbauorganisation
2.3.1 LenkungsausschußAls oberstes Entscheidungsgremium wurde ein Lenkungsausschuß gebildet, der sich wie folgt zusammensetzte:
Erstellt gemeinsam mit 15. April 1998 Seite 13 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Herr Prof. Dr. F. Scheuch (Vizerektor), der später von Prof. Dr. H.-R. Hansen (Rektor) abgelöst wurde;
Herr Dr. T. Herzog (Universitätsdirektor); Herr Prof. Dr. W. Janko (Studienkommission BWL); Frau R. Pieler (Dienststellenausschuß); Herr Mag. C. Ragacs (Kommission für Infrastruktur); Herr P. Hysek (Vorsitzender der Hochschülerschaft); Herr Dr. G. Miksch (Leiter ZID); Herr H.-J. Pollirer (GF der Secur-Data); Herr Dipl.-Kfm. R. Heib (IDS Projektkoordinator); Herr E. Klein (Projektleiter).
2.3.2 KernteamZur Koordination der laufenden Arbeiten wurde das Kernteam eingesetzt, dem folgender Personenkreis angehörte:
Herr Dr. G. Miksch (Leiter ZID), Frau Mag. M. Lenk (ZID Projektkoordinatorin), Herr E. Klein (Secur-Data Projektleiter)
sowie fallweise
Herr Dipl.-Kfm. R. Heib (IDS Projektkoordinator), Herr M. Kopp (IDS), Herr M. Herb (IDS), Herr C. Hüsselmann (IDS), Herr H. Wotzel (Secur-Data).
Seite 14 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
2.4 Projektablauf
2.4.1 Sitzungen des KernteamsDas Kick-off-Meeting des Kernteams fand am 18. November 1997 statt. In weiterer Folge wurden insgesamt 13 Sitzungen des Kernteams mit wechselnder Beteiligung abgehalten.
2.4.2 Sitzungen des LenkungsausschussesDer Lenkungsausschuß trat am 1. Dezember 1997 zu seiner konstituierenden Sitzung zusammen. Weitere Sitzungen folgten:
2. Sitzung am 30. Jänner 1998; 3. Sitzung am 5. März 1998; 4. Sitzung am 30. März 1998.
Nach Abgabe des vorliegenden Sollkonzepts am 15. April 1998 wird der Lenkungsausschuß zu seiner 5. und letzten Sitzung am 30. April 1998 zusammentreten.
2.4.3 Einbezogene Organisationseinheiten
2.4.3.1 Einbezogene Institute/AbteilungenIm Rahmen der 1. Sitzung des Lenkungsausschusses am 1. Dezember 1997 wurden folgende Institute bzw. Abteilungen als Interviewpartner ausgewählt:
Romanische Sprachen Bürgerliches Recht Warenhandel Wirtschaftsinformatik
Im Rahmen der 2. Sitzung des Lenkungsausschusses am 30. Jänner 1998 wurde beschlossen, 6 weitere Institute bzw. Abteilungen in die Erhebungs- bzw. Abstimmungsgespräche einzubeziehen. Folgende Institute bzw. Abteilungen wurden ausgewählt:
Englische Sprache/Wirtschaftssprache
Erstellt gemeinsam mit 15. April 1998 Seite 15 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Finanzierung & Finanzmärkte Betriebswirtschaftliche Steuerlehre Wirtschafts- & Sozialgeschichte Personalwirtschaft Politische Ökonomie
Die Auswahl der beteiligten Institute und Abteilungen erfolgte seitens der WU und wurde nach dem Zufallsprinzip vorgenommen. Dabei wurden zunächst Größenklassen anhand des administrativen Aufwandes der jeweiligen Bereiche gebildet; innerhalb dieser Größenklassen wurden zufällige Einheiten ermittelt, die – nach deren Zustimmung – in den Untersuchungsbereich aufgenommen wurden.
2.4.3.2 Einbezogene Verwaltungsstellen und sonstige StellenNeben den genannten Instituten bzw. Abteilungen war geplant, folgende Verwaltungs- bzw. übrige Stellen einzubeziehen:
Studien- und Prüfungsabteilung Zentrum für Informatikdienste Büro der Studiendekane Quästur Rechts- und Organisationsabteilung
Im Rahmen der 2. Sitzung des Lenkungsausschusses am 30. Jänner 1998 wurde beschlossen, 2 weitere Verwaltungs- bzw. sonstige Stellen verstärkt einzubeziehen:
Hochschülerschaft Zentrum für Auslandsstudien
2.4.3.3 Übersicht über die Interview- und AbstimmungstermineIm Rahmen der Projektdurchführung wurden folgende Interview- und Abstimmungstermine wahrgenommen:
Datum Stelle Interviewpartner26.11.1997
Romanische Sprachen
I. Hubmann, E. Lavric, N. Riehs
Seite 16 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Datum Stelle Interviewpartner3.12.1997 Wirtschafts-
informatikM. Fritscher, C. Drimmel, O. Kump
3.12.1997 Wirtschafts-informatik
A. Schüller, M. Kaukal
3.12.1997 Wirtschafts-informatik
R. Flatscher, R. Brandtweiner
3.12.1997 Wirtschafts-informatik
M. Fritscher
4.12.1997 Wirtschafts-informatik
A. Schuster
4.12.1997 Wirtschafts-informatik
A. Scharl
4.12.1997 ZID R. Barthauer, J. Langitz4.12.1997 Wirtschafts-
informatikO. Kump, C. Ragacs
9.12.1997 Warenhandel T. Reutterer9.12.1997 Romanische
SprachenI. Hubmann, E. Lavric, N. Riehs
9.12.1997 Wirtschafts-informatik
R. Flatscher
10.12.1997
Wirtschafts-informatik
O. Kump
10.12.1997
Wirtschafts-informatik
Prof. Hansen
11.12.1997
Warenhandel H. Kotzab, B. Gasner
12.12.1997
ZID C. Kaiser
12.12.1997
Bürgerliches Recht W. Blocher
16.12.1997
STAB W. Axterer, H. Spitzer, M. De Pellegrin
17.12.1997
Büro d. Studiendekane
G. Zihr
17.12.1997
STAB W. Axterer, H. Spitzer, temporär verschiedene Mitarbeiter
Erstellt gemeinsam mit 15. April 1998 Seite 17 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Datum Stelle Interviewpartner18.12.1997
STAB W. Axterer, M. De Pellegrin
18.12.1997
Büro d. Studiendekane
G. Zihr
8.1.1998 Warenhandel H. Kotzab12.1.1998 Bürgerliches Recht W. Martetschläger13.1.1998 ÖH P. Hysek14.1.1998 Büro d.
StudiendekaneH. Gabler, Prof P. Hackl (tw.), G. Sedlacek
27.1.1998 Quästur G. Krotky28.1.1998 Zentrum für
AuslandsstudienF. Brück, T. Friedlmayer
29.1.1998 ÖH S. Schmidt22.1.1998 ZID J. Loibl10.2.1998 Rechts- und
Organisationsabteilung
G. Mautner
11.2.1998 ZID J. Loibl24.2.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer26.2.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer3.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer4.3.1998 Quästur; Rechts-
und Organisationsabteilung
G. Krotky; G. Mautner
4.3.1998 Rechts- und Organisationsabteilung
D. Pouha
4.3.1998 Bürgerliches Recht W. Martetschläger5.3.1998 Warenhandel H. Kotzab5.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer10.3.1998 ÖH Hysek10.3.1998 Englische Sprache Prof. W. Obenaus, D. Schleihs10.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer10.3.1998 Politische Ökonomie H. Klausinger
Seite 18 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Datum Stelle Interviewpartner12.3.1998 Wirtschafts- und
SozialgeschichteG. Senft
12.3.1998 Romanische Sprachen
E. Lavric, N. Riehs, I. Hubmann
12.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer16.3.1998 ZID B. Sommer17.3.1998 Studiendekanat G. Zihr17.3.1998 Studiendekanat G. Sedlacek17.3.1998 Dienststellenaussch
ußR. Pieler
18.3.1998 Personalwirtschaft G. Lueger18.3.1998 Betriebswirtschaftlic
he SteuerlehreF. Hörmann
18.3.1998 Wirtschaftsinformatik
O. Kump, A. Schuster
18.3.1998 Wirtschaftsinformatik
R. G. Flatscher, M. Kaukal, R. Klimesch
18.3.1998 Wirtschaftsinformatik
S. Feregyhazy, C. Drimmel
18.3.1998 Wirtschaftsinformatik
M. Fritscher
19.3.1998 Wirtschafts- und Sozialgeschichte
G. Senft, S. Wolf, B. Bauer, R. Lackner, H. Hemetsberger-Koller
19.3.1998 Bürgerliches Recht W. Blocher, W. Martetschläger24.3.1998 Warenhandel H. Kotzab, B. Gasner24.3.1998 Personalwirtschaft Prof. D. Eckardstein, H. Mayerhofer, G. Riedl , G.
Lueger u. a.24.3.1998 Romanische
SprachenE. Lavric, N. Riehs, I. Hubmann
24.3.1998 Finanzierung und Finanzmärkte
S. Schmidt, H. Pichler, P. Hysek
25.3.1998 Betriebswirtschafltiche Steuerlehre
F. Hörmann
25.3.1998 ZAS A. M. Schator, K. Zollner25.3.1998 Studiendekanat H. Haller
Erstellt gemeinsam mit 15. April 1998 Seite 19 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Datum Stelle Interviewpartner26.3.1998 Politische Ökonomie Prof. J. H. Pichler, C. Ragacs, S. Holzweber, H.
Klausinger26.3.1998 Englische Sprache Prof. W. Obenaus, R. Markwitz, K. Wenschitz, D.
Schleihs1.4.1998 Wirtschaftsinformati
kO. Kump, A. Schuster
1.4.1998 Personalwirtschaft Prof. D. Eckardstein, H. Mayerhofer, G. Riedl1.4.1998 ADV-Abteilung R. Barthauer2.4.1998 STAB H. Spitzer, Svaljug, Szalay2.4.1998 STAB H. Spitzer, Nagy, Vario2.4.1998 Finanzierung; ÖH S. Schmidt, P. Hysek7.4.1998 ADV-Abteilung R. Barthauer8.4.1998 ZID G. Miksch
Tabelle 1: Interviews und Abstimmungsgespräche
2.4.4 Präsentationen und WorkshopsAm 11. Dezember 1997 wurde eine Präsentation des Projektes durchgeführt, zu der alle Mitarbeiter eingeladen waren. An der Veranstaltung nahmen ca. 40 – 50 Mitarbeiter teil.
Im Rahmen der 2. Sitzung des Lenkungsausschusses am 30. Jänner 1998 wurde beschlossen, vier Workshops durchzuführen, zu denen alle Mitarbeiter eingeladen waren, und an denen die Ergebnisse des Projekts vorgestellt und diskutiert werden konnten. Die Workshops fanden an folgenden Terminen mit folgender Beteiligung statt:
Datum Stelle Interviewpartner30.3.1998 Gewerbe, Klein- und Mittelbetriebe B. Mahel30.3.1998 Arbeit und Sozialrecht C. Münster30.3.1998 Angewandte Informatik R. Franz30.3.1998 Rektorat: Forschungsservice B. Moravec30.3.1998 Finanzwissenschaft S. Brunner30.3.1998 Verfassungs- und Verwaltungsrecht H. Beclin
Seite 20 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Datum Stelle Interviewpartner31.3.1998 Industrielle Informationsverarbeitung A. Prosser31.3.1998 Genossenschaftswesen;
StudiendekanatG. Zihr
31.3.1998 Angewandte Informatik; Wirtschaftsstatistik; Studiendekanat
G. Sedlacek
31.3.1998 Studiendekanat H. Gabler31.3.1998 Rechts- und Organisationsabteilung G. Mautner, D. Pouha, A.
Melcsok, H. Gelegs1.4.1998 Raumordnung G. Maier1.4.1998 Außenhandel Y. Fuchs1.4.1998 Organisation und Materialwirtschaft E. Chwosta2.4.1998 Finanzrecht M. Zueger2.4.1998 FBK Rechtswissenschaft I. Berger2.4.1998 Tourismus G. Ullrich
Tabelle 2: Workshops – Termine und Teilnehmer
2.4.5 PlakataktionDie noch nicht vollständig abgestimmten Ergebnisse mit Stand 13. März 1998 wurden auf DIN A0-Plakaten ausgedruckt und ab dem 24. März 1998 auf der Galerie vor dem Rektorat öffentlich ausgestellt. Die Mitarbeiter der Wirtschaftsuniversität wurden per E-Mail über die Plakataktion verständigt.
Erstellt gemeinsam mit 15. April 1998 Seite 21 von 171
Grobkonzept Projekt
3 METHODIK UND VORGEHEN
3.1 Die Phasen der KonzeptionDas vorliegende Projekt gliederte sich im wesentlichen in zwei Projektphasen
der Ist-Analyse sowie der Soll-Konzeption.
Diese Phasen wiederum lassen sich – wie in Abbildung 5 aufgezeigt – weiter detaillieren.
Abbildung 5: Phasen des Projektes ‘2gether’
Der Schwerpunkt wurde dabei auf die Konzeption der universitären Verwaltungsabläufe unter Verwendung des neuen Systems ‘2gether’, im weiteren Verlauf „Universitätsprozesse“ genannt, gelegt. Ein solcher Universitätsprozeß mit seinen verschiedenen Instanzen ist beispielhaft in Abbildung 6 dargestellt
Aufgrund des relativ engen zeitlichen Rahmens des Projektes und vor dem Hintergrund bereits existierender umfangreicher Studien erfolgte die Ist-Aufnahme dabei nicht in Form ausführlich ausmodellierter ARIS-Modelle.
Erstellt gemeinsam mit 15. April 1998 Seite 23 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Daher fokussiert dieser Bericht nahezu ausschließlich auf die Soll-Konzeption.
Antrag-stellung
erforderlich
Antragist
eingereicht
UniversitätsverwaltungUniversitätsverwaltung MinisteriumMinisteriumStudentStudent
Gutachtenerforderlich
Akte
Antragerfaßt
Stellung-nahmeerfolgt
GesetzlicheVorlagen
Antragsdaten
Studenten-daten
Fach-referat
DV-System
Genehmigungs-bescheid
Antrags-eckwerte
Begut-achtungerfolgt
Antrags-erfassung
Antrags-prüfung
Antragbearbeitet
Abt.
Gremium
Antrags-stellung
Antrags-bearbeitung
Ext.Fach-referat
Begut-achtung
Abbildung 6: Die Instanzen eines Universitätsprozesses
Eine ausführliche Beschreibung der Darstellungstechnik erfolgt im Abschnitt Architektur integrierter Informationssysteme.
Um eine möglichst schnelle und effiziente Realisierung des Projektvorhabens zu erreichen und gleichzeitig eine hohe Wiederverwendbarkeit der Projektergebnisse sicherzustellen, wird im Projekt durchgängig ein computergestütztes Werkzeug - das ARIS-Toolset - eingesetzt.
In allen Phasen des Projektes wurden daher die Interviewergebnisse sowie die Erkenntnisse aus bereits vorhandener Literatur – wie z. B. des ‘Grobkonzeptes 2gether’ – mit Hilfe des ARIS-Toolsets aufbereitet und verarbeitet (vgl. Abbildung 7). Eine vollständige Auflistung sämtlicher zur Verfügung stehender Sekundärliteratur erfolgt im entsprechenden Kapitel des Anhangs.
Seite 24 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Aufgaben- und Tätigkeitsanalyse Controlling VCAnzahl der Mitarbeiter nach Köpfen:
7
Personalkapazität in Mannjahren: 7,00Stunden pro Mannjahr: 1582Arbeitstage pro Jahr: 210Hauptaufgabe Aufgaben
Minim
ale D
FZ (
in h)
für
die e
inmalig
e Du
rchf
ühru
ngM
axim
ale D
FZ (
in h)
für
die e
inmalig
e Du
rchf
ühru
ngG
ewich
tete
, m
ittler
e DF
Z(in
h)
für
die e
in-m
alige
Durc
hfüh
rung
Men
ge p
.a.
Anza
hl de
r be
teiligt
enM
itarb
eiter
an
der
Teilau
fgab
e%
-Ant
eile d
er D
FZ(m
in) a
n M
enge
p.a
.
%-A
nteile
der
DFZ
(max
) an
Men
ge p
.a.
Ges
amta
ufwa
nd(in
h)
p.a.
Teila
ufga
be
Ges
amta
ufwa
nd(in
M
J) p
.a.
Teilau
fgab
e
Ges
amta
ufwa
nd(in
h)
p.a.
Hau
ptau
fgab
eG
esam
tauf
wand
(in M
J) p
.a.
Haup
tauf
gabe
%-A
nteil
der
Teil-
aufg
abe
an
Haup
tauf
gabe
%-A
nteil
der
Haup
tauf
-ga
be a
m
Ges
amta
ufwa
nd
Unternehmenspla-nung (kf., mf., lf.) 1782,2 1,12655 13,72%
Wirtschaftlichkeit einzelner Projekte berechnen 1,52 7,6 4,56 20 50% 50% 91,2 0,0576 5%Haushaltsplan aufstellen u. bearbeiten 1178 1254 1216 1 50% 50% 1216 0,7686 68%mittelfristige Unternehmensplanung erstellen 228 304 266 1 50% 50% 266 0,1681 15%langfristige Unternehmensplanung erstellen 114 114 114 1 50% 50% 114 0,0721 6%bei strat. Untern. entscheidungen mitarbeiten 76 114 95 1 50% 50% 95 0,0601 5%
Unternehmenskontrol-le bzw. -steuerung 300,1 0,1897 2,31%
Ergebnisrechnung laufend kontrollieren 190 228 209 1 50% 50% 209 0,1321 70%
Einzelmaßnahmen steuern 45,6 60,8 53,1 1 51% 49% 53,1 0,0336 18%neue Erkenntnisse berücksichtigen 30,4 45,6 38 1 50% 50% 38 0,024 13%
Kostensteuerung 1580,8 0,99924 12,17%Kostenrechnungssystem (KRS) pflegen 197,6 684 440,8 1 50% 50% 440,8 0,2786 28%Anwender KRS schulen u. betreuen 76 152 114 1 50% 50% 114 0,0721 7%
KRS weiterentwickeln 0 152 76 1 50% 50% 76 0,048 5%Kostenstellen auf Abweichungen analysieren 114 228 171 1 50% 50% 171 0,1081 11%Kostenstellengespräche vorbereiten und führen 304 456 380 1 50% 50% 380 0,2402 44%Wertefluß der Kostenstellen analysieren 342 456 399 1 50% 50% 399 0,2522 25%
Berichte erstellen 866,4 0,54766 6,67%Monatsberichte f.d. Entscheider-Ebene erstellen 15,2 15,2 15,2 6 50% 50% 91,2 0,0576 11%Ber. z. Weitergabe a.d. Aufsichtsgremien erstellen 304 380 342 1 50% 50% 342 0,2162 39%
Kostenstellen-Berichte erstellen 7,6 19 13,3 4 50% 50% 53,2 0,0336 6%
Aufgaben- und Tätigkeitsanalyse Controlling VCAnzahl der Mitarbeiter nach Köpfen:
7Personalkapazität in Mannjahren: 7,00Stunden pro Mannjahr: 1582
Arbeitstage pro Jahr: 210Hauptaufgabe Aufgaben
Minim
ale D
FZ (
in h)
für
die e
inmalig
e Du
rchf
ühru
ngM
axim
ale D
FZ (
in h)
für
die e
inmalig
e Du
rchf
ühru
ngG
ewich
tete
, m
ittler
e DF
Z(in
h)
für
die e
in-m
alige
Durc
hfüh
rung
Men
ge p
.a.
Anza
hl de
r be
teiligt
enM
itarb
eiter
an
der
Teilau
fgab
e%
-Ant
eile d
er D
FZ(m
in) a
n M
enge
p.a
.
%-A
nteile
der
DFZ
(max
) an
Men
ge p
.a.
Ges
amta
ufwa
nd(in
h)
p.a.
Teila
ufga
be
Ges
amta
ufwa
nd(in
M
J) p
.a.
Teilau
fgab
e
Ges
amta
ufwa
nd(in
h)
p.a.
Hau
ptau
fgab
eG
esam
tauf
wand
(in M
J) p
.a.
Haup
tauf
gabe
%-A
nteil
der
Teil-
aufg
abe
an
Haup
tauf
gabe
%-A
nteil
der
Haup
tauf
-ga
be a
m
Ges
amta
ufwa
nd
Unternehmenspla-nung (kf., mf., lf.) 1782,2 1,12655 13,72%
Wirtschaftlichkeit einzelner Projekte berechnen 1,52 7,6 4,56 20 50% 50% 91,2 0,0576 5%Haushaltsplan aufstellen u. bearbeiten 1178 1254 1216 1 50% 50% 1216 0,7686 68%mittelfristige Unternehmensplanung erstellen 228 304 266 1 50% 50% 266 0,1681 15%langfristige Unternehmensplanung erstellen 114 114 114 1 50% 50% 114 0,0721 6%bei strat. Untern. entscheidungen mitarbeiten 76 114 95 1 50% 50% 95 0,0601 5%
Unternehmenskontrol-le bzw. -steuerung 300,1 0,1897 2,31%
Ergebnisrechnung laufend kontrollieren 190 228 209 1 50% 50% 209 0,1321 70%
Einzelmaßnahmen steuern 45,6 60,8 53,1 1 51% 49% 53,1 0,0336 18%neue Erkenntnisse berücksichtigen 30,4 45,6 38 1 50% 50% 38 0,024 13%
Kostensteuerung 1580,8 0,99924 12,17%Kostenrechnungssystem (KRS) pflegen 197,6 684 440,8 1 50% 50% 440,8 0,2786 28%Anwender KRS schulen u. betreuen 76 152 114 1 50% 50% 114 0,0721 7%
KRS weiterentwickeln 0 152 76 1 50% 50% 76 0,048 5%Kostenstellen auf Abweichungen analysieren 114 228 171 1 50% 50% 171 0,1081 11%Kostenstellengespräche vorbereiten und führen 304 456 380 1 50% 50% 380 0,2402 44%Wertefluß der Kostenstellen analysieren 342 456 399 1 50% 50% 399 0,2522 25%
Berichte erstellen 866,4 0,54766 6,67%Monatsberichte f.d. Entscheider-Ebene erstellen 15,2 15,2 15,2 6 50% 50% 91,2 0,0576 11%Ber. z. Weitergabe a.d. Aufsichtsgremien erstellen 304 380 342 1 50% 50% 342 0,2162 39%
Kostenstellen-Berichte erstellen 7,6 19 13,3 4 50% 50% 53,2 0,0336 6%
Instand-haltungs-summeermitteln
Instandhaltungs-summe
istermittelt
Instand-haltungssumme
mitU-planung abgleichen
XOR
XOR
Instandhaltungs-summe istungleich
U-planung
Instandhaltungs-aufwandkürzen
Instandhaltungs-aufwand ist
ermittelt
Instandhaltungs-summe istzu planen
Thema: Neugestaltung der Budgetp lanung und -abwicklung
Rahmenbedingung:
Budget pro KC nach Kennzahlen
Quantitative Verbesserungen:
Abstimmungsgespräche in BST mit
Planungsingenieur (Bewertung der Pro jekte) entfällt
DV-Eingabe der Planungswerte und
Projekteinrichtung in HV entfäll t
Bewertung der HHP-Projekte nach
Planungsrichtlinien in der HV entfällt
Abstimmungsgespräche der Grobplanung im KC mit
KC-Leiter u. Fachbereichen wird reduziert
Budgetgenehm igung und F reigabe an KC wird
reduziert
Manuelle Einkaufsdisposition entfäl lt
Geringeres Volumen der gedruckten Pläne u. des
Erste llungsaufwandes (HHP)
Vereinfachte Materialbestellung und
Aufmaßerstellung mit anschließender
Rechnungserstellung der Baufi rmen
Vereinfachte DV-Erstellung und Fortführung der
Netzp läne in KC
Weniger Pro jektänderungsdienst
Vereinfachte Lohnaufschreibung
Synergieeffekt durch hohe Transparenz und Zugriff
der MA auf gle iche, aktuelle Infos
Abbau dezentraler Control lingtätigkeiten durch
zielgerichtete, qualitative Planungsunterstützung
Thema: Neugestaltung der Budgetp lanung und -abwicklung
Rahmenbedingung:
Budget pro KC nach Kennzahlen
Quantitative Verbesserungen:
Abstimmungsgespräche in BST mit
Planungsingenieur (Bewertung der Pro jekte) entfällt
DV-Eingabe der Planungswerte und
Projekteinrichtung in HV entfäll t
Bewertung der HHP-Projekte nach
Planungsrichtlinien in der HV entfällt
Abstimmungsgespräche der Grobplanung im KC mit
KC-Leiter u. Fachbereichen wird reduziert
Budgetgenehm igung und F reigabe an KC wird
reduziert
Manuelle Einkaufsdisposition entfäl lt
Geringeres Volumen der gedruckten Pläne u. des
Erste llungsaufwandes (HHP)
Vereinfachte Materialbestellung und
Aufmaßerstellung mit anschließender
Rechnungserstellung der Baufi rmen
Vereinfachte DV-Erstellung und Fortführung der
Netzp läne in KC
Weniger Pro jektänderungsdienst
Vereinfachte Lohnaufschreibung
Synergieeffekt durch hohe Transparenz und Zugriff
der MA auf gle iche, aktuelle Infos
Abbau dezentraler Control lingtätigkeiten durch
zielgerichtete, qualitative Planungsunterstützung
Grobkonzept‘2gether’
‘Sinz-Studie’ etc.
GraphischeOrganisations-
modelle Reports
Geringeres Volumen der gedruckten Pläne u. des
Erste llungsaufwandes (HHP)
Vereinfachte Materialbestellung und
Aufmaßerstellung mit anschließender
Rechnungserstellung der Baufi rmen
Vereinfachte DV-Erstellung und Fortführung der
Netzp läne in KC
Weniger Pro jektänderungsdienst
Vereinfachte Lohnaufschreibung
Synergieeffekt durch hohe Transparenz und Zugriff
der MA auf gle iche, aktuelle Infos
Abbau dezentraler Control lingtätigkeiten durch
zielgerichtete, qualitative Planungsunterstützung
Erhebungsbogen Interviews/Workshops
ARIS-Toolset
Abbildung 7: Werkzeuggestütztes Vorgehen im Projekt ‘2gether’
Dabei entstand eine umfangreiche Datenbasis in Form einer ARIS-Datenbank, deren Auszüge wesentlicher Bestandteil in diesem Bericht sind (siehe Abschnitt Fachliche Konzeption des Systems ‘2gether’).
3.2 Architektur integrierter InformationssystemeDas ARIS-Toolset ist ein DV-gestütztes Beratungswerkzeug auf Datenbankbasis, insbesondere für folgende Fragestellungen:
Analyse- und Optimierung organisatorischer Abläufe, Geschäfts- bzw. Universitätsprozesse;
Erstellung fachlicher und organisatorischer Sollkonzepte; Erstellung von IV-Strategien und IV-Bebauungsplänen; Einführung von Software, insbesondere Standardsoftware.
Erstellt gemeinsam mit 15. April 1998 Seite 25 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Das von der IDS Prof. Scheer GmbH entwickelte ARIS-Toolset ist ein wissenschaftlich fundiertes und in vielen Projekten erprobtes Modellierungs-Werkzeug, welches inzwischen im Bereich der Werkzeuge zur Geschäftsprozeßoptimierung weltweit marktführend ist.
3.2.1 Hintergrund und IdeeWissenschaftliche Grundlage für das Werkzeug ist die Architektur integrierter Informationssysteme (ARIS), ein Methodenrahmen zur Unternehmensmodellierung, der am Institut für Wirtschaftsinformatik der Universität des Saarlandes entwickelt worden ist. Kerngedanke des ARIS ist der der Zerlegung der darzustellenden Organisation nach verschiedenen Aspekten und der zielgerechten (Wieder-) Integration der Information zur effizienten Erreichung des Projektzieles.
Dadurch wird einerseits eine große Übersichtlichkeit in der Darstellung komplexer Sachverhalte, andererseits aber auch ein systematisches Vorgehen im Projekt erreicht. Je nach Darstellungsfokus kommen dabei unterschiedliche Modell-, d.h. Diagrammtypen zum Einsatz.
Die Zerlegung des Gesamtsystems erfolgt nach Sichten und Ebenen (vgl. Abbildung 8):
Seite 26 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Abbildung 8: Das ARIS-Haus im Gesamtüberblick
3.2.2 Die ARIS-EbenenBei der Unternehmensmodellierung treffen in den Projekten oftmals Mitarbeiter unterschiedlicher Fachrichtungen aufeinander. Dies ist beispielsweise immer dann der Fall, wenn zum Zwecke der Anwendungssystementwicklung Entwickler und Sachbearbeiter zusammenarbeiten. Jede Richtung hat dabei ihren eigene Sprachgebrauch: die Sachbearbeiter reden in fachlichen Termini, während die Entwickler dv-bezogene Ausdrücke und Begriffe verwenden. Dies macht die Verwendung jeweils spezifischer Beschreibungsmethoden naheliegend. ARIS bietet daher Modelltypen in drei verschiedenen Ebenen, die sich durch ihre Nähe einerseits zur fachlichen Seite, andererseits zur implementierungsnahen Beschreibung unterscheiden (vgl. Abbildung 9).
Erstellt gemeinsam mit 15. April 1998 Seite 27 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Fachkonzept
DV-Konzept
Implementierung
Fachbereich
Datenverarbeitung
Abbildung 9: Ebenenkonzept des ARIS
Die Breite der Pfeile symbolisiert dabei die Stärke der Kopplung zwischen den Ebenen, so daß in der ARIS-Methodik bewußt eine lose Verbindung zwischen Fach- und DV-Konzept realisiert wird.
Entsprechend der Zielsetzung des Projektes wird hier nur im Bereich des Fachkonzeptes modelliert, so daß im weiteren auch nicht näher auf die Ebenen DV-Konzept und Implementierung eingegangen wird und sich folgende Ausführungen stets auf die Fachkonzeptebene beziehen. Grundsätzlich erstreckt sich die im nächsten Abschnitt beschriebene Sichtenbildung natürlich auf alle Ebenen des ARIS-Hauses (Literaturhinweis: [Scheer95|98]).
3.2.3 Die ARIS-SichtenEin weiterer wesentlicher Aspekt der ARIS-Methode ist die Verwendung von vier verschiedenen Sichten:
der Organisationssicht, der Funktionssicht, der Datensicht sowie der Steuerungssicht.
Seite 28 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
In der Organisationssicht wird die Aufbauorganisation beispielsweise einer Universität beschrieben. Wichtigster Modelltyp ist hier das - auch außerhalb des ARIS verwendete - Organigramm, in dem die statischen, hierarchischen Beziehung von Organisationseinheiten wie Fachbereichen, Abteilungen oder auch Stellen beschreiben und definiert werden (vgl. Abbildung 10).
Universitäts-direktion
Rechts - undOrganisations-
abteilungPersonalabteilung
Studien- undPrüfungsabteilung
(STAB)
Wirtschaftsabtei-lung und Abteilung
für Gebäudeund Technik
Quästur
Abbildung 10: Beispiel eines Organigramms (Ausschnitt)
In den Organigrammen werden in der Regel sämtliche organisatorische Einheiten definiert, die in den anderen Modellen verwendet werden können.
In der Funktionssicht wird die statische, hierarchische funktionale Struktur einer Institution abgebildet. Dies kann in einer Universität beispielsweise deren Aufgabenstruktur oder aber auch natürlich die (hierarchische) Struktur der Vorgangsbearbeitung sein. Dies bedeutet, daß Aufgaben, Prozesse, Arbeitsvorgänge und Tätigkeiten etc. definiert und ihre Einordnung in die funktionale Gesamtstruktur beschrieben werden. Verwendung findet dabei in erster Linie der Modelltyp Funktionsbaum, der eben diesen Zweck ermöglicht und der beispielhaft in Abbildung 11 dargestellt ist.
Erstellt gemeinsam mit 15. April 1998 Seite 29 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Studien- undPrüfungs-verwaltung
allgemeineFunktionenStudium
*
Lehrver-anstaltung
*
Prüfung
*
Abschluß-arbeiten
*
An-undAbmeldung
*
Anerkennung
*
Abrechnung
*
Evaluierungder Lehre
*
allgemeineSystem-
funktionen
Abbildung 11: Beispiel eines Funktionsbaums
Die dritte Säule des sogenannten ARIS-Hauses ist die Datensicht. Hier wird die (statische) Struktur der im Untersuchungsbereich verwendeten Nutzendaten beschrieben. Die Beschreibung der Datenstruktur ist in erster Linie für Projekte im Bereich Anwendungssystementwicklung vonnöten, da aus ihr das notwendige Datenbankschema abgeleitet oder gar (mit Hilfe eines CASE-Tools) generiert werden kann. Bekanntester Modelltyp ist dabei das seit den 70er Jahren verbreitete Entity-Relationship-Modell.
Dieser Modelltyp bildet unter anderem einen Schwerpunkt dieses Projektes. Dabei werden die Datenstrukturen beschrieben, so wie sie im Bereich der Studien- und Prüfungsverwaltung Verwendung finden. Zentrales Objekt im ERM ist der Entitytyp mit seinen Beziehungen im betrachteten Umfeld. Dieses Objekt wird dargestellt mittels eines Rechtecks, seine Beziehungen zu anderen Entitytypen mittels einer Raute, s.d. die Kombination „Entitytyp - Beziehungstyp - Entitytyp“ i.d.R. der Semantik eines Satzes mit „Subjekt - Prädikat - Objekt“ entspricht.
Zur genaueren Spezifizierung der Beziehung zweier Entitytypen werden sog. Kardinalitäten eingeführt. Diese beschreiben, wie oft ein Entitytyp in einer Beziehung erscheinen kann. So bedeutet „cn“ beispielsweise, daß der Enti-tytyp keinmal bis beliebig oft in der entsprechenden Beziehung existieren kann.
Darüber hinaus können Beziehungstypen zur Konstruktion eines neuen Objektes, welches wiederum eigene Beziehungen eingehen kann, führen. Ein markantes Beispiel hierfür ist die Lehrveranstaltungsanmeldung, die eine Kombination aus Student und Lehrveranstaltung ist. Grafisch werden
Seite 30 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
diese uminterpretierten Beziehungstypen durch ein um die Raute gelegtes Rechteck dargestellt.
Schließlich sei als wichtiges logisches Mittel noch die Generalisierung/Spe-zialisierung erwähnt. Diese Beziehung, dargestellt in Form eines Dreiecks, beschreibt die hierarchische Struktur der Datenobjekte. Je nach Betrachtungsrichtung liest man sie „kann sein“ oder „ist ein“: z.B. eine Diplomarbeit ist eine Abschlußarbeit. Diese Konstruktion wird insbesondere verwendet zur Verdeutlichung von Vererbungsmechanismen, mit denen die Attribute und Beziehungen des übergeordneten Objektes auf das untergeordnete übertragen werden (Abbildung 12).
Die Objekte des Datenmodells definieren sich schließlich im Grunde durch eine Zusammenfassung von Attributen, sprich Datenfeldern, welche aus Gründen der Übersichtlichkeit in dieser Arbeit in einer EXCEL-Tabelle erfaßt werden.
Abbildung 12: Beispiel Entity-Relationship-Modell
Es folgt die zentrale Sicht des ARIS-Hauses, die Steuerungssicht.
In ihr werden die Prozesse, beispielsweise der Vorgangsbearbeitung in ihrem zeitlich-logischen Ablauf beschrieben. Sie ist damit von wesentlicher Bedeutung bei der Aufzeigung der organisatorischen Konsequenzen, die mit
Erstellt gemeinsam mit 15. April 1998 Seite 31 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
der Einführung eines neuen Anwendungssystems verbunden sind. Im Gegensatz zu den rein statischen Beschreibungen der anderen Sichten werden hier - unter Verwendung der in eben diesen Sichten definierten Organisationseinheiten, Funktionen und auch Anwendungssysteme - Prozesse in ihrer dynamischen Folge dargestellt. Wesentlicher Modelltyp ist die Ereignisgesteuerte Prozeßkette (EPK), wie sie beispielhaft in Abbildung13 gezeigt ist.
Semester-beginn
eingetreten
automatische Generationvom System
Beauftragungs-Bescheidegenerieren
LV-Leiterelektronischerreichbar
Normalfall
2gether
Beaufragungs-bescheide
verschicken
automatisch
LV-Leiterbenachrichtigt
Beauftragungs-bescheidedrucken
Beauftragungs-bescheide
2gether 2gether
Beauftragungs-bescheidegedruckt
absoluterAusnahmefall
LV-Leiterbenachrichtigen
LV-Leiterelektronisch
nicht erreichbar
absoluterAusnahmefall
Rechts - undOrganisations-
abteilungBeauftragungs-bescheide
Rechts - undOrganisations-
abteilung
Beauftragungs-bescheideeinsehen
LV-Leiter
Abbildung 13: Beispiel einer Ereignisgesteuerten Prozeßkette (Ausschnitt)
Grundgedanke der EPK ist - wie der Name schon sagt - die „Ereignissteuerung“ eines Prozesses. Dabei wird jede Tätigkeit (Funktion) durch ein genau definiertes Ereignis ausgelöst und mit einem bestimmten Ergebnis beendet. Dieses Ergebnis - auch in Form eines Ereignisses - löst
Seite 32 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
sodann eine weitere Funktion aus u.s.w. Dies bedeutet, daß auch ein Prozeß selbst durch ein oder mehrere Startereignisse ausgelöst und mit einem oder mehreren Endereignissen beendet wird. Diese Start- und Endereignisse können wiederum auch mit anderen Prozessen in Verbindung stehen, die dann durch sogenannte Prozeßwegweiser dargestellt werden (hier nicht im Bild). Desweiteren lassen sich in der EPK auch die mit den einzelnen Tätigkeiten verbundenen Informationsobjekte wie Stellen, Dokumente (Informationsträger), Daten oder Anwendungssysteme aber auch beispielsweise externe Beteiligte etc. darstellen.
Dabei sind folgende Lesarten angezeigt:
Das Anwendungssystem unterstützt die Funktion Das Organisationselement führt aus die Funktion Der Datum ist Input/Output der Funktion Der Informationsträger ist Input/Output der Funktion u.s.w.
Diese Zusammenhänge lassen sich fallweise auch in eigenen, ausgelagerten Modellen, den Funktionszuordnungsdiagrammen (FZD) darstellen (vgl. Abschnitt Projektkonventionen).
Zusammenfassend seien im folgenden Abbildung 14 die in diesem Projekt verwendeten Objekttypen in Form einer Legende aufgelistet.
Erstellt gemeinsam mit 15. April 1998 Seite 33 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Ereignis
Funktion
log. 'und'
log. 'exklusiv oder'
log. 'und/oder'
Anwendungssystem
Organisations-einheit (-styp)
Informationsträger(Dokument)
Personentyp
Informationsträger(Datei)
Entitytyp
Datencluster
Beziehungstyp
uminterpretierterBeziehungstyp
Legende
Generalisierung/Spezialisierung
Abbildung 14: Legende der verwendeten Objekttypen
Seite 34 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
3.3 Grundsätze ordnungsmäßiger ModellierungDie Grundsätze ordnungsmäßiger Modellierung (GoM) schaffen in begrifflicher Anlehnung an die ‘Grundsätze ordnungsmäßiger Buchführung’ eine methodenunabhängige Grundlage für die Darstellung von Informationsstrukturen in Form von Modellen, wie sie z.B. bei der Unter-nehmensmodellierung - zu der ja auch die Geschäftsprozeßmodellierung gehört - durchgeführt wird.
Dabei schaffen sie einerseits ein theoretisches Fundament für die Beschreibungsmethoden als solche (‘Meta-Ebene’), andererseits werden aber auch Richtlinien für die eigentliche Modellierung der Inhalte entwickelt. Die GoM’s werden dabei in einer Anzahl von Grundsätzen formuliert.
Ersterer Aspekt, die Meta-Ebene, beinhaltet dabei
den Grundsatz der Vergleichbarkeit sowie den Grundsatz des systematischen Aufbaus.
Diese Anforderung sind durch die verwendete ARIS-Methode voll abgedeckt, so daß „lediglich“ die inhaltlichen Grundsätze für dieses wie für jedes Projekt zu verwirklichen sind. Diese lauten:
Grundsatz der Richtigkeit,- syntaktisch
- semantisch
Grundsatz der Relevanz, Grundsatz der Wirtschaftlichkeit und Grundsatz der Klarheit
- Strukturiertheit
- Übersichtlichkeit
- Lesbarkeit.
Auf eine ausführliche Beschreibung der einzelnen Grundsätze kann an dieser Stelle nicht eingegangen werden; das intuitive Verständnis der Begriffe er-scheint aber jedoch auch als ausreichend.
Erstellt gemeinsam mit 15. April 1998 Seite 35 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Zur Realisierung der GoM’s in einem GPO-Projekt unter Einsatz eines Modellierungswerkzeugs stellen sich damit konkret folgende Fragen der:
Methodenverwendung, d.h.- Auswahl der Modelltypen,
- Auswahl der Objekttypen,
- Auswahl der Kantentypen,
- Auswahl der Attributtypen;
Modellierungsrichtlinien, d.h.- Benennung von Objekten,
- Benennung von Modellen,
- Detaillierungsgrad von Objekten,
- Gruppierung von Objekten;
Darstellungskonventionen, d.h.- allgemeine grafische Einstellungen,
- grafische Normen für Diagramme,
- Ausrichtung von Objekten sowie des
Werkzeugeinsatzes, d.h.- Aufbau der Gruppenhierarchie,
- Festlegung der Benutzerrechte,
- [Zusammenführen von Datenbanken,]
- Koordination bei Multi-User-Betrieb,
- Verwendung von Kopierarten,
- Definition von Standardreports sowie
- Definition von Konsistenzchecks
All diese Aspekte münden in der Festlegung von projektspezifischen Konventionen, die ihren Niederschlag in
der (Aufbau-) Organisation des Projektes,
Seite 36 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
der inhaltlichen Vorgehensweise in der Modellierung, der Administration und dem Aufbau der ARIS-Datenbank, der Erstellung eines projektspezifischen Methodenfilters, der Definition von Standardauswertungen mit Hilfe von Reports
und Makros sowie in der verbalen Beschreibung der weiterhin getroffenen Konventionen
finden.
Es ergibt sich also als methodische Grundlage für die Projektdurchführung folgender, in Abbildung 15 dargestellter Aufbau:
Grundsätze ordnungs-mäßiger Modellierung (GoM)
Architektur integrierterInformationssysteme (ARIS)
ZielgerichteteProjektkonventionen
Projekterfolg
Abbildung 15: Bestandteile der Methodik
So weit möglich und sinnvoll wird auf die verschiedenartigen Konventionen in den folgenden Abschnitten eingegangen. Insbesondere letztere sind wertvoll zum Verständnis der Modelle und somit letztlich auch zur sinnvollen Weiterverwendung des Erarbeiteten.
Erstellt gemeinsam mit 15. April 1998 Seite 37 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
3.4 Projekt-/ModellierungskonventionenAn dieser Stelle erfolgt eine Beschreibung der im Rahmen des Projektes aufgestellten Konventionen. Dabei handelt es sich einerseits um solche, die durch den speziellen ARIS-Methoden-Filter („WU-Wien-Filter“) sichergestellt werden, andererseits um Konventionen, die nur durch Modellierungsdisziplin und manuelle Qualitätssicherung zu realisieren sind:
Unter den „Erweiterten Modellierungskonventionen“ werden Konventionen gefaßt, die über die reine Einschränkung von ARIS-Modelltypen, -Objekttypen oder –Kantentypen – realisiert durch den Methodenfilter – hinausgehen.
Dies sind insbesondere Konventionen zur Interpretation der Modelle („implizite“ Konventionen), zur Verwendung von Objekttypen oder bspw. zur Verwendung von Ausprägungskopien etc.
3.4.1 Verwendung aufbauorganisatorischer ElementeZur leichteren Lesbarkeit und Erhöhung der Allgemeingültigkeit wird auf die explizite Verwendung einzelner Instituts- oder Abteilungsbezeichnungen aus den Fachbereichen verzichtet. Statt dessen wird in den Prozeßmodellen das Objekt „Institut/Abteilung" verwendet zum Verweis auf die jeweils betroffenen Organisationseinheit. Dies wird durch die unsymmetrische Struktur der Fachbereiche - Aufgliederung in Institute und/oder Abteilungen - an der WU Wien erforderlich und fördert zudem die allgemeine, übergreifende Verwendung der Ergebnisse.
Entsprechend gilt Analoges für die jeweiligen Leiter/-innen der betreffenden Organisationseinheit.
3.4.2 Aufbau der Modellhierarchie
3.4.2.1 Ablaufbeschreibung versus FunktionalitätsbeschreibungEs wird unterschieden zwischen Funktionalitäten, die eine dezidierte Beschreibung der ablauforganisatorischen Einbindung des Systems ‘2gether’ erfordern und solchen, die eher Ad-Hoc-Funktionalitäten entsprechen, d.h. bei denen die beschriebenen Teilaspekte im weitesten
Seite 38 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Sinne Modulen entsprechen, die von Berechtigten jederzeit ausgeführt werden können.
Erstere werden dementsprechend durch Ereignisgesteuerte Prozeßketten beschrieben, letztere durch Funktionsbäume. Diese Funktionsbäume werden allerdings ergänzt um Funktionszuordnungsdiagramme, die jeweils den sog. „Level-1-Funktionen“ hinterlegt werden und die sowohl die organisatorische Zuordnung als auch die systemseitige Unterstützung der beschriebenen Funktionalität definieren.
3.4.2.2 Bildung von SzenarienErfordert die Beschreibung der Funktionalitäten, respektive Abläufe, die Bildung von Varianten, sogenannten „Szenarien“, dann erfolgt dies über das Instrument der Prozeßauswahlmatrix (PAM). Dabei wird diese – in Ergänzung der Standardkonventionen – um ihre Bedeutung erweitert, so daß letztlich über die PAMs auch in Funktionsbäume navigiert werden kann.
3.4.2.3 Integration von Daten und FunktionalitätenEntsprechend des Zeitrahmens sowie insbesondere den Zielen dieses Projektes (nämlich eine Ausschreibungsgrundlage zu erzeugen), erfolgt die Spezifikation lesender oder schreibender Datenzugriffe durch Funktionen mit Hilfe von Funktionszuordnungsdiagrammen auf Prozeß- und Clusterebene. Entsprechend wird auf die Zuordnung detaillierter Datenobjekte oder gar -felder zu einzelnen Funktionalitäten verzichtet.
3.4.3 DetaillierungsgradDer Detaillierungsgrad der Modellierung richtet sich nach den Zielen des Projektes und folgt somit insbesondere den Grundsätzen der Relevanz sowie der Wirtschaftlichkeit (vgl. Abschnitt Grundsätze ordnungsmäßiger Modellierung). Im Einzelnen:
3.4.3.1 DatenmodelleDie konzeptionellen Datenmodelle wurden in Form detaillierter (erweiterte) Entity-Relationship-Modelle erstellt. Diese beinhalten zunächst keine Datenfelder (Attribute), sondern Verweise der einzelnen Datenobjekte auf eine EXCEL-Tabelle. Diese Verweise können im ARIS-Toolset unmittelbar ausgelöst werden und enthalten jeweils eine Liste der wesentlichen Da-tenfelder.
Erstellt gemeinsam mit 15. April 1998 Seite 39 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
3.4.3.2 ProzeßmodelleDer in den Ereignisgesteuerten Prozeßketten verwendete Detaillierungsgrad richtet sich nach der Klarheit und Aussagekraft der jeweiligen Beschreibung der Funktion. Es ist daher möglich, daß in den Modellen sowohl sogenannte „Elementartätigkeiten“ als auch komplexere Arbeitsschritte verwendet wurden. Dadurch wird eine intuitivere Lesbarkeit und somit ein besseres Verständnis erreicht.
In diesem Zusammenhang ist auch zu betonen, daß die Funktionen in den Prozeßabläufen teilweise als optional einzuordnen sind.
3.4.4 Übersicht der MethodenverwendungIn den folgenden tabellarischen Übersichten werden die im Projekt verwendeten Modell-, Objekt- und Attributtypen beschrieben. Dabei wird spezifiziert, ob es sich jeweils um einen optionalen („Kann“) oder um einen obligaten („Muß“) Bestandteil handelt. Darüber hinaus werden zum besseren Verständnis intuitive Beispiele angeführt.
Auf eine darüber hinausgehende Auflistung der verwendeten Kantentypen wurde aus Gründen der Übersichtlichkeit verzichtet.
Modelltyp Kann Muß BeispielOrganigramm X Organigramm WU WienEEPK X Planung von LehrveranstaltungenProzeßauswahlmatrix X An- und AbmeldungEERM X LehrveranstaltungFunktionszuordnungsdiagramm
X Abrechnung
Funktionsbaum X PrüfungsanmeldungTabelle 3: Modelltypverwendung
Seite 40 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Modelltyp Objekt-/Symboltyp Kann Muß BeispieleEPK Ereignis X „VVZ ist erstellt“
Funktion X „VVZ drucken“Prozeßwegweiser XPersonentyp X Student/-in (im Sinne
einer Rolle)(externe) Person X DruckereiOrganisationseinheit (-styp)
X Institut
Anwendungssystem (-typ) X ‘2gether’Regel X ‘und’, ‘oder’, ‘exkl. oder’Prozeßwegweiser X folgender ProzeßDokument X BeauftragungsbescheidDatei X VVZ
FZD1 Funktion X AbrechnungPersonentyp X Student/-in (im Sinne
einer Rolle)Organisationseinheit (-styp)
X Institut
Anwendungssystem (-typ) X 2getherCluster X Lehrveranstaltung
Funktionsbaum
Funktion X Chipkarten personalisieren
Organigramm Organisationseinheit (-styp)
X STAB, Institut
Prozeßauswahlmatrix
Szenario X Lehrveranstaltungsan- und -abmeldung
Hauptprozeß X EinzelanmeldungenProzeß X Lehrveranstaltungsanm
eldung eERM Entitytyp X Student/-in
Beziehungstyp X Reservierung; (Terminliste) gibt
1 Funktionszuordnungsdiagramm
Erstellt gemeinsam mit 15. April 1998 Seite 41 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Modelltyp Objekt-/Symboltyp Kann Muß BeispielVorlagetermin für (Anerkennungsantrag)
Uminterpretierter Beziehungstyp
X LV-Anmeldung
Generalisierung/ Spezialisierung
X (WU-Angehöriger) kann sein (wiss. MA)
Tabelle 4: Modell-/Objekttypzuordnung
Objekt-/Sym-boltyp Attributtyp Kann Muß Inhalt
<alle> Name X2 --Identifizierer X Ids1.4711Langbezeichnung X Name ohne AbkürzungenBemerkung/Beispiel X ZusatzinfoBeschreibung/Definition
X Zusatzinfo
Funktion Bearbeitungskennzeichen
X „*“ als Hinweis auf WORD-Hinterlegung
Systemattribute/Extern i
X Verweis auf WORD-Hin-terlegung
Funktionstyp/Typ 1 X „P“: hinterlegter Prozeß„F“: hinterlegter Funktionsbaum
Bearbeitungsart/auto-dezentral
X Automatisch, dezentral von ‘2gether’ durchgeführte Funktion
Bearbeitungsart/auto-zentral
X Automatisch, zentral von ‘2gether’ durchgeführte Funktion
Hauptprozeß Bearbeitungskennzeichen
X „*“ als Hinweis auf WORD-Hinterlegung
Systemattribute/Extern i
X Verweis auf WORD-Hin-terlegung
Informations- --2 außer ‘Generalisierung/Spezialisierung’
Seite 42 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Objekt-/Sym-boltyp Attributtyp Kann Muß Inhalt
trägerOrganisations-einheit
--
Organisations-einheitstyp
--
(externe) Person
--
Personentyp --Anwendungs-systemtyp
--
Beziehungstyp Beschreibung/Definition
X Beispielhafte Datenfelder
System/Extern i X Verweis auf EXCEL-Hin-terlegung
Bearbeitungskennzeichen
X „*“ als Hinweis auf EXCEL-Hinterlegung
Cluster/Daten-modell
Verfasser/Quelle X Zugehöriges Altsystem
Ereignis --Generalisie-rungstyp
Zerlegungsgrad X ‘c’: unvollständig, disjunkt‘1’: vollständig, disjunkt‘cn’: unvollständig, nicht disjunkt‘n’: vollständig, nicht dis-junkt
Regel --Entitytyp Beschreibung/
DefinitionX Beispielhafte Datenfelder
System/Extern i X Verweis auf EXCEL-Hin-terlegung
Bearbeitungskennzeichen
X „*“ als Hinweis auf EXCEL-Hinterlegung
Tabelle 5: Objekt-/Attributtypzuordnung
Erstellt gemeinsam mit 15. April 1998 Seite 43 von 171
Grobkonzept Projekt
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“
4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Die organisatorische Einbindung des Systems ‘2gether’ in die WU Wien ist Gegenstand dieses Kapitels. Die erwähnten Organisationseinheiten sind dabei – wie in der folgenden Abbildung 16 aufgezeigt – in die Aufbauorganisation eingegliedert.
Erstellt gemeinsam mit 15. April 1998 Seite 45 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Uni
vers
itäts
-ko
llegi
um
UK
Kom
mis
sion
Bes
onde
reU
nive
rsitä
ts-
einr
icht
ung
Bür
o de
rK
olle
gial
-or
gane
Stu
dien
-de
kana
t
Stu
dien
-de
kan
Uni
vers
itäts
-di
rekt
ion
Bib
lioth
ekA
ußen
inst
itut
Zent
rum
für
Aus
land
s-st
udie
nZI
DS
prac
hlab
or
Rec
hts
- und
Org
anis
atio
ns-
abte
ilung
Per
sona
l-ab
teilu
ngS
tudi
en- u
ndP
rüfu
ngsa
btei
lung
(STA
B)
Wirt
scha
ftsab
tei-
lung
und
Abt
eilu
ngfü
r Geb
äude
und
Tech
nik
Quä
stur
Vol
ksw
irt-
scha
fts-
lehr
eR
echt
swis
sen-
scha
ftG
eist
es- u
ndFo
rmal
-w
isse
nsch
aft
Bet
riebs
-w
irtsc
hafts
-le
hre
Inst
itut/
Abt
eilu
ngIn
stitu
t/A
btei
lung
Inst
itut/
Abt
eilu
ngIn
stitu
t/A
btei
lung
Stu
dien
-ko
mm
issi
on
WU
Wie
n
Rek
tor/
Viz
erek
tore
n
Abbildung 16: WU Wien Aufbauorganisation nach UOG 93, Überblick3
3 Quelle: UOG 93Seite 46 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.1 Übersicht
Studien- undPrüfungs-verwaltung
allgemeineFunktionenStudium
*
Lehrver-anstaltung
*
Prüfung
*
Abschluß-arbeiten
*
An-undAbmeldung
*
Anerkennung
*
Abrechnung
*
Evaluierungder Lehre
*
allgemeineSystem-
funktionen
Abbildung 17: Funktionsbaum „Studien- und Prüfungsverwaltung“
Bemerkungen:Unterteilt werden die organisatorischen Themengebiete nahezu wie im Grobkonzept 2gether, das im Vorfeld zu diesem Bericht entstand - also in Studium, Lehrveranstaltungen, Prüfungen etc. (vgl. Abbildung 17). Das Grobkonzept bildet also den Rahmen der fachlichen Konzeption.
Die im Grobkonzept aufgeführten „allgemeinen Funktionen“ der Anwendungssoftware (Kapitel 5.1 Grobkonzept) und die Themenpunkte der „Systemimplementierung und -verwaltung“ (Kapitel 6 Grobkonzept) wurden ohne größeren Zusatz übernommen und dem Kapitel „allgemeinen Systemfunktionen“ zugeordnet – ausgenommen die Chipkartenverwaltung, die dem Kapitel „allgemeine Funktionen“ zugeordnet wurden. Bei den anderen Themengebieten wurden Prozeßketten (eEPK) und Funktionsbäume modelliert, um die künftige Ablaufbeschreibung detaillierter und transparenter zu machen und damit die Akzeptanz der potentiellen Benutzer zu erhöhen. Das Kapitel „Sonstige Funktionen“ (Kapitel 5.10 Grobkonzept), wurde in „Allgemeine Funktionen“ umbenannt.
In jedem Themenabschnitt, wie z.B. „Lehrveranstaltungen“, findet man das Übersichtsmodell (Prozeßauswahlmatrix oder Funktionsbaum) abgebildet mit Erläuterungen. In allen Unterabschnitten, wie z.B. „Planung von Lehrveranstaltungen“, werden Funktionszuordnungsdiagramme mit
Erstellt gemeinsam mit 15. April 1998 Seite 47 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Beschreibung der teilnehmenden Organisationsabteilungen und wichtigen Anwendungssystemen aufgeführt. Außerdem kommen Bemerkungen zu den Prozessen oder Funktionsbäumen hinzu. Die Prozesse und Funktionsbäume findet man im Anhang, tragen den gleichen Namen wie die Unterabschnitte (also z.B. „Planung von Lehrveranstaltungen“) und liefern die Detailinformationen. Natürlich sollte grundsätzlich bei Unklarheiten auf die ARIS-Datenbank ‘WU_Wien’ zurückgegriffen werden, in der bei vielen Objekten weitere Informationen hinterlegt sind. Ein wesentlicher Bestandteil am Ende fast jeden Abschnitts/Unterabschnitts ist die Abschätzung des Nutzenpotentials aus der Sicht der beteiligten Organisationseinheiten. Aufgrund der hohen Heterogenität der Abteilungen/Institute der WU-Wien kann nicht jeder Nutzen allen Abteilungen/Instituten zugeordnet werden; auch finden sich dieselben Arbeiten in den einen Abteilungen/Instituten bei den Sekretariaten in den anderen dagegen im Mittelbau, so daß die Nutzenpotentiale aus der Sicht dieser beiden Organisationseinheiten sich häufig ähneln. Bei allen Fragestellungen sollten die erstellten Prozeßketten und Funktionsbäume zu Rate gezogen werden.
Als Abschluß findet man ein Aufzählung aller Einwände der interviewten Bereiche, also eine Art Forum für die Meinungsvielfalt an der WU-Wien. Hier möchten die Autoren besonders allen Teilnehmern für ihre engagierte Mitarbeit danken.
Auf Ergebnisse des Grobkonzepts, das als Anhang vorliegt, wird im folgenden des öfteren verwiesen werden.
Seite 48 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.2 Studien
P
Rück-meldungStudium
*
P
Zusatzstudium/Wechsel des
Studiums*
P
BeendigungStudium
*
P
ZulassungStudium mit bes.Voraussetzung
P
ZulassungStudium mit Be-
rechtigungsprüfungP
ZulassungStudium mit ind.
StudiengangP
ZulassungStudium
mit Auflagen
P
ErstellungDiplomzeugnis
Studium mit allg.Voraussetzung
Studium mit bes.Voraussetzung
Studium mit Be-rechtigungsprüfung
Studium mit ind.Studiengang
Studium mitAuflagen
ZulassungStudium mit allg.Voraussetzung* P
ZulassungStudium
Rück-meldungStudium
Studien-wechsel
BeendigungStudium
P
Rück-meldungStudium
*Zusatzstudium/Wechsel des
StudiumsP*
BeendigungStudium
P*
P
ErstellungDiplomzeugnis
P
Rück-meldungStudium
*
* P
Zusatzstudium/Wechsel des
Studiums
P*
BeendigungStudium
ErstellungDiplomzeugnis
P
Rück-meldungStudium
P*Zusatzstudium/Wechsel des
StudiumsP*
P
BeendigungStudium
*
P
ErstellungDiplomzeugnis
P
Rück-meldungStudium
*
P
Zusatzstudium/Wechsel des
Studiums*
P
BeendigungStudium
*
P
ErstellungDiplomzeugnis
Abbildung 18: PAM „Studium“
Bemerkungen:Angestrebt wird eine umfangreichere Kommunikation der Studenten mit der DV-Welt und die damit verbundene Erleichterung von Routineaufgaben in der STAB. Dateneingaben werden z.B. über Internet möglich sein, Bezahlungen und Rückmeldungen mit der Studentenausweis-Chipkarte oder auch über Internet, Studienwechsel können systemunterstützt direkt vom Studenten durchgeführt werden. Bei der Beendigung des Studiums werden Folgeaktivitäten automatisch angestoßen. Wichtig ist ein Umdenkungsprozeß der Studenten, daß Termine mit der STAB einzuhalten und zu vereinbaren sind – letztendlich zum Wohl aller, da dann ein schnellerer reibungsloser Ablauf garantiert werden kann.
Siehe auch Kapitel 5.2 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 49 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.2.1 Zulassung Studium(Zulassung Studierende mit allg. Voraussetzungen, Zulassung Studierende mit bes. Voraussetzungen, Zulassung Studierende mit Studienberechtigungsprüfung, Zulassung Studierende mit Nostrifikationsauflagen, Zulassung Studierende mit indiv. Diplom-studiengang)
ZulassungStudium
Studien- undPrüfungsabteilung
(STAB)Studium
Student/-in
Abbildung 19: Funktionszuordnungsdiagramm „Zulassung Studium“
Bemerkungen:Zulassungen von Studenten sollten in Zukunft nur mit vorheriger Terminvereinbarung systemunterstützt zwischen der STAB und den Studenten stattfinden. Ein Großteil der Datenmenge wäre also beim Zulassungsantrag vom Studenten ins System zu stellen, und ein Termin würde vom Studenten ausgewählt werden. Leider muß man, um einen Mißbrauch der Terminvereinbarung auszuschließen, diesen Antrag direkt mit der Zahlung eines Kostenbeitrages (ÖH-Beitrag) verbinden. Die Zulassungsprozedur sieht daher die Integration von Kreditkartenzahlungen bei der Einwahl über Internet oder Quick-Card-Bezahlung bei Zugriff über WU-eigene Terminals vor. Sollte dies Probleme bereiten, wäre als Serviceeinrichtung in der STAB ein Schalter zur Betreuung für Studenten ohne Termin einzurichten (dies ist auf jeden Fall sinnvoll in der Phase der Systemeinführung).
Wichtig ist die Vergabe einer vorläufigen Kennung, die der Student zur Anmeldung bei Lehrveranstaltungen erhalten sollte – gerade für Studenten aus dem Ausland (Austauschstudenten) ein von der ZAS geforderter Service. Sollte die Zulassung nicht innerhalb einer festgesetzten Frist erteilt werden, erlöschen diese Anmeldungen.
Seite 50 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nach Erteilung der Zulassung am Schalter wird von der STAB eine Chipkarte als Studentenausweis ausgegeben, die neben der Legitimationsfunktionalität auch Zahlungsfunktionen integriert. Die Karte sollte als Rohling von der STAB mit den notwendigen Daten und den digitalen Lichtbildern der Studenten – auch in einer Servicestelle der WU (am besten direkt in der STAB) aufgenommen – nur noch bestückt werden (Variante 1 des Grobkonzepts). Die Chipkartenbetreuung sollte auch in der STAB angesiedelt sein.
Unterschieden wird in den Prozessen zwischen einer Zulassung mit allg. Zulassungsvoraussetzungen und mit besonderen Zulassungsvoraussetzungen, wobei letztere Rahmenbedingung die Integration der StabDat in das neue System erfordert mit umfangreichen Drag- und Drop-Funktionalitäten und Layout-Gestaltungsmaßnahmen. Weitere Prozeßszenarien wurde geschaffen mit der Zulassung mit Nostrifikationsauflagen, der Zulassung mit Studienberechtigungsprüfung und der Zulassung zum individuellen Diplomstudiengang, in der unter Umständen das Rektorat und die Studienkommissionen befragt werden müssen. Bei der Zulassung mit Auflagen zum Ziel der Nostrifikation sollte eine Fristverlängerung durch die STAB möglich sein; auch sollte der Student an das Fristende über E-Mails erinnert werden.
Siehe auch Kapitel 5.2.3 im Grobkonzept.
Nutzenpotential: Zulassung Studium
Verwaltung
Plus STAB: Abschaffung des Studienblattes
STAB: Kontakttermine werden im voraus elektronisch vereinbart - optimale Kapazitätsauslastung möglich
STAB: Zulassungsdaten der Studenten werden im voraus im System eingegeben – geringe Dateneingabe und Datenverwaltung in Papierform mehr.
STAB: Plausibilitätsprüfungen finden beim Dateneintrag im System automatisch statt.
STAB: statistische Auswertungen können direkt durch das System vorgenommen werden - Eintrag von Codierungen (zumindest eines großen Teiles) fallen weg.
Erstellt gemeinsam mit 15. April 1998 Seite 51 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Zulassung Studium
STAB: kein manueller Datenabgleich zwischen STEP und STAB-DAT mehr nötig (Funktionen integriert in 2gether).
STAB: keine Verschickung von Semesteretikett nötig .
STAB: neue Terminvereinbarung mit zurückgestellten Studenten wird systemunterstützt möglich sein.
STAB: Groupware-Funktionalitäten beschleunigen Genehmigungsverfahren bei ind. Diplomstudiengängen und Studienberechtigungsprüfungen.
STAB: Prüfungsbescheid mit Fächern wird automatisiert erstellt.
STAB: Analysen bzgl. Studienberechtigungsprüfungen können aus dem System abgerufen werden.
STAB: statistische Analysen umfangreich möglich über ‘2gether’ - bisher in der STAB-DAT nur beschränkt möglich.
STAB: ‘2gether’ wird die Aufnahme mit Auflagen zum Studium (z.B. Fachhochschulabsolventen zu Doktoratsstudium mit Auflagen) unterstützen müssen, was bisher nicht von STEP unterstützt wurde.
Minus
STAB: möglicherweise Mißbrauch des Fernzulassungsantrags (z.B. über Internet), da eine Legitimierungsüberprüfung unmöglich ist. Falsche systemunterstützte Terminierung ist zu überprüfen (eingeschränkt bei ÖH-Betragsabbuchung beim Zulassungswunsch).STAB: möglicherweise mangelnde Auslastung bei Nichterscheinen der Studenten zu den Terminen.STAB: Abweisung von Studenten ohne Termin problematisch (zumindest in der Anfangsphase).STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitarbeiterumschulung.STAB: digitale Lichtbilder müssen angefertigt werden.
ZID
Plus kein Druck der Zulassungsunterlagen nötig (Studienblatt, Semesteretikett, Zahlschein etc.)
Studierende
Seite 52 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nutzenpotential: Zulassung Studium
Plus Schnellere ZulassungFernzulassungsantrag möglichSchnellere Bearbeitungszeit am SchalterDurch Terminierung geringere Wartezeit vor dem SchalterMehr Zahlungsmöglichkeiten durch ChipkarteÖH: automatische Rückerstattung des ÖH-Beitrags bei zurückgewiesenen Studenten
Minus
Daten zur Zulassung müssen selbst in ‘2gether’ eingetragen werdenZusätzlich zum Studentenausweis muß ein „wallet“ zur Authentifizierung außerhalb der Universität (Kinos etc.) finanziert werden.
4.1.2.2 Rückmeldung Studium(Rückmeldung Studierende mit Zahlschein, Rückmeldung Studierende ohne Zahlschein)
P*
Rück-meldungStudium
Studien- undPrüfungsabteilung
(STAB)
Student/-in
ZIDStudium
Abbildung 20: Funktionszuordnungsdiagramm „Rückmeldung Studium“
Bemerkungen:
Erstellt gemeinsam mit 15. April 1998 Seite 53 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
In Prozeßketten (eEPK) wird die Rückmeldung der Studenten in zwei Szenarien beschrieben; zum einen für eine Rückmeldung ohne Zahlschein, zum anderen für eine Rückmeldung mit Zahlschein.
Bei einer Rückmeldung ohne Zahlschein wird die Bezahlung des ÖH-Beitrags und die Rückmeldung über Internet oder WU-interne Terminals vorgenommen; im ersten Fall muß ein Karteneintrag der Rückmeldung nachträglich von den Studenten am System vorgenommen werden können. Bei Bezahlung mit Zahlscheinen mit Scancodes erfolgt der Dateneintrag der Bezahlung über einen Datenabgleich mit der Bank - Vermerk der Rückmeldung im Ausweis muß vom Studenten auch hier direkt an den WU-Terminals nachgetragen werden. Bezahlungen mit Zahlscheinen ohne Scancodes sollten die Ausnahme bilden, da sich der Verwaltungsaufwand sehr umfangreich darstellt. Wichtig sind zur Rückmeldung automatisch vom System generierte Erinnerungsfunktionalitäten, als auch die Möglichkeit der Prüfung der Rückmeldung online im System durch die Studenten. Sowohl Rückmeldungen ohne Bezahlung des ÖH-Beitrags (bei Zulassung an anderen Universitäten), als auch Bezahlungen ohne Rückmeldung sollten möglich sein.
Siehe auch Kapitel 5.2.4 im Grobkonzept.
Nutzenpotential: Rückmeldung Studium
Verwaltung
Plus STAB: keine Datenüberspielung der Bankdaten anzustoßen (bei Bezahlung mit Zahlschein mit Scancode)STAB: Rückmeldung und Bezahlung des ÖH-Beitrags in den meisten Fällen ohne Schalterbetreuung der StudentenSTAB: automatische Ermahnung wird an Studenten geschickt beim Erreichen des Rückmeldefristendes minus einer WocheSTAB: Rückmeldemerkmal wird auf Chipkarte automatisch gesetzt (Ansicht über „wallets“)
Minus
STAB: Betreuung der Studenten am Schalter nötig bei Rückmeldung über Internet (Chipkarteneintrag der Rückmeldung), falls automatischer Chipkarteneintrag fehlschlägt (wie heute über Reklamation zu lösen).
Studierende
Seite 54 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nutzenpotential: Rückmeldung Studium
Plus Rückmeldung ohne Zahlschein möglichFernrückmeldung möglich
4.1.2.3 Zusatzstudium/Wechsel des Studiums
P*
Zusatzstudium/Wechsel des
StudiumsStudent/-in
Studien- undPrüfungsabteilung
(STAB)
Studium
Lehrver-anstaltung
Prüfung
Anerkennung
Studienplan
Abbildung 21: Funktionszuordnungsdiagramm „Wechsel Studium/Aufnahme Zusatzstudium“
Bemerkung:Bei Wechsel und Aufnahme von Studien innerhalb der WU-Wien sollte zuerst von den Studenten am Terminal überprüft werden, ob eine automatisch generierte Anerkennung von Studienleistungen und Aufnahme des neuen Studiums möglich ist. Nur - und das sollte eine Minderheit der Fälle betreffen - bei Negation des Systems ist die STAB zu kontaktieren, die dann die Entscheidung zu treffen hat.
Bei der Genehmigung durch das System werden vorher alle Voraussetzungen des Studenten geprüft und daraus die notwendigen Aktionen abgeleitet. Kann das System die entsprechenden Wünsche des Studenten nicht vollziehen, sollte eine Ablehnung angezeigt werden.
Siehe auch Kapitel 5.2.5 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 55 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Zusatzsturium/Wechsel des Studiums
Verwaltung
Plus STAB: Automatische Prüfmöglichkeit für Studenten durch das System, ob Studienwechsel oder Zusatzstudium möglich ist.STAB: Dateneintrag für Studienwunsch direkt durch die Studenten am System.STAB: Automatische Leistungsanrechnungen für Ergebnisse, die an der WU erbracht wurden (im Normalfall).STAB: Keine Schalterbetreuung der Studenten nötig (im Normalfall).STAB: Zulassungsbestätigung wird vom Student ausgedruckt.
Studierende
Plus Studienwechsel und Zusatzstudium schnell direkt am System.Prüfungen über verschiedene Studienszenarien direkt am System.
4.1.2.4 Beendigung Studium(Beendigung des Studiums, Beendigung des Sonderstudiums)
P*
BeendigungStudium
Student/-in
Studien- undPrüfungsabteilung
(STAB)
Bibliothek
ZID
Institut/Abteilung
Studium
Abbildung 22: Funktionszuordnungsdiagramm „Beendigung Studium“
Seite 56 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Bemerkungen:In der Prozeßkette „Beendigung des Studiums“ (eEPK) kann man den gewünschten Ablauf zur Studienbeendigung verfolgen. Natürlich müssen bei Studienbeendigung Folgeaktivitäten angestoßen werden, die aufgrund der sehr dezentralen Verteilung idealerweise von dem System angesteuert und verwaltet werden sollten - z.B. per Jobverteilung.
Unterstützung findet z.B. die STAB durch Erinnerungsfunktionalitäten des Systems, das informiert, wenn die Voraussetzungen der Beendigung des Studiums für einen Studenten gegeben sind. Auch werden einige Bescheide (Abgangsbescheide, Feststellungsbescheide) in Zukunft direkt vom Studenten am System ohne größeren Verwaltungsaufwand ausgedruckt werden können .
Hier, wie auch teilweise in den anderen Prozessen, böte sich eine Unterstützung durch eine Workflow-Funktionalität an, da eine starre Ablaufstruktur mit relativ hohem Mengengerüst bearbeitet wird.
Die Prozeßkette „Beendigung des Sonderstudiums“ beschreibt die leicht geänderte Situation bei Studien mit Auflagen, Studien mit Studienberechtigungsprüfungen und individuellen Diplomstudiengängen (zu beachten: Sonderstudien ist ein nur vom Projektteam der Beratungsunternehmen definierter Begriff zur kürzeren Prozeßetikettierung).
Siehe auch Kapitel 5.2.6 im Grobkonzept.
Nutzenpotential: Rückmeldung Studium
Verwaltung
Plus STAB: Salden der Abrechungskonten werden direkt am System geprüft.STAB: Deaktivierung des Studentenstammsatzes, Chipkartendeaktivierung und Generierung des Abgangsbescheids erfolgt automatisch.STAB: automatische Abmelde-Information (per E-Mail) wird an entsprechende Stellen verschickt - z.B. um Powernetkennung zu löschen.STAB: automatische Prüfung, ob erzwungene Abmeldung erfolgen muß, und Einleitung von Schritten.STAB: Abgangsbescheinigung und Feststellungsbescheid werden vom Studenten selbst ausgedruckt.
Erstellt gemeinsam mit 15. April 1998 Seite 57 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Rückmeldung Studium
Minus
STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitarbeiterumschulung.
Quästur
Plus Kontenabrechnung wird automatisch angestoßen und ausgeführt.
Studierende
Plus Abmeldungswunsch kann direkt am System erfolgen ohne Schalterkontakt.Fernabmeldung möglichkeine „Stellenrundgang“ nötig (PowerNet-Kennung löschen, Kontenabrechnung etc.).
4.1.2.5 Erstellung Diplomzeugnis
P
ErstellungDiplomzeugnis
StudiumStudiendekan/
Vizestudiendekan
Studien- undPrüfungsabteilung
(STAB)
Student/-in
Abbildung 23: Funktionszuordnungsdiagramm „Erstellung Diplomzeugnis“
Bemerkung:
Seite 58 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Auch die Diplomzeugniserstellung kann durch das System sinnvoll unterstützt werden, zieht man in Betracht, daß das Studiendekanat eingebunden werden kann durch direkte Jobvermittlung. Während hier das Mengengerüst (ca. 1200/a) eine vorgegebene Ablaufunterstützung fordert, können bei der Verleihung des Doktortitels (ca. 100/a) auch Ad-hoc-Funktionalitäten des Systems zum Zuge kommen.
4.1.3 Lehrveranstaltungen
*
AdministrationLehrver-
anstaltung
*
Lehrver-anstaltungen
*
Planung vonLehrver-
anstaltungen
*
Aufnahme vonLehrver-
anstaltungen
*
Lehrver-anstaltungen
administrieren
Abbildung 24: Funktionsbaum „Lehrveranstaltung“
Bemerkungen:Geplant ist eine Einbindung aller LV-Leiter bei der Eingabe der Daten zur Lehrveranstaltung direkt in das System 2gether. Natürlich wird eine Akzeptanz kritisch von der Anwenderfreundlichkeit des Systems und von der Vertrautheit dem System gegenüber abhängen sowie von umfangreichen Zugriffsmöglichkeiten. So sollte ein Dateneintrag auch von außerhalb der WU-Wien über das Internet möglich sein, um externe Dozenten einbeziehen zu können. Durch die tägliche Arbeit mit dem System ‘2gether’ über Groupwise-Funktionalitäten, wie Jobverwaltung, Terminplanung und E-Mail-
Erstellt gemeinsam mit 15. April 1998 Seite 59 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Verwaltung, und unterstützende Module bei der Administration der Lehrveranstaltung (siehe das Modell „Lehrveranstaltungen administrieren“) sollte eine intuitive Benutzerführung für den LV-Leiter gegeben sein. Natürlich kann der LV-Leiter seine Tätigkeiten am Institut über eine Delegation der Benutzerrechte verwalten lassen; dies sollte jedoch eher die Ausnahme als die Regel sein.
Siehe auch Kapitel 5.3 im Grobkonzept.
4.1.3.1 Planung von Lehrveranstaltungen
P*
Planung vonLehrver-
anstaltungen
Institut/Abteilung
LV-Leiter/-in
Büro desStudiendekans
Rechts - undOrganisations-
abteilung
Abt.-/Inst.-Leiter/-in
Druckerei
Fachbereich
Studien-dekan
Lehrver-anstaltung
Raum-verwaltung
Studienplan
Vorlesungs-verzeichnis
Abbildung 25: Funktionszuordnungsdiagramm „Planung Lehrveranstaltung“
Bemerkungen:Der Prozeß, der im Vorfeld des Semesters zur Planung von Lehrveranstaltungen und zur Erstellung des VVZ durchlaufen werden muß, wird in Form einer eEPK wiedergegeben.
Bei Planung einer Lehrveranstaltung im System sollte auf eine Datenbasis bereits abgehaltener Lehrveranstaltungen zurückgegriffen werden können. Eine „Revitalisierung“ dieser Lehrveranstaltungen kann dann jederzeit möglich sein; mitsamt der dazugehörigen Anmeldemodalitäten, Beschreibungen, Terminwünsche etc.. Auch eine Präferenzliste von Hörsälen und Terminen sollte bearbeitet werden, um eine möglichst optimale Zuordnung aller Hörsäle gewährleisten zu können.
Seite 60 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Automatisch werden die vor zwei Semestern stattgefundenen Lehrveranstaltungen zur Erstellung des VVZ berücksichtigt, in denen nur die Daten korrigiert werden müssen. Bei der Zuordnung der Hörsäle durch die Rechts- und Organisationsabteilung sind mehrere Szenarien möglich. Sinnvoll wäre gewiß eine systemberechnete Optimierung, die jedes Semester durchgeführt werden würde, einschließlich der damit verbundenen optimalen Auslastung aller Hörsaal-Kapazitäten. Allerdings würden damit liebgewonnene Gewohnheiten aufgegeben werden müssen - so könnte jedes Semester eine Lehrveranstaltung in einem anderen Hörsaal stattfinden. Sicher wäre das zweite Szenario vorzuziehen, in dem jede Lehrveranstaltung nur bei gewünschter Änderung der Hörsaalzuordnung und bei Neuplanung optimiert vom System einem Raum zugeordnet wird. Unterstützt würde diese Prozedur durch eine Hörsaalbörse, die z.B. in einem Forum des Groupwise-Systems abgewickelt werden könnte, und in der mit Benachrichtigung der Rechts-Organisationsabteilung Hörsäle getauscht werden können. Weitere Maßnahmen zur einer Verbesserung der Kapazitätsausnutzung wären eine Online-Einsicht in die aktuellen Daten der Hörsaalbelegung und ein Warnsystem bei großer Diskrepanz der Teilnehmer einer Lehrveranstaltung (natürlich auch bei Prüfungen) zu der Hörsaalkapazität - aufgrund dieses Sachbestandes könnte automatisch eine Nachricht an den Studiendekan generiert werden, der weitere Schritte einzuleiten hätte. Während des Semesters wäre wegen einer Raumbelegung bei der Hörsaalverwaltung anzufragen, die eine Servicestelle für die Institute/Abteilungen bilden sollte – also auch bei kurzfristigem Ausfall einer Lehrveranstaltung für Informationen direkt am Hörsaal sorgen sollte.
Vorteilhaft wäre für die Institute/Abteilungen auf jeden Fall die immer – auch im Semester – gegebene Einsichtsmöglichkeit in aktuelle Daten zu den Lehrveranstaltungen, da das VVZ im Internet ständig aus dem System heraus aktualisiert werden würde mit automatisch generierten Links zu den Internetseiten der Institute/Abteilungen. Somit wäre der Versorgung des Informationsbedarfs der Studenten bei Wartung der Daten im System Sorge geleistet. Auch eine Papierversion des VVZ sollte am Anfang des Semesters gedruckt werden, damit auch an nicht computerunterstützten Lokalitäten – wie z.B. Bushaltestellen – eine Einsicht und Suche in angebotene Lehrveranstaltungen möglich wäre.
Aufgrund der zu erwartenden schnelleren Durchlaufzeit bei der Erstellung des VVZ - kein Hausposttransport von Fahnen, Waschzetteln etc. zur Korrektur, systemunterstützte Abfragemöglichkeiten im System bzgl. Hörsaalbelegung, Datenvollständigkeit und Korrektheit des Lehrveranstaltungsspektrums und weltweiter Zugriff auf die Daten - kann der Beginn der Planung deutlich näher an den Semesterbeginn gelegt werden, womit wiederum akkuratere Daten eingetragen werden können.
Erstellt gemeinsam mit 15. April 1998 Seite 61 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Auch werden planungsrelevante Einträge im System – wie z.B. Anmeldefristen, max. Teilnehmerzahl, Anmeldemodalitäten – von den Instituten/Abteilungen durchgeführt werden, so daß Anmeldungen bis kurz vor Vorlesungsbeginn und auch darüber hinaus möglich sein werden und so die Bearbeitung von Nachmeldefristen größtenteils wegfallen kann.
Ein wichtiges Werkzeug zur Unterstützung der Planung von Lehrveranstaltungen bildet die Budgetsimulation, in der die Berechnung von Kostenwerten zu möglichen Lehrveranstaltungsszenarien systemgeneriert durchgeführt werden kann, und so Institute, aber auch die Fachbereiche und das Studiendekanat schnell an wichtige Kontrolldaten gelangen können. Natürlich sind auch andere Regelhinterlegungen bei Prüfungsdefinition denkbar – so z.B. die Prüfung der Vollständigkeit des Lehrangebots und der Vermeidung von Überschneidungen. Um diese Prüfungen systemunterstützt durchführen zu können ist die Wartung der Studienpläne im System unbedingt erforderlich – dies sollte von der STAB durchgeführt werden mit einer Drag- and Drop-Funktionalität auf Systemseite.
Siehe auch Kapitel 5.3.1 im Grobkonzept.
Nutzenpotential: Planung von Lehrveranstaltungen
Institute/Mittelbau
Plus Erinnerung bzgl. Beschreibung einer neuen LV und bzgl. Erhebungsbogen eines neuen LV-Leiters wird automatisch zugestellt.Lehrveranstaltungsankündigung, Erhebungsbogen und Remunerationsantrag können direkt am System bearbeitet und per E-Mail weitergeleitet werden (keine Hauspost).Erhebungsbogen und Lehrveranstaltungsankündigung brauchen (im Normalfall) nicht mehr verwaltet werden (wird direkt vom LV-Leiter bearbeitet).Budgetsituationen können schon bei der Grobplanung des VVZ überprüft werden.Verifizierung der VVZ-Daten in der Grobplanung braucht (im Normalfall) nicht mehr verwaltet zu werden (wird vom LV-Leiter direkt bearbeitet).Simulationen versch. Szenarien sind immer möglich - Überprüfung von Budget-Rahmenwerten.Kommentar zu Lehrveranstaltungen werden direkt im System gepflegt und sind im VVZ abrufbar.
Seite 62 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nutzenpotential: Planung von Lehrveranstaltungen
Institute/Sekretariate
Plus Lehrveranstaltungsankündigung, Erhebungsbogen und Remunerationsantrag können direkt am System bearbeitet und per E-Mail weitergeleitet werden.Budgetsituationen können schon bei der Grobplanung des VVZ überprüft werden (per automatischer Überprüfung).Verifizierung der VVZ-Daten in der Grobplanung braucht (im Normalfall) nicht mehr verwaltet werden (wird vom LV-Leiter direkt bearbeitet).keine Verschickung der VVZ-Versionen mehr nötig (1.Version oder spätere Versionen) - direkte Eingabe in das System.Automatische Erstellung von Adressenangaben auf den zu versendeten Dokumenten bei LV-Leitern ohne E-Mail.Simulationen versch. Szenarien sind immer möglich - Überprüfung von Budget-Rahmenwerten.Keine „Waschzettel“ und „Fahnen“ mehr zu bearbeiten.
Minus
bei manchen (meist externen) LV-Leitern werden häufig die Daten von den Sekretariaten ins System eingegeben werden müssen - bisher wurden die in Schriftform vorliegenden Daten an die Verwaltung zur Verwertung weitergegeben.
Verwaltung
Plus Rechts- und Organisationsabteilung: keine Papierverwaltung bzgl. Erhebungsbögen und Lebenslauf mehr notwendig.Rechts- und Organisationsabteilung: kein Druck der Lehrveranstaltungsankündigungen.Rechts- und Organisationsabteilung: keine Papierverwaltung der Lehrveranstaltungsankündigungen.Rechts- und Organisationsabteilung: kein Ausdruck und Zuschicken des Grobplanungs-VVZ (an externe Druckerei) mehr notwendig.Rechts- und Organisationsabteilung: keine Eingabe der Institutsdaten zur Erstellen des Grobplanungs-VVZ mehr nötig.Rechts- und Organisationsabteilung: bei Vollständigkeits- und Korrektheitsprüfungen werden fehlerhafte LV-Beschreibungen automatisch
Erstellt gemeinsam mit 15. April 1998 Seite 63 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Planung von Lehrveranstaltungen
aufgelistet.Rechts- und Organisationsabteilung: Hörsaalvergabe wird durch das System unterstützt.Rechts- und Organisationsabteilung: kein Ausdruck der 1.Version VVZ zur Korrektur nötig.Rechts- und Organisationsabteilung: keine Eingabe der Institutsdaten zur Erstellen des 1.Verson und freigegebener Version des VVZ mehr nötig.
Minus
Erinnerungsmail ist den Instituten zur Überarbeitung des Grobplanungs-VVZ zustellen (E-Mail) - wird automatisch für alle Institute generiert (nur auszulösen).
Studiendekanat
Plus keine Papierverwaltung der Remunerationsanträge notwendig.keine Papierverwaltung bzgl. der LV-Kontingenterhebung nötig.Budgetsituationen können automatisch überprüft werden.
Allgemein
Plus Planungsprozeß des VVZ wird wesentlich beschleunigt.
Studierende
Plus Einsicht in das VVZ schneller möglich und direkt über das Internet (mit anspruchsvoller Gestaltung der Web-Seiten).
Fachbereiche
Plus Budgetsituationen können automatisch überprüft werden.
Seite 64 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.3.2 Aufnahme von Lehrveranstaltungen
P*
Aufnahme vonLehrver-
anstaltungen
LV-Leiter/-in
Institut/Abteilung
Rechts - undOrganisations-
abteilung
ZID
Lehrver-anstaltung
Abbildung 26: Funktionszuordnungsdiagramm „Aufnahme Lehrveranstaltung“
Bemerkungen:
Alle Aktivitäten, die am Anfang der Durchführung einer Lehrveranstaltung stehen, sind in einer eEPK festgehalten.
Geplant ist der Wegfall der LV-Beginnmeldungen. An ihre Stelle tritt die automatische Versendung von Beauftragungsbescheiden per E-Mail zwecks Information der LV-Leiter und die Quittierung der LV-Aufnahme mit elektronischer Unterschrift im System von den LV-Leitern. Eine Reduzierung dieses Arbeitsgebietes auf eine Quittierung nur bei Nichtaufnahme einer Lehrveranstaltung läßt sich leider aus rechtlichen Gründen momentan nicht fordern.
Eine Quittierung der Teilnehmerzahl nach ca. 4-5 Wochen nach Beginn der Lehrveranstaltung erscheint sinnvoll im Hinblick auf spätere Planungsaktivitäten und einer automatischen Generierung von Teilen des Evaluierungsreports aus dem System heraus.
Siehe auch Kapitel 5.3.2 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 65 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Aufnahme von Lehrveranstaltungen
Institute/Mittelbau
Plus Keine Kontaktaufnahme zum LV-Leiter und Zusendung der LV-Beginnmeldungen nötig.Kein Einsammeln der LV-Beginnmeldungen von den LV-Leitern nötig (im Normalfall)Kein Bearbeiten von LV-Beginnmeldungen mehr.Hörereintrag und Quittierung der Aufnahme der LV im System ‘2gether’ dient direkt den Evaluierungsberichten und Arbeitsberichten der Institute.Ständig Information über aktuellen Stand des VVZ im Internet.Schnellere Bezahlung der LV-Leiters wg. Wegfall der Beginnmeldung in Papierform.Bearbeitung und Verwaltung der „Teilnehmerliste“ (Meldung der Höreranzahl an das Studiendekanat) fällt weg.
Institute/Sekretariate
Plus Keine Kontaktaufnahme zum LV-Leiter und Zusendung der LV-Beginnmeldungen nötig.Kein Weiterleiten der Dokumente an die Rechts- und Organisationsabteilung nötig.kein Dateneintrag in einem DV-System (z.B. Wufis) nötig (im Normalfall). keine Bearbeitung von LV-Beginnmeldungen mehr.Bearbeitung und Verwaltung der „Teilnehmerliste“ (Meldung der Höreranzahl an das Studiendekanat) fällt weg.
Verwaltung
Plus Rechts- und Organisationsabteilung: automatisch generierte E-Mail (Beauftragungsbescheide) an den LV-Leiter anstatt der Erstellung und Versendung der schriftlichen LV-Beginnmeldungen an die Institute (im Normalfall).Rechts- und Organisationsabteilung: automatische Selektion der nicht bearbeiteten LehrveranstaltungenRechts- und Organisationsabteilung: keine Einmahnungen an die InstituteRechts- und Organisationsabteilung: automatische Generation der
Seite 66 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nutzenpotential: Aufnahme von Lehrveranstaltungen
Benachrichtigung an den Studiendekan (nur Freigabe der automatisch generierten E-Mail)Rechts- und Organisationsabteilung: kein Anstoß zur Datenübernahme zwischen WUFIS und STEP nötigRechts- und Organisationsabteilung: kein Vergleich der LV-Beginnmeldungen und den Einträgen im STEP-System nötigRechts- und Organisationsabteilung: keine Bearbeitung von zurückgemeldeten LV-Beginnmeldungen mehr.
ZID
Plus kein Druck der LV-Beginnmeldungen nötig
4.1.3.3 Lehrveranstaltungen administrieren
F*
Lehrver-anstaltungenadministrieren
Lehrver-anstaltung
Institut/Abteilung
LV-Leiter/-in
Student/-in
Studien-dekanat
Abbildung 27: Funktionszuordnungsdiagramm „Administration Lehrveranstaltung“
Bemerkungen:
Erstellt gemeinsam mit 15. April 1998 Seite 67 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Aufgeführt in einem Funktionsbaum sind die wesentlichen Funktionalitäten, die ein zukünftiges System zur Administration der Lehrveranstaltungen anbieten sollte.
Über die Anmeldelisten lassen sich wesentliche Daten zur Beschreibung der Leistung der Teilnehmer erfassen, wie z.B. Anwesenheit, Zwischennoten, Endnoten. Das Layout dieser Listen im System sollte von Seite der Institute/Abteilungen definierbar sein; interessant wäre eine Tabellenstruktur, deren Köpfe entsprechend den Anforderungen etikettiert werden könnten. Auch eine Vorgabe der tatsächlichen LV-Termine im Semester wäre sinnvoll (wobei Feiertage und Rektoratstage etc. schon bereinigt wären). Wichtig ist eine intuitive Benutzerführung und die Möglichkeit der Datenfreigabe der Einträge zwecks Information der Studenten.
Siehe auch Kapitel 5.3.3 im Grobkonzept.
4.1.4 Prüfungen
PlanungPrüfungstermin
*
Prüfungen
*
Planung vonPrüfungen
*
Leistungs-feststellung
*
Abbildung 28: Funktionsbaum „Prüfung“
Bemerkungen:
Seite 68 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Angestrebt wird, ein virtuelles Prüfungsamt im System abzubilden. Dazu sollten Tätigkeiten der Prüfungsreferate der STAB auf die systemunterstützte Mitarbeit der Studenten umgelegt werden. Hinzukommen sollte die Mitarbeit der Prüfer an den Abteilungen/Instituten, die die relevanten Daten direkt in das System eingeben.
Siehe auch Kapitel 5.4 im Grobkonzept.
4.1.4.1 Planung von Prüfungen
P*
Planung vonPrüfungen
LV-Leiter/-in
Büro desStudiendekans
Studien- undPrüfungsabteilung
(STAB)
Hörsaal-verwaltung
Prüfung
An- undAbmeldung
Raum-verwaltung
Abbildung 29: Funktionszuordnungsdiagramm „Planung Prüfungstermin“
Bemerkungen:Regelmäßig stattfindende Prüfungen werden schon automatisch vorgeplant im System und im WU-Kalender entsprechend festgehalten. Alle unregelmäßig stattfindenden Prüfungen sollten vorher, über die Hörsaalverwaltung, einen Termin mit Raumbelegung reserviert bekommen – bei der Absprache können Groupware-Eigenschaften des zukünftigen Systems eingesetzt werden.
Zur Unterstützung der Erstellung von Prüfungsunterlagen sollten Ausdrücke („Deckblätter“) aus dem System möglich sein mit den Personalien und den Terminen des Prüflings – diese können dann den Prüfungsfragen oder bei mündlichen Prüfungen dem Prüfungsprotokoll beigefügt werden.
Erstellt gemeinsam mit 15. April 1998 Seite 69 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Die Prüfer sollten direkt die Daten in das System eingeben – auch hier ist ein Dateneintrag über das WWW vorzusehen, um externe Prüfer miteinzubeziehen.
Siehe auch Kapitel 5.4.1 im Grobkonzept.
Nutzenpotential: Planung von Prüfungen
Institute/Mittelbau
Plus Hörsaalvergabe wird durch das System unterstützt (Groupware, Optimierungsalgorithmen)bei generierter Anmeldeliste Unterscheidung, ob mündliche oder schriftliche Prüfung erfolgen soll.Deckblätter bei Unterlagen für Prüfungen (mit Personaldaten) werden automatisch erstellt aus dem System heraus.Daten der Prüfungen sollten direkt vom Prüfer in das System eingegeben werden (keine schriftliche Datenweitergabe mehr).maximale Teilnehmerzahl muß nach Hörsaal-Vergabe automatisch auf die max. Kapazität des Hörsaals beschränkt werden. aktuelle Informationen über Anmeldeliste im System - keine Papierbearbeitung bzgl. Abfragen mehr nötig.Bestimmung der Anmeldefristen etc. durch das Institut selbst (und nicht mehr durch die STAB). Dadurch können Nachmeldefristen vermieden werden.
Minus
Planungstermine müssen in das System eingegeben werden (bisher teilweise Festlegung von der STAB).
Institute/Sekretariate
Plus Hörsaalvergabe wird durch das System unterstützt (Groupware, Optimierungsalgorithmen). Anmeldelisten werden von den Studenten selbst gepflegt.
Verwaltung
Plus STAB: Hörsaalvergabe wird durch das System unterstützt (Groupware,
Seite 70 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nutzenpotential: Planung von Prüfungen
Optimierungsalgorithmen).STAB: Prüfungsliste muß nicht mehr vor Semesterbeginn erstellt und an die Institute verschickt werden.STAB: bearbeitete Prüfungsliste muß nicht mehr entgegengenommen werden.STAB: bearbeitete Prüfungsliste muß nicht mehr für die Hörsaalverwaltung umgeschrieben werden.STAB: die Erstellung des Prüfungskalenders erfolgt vollautomatisch.STAB: Korrekturen bei Hörsaal - Änderungen müssen nicht mehr eingetragen werden.STAB: Einträge in das WWW sind nicht mehr nötig.STAB: Anmeldeformulare zur Prüfung sind nicht mehr zu bearbeiten.STAB: Zulassungsvoraussetzungen zur Prüfung sind nicht mehr zu prüfen.STAB: Anmeldeliste für Prüfungen sind nicht mehr zu erstellen und zu verschicken.STAB: Anmeldeliste der Prüfungen ist nicht mehr auszudrucken und auszuhängen.Hörsaalverwaltung: Hörsaalvergabe wird durch das System unterstützt (Groupware, Optimierungsalgorithmen).Hörsaalverwaltung: Hörsaalvergabe wird durch das System ständig kontrolliert und bei Fehlern werden Mahnungen verschickt.
Studierende
Plus Fernanmeldung zu Prüfungen möglich.Kein Anmeldeformular auszufüllen und einzuwerfen.Kein Einreichen von Sammelzeugnissen nötig.
Erstellt gemeinsam mit 15. April 1998 Seite 71 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.4.2 Leistungsfeststellung
P*
Leistungs-feststellung
Institut/Abteilung
LV-Leiter/-in
Prüfung
An- undAbmeldung
Abrechnung
Abbildung 30: Funktionszuordnungsdiagramm „Leistungsfeststellung“
Bemerkung:Die Noteneingabe sollte direkt vom Prüfer am System vorgenommen werden - externe Dozenten können über das Internet auf das System zugreifen. Nach Noteneintrag in eine Liste der dem Prüfer im Semester zugeteilten Prüfungen wird per E-Mail automatisch an den Studenten die Benotung verschickt mit Angabe der vom Institut beschlossenen Einsichtsfrist (nicht zu verwechseln mit der rechtlichen Einsichtsfrist). Notenabfragen durch die Studenten werden auch jederzeit über IVR und Internet möglich sein, so daß Anfragen in den Instituten/Abteilungen entfallen sollten. Die Auswahl der angezeigten Daten sollte vom Prüfer leicht im System zu definieren sein (Anwählen von Tabellenköpfen). Zusätzlich wird das zu erwartende Datum der Noteneingabe jederzeit im Internet einzusehen sein.
Nach Abschluß der Einsichtsfrist gibt der Prüfer die Daten mit seiner elektronischen Unterschrift frei - im Nachhinein sollten nur noch Änderungen mit Genehmigung des Prüfers eingegeben werden können, wobei fundamentale Änderungen für die Abrechnung der Rechts- und Organisationsabteilung mitgeteilt werden sollten.
Prüfungsprotokolle, bisher in Papierform, müssen nicht mehr bearbeitet werden. Zeugnisse sollten - soweit angestrebt - von den Studenten direkt vom System ausgedruckt werden mit maschineller Unterschrift (ausgenommen Diplomzeugnisse und Promotionszeugnisse).
Seite 72 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Siehe auch Kapitel 5.4.2- 5.4.3 im Grobkonzept.
Nutzenpotential: Leistungsfeststellung
Institute/Mittelbau
Plus Nur einmalige Noteneingabe in Instituten - keine zusätzlichen Excel - Listen oder andere Systemeinträge ( PC-Levis, WUFIS) nötig.Prüfungsergebnisse werden normalerweise vom Prüfer direkt in das System eingegeben (Delegation möglich).Prüfungsprotokoll muß nicht mehr bearbeitet werden (Eintrag in BTX, Kontrolle der Ausdrucke, Bestätigung und Unterschrift).
Institute/Sekretariate
Plus Nur einmalige Noteneingabe in Instituten - keine zusätzlichen Excel - Listen oder andere Systemeinträge ( PC-Levis, WUFIS) nötig.Keine Korrektur der von der ADV-Stelle ausgedruckten (aus WUFIS) Prüfungsprotokolle nötig.Prüfungsergebnisse werden normalerweise vom Prüfer direkt in das System eingegeben (Delegation möglich).Keine Verwaltung von Interimszeugnisse, Diplomzeugnissen mehr (Stempeln etc.).Kein Aushändigen von Zeugnisse an Studenten nötig.Falls Zweiterfassungssysteme zur Notenfestlegung benutzt werden, ist Datenüberspielung in/aus dem System ‘2gether’ (Word, Excel) möglich.
Minus
Bei vielen externen Lektoren muß doch der Papierweg gewählt werden. Dies führt dazu, daß die Sekretariate die Daten eingeben müssen, anstatt das Papier einfach weiterzuleiten.
Verwaltung
Plus STAB: Daten der ausgefüllten Anmeldelisten/Prüfungsprotokolle brauchen nicht mehr in STEP eingetragen zu werden.
Erstellt gemeinsam mit 15. April 1998 Seite 73 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Leistungsfeststellung
Minus
STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitarbeiterumschulung.STAB: Archivierung muß zugriff auf Historie sicherstellen - Bedenken bei Systemwechsel in der Zukunft.
ZID
Plus Kein Ausdruck und Versenden von WUFIS-Daten (BTX) nötig.
Studierende
Plus Automatische Benachrichtigung über Einsichtstermine.Noteninformation auch über Fernabfrage möglich.Automatische Benachrichtigung über Ergebnisse.
4.1.5 Diplomarbeiten/Dissertationen
Diplomarbeiten/Dissertationen
vereinbaren* FDiplomarbeiten/Dissertationen
betreuen* FDiplomarbeiten/Dissertationenabschließen
* P
Diplomarbeit/Dissertation
*
Seite 74 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Abbildung 31: Funktionsbaum „Diplomarbeit/Dissertation“
Bemerkungen:Für die Administration der Diplomarbeiten und Dissertationen wird in ‘2gether’ eine eigene Datenbank eingerichtet mit den wesentlichen Informationen zu den Abschlußarbeiten, so daß alle aktuellen Daten zu den laufenden und vorgeschlagenen Diplomarbeiten und Dissertationen hier zu finden sind.
Unterteilt wird in die Themengebiete der Vereinbarung, der Betreuung und der Beendigung der Abschlußarbeiten.
Siehe auch Kapitel 5.5 im Grobkonzept.
Nutzenpotential: Diplomarbeiten/Dissertationen
Institute/Mittelbau
Plus Studenten geben Daten direkt in das System ein.Themendatenbank informiert übersichtlich alle Studenten.Mustervorlagen ergeben einheitliche Formate der Arbeiten.Terminabstimmungen und Dokumententransfers können über das System getätigt werden.Informationen über einen stattgefundenen Betreuerwechsel werden automatisch vom System an die Institute versendet.
Institute/Sekretariate
Plus Studenten geben Daten direkt in das System ein.Mustervorlagen ergeben einheitliche Formate der Arbeiten.automatische Fristenüberwachung durch das SystemZweitgutachter wird vom Studiendekan direkt am System festgelegt.Betreuerwechsel kann durch das System unterstützt werden.Manuelles Karteikartensystem wg. alten Diplomarbeiten, falls vorhanden, fällt weg.
Minus
Möglicherweise höherer Wartungsaufwand wegen Nachfrage nach mehr Analysen (erweiterte Möglichkeiten durch das System verlangen aktuellere
Erstellt gemeinsam mit 15. April 1998 Seite 75 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Diplomarbeiten/Dissertationen
Daten).
Verwaltung
Plus STAB: Formular zur Genehmigung der Arbeit durch das Studiendekanat muß nicht mehr administriert werden - Abholung durch den Antragsteller, Versendung an Studiendekanat etc.STAB: Versendung der Exemplare der Doktorarbeit zur Hauptbibliothek, Nationalbibliothek erfolgt nicht mehr durch STAB.STAB: Statistikformulare müssen nicht mehr administriert werden.STAB: Erfassungsblätter zur Arbeit („Abstracts“) müssen nicht mehr administriert werden.STEP: Rigorosum-Zeugnis, Diplomarbeitszeugnis wird aus dem System ‘2gether’ ausgedruckt - kein händischer Übertrag der Daten zwischen verschiedenen Systemem mehr nötig (bisher nach StabDAT aus STEP).STAB: Herausragende Arbeiten werden dem Ausseninstitut automatisch gemeldet .STAB: Daten werden der Abrechnungsstelle automatisch mitgeteilt.STAB: Automatische Fristenüberwachung durch das System („Erinnerungsfunktion“).
Studierende
Plus Kein Besuch mehrerer Bearbeitungsstellen zum Erhalt des Sponsionsbescheids nötig.schnellere Bearbeitungszeit.Themendatenbank gibt guten Überblick über mögliche Arbeitsgebiete.
Seite 76 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.5.1 Diplomarbeiten/Dissertationen vereinbaren
F*
Diplomarbeiten/Dissertationenvereinbaren
Diplomarbeit/Dissertation
Student/-in
Betreuer/-in
Studien-dekan
Institut/Abteilung
Abbildung 32: Funktionszuordnungsdiagramm „Themenvereinbarung“
Bemerkungen:In einem Funktionsbaum sind die wesentlichen Funktionalitäten des Systems festgehalten, die bei der Vereinbarung von Diplomarbeiten und Dissertationen zum Einsatz kommen könnten.
Im Mittelpunkt steht die Themendatenbank, aus dem der Student, aber auch Interessenten außerhalb der WU-Wien, sich Vorschläge zu einer möglichen Diplomarbeit bzw. Doktorarbeit holen können. Natürlich ist dieses Angebot an die Studenten seitens der Institute/Abteilungen keine Pflicht, doch wäre es zum allgemeinen Überblick empfehlenswert alle Informationen rechtzeitig dort einzutragen. Über eine Stichwortsuche kann der Student sein Interessensgebiet weiter einengen und danach sein Interesse über das System bekunden, das weitere Terminkoordinationen zwischen Student und Institut/Abteilung regelt. Jederzeit sollte der Status der Diplomarbeit (z.B. in Bearbeitung) gepflegt werden und damit abrufbar sein.
Natürlich sollten vom System die Voraussetzungen zur Aufnahme einer Abschlußarbeit, falls möglich, geprüft werden. Jederzeit kann der Zweitgutachter im Falle einer Promotion vom Studiendekan vorgeschlagen werden (meist in Absprache mit dem Institut).
Siehe auch Kapitel 5.5.1 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 77 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.5.2 Diplomarbeiten/Dissertationen betreuen
F*
Diplomarbeiten/Dissertationen
betreuen
Diplomarbeit/Dissertation
Student/-in
Betreuer/-in
Abbildung 33: Funktionszuordnungsdiagramm „Laufende Betreuung“
Bemerkungen:In einem Funktionsbaum werden die wesentlichen Funktionalitäten bei der Betreuung der Abschlußarbeiten festgehalten.
Sinnvoll in der Systemunterstützung der Betreuung könnte der Aufbau eines Diskussionsforums zur Arbeit sein, in der z.B. Literaturdateien, eine Linkliste im WWW zu themenverwandten Seiten oder auch verschiedene Versionen der Arbeit abgelegt werden würden.
Im Falle eines Betreuerwechsels durch den Studenten würden alle betreuenden Personen informiert, wodurch das Aufkommen von „Datenleichen“ vermindert werden könnte.
Siehe auch Kapitel 5.5.2 im Grobkonzept.
4.1.5.3 Diplomarbeiten/Dissertationen abschließen
P*
Diplomarbeiten/Dissertationenabschließen
Studiendekan/Vizestudiendekan
Betreuer/-in
Student/-inStudium
Diplomarbeit/Dissertation
Abrechnung
Seite 78 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Abbildung 34: Funktionszuordnungsdiagramm „Einreichung, Beurteilung und Veröffentlichung“
Bemerkungen:In der Prozeßkette (eEPK) kann detailliert der mögliche Ablauf einer Abgabe von Abschlußarbeiten abgelesen werden. Auch hier bietet sich aufgrund der hohen Dezentralität eine Unterstützung mit einem im System integrierten Workflow-Tool an, das die Folgeaktivitäten nach Abgabe koordiniert.
Siehe auch Kapitel 5.5.3 im Grobkonzept.
4.1.6 An- und Abmeldungen
LV-Anmeldungen
Abmeldungen
Prüfungs-anmeldungen
*
Lehrveranstal-tungsan- und -abmeldung
*
Prüfungs-an- und
-abmeldung
*
Einzel-anmeldungen
*
Sammel-anmeldungen
*
Einzel-abmeldungen
Abmeldungen
Abbildung 35: PAM „An- und Abmeldung“
Bemerkungen:Anmeldungen und Abmeldungen zu Lehrveranstaltungen und Prüfungen können vom System ideal unterstützt werden. Voraussetzung dazu ist natürlich die exakte Pflege der Studienpläne im System durch die STAB.
Siehe auch Kapitel 5.6 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 79 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.6.1 LV-Anmeldungen
F
LV-Anmeldungen
LV-Leiter/-in
Student/-inLehrver-
anstaltung
An- undAbmeldung
StudiumStudien- und
Prüfungsabteilung(STAB)
Abbildung 36: Funktionszuordnungsdiagramm „Lehrveranstaltungsanmeldung durchführen“
Bemerkungen:Einen Überblick über die wichtigsten Funktionalitäten einer Anmelde-Unterstützung durch ein System bietet der Funktionsbaum „LV-Anmeldungen“.
Bei der Anmeldung der Studenten zu Lehrveranstaltungen finden auf Systemseite verschiedene Überprüfungen statt, um die korrekte Anmeldung gewährleisten zu können. Hervorzuheben wäre die Überprüfung der Anmeldevoraussetzungen, aufbauend auf den Informationen der bisherigen Studienleistung des Studenten und der Daten aus der Studienplanverwaltung im System, und das Negieren von Anmeldungen zu Parallellehrveranstaltungen; wobei auch Gruppen von Lehrveranstaltungen definiert werden können, in denen nur eine Anmeldung möglich ist. Natürlich muß ein solches Anmeldesystem auch die Eingabe von Anmeldemodalitäten unterstützen - so die Zuordnung der Studenten nach vom Institut/Abteilung definierten Algorithmen - z.B. Sammeln der Anmeldungen über einen Zeitraum hinweg, Einteilung nach Zufallsgenerator, Einteilung nach definierten Präferenzlisten etc.. Die Layout-Gestaltung der Anmeldemaske sollte institutsseitig/abteilungsseitig ohne größere Einarbeitungszeit definiert werden können, um auch Auswahlmenüs festzulegen - z.B. um eine Themenauswahl bei Proseminaren gleich bei der Anmeldung vorzunehmen.
Auch Wartelistenfunktionalitäten sollten unterstützt werden. So wird bei Überschreitung der max. Teilnehmerzahl dem Studenten ein Eintrag in eine
Seite 80 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Warteliste angeboten. Ständig ist im System die aktuelle Wartelistenplazierung einsehbar vom Studenten. Per E-Mail wird er automatisch als möglicher Nachrücker informiert, um freigewordene Plätze aufzufüllen, falls er sich innerhalb einer gewissen Frist anmeldet. Ansonsten wird der Nächste der Warteliste informiert. Zu unterstützen ist die Vergabe von Anmeldeprioritäten aufgrund von Wartelistenpositionen in vergangenen Semestern.
Betont werden sollte, daß Anmeldungen ausschließlich am System und nicht mehr in den Abteilungen/Instituten stattfinden sollten. Positiv wurde vermerkt, daß zu jeder Zeit die aktuelle Anzahl der angemeldeten Studenten aus dem System verfügbar ist. Auch sollten E-Mail-Verteiler automatisch aus den Teilnehmerlisten generiert werden, um so eine einfache und schnelle Informationsübermittlung gewährleisten zu können. Schwierig gestaltet es sich, die Abmeldung von den Lehrveranstaltungen zu urgieren, da ein Druck auf die Studenten aufgrund fehlender rechtlicher Mittel nahezu unmöglich ist - hier ist eine interessante Variante im Workshop 2 vorgeschlagen worden (siehe Anregungen der Institute/Abteilungen zu Lehrveranstaltungen).
Erwähnt sei hier noch die Möglichkeit, Kapazitätsengpässe bei der Anmeldung direkt den Instituten/Abteilungen und dem Studiendekanat zu melden, um rechtzeitig Fehlentwicklungen stoppen zu können. Natürlich sind umfangreiche statistische Erhebungen über einen längeren Untersuchungszeitraum jederzeit systemunterstützt möglich.
Erstellt gemeinsam mit 15. April 1998 Seite 81 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.6.2 Prüfungsanmeldungen
F
Prüfungs-anmeldungen
Student/-in
An- undAbmeldung
Studium
Studien- undPrüfungsabteilung
(STAB)
Prüfung
Fachbereich
Abbildung 37: Funktionszuordnungsdiagramm „Prüfungsanmeldung durchführen“
Bemerkungen:Analog zu den Anmeldungen zu den Lehrveranstaltungen sollten auch die Prüfungsanmeldungen systemunterstützt möglich sein. Zu beachten ist eine erhöhte Sicherheitsanforderung, da Anmeldung zu Prüfungen kritischer sein könnten (Sanktionierung bei Nichtantritten). Eine Anmeldung in den Instituten/Abteilungen sollte nunmehr die absolute Ausnahme sein.
Aus der Liste möglicher Prüfungen nach seinen erbrachten Studienleistungen wählt der Student seine Kombination aus Prüfer, Prüfungstermin und Studium, um danach seine Anmeldung zu bestätigen. Auf Systemseite erfolgt die Prüfung der Teilnahme und die Bestätigung des Prüfungseintrags oder des Eintrags in die Warteliste. Kapazitätsüberschreitungen werden den zuständigen Stellen gemeldet, um rechtzeitig reagieren zu können.
Aktuell können die Anmeldedaten von den Instituten/Abteilungen ständig im System verfolgt werden. Die Anzahl der Prüfungsantritte sollte dem/der Institut/Abteilung angezeigt werden, damit die Brisanz der Prüfung abgeschätzt werden kann. Auch Spätanmelder können mit Genehmigung des Prüfers nach Anmeldeschluß eingetragen werden - mit Verifizierung des Prüflings, wobei die Anmeldefristen von den Instituten/Abteilungen flexibel definierbar sind.Die Anmeldeliste sollte jederzeit von den Instituten/Abteilungen konfigurierbar sein und z.B. eine Eingrenzung des Prüfungsstoffs (z.B. Abfrage nach besuchten Vorlesungen) fordern können. Auch hier sorgen
Seite 82 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
automatisch generierte E-Mail-Verteiler für schnellen Informationsaustausch an die Studenten.
Nutzenpotential: Prüfungsanmeldungen
Institute/Mittelbau
Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.Voraussetzungen zur Anmeldung werden automatisch geprüft.Anmeldung zu Parallelveranstaltungen nicht möglich.Anmeldelisten dienen als Verteilerlisten für E-Mail, wodurch schnell Informationen an die Teilnehmer verschickt werden können.Erhöhte Auskunftsfähigkeit, z.B. aktuelle Anmeldelisten, durch das System.Flexibilität erhöht sich, da die Administration der Daten auf Institutsseite liegt (z.B. Anmeldefrist).
Minus
Anmeldemodalitäten müssen zumindest einmal festgelegt werden im System.
Institute/Sekretariate
Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.Nachrücker werden vom System über Wartelisten automatisch berücksichtigt; Spätanmelder können direkt in das System eingegeben werden (mit Zustimmung des LV-Leiters).Anmeldungen/Abmeldungen werden nicht mehr in den Instituten abgewickelt.Voraussetzungen zur Anmeldung werden automatisch geprüft.Anmeldung zu Parallelveranstaltungen nicht möglich.Anmeldelisten dienen als Verteilerlisten für E-Mail, wodurch schnell Informationen an die Teilnehmer verschickt werden können.
Minus
Anmeldemodalitäten müssen zumindest einmal festgelegt werden im System.
Erstellt gemeinsam mit 15. April 1998 Seite 83 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Prüfungsanmeldungen
Verwaltung
Plus STAB: Anmeldezeitraum wird automatisch überprüft.STAB: Überschreitung der max. Teilnehmerzahl wird automatisch überprüft.STAB: Prüfung, ob Zulassungsvoraussetzungen gegeben sind, findet automatisch statt (Regeln werden durch STAB definiert - Studienplan).STAB: Keine Betreuung des Studenten zur Anmeldung nötig.STAB: Anmeldemodalitäten werden automatisch berücksichtigt (Präferenzeingaben, Kapazitätsauslastungen).STAB: Nachrücker und Wartelisten werden automatisch und institutsseitig administriert.STAB: Kapazitätsengpässe und Kapazitätsanalysen werden automatisch gemeldet.
Studiendekanat
Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.
Studierende
Plus Prüfung, ob Anmeldung erfolgen kann, erfolgt sofort online.Präferenzen zu LV können berücksichtigt werdenWartelisten werden erstellt - Nachrücker werden sofort per E-Mail verständigt.Prüfungstermine, Prüfer und Dauer werden per E-Mail sofort mitgeteilt.
Seite 84 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.6.3 Abmeldungen
F
Abmeldungen
Student/-in
An- undAbmeldung
Studien- undPrüfungsabteilung
(STAB)
Studien-dekanat
Prüfung
Fachbereich
Lehrver-anstaltung
Abbildung 38: Funktionszuordnungsdiagramm „Abmeldung durchführen“
Bemerkungen:In einem Funktionsbaum finden sich die wesentlichen Funktionen des Systems zur Unterstützung der Abmeldemodalitäten.
Abmeldungen sind vom Schutzbedarf her besonders kritisch zu sehen, da hier Mißbrauch der Abmeldung von unbefugten Personen zu ernsten Konsequenzen führen könnten für die angemeldeten Studenten.
Die Sperrfrist bei Nichterscheinen zu Prüfungen sollte im System von der STAB gewartet werden.
Nutzenpotential: Abmeldungen
Institute/Mittelbau
Plus Verschiebungen können direkt in das System eingetragen werden (daraus resultierende anmelderechtlichen Konsequenzen werden durch das System automatisch berücksichtigt).
Institute/Sekretariate
Erstellt gemeinsam mit 15. April 1998 Seite 85 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Nutzenpotential: Abmeldungen
Plus Nachrücker werden vom System über Wartelisten automatisch berücksichtigt; Spätanmelder können direkt in das System eingegeben werden (mit Zustimmung des LV-Leiters).Abmeldungen werden nicht mehr in den Instituten abgewickelt.
Verwaltung
Plus STAB: Abmeldezeitraum wird automatisch überprüft.STAB: Verschiebungen können direkt in das System eingetragen werden (daraus resultierende anmelderechtlichen Konsequenzen werden durch das System automatisch berücksichtigt).STAB: Prüfung, ob Abmeldevoraussetzungen gegeben sind, findet automatisch statt (Regeln werden durch STAB definiert - Studienplan).STAB: Keine Betreuung des Studenten zur Abmeldung nötig.STAB: Nachrücker und Wartelisten werden automatisch und institutsseitig administriert.
Studierende
Plus Prüfung, ob Abmeldung erfolgen kann, erfolgt sofort online.Fernabmeldung sollte möglich sein.Wartelisten werden erstellt - Nachrücker werden sofort per E-Mail verständigt.
Seite 86 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.7 Anerkennungen
An-erkennungen
*
P
Aner-kennungen
erzielen
P
Nostrifi-kationenerzielen
Abbildung 39: Funktionsbaum „Anerkennung“
Bemerkungen:Anerkennungen sollten mit Systemunterstützung gewährt werden können. Während die Aktivitäten bei der Nostrifikation vom Charakter her sehr heterogen und daher schlecht im System abbildbar sind, sollten die Arbeiten im Umfeld von Anerkennungen von Prüfungen und wissenschaftlichen Tätigkeiten gute Hilfeleistung durch das System bekommen können.
Alle Anerkennungen von WU-internen Leistungen bei Aufnahme von Zusatzstudien und Wechsel des Studiums sollten automatisch durch das System gewährt werden; näheres findet man im Prozeß „Zusatzstudium/Wechsel des Studiums“ wieder.
Siehe auch Kapitel 5.7 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 87 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.7.1 Anerkennungen erzielen
P
Aner-kennungen
erzielenStudium
Anerkennung
StudienplanStudent/-in
Service-Einrichtungfür die Studien-kommissionen
Abbildung 40: Funktionszuordnungsdiagramm „Erzielen von Anerkennungen“
Bemerkungen:In einer Prozeßkette (eEPK) wird der Ablauf zwecks Vergabe von Anerkennungen dokumentiert.
Verschiedene Verbesserungspotentiale ergeben sich bei Analyse der derzeitigen Situation: Zum Beispiel können Daten direkt in das System vom Studenten eingegeben werden, Terminvereinbarungen können im Vorfeld getroffen werden, Ergebnisinformationen den Antragstellern über E-Mail gegeben werden, und Teile der Schriftstücke in der Verwaltung schon aus den Daten vom System vorgeneriert werden.
Nutzenpotential: Anerkennungen erzielen
Verwaltung
Plus STAB/Studienkommission: Anerkennungsbescheid wird automatisch aus den Daten generiert.STAB/Studienkommission: Berufungsbescheid bei Einspruch des Antragstellers muß nicht mehr händisch erstellt werden.STAB/Studienkommission: durch Einscannen von Originaldokumente wird das Versenden von Schriftstücken eingeschränkt - z.B. Versendung an die Studienkommission zur Entscheidung, Versendung an Fachgutachter - und
Seite 88 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nutzenpotential: Anerkennungen erzielen
die Archivierung von Kopien in Papierform wird obsolet.STAB/Studienkommission: Anerkennungsbescheid wird vom Studenten am System ausgedruckt - keine Schalterbetreuung mehr nötig.STEP: Information der Vorlage des Anerkennungsbescheids wird automatisch an den Studenten geschickt (E-Mail) oder später schriftlich automatisch generiert.STAB/Studienkommission: Information über Einspruch des Antragstellers an die Studienkommission erfolgt systemunterstützt über E-Mail.STAB/Studienkommission: Terminvereinbarung mit Antragsteller zur Vorlage der Originaldokumente erfolgt systemunterstützt.STAB/Studienkommission: Daten zwecks Anerkennung werden vom Studenten direkt in das System im Vorfeld eingegeben.STAB/Studienkommission: Nachfrage nach zusätzlichen Unterlagen kann elektronisch geschehen (bei Empfangsbestätigung mit elektr. Unterschrift vom Studenten).STAB/Studienkommission: Schreiben an die Fachgutachter wird automatisch aus den Daten generiert.
Minus
STAB/Studienkommission: Einscannen von Originaldokumente nötig, falls diese Aufgabe vom Antragsteller nicht übernommen wird.
Studierende
Plus Terminabstimmung am System im Vorfeld möglich.schnellere BearbeitungszeitAnerkennungsbescheid kann direkt aus dem System ausgedruckt werden - keine Schalterbetreuung notwendig.
Erstellt gemeinsam mit 15. April 1998 Seite 89 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.7.2 Nostrifikationen erzielen
P
Nostrifi-kationenerzielen
Studium
Anerkennung
Studienplan
Studien- undPrüfungsabteilung
(STAB)
Antragsteller/-in
Studiendekan/Vizestudiendekan
Abbildung 41: Funktionszuordnungsdiagramm „Erzielen von Nostrifikationen“
Bemerkungen:Nach einer Gesetzesänderung könnte die Anzahl der durchzuführenden Nostrifikationen im Gebiet der EU deutlich absinken; allerdings werden weiterhin auch aus diesem Gebiet Nostrifikationen durchzuführen sein.
In der Prozeßkette „Nostrifikationen erzielen“ wird dokumentiert, wie in Zukunft die Bearbeitung der Nostrifikation aussehen könnte. Verbesserungspotential liegt in der Information der beteiligten Stellen. In diesem Zusammenhang ist auch die Prozeßkette „Zulassung Studierende mit Nostrifikationsauflagen“ zu beachten, in der eine Zulassung zum Studium mit Auflagen zum Erlangen der Nostrifikation beschrieben wird.
Seite 90 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.8 Abrechnungen
P*
Ab-rechnungen
Rechts - undOrganisations-
abteilung
Quästur
wissenschaftl.Mitarbeiter/-in
Lehrver-anstaltung
PrüfungDiplomarbeit/Dissertation
Abrechnung
Abbildung 42: Funktionszuordnungsdiagramm „Abrechnung“
Bemerkungen:Abrechnungen der erbrachten Leistungen werden von der Rechts - und Organisationsabteilung und der Quästur vorgenommen. Bei beiden Organisationseinheiten sind Anwendungssysteme im Einsatz, die mit den entsprechenden Daten über Schnittstellen gefüttert werden müssen.
In der Rechts- und Organisationsabteilung wird mit einer Access-Datenbank mit Namen „PTKG“ gearbeitet, während in der Quästur das System „PAV“ - auch zum Teil in der Rechts - und Organisationsabteilung - eingesetzt werden wird, das österreichweit zum Einsatz kommen soll.
In der Prozeßketten (eEPK) „Abrechnungen mit PAV und PTKG“ wird ein Szenario beschrieben, in dem das System ‘2gether’ mit beiden Systemen die Abrechnung verwaltet - sicherlich in der ersten Ausbaustufe ein sinnvoller Weg. Bei Integration des Systems „PTKG“ in ‘2gether’ könnte der Ablauf wie in der Prozeßkette (eEPK) „Abrechnungen mit PAV und ohne PTKG“ aussehen. Das Szenario einer Integration beider Systeme ist in der Prozeßkette „Abrechnungen ohne PAV und PTKG“ abzulesen, wobei eine solche Lösung als Endausbaustufe aufgrund der weiten Verbreitung von „PAV“ mehr als fraglich ist.
Auf jeden Fall sollten die Abrechnungen durch ein perfektionierte Schnittstelle in Zukunft schneller ablaufen. Wesentlich ist, daß alle abrechnungsrelevanten Daten, also Prüfungstaxen, Kollegiengelder und Lehraufträge,aus dem System abrufbar sind und in Verbindung mit den
Erstellt gemeinsam mit 15. April 1998 Seite 91 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Personaldaten - ‘2gether’ sollte wesentliche Personaldaten (zumindest die Personaldaten aus WUFIS) integrieren und Schnittstellen zu dem System „PIS“ aufzeigen - alle notwendigen Informationen zur Abrechnung liefern.
Siehe auch Kapitel 5.8 im Grobkonzept.
4.1.9 Evaluierung der Lehre
*
Beurteilungvon Lehrver-anstaltungen
P
*
Arbeitsberichte erstellen
F
Evaluierungder Lehre
*
Evaluierungder Lehre
Abbildung 43: PAM „Evaluierung der Lehre“
Bemerkungen:Natürlich bietet es sich an, mit Hilfe der mannigfaltigen Dateneinträgen im System auch die regelmäßigen Arbeitsberichte (einmal im Jahr) und die Berichte zur Evaluierung (im Moment geplant: alle vier Jahre) zu unterstützen. Dabei sollte eine automatische Generation aller Berichtsteile, die auf Daten im System basieren, von den Instituten/Abteilungen ohne größere Umstände möglich sein.
Siehe auch Kapitel 5.9 im Grobkonzept.
Seite 92 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Nutzenpotential: Evaluierung der Lehre
Institute/Mittelbau und Sekretariate
Plus Arbeitsberichte können aus den Daten des Systems automatisch generiert werden.Evaluierungsberichte können aus dem System automatisch generiert werden.Layout - Vorgabe der Arbeitsberichte möglich über 2gether.
Studiendekanat
Plus Doppelte Stimmabgaben eines Studenten zur Bewertung der Lehrveranstaltung können vermieden werden (wird mit dem bisherigen System nicht abgedeckt).Legitimation der Stimmabgabe kann durch das System ‘2gether’ überprüft werden (wird mit dem bisherigen System nicht abgedeckt) - dadurch wird Mißbrauch nahezu unmöglich.Layout - Vorgabe der Arbeitsberichte möglich über 2gether.
Studierende
Plus Einheitliche Systemlandschaft bei Benutzung von ‘2gether’ zur Abgabe der Evaluierung.
Erstellt gemeinsam mit 15. April 1998 Seite 93 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.9.1 Beurteilung von Lehrveranstaltungen
P*
Beurteilungvon Lehrver-anstaltungen
Evaluierung
Student/-in
LV-Leiter/-in
Studien-dekan
Studien-kommission
Abbildung 44: Funktionszuordnungsdiagramm „Beurteilung Lehrveranstaltung“
Bemerkungen:Evaluierungen sollten in Zukunft regelmäßig durchgeführt werden. Dazu ist es notwendig, daß die Studenten ihre Wertungen anonym abgeben können. Hier bietet sich der Einsatz von ‘2gether’ geradezu an, da gewährleistet werden kann, daß Studenten nur einmal ihre Stimme abgeben, und eine Überprüfung der Berechtigung der Stimmabgabe durchgeführt wird - also ob z.B. der Student in der von ihm bewerteten Lehrveranstaltung auch angemeldet ist. In der beiliegenden Prozeßkette (eEPK) wird ein Evaluierungsszenario beschrieben. Zu betonen ist, daß hiermit nur die Evaluierung der Lehre eine Unterstützung durch das System bekommt - als weitere Ausbaustufen könnte man sich auch eine Integration der Forschungsevaluierung vorstellen.
Das vom Studiendekanat in den letzten Monaten erstellte Anwendungssystem, das eine Stimmabgabe der Studenten dv-technisch unterstützt, sollte natürlich in seinen Funktionalitäten in das System ‘2gether’ integriert werden.
Siehe auch Kapitel 5.9.1 im Grobkonzept.
Seite 94 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.9.2 Arbeitsberichte erstellen
F*
Arbeitsberichte erstellen
EvaluierungStudien-dekan
Studien-kommission
Institut/Abteilung
Abbildung 45: Funktionszuordnungsdiagramm „Arbeitsbericht Institutsvorstände“
Bemerkungen:Alle Funktionalitäten, die das System zur Unterstützung der Erstellung von Arbeitsberichten präsentieren kann, sind in einem Funktionsbaum dargestellt.
Umfangreiche Statistiken und Analysen sollten in den Abteilungen/Instituten vom System abrufbar sein. Hinzukommen sollte die automatische Generation eines Berichtes mit einer darauffolgenden Verschickung an das Studiendekanat und die Studienkommissionen über das System.
Siehe auch Kapitel 5.9.2 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 95 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.10 Allgemeine Funktionen
allgemeineFunktionen
Stammdatenverwaltung
*
Aus-wertungen/Ausdrucke
*
Hörsaal-administration
*
Chipkarten-verwaltung
*
Abbildung 46: Funktionsbaum „allgemeine Funktionen“
Bemerkungen:Hier werden grundlegende organisatorische Funktionalitäten dargestellt, die von dem System zu unterstützen sind.
4.1.10.1 ChipkartenverwaltungDer Lebenzyklus der an der WU Wien zum Einsatz kommenden Chipkarten läßt sich im wesentlichen in fünf Phasen unterteilen.
Der erste Schritt - die Herstellung der Karte - wird von einem externen Anbieter, der die notwendigen technischen Gerätschaften vorhalten kann, durchgeführt. Alle weiteren Schritte im Zusammenhang mit der Chipkartenverwaltung sollten von der WU selbst vorgenommen werden. Aus diesem Grunde wurde die entsprechende Funktion im Diagramm grau hinterlegt.
Seite 96 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
So sollte bereits der nächste Schritt, die Initialisierung der Chipkarte, von einer WU-internen Stelle, dem sogenannten „Trust-Center“, durchgeführt werden. Diese Trust-Center-Funktionalität könnte sinnvollerweise von einer um diese Aufgabe erweiterte Studien- und Prüfungsabteilung vorgenommen werden. Bei der Initialisierung enthält die Chipkarte alle Informationen der Anwendung ‘PowerCard’, d.h. von diesem Zeitpunkt an ist es sinnvoll, den Begriff ‘PowerCard’ zu verwenden.
An die Initialisierung schließt sich die Personalisierung der ‘PowerCard’ an. Auch diese – wie auch alle weiteren Tätigkeiten – sollte sinnvollerweise vom o.e. WU-internen Trust-Center durchgeführt werden. In dieser Phase werden die für den späteren Gebrauch der PowerCard notwendigen (personenbezogenen) Daten in die Karte geschrieben und das Lichtbild mittels Thermotransferverfahrens aufgebracht.
Die nächsten im Funktionsbaum im Anhang detailliert aufgeführten Phasen umfassen die Verwendungs- und Endphase der PowerCard.
Mit der hier geschilderten Organisation der Verwaltung der Chipkarte ist eine größtmögliche Sicherheit und Effizienz in der Handhabung gewährleistet. So fallen unnötige Transportwege sowie die unnötige Herausgabe WU-interner oder gar persönlicher Daten an einen Fremdanbieter weitgehendst weg. Durch die zeitnahe Initialisierung und Personalisierung der Karte kurz vor der Ausgabe sind auch Risiken – beispielsweise durch Diebstahl – minimiert.
Sinnvollerweise sollte das Trust-Center auch die Verwaltung der Karten von WU-Mitarbeitern übernehmen, obwohl dies nicht zu den ursprünglichen Aufgaben der Studien- und Prüfungsabteilung gehört.
Siehe auch Kapitel 6.2 im Grobkonzept.
Erstellt gemeinsam mit 15. April 1998 Seite 97 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.10.2 Hörsaaladministration
Hörsaal-administration
*Lehrver-anstaltung
Prüfung
Raum-verwaltung
WU-Angehörige/-r
Wirtschaftsabtei-lung und Abteilung
für Gebäudeund Technik
Rechts - undOrganisations-
abteilung
Abbildung 47: Funktionszuordnungsdiagramm „Hörsaaladministration“
Bemerkungen:Sinnvoll erscheint weiterhin eine Servicestelle für die Hörsaaladministration als Ansprechpartner der Institute und Abteilungen bereitzuhalten. Diese sollte sowohl während des Semesters Wünsche zur Belegung von Räumen bearbeiten, an andere Stellen (Rektorat) zur Genehmigung weiterleiten, als auch über Kostenersätze informieren. Auch für die Information über kurzfristige Verschiebungen von Veranstaltungen könnte von hier gesorgt werden.
Online sollte immer die aktuelle Raumbelegung einsehbar sein für interessierte Abteilungen der WU-Wien; auch hier könnte die Service-Stelle ihren Part leisten, wie auch bei der Unterstützung einer Hörsaaltauschbörse.
Siehe auch Kapitel 5.10.4 im Grobkonzept.
4.1.10.3 StammdatenverwaltungDie Stammdatenverwaltung sollte je nach Datenbereich klar definierte Zuständigkeiten aufweisen.
Siehe auch Kapitel 5.10.1 im Grobkonzept.
Seite 98 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.1.10.4 Auswertungen/AusdruckeDie verschiedensten Auswertungen und Statistiken sollten jederzeit über der Datenbank des Systems abrufbar sein. Wichtig ist Möglichkeit, Abfragen flexibel den Bedürfnissen anpassen zu können. Dies sollte ohne allzu viel Vorkenntnisse auch von Anwenderseite durchführbar sein.
Alle durchgeführten Abfragen sollten sich speichern lassen (sowohl die Abfrage-Einstellungen an sich als auch die Ergebnisse) und sollten automatisch archiviert werden. Datenexporte der Ergebnisse in verschiedenen Formaten sollten unterstützt werden.
Eine Übersicht wünschenswerter Abfragen und weitere Informationen enthält das Kapitel 5.10.2 des Grobkonzepts.
Erstellt gemeinsam mit 15. April 1998 Seite 99 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.1.11 Allgemeine Systemfunktionen – Grundfunktionalitäten
Benutzer-führung
Delegations-mechanismen
Vorgangs-sicherheit
(Authentifizierung)
Vorgangs-Protokollierung
elektronischeSchautafel
allgemeineSystem-
funktionen
Benutzer-administration
Backup-und Archivierung
Begleit-maßnahmen
Grundfunktionalitäten
Abbildung 48: Funktionsbaum „allgemeine Systemfunktionen“
Seite 100 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Bemerkungen:Wesentliche „Grundfunktionalitäten“ des Systems werden an dieser Stelle genannt. Für detaillierte Informationen sei an dieser Stelle auf das Grobkonzept Kapitel 5.1 und Kapitel 6 verwiesen, das sehr anschaulich und umfangreich entsprechende Anforderungen auflistet.
Die Benutzerführung sollte intuitiv und einfach ablaufen und alle angesprochene Eingabemedien unterstützen (IVR, Internet etc.). Auch wurde bei den Interviews eine englische Sprachvariante als conditio sine qua non gefordert und eine französische als sinnvolle Erweiterung angesprochen (unabdingbar für die Information der Austauschstudenten).
Eine wichtige Kernfunktionalität deckt der Delegationsmechanismus ab, mit dem es möglich sein sollte, Berechtigungen auf andere Personen zu übertragen. Zu klären wäre noch, ob bei Leistung von elektr. Unterschriften seitens der delegierten WU-Angehörigen auch die Zuordnung der Verantwortlichkeiten entsprechend gesetzlich geregelt sind. Dies sollte das in naher Zukunft erwartete Gesetz zur Regelung der elektr. Unterschriften beantworten können.
Es sollte den je nach durchgeführter Transaktion unterschiedlichen Sicherheitsanforderungen Rechnung getragen werden. Hier bieten die Eingabe der Benutzerkennung und Paßwörter, elektr. Unterschriften, TAN-Nummern und die Verwendung von Verschlüsselungsalgorithmen vielfältige Möglichkeiten je nach Eingabemedium die korrekte Authentifizierung gewährleisten zu können. Zum Zeitpunkt der Einführung des Systems sollten auch Transaktionen über das Internet per WWW vom Sicherheitsstandard her allen Ansprüchen gerecht werden (128-Bit Schlüssel etc.), falls die derzeitige Entwicklung anhält.
Alle Transaktionen im System sollten mitprotokolliert werden und von den verschiedenen interessierten Abteilungen einsehbar sein, falls die Datenschutzgesetze dies erlauben. So könnte die Überprüfung der Anmeldung zu Lehrveranstaltungen und Prüfungen auch direkt von Abbteilungsseite/Institutsseite sinnvoll sein.
Eine Möglichkeit alle interessanten Daten direkt zur Veröffentlichung („Schaukasten“) ins WWW zu stellen sollte gegeben sein. Per E-Mail sollten bei Veränderungen von Daten je nach Zuordnung alle Betroffene automatisch informiert werden („shared-Mail-Mechanismus“ bei Massenmailings). Fristerinnerungen sollten automatisch verschickt werden. Ausdrücke der angezeigten Daten sollten jederzeit möglich sein für die Anwender.
Erstellt gemeinsam mit 15. April 1998 Seite 101 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Eine umfangreiche Benutzerverwaltungskomponente sollte im System integriert werden. Berechtigungen müssen anwenderfreundlich verwaltet werden und automatisiert vergeben werden können. Bisherige Benutzerverwaltungssysteme können eingespart werden.
Datenschutz muß entsprechend berücksichtigt werden - insbesondere sollten Anforderungen der ÖH bzgl. der Einschränkung der Einsicht in Studentenstammdaten einbezogen werden.
Eine Auslagerung von Altbeständen von Daten zur Archivierung muß unterstützt werden, wie auch die Rückspielen dieser Daten zur Ansicht. Transaktionen (z.B. Zuordnungen zu Prüfungen) sollten rückgängig gemacht werden können (roll-back), natürlich mit entsprechender E-Mail-Information.
Begleitmaßnahmen wie Anwender - und Administrator- Schulungen und die Erarbeitung von Ausfallkonzepten und Sicherheitskonzepten müssen vor Systemeinführung sichergestellt sein. Umfangreiche Informationsaktivitäten für die Studentenschaft erscheint notwendig und sind rechtzeitig durchzuführen.
Weitere Grundfunktionalitäten wie das Abspeichern der erstellten Daten, die Aufruf- und Eingabefunktionalität, Maus- und Keyboard - unterstützte Benutzerführung etc. verstehen sich von selbst.
Seite 102 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.2 Anregungen der verschiedenen Organisationseinheiten
In den Interviews wurden die verschiedenen Anforderungen, Bemerkungen und Befürchtungen der beteiligten Interviewpartner aufgenommen und werden im Folgenden dokumentiert. Die aufgeführten Themen entsprechen nicht unbedingt der Meinung der beratenden Firmen - sie sollen vielmehr ein Forum zur Transparenz der Meinungsvielfalt der WU-Wien bilden. Manche Themen wurden auch von den beratenden Firmen im Gespräch gefordert oder von mehreren Abteilungen angesprochen, wobei hier meist nur der erste Anstoß vermerkt wurde. Die von den beratenden Firmen unterstützten Anregungen werden durch das unterstrichene erste Wort des Satzes gekennzeichnet. Im Anhang findet man eine Legende zu den Abkürzungen der interviewten Abteilungen/Institute.
4.2.1 Studien- und Prüfungsabteilung Durch Nachschauen vom Studenten im Medium (z.B. WWW)
sollte möglich sein zu klären, ob Rückmeldung erfolgt ist - dadurch ist rechtzeitiges Reklamieren möglich!
StabDat also die in der STAB verwendete Filemaker-Datenbank, sollte in Funktionalität und Anwenderfreundlichkeit im neuen System vorliegen (ca. 10000 Briefe an ausländ. Studenten) - also Layout-Generierung, Datenfelderkontrolle, Datenlinks, Funktionalitäten (zB Summierung).
Die Änderung der Kennzahl (entspricht Studienrichtung) war bisher nur möglich über Löschung des gesamten Eintrags und neues Erfassen; dies sollte verbessert werden!
Der gesamte Briefverkehr sollte archiviert werden und auf Anfrage abrufbar sein.
Ähnlichen Prüfungen sollten ähnlich Nummern zugeordnet werden – in Zukunft sind alle Prüfungen wie LV-Prüfungen zu handhaben.
Layout: bisher Gestaltung der Ausdrucke aus Step nur über Programmierer; hier läge ein deutliches Verbesserungspotential.
Automatisches Zuschicken der Sammelzeugnisse (2x im Jahr) sollte nur erfolgen falls sich eine Veränderung im System ergab!
Erstellt gemeinsam mit 15. April 1998 Seite 103 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Zulassungsdaten sollen direkt von Schulen eingespielt werden in Zukunft (von Schuldatenbanken).
Exaktes Ausfallkonzept muß vor Einführung erstellt werden. Fristerinnerungen bei Studien mit Auflagen sind automatisch vom
System zu verschicken. Verlängerung des Studiums über Fristende hinaus (z.B. bei
Nostrifikationen) muß möglich sein. Bei Studien mit Auflagen sollte Auflagenerfüllung automatisch
vom System zurückgemeldet werden. Informationen über Studienberechtigungsprüfungen per
Schnittstelle aus ‘2gether’ in das Ministerium sollte möglich sein (bisher händisch zu machen).
2gether wird die Aufnahme mit Auflagen zum Studium (z.B. Fachhochschulabsolventen zu Doktoratsstudium mit Auflagen) unterstützen müssen.
Interessant wäre ein Sponsions-Ranking pro Fachbereich als Auswertung.
4.2.2 Institute/AbteilungenLehrveranstaltungen
Anforderung: Warnfunktionalität bei der Hörsaalvergabe, wenn noch keine Reservierung für eine Prüfung etc. stattgefunden hat. (WI)
Sinnvoll wäre ein Plausibilitätscheck im System, ob zu jeder Lehrveranstaltung eine Prüfung geplant ist.(WI)
Anforderung: Die Wartelistenfunktionalitäten sollten umfassend sein - speziell sollten Studenten, die schon in Vorsemestern auf Wartelisten standen, Priorität bei der Zuordnung genießen. (WS2)
Anforderung: Daten in Anmeldelisten sollten von Instituten/Abteilungen zur Ansicht für den Studenten freigegeben werden können - Freigabe könnte über entsprechendes Ansteuern des Tabellenkopfes erfolgen. (WS2)
Anforderung: Ein Roll-Back-Verfahren sollte möglich sein - speziell was die Revidierung von Zuteilung zu LV und Prüfungen betrifft. (WS2)
Seite 104 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Anregung: Druck auf die Studenten zur Abmeldung zu LV dadurch, daß nur eine Menge, oder auch Reservoir, von „Credit Points“ pro Student zur Anmeldung zur LV existiert. (siehe Universität Konstanz). (WS2)
Anforderung: Bei der Hörsaalvergabe muß auch die Blockvergabe der Hörsäle berücksichtigt werden (Blockveranstaltung).Diese „blockiert“ andere Lehrveranstaltungen. (WS2)
Es wird gefordert, daß auf Schleifendurchgänge a priori verzichtet wird. D.h. das System sollte viel stringenter Vorgaben machen. (Bsp.: Budgetsituationen für Lehrveranstaltungen) (WS2)
Bemerkung: Die Hörsaalverwaltung des Grobkonzeptes ist zu idealistisch. Die geforderten Algorithmen sind nicht machbar ( Endlosschleifen). (WS2)
Anregung: Die Art des (LV-) Entgeldes sollte auch schon vom System abgecheckt werden. (WS2)
Bedingungslose Optimierung der Hörsaal-Vergabe in jedem Semester wäre sinnvoll - keine Übernahme gewohnter Hörsäle. (PoÖk)
Bei der Planung der Lehrveranstaltungen wären Schnittstellen zwischen dem System und Text- bzw. Tabellenbearbeitungssystemen sinnvoll. (PoÖk)
Verantwortung der Hörsaal-Verwaltungsstelle für die Bekanntgabe eines Ausfalls einer Lehrveranstaltung an den Hörsälen. (BeSt)
Automatische Erzeugung von E-Mail-Verteiler bzgl. der LV-Teilnehmer und der Gruppenbildung in den Lehrveranstaltungen. (BeSt)
Interessant wären Diskussionsfora pro LV im System. (BeSt) Bei Anforderungen an Hörsäle sollten Equipment-Anforderungen
integriert werden. (BeSt) Historie aller Lehrveranstaltungen sollte im System ‘2gether’ zum
Aufruf („Revitalisierung“) vorliegen. (FI,BeSt) Keine Zuordnung von festen Terminen und Hörsälen zu
Prüfungen über mehrere Semester hinweg - nur bei Massenprüfungen. Ansonsten Optimierung über das System nach Teilnehmerzahlen in der Vergangenheit. (FI)
Erstellt gemeinsam mit 15. April 1998 Seite 105 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Anregung: Vorläufiger Terminkalender (schon in Grobplanungsphase VVZ) zur Planung von Lehrveranstaltungen auf Inst./Abt.-Ebene zur Vermeidung von Überschneidungen. (FI)
Bei Eingangstest für eine Lehrveranstaltung sollten erfolgreiche Teilnehmer automatisch für die folgende Lehrveranstaltung angemeldet sein. (WA)
Alle LV-Termine sollten nach Planung im System einzusehen sein. Am besten wäre Anlegung einer Tabelle in der Anmeldeliste mit den Veranstaltungsterminen als Spaltenköpfe (für Anwesenheitslisten etc.) - alle Feiertage, Rektoratstage etc. sind zu berücksichtigen. (BüRe)
Über die Anmeldeliste müßte die Informationsversendung per E-Mail an die Teilnehmer problemlos über automatisch generierte Verteiler möglich sein.(BüRe)
2gether sollte Projekt „Studieren im Team“ unterstützen - Anmeldungen sollten sich auch auf Pakete von Lehrveranstaltungen beziehen können.(BüRe)
In dem im Internet generierten VVZ sollten Links zwischen den Lehrveranstaltungen und den ausführenden Instituten/Abteilungen automatisch vorgegeben werden. (BüRe)
„Antrag auf bargeldlose Gehaltszahlung“ sollte nicht mehr über die Bank zu bestätigen sein - Kontoadresse als Information sollte ausreichen. (BüRe)
Anforderung: systemunterstützte Überprüfung, daß Assistenten ihre Mindest- (Lehr-) Stundenzahl erfüllen. (WI)
Bei Anmeldung zu Proseminaren und Seminaren sollte einen Themenauswahl über das System möglich sein.(WI)
Wünschenswert: Abgleich zwischen Prüfungs- oder LV-Kapazität und der Hörsaalzuordnung, z.B. # LV-Teilnehmer <= # Hörsaalplätze (Anmerkung des Verfassers: Vielleicht wären auch „Überbuchungen“ sinnvoll.) (WI)
Anmerkung: Es gibt für Professoren, Assistenten und Externe eigene Budgets, die nicht gegeneinander aufgerechnet werden können. (WI)
Anmerkung: Hinweis auf das Problem der externen Lektoren es sollte an den Instituten eine (interne) Koordinierungsstelle für die LV-Ankündigungen geben. (WI)
Seite 106 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Vorschlag zur LV-Beginnmeldung: der LV-Leiters sollte bei seiner allerersten LV ein Papier unterschreiben, in dem daraufhin gewiesen wird, daß er bei LV-Beginn im negativen Fall Meldung zu machen hat. (RoSp)
Anmeldelisten für Lehrveranstaltungen oder Prüfungen dienen dazu, Verteilerlisten für E-Mails automatisch zu erstellen. (z.B. RoSp)
Anmeldefristen sollten von den Abteilungen/Instituten festzulegen sein. (RoSp)
Falls LV-Leiter nicht zu erreichen ist (z.B. mit E-Mail), sollten Dokumente automatisch vom System an das Institut geschickt werden - schon mit Eintrag aller Daten (z.B. Personaldaten). (RoSp)
Die LV-Beginnmeldungen sollten abgeschafft werden - Information nur im negativen Fall der Nichtaufnahme (RoSp).
LV-Beginnmeldungen sollten nicht mehr in den Sekretariaten zu bearbeiten sein (direkt vom LV-Leiter und danach in der RO). (RoSp)
Simulationen verschiedener LV-Szenarien sollten immer möglich sein - und somit die Prüfung der Einhaltung von Budget-Rahmenwerten. (RoSp).
LV-Leiter sollten bei Ankündigung von Lehrveranstaltungen im System Wunschzeiten und Ausweichzeiten angeben und verändern können (RoSp).
Planung von Lehrveranstaltungen im Semester von Seiten der Institute sollte über Genehmigung der Rechts- und Organisationsabteilung und des Studiendekanats möglich sein. (WS2)
Wenn die Rechts- und Organisationsabteilung weiß, daß der LV-Leiter nicht per E-Mail erreichbar ist, dann sollte sie direkt an den LV-Leiter schreiben und umgekehrt (Bsp. Erhebungsbogen).(PeWi)
Prüfungen Anforderung: Warnfunktionalität bei der Hörsaalvergabe, wenn
noch keine Reservierung für eine Prüfung etc. stattgefunden hat. (WI)
Erstellt gemeinsam mit 15. April 1998 Seite 107 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Sinnvoll wäre ein Plausibilitätscheck im System, ob zu jeder Lehrveranstaltung eine Prüfung geplant ist.(WI)
Wünschenswert: Abgleich zwischen Prüfungs- oder LV-Kapazität und der Hörsaalzuordnung, z.B. # LV-Teilnehmer <= # Hörsaalplätze (Anmerkung des Verfassers: Vielleicht wären auch „Überbuchungen“ sinnvoll.) (WI)
Anforderung: Die Wartelistenfunktionalitäten sollten umfassend sein - speziell sollten Studenten, die schon in Vorsemestern auf Wartelisten standen, Priorität bei der Zuordnung genießen. (WS2)
Anforderung: Ein Roll-Back-Verfahren sollte möglich sein - speziell was die Revidierung von Zuteilung zu LV und Prüfungen betrifft. (WS2)
Anforderung: Bei nachträglicher (d.h. nach Freigabe der Daten durch das Institut) Änderung der Teilnehmerdaten zur Prüfung müßte auch die Rechts- und Organisationsabteilung (z.B. bei Änderung der Teilnehmerzahl) informiert werden. (WS2)
Anforderung: Daten in Anmeldelisten sollten von Instituten/Abteilungen zur Ansicht für den Studenten freigegeben werden können - Freigabe könnte über entsprechendes Ansteuern des Tabellenkopfes erfolgen. (WS2)
Anforderung: Versendung der Noteninformation an die Studenten erfolgt bei Noteneintrag, nicht über Prüfungsanmeldeliste (auch Teilmengen sollten informiert werden können). (WS2)
Anforderung: Die Menge der Prüflinge sollten bei mehreren Prüfern entsprechend den Prüfern im System zugeordnet werden können. (WS2)
Die freiwerdenden Kapazitäten der Prüfungsabteilung sollten dafür eingesetzt werden, den (zeitlichen) Engpaß, der dadurch entsteht, daß eine LV von der STAB dem Studienplanpunkt zugeordnet werden muß, zu vermeiden. (WS2)
Bei Spätanmeldungen müssen Prüfer und Student unterschreiben. (FI)
Hängt die Teilnahme an einer (mündlichen) Prüfung vom Ergebnis einer anderen (schriftlichen) Prüfung ab, dann sollte diese Teilnahme auch automatisch generiert werden. (FI)
Anforderung: Das Halten von Prüfungsfragen im ‘2gether’ ist strikt optional (Gefahr des Mißbrauchs). (WA)
Seite 108 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Anforderung: Nachrücker für Prüfungen müssen sich explizit anmelden.(WI)
Anmeldelisten für Lehrveranstaltungen oder Prüfungen dienen dazu, Verteilerlisten für E-Mails automatisch zu erstellen. (z.B. RoSp)
Anmeldefristen sollten von den Abteilungen/Instituten festzulegen sein. (RoSp)
Killerprüfungen (also 3. Prüfung für den Studenten) sollten mit Warnungen dem Prüfer angezeigt werden. (RoSp)
Bei Prüfungsanmeldungen sollte aufgeführt werden, der wievielte Antritt des Studenten es ist. (RoSp)
Layout der Prüfungslisten sollten von Instituten leicht modifizierbar sein. (z.B. mehrere Spalten mit internen Bemerkungen). (RoSp)
Online sollten Informationen über die Studienjahreinteilung und Prüfungsanforderungen einsehbar sein. (WS3)
Diplomarbeiten/Dissertationen Forderung: Rechtzeitige, zeitnahe Eintragungen in der
Themendatenbank, insbes. wenn (d.h. wann) das Thema vergeben worden ist. (WS2)
Abgegebene Diplomarbeiten sollten von Institutsseite eingesehen werden können. (PoÖk)
Anregung: Bei Vergabe von Themen in der Abschlußarbeit sollte ein Verweis auf Fördermittel (intern und extern) gegeben werden. (BeSt)
Einsicht in abgelegte Diplomarbeiten in digitaler Form sollte öffentlich nicht möglich sein. (Gefahr des Plagiats). (WA)
Allgemein Anforderung: Interimszeugnisse sollten jederzeit vom Studenten
im System ausgedruckt werden können. (WS2) Möglichkeit des Ausdrucks von FLAG-Bestätigungen von den
Studenten aus dem System. (WS2) Alle Vorgänge in System sollten mitprotokolliert werden (z.B.
Abmeldungen) - wichtig ist ein einfacher Zugang zu diesen Informationen. (WS2)
Erstellt gemeinsam mit 15. April 1998 Seite 109 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Anforderung: Letztlich muß auch die gesamte Software parametrisierbar sein; denn z.Zt. gibt es einen Lebenszyklus von gesetzlichen Grundlagen von ca. 2 Jahren... (z.B. Einsichtsfristen, Taxenverteilung (bei mehreren LV-Leitern), Modellierung der Workflow-Prozesse).(WS2)
Es gibt einen abgestuften Delegationsmechanismus. Der Delegationsmechanismus muß parametrisierbar sein. (WS2)
Anforderung: Personalinformationssystem sollte ins ‘2gether’ aufgenommen werden. (WS2)
Anforderung: Aus dem im System bestehenden Daten sollten E-Mail-Verteiler erzeugbar sein, also nicht nur bei den LV-Teilnehmern etc. (Bsp. „Alle WU-Angehörigen, die im Sekretariat arbeiten“).(WS1)
Bei Delegation muß vorher die Frage der Haftung bei stellvertretender elektr. Unterschrift geklärt sein. (WS1)
Gutachtenabgabe bzgl. Austauschstudenten sollte vom System unterstützt werden - z.B. automatische Unterschriften und elektr. Weitergabe des Gutachten vom Fachprofessor und Kooperationsprofessor. (EnSp)
Filter sollten bei der E-Mail-Verwaltung problemlos anwendbar und definierbar sein. (PoÖk)
Sommerhochschulkurse brauchen erst einmal nicht im System administriert werden. (ZAS)
Die Vergabe von ECTS-Credits sollte im System berücksichtigt werden - Nachweis von erzielten Credits könnte über maschinell bestätigten Ausdruck vom Studenten möglich sein. (ZAS)
Umfangreiche Informationen über Anmeldeprozeduren etc. sollte im System in versch. Sprachen angeboten werden. (ZAS)
Bei Austauschstudenten ist es dringend erforderlich, daß Anmeldungen mit höherer Priorität und verändertem Anmeldezeitraum behandelt werden. (ZAS)
Auf jeden Fall sollte das System mehrere Sprachen unterstützen (Englische und französische Sprache erscheint sinnvoll). (ZAS)
Antrag auf Zulassung sollte auch ohne Bezahlung eines ÖH-Beitrags bei Austauschstudenten möglich sein - Authentifizierung erfolgt über elektr. Unterschrift des ZAS. (ZAS)
Seite 110 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Die Hörsaalverteilung sollte immer aktuell abrufbar sein. (BeSt) Anforderung: Berücksichtigung von nationalen und WU-internen
„Feiertagen“ im WU-weiten Terminkalender. (BeSt) WU sollte als Trust Center für Verschlüsselungs-Verwaltung
(Elektr. Unterschrift) dienen. (BeST) Ausblick: Bibliotheksverwaltung sollte in das System integriert
werden, insbesondere bei an die Institute ausgelagerter Literatur. (BeSt)
Wichtiger Punkt ist der Datenschutz, d.h. das Institut darf nicht alle Daten der Studenten sehen - Beteiligung der ÖH an einem Berechtigungskonzept ist erforderlich. (ÖH)
Bei Datenexport aus ‘2gether’ in Dateien sollten die Daten in „interessanten“ (sprich gut zu bearbeitenden) Formate vorliegen. (BüRe)
Befürchtung: Arbeitsumlegungen vom Mittelbau auf Sekretariate könnten gefordert werden, wenn neue Medien eingesetzt werden. (WiSoGe)
VVZ sollte ständig von den Abteilungen bearbeitet werden können. (BüRe)
Informationsgehalt (also Auswahl der Daten) der vom System automatisch generierten E-Mails an die Studenten sollte von den Instituten bestimmt werden können. (RoSp)
Kalender an der WU sollte über versch. Sichten (z.B. Prüfungssicht) anzuschauen und auszudrucken sein. (RoSp).
Institutsstundenplan sollte aus dem System zu erstellen sein mit versch. Sichten (auch mit Unterhierarchien - z.B. versch. Sprachbereiche). (RoSp)
Hörsäle, die einem Fachbereich/Abteilung zugeordnet wurden, sollten auch von diesem im System verwaltet werden können. (RoSp).
Zu überlegen wäre es in Zukunft Budget-Vorgaben auf Jahresebene zu definieren. (RoSp)
Anforderung: Serviceschalter sollte es in Zukunft auch für Studenten ohne Anmeldung geben - hier wäre eine Zulassung mit Zahlscheinbezahlung möglich.. Diese Schalter könnten getrennt von den Schaltern für angemeldete Studenten sein. (ÖH)
Erstellt gemeinsam mit 15. April 1998 Seite 111 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Anforderung: Sichergestellt werden muß, daß LV-Anmeldungen nach einer gewissen Frist, ohne daß eine Zulassung des angemeldeten Studenten erfolgt ist, gestrichen werden. (ÖH)
Anmerkung: Kritisch wird die kurze Zeit der Ist-Aufnahme im Projekt ‘2gether’ gesehen und daher werden Zweifel am ausreichenden Informationsstand für das Projekt gehegt. (WI)
4.2.3 Studiendekanat Eine Lehrveranstaltungsbörse - oder besser Hörsaalbörse - sollte
es geben im System (besonders bei automatischer Hörsaalvergabe durch das System).
Besser als eine Zuordnung der Veranstaltungen zu den Hörsälen analog der Verteilung wie vor 2 Semestern wäre jedes Semester eine vollautomatische Optimierung der Hörsaalverteilung.
Sollte ‘2gether’ das zur Zeit erstellte Evaluierungsprogramm ablösen, müßten die wesentlichsten Funktionalitäten übernommen werden (z.B. die Möglichkeit der Definition von individuellen Fragen durch den LV-Leiter).
Am Semesterende sollte jeder LV-Leiter die Teilnehmerzahl eingeben mit elektr. Unterschrift (wichtige Daten zur Erstellung von Berichten).
Legende:
Kürzel BedeutungWI WirtschaftsinformatikPoÖk Politische ÖkonomieRoSp Romanische SprachenEnSp Englische SprachenBüRe Bürgerliches RechtWA WarenhandelFI FinanzierungBeSt Betriebswirtschaftliche SteuerlehreWiSoGe Wirtschafts- und Sozialgeschichte
Seite 112 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
ZAS Zentrum für AuslandsstudienPeWi PersonalwirtschaftWS 1 Workshop 1WS 2 Workshop 2WS 3 Workshop 3WS 4 Workshop 4
Tabelle 6: Legende zu den Anmerkungen
Erstellt gemeinsam mit 15. April 1998 Seite 113 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.3 Konzeptionelles Datenschema
4.3.1 IntentionNeben der Beschreibung der universitären Abläufe unter Berücksichtigung des neuen Systems ‘2gether’ durch Geschäftsprozeßmodelle, Funktionsbäume und Funktionszuordnungsdiagramme (vgl. Abschnitt Organisatorische Gestaltung der Studien- und Prüfungsverwaltung), ist die Erstellung konzeptioneller, semantischer Datenmodelle ein weiterer wichtiger Baustein in der fachlichen Konzeption eines Anwendungssystems.
In diesem Abschnitt werden daher die entsprechenden relationalen Datenmodelle der Studien- und Prüfungsverwaltung vorgestellt. Diese verfolgen nicht den Zweck, fertige Programmiervorlagen zu erzeugen. Dies ist allein schon deshalb nicht angebracht, da es sich bei dieser Projektphase um die Erstellung einer Ausschreibungsgrundlage handelt. Die technischen „Einzelheiten“, z.B. ob es sich um eine relationale oder eine objektorientierte Datenbank handeln wird, sind somit noch nicht festgelegt.
Nichtsdestotrotz wurden die Datenobjekte mit den zugehörigen, markanten Attributen detailliert. Diese wurden in einer eigenen EXCEL-Datei erfaßt und sind dem Bericht im Anhang beigefügt. Die Datenmodelle entsprechen aus den vorgenannten Gründen nicht in jedem Fall der sogenannten „Dritten Normalform“ und sollten daher intuitiver verständlich sein.
4.3.2 Semantische DatenmodelleDie folgende Abbildung 49 beinhaltet die Clustersammlung zum Themenbereich und dient somit - auch in der ARIS-Datenbank - als Übersichts- und Navigationsmittel für die Datenmodellierung.
Seite 114 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Studium Lehrver-anstaltung
Prüfung Diplomarbeit/Dissertation
An- undAbmeldung
Anerkennung AbrechnungEvaluierung
Raum-verwaltung
Studienplan
Vorlesungs-verzeichnisAdresse
Abbildung 49: Clustersammlung zur Studien- und Prüfungsverwaltung
Im folgenden sollen nun die einzelnen Cluster weiter detailliert werden. Dabei deuten die neben den Objekten befindlichen Sterne („*“) auf die Existenz weiterer Attribute hin. Eingegraute Objekte dienen zu Erhöhung des Veständnisses und sind an anderer Stelle definiert (und somit redundant dargestellt).
4.3.2.1 Studium
Abbildung 50: Semantisches Datenmodell ‘Studium’
siehe nächste Seite.
Erstellt gemeinsam mit 15. April 1998 Seite 115 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
Seite 116 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.3.2.2 Studienplan
Abbildung 51: Semantisches Datenmodell ‘Studienplan’
siehe nächste Seite.
Erstellt gemeinsam mit 15. April 1998 Seite 117 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
*
Stu
dien
-pl
an
*
Stu
dien
-pl
anpu
nkt
*
Stu
dier
ende
/-rde
finie
rtLe
istu
ngfü
r
Fach
*
Prü
fung
[Stu
nden
ausm
aß] e
tc.
Stu
dien
-pl
anpu
nkt
(Fac
h)
Stu
dien
-pl
anpu
nkt
(Prü
fung
)
Vor
aus-
setz
ung
benö
tigt
*
Stu
dien
-pl
an
*
Stu
dien
-pl
anbe
nötig
t
Stu
dien
-ko
mm
issi
on
legt
fest
Fach
-ka
tego
rie
Wah
l- od
er
Pfli
chtfa
ch e
tc.
[Bed
ingu
ng] e
tc.
wird
real
isie
rtdu
rch
Stu
nden
-au
smaß
Prü
fung
s-or
dnun
g
ist B
a-si
s fü
r
1
Fern
stud
ium
-ei
nhei
tbe
steh
tau
s
wird
erse
tzt
durc
h
*
Lehr
ver-
anst
altu
ng
*
Stu
dien
-pl
an
Fach
-ka
tego
rie
Fern
-st
udiu
m
Stu
dien
-pl
anpu
nkt
(Fac
h)
Stu
dien
-pl
anpu
nkt
(Prü
fung
)
Vor
aus-
setz
ung
1
Vor
kenn
tnis
Pra
xis
*
Abs
chlu
ß-ar
beit
[The
ma]
[Zie
le]
[Vor
kenn
tnis
se]
[Met
hode
n] e
tc.
[gle
ichw
ertig
erN
achw
eis]
etc
.
defin
iert
Ers
atz
für
Fäch
er-
kom
bina
tion
Fach
best
eht
aus
*
Stu
dien
-pl
an
*
Lehr
ver-
anst
altu
ng
Vor
aus-
setz
ung
benö
tigt
*
Stu
dien
-pl
an
auch
indi
vidu
elle
r S
tudi
enpl
an
[Bed
ingu
ng] e
tc.
regl
emen
tiert
Stu
dien
-pl
anpu
nkt
(Abs
chlu
ßarb
eit)
benö
tigt
Typ
Abs
chlu
ß-ar
beit
Stu
dien
-pl
anpu
nkt
(Abs
chlu
ßarb
eit)
*
Stu
dien
-pl
anle
gt A
ufba
ufe
st v
on
Stu
dien
-ab
schn
ittS
tudi
en-
zwei
g
*
Stu
dien
ab-
schn
itt d
esS
tudi
ums
[Stu
nden
zahl
] etc
.
ist u
nter
-gl
iede
rt in
*[Ges
amts
tund
enza
hl] e
tc.
Stu
dium
*
Stu
dium
*
Stu
dium
*
Stu
dium
Lehr
ver-
anst
altu
ngP
rüfu
ng
cn
cncn
cn
cn
cncn
cc
cncn
cnn
cncn
cn1
cn
cn
ccn
ncn
c
cn
cnn
cncn
cn
c
cn
1
cn
1
cn
1
nn
1
n
cn
Seite 118 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.3.2.3 Lehrveranstaltung
Abbildung 52: Semantisches Datenmodell ‘Lehrveranstaltung’
*
Organisations-einheit
*
istbeteiligt
an
Verwaltungs-mitarbeiter
wissenschaftl.Mitarbeiter
*
Mitarbeiter
1
*
LV-Leitung
*
LV-Beteiligung *
Lehrver-anstaltung
Fachbereich
wirddurchgeführt
im
*
Lehrver-anstaltung
Lehrauftrags-rahmen
* *
Semester
Wochen-stunden-zuteilung
cn
Professor AssistentStudiendekan L1-Lehrer
genehmigt beantragt
Lehrver-anstaltungs-
raum
*
Semester
*Felder s.
"2gether - Grobkonzept", S. 57f
Lehrver-anstaltung
*
Zuteilung
[@Belegungszeit] etc.
*
Studierende/-r
[Name][Adresse][WU-Matrikel-nummer] etc.
*
Lehrver-anstaltung
*[Plazierung in derAnmeldungsreihenfolge]
etc.
Lehrver-anstaltungs-anmeldung
Teilnehmer-gruppe
z.B. als Basis für E-Mail-Verteilerlisten
bildet
*
Lehrver-anstaltungs-
termin
[Teilnehmerzahl] etc.
findetstatt an
Anwesenheit
*
Lehrver-anstaltungs-
teilnahme[(Zwischen-) Ergebnis] etc.
generiert
externeOrganisations-
einheit
interneOrganisations-
einheit
1
ProSeminar
Seminar
Vorlesung
Übung
c
*
Mitarbeiterwird
geleitetvon
Organisations-struktur
AbteilungFachbereich Institut
c
cn 1cn
cn
1
cn cn
cn
cn cn
c 1
cn cn
cn
cn
n
cn
1
cn
cn
1
c
cn
cn
cn
cn
cn
c
cnist übergeordnet
c ist untergeordnet
cn
Erstellt gemeinsam mit 15. April 1998 Seite 119 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.3.2.4 Vorlesungsverzeichnis
LV-Ankündigung
SemesterVorlesungs-verzeichnis
enthält
istgültig
für
Lehrver-anstaltung
LV-Ankündigung
wirdgeplantmittels
istzugeordnet
benötigt
Ankün-digungs-bereich
Fach-bezug
Programm
CEMS,
JOSZEF,
English Track
etc.
gehörtzu
LV-Änderungs-ankündigung
wirdgeändert
durchc
LV-Ankündigung
Studien-plan
auch individueller
Studienplan
Voraus-setzung
Fachbereich
Fach-kategorie
FachBildung von- Parallelveranstaltungen- LV-Gruppierungen
LV-Gruppe
istTeilvon
1
n
1
1 c
n
cn
cn
1
cn
cn
cn
cn
cncn
cn
1
1
cn
n
cn
Abbildung 53: Semantisches Datenmodell ‘Vorlesungsverzeichnis’
4.3.2.5 Prüfungen
Abbildung 54: Semantisches Datenmodell ‘Prüfungen’
siehe nächste Seite.
Seite 120 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 121 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.3.2.6 An- und Abmeldung
Lehrver-anstaltungs-anmeldung
Anmeldung
Prüfungs-anmeldung
1
giltfür
Studiumdes
Studierenden
1 cn
Abbildung 55: Semantisches Datenmodell ‘An- und Abmeldung’
Seite 122 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.3.2.7 Diplomarbeiten und Dissertationen
*[Thema][Ziele]
[Vorkenntnisse][Methoden] etc.
Abschluß-arbeit
[Thema][Ziele]
[Vorkenntnisse][Methoden] etc.
Abschluß-arbeit
WU-Ab-schlußarbeit-datenbank
bestehtaus
Fachwissenschaftl.Mitarbeiter
Studierende/-r
Abschluß-arbeitbe-treuung
*
[Status]Vergabe
*
[Fachrolle]- Erstfach
- Nebenfach
gehörtzu
[Beurteilung] etc.
Abschluß-arbeitbe-
gutachtung
1WU-Themen-
datenbank
WU-Dipl./Diss.-Datenbank
Diplom-arbeit
1
Dissertation
TypAbschluß-
arbeit
typisiertdurch
n
1
n cn
cn
cn
1
cncn cn
1
cn
Abbildung 56: Semantisches Datenmodell ‘Abschlußarbeiten’
Erstellt gemeinsam mit 15. April 1998 Seite 123 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.3.2.8 Anerkennung
Abbildung 57: Semantisches Datenmodell ‘Anerkennung’
Ane
rken
nung
s-an
trag
Ane
rken
nung
s-be
sche
id
*
Stu
dier
ende
/-r *
veru
rsac
ht
stel
lt
bein
halte
tA
nerk
ennu
ngs-
gege
nsta
nd
Nos
trifiz
ieru
ng e
tc. *
c
Wis
s. T
ätig
-ke
it de
sS
tudi
eren
den
Wis
s. A
rbei
tde
sS
tudi
eren
den
ausl
ändi
sche
rS
tudi
enab
schl
ußde
s S
tude
nten
Prü
fung
des
Stu
dier
ende
n *
Ver
wal
tung
s-m
itarb
eite
r
Term
in
Term
in(-
liste
)de
s V
MA
's
(Vor
lage
-)Te
rmin
liste
*
defin
iert
gibt
Vor
-la
gete
rmin
für
Vor
lage
-te
rmin
bear
beite
t
Stu
dien
-pl
anpu
nkt
*
bezi
eht
sich
auf
cn1c1
n
1
cn
cn
11
cn cn
1
n
cn1
c
cn
Seite 124 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.3.2.9 Abrechnung
wissenschaftl.Mitarbeiter
s. "2gether - Grobkonzept", S. 90
1interner
Mitarbeiter
externerMitarbeiter
Prüfungs-beteiligung
s. "2gether - Grobkonzept", S. 91
Leistung
Abgeltung
c
erfolgtnach
[Regelwerk] etc.
Lehrauftrag, remuneriert
Lehrauftrag, nicht remuneriert
Kollegiengeld
Tutorengeld
Prüfungstaxe
Abgeltungs-art
*
Abrechnung Abrechnungs-position
LV-Leitung
LV-Beteiligung
Prüfungs-leitung
Abschluß-arbeitbe-treuung
Abschluß-arbeitbe-
gutachtung
cn
1
1 cnn cn
Abbildung 58: Semantisches Datenmodell ‘Abrechnung’
Erstellt gemeinsam mit 15. April 1998 Seite 125 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.3.2.10 Hörsaalverwaltung
[Größe][Ausstattung] etc.
Raum
1
zweck-gebundener
Raum
instituts-eigenerRaum
EDV-Schulungs-
raum
c
1internerRaum
z.B. Austria CenterexternerRaum
Mitarbeiter
[@Belegungszeit] etc.
Reservierung
persönlicherRaum
Raum-anrecht
(Prüfungen)
Termin(-liste)des wiss.MA's Reservierung
Raum fürsonstige
Veranstaltung
Lehrver-anstaltungs-
raum
Hörsaal Seminar-raum
LV-Ankündigung
1
Zuteilung
[@Belegungszeit] etc.
Reservierung
Semester Abteilung
Raum-anrecht
Mitarbeiter
c
cn cn
cn
cncn
1
cn
cn
cn
1
cn
cn
Abbildung 59: Semantisches Datenmodell ‘Hörsaalverwaltung’
Seite 126 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
4.3.2.11 Evaluierung
Abbildung 60: Semantisches Datenmodell ‘Evaluierung’
[Tei
lnah
mef
requ
enz]
[Beu
rteilu
ng] e
tc.
Lehr
ver-
anst
altu
ngs-
beur
teilu
ng
wird
beur
teilt
durc
h
Lehr
ver-
anst
altu
ng
[Zie
lerfü
llung
][D
idak
tik]
[Ler
nbeh
elfe
][B
etre
uung
] etc
.
Erh
ebun
gs-
boge
n
faßt
zusa
mm
en
Eva
luie
rung
1
inte
rne
Org
anis
atio
ns-
einh
eit
Arb
eits
-be
richt
Anza
hl v
on:
[wis
s. In
stitu
tspe
rson
al]
[abg
ehal
tene
Leh
rver
anst
altu
ngen
][d
urch
gefü
hrte
Beu
rteilu
ngen
] etc
.so
wie
Bel
astu
ngsa
naly
se
Stu
dien
-ja
hr
Win
ter-
sem
este
r
Sem
este
r
Som
mer
-se
mes
ter
1
Stu
dien
-ja
hr
1c
n c
cn
cn
1 1
Erstellt gemeinsam mit 15. April 1998 Seite 127 von 171
3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption
4.3.2.12 Adresse
Adresse
Studierende/-r
Mitarbeiter
Organisations-einheit
Anschriftder Org.-Einh.
Anschriftdes MA's
Heimatan-schrift des
Studierenden
Studienan-schrift des
Studierenden
cccc
1
n
11
Abbildung 61: Semantisches Datenmodell ‘Adresse’
Seite 128 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
5 MENGEN- UND WERTGERÜSTDie folgende Tabelle 7 enthält eine Auflistung des Mengengerüstes, das für das zukünftige System ‘2gether’ von Bedeutung ist. Dabei wurden im wesentlichen drei Quellen berücksichtigt: das ‘Grobkonzept 2gether’, die Diplomarbeit von Mag. S. Schmidt sowie eine Auswertung zur Belastung der Institute im Studienjahr 1996/97 (vgl. Literaturliste im Anhang).
Unter der Spalte ‘Objekttyp’ erfolgt eine Klassifizierung der beschriebenen Größen in Form einer Einstufung einerseits als reine Benutzung des Systems, d.h. als Funktionalität („Fkt.“), andererseits als daten- (satz-) erzeugend („Ds.“). Letztere Größe hat (zunächst) Auswirkung auf den Speicherbedarf, erstere auf die Zugriffshäufigkeit.
Bereich Häufigkeit Bemerkung Objekttyp Jahr(Erst-)Zulassung 4.500 - 8.000 p.a. Schwerpunkt 1.
ZulassungswocheFkt., Ds. 1997
(pers.) Stundenplan 15.000 p.sem. zeitliche Spitzen Fkt. 1997(weitere) Zulassung, Wechsel
3.000 - 5.500 p.a. Fristen Fkt., Ds. 1997
Abmeldung v. Studienrichtung
1.000 p.a. Fkt. 1997
Abmeldung v. Studium 60 % d. Stud. aufwendig, zeitintensiv Fkt. 1997Abmeldung von LV 30.000 p.a. zeitliche Spitzen Fkt. 1997Abmeldung von Teildiplomprüfung
6.000 p.a. Fristen Fkt. 1997
Abrechnungen 5.000 LV’s, 144.000 Prüf., 1.100 wiss. Arb.
Fkt., Ds. 1997
Änderung PIN 30.000 p.a. Fkt. 1997Anerkennungsanträge 5 - 6.000 p.a. große Belastung Fkt., Ds. 1997Anerkennungs-bescheide
16.000 p.a. Fkt., Ds. 1997
Anmeldung zu LV 122 - 144.000 p.a.
zeitliche Spitzen Fkt., Ds. 1997
Erstellt gemeinsam mit 15. April 1998 Seite 129 von 171
5 MENGEN- UND WERTGERÜST
Bereich Häufigkeit Bemerkung Objekttyp JahrAnmeldung zu Teildiplomprüfung
23.000 p.a. zeitliche Spitzen Fkt., Ds. 1997
Aufnahme LV’s 2 p.a. à 2.500 Fkt. 1997Auskunft 100.000 p.sem. Fkt. 1997Erstellung/Wartung Studienpläne
4-20 ohne individuelle Fkt., Ds. 1997
Evalierung LV 122 - 144.000 p.a.
Fkt., Ds. 1997
Generierung IDFile 30.000 p.a. Fkt. (Ds.) 1997Generierung TAN’s 15.000 p.sem. Fkt. 1997Leistungsfeststellung 100.000 LV’s
10.000 Dipl.Fkt., Ds. 1997
Planung LV’s 2 p.a. à 2.500 Fkt., Ds. 1997Planung Prüfungen 2 p.a. Fkt., Ds. 1997Planung Studienjahr-einteilung
1 p.a. Fkt., Ds.
Prüfungsanmeldungen 12.750 Dipl. 125.000 Prüf.
Fkt., Ds. 1997
Raumverwaltung 3.700 p.a. Fkt., Ds. 1997Rückmeldung 52 - 65.000 p.a. großer Aufwand Fkt., Ds. 1997Standard-Ausdrücke z.B. 2.700
Diplome p.a.Fkt. 1997
Studienabschluß 1.300 - 1.600p.a. Fkt. 1997VVZ-Zugriff 75.000 p.sem. zeitliche Spitzen Fkt. 1997Wartelisteeinträge Teildiplomprüfung
30.000 p.a. Fristen Fkt., Ds. 1997
Wiss. Arbeiten 1.000 Dipl., 100 Diss.
Fkt., Ds. 1997
Tabelle 7: Mengengerüst der Studien- und Prüfungsverwaltung i.w.S.
Darüber hinaus ist dieses Mengengerüst in die Abschätzung des Nutzenpotentials eingeflossen (siehe Kapitel 8).
Seite 130 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
6 DATENSCHUTZ UND DATENSICHERHEIT
6.1 SchutzbedarfsermittlungDurch eine angemessene IT-Sicherheitsstrategie soll die Datensicherheit zur Gewährleistung einer ordnungsgemäßen Informationsverarbeitung (im Interesse der datenverarbeitenden Stellen) und der Datenschutz bei der Verarbeitung personenbezogener Daten (im Interesse der betroffenen Studenten und Mitarbeiter) gewährleistet werden.
Da bei der Studien- und Prüfungsverwaltung personenbezogene Daten verarbeitet werden, ist das dargestellte Schutzstufenkonzept bei der Beurteilung der einzelnen Funktionalitäten zu Grunde gelegt, wobei auch der Verwendungszusammenhang der zu verarbeitenden Informationen berücksichtigt ist. Der Schutzbedarf der 2gether-Teilsysteme richtet sich nach dem Schutzbedarf seiner bedürftigsten Anwendung.
Ergibt sich ein niedriger oder mittlerer Schutzbedarf, ist ein standardisiertes IT-Sicherheitskonzept zu erstellen, wie es beispielsweise das IT-Grundschutzhandbuch des BSI, „Bundesamt für Sicherheit in der Informationsverarbeitung“ (Deutschland) zur Risikoanalyse und zur Auswahl der erforderlichen Maßnahmen bereitstellt.
Ergibt sich ein hoher oder sehr hoher Schutzbedarf, so ist ein individuelles Sicherheitskonzept – basierend auf weiterführenden individuellen Sicherheitsuntersuchungen – zu erstellen. Dazu gehören eine ausführliche Schutzbedarfsfeststellung für alle Objekte, eine Bedrohungs- und Risikoanalyse und ein IT-Sicherheitskonzept, das eine Auswahl und Bewertung der Maßnahmen, eine Kosten-/Nutzen-Betrachtung und eine Restrisikoanalyse enthält.
Das IT-Sicherheitskonzept ist umzusetzen durch: Abgleich vorhandener Maßnahmen mit dem Sollkonzept, Realisierung der offenen Maßnahmen, Realisierung der datenschutzrechtlichen Anforderungen, Beteiligung des Beauftragten für Datenschutz, Freigabe des Verfahrens, Schulung der Anwender, Inbetriebnahme des Verfahrens.
Erstellt gemeinsam mit 15. April 1998 Seite 131 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
6.1.1 Schutzstufenkonzept
6.1.1.1 Stufe INiedriger/geringer Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung keine besondere Beeinträchtigung des informationellen Selbstbestimmungsrechts erwarten läßt.
Beispiele:
Name, Anschrift, Beruf, Geburtsjahr, Tel.-Nr., Titel, Telefonverzeichnis, Adreßangaben, Bankverbindungen, Adreßdaten von Funktionsträgern an der Wirtschaftsuniversität
Mittlerer Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung eine besondere Beeinträchtigung des informationellen Selbstbestimmungsrechts insofern erwarten läßt, als der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen beeinträchtigt werden kann.
Beispiele:
Kontenstände, Familienstand, Zeugnisse, Prüfungsergebnisse, Versicherungsdaten, Wehrdienstzeit, Grad der Behinderung, Personalverwaltungsdaten aus dem Beschäftigungsverhältnis (mit Ausnahme von dienstlichen Beurteilungen, berufliche Laufbahn, nähere Angaben über Behinderung u. dgl.), Studentendaten.
Die einzelnen Maßnahmen für die Sicherstellung des Schutzbedarfs der Stufe I können dem IT-Grundschutz (für mittleren Schutzbedarf) entnommen werden.
6.1.1.2 Stufe IIHoher Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung eine erhebliche Beeinträchtigung des informationellen Selbstbestimmungsrechts insofern erwarten läßt, als der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen erheblich beeinträchtigt werden kann oder die Daten aufgrund ihrer besonderen Sensibilität bzw. ihres Verwendungszusammenhangs einen höheren Schutzbedarf als Stufe I erfordern.
Seite 132 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Beispiele:
besonders sensible Sozialdaten, Steuerdaten, Daten, die einem Berufs-, Geschäfts-, Fernmelde- oder Mandantengeheimnis unterliegen, Personalverwaltungsdaten (dienstliche Beurteilungen, berufliche Laufbahn u. dgl.) soweit nicht Stufe I, als „streng vertraulich“ eingestufte Verwaltungsdaten.
Sehr hoher Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung eine sehr hohe Gefährdung des informationellen Selbstbestimmungsrechts insofern erwarten läßt, als eine Gefahr für Leib und Leben oder die persönliche Freiheit des Betroffenen gegeben ist.
Beispiele:
Adressen von polizeilichen V-Leuten, Adressen von Zeugen in bestimmten Strafverfahren.
Als Maßnahme für die Sicherstellung des Schutzbedarfs der Stufe II ist ein maßgeschneidertes Sicherheitskonzept nach individueller Bedrohungs- und Risikoanalyse („IT-Grundschutz + X“) zu erstellen.
Ausgehend von der oben dargestellten Schutzbedarfsermittlung sind zur Realisierung des IT-Grundschutzes bei IT-Vorhaben – wie dem Projekt „2gether“ – für folgende Bereiche entsprechende Maßnahmen zu treffen:
Organisation, Personal, Notfallsvorsorgekonzept, Datensicherungskonzept, Datenschutzkonzept, Gebäude, Verkabelung, Büroräume, Serverräume/Rechnerraum, Datenträgerarchiv,
Erstellt gemeinsam mit 15. April 1998 Seite 133 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Räume für technische Infrastruktur, lokales Netzwerk, TK-Anlage, vernetzte PCs.
6.1.2 Schutzbedarf im Projekt „2gether“Es wird empfohlen, im Rahmen des Projekts „2gether“ folgende Schutzbedarfszuordnung vorzunehmen:
Gruppe Modul Schutzbe-darf
Stufe
Lehrveranstaltungen
Administration Lehrveranstaltung mittel I
Aufnahme Lehrveranstaltung mittel IPlanung Lehrveranstaltung kein I
Prüfungen Leistungsfeststellung mittel IPlanung Prüfungstermin niedrig/gering I
Studien Beendigung Studium mittel IRückmeldung Studium niedrig/gering IWechsel Studium/Aufnahme Zusatzstudium
mittel I
Zulassung Studium mittel I
Diplomarbeiten & Dissertationen
Einreichung, Beurteilung & Veröffentlichung
mittel I
Laufende Betreuung niedrig/gering IThemenvereinbarung niedrig/gering I
Anerkennungen Anerkennung durchführen mittel I
Seite 134 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Gruppe Modul Schutzbe-darf
Stufe
Anerkennung vorbereiten mittel IBescheide der Anerkennung ausfertigen
mittel I
Abrechnungen Abrechnung mittel I
Evaluierungen Arbeitsbericht Institutsvorstände kein IBeurteilung Lehrveranstaltung niedrig/gering I
An- und Abmeldungen
Lehrveranstaltungsanmeldung durchführen
mittel I
Prüfungsabmeldung durchführen mittel IPrüfungsanmeldung durchführen mittel I
Allgemeine Module Hörsaaladministration kein IChipkartenverwaltung hoch II
Tabelle 8: Zuordnung des Schutzbedarfes
6.2 ChipkartenWichtige Funktionalitäten der Chipkarten sind:
Chipkarten als Speicher von Daten, die hinsichtlich ihrer Vertraulichkeit und/oder Integrität hohen Schutzbedarf aufweisen (z. B. Kontodaten, Personalverwaltungsdaten, Sozialdaten);
Chipkarten als Mittel zur Authentisierung ihres Trägers für die Gewährung des Zugriffs auf sicherheitsrelevante Daten und Funktionen (Kontoverfügungen, Änderung prüfungsrelevanter Individualdaten);
Chipkarten als Mittel zur Signatur von Dokumenten (Anerkennungsbescheide, Willenserklärungen
Erstellt gemeinsam mit 15. April 1998 Seite 135 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
[Lehrveranstaltungs- und Prüfungsanmeldungen], Prüfungsergebnisse etc.);
Chipkarten als Träger elektronischer Geldbörsen.Für den datenschutzgerechten Einsatz von Chipkarten ist eine konsequente und überzeugende Sicherungstechnologie erforderlich. Datensicherungsmaßnahmen müssen in ihrer Gesamtheit einen hinreichenden Schutz der Daten vor Mißbrauch gewährleisten. Dabei ist von folgenden Gefahren auszugehen:
unbefugte Preisgabe von Informationen (Verlust der Vertraulichkeit);
unbefugte Veränderung von Informationen (Verlust der Integrität); unbefugte Vorenthaltung von Informationen oder Betriebsmitteln
(Verlust der Verfügbarkeit); unbefugte Änderung identifizierender Angaben (Verlust der
Authentität).Diese Gefahren sind sowohl dann zu betrachten, wenn die Daten auf der Chipkarte gespeichert werden, als auch dann, wenn sie in einer externen Datenbank gespeichert werden, die durch Chipkarten erschlossen wird.
Das Sicherungskonzept für Chipkarten sollte folgende Mindestanforderungen erfüllen:
Ausstattung des Kartenkörpers mit fälschungssicheren Authentisierungsmerkmalen wie z.B. Unterschrift, Foto, Hologramme.
Steuerung der Zugriffs- und Nutzungsberechtigungen durch die Chipkarte selbst.
Realisierung aktiver und passiver Sicherheitsmechanismen gegen eine unbefugte Analyse der Chip-Inhalte sowie der chipintegrierten Sicherheitsfunktionen.
Benutzung allgemein anerkannter, veröffentlichter Algorithmen für Verschlüsselungs- und Signaturfunktionen sowie zur Generierung von Zufallszahlen.
Sicherung der Kommunikation zwischen der Chipkarte, dem Chipkartenbasierten Dienstleistungssystem (CDLS) und dem ggf. im Hintergrund wirkenden System durch kryptographische Maßnahmen.
Seite 136 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Sicherung unterschiedlicher Chipkartenanwendungen auf einer Chipkarte durch gegenseitige Abschottung.
Durchführung einer gegenseitigen Authentisierung von Chipkarte und CDLS mit dem Challenge-Response-Verfahren.
Grundsätzlich sollte zunächst die Möglichkeit in Betracht gezogen werden, daß bei der Chipkartenbenutzung Anonymität gewahrt bleiben kann. Ist dies nicht möglich, sollten Wahlmöglichkeiten anonymer Alternativen geschaffen werden.
Der Chipkarteninhaber bzw. die Betroffenen sollten die Möglichkeit erhalten, auf neutralen, zertifizierten Systemumgebungen die Dateninhalte und Funktionalitäten ihrer Chipkarten einzusehen (Gebot der Transparenz).
Die gesamte Infrastruktur ist zu dokumentieren und die Produktion, die Initialisierung und der Versand der Chipkarten zu überwachen.
Wie in der Einleitung kurz dargestellt, sind Chipkarten nicht als isolierte Träger von Risiken zu betrachten, wenn es um Fragen ihrer IT-Sicherheit geht. Aufwendige sicherheitstechnische Maßnahmen an und in der Chipkarte können durch unsichere Systemumgebungen bei der weiteren Verwendung der Daten konterkariert werden.
Wenn zum Beispiel das System der Studien- und Prüfungsabteilung nicht den erforderlichen Schutz bietet, können die Schutzmaßnahmen der Karte umgangen werden. Der Schutz der Chipkarte gegen unbefugte Manipulationen ist weitgehend wertlos, wenn beim elektronischen Zahlungsverkehr das POS-Terminal leicht manipuliert werden kann. Jedoch sieht ISO/IEC 7816 Schutzmechanismen vor, die bei richtiger Anwendung mit vertretbarem Aufwand nicht umgangen werden können.
Allgemein sind an die Sicherheitsfunktionen folgende Anforderungen zu stellen:
Zugriffs- und Nutzungsberechtigungen sollten soweit möglich von der Chipkarte selbst geprüft und gesteuert werden.
In Anwendungen sollten sich alle beteiligten Rechner (inkl. Chipkarten) gegenseitig authentifizieren. Die Authentifizierung des Benutzers hat gegenüber der Chipkarte zu erfolgen.
Sicherheitserwägungen greifen bereits bei der Herstellung, Initialisierung und dem Versand von Chipkarten. Dabei müssen
die Produktion der Prozessoren und Chipkarten,
Erstellt gemeinsam mit 15. April 1998 Seite 137 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
die Produktion und das Laden von Software, das Erzeugen der Schlüssel, das Laden der Schlüssel in die Sicherheitsmodule (Internal
Elemetary Files), das Laden von Hersteller- und Transportschlüssel für die spätere
Initialisierung und die Ausgabe der Chipkarten und Transportschlüssel an den
Empfänger, insbesondere der Versand an die Studierendendurch entsprechende technische und organisatorische Maßnahmen abgesichert werden.
Zunächst sollte sichergestellt sein, daß sich nicht alle Teile des Betriebssystems im ROM befinden, damit der Chiphersteller nicht über das ganze Wissen über die Sicherung der Chipkarte verfügt. Wesentliche Teile des Betriebssystems können bei der späteren Initialisierung über entsprechend authentisierte CDLS dynamisch aus Tabellen geladen werden (siehe auch Grobkonzepts 2gether, Kapitel 6.2, „Chipkartenverwaltung“).
Darüber hinaus sollte das Betriebssystem in folgender Weise Sicherheit „erzeugen“:
Die Identifizierung und Authentifizierung des Benutzers erfolgt mittels PIN oder mit biometrischen Verfahren.
Üblicherweise erfolgt die Prüfung einer PIN. Zwar können die normale Forderungen zur Paßwortverwaltung bei Rechnern nicht voll auf Chipkarten übertragen werden, jedoch sollte die PIN-Länge je nach Sensibilität mindestens 4 oder mehr Stellen betragen, die Anzahl der Fehlversuche begrenzt sein, die Möglichkeit bestehen, die PIN zu ändern und eine Freischaltung der Karte auch mittels Personal Unblocking Key (PUK) in Abhängigkeit von der Anwendung ermöglicht werden.
Es erfolgt eine Zugriffskontrolle mit einer Rechteverwaltung, wobei die Zugriffsrechte an die einzelnen Dateien geknüpft werden. Den Dateien sind Sicherheitsattribute zugeordnet, mit denen festgelegt wird, ob die Dateien (Daten) gelesen, kopiert, beschrieben, gelöscht, gesperrt oder freigegeben werden dürfen.
Wenn anderen Personen als dem Karteninhaber Zugriffsmöglichkeiten auf die Chipkarte gewährt werden sollen, erfolgt dies im Rahmen einer Programm-Programm-Kommunikation mit einem anderen Rechner oder einer anderen
Seite 138 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Karte (z.B. mit einer Professional Card). Der Rechner bzw. die andere Karte muß authentifiziert werden.
Zwar bilden – wie oben festgestellt – Chipkarten und CDLS erst zusammen ein vollwertiges Rechensystem, jedoch befinden sich beide Komponenten in der Regel in unterschiedlicher Verfügungsgewalt, die Karte in der des Inhabers und das CDLS in der von Anwendern.
Wenn eine Chipkarte in ein CDLS eingeführt wird, gibt der Inhaber, d. h. z. B. der Student/die Studentin, die Verfügungsgewalt über die Software auf der Karte und die ihn betreffenden Datenbestände auf. Eine unbefugte Veränderung der Software muß daher technisch verhindert werden.
Der Karteninhaber sollte daher nicht nur die Möglichkeit haben, sich den Inhalt der gespeicherten Daten anzeigen zu lassen, sondern die tatsächlichen Funktionen z. B. auf neutralen CDLS testen zu können. Wegen der u. U. unterschiedlichen Interessenlagen (z. B. bei der Anmelde- und Prüfungsadministration) ist die Prüfung der korrekten Funktion der Software sowie umgekehrt des Ausschlusses ungewollter Funktionen im realisierbaren Rahmen zu ermöglichen.
Als besonders angriffsgefährdet sind CDLS vom Typ „PC mit Kartenterminal“ anzusehen, sofern sie nicht in manipulationsgeschützten Umgebungen eingesetzt werden. Erhöhte Schutzfunktionen werden hier als notwendig angesehen.
6.3 InternetMit dem Zugang zum Internet sind Risiken verbunden, die größtenteils daraus resultieren, daß dieses Datennetz nicht unter Sicherheitsaspekten entwickelt wurde und historisch gewachsen ist. Schwächen finden sich in den Protokollen für die Datenübertragung, in den Implementierungen und Installationen der Programme für die Internet-Dienste und in den angeschlossenen Übertragungswegen und Rechnersystemen.
Dies ist besonders gravierend, weil aufgrund der riesigen Zahl von Internet-Teilnehmern auch die Zahl der potentiellen Angreifer, die diese Sicherheitslücken ausnützen und somit die am Internet angeschlossenen Verwaltungsrechner und -netze bedrohen können, sehr groß ist.
Sensible Daten, insbesondere personenbezogene Daten, sind bei entsprechendem Schutzbedarf mit Hilfe hinreichend sicherer, kryptographischer Verfahren zu verschlüsseln; hierzu gehören auch Paßwörter und sonstige Authentifikationsdaten. Es sollte angestrebt werden,
Erstellt gemeinsam mit 15. April 1998 Seite 139 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
generell alle Transport- und Verkehrsdaten auf möglichst niedriger Protokollebene zu verschlüsseln und sichere Authentisierungsverfahren einzusetzen. Bei asymmetrischen Verschlüsselungsverfahren sollte eine vertrauenswürdige, zentrale Stelle mit der Funktion der Schlüsselerzeugung und -verwaltung (Trust-Center) beauftragt werden.
Übernommene Programme und Dokumente sind vorab mit einem aktuellen Virenscanner auf Virenfreiheit zu testen. Wenn möglich, sollte auch die Integrität der Daten überprüft werden, wozu z. B. Verfahren der elektronischen Unterschrift und/oder Prüfsummenverfahren genutzt werden können.
Da ein Netzanschluß der Rechner im Rahmen der Studien- und Prüfungsadministration unbedingt erforderlich ist, sollte die Sicherheit der Verwaltungsnetze und der Schutz von personenbezogenen Daten, die auf vernetzten Systemen verarbeitet werden, durch den Einsatz geeigneter Schutzkonzepte mit Hilfe einer zwischengeschalteten Prüf- und Filterfunktion (Firewall) gewährleistet werden.
Der ausschließliche Einsatz einer zentralen Firewall-Lösung ist nur dann vertretbar, wenn sich die Sicherheitsmaßnahmen an den Daten orientieren, die den höchsten Schutzbedarf haben.
Da jedoch das WU-Netz aus einer Vielzahl verschiedener Teilnetze besteht, in denen Daten unterschiedlicher Sensibilität verarbeitet werden, empfiehlt es sich, das Konzept gestufter Firewalls anzuwenden. Die Anbindung an das Internet sollte allerdings nur über einen zentralen Zugang (Gateway) erfolgen.
Werden in den anzuschließenden Netzen sensible personenbezogene Daten verarbeitet, ist der hohe personelle und sachliche Aufwand für Firewall-Lösungen gerechtfertigt und geboten. Firewall-Konzepte stellen erhöhte Anforderungen an die lokale Systemverwaltung, da Administrationsfehler in diesem Bereich ungleich schwerwiegendere Konsequenzen haben können als bei isoliert betriebenen Rechnern.
Seite 140 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
7 MIGRATIONSKONZEPT
7.1 AllgemeinesDen folgenden Ausführungen zum Migrationsplan (wie auch den Wirtschaftlichkeitsbetrachtungen in Kapitel 1) liegen die Aufwandsschätzungen der Firma Alper & Pesch Ges.m.b.H. zugrunde, die diese auf Grundlage des „Grobkonzepts 2gether“ im Juni 1997 vorgenommen hat.
Aufgrund des geschätzten Gesamtaufwandes für die Realisierung des „2gether“-Projekts von ca. 36 Personenjahren ist ein Realisierungszeitraum von 3 Jahren als realistisch und machbar anzusehen und wird in diesem Ausmaß auch von uns empfohlen.
Basierend auf den derzeitigen Gegebenheiten bietet sich eine stufenweise Einführung des neuen Systems an (siehe Punkt 7.6). Der Stufenplan sieht eine vorrangige Ablöse der BS2000-Anwendungen vor; die Übernahme der Funktionalität der WUFIS-Anwendungen erfolgt erst in einer oder mehreren nachfolgenden Stufen.
Der empfohlene Projektablauf orientiert sich an folgenden Basis-Terminen:
1998 1999 2000 2001 20021 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Implementierung Stufe I Echtbetrieb Stufe I
Implementierung Stufe II Echtbetrieb St. II
Tabelle 9: Empfohlene Basistermine
Der vorgeschlagene Terminplan beruht auf den in den folgenden Punkten ausgeführten Überlegungen.
Erstellt gemeinsam mit 15. April 1998 Seite 141 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
7.2 Ablöse STEPDB und INSTDBBei der Ablöse der alten Datenbankanwendungen durch die neue Software im Rahmen des 2gether-Projektes sind folgende Kriterien zu beachten:
7.2.1 DatenübernahmeSobald – wie im gegenständlichen Fall – sich die geplante neue Datenbankstruktur wesentlich von der alten unterscheidet und es gleichzeitig unmöglich ist, die neuen Anwendungen ohne „Altdaten“ zu starten, stellt die Datenübernahme eine erhebliche Erschwernis für die Betriebsaufnahme dar. Erfahrungsgemäß treten hierbei Probleme der folgenden Arten auf:
Die Altdaten entsprechen nicht den Konsistenzbedingungen der neuen Datenbank.
Die Altdaten können nicht sämtliche notwendigen Felder der neuen Datenbank beschicken.
Die Umschlüsselung bestimmter Felder ist nicht eindeutig geklärt. Die Altdaten weisen Datenfehler auf, die bis dato nicht erkannt
oder einfach hingenommen wurden. Die Normalisierung bringt nicht den gewünschten Erfolg, weil
durch – meist geringfügige – Abweichungen in der Schreibweise Daten nicht zusammenfinden.
Erschwerend tritt hinzu, daß sich im – bis zuletzt lebenden – Altbestand auch noch zwischen dem letzten Test und der realen Übernahme derartige Problemfälle ergeben können. In dieser Hinsicht kann die stichtagsgenaue fehlerfreie Datenübernahme überhaupt nur nach Festlegung eines Änderungsstops der Altanwendung garantiert werden.
Der Umfang allfällig erforderlicher manueller Eingriffe nach der Datenübernahme kann in bezug auf neu hinzukommende Felder frühzeitig geschätzt werden, nicht aber in bezug auf erst bei der Überleitung auftretende Datenfehler und Inkonsistenzen.
Im Detail können konkrete Aussagen über die Datenübernahme erst nach endgültiger Festlegung der neuen Datenbankstruktur gemacht werden.
Seite 142 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
7.2.2 Anmerkungen zur Synchronisation von DatenbankenEine permanente Online-Synchronisation großer Datenbanken ist praktisch ausgeschlossen. So lange der Altdatenbank die Führung des aktuellen Standes obliegt, muß von der Altanwendung aus nach jeder Datenbankveränderung eine analoge Veränderung der neuen Datenbank angestoßen und anschließend ein gemeinsames Commit abgesetzt werden. Dies erscheint im gegenständlichen Fall aus folgenden Gründen nicht realisierbar:
Zu hoher Änderungsaufwand in den Altanwendungen. Notwendigkeit eines 2-Phasen-Commit über zwei Datenbanken
unterschiedlicher Technologie.Hat die Neudatenbank die Führung inne, so stellt sich das umgekehrte Problem, nämlich daß in den Neuanwendungen die Datenbankveränderungen im Altsystem mitbetreut werden müssen. Komplizierte Eingriffe in die Logik der Altprogramme wären somit auf alle Fälle erforderlich.
Eine regelmäßige Batch-Synchronisation ist grundsätzlich möglich. Der Nachteil dieser Methode liegt allerdings in den zu erwartenden hohen Laufzeiten für den regelmäßig notwendigen Datenabgleich, der zumindest die Tagfertigkeit der Datenbanken sicherstellen sollte. Bei dem derzeitigen hohen Änderungsaufkommen kann davon ausgegangen werden, daß im vorliegenden Falle Tagfertigkeit nicht erreicht werden kann.
Eine schrittweise Übernahme der derzeitigen STEPDB- und INSTDB-Anwendungen ist daher – allein wegen der aufgezeigten unzureichenden Synchronisationsmöglichkeiten – nicht als sinnvoll anzusehen. Es muß somit von der Notwendigkeit ausgegangen werden, beide Datenbanken an einem gemeinsamen Stichtag umzustellen.
7.3 Zeitlicher AspektNach Aussagen des Herstellers SNI ist die derzeitige Version des Betriebssystems BS2000 und des Datenbanksystems UDS im Jahre 2000 nicht mehr lauffähig. Als Konsequenz muß
entweder auf die neuen Releases von BS2000 und UDS umgestiegen werden
oder die Datenbanken STEPDB und INSTDB werden noch vor dem Jahr 2000 außer Betrieb genommen.
Erstellt gemeinsam mit 15. April 1998 Seite 143 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Seitens der ADV wird glaubwürdig versichert, daß die Datenbankanwendungen STEPDB und INSTDB selber kein Problem im Zusammenhang mit dem Jahrhundertwechsel bereiten. Die Weiterverwendung der alten Anwendung verursacht demnach ausschließlich aufgrund notwendiger Systemadaptierungen (bei Hardware und Software) zusätzliche Kosten, und zwar in Höhe von fast 3 Mio. öS.
Die Alternative, die BS2000-Systeme mit Ende 1999 außer Betrieb zu nehmen, kann nur unter enormem Zeitdruck realisiert werden. Da über STEPDB und INSTDB vor allem der Massenbetrieb zu Semesterbeginn abgewickelt wird (Immatrikulation, Inskription, Rückmeldung, Anmeldungen) und diese Aktivitäten Auswirkungen auf das ganze Semester haben, wäre der einzige realistische Zeitpunkt der Umsetzung der Sommer 1999, sodaß zu Beginn der Inskriptionsfrist zum Wintersemester 1999/2000 die neuen Datenbankanwendungen bereitstehen müssen. Da der angesprochene Zeitdruck jedoch unweigerlich auch qualitative Probleme mit sich bringt, die nicht nur Unzufriedenheit, sondern auch Mehrkosten in derzeit nicht abschätzbarer Höhe verursachen können, kann diese Variante (sofortige Ablösung der BS2000-Systeme) unsererseits nicht empfohlen werden.
Bezüglich der Oracle-Anwendungen sind Jahr-2000-Einschränkungen nicht bekannt, allerdings sind hier noch entsprechende Garantien des Herstellers einzuholen.
7.4 SchnittstellenZwar sind die STEP-Anwendungen zu einem gemeinsamen Stichtag zu ersetzen, es kann jedoch davon ausgegangen werden, daß – um den dadurch entstehenden Zeitdruck abzuschwächen – die Umstellung der übrigen Anwendungen zu einem späteren Termin erfolgen kann.
Solange die derzeitigen WUFIS-Anwendungen jedoch nicht in das neue System integriert sind, sind entsprechende Schnittstellen vorzusehen. Als wichtigste Schnittstellen sind hier anzuführen:
7.4.1 VorlesungsverzeichnisEs empfiehlt sich, die Anwendungen zur Erstellung des Vorlesungsverzeichnisses und zu dessen Publikation zunächst in WUFIS beizubehalten. Für den Studienbetrieb im neuen 2gether-System ist lediglich die Kenntnis der angebotenen Lehrveranstaltungen notwendig.
Seite 144 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Es ist somit eine Schnittstelle erforderlich, die entweder – analog zur heutigen WUFIS-STEP-Schnittstelle – die Daten der angebotenen Lehrveranstaltungen in 2gether einspielt oder einen Zugriff von 2gether aus auf die WUFIS-Datenbank erlaubt. In diesem Zusammenhang soll auf die Komplexität der Schnittstelle hingewiesen werden; nach Angaben der ADV war zur Implementierung der derzeit verwendeten Schnittstelle ein Programm mit ca. 9.000 Statements erforderlich.
Es ist des weiteren zu beachten, daß nicht nur alle Lehrveranstaltungen des betreffenden Semesters überzuleiten sind, sondern auch alle jene aus früheren Semestern, zu denen noch Prüfungen abgehalten werden.
7.4.2 HörsaalbelegungDie aktuelle Hörsaalbelegung hat ausschließlich Informationswert und beeinflußt nicht den Studienbetrieb im neuen 2gether-System. Auch diese Anwendung kann zu einem späteren Termin umgestellt werden.
Dennoch ist zu empfehlen, die Hörsaalbelegung generell zu Semesterbeginn und dann bei Bedarf in 2gether überzuleiten, um den Studierenden ein Maximum an Information unter einer einheitlichen Oberfläche anzubieten.
7.5 ÜbergangszeitraumWie in den vorstehenden Abschnitten ausgeführt, können es verschiedene Umstände zweckmäßig erscheinen lassen, bei der Einführung von 2gether nicht mit der vollen Funktionalität zu starten. Als mögliche Gründe hierfür können folgende angeführt werden:
Reduzierung des Zeitdrucks; Möglichkeit zur Erstellung eines praktikablen
Umstellungszeitplanes; Verteilung der Entwicklungskosten auf einen längeren Zeitraum,
ohne bis zur Fertigstellung auf jeden Nutzen aus der Neuentwicklung verzichten zu müssen.
Eine Verschiebung von Teilbereichen wirkt sich nicht nur im Hinblick auf den Zeitraum für die Softwareentwicklung aus, sondern auch im Hinblick auf Datenbestände, die nicht unmittelbar aus den alten Datenbanken übergeleitet werden können, sondern einer Nachbearbeitung oder Nacherfassung bedürfen. Ansatzpunkte in dieser Richtung sind in nachstehenden Punkten angeführt.
Erstellt gemeinsam mit 15. April 1998 Seite 145 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
7.5.1 Historische Daten der StudentenFür die Zulassung zu bestimmten Lehrveranstaltungen oder Prüfungen sind bestimmte Vorbedingungen zu erfüllen – das sind in der Regel absolvierte Prüfungen oder bescheidmäßig festgestellte Anrechnungen. Ob eine lückenlose Übernahme dieser Daten aus der STEPDB nach 2gether möglich ist, kann erst nach endgültiger Festlegung der neuen Datenstruktur untersucht werden. Es ist jedoch schon zum jetzigen Zeitpunkt damit zu rechnen, daß sich diese Datenüberleitung als äußerst erweisen wird. Sollte sie überhaupt undurchführbar sein, würde die Notwendigkeit entstehen, ohne Prüfungshistorie zu beginnen. Dazu muß der Studienabteilung jedoch eine einfache Möglichkeit geboten werden, für Studierende, die den Nachweis einer Voraussetzung benötigen, diesen direkt am Schalter nachzuerfassen. Um manuelle Tätigkeiten dieser Art so gering wie möglich zu halten, ist danach zu trachten, einen möglichst hohen Anteil an Prüfungshistorien und Anrechnungen automatisiert aus dem Altsystem zu übernehmen.
7.5.2 SelbstbedienungsfunktionenDie vorgesehenen Selbstbedienungsfunktionen für die Studierenden führen zu einer umfassenden Entlastung der angestellten Verwaltungskräfte. Aus Gründen der Ausfallssicherheit sollte dennoch die Möglichkeit beibehalten werden, an den Schaltern der Studienabteilung die an sich für die Selbstbedienung vorgesehenen Tätigkeiten vorzunehmen.
7.6 Zeitlicher AblaufWird aus den genannten Gründen entschieden, das 2gether-Projekt stufenweise einzuführen, so erscheint folgende Reihenfolge des Einsatzes der neuen Anwendungen zweckmäßig:
Gruppe Modul FunktionalitätStufe1 2 3 4 5 6
Lehrveranstaltungen
Administration LV XAufnahme LV XPlanung LV X
Seite 146 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Gruppe Modul FunktionalitätStufe1 2 3 4 5 6
Anmerkung: durch Schnittstellen ist sicherzustellen, daß bereits in Stufe 1 die Inskription möglich ist.
PrüfungenPlanung Prüfungstermin
X
Leistungsfeststellung X
Studien
Studienpläne XZulassung Studium X X4
Zusatzstudium XStudienwechselRückmeldung Studium XBeendigung Studium X X5
Diplomarbeiten und Dissertationen
Themenvereinbarung XLaufende Betreuung XEinreichung, Beurteilung und Veröffentlichung
Beurteilung, soweit für Zeugnis erforderlich
X
Volle Funktionalität X
Anerkennungen
Anerkennung vorbereiten
X
Anerkennung durchführen
X
Bescheide ausfertigen X X6
Abrechnungen Abrechnung Basisfunktionalität XVolle Funktionalität X
EvaluierungArbeitsbericht Institut XBeurteilung Lehrveranst.
X
An- und Abmeldungen
Lehrveranst. Anmeldung
X
Prüfungsanmeldung XPrüfungsabmeldung X
Allgemeine Module
Hörsaaladministration XBenutzeradministration X
4 Eine allfällige Unterstützung des Aktenlaufes in solchen Fällen, wo Inskriptionsvoraussetzungen zu erfüllen sind, kann in einer späteren Phase erfolgen.5 Eine allfällige Unterstützung von Nebensystemen wie Bibliothek, Leihgeräte etc. kann in einer späteren Phase erfolgen.6 Eine allfällige Unterstützung des Aktenlaufes vor der eigentlichen Bescheiderstellung kann in einer späteren Phase erfolgen.
Erstellt gemeinsam mit 15. April 1998 Seite 147 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Gruppe Modul FunktionalitätStufe1 2 3 4 5 6
Chipkartenverwaltung Unabhängig vom Zeitplan
Tabelle 10: Definition möglicher Umstellungsstufen
Die Zuordnung zur ersten Realisierungsstufe ergibt sich primär aus der Notwendigkeit, zum Zeitpunkt ihrer Implementierung die UDS-Datenbanken abzulösen, ergänzt um weitere Funktionalitäten, die zur Abrundung eines provisorisch verwendbaren Gesamtsystems erforderlich sind. Die Stufen 2 bis 6 können unabhängig voneinander implementiert und auch beliebig kombiniert werden.
Es wird empfohlen, die Migration in den nachfolgend angeführten Schritten abzuwickeln.
7.6.1 DatenüberleitungDas Datenmodell muß in jenen Teilen, die für die Realisierung in Phase 1 vorgesehen sind, bis auf Attributsebene herunter festgelegt sein. Die Beziehungen zwischen den Tabellen müssen feststehen und die vorgesehen Foreign Keys definiert sein. Es ist der Übernahmeweg der Daten insbesondere der Alt-Datenbanken STEPDB und INSTDB festzulegen, wobei für Datenarten, die nicht 1:1 überzuleiten sind, entsprechende Umsetztabellen zu definieren sind.
Wie auch die Erfahrungen mit dem Projekt STEP2000 zeigen, ist die Überleitung der Daten aus Codasyl-basierten Datenbank in relationale Datenbanken nicht immer problemlos, vor allem wenn das Datenbankdesign auf das jeweilige Datenbanksystem abgestimmt ist – was schon allein aus Performance-Gründen fast immer der Fall ist. Es hat sich deshalb als günstig erwiesen, einen Zwischenschritt in Form einer UDS-Datenbank einzuführen, die im Aufbau bereits an die relationale Ziel-Datenbank angepaßt ist.
Im Anschluß daran ist erstmalig eine Datenübernahme aus den Alt-Datenbanken STEPDB und INSTDB vorzunehmen. Bei Notwendigkeit sind die Umsetztabellen solange zu ergänzen, bis eine vollständige fehlerlose Datenübernahme möglich ist.
Die endgültige Datenüberleitung erfolgt anläßlich der Aufnahme des Echtbetriebes.
Seite 148 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
In analoger Weise ist auch die Übernahme von Daten aus den WUFIS-Anwendungen vorzubereiten, nur mit der Besonderheit, daß diese Überleitungen als Schnittstellen auch noch während des Echtbetriebes der bereits implementierten 1. Stufe stattfinden müssen, weshalb festzulegen ist, welche Daten jedesmal überschrieben und welche fortgeschrieben werden.
7.6.2 StammdatenerfassungDaten, die nicht durch Überleitung aus den Altsystemen gewonnen werden können, aber für ein funktionierendes System wesentlich sind (in der Regel Stammdaten), sind manuell zu erstellen. Dies hat derart zweigleisig zu erfolgen, daß die für den Echtbetrieb notwendigen Daten von den reinen Testdaten separiert bleiben.
7.6.3 Phase 1In Phase 1 sind die Funktionalitäten
Benutzeradministration Stammdaten Studierende Studien (mit geringfügigen Abstrichen) Prüfungen An-/Abmeldungen
erforderlich.
Zu den Funktionalitäten
Lehrveranstaltungen Studienwechsel Beurteilung der Diplomarbeiten/Dissertation Anerkennungsbescheid Abrechnung Hörsaaladministration
sind insoweit Basisfunktionalitäten vorzubereiten, daß das Gesamtsystem funktionsfähig ist.
Erstellt gemeinsam mit 15. April 1998 Seite 149 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
7.6.4 Weitere PhasenDie nachgelagerten Phasen 2 bis 6 können, was ihre Funktionalität betrifft, ohne Zeitdruck in Angriff genommen werden.
7.7 Zuordnungen alte/neue DatenbankDie folgende Tabelle 11 zeigt eine grobe Zuordnung zwischen den alten Datenbanken STEPDB und INSTDB zu den neuen Objekten. Die zweibuchstabigen Codes der Spalten STEPDB und INSTDB entsprechen den Tabellennamen, gefolgt von der Anzahl der Einträge im März 1998.
Objektname StepDB InstDB AnmerkungenAbgeltungsart PQ (6634) Kollegiengeld etc.Abschlußarbeit Diplomarbeit etc.; Titel, Termine,
Methoden, Kurzfassung, Förderungsmöglichkeiten
Abschlußarbeitsbegutachtung
Beurteilung, Begründung
Adresse PE (2383) ST (92072)
Anerkennungsbescheid
BD (38325) BB (112821) BL (222)
Aktenzeichen, Datum, Inhalt, Anrechnungsvermerk
Anerkennungsgegenstand
AN (81284) Behörde, Datum, evtl. Note, Art, Semesterzahl
Anmeldung LM (1029897) LV oder Prüfung; Datum, Status, NummerArbeitsberichtErhebungsbogenLehrauftragsrahmen
Lehrauftragstyp, Versteuerungsart
Lehrveranstaltung LV (8718) LV (5720) Typ, Bezeichnung, Daten aus der Ankündigung
Lehrveranstaltungsanmeldung
LS (689688) Anmeldungsreihenfolge
Lehrveranstaltungsbeurteilung
LP (36568) LT (103266)
Teilnahmefrequenz, Beurteilung
Lehrveranstaltungsrahmen
Kontingente, Rahmenwerte
Lehrveranstaltungsteilnahme
LS (689688) Ergebnisse
Lehrveranstaltungstermin
MT (18674) Teilnehmerzahl
Seite 150 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Objektname StepDB InstDB AnmerkungenLV-Ankündigung IL (26556)
AH (13) AR (74)
Nummer, Zeitraum, Bezeichnung, Typ, Wochenstunden, Termine, letztes Semester, Lehrziele, Lehrinhalte, Sprache, Anforderungen, Literatur, Teilnehmerzahl
LV-Beteiligung v. Org.-Einh.
Funktion, Art der Beteiligung, Remuneration
LV-Beteiligung Mitarbeiter
ER (972) MI (49069) MS (33173) MB (20714)
MI (39223) MT (18674)
rechtl. Grundlage, Art der Beteiligung, Abrechnungsdaten
Leistung PQ (6634) MQ (32585) MA (31815) LQ (23695)
QP (20244) Leistungsart (Prüfung, Begutachtung, ...)
Mitarbeiter PE (2383) PE (2135) Pers. Daten, Dienstverhältnis, Funktion, SV-Nr.
Nostrifizierung verl. GradOrganisationseinheit
IN (234) IN (80) Bezeichnung, Art, Typ, ..., Öffnungszeiten
Prüfung AB (2607) Bezeichnung, Art, Beschreibung, CodePrüfungen des wiss. MA
TT (31143) TK (29615)
Anmeldezeitraum, Teilnehmerzahlen, Zuteilungssystem
Prüfung des Studenten
BS (488439) PR (325313) ET (3263)
Beurteilung, Status, Einsichtsfrist
Prüfungstermin TE (1609) PositionRaum Größe, AusstattungReservierung Belegungszeit, StatusRückmeldung SI (746161) Datum, Typ, BemerkungSemester Anfang, Ende, Bezeichnung, 1. Und letzte
Unterrichtswoche, lehrveranstaltungsfreie Zeiten, Fristen, Termine
Studium Typ, GesamtstundenzahlStudium des Studenten
BS (488439) Anfangs- und Enddatum, Status, Erfüllungsstatus, Abgabestatus
Student ST (92072) SH (127163)
Name, Matrikelnummer, Zahlweise, Gebührenstatus, absolvierte Schule, Stammhochschule, Rückgabestatus, Salden
Studentenausweis Status, Gültigkeitszeitraum, Kontonummer WU
Studienplan PL (36) Bezeichnung, Inkrafttreten, Ablaufdatum, Versionsnummer, zu verleihender Titel
Studienabschnitt eines Studiums
Anzahl Semester, Nachlaßsemester, Stundenzahl
Studium der Zulassung
lfd. Nr., Status
Erstellt gemeinsam mit 15. April 1998 Seite 151 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Objektname StepDB InstDB AnmerkungenStudiumsänderung Wechsel, Aufnahme, BeendigungStudienplanpunkt BP (7129) Bezeichnung, Typ, StundenausmaßTermin des wiss. MA
Anmeldekapazität
Terminliste TE (1609) Art der Termine, GültigkeitszeitraumWartelistenposition LS (689688)Zuteilung BelegungszeitZulassung zum Studium
Datum, Termine, Anmeldenummer, Status, Kennwort, Bemerkung
Tabelle 11: Zuordnung der neuen Objekte
Die nachstehende Abbildung 62 gibt die Zusammenhänge innerhalb der STEPDB wieder. Die Pfeile sind grundsätzlich vom Owner in Richtung Member gezeichnet, strichlierte Pfeile sind Beziehungen, die nicht durch Sets, sondern mittels Foreign Keys realisiert sind (in der Regel die Matrikelnummer). Die dunkel hinterlegten Recordarten enthalten keine Daten.
Seite 152 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Abbildung 62: Struktur der Datenbank STEPDB
Erstellt gemeinsam mit 15. April 1998 Seite 153 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Es folgt eine analoge Graphik über die INSTDB (Abbildung 63). Auch hier enthalten die dunkel hinterlegten Recordarten entweder gar keine Daten oder nur ganz wenige (AB enthält 8 Records). PA enthält zwar 2183 Records, wird seitens des ZID als überholt bezeichnet, demnach ist PA nur mehr aus historischen Gründen in der Datenbank enthalten.
Seite 154 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Abbildung 63: Struktur der Datenbank INSTDB
Erstellt gemeinsam mit 15. April 1998 Seite 155 von 171
Grobkonzept Projekt
8 WIRTSCHAFTLICHKEITSBETRACHTUNGWirtschaftlichkeitsbetrachtungen werden üblicherweise dann angestellt, wenn es zu entscheiden gilt, ob ein bestehendes System durch ein neues ersetzt werden soll, oder auch dann, wenn eine Entscheidung zwischen mehreren Varianten getroffen werden muß.
Das Anstellen von Wirtschaftlichkeitsbetrachtungen ist dann problematisch, wenn es zur Ablöse eines Altsystems keine wirkliche Alternative gibt, wenn das Altsystem also aus zwingenden Gründen auf alle Fälle abgelöst werden muß, wie dies im Falle des STEP-Systems an der WU-Wien gegeben ist. Folgende Gründe, die eine rasche Ablösung des STEP-Systems unausweichlich machen, sind hier anzuführen:
Das System hat das Ende seines Lebenszyklus erreicht. Es ist zu erwarten, daß das Betriebssystem BS2000 in absehbarer
Zeit vom Hersteller nicht mehr unterstützt wird. Die angewendeten informationstechnologischen Methoden sind
überholt und nicht mehr wirtschaftlich; sie lassen wenig bis gar keinen Spielraum für die Integration neuer, moderner IT-Verfahren.
8.1 Anmerkungen zum Nutzen des neuen Systems
Die Ermittlung des durch die Einführung des neuen Systems „2gether“ zu erzielenden Nutzens erfordert die Differenzierung nach zwei wesentlichen Aspekten:
Zum einen besteht ein quantitativer Nutzen, der es den WU-Mitarbeitern ermöglicht, dieselbe bisherige Tätigkeit in kürzerer Zeit zu erledigen, um so die gewonnene Zeit in höherwertige Tätigkeiten zu investieren (Effizienz), bzw. in derselben Zeiteinheit ein höheres Arbeitspensum zu leisten (Effektivität). Als Beispiele zur Effizienz seien insbesondere die administrative Entlastung des Mittelbaus an den Instituten zugunsten einer mehr inhaltlich gewichteten Arbeit oder beispielsweise die Entlastung
Erstellt gemeinsam mit 15. April 1998 Seite 157 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
der STAB-Mitarbeiter von Prüfroutinen zugunsten der ausgiebigeren Beratung von Studierenden genannt.
Zum anderen ein qualitativer Nutzen, der sich beispielsweise aus der Vereinfachung von Arbeitsabläufen und insbesondere auch aus dem Wegfall monotoner Tätigkeiten ergibt und eine höhere Motivation und einen höheren Einsatz der Mitarbeiter zu Folge hat.
Schematisch lassen sich die Bewertungsmöglichkeiten des zu erzielenden Nutzens eines neuen Systems wie folgt darstellen:
Abbildung 64: Bewertbarkeit des Verbesserungspotentials
Es ist darauf hinzuweisen, daß im vorliegenden Projekt lediglich die Steigerung der Effizienz bewertet werden konnte. Die damit verbundene Steigerung der Effektivität wird in der Literatur in der gleichen Höhe wie die eigentlich erzielten Einsparungen angesetzt.
Seite 158 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
8.1.1 Qualitative VerbesserungenDie mit der Einführung des neuen Systems „2gether“ in Verbindung stehende qualitative Verbesserung läßt sich in erster Linie aus den allgemeinen Zielen des Projektes herleiten. Hierbei seien besonders erwähnt:
Eine integrierte, redundanzfreie DatenbasisDieses Ziel verkörpert die Grundlage aller weiteren Punkte. Unmittelbar bewirkt es eine höhere Fehlersicherheit bei der Bearbeitung.
Ein einheitliches, homogenes DV-SystemHier entfällt das mühsame Umschalten zwischen verschiedenen Anwendungen, was nicht zuletzt eine größere Vertrautheit mit den Funktionalitäten des Systems bewirken wird.
Optimale AuswertungsmöglichkeitenDurch die wegfallenden Medienbrüche und Insellösungen ist es möglich, WU-weite Auswertungen zu fahren, was insbesondere für das angestrebte Universitätscontrolling (Stichwort „Evaluierung“) von großer Bedeutung ist.
Keine MehrfachdatenerfassungEin Grundsatz des neuen Systems ist es, Daten dort zu erfassen, wo sie anfallen. Dies beschleunigt die Dateneingabe und bewirkt zudem eine bessere Qualität der Daten. (Das „Stille-Post-Prinzip“ fällt weg.)
Ein erhöhter InformationsflußFür die Institute, aber auch insbesondere für die Studenten, stehen Informationen erheblich zeitnaher zur Verfügung. Als Beispiel seien hier nur die Notenauskunft für Prüfungsnoten oder die zeitnahe Einsicht in aktuelle Planungsstände des Vorlesungsverzeichnisses genannt.
Diese qualitativen Verbesserungen können somit auch zu kürzeren Studienzeiten führen. Im genannten Beispiel der Prüfungsnoten können beispielsweise die nur befristet gültigen Interimszeugnisse wegfallen und somit unter Umständen Anmeldefristen überhaupt erst eingehalten werden.
Die im Zusammenhang der Prozeßbeschreibung angeführte Argumenten- oder Nutzenbilanz stellt desweiteren eine detaillierte Auflistung auch qualitativ zu verstehender Verbesserungen dar. An dieser Stelle soll jedoch nicht weiter explizit hierauf eingegangen werden (vgl. Abschnitt Organisatorische Gestaltung der Studien- und Prüfungsverwaltung).
Erstellt gemeinsam mit 15. April 1998 Seite 159 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
8.1.2 Quantitativ meßbare VerbesserungenDie exakte Herleitung des quantitativen Nutzens – der Verringerung des benötigten Arbeitsaufwandes zur Durchführung geringer bewerteter Tätigkeiten ausgedrückt in Personenarbeitsleistungen (PAL)7 – ist nicht unproblematisch. Dies gilt insbesondere vor dem Hintergrund des Projektes, eine Ausschreibungsgrundlage zu erstellen. Dadurch muß eine Abschätzung in diesem Rahmen zwangsläufig von einer optimalen Umsetzung der in diesem Fachkonzept beschriebenen Anforderungen, bei denen es sich ja auch um Maximalanforderungen handelt, an das System ausgehen.
Um eine fundiertere Basis für unsere Abschätzungen zu erhalten, wurden die Organisationseinheiten des Untersuchungsbereichs gebeten, Erhebungsbögen zum Mengen- und Wertegerüst auszufüllen, die auch eine (subjektive) Einschätzung der zu erwartenden Verbesserungen in Form von Zeitersparnis beinhaltet haben. Der Rücklauf dieser Bögen betrug beispielsweise aus den Instituten 50%, wobei zudem der Aussagegehalt sehr heterogen war. Diese Umstände führen dazu, daß sich aus den Ergebnissen der Befragung keine einwandfrei gesicherten Aussagen herleiten lassen.
Nichtsdestotrotz dienen die Ergebnisse in jedem Fall dazu, fundierte Trendaussagen tätigen zu können. Diese münden letztlich auch in einer Anzahl von Personenarbeitsleistungen, die umgeschichtet und in Zukunft effizienter und höherwertiger eingesetzt werden kann.
Die Untersuchung wurde im wesentlichen in zwei getrennten Bereichen mit eigenen, zugeschnittenen Erhebungsbögen durchgeführt. Dies sind zum einen die Verwaltungsbereiche, bestehend aus der Studien- und Prüfungsabteilung (STAB), der Quästur und der Rechts- und Organisationsabteilung (RO) sowie des Zentrums für Auslandsstudien (ZAS) und des Studiendekanats. Hierbei ergibt sich ein Nutzenpotential in der Größenordnung von Personenarbeitsleistungen nur in der STAB, so daß die Quästur, die RO, das ZAS und das Studiendekanat im folgenden nicht ein-gehender betrachtet werden. Dies bedeutet nicht, daß nicht auch in diesen Bereichen punktuelle, qualitative Verbesserungen zu erwarten sind (vgl. Argumentenbilanz, Abschnitt Organisatorische Gestaltung der Studien- und Prüfungsverwaltung).
7 Als Personenarbeitsleistung soll hier die Gesamtheit an Leistungen bezeichnet werden, die von einer fulltime beschäftigten Person erbracht wird (= Arbeitsleistung einer Person). Diese Bezeichnung wurde deshalb gewählt, weil der erzielbare Nutzen in einer Verringerung der benötigten Arbeitsleistung liegt, nicht jedoch in der Verringerung der Mitarbeiteranzahl.
Seite 160 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Zum anderen wurden die zehn Institute und Abteilungen des (erweiterten) Untersuchungsbereichs um das spezifische Mengen- und Wertegerüst einschließlich einer Stellungnahme gebeten.
8.1.2.1 Studien- und PrüfungsabteilungZusammenfassend ergibt sich für die Studien- und Prüfungsabteilung ein Potential von
11 - 15 PAL8.
Dabei geht der maximale Wert vom Idealfall der optimalen Umsetzung der Anforderungen aus und beinhaltet zudem 1 PAL aus der BW-Servicestelle.
Die folgende Abbildung 65 gibt einen Eindruck, wie sich das Nutzenpotential qualitativ auf die einzelnen Prozeßbereiche verteilen.
Abbildung 65: Qualitative Verteilung des Nutzenpotentials in der STAB
Die Nummern auf der horizontalen Achse stehen stellvertretend für die ermittelten Prozesse. Eine Zuordnung wird in Tabelle 12 vorgenommen.
8 Personenarbeitsleistung = Arbeitsleistung einer Person.
Erstellt gemeinsam mit 15. April 1998 Seite 161 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Lfd. Nr. Prozeßbereich1. Erstellung/ Wartung Studienplan2. Planung Studienjahreinteilung3. Zulassung4. Rückmeldung Studium5. Wechsel Studium/ Aufnahme Zusatzstudium6. Beendigung Studium7. Verleihung akadem. Grad/akadem. Feier8. Planung Prüfungstermin9. Leistungsfeststellung10. Notenabfrage11. Diplomarbeiten12. Dissertationen13. LV-Anmeldungen14. Prüfungsanmeldungen15. Abmeldungen16. Vormerkungen / Warteliste17. Anmeldeauskunft18. Anerkennungen19. Nostrifizierung
Tabelle 12: Numerierung der Prozeßbereiche (Verwaltung)
Die Grafik bestätigt die Bereiche, in denen sich das größte Potential erwarten läßt. Dies sind die Bereiche
Zulassung und Rückmeldung von Studierenden, Leistungsfeststellungen, Anerkennungen (insbesondere WU-intern), Abschlußarbeiten sowie insbesondere Prüfungsanmeldungen.
Seite 162 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Diese Bereiche verfügen über das höchste Automatisierungspotential.
8.1.2.2 Institute/AbteilungenAnalog erfolgt die Bewertung des Nutzenpotentials bei den Instituten. Hier ist jedoch eine „Hochrechnung“ der Daten aus der Befragung auf die gesamte WU erforderlich.
Diese Hochrechnung geschieht nach folgendem Prinzip:
Normierung der einzelnen Werte mit Bezug auf eine spezifische Basisgröße.
Bildung des arithmetischen Mittels der normierten Werte.
Hochrechnung dieser Mittelwerte anhand der entsprechenden WU-weiten Kennzahlen auf die gesamte WU.
Beim ersten Schritt wurden dabei folgende Basisgrößen verwendet:
Bezugsgröße Prozeßbereich
#9 Lehrveranstaltungen Planung Lehrveranstaltung (inkl. VVZ)# Lehrveranstaltungen Aufnahme Lehrveranstaltung
# LV-Anmeldungen Administration Lehrveranstaltung
# Prüfungsanmeldun-gen10
Planung Prüfungstermin
# Prüfungsanmeldun-gen
Leistungsfeststellung
# Prüfungsanmeldun-gen
Notenabfrage
# Abschlußarbeiten Themenvereinbarung# Abschlußarbeiten Laufende Betreuung
9 „#“ := Anzahl10 Logisch korrekter wäre hier die Anzahl der Prüfungen. Diese ist zum einen sehr schwer definierbar und auch nicht bekannt gewesen. Da nicht unrealistisch ist, daß die Anzahl der Prüfungsanmeldungen in etwa mit der Anzahl der Prüfungen korreliert, wurde auf diese zurückgegriffen.
Erstellt gemeinsam mit 15. April 1998 Seite 163 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Bezugsgröße Prozeßbereich# Abschlußarbeiten Einreichung, Beurteilung & Veröffentlichung
# LV-Anmeldungen LV-Anmeldungen# Prüfungsanmeldun-gen
Prüfungsanmeldungen
# LV-Anmeldungen Abmeldungen# LV-Anmeldungen Vormerkungen / Warteliste
# LV-Anmeldungen Anmeldeauskunft# Lehrveranstaltungen (Anträge zur) Hörsaaladministration
# Lehrveranstaltungen Beurteilung Lehrveranstaltung
1 Arbeitsbericht Institutsvorstände
Tabelle 13: Bezugsgrößen der Prozeßbereiche
Somit ergibt sich die folgende Formel zur Berechnung des Nutzeffekts:
PT
xbn
bj
ij
iji
n
j: 1
Dabei ist
PTj := (WU-weiter) Nutzen des Prozeßbereichs j in Personentagen
n := Anzahl der befragten Institute/Abteilungen
bij := Wert der Bezugsgröße des Prozeßbereichs j für das Institut i
xij := Nutzenpotential des Instituts i im Prozeßbereich j
bj := WU-weiter Wert der Bezugsgröße des Prozeßbereichs j
Als Ergebnis läßt sich feststellen, daß sich eine WU-weite Effizienzsteigerung im Gegenwert von
Seite 164 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
ca. 20 - 23 PAL11
erwarten läßt, allerdings ohne daß einzelne Stellen als solche unmittelbar freigesetzt werden können.
Betonenswert an diesem Ergebnis ist wohl in erste Linie die Tatsache, daß auch von den Instituten selber unter dem Strich keine Mehrbelastung erwartet wird. Die in den Instituten durchgeführten reinen Verwaltungstätigkeiten im Umfeld der Studien- und Prüfungsverwaltung können somit merklich reduziert und als zusätzliche Potentiale zur Unterstützung der Kernaktivitäten in Forschung und Lehre genutzt werden.
In der folgenden Abbildung 66 wird – analog zur Studien- und Prüfungsabteilung – die qualitative Verteilung des Nutzens aufgezeigt.
11 Personenarbeitsleistung = Arbeitsleistung einer Person.
Erstellt gemeinsam mit 15. April 1998 Seite 165 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
Abbildung 66: Qualitative Verteilung des Nutzenpotentials in den Instituten
Hierbei ist anzumerken, daß – nach unserer Auffassung – tatsächlich ein größeres Nutzenpotential realistisch ist. Dies ist insbesondere damit begründet, daß teilweise von einzelnen Instituten keine Aussage hinsichtlich des Potentials getroffen wurde, obwohl eine Erleichterung der administrativen Arbeit offensichtlich ist – es handelt sich also um eine eher konservative Einschätzung.
Die Legende zur Numerierung der Prozeßbereiche können der folgenden Tabelle 14 entnommen werden.
Lfd. Nr. Prozeß1. Planung Lehrveranstaltung (inkl. VVZ)2. Aufnahme Lehrveranstaltung3. Administration Lehrveranstaltung4. Planung Prüfungstermin5. Leistungsfeststellung6. Notenabfrage7. Abschlußarbeiten (Dipl.+Diss.), Summe8. Themenvereinbarung (Dipl.+Diss.)9. Laufende Betreuung (Dipl.+Diss.)10. Einreichung, Beurteilung & Veröffentlichung (Dipl.+Diss.)11. LV-Anmeldungen12. Prüfungsanmeldungen13. Abmeldungen14. Vormerkungen / Warteliste15. Anmeldeauskunft16. (Anträge zur)Hörsaaladministration17. Beurteilung Lehrveranstaltung18. Arbeitsbericht Institutsvorstände
Tabelle 14: Numerierung der Prozeßbereiche (Institute)
Seite 166 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Zum Bereich der „LV-Anmeldungen“ ist noch zu vermerken, daß bereits heute die Anmeldung mittels System erfolgen kann – aber offensichtlich nicht umfassend eingesetzt wird. Dieses Beispiel macht ein generelles Problem an der WU Wien deutlich: Die weit verbreitete Freistellung der Nutzung von DV-Unterstützung sowohl durch WU-Mitarbeiter selbst als auch durch die Studierenden bewirkt, daß in vielen Bereichen Parallelabläufe existieren, die direkt zu Mehraufwendungen führen. Soll das avisierte Nutzenpotential auch wirklich umgesetzt werden, ist ein Umdenken – ggf. erreichbar nur durch striktere organisatorische Vorgaben bzw. bessere und intensivere Schulungen – erforderlich: In Zukunft müssen sich beispielsweise die Studierenden über das System anmelden, andernfalls können sie nicht an der Lehrveranstaltung teilnehmen.
Erstellt gemeinsam mit 15. April 1998 Seite 167 von 171
6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung
8.2 Kosten-/NutzenrechnungDa die Anwendung des Hedonistischen Modells auf die Quantifizierung der Einsparungen nicht möglich war12, wurde teils auf die Ergebnisse der Fragebogenaktion, teils auf eigene Schätzungen der zu erwartenden Verringerung des Verwaltungsaufwandes zurückgegriffen (zur Qualität der getroffenen Annahmen siehe Kapitel 8.1.2 ). Wie anläßlich der 3. Sitzung des Lenkungsausschusses vorgegeben, wurde davon ausgegangen, daß die eingesparten Zeiten nicht für Tätigkeiten verwendet werden, deren Wert geringer als die eingesparten Tätigkeiten einzustufen ist. Die Steigerung der Effektivität, die üblicherweise gleich hoch wie der Effizienzgewinn eingestuft wird (siehe dazu auch Seite 158, Abbildung 64), bleibt jedoch aus kaufmännischer Vorsicht bei der Quantifizierung des Verbesserungspotentials unberücksichtigt.
Als Basis für die Aufwandsschätzungen wurde auf die bereits vom ZID erhobenen Werte zurückgegriffen. Die vom ZID erstellte Kostenschätzung, deren Ansätze uns als durchaus plausibel erscheinen, ist in Anhang F beige-fügt. Es wurden folgende Adaptierungen vorgenommen (siehe Tabelle 15 auf Seite 169):
Es wurden die vom ZID angesetzten Eigenleistungen kostenmäßig bewertet und in die Kalkulation aufgenommen.
Die Kosten für einen internen Mitarbeiter der erforderlichen Qualifikation wurden mit 600.000 öS p.a. inklusive Dienstgeberanteil angenommen (Basis: ZID Gehaltskostenanteil 1997).
Die bislang unberücksichtigt gebliebenen notwendigen laufenden Adaptierungsarbeiten am Neusystem 2gether wurden aufwandsmäßig in die Kalkulation aufgenommen (1 Mitarbeiter fulltime).
Die Entwicklungszeit für die Realisierung des „2gether“-Projektes wurde mit drei Jahren angenommen (siehe dazu das in Kapitel 7 ausgeführte Migrationskonzept).
Der Durchrechnungszeitraum wurde auf 10 Jahre reduziert.
12 Da seitens des Lenkungsausschusses (3. Sitzung am 5. März 1998) massiver Widerstand bei der Erhebung der benötigten Daten erwartet wurde, wurde beschlossen, das Ausmaß der zu erzielenden Einsparungen beim Verwaltungsaufwand mittels Fragebogen bei den bereits im Projekt involvierten Organisationseinheiten zu erheben.
Seite 168 von 171 Erstellt gemeinsam mit 15. April 1998
Gegenüberstellung der Kosten STEP vs. 2gether (alle Werte in Mio. öS inkl. USt.)
Erhaltung des derzeitigen Systems STEP 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 TotalHardware, Systemsoftware (inkl. Wartung) 10,8 0,9 0,9 0,9 11,5 0,9 0,9 0,9 13,2 1,0 41,9Anwendungs-SW (notwendige Adaptierungen) 2,6 4,4 4,5 1,9 2,0 2,0 2,1 2,1 2,2 2,2 26,0 Kosten STEP pro Jahr 13,4 5,3 5,4 2,8 13,5 2,9 3,0 3,0 15,4 3,2 67,9 Kosten STEP kumuliert 13,4 18,7 24,1 26,9 40,4 43,3 46,3 49,3 64,7 67,9
Neuentwicklung 2gether 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008Hardware, System-SW (inkl. Wartung) 10,4 0,4 0,4 0,4 10,5 0,4 0,4 0,4 10,9 0,4 34,6Anwendungs-SW (Entwicklung) 19,2 19,2 19,2 0,0 0,0 0,0 0,0 0,0 0,0 0,0 57,6Eigenleistung (Entw. + lfd. Adaptierung) 1,2 1,2 1,2 0,6 0,6 0,7 0,7 0,7 0,7 0,7 8,3Schulung pro (Jahr) 1,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 3,0 Kosten 2gether pro Jahr 32,0 21,0 21,0 1,2 11,3 1,3 1,3 1,3 11,8 1,3 103,5Kosten 2gether kumuliert 32,0 53,0 74,0 75,2 86,5 87,8 89,1 90,4 102,2 103,5
Quantifizierbare Einsparungen durch 2gether 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008Werkverträge (Erfassungsarbeiten STAB) 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 2,0Material (Formulare) 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 2,0Porto 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 5,0Reduktion Verwaltungsstellen -9,0 -13,0 -34,0 -34,0 -34,0 -34,0 -34,0 -34,0Reduktion Personalkosten 3,8 5,6 15,0 15,4 15,8 16,2 16,6 17,0 105,4 Einsparungen 2gether pro Jahr 0,9 0,9 4,7 6,5 15,9 16,3 16,7 17,1 17,5 17,9 114,4Einsparungen 2gether kumuliert 0,9 1,8 6,5 13,0 28,9 45,2 61,9 79,0 96,5 114,4
Berichtigte Kosten 2gether 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008Aufwand abzügl. Einsparungen (–) 31,1 20,1 16,3 -5,3 -4,6 -15,0 -15,4 -15,8 -5,7 -16,6 -10,9 Berichtigte Kosten kumuliert 31,1 51,2 67,5 62,2 57,6 42,6 27,2 11,4 5,7 -10,9
Aufwendungen Altsystem im Vergleich zu 2gether (100) 43% 37% 36% 43% 70% 102% 170% 432% 1135% –
Tabelle 15: Gegenüberstellung der geschätzten Kosten
8 WIRTSCHAFTLICHKEITSBETRACHTUNG8.2 Kosten-/Nutzenrechnung
Aus der vorstehenden Kostenübersicht kann folgendes abgeleitet werden:
Die vergleichbaren Gesamtkosten sind nach 6 Jahren ausgeglichen (Break Even im Jahre 2004).
Am Ende des Durchrechnungszeitraumes betragen die von 2gether erwirkten Gesamteinsparungen 78,8 Mio. öS.
In den Zahlen sind weder der qualitative Nutzen noch die zu erwartende Steigerung der Effektivität berücksichtigt.
Die Vornahme einer dynamischen Investitionsrechnung, wobei wir uns der in der betrieblichen Praxis häufig verwendeten Internen-Zinsfuß-Methode bedienten, ergibt einen internen Zinsfuß von 12%.
Seite 170 von 171 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Anhang A: Verzeichnisse
Grobkonzept Projekt
ABBILDUNGSVERZEICHNIS
Abbildung 1: Ist-Situation und Ziele des Projektes „2gether“Abbildung 2: Aspekte der Studien- und Prüfungsverwaltung in „2gether“Abbildung 3: Partner im Projekt „2gether“Abbildung 4: ProjektaufbauorganisationAbbildung 5: Phasen des Projektes ‘2gether’Abbildung 6: Die Instanzen eines UniversitätsprozessesAbbildung 7: Werkzeuggestütztes Vorgehen im Projekt ‘2gether’Abbildung 8: Das ARIS-Haus im GesamtüberblickAbbildung 9: Ebenenkonzept des ARISAbbildung 10: Beispiel eines Organigramms (Ausschnitt)Abbildung 11: Beispiel eines FunktionsbaumsAbbildung 12: Beispiel Entity-Relationship-ModellAbbildung 13: Beispiel einer Ereignisgesteuerten Prozeßkette (Ausschnitt)Abbildung 14: Legende der verwendeten ObjekttypenAbbildung 15: Bestandteile der MethodikAbbildung 16: WU Wien Aufbauorganisation nach UOG 93, ÜberblickAbbildung 17: Funktionsbaum „Studien- und Prüfungsverwaltung“Abbildung 18: PAM „Studium“Abbildung 19: Funktionszuordnungsdiagramm „Zulassung Studium“Abbildung 20: Funktionszuordnungsdiagramm „Rückmeldung Studium“Abbildung 21: Funktionszuordnungsdiagramm „Wechsel Studium/Aufnahme
Zusatzstudium“Abbildung 22: Funktionszuordnungsdiagramm „Beendigung Studium“Abbildung 23: Funktionszuordnungsdiagramm „Erstellung Diplomzeugnis“Abbildung 24: Funktionsbaum „Lehrveranstaltung“Abbildung 25: Funktionszuordnungsdiagramm „Planung Lehrveranstaltung“Abbildung 26: Funktionszuordnungsdiagramm „Aufnahme Lehrveranstaltung“
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 1
Anhang AVerzeichnisse
Abbildung 27: Funktionszuordnungsdiagramm „Administration Lehrveranstal-tung“
Abbildung 28: Funktionsbaum „Prüfung“Abbildung 29: Funktionszuordnungsdiagramm „Planung Prüfungstermin“Abbildung 30: Funktionszuordnungsdiagramm „Leistungsfeststellung“Abbildung 31: Funktionsbaum „Diplomarbeit/Dissertation“Abbildung 32: Funktionszuordnungsdiagramm „Themenvereinbarung“Abbildung 33: Funktionszuordnungsdiagramm „Laufende Betreuung“Abbildung 34: Funktionszuordnungsdiagramm „Einreichung, Beurteilung und
Veröffentlichung“Abbildung 35: PAM „An- und Abmeldung“Abbildung 36: Funktionszuordnungsdiagramm „Lehrveranstaltungsanmeldung
durchführen“Abbildung 37: Funktionszuordnungsdiagramm „Prüfungsanmeldung durch-
führen“Abbildung 38: Funktionszuordnungsdiagramm „Abmeldung durchführen“Abbildung 39: Funktionsbaum „Anerkennung“Abbildung 40: Funktionszuordnungsdiagramm „Erzielen von Anerkennungen“Abbildung 41: Funktionszuordnungsdiagramm „Erzielen von Nostrifikationen“Abbildung 42: Funktionszuordnungsdiagramm „Abrechnung“Abbildung 43: PAM „Evaluierung der Lehre“Abbildung 44: Funktionszuordnungsdiagramm „Beurteilung Lehrveranstaltung“Abbildung 45: Funktionszuordnungsdiagramm „Arbeitsbericht Insti-
tutsvorstände“Abbildung 46: Funktionsbaum „allgemeine Funktionen“Abbildung 47: Funktionszuordnungsdiagramm „Hörsaaladministration“Abbildung 48: Funktionsbaum „allgemeine Systemfunktionen“Abbildung 49: Clustersammlung zur Studien- und PrüfungsverwaltungAbbildung 50: Semantisches Datenmodell ‘Studium’Abbildung 51: Semantisches Datenmodell ‘Studienplan’Abbildung 52: Semantisches Datenmodell ‘Lehrveranstaltung’Abbildung 53: Semantisches Datenmodell ‘Vorlesungsverzeichnis’
Seite 2 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Abbildung 54: Semantisches Datenmodell ‘Prüfungen’Abbildung 55: Semantisches Datenmodell ‘An- und Abmeldung’Abbildung 56: Semantisches Datenmodell ‘Abschlußarbeiten’Abbildung 57: Semantisches Datenmodell ‘Anerkennung’Abbildung 58: Semantisches Datenmodell ‘Abrechnung’Abbildung 59: Semantisches Datenmodell ‘Hörsaalverwaltung’Abbildung 60: Semantisches Datenmodell ‘Evaluierung’Abbildung 61: Semantisches Datenmodell ‘Adresse’Abbildung 62: Struktur der Datenbank STEPDBAbbildung 63: Struktur der Datenbank INSTDBAbbildung 64: Bewertbarkeit des VerbesserungspotentialsAbbildung 65: Qualitative Verteilung des Nutzenpotentials in der STABAbbildung 66: Qualitative Verteilung des Nutzenpotentials in den Instituten
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 1
Anhang AVerzeichnisse
TABELLENVERZEICHNIS
Tabelle 1: Interviews und AbstimmungsgesprächeTabelle 2: Workshops – Termine und TeilnehmerTabelle 3: ModelltypverwendungTabelle 4: Modell-/ObjekttypzuordnungTabelle 5: Objekt-/AttributtypzuordnungTabelle 6: Legende zu den AnmerkungenTabelle 7: Mengengerüst der Studien- und Prüfungsverwaltung i.w.S.Tabelle 8: Zuordnung des SchutzbedarfesTabelle 9: Empfohlene BasistermineTabelle 10: Definition möglicher UmstellungsstufenTabelle 11: Zuordnung der neuen ObjekteTabelle 12: Numerierung der Prozeßbereiche (Verwaltung)Tabelle 13: Bezugsgrößen der ProzeßbereicheTabelle 14: Numerierung der Prozeßbereiche (Institute)Tabelle 15: Gegenüberstellung der geschätzten Kosten
Seite 4 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
VERZEICHNIS DER ABKÜRZUNGEN
ARIS Architektur Integrierter InformationsSystemeBeSt Betriebswirtschaftliche SteuerlehreBüRe Bürgerliches RechtCDLS Chipkartenbasiertes DienstleistungssystemEEPK Erweiterte Ereignisgesteuerte ProzeßketteEnSp Englische SprachenFI FinanzierungInstDB Datenbank auf UDS-Basis, Teil des AltsystemsISO/IEC International festgelegter StandardIT InformationstechnologieLV LehrveranstaltungPAL Personenarbeitsleistung (Arbeitsleistung einer Person)PAM ProzeßauswahlmatrixPeWi PersonalwirtschaftPIN Personal Identification NumberPoÖk Politische ÖkonomiePOS Point of SalePUK Personal Unblocking KeyRO Rechts- und OrganisationisabteilungRoSp Romanische SprachenSTAB Studien- und PrüfungsabteilungStepDB Datenbank auf UDS-Basis, Teil des AltsystemsUDS Codasyl-basiertes Datenbanksystem der Firma SNIWA WarenhandelWI WirtschaftsinformatikWiSoGe Wirtschafts- und Sozialgeschichte
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 1
Anhang AVerzeichnisse
WS 1 Workshop 1WS 2 Workshop 2WS 3 Workshop 3WS 4 Workshop 4ZAS Zentrum für AuslandsstudienZID Zentrum für Informatikdienste
Seite 6 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
VERZEICHNIS DER DOKUMENTE
[BeRoSchü95]
Becker, J., Rosemann, M., Schütte, R.: Grundsätze ordnungsmäßiger Modellierung, Wirtschaftsinformatik, 37 (1995) 5
[FeSi94] Ferstl, O.K., Sinz, E.J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen, Bamberger Beiträge zur Wirtschaftsinformatik, Nr. 21, 1994
[Fla90] Flatscher, R.G.: Entwicklung eines PC-basierten Lehrveranstal-tungsadministrationssystems für die Abteilungen an der Wirt-schaftsuniversität Wien, Service Fachverlag, Wien, 1990
[Kru97] Krumbiegel, J.: Integrale Gestaltung von Geschäftsprozessen und Anwendungssystemen in Dienstleistungsbetrieben, Deutscher Universitätsverlag, Wiesbaden, 1997
[KruOeSiVa95]
Krumbiegel, J., Oechsler, W.A., Sinz, E.J., Vaanholt, S.: Business Process Reengineering an der Universität, Personal, Heft 10/1995
[Mi86] Miksch, G.: Strategische Informationssystemplanung - dargestellt am Beispiel der zentralen Verwaltung der Wirtschaftsuniversität Wien, Service Fachverlag, 1986
[PiSchwa97] Piller, E., Schwarzinger, M.: WU-PowerCard - Einsatzmöglichkeiten von Chipkarten an der WU, Wien, 1997
[Pö88] Pönighaus, R.: Der Nutzen von Informations- und Kommunikationssystemen an Forschungs- u. Lehrarbeitsplätzen - Theoretische Analyse und empirische Ergebnisse, Hansen/Janko (Hrsg.), WU Wien, 1988
[ProSo93] Prosser, A., Sommer, B.: EDV-unterstützte Lehrveranstaltungsadministration an der Wirtschaftsuniversität Wien, Handbuch für In-formationsanbieter im WU-BTX-System, 2. Aufl., WU Wien, 1993
[Scheer95] Scheer, A.-W.: Wirtschaftsinformatik - Referenzmodelle für
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 1
Anhang AVerzeichnisse
industrielle Geschäftsprozesse, 6. Aufl., Berlin et al. 1995
[Scheer98] Scheer, A.-W.: ARIS - Vom Geschäftsprozeß zum Anwendungssystem, 3. Aufl., Berlin et al. 1998
[Schmi97] Schmidt, S.: WU Informationssystem 2000 - Neue Ansätze der Studentenverwaltung, Diplomarbeit, WU Wien, 1997
[Si95] Sinz, E.J.: Serviceorientierung der Hochschulverwaltung und ihre Unterstützung durch workflow-orientierte Anwendungssysteme, Bamberger Beiträge zur Wirtschaftsinformatik, Nr. 35, 1995
[Si96] Sinz, E. et al.: WU IS 2000 – Geschäftsprozeß- & Anwendungssystemarchitektur der WU Wien, Bamberg, 1996
[Si97] Sinz, E.J.: Analsyse und Gestaltung universitärer Geschäftsprozesse und Anwendungssysteme, Bamberger Beiträge zur Wirtschaftsinformatik, Nr. 41, 1997
[WI94] Organisationshandbuch der Abteilung für Wirtschaftsinformatik an der WU Wien, 1994
[WUWi97] WU Wien: Bericht der Studiendekane, Wien, 1997
[ZID97] WU Wien, Zentrum für Informatikdienste: Grobkonzept 2gether, Anlage zum Offenen Verfahren, WU Wien, 1997
Seite 8 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Anhang B: Datenfelder
Grobkonzept Projekt
Anhang B enthält eine Auflistung markanter Datenfelder, alphabetisch geordnet nach dem jeweils übergeordneten Datenobjekt (Entitytyp oder Beziehungstyp).
ObjektnameFeldname Bemerkung
AbgeltungsartBezeichnung z.B. Kollegiengeld, TutorengeldRegelwerk
AbschlußarbeitTitel Ggf. auch englischTyp der Arbeit Diplomarbeit, Dissertation etc.AbgabedatumSeitenzahlTextspracheKurzfassung AbstractSchlagwörter ggf. auch englischVorkenntnisse Erforderliche VorkenntnisseMethoden benötigte MethodenFristen z.B. für Themeabgrenzung, Vorlage einer
GrobfassungBemerkungen z.B. Ablaufplanung, BenotungLiteraturlisteWeb-Link-ListeFörderungs-möglichkeiten<sonstige Felder> s. 'Grobkonzept 2gether', S. 77ff
AbschlußarbeitbegutachtungBeurteilung
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 1
Anhang BDatenfelder
ObjektnameFeldname BemerkungBegründung
AA-Fach-ZUOFachrolle Erstfach, Nebenfach
AdressePLZ PostleitzahlOrtLandStrasseTelefonE-Mail
AnerkennungsbescheidAktenzeichenAblehnung? Kennzeichen, ob der Bescheid ablehnend
istDatum der BescheidungAusfolgedatumDatum der Anrechnung
AnerkennungsgegenstandArt der AnerkennungNummer lfd. Nummer der AnerkennungSemesteranzahl Anzahl der angerechneten Semester
Note Note, falls nicht aus dem Ergebnis angerechnet wird
Bemerkung
Seite 2 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
ObjektnameFeldname BemerkungBehörde Bezeichnung der ausstellenden Behörde,
z.B.der ausl. Universität
StaatStadtAusstellungsdatum Ausstellungsdatum der Urkunde
AnmeldungDatumTyp z.B. LV, PrüfungStatus z.B. aktuell, zurückgenommenNummer lfd. Nummer der Anmeldung
Arbeitsbericht# wiss. Institutspersonal Anzahl wiss. Institutspersonal
# abgehaltene Lehrveranstaltungen
Anzahl abgehaltene Lehrveranstaltungen
# durchgeführte Beurteilungen
Anzahl durchgeführte Beurteilungen
Belastungsanalysen s. 'Grobkonzept 2gether', S. 95 f
ErhebungsbogenZielerfüllungDidaktikLernbehelfeBetreuung
LehrauftragsrahmenLehrauftragstyp Funktion der beteiligten Org.-Einheit
Versteuerungsart
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 1
Anhang BDatenfelder
ObjektnameFeldname Bemerkung
LehrveranstaltungBezeichnungLV-Typ<Felder aus der LV-Ankündigung>
Daten, die schließlich für die LV gelten und relevant sind
LehrveranstaltungsanmeldungPlazierung in der Anmeldungsreihenfolge
LehrveranstaltungsbeurteilungTeilnahmefrequenzBeurteilungÖffentlichkeitsgradGlobalurteile (Zufriedenheit, Empfehlung)DurchfallquotenAllgemeine FragenIndividuelle Fragen
LehrveranstaltungsrahmenKontingent, remuneriert SchlüsselattributKontingent, nicht remuneriertRahmenwerte
LehrveranstaltungsteilnahmeErgebnisse auch Zwischenergebnisse
Seite 4 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
ObjektnameFeldname Bemerkung
LehrveranstaltungsterminTeilnehmerzahl
LV-AnkündigungLV-BeginnLV-EndeNummer lfd. Nummer im Abhaltungsplan
BezeichnungTyp z.B. Vorlesung, Seminar, Lehrgang
WochenstundenLV-Termine Wochentage, UhrzeitenLetztes Semester Semester, in dem die LV zuletzt
abgehalten wurdeStatus Status der Ankündigung, z.B. vorläufig,
entgültigModus AbhaltungsmodusAnmeldeartECTS-Anerkennungspunkte
European Credit Transfer System-Credits
ReihenfolgeverfahrenLehrinhalteLehrzieleUnterrichtsspracheAnforderungenVerwendete Literatur# Teilnehmer max. Anzahl der Teilnehmer<sonstige Abhaltungsinformationen>
s. 'Grobkonzept 2gether', S. 58
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 1
Anhang BDatenfelder
ObjektnameFeldname Bemerkung
LV-Beteiligung v. Org.-EinheitFunktion Funktion der beteiligten Org.-Einheit
RemunerationstypArt der Beteiligung
LV-Beteiligung MitarbeiterRechtliche Grundlage z.B. Venia, Gastprofessur etc.AbrechnungsdatenArt der Beteiligung z.B. Leitung etc.
LeistungLeistungsart s. 'Grobkonzept 2gether', S. 91
Mitarbeiter/-inVornameZunameAkad. GradAnredeTelefonklappeFamilienstandGeburtsdatumGeburtsortGeschlechtSozialversicherungsnummerArt der PersonFunktionStaatsbürgerschaft
Seite 6 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
ObjektnameFeldname BemerkungDienstverhältnis
NostrifizierungGrad Bezeichnung des verl. Grades
OrganisationseinheitBezeichnungArt der Org.-Einheit z.B. extern/internTyp der Org.-Einheit z.B. Abteilung, Fachbereich, Institut
Hochschulcode lt. MinisteriumsentwurfFachgruppeÖffnungszeiten
PrüfungBezeichnungPrüfungsartBeschreibungPrüfungscode lt. Ministerium
Prüfungen des wiss. MAAnmeldezeitraumTeilnehmerzahlenZuteilungssystem
Prüfung des StudentenBeurteilung Endnote/ErgebnisStatusEinsichtsfristZwischenergebnis 1-n
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 1
Anhang BDatenfelder
ObjektnameFeldname BemerkungPunkte
PrüfungsterminPosition
RaumGrößeAusstattung
ReservierungBelegungszeit SchlüsselattributStatus
RückmeldungDatumTypBemerkung
SemesterSemesteranfangSemesterendeJahrBezeichnungTyp Sommer-, Wintersemester1. Unterrichtswoche mind. 14 WochenLetzte UnterrichtswocheLehrveranstaltungsfreie ZeitenImmatrikulationsfrist
Seite 8 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
ObjektnameFeldname BemerkungRückmeldungsfristPrüfungszeiträumeSponsionsterminePromotionstermine
StudiumStudientyp Kennzahl, BezeichnungGesamt-stundenzahl
Studium des StudentenAnfangsdatumEnddatumStatus z.B. "aufgenommenes ordentliches
Studium", "aufgenommenes Studium irregulare"
Erfüllungsstatus Bei Beendigung des Studiums: Sind alle Studienplanpunkte erfüllt?
Abgabestatus Bei Beendigung des Studiums: Sind die erfoderlichen Exemplare der Abschlußarbeit abgeben?
Student/-inNameWU-MatrikelnummerVermerk ZahlweiseGebührenstatusImmatrikulationsstatusSchule absolvierte SchuleSchulform Form der absolvierten SchuleAufnahmedatum
Erstellt gemeinsam mit 15. April 1998 Seite 9 von 1
Anhang BDatenfelder
ObjektnameFeldname BemerkungExmatrikulationsdatumReifeprüfungsdatumStammhochschuleRückgabestatus I Bei Beendigung des Studiums: Sind die
entliehenen Bücher abgeben?
Rückgabestatus II analog: GeräteRückgabestatus III analog: SchlüsselSaldenstatus Salden auf diversen Konten?
StudentenausweisGültigkeitszeitraumStatusKontonummer der WU Zwecks Bezahlung vom Bankomat-
Terminal
StudienplanBezeichnungDatum des InkrafttretensAblaufdatumVersionsnummerTitel Titel, der durch die Absolvierung des
Studienabschnitts verliehen wird
Studienabschnitt des StudiumsAnzahl der Semester Anzahl der Semester, die inskribiert sein
müssenNummer lfd. nummer des AbschnittsNachlaßsemester Anzahl der Semester, die nachgelassen
werden könnenStundenzahl
Seite 10 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
ObjektnameFeldname Bemerkung
Studium der ZulassungLfd. Nr.Status
StudiumsänderungTyp z.B. Wechsel, Aufnahme, Beendigung
StudienplanpunktBezeichnungTypStundenausmaß
Termin des wiss. MAAnmeldekapazität
TerminlisteGültigkeitszeitraumArt der Termine z.B. Prüfungstermin, Vorlagetermine
VergabeStatus Interesse, Bearbeitung
WartelistenpositionPosition
ZuteilungBelegungszeit Schlüsselattribut
Erstellt gemeinsam mit 15. April 1998 Seite 11 von 1
Anhang BDatenfelder
ObjektnameFeldname Bemerkung
Zulassung zum StudiumDatum der ZulassungVorlageterminAnmeldenummerStatus<Ersterfassungsfelder> s. 'Grobkonzept 2gether', S. 42 ffHochschulstatistik Felder des Formulars des Statistischen
ZentralamtsKennwortKennwort (Wdh.)Bemerkung z.B. Begründung für Stornierung
Seite 12 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Anhang C: ARIS-Datenbank/Modell-Liste
Grobkonzept Projekt
Struktur und Modelliste
Die Struktur der ARIS-Datenbank13 läßt sich der ersten Spalte der folgenden Tabelle entnehmen, die insbesondere eine Liste aller relevanten, im Rahmen des Projektes erstellten Modelle enthält.
Gruppe Modell Typ\ROOT Legende EEPK
\ROOT\2gether WU Wien Organigramm
\ROOT\2gether\Soll-Konzept
2gether, Grobkonzept Funktionsbaum
Studien- und Prüfungsverwaltung FunktionsbaumStudien- und Prüfungsverwaltung EERMAnwendungen WU-Wien Soll Anwendungssystemtypdia
gr.
\ROOT\2gether\Soll-Konzept\Lehrveranstaltungen
Lehrveranstaltungen administrieren
Funktionsbaum
Aufnahme von Lehrveranstaltungen
EEPK
Planung von Lehrveranstaltungen EEPKLehrveranstaltung EERMVorlesungsverzeichnis EERMAdministration Lehrveranstaltung Funktionszuordnungsdiagr
.Aufnahme Lehrveranstaltung Funktionszuordnungsdiagr
.Planung Lehrveranstaltung Funktionszuordnungsdiagr
.Lehrveranstaltung Prozeßauswahlmatrix
13 Nicht zu verwechseln mit der Struktur der ARIS-Methodik.
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 1
Anhang CARIS-Datenbank/Modell-Liste
Gruppe Modell Typ\ROOT\2gether\Soll-Konzept\Lehrveranstaltungen\Detailfunktionen
Anwesenheitslisten führen Funktionszuordnungsdiagr.
Datenfelder freigeben zur Ansicht Funktionszuordnungsdiagr.
Endnoten eingeben Funktionszuordnungsdiagr.
Layout der Anmeldeliste festlegen Funktionszuordnungsdiagr.
Lehrveranstaltungen mit eigener Beteiligung auflisten
Funktionszuordnungsdiagr.
Nachmeldungen eingeben Funktionszuordnungsdiagr.
Studierende zu Gruppen zusammenfassen
Funktionszuordnungsdiagr.
Studierendenlisten pro LV ausgeben
Funktionszuordnungsdiagr.
Teilnehmerlisten & Anwesenheitslisten ausdrucken
Funktionszuordnungsdiagr.
Zwischenergebnisse & Mitarbeitsnoten eingeben
Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\Prüfungen
Leistungsfeststellung EEPK
Planung von Prüfungen EEPKPrüfung EERMLeistungsfeststellung Funktionszuordnungsdiagr
.Planung Prüfungstermin Funktionszuordnungsdiagr
.Prüfung Prozeßauswahlmatrix
\ROOT\2gether\Soll- Diplomarbeiten/Dissertationen Funktionsbaum
Seite 2 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Gruppe Modell TypKonzept\Diplomarbeiten & Dissertationen
betreuen
Diplomarbeiten/Dissertationen vereinbaren
Funktionsbaum
Diplomarbeiten/Dissertationen abschließen
EEPK
Diplomarbeit/ Dissertation EERMEinreichung, Beurteilung & Veröffentlichung
Funktionszuordnungsdiagr.
Laufende Betreuung Funktionszuordnungsdiagr.
Themenvereinbarung Funktionszuordnungsdiagr.
Diplomarbeit/ Dissertation Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\Diplomarbeiten & Dissertationen\Detailfunktionen
Abgabetermine festsetzen Funktionszuordnungsdiagr.
Betreuer wechseln Funktionszuordnungsdiagr.
Dokumententransfers durchführen Funktionszuordnungsdiagr.
Erinnerungen bei Fristüberschreitungen verschicken
Funktionszuordnungsdiagr.
Interessenten- Daten eintragen Funktionszuordnungsdiagr.
Mustervorlagen für Arbeit erstellen Funktionszuordnungsdiagr.
Statusveränderungen der Arbeit durchführen
Funktionszuordnungsdiagr.
Stichwortkatalog erstellen Funktionszuordnungsdiagr.
Termine abstimmen Funktionszuordnungsdiagr.
Themen eintragen Funktionszuordnungsdiagr
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 1
Anhang CARIS-Datenbank/Modell-Liste
Gruppe Modell Typ.
Voraussetzungen prüfen Funktionszuordnungsdiagr.
Zweitgutachter festlegen Funktionszuordnungsdiagr.
über Thema, Bearbeiter und Erstbetreuer informieren
Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\An- und Abmeldungen
Abmeldungen Funktionsbaum
LV-Anmeldungen FunktionsbaumPrüfungsanmeldungen FunktionsbaumAn- und Abmeldung EERMAbmeldung durchführen Funktionszuordnungsdiagr
.Lehrveranstaltungsanmeldung durchführen
Funktionszuordnungsdiagr.
Prüfungsanmeldung durchführen Funktionszuordnungsdiagr.
An-und Abmeldung Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\An- und Abmeldungen\Detailfunktionen
Abmeldung überprüfen Funktionszuordnungsdiagr.
Anmelde-Berechtigungen überprüfen
Funktionszuordnungsdiagr.
Informationen weitergeben Funktionszuordnungsdiagr.
Kapazitätsanalysen durchführen Funktionszuordnungsdiagr.
LV/Prüfung auswählen Funktionszuordnungsdiagr.
Lehrveranstaltung auswählen Funktionszuordnungsdiagr
Seite 4 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Gruppe Modell Typ.
Lehrveranstaltungsanmeldung prüfen
Funktionszuordnungsdiagr.
Prüfung auswählen Funktionszuordnungsdiagr.
Prüfungsanmeldung überprüfen Funktionszuordnungsdiagr.
Sicherheitsvorkehrungen durchführen
Funktionszuordnungsdiagr.
Zuteilungsalgorithmen entwerfen Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\Anerkennungen
Anerkennungen erzielen EEPK
Nostrifikationen erzielen EEPKAnerkennung EERMErzielen von Anerkennungen Funktionszuordnungsdiagr
.Erzielen von Nostrifikationen Funktionszuordnungsdiagr
.Anerkennung Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\Abrechnungen
Abrechnungen mit PAV und PTKG EEPK
Abrechnungen mit PAV und ohne PTKG
EEPK
Abrechnungen ohne PAV und PTKG EEPKAbrechnung EERMAbrechnung Funktionszuordnungsdiagr
.
\ROOT\2gether\Soll-Konzept\Evaluierungen
Arbeitsberichte erstellen Funktionsbaum
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 1
Anhang CARIS-Datenbank/Modell-Liste
Gruppe Modell TypBeurteilung von Lehrveranstaltungen
EEPK
Evaluierung EERMArbeitsbericht Institutsvorstände Funktionszuordnungsdiagr
.Beurteilung Lehrveranstaltung Funktionszuordnungsdiagr
.Evaluierung der Lehre Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\Studien
Beendigung des Sonderstudiums EEPK
Beendigung des Studiums EEPKErstellung Diplomzeugnis EEPKRückmeldung Studierende mit Zahlschein
EEPK
Rückmeldung Studierende ohne Zahlschein
EEPK
Zulassung Studierende mit Nostrifikationsauflagen
EEPK
Zulassung Studierende mit Studienberechtigungsprüfung
EEPK
Zulassung Studierende mit allg. Voraussetzungen
EEPK
Zulassung Studierende mit bes. Voraussetzungen
EEPK
Zulassung Studierende mit indiv. Diplomstudiengang
EEPK
Zusatzstudium/Wechsel des Studiums
EEPK
Studienplan EERMStudium EERMBeendigung Studium Funktionszuordnungsdiagr
.Diplomzeugniserstellung Funktionszuordnungsdiagr
.
Seite 6 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Gruppe Modell TypRückmeldung Studium Funktionszuordnungsdiagr
.Wechsel Studium/Aufnahme Zusatzstudium
Funktionszuordnungsdiagr.
Zulassung Studium Funktionszuordnungsdiagr.
Zulassung Studium mit Auflagen Funktionszuordnungsdiagr.
Zulassung Studium mit Berechtigungsprüfung
Funktionszuordnungsdiagr.
Zulassung Studium mit allg. Voraussetzung
Funktionszuordnungsdiagr.
Zulassung Studium mit bes. Voraussetzung
Funktionszuordnungsdiagr.
Zulassung Studium mit ind. Studiengang
Funktionszuordnungsdiagr.
Studium Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\allgemeine Funktionen
Hörsaaladministration Funktionsbaum
PowerCard Funktionsbaumallgemeine Funktionen FunktionsbaumAdresse EERMRaumverwaltung EERMHörsaaladministration Funktionszuordnungsdiagr
.
\ROOT\2gether\Soll-Konzept\allgemeine Funktionen\Detailfunktionen
Chipkartenfunkionen Funktionszuordnungsdiagr.
Chipkartenverwaltung Funktionszuordnungsdiagr.
Hörsaal reservieren Funktionszuordnungsdiagr
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 1
Anhang CARIS-Datenbank/Modell-Liste
Gruppe Modell Typ.
Hörsaal verwalten Funktionszuordnungsdiagr.
Hörsaal zurückgeben Funktionszuordnungsdiagr.
Hörsaalreservierungs-Info versenden
Funktionszuordnungsdiagr.
Hörsäle tauschen Funktionszuordnungsdiagr.
Institutshörsaal verwalten Funktionszuordnungsdiagr.
Kollisionsprüfung durchführen Funktionszuordnungsdiagr.
Reservierung freigeben Funktionszuordnungsdiagr.
Reservierungssituation abfragen Funktionszuordnungsdiagr.
autom. Hörsaalplanung durchführen
Funktionszuordnungsdiagr.
man. Hörsaalzuteilung durchführen Funktionszuordnungsdiagr.
Seite 8 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Anhang D: ARIS-Datenbank/wichtigste Modelle
Grobkonzept Projekt
Anhang D enthält die wichtigsten Modelle der ARIS-Datenbank, u. zw.:
Gruppe Modell TypSoll-Konzept 2gether, Grobkonzept Funktionsbau
mStudien- und Prüfungsverwaltung Funktionsbau
m
Lehrveranstaltungen
Lehrveranstaltungen administrieren Funktionsbaum
Aufnahme von Lehrveranstaltungen EEPKPlanung von Lehrveranstaltungen EEPK
Prüfungen Leistungsfeststellung EEPKPlanung von Prüfungen EEPK
Diplomarbeiten & Dissertationen
Diplomarbeiten/Dissertationen betreuen Funktionsbaum
Diplomarbeiten/Dissertationen vereinbaren Funktionsbaum
Diplomarbeiten/Dissertationen abschließen EEPK
An- und Abmeldungen
Abmeldungen Funktionsbaum
LV-Anmeldungen Funktionsbaum
Prüfungsanmeldungen Funktionsbaum
Anerkennungen Anerkennungen erzielen EEPKNostrifikationen erzielen EEPK
Abrechnungen Abrechnungen mit PAV und PTKG EEPKAbrechnungen mit PAV und ohne PTKG EEPKAbrechnungen ohne PAV und PTKG EEPK
Evaluierungen Arbeitsberichte erstellen Funktionsbau
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 1
Anhang DARIS-Datenbank/wichtigste Modelle
Gruppe Modell Typm
Beurteilung von Lehrveranstaltungen EEPK
Studien Beendigung des Sonderstudiums EEPKBeendigung des Studiums EEPKErstellung Diplomzeugnis EEPKRückmeldung Studierende mit Zahlschein EEPKRückmeldung Studierende ohne Zahlschein EEPKZulassung Studierende mit Nostrifikationsauflagen EEPKZulassung Studierende mit Studienberechtigungsprüfung
EEPK
Zulassung Studierende mit allg. Voraussetzungen EEPKZulassung Studierende mit bes. Voraussetzungen EEPKZulassung Studierende mit indiv. Diplomstudiengang
EEPK
Zusatzstudium/Wechsel des Studiums EEPK
Allgemeine Funktionen
Hörsaaladministration Funktionsbaum
PowerCard Funktionsbaum
Seite 2 von 1 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Anhang E: ARIS-Datenbank/Auswertungen
Grobkonzept Projekt
Das ARIS-Toolset stellt als datenbankbasiertes System zur Modellierung betrieblicher Informationssysteme ein Reporting-Tool zur Verfügung, daß es ermöglicht, Ad-Hoc-Auswertungen der ARIS-Datenbank zu erhalten.
Die folgende Tabelle zeigt beispielhaft eine Auflistung der vom System ‘2gether’ automatisiert, d.h. etwa in einem Batch-Lauf durchzuführende Funktionen, sortiert nach den zugehörigen Prozessen.
Modell Funktion Automa-tisiert
Aufnahme von Lehrveranstaltungen
Beauftragungsbescheide verschicken X
Planung von Lehrveranstaltungen
Erinnerung bzgl. Erhebungsbogen an LV-Leiter verschicken
X
Erinnerung bzgl. LV-Beschreibung verschicken XHistorie v. LV-Leiter und LV überprüfen X
Leistungsfeststellung Anmeldedaten anzeigen XAuswahlliste aller Prüfungen ohne Noteneingabe generieren
X
Daten an Rechts- und Organisationsabteilung weiterleiten
X
Studierenden über Einsichtstermine benachrichtigen
X
Studierenden über Noteneintrag benachrichtigen
X
Planung von Prüfungen Prüfung anzeigen Xüber Terminierungsprobleme informieren XAuswahlliste der möglichen Prüfungen generieren
X
Prüfungstermin in Kalender eintragen XAnerkennungen erzielen Antragsteller über Anerkennung informieren XAbrechnungen mit PAV und PTKG
Datenabgleich vornehmen (2gether,PIS -> PTKG)
X
Abrechnungen mit PAV und ohne PTKG
Daten übermitteln (2gether->PAV) X
Datenabgleich vornehmen (PIS->2gether) XAbrechnungen ohne PAV Abrechnungsbelege erstellen X
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 5
Anhang EARIS-Datenbank/Auswertungen
Modell Funktion Automa-tisiert
und PTKGAdressenangaben der Fehlläufer angeben XAnweisungen an Postsparkasse übermitteln XDaten an Bundesrechenzentrum schicken XDatenabgleich vornehmen (PIS->2gether) XFehlläufer informieren XLeistungsempfänger benachrichtigen X
Beendigung des Sonderstudiums
Abmeldung bewirken X
Bescheid erstellen XInformation der Abmeldung versenden XKartenfunkionen deaktivieren XSaldo der Abrechnungskonten prüfen XStudienblatt zur Beendigung generieren XStudierenden über Negativsalden informieren XStudierendenstammsatz deaktivieren X
Beendigung des Studiums
Abmeldung bewirken X
Information der Abmeldung versenden XKartenfunkionen deaktivieren XSaldo der Abrechnungskonten prüfen XStudienblatt zur Beendigung generieren XStudierenden über Negativsalden informieren XStudierendenstammsatz deaktivieren X
Erstellung Diplomzeugnis
Sponsionsbescheid versenden X
Rückmeldung Studierende mit Zahlschein
Bezahlungen bzgl. Rückmeldung überprüfen X
an Rückmeldungsbezahlung erinnern XRückmeldung Studierende ohne Zahlschein
Erinnerung an Rückmeldung versenden X
Seite 2 von 5 Erstellt gemeinsam mit 15. April 1998
Grobkonzept Projekt
Modell Funktion Automa-tisiert
Zulassung Studierende mit Studienberechtigungsprüfung
Prüfungsbescheid zur Studienberechtigungsprüfung konfigurieren
X
Zulassung Studierende mit allg. Voraussetzungen
Zulassungsvoraussetzungen prüfen X
ÖH-Beitrag zurückerstatten XZulassung Studierende mit bes. Voraussetzungen
Dokumente zur Zulassung anfordern X
Zulassungsvoraussetzungen prüfen XÖH-Beitrag zurückerstatten X
Zusatzstudium/Wechsel des Studiums
Ergebnis des Studienwunsches anzeigen X
Möglichkeit der Leistungsanerkennung überprüfen
X
Möglichkeit zur Aufnahme des Zusatzstudiums überprüfen
X
Neue Studienwahl bestätigen XWechselmöglichkeit überprüfen Xbisherige Leistungen anerkennen X
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 5
Grobkonzept Projekt
Anhang F: Wirtschaftlichkeitsbetrachtungen (ZID)