Startseite der Beteiligung
Dialog IT-Planungsrat | Open Government Moderne Verwaltung

Öffentlichkeitsbeteiligung zur Referenzarchitektur für E-Partizipationssoftware

Inhaltsverzeichnis

  • Referenzarchitektur für E-Partizipationssoftware
    • 2 Einführung E-Partizipation
    • 3 Anforderungen an die Software: Basisfunktionen
      • 3.1 User Stories
      • 3.2 Arbeitsprozesse beachten
    • 4 Konkrete Anwendungsfelder: Szenario-spezifische Anforderungen
      • 4.1 Szenario 1: Rückmeldungen zu einem Text einholen
        • 4.1.1 User Stories
        • 4.1.2 Notwendige und wünschenswerte Anforderungen
        • 4.1.3 Exkurs: Innovative Ansätze für E-Partizipation
      • 4.2 Szenario 2: Rückmeldungen zu einer räumlichen Planung einholen
        • 4.2.1 User Stories
        • 4.2.2 Notwendige und wünschenswerte Anforderungen
        • 4.2.3 Exkurs: Innovative Ansätze für E-Partizipation
      • 4.3 Szenario 3: Ideen zu einem Thema sammeln
        • 4.3.1 User Stories
        • 4.3.2 Notwendige und wünschenswerte Anforderungen
        • 4.3.3 Exkurs: Innovative Ansätze für die Anwendung der Funktionen
      • 4.4 Auswertung von Beteiligungsverfahren
    • 5 Technische Umsetzung
      • 5.1 Nicht-funktionale Anforderungen und Spezifikation
        • 5.1.1 Usability, Barrierefreiheit und Responsivität
        • 5.1.2 Mandantenfähigkeit
        • 5.1.3 Interoperabilität
        • 5.1.4 Operabilität
        • 5.1.5 Wartbarkeit, Erweiterbarkeit und Flexibilität
        • 5.1.6 Skalierbarkeit, Performanz und Verfügbarkeit
        • 5.1.7 Informationssicherheit und Datenschutz
        • 5.1.8 Open-Source-Basis
        • 5.1.9 Unterstützung offener Standards
        • 5.1.10 Exkurs: Innovative Ansätze für E-Partizipation
      • 5.2 Strukturelle Merkmale und Rahmenbedingungen
      • 5.3 Referenzarchitektur für E-Partizipationslösungen
        • 5.3.1 Zielsetzungen einer Referenzarchitektur
        • 5.3.2 Entwicklungsansätze
        • 5.3.3 Aufbau der Referenzarchitektur für E-Partizipationslösungen
        • 5.3.4 Interoperabilität als Schlüsselanforderung
        • 5.3.5 Exemplarischer Aufbau
5 von 43

2.2.1 Zusammenführung der Szenarien: Gesetzliche Vorgaben

Nach Sammlung der nutzerspezifischen Anforderungen für die fünf oben beschriebenen Szenarien zeigte sich, dass das Kriterium Schriftformerfordernisin der Gesamtheit der technischen Anforderung, die die Szenarien unterscheiden, für die Software nur eine untergeordnete Rolle spielt. Daher werden in Kapitel 3 die Szenarien 1 und 3.1, sowie die Szenarien 2 und 4 gemeinsam dargestellt.

Zusammenführung der Szenarien seit dem 1. Zwischenbericht

Abbildung 1   Zusammenführung der Szenarien seit dem 1. Zwischenbericht (August 2016)

Mit dieser Zusammenführung bzw. Reduzierung der Anzahl der Szenarien sollen die technische und verfahrensrechtliche Relevanz des Schriftformerfordernisses keinesfalls als gering beschrieben werden. Das Gegenteil ist der Fall. Gleichwohl wird allein durch das Kriterium des Schriftformerfordernisses keine Beschreibung von zwei weiteren, eigenständigen Szenarien erforderlich:

1. Das Kriterium des Schriftformerfordernisses ist lediglich für eine Teilmenge gesetzlich vorgegebener Verfahren relevant (z.B. Planfeststellungsverfahren). Die Möglichkeiten eine gesetzlich vorgegebene Schriftform durch die elektronische Form zu ersetzen sind gesetzlich präzise geregelt. Sie treffen für alle relevanten Verfahren gleichermaßen zu und müssen nicht im Einzelfall gesondert betrachtet werden. (Ist die Schriftform vorgeschrieben, muss der Zugang via qualifizierter elektronischer Signatur eröffnet werden. Dies kann durch die Eröffnung eines DE-Mail Zugangs oder über eine Web-Anwendung geschehen, welche die sichere elektronische Identifizierung durch die eID-Funktion des neuen Personalausweises ermöglicht.) Eine detaillierte Auseinandersetzung mit dem Schriftformerfordernis würde den Rahmen des Projekts zudem sprengen. Im Rahmen von sogenannten formellenVerfahren werden aus bisherigen Erfahrungen in der digitalen Öffentlichkeitsbeteiligung vor allem solche erhöhte Anforderungen an die Systeme deutlich, die insbesondere die Funktionen zur Auswertung betreffen. Denn es passiert nicht selten, dass in einem Verfahren in dem die Öffentlichkeit die Möglichkeit hat, auf Betroffenheiten oder Raumwiderstände hinzuweisen, die Anzahl der zu bearbeitenden Rückmeldungen fünfstellige Beträge überschreitet. Damit solche Verfahren online durchgeführt werden können, sind Systeme notwendig, die die Werkzeuge für die effiziente Auswertung solcher Textmengen bereitstellen. Formelle Verfahren stellen somit übergreifend vor allem hohe Anforderungen an ein durchdachtes und leistungsstarkes System für die Auswertung entstehen.

2. Andererseits helfen solche Funktionen bei der Auswertung eines Online-Dialogs über ein politisches Thema. Auch für diese Form der informellen Beteiligung sind die inhaltlichen Auswertungen teilweise sehr aufwändig und technische Unterstützung wäre daher wünschenswert. Da in der Regel (bisher) jedoch keine fünfstellige Anzahl an Kommentaren in einer informellen Online-Diskussion zu erwarten sind, werden die entsprechenden Auswertungssysteme dafür oft vernachlässigt. Dieser Fehler soll in diesem Dokument vermieden werden.
Gleichwohl wird an mehreren Stellen, und zuletzt ausführlich im Kapitel 5.2, darauf hingewiesen, dass nicht jedes E-Partizipationsangebot jede der in diesem Dokument genannten Funktionen besitzen muss und es immer verschiedene Abwägungsentscheidungen zu treffen gilt. Eine Online-Plattform für den Dialog in der Kommune über die Neugestaltung einer Parkanalage muss beispielsweise nicht dasselbe, aufwändig entwickelte Auswertungssystem bereitstellen, wie es für die Online-Beteiligung zu einem Trassenbau erforderlich wäre, damit ein erfolgreiches und effizientes Verfahren durchgeführt werden kann. Hilfreich wären diese Auswertungssysteme jedoch auch bei kleineren Verfahren mit weniger Beiträgen.

3. Darüber hinaus stellt das Schriftformerfordernis bei Weitem nicht die einzige zu beachtende rechtliche Anforderung für Verfahren der Öffentlichkeitsbeteiligung dar. Bereits im Vorfeld müssen daher grundlegende Fragen der rechtssicheren Durchführung von Verfahren geklärt werden. Diese können unterschiedlichste Aspekte im Einzelfall betreffen. Beispielsweise muss es bestimmten Verfahren möglich sein, eine anonyme Stellungnahme abzugeben Dieser Umstand können bei der Eingabe einer Stellungnahme bzw. über die Registrierung recht einfach berücksichtigt werden. Zentral ist jedoch, dass diese rechtlichen Aspekte vor der Bereitstellung bzw. Entwicklung einer Software geklärt sind. In diesem Sinne liefert die vorliegende Referenzarchitektur die allgemeine Basis für ein umfassendes System dessen konkrete Anwendung auf den rechtlichen Einzelfall aber einer weiteren Detaillierung bedarf.

Mit Fokus auf die technischen Anforderungen für eine modulare Referenzarchitektur für E-Partizipation, die alle möglichen Anwendungsszenarien abdecken soll, werden somit die folgenden drei archetypischen Szenarien genauer beleuchtet:

Drei Szenarien für die Ableitung der funktionalen Anfoderungen

Abbildung 2   Drei Szenarien für die Ableitung der funktionalen Anforderungen

Diese drei Szenarien weisen in ihren funktionalen Anforderungen einige Unterschiede auf, die in den jeweiligen Kapiteln beschrieben werden. Jedoch ähneln sich selbst diese drei Anwendungsgebiete in der grundsätzlichen Idee einer verbesserten, technisch-vermittelten Information und Teilhabe für die Öffentlichkeit. Daher sollte stets in Betracht gezogen werden, Systeme bereitzustellen, die alle Szenarien abdecken können, sodass der gesamte Beteiligungsprozess mit formellen und informellen Beteiligungsphasen auf einer Plattform realisiert und nachvollzogen werden kann.

5 von 43

2 Beiträge

Sortieren nach:
Datum
Anzahl Kommentare
Anzahl Bewertungen

Raumbezug bei Bürgerbeteiligungen

Bilder zum Beitrag - öffne Lightbox

"Daher sollte stets in Betracht gezogen werden, Systeme bereitzustellen, die alle Szenarien abdecken können, sodass der gesamte Beteiligungsprozess mit formellen und informellen Beteiligungsphasen auf einer Plattform realisiert und nachvollzogen werden kann. " Meines Erachtens ist es völlig ilusorisch *ein* System oder eine "Plattform" zu entwickeln oder zu erwerben welche alle Anforderungen abdeckt. Dies führt immer zu Systemen die alles etwas aber nichts richtig können: "Etwas Rückmeldungen zu Text einholen", "Ideen sammeln" und "Karte" bekommen man meist schon irgendwie in Software oder Plattform XX eingebaut. Mit dem Anspruch einer nutzerfreundlichen Lösung der in Sektion 5.1.1 erläutert wird hat es *eine* Plattform aber meist schwer. Das Beste Beispiel ist dieses Beteiligungssystem: Funktional mag es ermöglichen Feedback zu einem Text einzuholen, von der Sinnhaftigkeit dies als Form von Kommentaren ohne direkten Textbezug in einem Thread untereinander zu tun bin ich nicht überzeugt. Genauso verhält es sich mit den meisten Kartenanwendungen in Beteiligungssystemen: Oft werden ohne jedes kartographisches Verständniss auf einer Hintergrundkarten Marker, Linien und Polygone eingezeichnet die Veränderungsbedarfe im Raum anzeigen sollen. Als Beispiel kann hier z.B. Nexthamburg dienen. Die Initative ist klasse - methodisch, strukturell, vom Marketing, etc. Aber, die Kartendarstellung ist stark verbesserungwürdig: http://www.nexthamburg.de/ideenkarte/ . Dinge wie ein Clustering oder eine passende Smbolyisierung der Marker könnten die "Lesbarkeit" verbessern. Kontextsensitive Legenden, Adressuche für die Navigation innerhalb der Karte, eine Auswahl von verschiedenen Hintergrundkarten, und besseren "Pop-Ups" (Feature Infos) die nicht auf weitere Subseiten verlinken bei einem Klick auf eine Idee in der Karte sind simpele weitere Verbessrungen. Man kann nicht "nicht kommunizieren" und dies gilt für Geovisualisierungen oder "Karten" ebenso wie für Texte mit Feedback und Ideensammlungen für Abstimmungen. Deshalb würde ich die Aussage des Satzes oben hinterfragen und hier lieber auf ein Baukastensystem von Software verweisen welches Basisfunktionen anbietet. Dieser Baukasten muss aber auf jeden Fall die Möglichkeiten bieten sich mit anderen Softwarekomponenten zu kombinieren oder erweitern zu lassen. Integration ist hier das Stichwort. Deshalb würde ich empfehlen auf Standard Interfaces zu setzen, (wie hier von im Ansaätzen im Dokuemnt zu erkennen über die SAGA verweise) und modulare Komponeten / Systeme empfehlen.

Transparenz // Open Algorithmus

"Damit solche Verfahren online durchgeführt werden können, sind Systeme notwendig, die die Werkzeuge für die effiziente Auswertung solcher Textmengen bereitstellen. Formelle Verfahren stellen somit übergreifend vor allem hohe Anforderungen an ein durchdachtes und leistungsstarkes System für die Auswertung entstehen." - Wer programmiert den Algorithmus nach welchen Maßstäben und Kriterien? Automatisierte Entscheidungsmechanismen bauen auf einer Programmierung und einer Datengrundlage auf. Das Interesse der Bürger, über die Grundlagen der Entscheidungsfindung aufgeklärt zu werden, ist evident. Transparenz zu erreichen ist jedoch komplex. Zum einen basieren verschiedene automatisierte Entscheidungen darauf, dass die Details der Entscheidungsfindung nicht bekannt sind. Zudem müssen technische Spezifikationen und die sich daraus ergebenen Folgen verstanden werden - und nachvollziehbar sein. Die technischen Details müssen so kommuniziert werden, dass sie sowohl akkurat als auch richtig sind. (Quelle: Siehe dazu die Vorschläge aus dem Arbeitskreis Open Government Partnership Deutschland - 270 Vorschläge aus der Zivilgesellschaft zu Pkt. Künstliche Intelligenz und Algorithmenkontrolle (D.30)

Gegenstände

Übersicht

Informationen

Übersicht
  • Hintergrund zur Beteiligung
  • Design Thinking-Workshop
  • Entwurf Referenzarchitektur (Download *.pdf 1.8 MB)
zum Seitenanfang
Anmelden

Anmelden

Anmelden

Datenschutzeinstellungen

Es werden für den Betrieb der Seite technisch notwendige Cookies gesetzt. Darüber hinaus können Sie Inhalte von Drittanbietern erlauben. Ein Widerruf ist jederzeit möglich.
Weitere Informationen finden Sie unter Datenschutzerklärung und Impressum.