Eine der Sachen, die mich an dieser ganzen Luca App-Diskussion stören ist das immer wiederkehrende Argument

"Laß die doch einfach mal machen, Hauptsache es tut überhaupt mal jemand was in dieser Sache."

Also Software First, Bedenken Second.
Ich kann nicht einfach Software schreiben und dabei jedwede regulatorische und Compliance-Anforderung ignorieren.

Also, ich kann das, für mich daheim und privat, aber ich kann das nicht mal dann tun, wenn ich den Kram mit einer Soda-Lizenz auf Github tu.

Das ist normal.
Ich kann auch nicht Essen kochen oder Brot backen, ohne regulatorische und Compilance-Anforderungen zu erfüllen. Also, nicht für andere.

Ich muss zum Beispiel ein Gesundheitszeugnis haben, und darf keine aktiven ansteckenden Krankheiten haben. https://de.wikipedia.org/wiki/Mary_Mallon
Ausnahmen scheinen lediglich bei der fleischverarbeitenden Industrie in Deutschland zu bestehen.
Ich kann auch nicht für Andere Häuser bauen, darin Strom und Gas verlegen und viele andere Dinge, ohne eine Vielzahl von überwiegend sinnvollen Anforderungen aus dem Bereich Regulierung und Compliance zu erfüllen. Die dann im Genehmigungsprozess und der Abnahme geprüft werden.
Die Entwicklung von Software ist eine sehr junge Ingenieursdisziplin, aber es gibt eine große Anzahl von Anforderungen aus anderen, reiferen Prozeßdomänen, die in die Software-Entwicklung rein wirken.
Für Luca sind neben den funktionalen Anforderungen die Domänen Datenschutz und Urheberrecht auffällig geworden, aber ich nehme an, da kommen auch noch Wettbewerbsrecht und ein paar andere dazu.
Die funktionalen Anforderungen sind nicht wirklich diskutiert worden, geschweige denn in einen Prozeßkontext "Kontaktverfolgung" eingeordnet worden.

Man kann das tun.
"Als Kontaktverfolger im Gesundheitsamt habe ich den Fall einer seit dem 10. April als infiziert markierten Person zu bearbeiten. Ich möchte alle Kontakte seit dem 4. April dieser Person herausfinden können."
Das ist eine von vielen User Stories im Kontext Kontaktverfolgung.

Zusammen definieren sie einen Prozeß in einer behördlichen Organisation oder gar einen Prozeß über die Grenzen einer Einzelorganisation, wobei die Einzelorganisationen unterschiedliche Rechtsformen haben.
Luca App muß sich jetzt scopen, also ansagen, welche User Stories aus dem ganzen Prozeßboard für ihre Programmieraufgabe in scope sind und bearbeitet werden.

Prozesse, insbesondere solche, die über Organisationsgrenzen hinweg gehen, werden oft von Program Managers bearbeitet
Deren Aufgabe ist es, dafür zu sorgen, daß die einzelnen Projekte und ihre Produkte zusammenpassen und in der Lage sind, den gesamten Prozeß zeitgerecht und wiederholbar auszuführen.

Die Amis nennen diese Funktion in der Politik oft Czar.
Die Regierung der Bundesrepublik Deutschland hat keinen ausdrücklichen Corona-Czar benannt, also fällt die Zuständigkeit per Default an den amtierenden Gesundheitsminister.

Meh.

So sieht es dann auch aus.
Die einzelnen Organisationseinheiten packen sich die gescopten User Stories in ein oder mehrere Projekte. Ein Projekt hat einen Projektmanager, ein Deliverable und eine Deadline.

Das wäre dann so was wie "Luca App bis zum 15. April" oder so.
Und eine Definition of Done, das ist der Scope. Der ist mit dem Program Manager abgestimmt, wie auch die Deadlines. Der Rest ist auf Management-Ebene Excel-Gewichse, also Projektfortschritt reporten, Blocker und Project Risks benennen und Pläne B, C und D schmieden.
Datenschutz, Urheberrecht, Wettbewerbsrecht und so weiter sind non-functional requirements. Sie legen den regulartorischen Rahmen fest, in dem sich die User Stories und das Deliverable bewegen müssen.
Die kann man nicht ignorieren. Wenn man das tut ("Die Köchin muss gesund sein, und darf nicht die Kunden mit Typhus anstecken") sterben oft Leute, oder haben empfindliche Nachteile.
Jedes Software-Projekt hat einen Satz NFRs, die immer gleich sind. Dazu gehören simple Dinge wie externe Abhängigkeiten zu tracken und zu scannen und zu cachen.

Das ist notwendig, damit Builds reproduzierbar sind. Ohne so was kann man nicht über Software reden, ...
weil man konkrete Versionen der Software nicht bennen kann und so Fehler Versionen nicht zuordnen kann. Damit ist keine Qualitätssicherung möglich.

Ich muß also alle externen Bibliotheken lokal cachen und versionieren ("vendoren"), und genau so mit den eigenen Modulen umgehen.
Ich muß die externe Software auch prüfen, ob sie die funktionalen und nicht funktionalen Requirements erfüllt. Software kann dabei helfen (X-Ray, SonarQube und viele andere mehr können offensichtliche Programmierfehler in Software aufdecken).
Es existieren auch Softwarepakete, die die Lizenzbedingungen von externen Modulen verfolgt, und sagt, was man kaufen muss, was man umsonst, aber mit welchen Auflagen bekommt und welche Autoren verantwortlich sind. https://twitter.com/bagder/status/1379897937141063686
Macht man das nicht, handelt man sich einen "unabsichtlichen" Urheberrechtsverstoß ein.

Also, genau genommen fahrlässig, nicht unabsichtlich. Das ist ein wesentlicher Unterschied.
Speziell bei Luca war es jetzt so, daß bei der Erstveröffentlichung die Lizenzbedingungen und die Autorennamen aller externen Module entfernt worden waren.

Das heißt, die Module waren mit externen Modulen 1:1 identisch bis auf alle relevanten Urheberrechtshinweise.
Also, a) Vorsatz und b) Smudo als Copyrightmaximalist in den Urheberrechts-Debatten der letzten 20 Jahre.

Man kann sich da über leidenschaftliche Reaktionen in der öffentlichen Diskussion beschweren, aber das ignoriert zwei Dekaden Kontext. Vorsätzlich.
Die funktionalen Requirements der Luca App sind nicht öffentlich dokumentiert, aber sie involvieren offensichtlich die Erfassung, Verarbeitung und Speicherung der personenbezogenen Daten von Besuchern eines Veranstaltungsortes.
Wenn man weiter drüber nachdenkt bleibt genau genommen kaum was anderes. Die Luca App verarbeitet also kein PII, sie ist solide aus PII gemacht. Außer personenbezogenen Daten gibt es kaum weitere Primäreingaben in den Prozeß.
Wenn man NFRs Ernst nimmt ist ein Subprojekt und Deliverable mit allerhöchster Priorität also eine Absicherung der Verarbeitung nach GDPR und Datenschutz, sowie eine Datenschutz-Folgenabschätzung.
Also, ich meine, es bleibt ja kaum was anderes bei dieser Ausgangslage.

Das ist ein dickes Paket. Es muß die Rechtsgrundlage geklärt oder politisch geschaffen werden, es muß gezeigt werden, daß die Daten geeignet sind, den zu benennenden Zweck zu erfüllen (und dazu ...
... braucht es erst einmal einen Prozeß, der existiert und geeignet ist, den Zweck zu erfüllen, und dazu braucht es eine dokumentierte Prozeßdokumentation, und dazu braucht es einen Program Manager, der die zu verantworten hat...)
Dann muß gezeigt werden, daß die gefundene Lösung datensparsam oder gar -minimal ist.

Und dann braucht man Metriken, mit denen man den Prozeß in seiner Ausführung kontrollieren kann.
Wir haben davon... nix?

Es ist fast so als gäbe es einen Grund, daß das alles nicht funktioniert.
Die *anderen* Daten, also außer PII, die Luca App verarbeitet, sind die Daten von Veranstaltungen und Orten.

Das sind Definitionen von Cafes, Theatern und anderen Orten, an denen dauerhaft Begegnungen stattfinden und ...
von Feiern, Konzerten und anderen Orten, an denen einmalig Begegnungen stattfinden.

Es gibt funktionale Requirements an solche Orte, zum Beispiel daß sie segmentiert werden müßten, damit sie zur Kontaktverfolgung tauglich sind, wenn sie eine gewisse Größe überschreiten.
Und es gibt non-funktionale Requirements an solche Orte.

Zum Beispiel wäre es ja als Forderung legitim, daß die Belegung eines Ortes nicht öffentlich einsehbar ist, zu Marketingzwecken an die Konkurrenz weiter verkauft wird und so weiter.
Ich wollte hier den Graph der Belegung des Zoos in Osnabrück zeigen, habe aber gerade den Tweet nicht zur Hand.
Ich bin an der Softwareentwicklung der Luca App nicht beteiligt und ich bin auch mit der Prozeßentwicklung in der Kontaktverfolgung nicht betraut.

Ich bin aber unmittelbar in Prozesse der Softwareentwicklung bei meinem Arbeitgeber eingebunden,...
... und ich arbeite in diesem Umfeld seit 1983, und beobachte die Entwicklung von "Practice" seit nun fast 40 Jahren.

Von wo ich sitze (und das ist ein wenig weiter weg, siehe oben) bin ich nicht beeindruckt.
Also, es ist normal, daß die Prozeßreife in jungen Organisationen und kleinen Startups oft Defizite hat.

Aber von wo ich sitze sieht das nach einer Kombination von Fahrlässigkeit und Vorsatz aus, die mich nicht ermutigt, diesem Produkt meine Daten anzuvertrauen.
Schlimmer noch, wir sehen auch Defizite bei der Auftragsvergabe, denn auch bei gebotener Eile im Projekt gibt es eine minimale Due Diligence, die unversichtbar ist und dokumentiert werden muß.

Das ist nicht passiert.
Nun kann man eine Regierung nicht wie das Management in einem Betrieb führen - Ziele und rechtlicher Rahmen sind zu verschieden.

Aber man kann eine Menge Practice aus gutem Management anschauen, verstehen und anpassen.
Und was wir hier sehen ist nicht nur die Luca App, die die gesteckten Ziele nicht erfüllen kann, weil sie unter anderem unzureichend definiert sind.

Sondern auch den Prozeß, dessen Bestandteil die App sein soll, der dysfunktional und parteill undefiniert ist.
Das ist aber genau die Aufgabe eines Staates und seiner Organe, zu denen auch Behörden wie die Gesundheitsämter und deren Ministerium gehören.
Und das braucht nicht nur eine rechtliche, sondern auch eine politische Aufarbeitung.
Thread muted.

https://freiheitsrechte.org/mitmachen/ 
Meine SoundCloud ist die Gesellschaft für Freiheitsrechte.

Gebt den Grundgesetz Ultras all Eure Unterstützung
You can follow @isotopp.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.