Die Thesis ist nach langem feilen und schleifen endlich fertig und wartet geduldig auf ihre Einreichung. Dazu fehlen aber noch die beiden Begleitdokumente, eine achtseitige Zusammenfassung und eine ca. 20-seitige PPT, die mit der Thesis abgegeben werden müssen. Diese versuche ich jetzt nebenbei noch fertigzustellen um alle digitalen Dokumente dann vor Ende April einzureichen.

Die letzten Wochenenden sind komplett von Formatierungsarbeiten und kleinen Anpassungen, Umformulierungen, etc. vereinnahmt worden. Eine nicht zu unterschätzende Arbeit wenn man entsprechend viele Grafiken, Tabellen etc. im Text hat. Alle Figures müssen manuell im Text upgedated werden (das macht Word nicht eigenständig mit cross-referenzen), die Liste der Abkürzungen muss zusammengestellt werden, und vieles mehr.

 

Umso besser fühlt man sich wenn´s endlich geschafft ist. Ich freu mich auf den Tag wenn´s alles eingereicht ist. Wie gesagt, das soll spätestens am Dienstag, dem 30.04.2013 geschehen.

Advertisements

4 days intensive work on the thesis instead of celebrating easter. Nun ja, manchmal ist´s eben notwendig. In der Endphase der Arbeit bin ich nun mit der Beschreibung der Projekteinführung beschäftigt, schreibe die Conclusions und verfolge den roten Faden durch die Thesis um sicherzustellen, dass das Thema durchweg logisch durchgearbeitet ist und für den Leser entsprechend dargestellt wird. Zudem kommen die zahlreichen Formatierungsarbeiten (z.B. korrekte Darstellung aller Referenzen, Aktualisierung aller corss references für figures, tables und nummerierte Sektionen, usw.). Leider haben die 4 Tage wiederum noch nicht gereicht, sodass ich noch an den kommenden Nachmittagen und dem nächsten Wochenende damit beschäftigt sein werde. Man sollte den Aufwand des Niederschreibens eben nicht unterschätzen. Die ganzen Grafiken, die in dieser Thesis verarbeitet werden, die Tabellen und Statistiken die aus Daten erzeugt werden und einiges mehr haben ihr übriges dazu beigetragen. Aber das Ende ist absehbar – zum Glück 🙂

Dieses Wochenende habe ich mich weiter mit der Beschreibung der Anwendungen AzArchitect und AzFinance beschäftigt. Dabei gilt es sowohl die Funktionalität zumindest grundsätzlich zu erklären und aufzuzeigen, wie diese Lösungen den betreffenden öffentlichen Einrichtungen nützen können und sollen als auch hervorzuheben, wie die speziellen Umstände, die sich in den Befragungen in der Vorbereitung der Anwendungsentwicklung herauskristallisiert haben, programmatisch umgesetzt werden. Ein deutliches Beispiel ist z.B. die Nummerierung der Anträge in AzArchitekt. In der bestehenden analogen Buchhaltung werden die Anträge wie folgt nummeriert “Anfagnsbuchstabe des Nachnamen des Antragsstellers” – “Nummer der Antrags in der Buchstabenkategorie”/”Anzahl der Anträge von diesem Antragssteller”, also z.B. K-58/2, was bedeutet, dass der Nachname des Antragsstellers mit K beginnt, es in der Kategorie K der 58ste Antrag (im Archiv) ist und es der zweite Antrag des Antragsstellers ist.

Diese Nummerierungsmethode hat ihren Ursprung in der analogen Buchhaltung und dient der Auffindung des Antrags bei Bedarf. Mit AzArchitect ist eine solche Prozedur unnötig, da es einen Antragsfinder gibt, der Anträge schnell und einfach anhand einer Vielzahl an Attributen findet. Dennoch wurde AzArchitect so umgesetzt, dass die Antragsnummern nach dem alten Schema und automatisch nummeriert werden um den Nutzern die gewohnten Antragsnummern zur Verfügung zu stellen, unabhängig davon ob es systematisch notwendig ist. Die Berechnung dieser Antragsnummer stellt einen gewissen programmatischen Aufwand dar, der aber mit dem höheren Potenzial der Nutzerakzeptanz gerechtfertigt ist.

Solche und andere Erwägungen in der Anwendungsentwicklung werden in diesem Zusammenhang erläutert.

Nach der Analyse der Anforderungen an die beiden Softwarelösungen stand die Entwicklung an. In diesem Kapitel beschreibe ich wie ich die Arbeitsprozesse bzw. den Informationflow in der jeweiligen Softwarelösung abzubilden versuche. Grundsätzlich hatte ich entschieden die beiden Softwarelösungen als Python Plugins für QGIS zu schreiben und PostgreSQL mit PostGIS als DBMS zu nutzen.

Der allererste Schritt ist allerdings die Umwandlung der bestehenden Katasterdaten, bzw. des dafür bestehenden Templates, in eine Postgres Datenbank, die ich dann um jeweils ein Schema für das Architektenbüro und die Steuerabteilung erweitern kann. Dafür haben wir glücklicherweise in der Firma FME zur Verfügung.

Danach habe ich mir Gedanken zum Aufbau der beiden Lösungen (AzArchitect & AzFinance) gemacht. In AzArchitect habe ich ein User-management integriert, in dem jeder Mitarbeiter des Departments erfasst werden wird und die ihm/ihr zugeordneten Anträge einsehen und bearbeiten kann. Dabei wird vorläufig lediglich feastgehalten bei wem welcher Antrag liegt und was dessen Status ist. Auf diese Weise wird für AzArchitect ein digitales Archiv geschaffen, das um gewisse Funktionen erweitert ist und neue Möglichkeiten eröffnet. Die GIS Komponenten sind vorerst auf simple räumliche queries beschränkt, so wird z.B. bei einem Antrag auf Baumaßnahmen geprüft, ob die dafür vorgesehene Fläche die registrierten Altlastenflächen schneidet. Ist dies der Fall, wird eine entsprechende Warnung ausgegeben. Weiter werden Katasterausschnitte erzeugt und eine vielzahl an Kartenansichten ermöglicht den Benutzern die Einsicht in die räumliche Verteilung von gewissen Phänomenen.

Etwas anders wird das für AzFinance aussehen. Hier werden die einfachen Arbeitsprozesse des Registrierens und Verwaltens von Pachtverträgen und Grund- und Eingentumssteuerobjekten integriert. Auch hier ist bereits mit verschiedenen “Views” viel erreicht (z.B. eine farbliche Kartenübersicht der bestehenden Steuerschulden). Ein Beispiel der unterschiedlichen Einfärbungen in AzFinance ist hier abgebildet:

AzFinance_view_bys

View map by 1) Tax/Lease Object, 2) Tax Balance, 3) Tax Zone / Tax Inspector, 4) Object type

 

Die detailliertere Planung der beiden Softwareprodukte anhand von Anforderungsanalysen habe ich dieses Wochenende weiter vorwärts bringen können. Die Softwarelösungen müssen demnach in erster Linie die Natzbarmachung der Katasterdaten gewährleisten und dann die interne Datenverwaltung unterstützen ohne die Prozesse zu detailliert abzubilden um Problemen mit bisher nicht erwähnten Ausnahmen von Standardprozessen vorzubeugen und allgemein der Divergenz zwischen theoretischer und praktischer Durchführung Rechnung zu tragen. Die Programme müssen sich daher stark an existierenden Prozessen orientieren und sollten zu diesem Zeitpunkt so wenig wie möglich Veränderungen einbringen um die skeptische Haltung vieler künftiger Benutzer nicht in eine Ablehnung des Produktes umschlagen zu lassen. Komplexe GIS Analysen sind vorerst nicht in den Vordergrund zu stellen. User management und geschützte Datenverwaltung haben momentan Vorrang.

Endlich wieder ein Wochenende an dem ich mich voll der Thesis widmen kann. Die letzten 2 sind, zumindest teilweise arbeitsbedingt und krankheitsbedingt ausgefallen.

Jetzt habe ich mich der Requirement Analysis gewidmet. In der Analyse ergründe ich wie die GIS Anwendungen für die beiden Partner, das städtische Architektenamt und das Steuerdepartment der Kommune, aussehen soll, was sie beinhaltet, wie sie aufgebaut ist und was sie keinesfalls beinhalten sollte. Dabei ist es nicht ganz leicht die Erkenntnisse für den Leser gut strukturiert zu übermitteln, da die Ergebnisse der folgenden Teilbereiche in die Bewertung mit einfließen und deren Grenzen sind nicht ganz einfach scharf zu schneiden:

– Analyse der algemeinen und detaillierten Arbeitsprozesse der departments und Unterbereichen

– Befragungen der Angestellten zu deren Erwartungen an die Software

– Befragungen der Angestellten zu deren Befürchtungen was eine GIS Einführung angeht (Erkennen der Faktoren die zur Ablehnung führen könnten) – klare Aussagen dazu sind von den Angestellten nicht zu erwarten, da sie kaum Erfahrungen mit der digitalen Datenbearbeitung haben, geschweigedenn GIS

– Erkennen von kritischen Prozessen die in Praxis und Theorie unterschiedlich ablaufen – wenn solche Prozesse modeliert werden und kein ausreichender Degree of Freedom gewährleistet ist, wird auch das zur Ablehnung führen

– Analyse des Programmieraufwands der einzelnen Komponenten um sicherzustellen, dass der vorgesehene Umfang auch erreicht werden kann

 

Naja, da muss ich noch ein bisschen dran arbeiten. Darüber hinaus beschreibe ich die Aktivitäten, die ich zeitgleich vorgenommen hatte, nämlich die weiterführende Schulung ausgewählter Workshopteilnehmer zu den Potentialen und den Einsatzfeldern von GIS in öffentlichen Administrationen und das Anstreben eines “Memorandum of Understanding“s zwischen allen Akteuern, dass sicherstellen soll, dass der Datenaustausch der Katasterdaten wirklich stattfinden wird. Das Dokument bildet die Voraussetzung für das ganze Projekt. Denn wenn keine Katasterdaten geliefert werden sind die beiden avisierten GIS Softwareprodukte pretty much useless.

 

Soweit erstmal, nächstes Wochenende werde ich mich wieder melden. Früher werde ich es sicherlich nicht schaffen.

In den letzten Tagen habe ich mich an der Einleitung versucht aber noch nicht so recht den roten Faden gefunden, der den Leser dann durch die Arbeit leitet. Bisher habe ich versucht die essentiellen Hintergrundinformationen einzubauen. Das beinhaltet z.B.

  • Übersicht zum Thema Land Administration Systems und der Rolle der Katasterdaten darin
  • Nutzung der Katasterdaten in lokalen Administrationen
  • Studie über relevante Faktoren einer GIS Einführung in Entwicklungsländern
  • Derzeitige Situation in Azerbaijan
  • Einführung in die relevanten Rahmenbedingungen:
  •              Institutuioneller Aufbau in Azerbaijan (struktureller Kontext)
  •              Stand der Korruption in Azerbaijan (politischer/kultureller Kontext)
  •              Verlauf der Land Reform in Azerbaijan (historischer Kontext

Derzeit ist es alles noch etwas fragmentiert aber ich denke es wird mit der Zeit schon werden und wenn ich den Faden erstmal in die Hände bekommen habe, lasse ich ihn eh nicht mehr los. Außerdem denke ich, dass die Niederschrift des Hauptinhaltes der Arbeit leichter fallen wird als die Einleitung denn dann steht zumindest schon mal das Gerüst, an dem man anknüpfen kann.