1 Kurzfassung

Integrierte Vollzugsverwaltung (IVV) ist im Bereich des Strafvollzuges ein Innovationssprung von der „Steinzeit“ ins nächste Jahrtausend. Nach mir vorliegenden Informationen ist IVV das erste System im deutschsprachigen Raum, das den Vollzugsbeamten eine möglichst vollständige elektronische Unterstützung in den zentralen Belangen des Vollzugs, also der täglichen Arbeit, bietet. Der praktische Teil dieser Arbeit umfaßt lediglich die die am Benutzerarbeitsplatz ablaufenden Masken (vgl. 7.1 Abgrenzung der Aufgabenstellung der vorliegenden Diplomarbeit) Hervorzuheben sind folgende Punkte:

• Implementierung von Gesetzen, wie z.B. die Strafzeitberechnung, die völlig auf EDV umgestellt wird: Die von der EDV errechneten Daten sind rechtsgültig.

• Abbildung von 29 verschiedenen Organisationsformen, die historisch in den 29 Strafvollzugsanstalten Österreichs entstanden sind.

• Mischung verschiedenster Technlogien: HOST mit CICS-Transaktionen, WEB-Server und WEB-Browser

• Gemeinsame Analyse und Entwicklung mit den Anwendern, um ein Produkt für die Anwender zu schaffen

• Besondere Anforderung an Datenschutz und Datensicherheit aufgrund der zu verspeichernden Daten.

Inhaltlich beschäftigt sich die vorliegende Arbeit mit folgenden Punkten:

• Spezifika dieses Systems: Wie bereits erwähnt handelt es sich um das erste deutsch-

• Datenschutz:Da sämtliche strafrechtlichen und vollzugsrelevanten Daten gespeichert

• Systemarchitektur: Beschreibung des heterogenen Systemumfelds und des Zusammenwirkens der einzelnen Komponenten.

• Entwurfsrichtlinien: Dies ist der zentrale Teil der Arbeit, in dem festgelegt wird, wie die graphische Benutzeroberfläche aufgebaut ist.

• Zugriffsberechtigung: Um mißbräuchliche Verwendung der Daten bzw. ungerechtfertig-

• Statuskonzept:Die teilweise parallele Bearbeitung personenbezogener Daten und die

• Funktionen: Hier wird als zentrale Funktion die Strafzeitberechnung und aus dokumentarische Gründen einige JS-Routinen vorgestellt.

• Schnittstellen: Beschreibung der XML-ähnlichen Schnittstelle der GUI zum HOST • Aussichten: Kommt die Veröffentlichung der Insassendaten im Internet?

Seite 3/57

2 Danksagung

Im Projektteam wirkten bis zu zehn Personen mit, die durch Ihre unterschiedlichen Tätigkeiten (Projektleitung, Datenbankdesign, Analyse, Datenbankwartung und HOST-Programmierung) und somit Wissen, wertvolle Informationen über meine eigentliche Tätigkeit der „Oberflächenprogrammierung“ hinaus geliefert haben, die in dieser Arbeit Niederschlag fanden. Hier einzelne herauszugreifen ist zu schwierig, so daß ich stellvertretend für das Entwicklungsteam den Projektleiter, Ing. Karl Bartl, nennen darf.

Daß es überhaupt zu dieser Arbeit kam und diese letztendlich auch fertiggestellt wurde, ist der Verdienst des betreuenden Dozenten Dr. Veith Risak.

Als verheirateter Student und Vater dreier Kinder wäre es ohne Verständnis meiner Familie auch kaum möglich gewesen, diese Arbeit zu vollenden.

Insbesondere gilt mein Dank auch für meine Eltern, die es erst ermöglichten, daß ich die Möglichkeit bekam, dieses Studium zu absolvieren.

Seite 4/57

3  Inhaltsverzeichnis  

1  Kurzfassung  2

2  Danksagung  4

3  Inhaltsverzeichnis  5

4  Einleitung.  9

5  Spezifika dieses Systems  10

6  Datenschutz.  11

6.1  Art der Daten.  11

6.2  Datenschutzgesetz.  11

6.3  Datensicherheit  11

6.4  Löschungen:  12

7  Architektur  13

7.1  Abgrenzung der Aufgabenstellung der vorliegenden Diplomarbeit  15

8  Entwurfsrichtlinien.  16

8.1  Allgemeines  16

8.2  Unterstützter WEB- HTML-Standard.  16

8.3  JavaScript  17

8.4  Cookies  17

8.5  Bildschirmdarstellung  17

8.6  Farben  19

8.7  Symbolik- Textdarstellung.  20

8.8  Frames.  20

8.8.1  Logo-Frame  21

8.8.2  Menü-Frame  21

8.8.3   22

8.8.4  Subjekt-Frame (Benutzerdaten)  22

8.8.5  Objekt-Frame (Bearbeitete Person/ Objekt)  22

8.8.6  Seitennavigations-Frame  23

8.8.7  Datenframe.  25

   5/57

8.9  Formulare.  27

8.9.1  Ein- und Ausgabefelder.  27

8.9.2  Vertikale Gliederung  28

8.9.3  Horizontale Gliederung.  28

8.10  Berichte.  30

8.11  Schaltflächen (Buttons)  30

8.11.1  Weitere Fenster.  31

8.12  Beenden der Applikation  32

8.13  Fehler und Hinweise  33

8.13.1  Eingabefehler.  33

8.13.2  Systemfehler.  33

8.13.3  Hinweise  33

9  Zugriffsberechtigung.  34

9.1  Technische Voraussetzungen.  34

9.1.1  Systemanforderungen / Systembeschränkungen  34

9.1.2  IVV-Systemadministration:  34

9.1.3  IVV-Zentrum (Schnittstelle Benutzer / Systemadministration):  34

9.1.4  Justizanstalten:  34

9.2  Datenbankausschnitt für Berechtigungslogik  35

9.3  Funktionen  36

9.3.1  Unterrollen aufbauen.  36

9.3.2  Rollen aufbauen.  36

9.3.3  Rechte in Form von Rollen vergeben.  36

9.3.4  Individuelles Menü aufbauen (Login)  36

9.3.5  Recht auf Aktion prüfen.  36

10  Statuskonzept.  37

10.1  Anforderungen.  37

10.1.1  Statuskonzept.  37

10.1.2  Historisierung.  37

10.1.3  Sperrung von Datensätzen.  37

   6/57

10.1.4  Datenhoheit  37

10.2  Lösungsansätze.  38

10.2.1  Statuskonzept.  38

10.2.2  Historisierung.  38

10.2.3  Sperren von Datensätzen  39

10.2.4  Datenhoheit  39

10.3  Detailkonzept Sperrlogik.  39

10.3.1  Funktion der Sperrung (Was wird getan )  39

10.3.2  Auswirkungen der Sperre  40

10.4  Detailkonzept Status  40

10.4.1  Grundlagen.  40

10.4.2  Umsetzung.  40

11  Funktionen.  42

11.1  Funktion Strafzeit berechnen.  42

11.1.1  Strafende:  42

11.1.2  BE:  42

11.1.3  Amnestie 1995 §3 u §2  43

11.1.4  VBE2-Termin, VBE3-Termin, EVZ-§145(2):(Erlaß von Miklau)  43

11.1.5  Prüfungstermine §25 StGB:  43

11.1.6  Änderungsmöglichkeit von Strafvollzugsanordnungen, deren Zuordnung,  

Reihenfolge  und „übernommen in Strafhaft“  44

11.1.7  Support-Funktion:  44

11.1.8  Vorgehensweise bei Rückerfassung, wenn die vom Vollzugsbeamten  

errechneten  Termine unterschiedlich zu den IVV-Terminen sind  44

11.1.9  IVV-Termine nach den errechneten Terminen:  44

11.1.10  Anhang:  45

11.2  Strafe reduzieren.  45

11.3  Zentrale JS-Funktionen.  46

11.3.1  Datumsfunktionen.  46

11.3.2  Listenfunktionen.  47

   7/57

12  Schnittstellen  49

12.1  Zum Host  49

12.2  Zu Projekt Redesign  49

12.2.1  Zielsetzung.  50

12.2.2  Nutzen  50

12.2.3  Anforderungen an Schnittstelle  50

12.2.4  Bereitstellen der Erfassungsfunktionalität aus IVV  50

13  Aussichten.  51

13.1  Nächste Versionen  51

13.2  Designänderungen.  51

13.2.1  Notsystem.  51

13.2.2  GGV.  51

13.3  Weitere Betrachtungen.  51

14  Anhang  54

14.1  Aufbauorganisation (Stand 11/98)  54

15  Abkürzungsverzeichnis.  55

16  Abbildungs- und Tabellenverzeichnis  56

17  Literaturliste  57

   8/57

4 Einleitung

Die Software für eine EDV gestützte, benutzerorientierte Unterstützung im Verwaltungsbereich des Strafvollzuges zu erstellen, wurde im März 1998 auf Grundlage einer Vorstudie ¹ die Bundesrechenzentrums GmbH (BRZ) durch den Lenkungsausschuß (LA) (siehe Anhang A Aufbauorganisation) beauftragt.

Die Zielsetzung dieser Integrierten Vollzugsverwaltung (IVV) ist die Rationalisierung durch einmalige Erfassung von Daten, Verfügbarkeit im österreichweiten Netz, automatische Erstellung und Weiterleitung von Meldungen und der Entfall der händischen Standesführung. Implementierungsplattform ist auf Benutzerseite ein WEB-Browser. Die Datenhaltung erfolgt zentral in einer relationalen Datenbank (DB2).

Ziel der vorliegenden Arbeit ist es, neben einer allgemeinen Darstellung des technischen Umfeldes, die Aspekte der Benutzerfreundlichkeit zu betrachten. Insbesondere wird darauf eingegangen, ob mit der von Auftraggeber (Bundesministerium für Justiz) und Auftragnehmer (BRZ) vorgegebenen Struktur und den zu erfüllenden gesetzlichen Grundlagen (Strafgesetzbuch, Strafvollzugsgesetz), die Anforderungen und Erwartungen der verschiedenen Endbenutzergruppen erfüllt werden können. Betrachtet wird auch, wie sich der in den 29 Vollzugsanstalten Österreichs sehr individuell entwickelte Vollzugsbetrieb in einem zentralem EDV-System abbilden lässt. Durch die Vorgabe eines 24 Stundenbetriebes und der weitreichenden Folgen eines Ausfal-

les (z.B.: Entlassung kann nicht durchgeführt werden ⇒ unerlaubter Freiheitsentzug) kommt einem Notsystem entsprechende Bedeutung zu. Ob und wie sich ein solches verwirklichen lässt ist ein zentraler Punkt der Benutzeraktzeptanz und wird somit auch in die folgende Betrachtung eingebunden.

Weiters werden exemplarisch typische Ein- und Ausgabemasken dargestellt und erörtert, inwieweit sich hier einerseits Vorteile im täglichen Verwaltungsablauf ergeben, andererseits welche Probleme durch die Umstellung einer „zettelbasierten“-Erfassung auf EDV-gestützte auftreten können. Dabei werden auch zentrale JavaScript-Module wie z.B.: Strafzeitberechnung vorgestellt. Datenschutz und Zugangsberechtigung werden, da es sich um sehr sensitive Daten handelt, nur allgemein betrachtet. Es wird keine Beschreibung der in IVV verwendeten Mechanismen erfolgen.

^{1 Steiner Ernst. IVV-Vorstudie. Wien: Bundesrechenzentrum, 1998} Seite 9/57

5 Spezifika dieses Systems

Bereits im ADV-Bericht der Österreichischen Bundesregierung aus dem Jahr 1995 wurde zum gewünschten ADV-Ausbaues des Strafvollzuges folgendes festgehalten: „Neben der Erarbeitung professioneller IT-Standards anstelle bereits bestehender Einzelplatzapplikationen sollen folgende IT-Vorhaben für eine Rationalisierung im Vollzugsbereich sorgen: • Einführung einer Häftlingsevidenz nach dem Meldegesetz 1991, enthaltende eine Proto-

• Einführungdes Elektronischen Datenaustausches im Verkehr der Justizanstalten v.a. mit

• Einführung einer einheitlichen Geschäftsregister-Applikation (als Teil der Applikation ADV-Justizverwaltung).

• Einführung einer einheitlichen IT-Verwaltung des Vollzugspersonals, ausgehende vom

• Unterstützung des Bereichs Wirtschaftsverwaltung.“

Nicht alle angeführten Punkte werden - zumindest in den ersten beiden Versionen - im Projekt IVV umgesetzt. Dennoch ist es eine neuartige Herausforderung, für ein „beamtetes“ System eine EDV-technische Lösung zu schaffen. Weiters erfolgt die „Mischung“ einer jungen, modernen Technolgie - Schlagwort Intranet - und einer erprobten, veraltend wirkenden „Hostdatenspeicherung“, die auch auf Grund des Zusammenwirkens unterschiedlichen Programmierphilosophien (einerseits userinterfaceorientiert, andererseits transaktionsorientiert) neue Perspektiven aufweisen kann.

Seite 10/57

6 Datenschutz

Aufgrund der sensitiven Daten ist ein besonderes Augenmerk auf den Datenschutz zu richten. Genau aus diesem Grund wird im folgenden Kapitel auch nicht über die konkrete Umsetzung informiert sondern nur allgemein ein paar besonders wichtige Punkte angesprochen, die zu berücksichtigen sind.

6.1 Art der Daten

• klassischen Personengrunddaten (Name, Vorname, Geburtsdatum,...) • Vollzugsgeschichte (Strafdaten, Urteilsdaten, wann und wo verbüßt, ...) • Führung während des Aufenthalts (Sicherheitsvermerke, Ansuchen, Besuche,...) • Personenbesonderheiten (Kostarten, Merkmale, Religion,...) • Termine (Ausgänge, Abwesenheiten ,..) • Depositen

6.2 Datenschutzgesetz

Das in §1(1) Datenschutzgesetz festgeschriebene Recht „auf Geheimhaltung der ihn betreffenden personenbezogenen Daten“ trifft somit beonders berücksichtungswürdig ein, da ein offensichtliches „schutzwürdiges Interesse“ besteht.

Da es sich aber um Daten gem. §4(3) „für Zwecke des Schutzes der verfassungsmäßigen Einrichtungen der Republik Österreich und für Zwecke der Strafrechtspflege“ handelt, finden die §§ 8 (Meldungen von Datenverarbeitungen und), 9 (Datenschutzverordnung), 11 (Auskunftsrecht) und 12 (Pflicht zur Richtigstellung oder Löschung) keine Anwendung. Bei dem zitierten Datenschutzgesetz handelt es sich um ein Bundesgestz vom 18. Oktober 1978 mit Änderungen bis ins Jahr 1994. Es ist deshalb die geplante Novellierung diese Gesetzes, bei den nächsten Versionen der Applikation entsprechend zu berücksichtigen.

6.3 Datensicherheit

Ein zentraler Punkt ist die Datensicherheit (siehe auch Datenschutzgesetz §10), die in mehrerlei Hinsicht zu gewährleisten ist.

Erstens beim Datenhalter, in diesem Fall das Bundesrechenzentrum, der genau festzulegen hat, wie und in welcher Weise Entwickler und Betreiber Zugriff auf die Daten haben. Da eine generelle Zugriffsverweigerung auf den Datenbestand durch die Entwickler auf Grund von Fehlerbehebungen, Support, Datenbereinigungen (‚manuelle‘ Beseitigungen von Inkonsitenzen, die durch fehlerhafte Programmmodule auftreten können) nicht zielführend erscheint, ist es notwendig, diese Gruppe eine entsprechende Verschwiegenheitserklärung unterschreiben zu lassen. Selbiges gilt auch für die Gruppe der Betreiber. Änderungen direkt in der Datenbank sollten nur auf schriftliche Anforderung durchgeführt werden. Seite 11/57

Zweitens am Übermittlungsweg über WAN und LAN. Obwohl es sich um ein Intranet handelt, daß durch diverse Firewalls vom Internet abgeschottet ist, ist es denkbar, und Beispiele der Vergangenheit zeigen, daß jedes System zugänglich gemacht werden kann, müssen die Daten verschlüsselt übertragen werden und es ist zu überlegen, auch den Datenbestand verschlüsselt abzulegen. Da es sich um eine österreichweite Anwendung handelt und somit die Informationen quer durch Österreich transportiert werden (WAN), ist auch ein direktes Abhorchen der Leitungen möglich und somit eine Verschlüsselung vom der zentralen Datenbank bis zur anzeigenden Einheit notwendig. Drittens ist vorzusorgen, daß sich nur berechtigte Personen (siehe Pkt. 9

Zugriffsberechtigung) in das System einloggen können und nur Zugriff zu jenen Daten erhalten, für die sie berechtigt sind. Für Revisionen ist darüberhinaus notwendig, durch eine sogenannte „Historiendatenbank“ nachvollziehen zu können, wer, wann, was mit dem System gemacht hat. Dazu muß für jeden Zugriff der Zeitpunkt, Userkennnung, Aktion und Daten vor der Veränderung gespeichert werden.

6.4 Löschungen:

Zu klären ist von rechtlicher Seite wie und wann welche Daten zu löschen sind. Vom Benutzer ist keine „echte“ Löschung möglich. Er kann lediglich gewisse Daten (z.B. Sicherheitsvermerke) als „gültig bis“ bezeichnen bzw. Geschäftsstücke stornieren. Insbesondere ist in diesem Zusammenhang darauf zu achten, daß keine „versteckten“ Informationen gespeichert werden. So wäre es denkbar, daß ein Benutzer einen unliebsamen Deliquenten ein Geschäftsstück zuordnet, dieses mit entsprechenden Anmerkungen versieht und es anschließend storniert. Weiters ist darauf zu achten, daß die im Zuge des Betriebs durch das Bundesrechenzentrum angelegten Sicherungsbänder ebenfalls sensitive Daten enthalten, und diese bei Löschungen ebenfalls zu berücksichtigen sind.

Seite 12/57