Bundesgeschäftsstelle/Anforderungspapier Mitgliederverwaltung

Einführung

Mit Auftrag vom 19. November (2009-11-19_-_Vorstandssitzung#TOP3_Verwaltung) sind der Bundesschatzmeister Bernd Schlömer und der Leiter der Bundesgeschäftsstelle Michael Ebner beauftragt worden, Anforderungen für eine neue Mitgliederverwaltung zusammenzustellen.

Zu diesem Zweck wurde eine Arbeitsgruppe aus einigen Bundesvorstandsmitgliedern sowie GenSeks und Schatzmeister der Länder gebildet. Ein Entwurf für ein Anforderungspapier wurde an diese Gruppe verschickt und in zwei Runden bearbeitet. Zu diesem Zweck haben einige Mitglieder dieser Arbeitsgruppe Meinungen, Kommentare und eigene Anforderungen verfasst, teilweise wurden auch die Anregungen Dritter eingebracht.

Die eingebrachten Beiträge und der ursprüngliche Entwurf wurden zu einem Gesamtdokument zusammengefasst, das weitgehend ein Dissens-Papier ist: Wesentliche Punkte sind strittig und vom Bundesvorstand zu entscheiden.

Es wird vorgeschlagen, zunächst die Punkte im Abschnitt "besonders strittige Punkte" zu diskutieren, gegebenenfalls in der aufgeführten Reihenfolge.

besonders strittige Punkte

Entscheidung über die Einführung

Die Einführung einer solchen Software greift deutlich in die Belange der Landesverbände ein. Es wäre denkbar, in einer zweiten Runde alle Landesverbände (insbesondere deren Schatzmeister und GenSeks) zu beteiligen. Eine solche zweite Runde kostet jedoch Zeit.

Zur Entscheidung: Will der Bundesvorstand die Entscheidung über die Einführung der Mitgliederverwaltung alleine fällen, oder soll versucht werden, ein Konsens mit den Landesverbänden zu finden?

(Entscheidung vielleicht zurückstellen, bis die wesentlichen Konfliktlinien andiskutiert wurden.)

Funktionalität versus Datenschutz

Eine Mitgliederverwaltung kann so eingerichtet werden, dass möglichst alle relevanten Daten dort gespeichert werden. Dem stehen Bedenken bezüglich des Datenschutzes entgegen.

Für eine möglichst umfassende Speicherung spricht: - Redundanzen und somit verwaltete Daten an manchen Stellen werden vermieden - Die Daten befinden sich unter dem Schutz eines gemeinsamen Datenschutzkonzeptes mit dann hoffentlich ständig aktualisierten Zugangsberechtigungen - Wenn ein zentrales System alle nötige Funktionalität abdeckt, sinkt der Bedarf an "externen Lösungen", für die traditionell kein vernünftiges Datenschutzkonzept umgesetzt wird.

Gegen eine möglichst umfassende Speicherung spricht: - Man schafft für alle Angriffe auf solche Datenbestände (lesend oder zerstörend) ein lohnendes Ziel - Ein Mitglied, auch wenn es Funktionen in der Partei wahrnimmt (Vorstandsamt oder ähnliches), soll stets Herr über die eigenen Daten bleiben.

Umfang der Offenheit

Systeme mit umfangreichen Exportmöglichkeiten erfordern weniger interne Funktionalität, da im Bedarfsfall die Daten exportiert und mit anderer Software weiterverarbeitet werden. Dies Durchbricht allerdings jedes Datenschutzkonzept.

Wird der Export sehr restriktiv gehandhabt, dann muss das System alle erforderlichen Aufgaben abdecken.

Zur Entscheidung: Wie offen soll das System sein?

Reicht ein Login mit Benutzername und Passwort

Wenn nicht, welche alternativen Möglichkeiten gibt es? Sollen zusätzlich Transaktionsnummern (beispielsweise auch für mehrere Schritte gemeinsam oder für eine Login-Session verwendet werden)? Müssen die Daten in der Datenbank verschlüsselt werden?

Zur Entscheidung: Wie muss das System vor unbefugtem Zugriff geschützt werden?

Schreibrechte

Wer darf in das System Änderungen einpflegen? Wird technisch eine zuständige Stelle bestimmt (mit allen Problemen, wie diese nicht tätig wird) oder wird das per "Arbeitsanweisung" geregelt? Wer darf das Änderungslog einsehen?

Sollen Veröffentlichungsregeln änderbar sein

Soll die Sichtbarkeit von Daten beim Aufsetzen des Systems für die Betriebsdauer dieses Systems festgelegt werden, oder soll sich das nachträglich ändern lassen können?

Punkte ohne Konsens

Einladung per eMail

Muss die Mitgliederverwaltung Einladungen per eMail und mit Bestätigungslink unterstützen?

Folgen Dublettensuche

Bei der Eingabe von Daten könnte die Dublettensuche anspringen in einem Fall, in dem der zugrundeliegende Datensatz wegen Sichtbarkeitsregeln nicht angezeigt würde. Muss dann still nach oben Eskaliert werden? Macht das dann den übergeordneten Ebenen nach einem (ggf. auch Mehrfachen) Massendatenimport viel Freude?

Frei vergebbare Flags

Wer darf frei vergebbare Flags vergeben?

Definition von Items

Sollen sich nach dem Aufsetzen des Systems weitere Items einführen lassen? Wenn ja, von wem?

Self Service

Wollen wir Self Service und wie könnte das realisiert werden?

Open Source

Soll eine Festlegung auf OpenSource-Software erfolgen?

Datenhaltung

Muss die Datenhaltung auf eigenen Systemen erfolgen und wie definiert sich eigenes System in diesem Zusammenhang?

Anbindung an LDAP

Soll die Mitgliederverwaltung an ein LDAP-Dienst angebunden werden?

weitgehender oder völliger Konsens (informativ)

Browserlösung

Um keine Updates verteilen zu müssen und damit keine Festlegung auf ein Betriebssystem erforderlich ist, wird eine Browserlösung favorisiert.

rollenbasierte Zugriffskonzept

Zur Vereinfachung der Verwaltung werden generische Rollen verwendet.

Zugriff von Nichtgliederungen

Nichtgliederungen wie Schiedsgerichte oder Arbeitskreise erhalten keinen Direktzugriff und erhalten bei berechtigten Anliegen Amtshilfe von den GenSeks.

Grundsatz der Autarkie

Die Mitgliederverwaltung muss jeden Gebietsverband in die Lage versetzen, ohne die Mitwirkung anderer Gebietsverbände seine Verpflichtungen nach Satzung und/oder Parteiengesetz zu erfüllen.

Begründung: Es ist keinem Vorstand zuzumuten, sich bei der Erfüllung rechtlicher Verpflichtungen der "Gnade" anderer Gebietsverbände zu unterwerfen.

Grundsatz des beschränkten Zugriffs

Jeder Benutzer hat nur (Lese- und/oder Schreib-) Zugriff auf die Daten, die a) er für die Erfüllung seiner Verpflichtungen nach Satzung und/oder Parteiengesetz benötigt, oder b) deren Veröffentlichung vom Mitglied implizit oder explizit genehmigt wurde.

Begründung: Ein Vollzugriff ist aus Gründen des Datenschutzes abzulehnen.

Grundsatz der Konsistenz

Es wird auf einem Datenbestand gearbeitet, der entweder zentral gehalten wird, oder dessen konsistente Replikation durch eine technische Vorrichtung jederzeit gewährleistet wird.

Begründung: Unterschiedliche Datenbestände machen viel Ärger und werden uns bei der Wirtschaftsprüfung auch "um die Ohren gehauen".

Grundsatz der Historie

Für jeden beliebigen Zeitpunkt von Einführung der Mitgliederverwaltung bis zum Ende der gesetzlichen Aufbewahrungsfrist muss sich der jeweilige Stand ermitteln lassen.

Begründung: Wird für die Wirtschaftsprüfung benötigt

Grundsatz der Flexibilität

Die Mitgliederverwaltung muss sich jederzeit geänderten Anforderungen anpassen lassen.

Begründung: Wir wollen nicht alle paar Monate ein neues System einführen, nur weil das alte nicht an veränderte Anforderungen angepasst werden kann.

Grundsatz der Datensicherheit

Unautorisierter Zugriff auf die Daten muss verhindert werden. (Der Vollständigkeit halber: Datensicherung ist vorzusehen.)

Begründung: Ergibt sich aus dem Datenschutz.

Grundsatz der Bedienerfreundlichkeit

- komplette Tastaturbediebarkeit - frei definierbare Filterstatements (Mehrere Filterbedingungen verknüpfbar mit UND und/oder ODER - vielleicht gleich SQL-Syntax, sofern Sicherheitsrisiken sicher ausgeschlossen werden können.) - Jeder Benutzer muss solche Filterstatements abspeichern können, damit er sie nicht jedesmal neu formulieren muss

Begründung: Diejenigen, die solche Verwaltungsaufgaben schon freiwillig machen, sollen es wenigstens einfach haben.

Grundsatz der Nachvollziehbarkeit

Bei jeder Änderung am Datenbestand muss mitprotokolliert werden, wann wer welche Aktion durchgeführt hat

Begründung: Wenn irgendetwas nicht stimmt, dann muss feststellbar sein, warum das so ist.

komplettes Anforderungspapier

Version 0.5 14. Dezember 2009

Mitwirkende:

ME: Michael Ebner JMS: Jan Marten Simons MKU1: Michael Küthe BS: Bernd Schlömer AL: Arne Ludwig

Inhalt

1. Ziel dieses Dokumentes 2. Begriffe 3. Grundsätze 4. Diskussionspunkte 5. Vorschlag für die Veröffentlichungsregeln 6. Detailanforderungen 7. Neue Vorschläge zur Diskussion

Ziel dieses Dokumentes

Die Mitgliederverwaltung der Piratenpartei genügt derzeit nicht den Anforderungen: - es sind nicht alle nötigen Beteiligten an das System angebunden - sie genügt nicht den Anforderungen der PartG, für Stichtage zuverlässig die Zahl der Piraten zu ermitteln - darüber hinaus wäre eine bessere Unterstützung der Verwaltungsabläufe hilfreich

Um diese Probleme zu beheben, muss entweder a) beim bestehenden System diese Mängel abgestellt werden, oder b) eine neue Mitgliederverwaltung aufgesetzt werden.

Mit diesem Dokument sollten dafür die Anforderungen konkretisiert werden.

Begriffe

2.1 Mandantenfähigkeit Es lassen sich mehrere voneinander unabhängige Organisationen verwalten. (Partei, JuPis, Pirat e.V., parteinahe Stiftung - auch Test- und Schulungsinstanzen)

2.1.1 Instanzenfähigkeit Für mehrere voneinander unabhängige Organisationen müssen sich mehrere Instanzen der Software einrichten lassen. Dem dürfen keine technischen oder lizenzrechtlichen Probleme entgegen stehen.

2.2 Teilgliederungsfähigkeit Es lässt sich eine Organisation mit Landes-, Bezirks-, Kreis- und Ortsverbänden abbilden.

2.3 Self Service Das einzelne Mitglied kann die eigenen Daten (Adresse, Kontaktdaten) selbst editieren.

2.3.1 Pseudo Self Service Das einzelne Mitglied kann die Änderung eigener Daten (Adresse, Kontaktdaten) selbst veranlassen.

2.4 Mitgliederdaten Alle Daten, die zu einem Mitglied gespeichert sind

2.4.1 Minimaldaten Die Daten, welche die zuständigen Gliederungen zwingend benötigen (Name, Adresse, Geburtsdatum, Status Beitragszahlung, zuständige Gliederungen)

2.4.2 Kontaktdaten allgemein Minimaldaten und weitere Kontaktdaten, die einem größeren Kreis zugänglich gemacht werden können (eMail, Telefon, Handy, Zweitwohnsitz)

2.4.3 Kontaktdaten intern Kontaktdaten allgemein und weitere Kontaktdaten, die einem kleineren Kreis zugänglich gemacht werden können (Wer beispielsweise Bundesvorsitzender ist, möchte vielleicht seine Handynummer nicht an alle weitergeben - aber die Bundesgeschäftsstelle sollte ihm im Notfall schon erreichen können)

2.4.4 Informationsdaten Weitere Daten, die ein Mitglied freiwillig angibt, beispielsweise einen Beruf oder eine besondere Befähigung. Braucht der Bundesvorstand beispielsweise für eine bestimmte Einschätzung eines juristischen Sachverhaltes im Markenrecht einen darauf spezialisierten Anwalt, dann muss sich die Datenmenge entspechend filtern lassen.

2.5 zuständige Gliederungen Alle Parteigliederungen, denen das betreffende Mitglied angehört

2.5.1 erweiterte zuständige Gliederungen Alle Parteigliederungen, die in den letzten 18 Monaten zuständige Gliederung gewesen sind oder in den nächsten 6 Monaten zuständige Gliederung werden (ein Umzug kann ja auch im voraus angekündigt und eingegeben werden). Die Frist von 18 Monaten ergibt sich aus der Veröffentlichungspflicht der Spenden bei den Rechenschaftsberichten.

2.6 Filtern Ermittlung einer Teildatenmenge, die bestimmten Kriterien entspricht. Ein Filtervorgang liefert keinen, einen oder mehrere Datensätze zurück

2.6.1 Suche Ein Filtervorgang, der im Regelfall einen einzelnen Datensatz zurückliefern soll (z.B. Suche nach einer Mitgliedsnummer)

2.6.2 Dublettensuche Suche nach Mitgliedern, denen mehrere Hauptdatensätze zugeordnet sind.

2.6 Datensatz Eine Datenzeile in einer Datenbanktabelle

2.6.1 Hauptdatensatz Ein Datensatz, der einer bestimmten (natürlichen oder juristischen) Person zugeordnet ist

2.6.2 Mitgliederdatensatz Ein Hauptdatensatz, der einem Mitglied zugeordnet ist

2.6.3 Interessentendatensatz Ein Datensatz eines Nichtmitgliedes, an dessen Speicherung ein berechtigtes Interesse besteht und der dieser Speicherung explizit zugestimmt hat.

2.6.4 Detaildatensatz Ein Datensatz, der einem Hauptdatensatz zugeordnet ist

2.7 Benutzer Eine Person (m/w), die sich in die Mitgliederverwaltung einloggen kann

2.8 Veröffentlichung Sichtbarkeit der Daten für einige oder alle Benutzer

2.8.1 Genehmigung der Veröffentlichung Einverständnis eines Mitglieds zur Veröffentlichung seiner Daten

2.8.2 implizite Genehmigung der Veröffentlichung Durch Beitritt oder Annahme der Wahl in ein Amt oder eine Funktion genehmigt ein Mitglied im notwendigen Maße der Veröffentlichung

2.8.3 explizit Genehmigung der Veröffentlichung Genehmigung der Veröffentlichung durch eigene Erklärung, der Umfang der Veröffentlichung kann dabei festgelegt werden

2.9 Single Sign-on Mit einer einmaligen Anmeldung kann ein Mitglied mehrere Systeme (z.B. Forum, Mitgliederverwaltung, LiquidFeedback...) nutzen

2.9.1 Zentrale Authentifizierung (ZA) Einrichtung innerhalb oder außerhalb der Mitgliederverwaltung, mit dessen Hilfe Piraten für mehrere Systeme authentifiziert werden können.

2.10 Item Eine Dateninformation in einem Datensatz oder die "Spalte" dafür

2.11 Funktionsträger Mitglieder mit einer Parteifunktion (Vorstand, Schiedsgericht, Kassenprüfer, Kandidaten für öffentliche Wahlen, etc)

Grundsätze

Die Mitgliederverwaltung muss den folgenden Grundätzen entsprechen (Reihenfolge ohne Priorisierung)

3.1 Grundsatz der Autarkie Die Mitgliederverwaltung muss jeden Gebietsverband in die Lage versetzen, ohne die Mitwirkung anderer Gebietsverbände seine Verpflichtungen nach Satzung und/oder Parteiengesetz zu erfüllen.

Begründung: Es ist keinem Vorstand zuzumuten, sich bei der Erfüllung rechtlicher Verpflichtungen der "Gnade" anderer Gebietsverbände zu unterwerfen.

3.2 Grundsatz des beschränkten Zugriffs Jeder Benutzer hat nur (Lese- und/oder Schreib-) Zugriff auf die Daten, die a) er für die Erfüllung seiner Verpflichtungen nach Satzung und/oder Parteiengesetz benötigt, oder b) deren Veröffentlichung vom Mitglied implizit oder explizit genehmigt wurde.

Begründung: Ein Vollzugriff ist aus Gründen des Datenschutzes abzulehnen.

3.3 Grundsatz der Konsistenz Es wird auf einem Datenbestand gearbeitet, der entweder zentral gehalten wird, oder dessen konsistente Replikation durch eine technische Vorrichtung jederzeit gewährleistet wird.

Begründung: Unterschiedliche Datenbestände machen viel Ärger und werden uns bei der Wirtschaftsprüfung auch "um die Ohren gehauen".

3.4 Grundsatz der Historie Für jeden beliebigen Zeitpunkt von Einführung der Mitgliederverwaltung bis zum Ende der gesetzlichen Aufbewahrungsfrist muss sich der jeweilige Stand ermitteln lassen.

Begründung: Wird für die Wirtschaftsprüfung benötigt

3.5 Grundsatz der Flexibilität Die Mitgliederverwaltung muss sich jederzeit geänderten Anforderungen anpassen lassen.

Begründung: Wir wollen nicht alle paar Monate ein neues System einführen, nur weil das alte nicht an veränderte Anforderungen angepasst werden kann.

3.6 Grundsatz der Offenheit Daten müssen sich jederzeit in gängige Formate exportieren lassen. Daten müssen sich jederzeit aus gängigen Formaten importieren lassen. Beim Import müssen Dubletten automatisch erkannt und dem Importierenden zur Entscheidung vorgelegt werden.

Begründung: Nicht alles kann oder soll mit der Mitgliederverwaltung erledigt werden. Damit für anderen Programme keine eigenen Datenbestände aufgebaut werden müssen (Konsistenzprobleme, Arbeit...), müssen sich die Daten in andere Systeme übernehmen lassen.

3.7 Grundsatz der Datensicherheit Unautorisierter Zugriff auf die Daten muss verhindert werden. (Der Vollständigkeit halber: Datensicherung ist vorzusehen.)

Begründung: Ergibt sich aus dem Datenschutz.

3.8 Grundsatz der Bedienerfreundlichkeit - komplette Tastaturbediebarkeit - frei definierbare Filterstatements (Mehrere Filterbedingungen verknüpfbar mit UND und/oder ODER - vielleicht gleich SQL-Syntax, sofern Sicherheitsrisiken sicher ausgeschlossen werden können.) - Jeder Benutzer muss solche Filterstatements abspeichern können, damit er sie nicht jedesmal neu formulieren muss

Begründung: Diejenigen, die solche Verwaltungsaufgaben schon freiwillig machen, sollen es wenigstens einfach haben.

3.9 Grundsatz der Nachvollziehbarkeit Bei jeder Änderung am Datenbestand muss mitprotokolliert werden, wann wer welche Aktion durchgeführt hat

Begründung: Wenn irgendetwas nicht stimmt, dann muss feststellbar sein, warum das so ist.

Diskussionspunkte

Self Service

4.1.1 Wollen wir Self Service? Wenn ja, wollen wir das gleich? <JMS>Self-Service (via Updates) in 2. Phase</JMS> <MKU1> Self Service ist bei einer dynamischen Organisation ziemlich unabdingbar. Ansonsten müssten wir die Verantwortung für die korrekte Erfassung den Schatzmeistern und Generalsekretären übertragen. Ds bedeutet, für jeden LV oder KV andere Kommunikationswege. Die durch Self Service gemachten Änderungen sollten aber den zuständigen (Schatzmeister, ...) nach deren Erfassung zur Genhmigung vorgelegt (Workflow) werden um groben Unfug zu vermeiden.</MKU1> <AL>Ich nicht. GenSek II : "Self service" ist für mich ein totaler Ablehnungsgrund. Ansonsten Kompromiss siehe oben</AL>

4.1.2 Welche Sicherheitsanforderungen wären da zu stellen? <JMS>Sehr hohe, also kein direkter Dialog des Users mit der MV</JMS> <MKU1> - Login und SelfService via HTTPS. - Bestätigung oder Ablehnung der Änderung durch den zuständigen Mitgliederverantwortlichen </MKU1> <AL>Komplette Trennung und Schnittstelle über Import.</AL> <JMS>Dabei muß der Datenbestand der MV allerdings strikt "offline" gehalten werden, darf also dem Webserver nicht bekannt sein. Aus Sicherheitsgründen lehne ich eine online-MV strikt ab.</JMS>

Definition von Items

Items müssen sich jederzeit hinzufügen lassen. <JMS>Ja, aber nur durch Admins und wenn dann für alle.</JMS>

4.2.1 Ist es erforderlich, dass sich Teilgliederungen eigene Items definieren können? (Wenn - nur als Beispiel - der Kreisverband Garmisch-Partenkirchen der Ansicht ist, unbedingt die Schuhgröße seiner Mitglieder in der Datenbank zu speichern, dann bräuchte er dafür ein eigenes Item. Da gibt es prinzipiell folgende Möglichkeiten: a) Jede Untergliederung muss eigene Items definieren können -> Aufwand -> teuer b) Es gibt nur gemeinsame Items für alle -> Schuhgröße für Garmisch-Partenkirchen gibt's nicht oder alle haben das in ihrer Eingabemaske c) Es gibt ein paar Universalitems für Untergliederungen, und die entscheiden selbst, was sie da rein schreiben. -> Keine Datenplausibilisierung möglich und die Beschriftung der Items ist nicht sprechend)

<JMS>Für die MV: dagegen, Grund: Datensparsamkeit. Für ein Online-Piraten-Verzeichnis (LDAP): gerne aber alles nur auf freiwilliger Basis.</JMS> <MKU1>Ist das in der ersten Version tatsächlich notwendig? Mir sind jetzt die Anwendungsfälle (im Kontext der MV) nicht ganz klar - meine Schuhgröße ist 45!

 <ME>Schuhgröße werden wir auch wohl nie brauchen. Es können während des Betriebs jedoch Anforderungen hinzukommen, 
 die wichtig oder sogar gesetzlich vorgeschrieben werden. Dann brauchen wir die Flexibilität.</ME>

</MKU1> <BS>keine Items, zu viel Aufwand</BS> <AL>Solche inhaltlichen Items sollen nicht sein, Datensparsamkeit §3a BDSG. Nur abgeleitete Items oder Verwaltungsitems.</AL> <AL>Ein Landesverband wünscht sich Verwaltungsitems zur Erfassung von ernannten Funktionen, nach denen gefiltert werden kann: z.B. IT-Beauftragte, Pressesprecher etc.</AL>

Webinterface / Betriebssystem

4.3.1 Wollen wir mit dem Browser arbeiten oder mit lokal ausgeführter Software? <JMS>Ich bin für eine zentral vorgehaltene Anwendung (ob per Browser oder Terminal-Server ist mir dabei gleich), da dies deutlich einfacher zu warten ist.</JMS> <MKU1> die Browserlösung ist deutlich kosteneffizienter und deutlich uneverseller (Browser gibt es auch unter MacOS und Unix). Fat Clients sind i.d.R. nur unter Windows verfügbar (Emulatoren sind doch ein wenig unkomfortabel)</MKU1> <BS>tja, da scheiden sich die Geister...ich wäre für browser</BS> <AL>Hat beides Vor- und Nachteile. Browser ist flexibler.</AL>

4.3.2 Wenn wir mit lokal ausgeführter Software arbeiten, welche Betriebssysteme verwenden wir? <JMS>Mindestens: Windows, Linux, BSD, MacOS</JMS> <MKU1> Da werden wir wohl auf den Anbieter angewiesen sein. Nachteil dieser Lsg. Ist m.E. nach die Problemtik bei SW-Updates. Wenn es aber eine vernünftige Lösung auf der Basis von z.B. JAVA START (Fat Client mit automatisiertem Update) gibt, spricht nicht mehr viel dagegen</MKU1> <BS>ein parteirechner wäre hilfreich</BS> <AL>Das ist ein Argument gegen lokale Software. Deswegen Browser.</AL>

4.3.3 Ist es erforderlich, parteieigene Rechner zu verwenden, die dann bei einer Neubesetzung von Ämtern weitergegeben werden? <JMS>alternative: vorkonfigurierte Live-CD

 <ME>Die Frage geht eher nach den Daten, die da drauf sind. Die verbleiben nämlich derzeit bei 
 Personen, die kein Amt mehr haben, ggf. nicht mal mehr in der Partei sind.</ME>

</JMS> <MKU1> Um Gottes willen! Wollen wir auch noch ein Assetmanagement zur Verwaltung der parteieigenen Hardware und deren Verbleib aufbauen?</MKU1> <BS>es spricvht viel für parteieigene Rechner - ich wäre dafür....</BS> <AL>Schön, aber wer bezahlt das.</AL>

Einladung per eMail

Die Bundessatzung sieht in § 9b (2) vor, dass Mitglieder, die den Eingang einer Vorab-eMail-Einladung bestätigt haben, nicht per Brief oder Fax geladen werden müssen.

4.4.1 Muss die Mitgliederverwaltung dieses Verfahren abbilden können (beispielsweise mit Bestätigungslink auf der Einladungs-eMail)? <JMS>Die Bestätigung selber sollte auf dem Webserver erfolgen. Die MV kann von diesem dann am Stichtag eine Liste erhalten/importieren, welche User die Einladung bestätigt haben.</JMS> <MKU1> erscheint mir auf jeden Fall hilfreich. Hier ist aber auch wieder die SelfService Frage zu stellen.</MKU1>

4.4.2 Wenn ja, brauchen wir das gleich, oder können wir uns da zwischenzeitlich über die Importfunktion behelfen? <MKU1> Aus welchem System sollen denn die Daten dafür kommen. Wollen wir für jeden BPT oder LPT eine eigene Website zur Bestätigung der ausgesandten eMails einrichten? Nur um anschließend die Daten wieder von Hand in die MV zu importieren?</MKU1> <BS>kein muss für den Start</BS> <AL>Die Landesverbände haben andere Regeln. Ich sehe da keinen Bedarf. Die BundesGenSek mag das anders sehen.

 <ME>Manche LV haben gleiche Regelung oder streben sie an.</ME>

</AL>

Sicherheit der Accounts und der Daten

<MKU1> K 4.5.0 Wie soll ein Rollenkonzept für die MV aussehen? Es werden generische Rollen benötigt (Bundesschatzmeister, Verwaltung, Mitglied, ...). Hinzu kommen spezifische Rollen aufgrund der hierarchischen Organisationsstruktur. Sprich der Schatzmeister muss die Möglichkeit haben, für Teilgliederungen (Landesverbände) die jeweiligen lokalen Schatzmeister zu benennen. Diese wiederum müssen ggf. die Schatzmeister weiterer untergeordneter Gliederungen bennnen können. Hinzu muss eine Delegationsmöglichkeit kommen. Das bedeutet das eine Schatzmeister mehrere Bevollmächtige bennen können muss, um seine eigenen Aufgaben zu delegieren. Anmerkung: Letzteres wird sowieso passieren! Wenn wir kein entsprechendes Delegationskonzept vorsehen werden einfach die Accounts weitergegeben und dann ist jede Nachvollziehbarkeit dahin.

 <JMS>Die Rolle Mitglied benötigen wir nicht, da Mitglieder 
 keinen direkten Zugriff auf die MV haben sollen. Helfer 
 von $Amt sollte als weitere Rolle dazukommen.</JMS>

</MKU1>

4.5.1 Reicht ein Login mit Benutzernamen und Passwort? <JMS>nein.</JMS> <MKU1> Wenn eine entsprechende Policy zur regelmäßigen Aktualisierung (Password Renew) und eine Anbindung via HTTPS vorgesehen ist, sollte das fürs erste genügen.

 <JMS>Die Regeln zum häufigen Passwortwechsel verringern 
 meistens die Sicherheit leider, da Nutzer dann dazu 
 übergehen die Passwörter auf Zetteln/Dateien aufzuschreiben. 
 Lieber ein sicheres, langes Passwort einfordern und dieses 
 dann aber über die ganze Amtszeit gültig sein lassen (Der 
 Nutzer kann es auf Wunsch natürlich selber abändern).</JMS>

</MKU1> <BS>ja</BS> <AL>Nein.</AL>

4.5.2 Sollen Transaktionsnummern verwendet werden? (Wobei ich dann vorschlagen würde, dass nur eine TAN-Eingabe für eine komplette Datenbanksitzung erforderlich sein soll) <JMS>dafür.</JMS> <MKU1> ausgesprochen unkomfortabel! Und erst recht die Reduktion auf eine Datenbanksitzung - btw. I.d.R. nutzen Application Server nur eine begrenzte Anzahl an DB Connections (Pooling) und verwenden diese für die unterschiedlichen Anwenderanfragen. Das heißt eine Begrenzung auf DB Sitzungen wird recht komplex ;-}

 <JMS>Ich glaube mit der DB-Sitzung war eine Login-Session gemeint. In der   Kombination halte ich das für prakmatisch.</JMS>

</MKU1> <BS>ich wäre als schatzmeister dagegen, ich kann nicht verschiedenste TANs administrieren</BS> <AL>Zu kompliziert. Ein Zertifikat sollte nicht das grosse Problem sein, wenn sich jemand findet, der die VPN-Software für die gängigen Betriebssysteme paketiert.</AL> <AL>4.5.2 Ein (weiterer) Landesverband hält das aktuelle VPN-Verfahren für geeignet, allerdings muss dann zugesichert sein, dass ein Team beim BV oder besser der LV selbst die Zugänge für Untergliederungen erstellt. Keine Ahnung ob letzteres technisch geht, vom LV signierte Zertifikate?</AL>

4.5.3 Müssen die Daten in der Datenbank verschlüsselt werden? (Dann sind die Daten sicherer und wenn etwas nicht funktioniert die Probleme größer) <JMS>Suchanfragen und hohe gliederungen praktisch einen Master-key benötigen. Die Verschlüsselung mit verschiedenen Nutzersichten wird sehr schnell sehr komplex.</JMS> <MKU1> Die Anmerkung ist völlig korrekt. Unter dem Gesichtspunkt Verfügbarkeit und Verlässlichkeit ist diese Maßnahme abzulehnen. Eine sichere Anbindung des DB Servers sollte über streng definierte Schnittstellen erfolgen. Mit dem richtigen Account könnten die verschlüsselten Daten auf dem Server sowieso eingesehen werden. Die Kommunikation zu den Application Server sollte allerdings je nach Serverkonfiguration verschlüsselt erfolgen. (Wenn DB und App Server auf einer Maschine via named pipes laufen ist die Verschlüsselung der Kommunkation zwischen den beiden allerdings ziemlich wertfrei).

Wenn wir aber soweit gehen würden und jede Zugriffsbeschränkung sowohl auf den Application- als auch auf dem Datenbankserver zu implementieren haben wir doppelte Arbeit, Kosten, Ärger, ..</MKU1> <BS>habe ich keine Meinung</BS> <AL>Ich finde ja, aber das Argument von jamasi ist auch plausibel. Die Frage ist, ob es da einen Kompromiss gibt, also eine DB, die mit einem einfachen Verfahren verschlüsselt. Das würde dann eine Attacke eines GenSeks zusammen mit einem Admin nicht verhindern, aber trotzdem etwas sicherer sein.</AL>

Schreibrechte

4.6.1 Wer soll einen Datensatz bearbeiten dürfen? (Ich schlage vor: alle zuständigen Gliederungen) <JMS>check.</JMS> <MKU1>Also der jeweils zuständige Schatzmeister des LV oder KV?

 <ME>Oder auch der GenSek oder ein Mitarbeiter der Geschäftsstelle.</ME>

</MKU1> <BS>na ja, insbesondere nur "Amts-Piraten" (GenSek, Schatzmeister)

 <ME>Für die Gliederung handeln Mitgliederversammlung und Vorstand, und die entscheiden...</ME>

</BS> <AL>4.6.1 Ein (weiterer) Landesverband möchte die Verwantwortung beim jeweiligen zuständigen Vorstand sehen, u.a. weil es keinen designierten GenSek gibt.</AL>

4.6.2 Wie wird der Umzug eines Mitglieds abgewickelt? (Ich schlage vor: eine der bisherigen zuständigen Gliederungen nimmt die Änderung vor) <JMS>Vorschlag: die jeweils übergeordnete Gliederung (bei LV-Wechsel also der Bund, bei Umzug innerhalb des LV der LV, bei Umzug im Kreis der Kreis, ...) nimmt den Umzug vor, da diese die Rechte dafür hat.

 <ME>Das wäre eine Teilmenge meines Vorschlags. Wenn jedoch jemand seinen Umzug innerhalb seines LV an die BGS oder seinen alten KV meldet, 
 warum sollten die das dann nicht gleich selbst eintragen, statt dem LV zu melden?</ME>

</JMS> <MKU1> Die aufnehmende Gliederung startet den Prozess und die die abgebende Gliederung muss dem zustimmen. Im Konfliktfall Eskalation zum BV. Gesteuert werden kann dies durch einen Workflow Prozess der im besten Fall mit der Änderung der Daten durch das Mitglied beginnt.</MKU1> <BS>ja, die abgebene Teilgliederung meldet der neuen und ändert die Daten</BS> <AL>Das bisherige Verfahren scheint mir vernünftig. Die abgehende Gliederung gibt an die neue ab, und die neue pflegt die neuen Daten ein.</AL>

4.6.3 Wer kann das Änderungslog einsehen? (Ich schlage vor: Die erweiterten zuständigen Gliederungen) <JMS>check.</JMS> <MKU1> Das Mitglied; der zuständige Schatzmeister, der Bundesschatzmeister

 <ME>Oder auch der GenSek oder ein Mitarbeiter der Geschäftsstelle.</ME>

</MKU1> <BS>ja</BS> <AL>4.6.3 Ein (weiterer) Landesverband möchte zwingend den GenSek bzw. den Funktionsträger "Mitgliederverwaltung" dabeihaben.

 <ME>Würde mein Vorschlag beinhalten</ME>

</AL>

Umfang der Offenheit

Wenn das System ermöglicht, in großem Umfang zu exportieren, dann ist zu befürchten, dass Daten in großem Umfang auf Privatrechner wandern.

4.7.1 Lieber ein offenes System, oder lieber ein sehr restriktives System mit der dann folgenden Anforderung, dass die Mitgliederverwaltung flexibler sein muss, um alle nötigen Aufgaben intern abzudecken?

4.7.2 Sind wir uns einig, dass hier "Datenschutz per Betriebsanweisung: keine Parteidaten auf private Rechner" in der Praxis nicht funktionieren wird?

Zugriff von Nichtgliederungen

4.8.1 Wie kommen Schiedsgerichte an benötigte Daten der MV? (Auskunftspflicht des GenSek?) <AL>Ein (weiterer) Landesverband sieht die Lösung via Auskunftspflicht des GenSek, nötigenfalls durch Aufforderung durch den Vorstand oder Vorstandsbeschluss. </AL>

4.8.2 Wie kommen AGs an benötigte Daten der MV ? (Zum Beispiel die AGs, die nur Mitglieder offenstehen.) <AL>4.8.2 Mehrere LV: AG sollen keinen Zugriff auf die MV haben, sondern sich über Mailinglisten etc. selbst organisieren. Notfalls sollen sie den GenSek bitten.</AL>

Speicherung von Interessentendaten

4.9.1 Sollten Interessentendaten zur Kontaktpflege innerhalb der MV gespeichert werden?

4.9.2 Sollten Interessentendaten für Spenderlisten innerhalb der MV gespeichert werden?

Authentifizierungssystem

4.10.1 Besteht die Anforderung an ein gemeinsames Authentifizierungssystem?

4.10.2 Wenn ja, soll der Zugang zu der Mitgliederverwaltung damit geregelt werden?

4.10.3 Wenn ja, soll die Mitgliederverwaltung dafür Daten liefern?

Verpflichtende Veröffentlichung der Kontaktdaten von Funktionsträgern

Müssen Funktionsträger ihre Kontaktdaten, insbesondere auch Telefon, zwingend bekannt geben und zumindest den zuständigen Gliederungen bekannt geben?

Bitte bei der Diskussion auch folgende Szenarien berücksichtigen:

4.11.1 Ein Radiosender ruft an und braucht kurzfristig einen Interviewpartner in Kleinkleckersdorf.

4.11.2 Die Polizei ruft an, weil ein Wahlplakat falsch hängt und droht ein Ordnungswidrigkeitsverfahren an, wenn das nicht ganz flugs verschwindet.

4.11.3 Auf einer Webseite eines Gebietsverbandes steht etwas, was da ganz schnell runter muss (und sei es, weil wir bereits eine einstweilige Verfügung kassiert haben).

<AL>4.11 Ich bin der Meinung, dass die klassischen Wege ausreichen müssen. Gibt es faktisch Präzedenzfälle für die genannten Szenarien? (Und nicht, es hätte fast...)

 <ME>4.11.1 und 4.11.2 habe ich in der BGS schon erlebt, 
 und ich bin da erst seit Anfang November...</ME>

Wir sind nicht die Erhebungsgehilfen eines Obrigkeitsstaates. Wir sind die Partei der Eigenverantwortung. Wenn es wegen einer solchen Sache ein Ordnungsgeld gibt, und der Verantwortliche das aufgrund einer fehlenden Telefonnummer oder nicht-beantworteten email wesentlich zu verantworten hat, dann bezahlt ER das Ordnungsgeld. Fertig.</AL>

Vorschlag für die Veröffentlichungsregeln

Die Regeln für die Veröffentlichung der Daten sollten nachträglich anpassbar sein. Damit wir schon mal eine Vorstellung davon bekommen, über was wir da reden, mache ich mal einen Erstvorschlag für die Veröffentlichungsregeln.

<AL>Mit der nachträglichen Änderung der Veröffentlichungsregeln, auch durch den Bundesparteitag, habe ich in dieser Allgemeinheit ein Problem.

Ich finde es nicht in Ordnung, wenn wir einerseits eine informationelle Selbstbestimmung vortäuschen, an die wir uns nachher aber "implizit" oder wegen "gesetzlicher Vorgaben" oder wegen BPT-Beschluss dann nicht halten.

Der BPT könnte ja auch beschliessen, dass aus Transparenzgründen jeder alle Daten sehen darf. Das geht mal garnicht. (Beispiel: Satzungsänderung S4 in Niedersachsen. Sehr kontrovers.)

Und wieder einmal. Wir sind nicht die Erhebungsgehilfen eines Obrigkeitsstaates. Wenn der Bundestag morgen beschlösse, wegen der NPD natürlich, dass alle Parteien, die an der Parteienfinanzierung teilnehmen wollen, monatlich eine komplette Mitgliederliste an den Verfassungsschutz elektronisch übermitteln müssen, dann hoffe ich doch, dass wir uns dem zunächst widersetzen, und im Zweifel die Finanzierung auch riskieren.</AL>

Bitte immer daran denken: Veröffentlichung heisst hier: innerhalb unserer Mitgliederverwaltung.

5.1 Kontaktdaten Die Angabe dieser Daten ist freiwillig, es werden jedoch für Mitglieder mit Funktionen (Vorstände, Schiedsgericht, Kassenprüfer...) verpflichtende Kontaktdaten (mindestens eMail und Telefon) festgelegt. Bei jedem einzelnen Item kann angegeben werden, ob es sich um "Kontaktdaten allgemein" oder "Kontaktdaten intern" handelt. <BS>Adresse nebst Email; kein Telefon. Vorstände müssen und können sich selbst die Daten tauschen

 <ME>Auf derselben Ebene mag das funktionieren. Wenn 
 aber beispielsweise der Bundesschatzmeister sich ganz   dringend den Schatzmeister vom KV Erding greifen muss, 
 dann funktioniert das nur mit System.</ME>

</BS>

5.2 Informationsdaten Die Angaben dieser Daten ist freiwillig. <JMS>würde ich komplett aus der MV rauslassen und stattdessen über einen online-Verzeichnisdienst abbilden, den Mitglieder freiwillig (und pseudonym) nutzen können.

 <ME>Soll dort dann auch spezifiziert werden können, welche Gliederungen diese Informationen einsehen können? Und wenn ja, wie würde man das dort realisieren?</ME>

</JMS> <BS>brauchen wir nicht</BS>

5.3 Veröffentlichungsregeln Jedes Mitglied kann die Sichtbarkeit seiner Datengruppen "Minimaldaten", "Kontaktdaten allgemein", "Kontaktdaten intern" und "Informationsdaten" festlegen. Für die Sichtbarkeit gibt es folgende Gruppen: - Ortsverband - Kreisverband - Bezirksverband - Landesverband - Bundesverband - alle Ortsverbände des Kreisverbandes - alle Orts- und Kreisverbände des Bezirksverbandes - alle Orts-, Kreis- und Bezirksverbände des Landesverbandes - alle Benutzer <JMS>check. bitte für jeden Dateneintrag einzeln

 <ME>Hat sicher Vorteile, ist aber in der Konfiguration aufwendig...</ME>

</JMS> <AL>Ist die Gruppe Bundes-/Landesgeschäftsstelle gleichbedeutend mit Bundes-GenSek/Landes-GenSek? Ich würde das unterscheiden. Oder warum nicht?

Die aufwendige Konfiguration für "per Item" müsste man dann hinnehmen, wenn man das Gruppenkonzept so wollte.</AL>

5.4 Obligatorische Veröffentlichung

Manche Daten müssen obligatorisch veröffentlicht werden

5.4.1 Minimaldaten Die zuständigen Gliederungen können bei allen Mitgliedern auf die Minimaldaten zugreifen

5.4.2 Funktionsträger

5.4.2.1 Die allgemeinen Kontaktdaten sind zumindest allen zuständigen Gliederungen zu veröffentlichen

<AL>Vielleicht so:

2.4.2 Kontaktdaten allgemein Daten, über die Minimaldaten hinaus, die das Mitglied freiwillig angibt, damit sie den zuständigen Gliederungen zur zweckgebundenen parteiinternen Nutzung zur Verfügung stehen.

2.4.3 Kontaktdaten intern Daten, über die Minimaldaten hinaus, die das Mitglied freiwillig einer beschränkten Nutzergruppe (z.B. Bundesgeschäftsstelle, Kreisverband) zur Nutzung zur Verfügung stellt.</AL>

5.4.2.2 Die internen Kontaktdaten sind zumindest allen übergeordneten Gliederungen zu veröffentlichen

(Begründung für diese Veröffentlichungspflicht der Kontaktdaten von Funktionsträgern: Wenn irgendwo ein Wahlplakat falsch hängt, ein Anruf in die BGS kommt von wegen "das ist innerhalb von 24 Stunden weg oder wir leiten ein Ordnungswidrigkeitsverfahren ein", dann will ich weder lang recherchieren müssen, ob und wenn ja, welche Kontaktdaten im Wiki stehen, noch möchte ich dann eine eMail irgendwo in schreiben, auf die tagelang nicht reagiert wird.)

<AL>Das geht nicht. Wenn ich dem Ortsverband eine Handynummer offenlege, dann heisst das nicht, dass auch der Bundesverband die sehen soll.</AL>

<AL>Das Parteiengesetz schreibt meines Wissens nicht vor, dass wir die Geburtsdaten unsere Mitglieder per Postident oder notarisierter Ausweiskopie verifizieren. Wenn wir sowas einführen sollten, trete ich zurück und aus der Partei aus.

Lange Rede kurzer Sinn. Wir sollten als Generalsekretäre darauf achten, dass diese Daten angegeben werden und sie nach gesundem Menschenverstand substantieren, weil sie vieles vereinfachen.

Wir sollten aber nicht die Eintragung eines Mitglieds in die MV technisch verwehren, wenn ein Feld - aus welchen Gründen auch immer - nicht gefüllt werden kann. Es kommt z.B. auch vor, dass ich einen Antrag bekomme, wo die Strasse nicht lesbar ist. Dann trage ich alles ein, AUSSER der Strasse und frage die Strasse z.B. per email ab. Wenn ich die Antwort bekomme, trage ich das nach.

Wenn mir die Mitgliederverwaltung das verwehrt, dann greife ich eben zu ABC-Strasse oder 1.1.1900. Das finde ich schlimmer, weil dann das Fehlen nicht mehr sicher erkannt werden kann.

Mehr wollte ich nicht sagen. Minimaldaten als Policy, OK. Minimaldaten als technische Erfordernis, Nicht OK.

Und: Wir sind nicht die Erhebungsgehilfen eines Obrigkeitsstaates. Wir sind die Partei der Eigenverantwortung. Wenn jemand gesetzlich erforderliche Daten nicht angibt, dann muss ER mit den Folgen leben, z.B. dass es für ihn keine 0,85 Cent Parteienfinanzierung gibt, oder er keine Spendenbescheinigung bekommt, oder er kein Mandat erhalten kann.</AL>

Detailanforderungen

Anforderungen ergänzend zu den Grundanforderungen

6.1 Automatische Dublettensuche bei der Eingabe Wird ein Datensatz neu eingegeben (insbesondere bei Massendatenimport), dann wird automatisch geprüft, ob es bereits Datensätze mit Dublettenverdacht gibt. Diese Datensätze werden dann angezeigt, der eingebende Benutzer entscheidet. Bei dieser Anzeige sind die Sichtbarkeitsregeln zu berücksichtigen.

Begründung: Dubletten sorgen für viel Ärger, sie sollten nach Möglichkeit vermieden werden.

<AL>Damit ist die konkrete Anforderung aber nicht mehr klar. Wenn die Dublette im eigenen Sichtbarkeitsbereich ist, gibt es kein Problem. Ansonsten dürfte aus datenschutzrechtlichen nicht einmal die Tatsache als solche angezeigt werden. Eine Auflösung ist dann nur auf der übergeordneten Ebene möglich.

Dabei muss bei automatisierten Dateneingaben (Import) bei Dubletten in der eigenen Sichtbarkeit ein Update als Auflösung auswählbar sein.

In der Formulierung von Michael Küthe war von einem *geeigneten* Workflow die Rede. Die jetzige Formulierung gibt das nicht mehr her.

Begründung: Wenn bei 100 offline erfassten oder teilweise geänderten Datensätzen jedesmal der Mensch eingreifen muss, ist das nicht praktikabel.</AL>

6.2 Frei vergebbare Flags Alle Parteigliederungen können einfach Ja/Nein-Flags definieren, die sie dann frei ihren Mitgliedern zuordnen können.

Begründung: Mit solchen Flags erhöht man massiv die Flexibilität eines solchen Systems. Man kann sie beispielsweise für folgende Fragestellungen verwenden: - Wer ist bereits auf einem Parteitag akkreditiert? - Wem hat ein Schiedsgericht die Fähigkeit abgesprochen, Ämter zu bekleiden?

</JMS>teilweiser check, diese beiden Beispielsflags sollten besser global angelegt werden.

Grundsätzlich ist zu überlegen, daß neue flags immer erst diskutiert werden müssen, damit nicht z.B. in Ortsverband xy plötzlich ein "ist schwul"- oder "Troll"-Flag angelegt wird. (solche Flags ließen sich als Freitext-Felder mißbrauchen um fast jede Information über ein Mitglied zu speichern. Sowas wollen wir nicht und sollten es auch technisch unterbinden.</JMS> <MKU1> Sind das nicht Forderungen die auch global befriedigt werden können?</MKU1>

<AL>Flags nach Möglichkeit global anlegen und die Möglichkeit offenhalten, lokale Merkmale einzuführen, nötigenfalls mit Freischaltung?

Irgendwie vermisse ich die Liste mit den "globalen Flags/Items", die wir unbedingt brauchen, z.B. Beitrag bezahlt, Betrag der Ermässigung.

Das z.B. wurde mehrfach von verschiedenen Gliederungen angefordert.

Wollen wir da einfach die Liste aus dem CiviCRM übernehmen, oder wollen wir einfach fordern, dass unsere MV eine flexible Gestaltung haben muss. Das fände ich dann auch OK. Ich finde es gerade nicht.</AL>

Neue Vorschläge zur Diskussion

<MKU1> 7.1 Anbindung an LDAP. Die Authentifizierung und auch die Regsitrierung (siehe SelfService) sollte via LDAP möglich sein. Solange wir noch keinen eigenen LDAP Dienst haben sollte das System aber zudem noch über eine eigene Anwenderverwaltung verfügen.

 <JMS>Du möchtest doch hoffentlich nicht die MV-Daten 
 als LDAP-Tree in die web-welt herausblasen? In ein 
 öffentliches LDAP gehört aus meiner Sicht nur ein 
 einziges Datum der MV: der Mitgliedsstatus. Den Rest 
 hat der User selber auf freiwilliger Basis 
 einzupflegen.</JMS>

</MKU1>

<MKU1> 7.2 Skalierbarkeit Die MV sollte in der Lage sein, mit der Piratenpartei zu wachsen. Hierbei sind nicht nur die organisatorischen Änderungen zu berücksichtigen, sondern auch die Volumen und Performancegesichtspunkte. Hieraus ergibt sich Forderung nach einer Trennung von Datenbank und Applikationsserver. Die Applikationsserver sollten zudem noch untergliedert werden in einen Verwaltungs und einen SelfService Teil. Ob wir dann noch weitere Instanzen der Applikationsserver benötigen können wir bei Bedarf entscheiden. Wenn die Last weiter wächst sollte zudem die DB Engine ausgetauscht werden können. MySQL oder Postgress können am Anfang ausreichen. Bei Bedarf sollten aber auch andere DB Systeme zum Einsatz kommen können (Oracle, DB2).

 <JMS>Der self-service-teil darf keinen direkten Zugang 
 zur DB erhalten. Für den ist die MV als Praktisch 
 offline zu betrachten, wie für alles, wo normale User 
 mit dem System interagieren.</JMS>

</MKU>

<MKU1> 7.3 Hostbarkeit Die MV sollte bei einem der (relativ günstigen) Provider für dedizierte Server untergebracht werden können ohne gleich ein Sicherheitsdesaster oder einen Wartungsmoloch zu provozieren. Auf dieser Basis könnten dann auch entsprechende Schulungs- oder Entwicklungsinstanzen temporär aufgebaut werden.

 <JMS>Dagegen, die Daten sollten wir nicht aus der Hand 
 geben, also nur auf von uns selber betreuten Systemen 
 drauf haben. Test- und Schulungsinstallationen können 
 aber natürlich (mit fake-Daten) auch auf externe Server 
 drauf.</JMS>

</MKU1> <AL>Wenn der Admin kein Pirat ist, sollten wir über die Verschlüsselung der DB verschärft nachdenken.</AL>

<MKU1> 7.4 Online Backup Die DB Lösung und ggf. auch die Daten der AppServer sollten online zu sichern sein. Ein Ausfall der MV wegen Wartungsarbeiten auch zur Nachtzeit erscheint mir nicht mehr zeitgemäß.

 <JMS>Dafür haben wir in der Technik inzwischen
 MyLVMbackup im Einsatz, was eine DB-Downtime von 
 ca. 0-2 sek für einen DB-Dump braucht.</JMS>

</MKU1>

<MKU1> 7.5 Wartungsarmut Die neue MV sollte nur minimalen Administrationsaufwand erfordern. Fehler und Logs sollten bei Bedarf automatisiert an die zuständigen Admin gesandt werden. Es sollte kein Notwendigkeit geben regelmäßig die Logdateien zu scannen!

 <JMS>Dafür.</JMS>

</MKU>

<MKU1> 7.6 Kriterien zur Lieferantenauswahl - Wie oft wird die SW aktualisiert? - Wie hoch sind die jährlichen Wartungskosten? - Welche Zusatzkosten (Lizenzen HW, ...) kommen auf uns zu?

 <JMS>Ist das ganze mit der Parteiphilosophie gut vereinbar 
 (also bevorzugt OpenSource)?</JMS>

</MKU1> <AL>Open Source den Vorzug geben?</AL>

<AL> 7.7 Einbindung externer Nachschlagelisten Es fehlt die Möglichkeit der Einbindung von externen Datenmengen. Also z.B. die Liste aller Wahlkreise/Landkreise/PLZ-Ort usw. für Vorgabe bzw. Adressprüfung. Sowas sollte zumindest auf Bundes-/Landesebene möglich sein. </AL>