Projekte in mobile Applications

Direkt zu den Projekten und offenen Arbeiten.

"Grau, teurer Freund, ist alle Theorie, und Grün des Lebens goldner Baum.", legte Goethe dem Mephisto in den Mund. Ich behaupte nun aber nicht, dass unsere Projekte des Lebens goldener Baum sind. Aber...

Es macht nie Spaß für die Mülltonne zu arbeiten. Gleichzeitig ist es wirklich schwer, ein Projekt zu erdenken, dass in einem Semester erledigt werden kann und wirklich richtig sinnvoll ist.

Andererseits wäre es doch schön, wenn wir unsere kreative Kraft in etwas stecken, was etwas Bestand hat. Und genau das versuchen wir in den mobilen Anwendungen mit den Projekten zu machen.

Wir haben eine Reihe von Projekten, die bereits seit einigen Semesters laufen. Die sind in unterschiedlichen Phasen. Manche werden finanziell von Ministerien und Firmen unterstützt. Manche sind bisher mehr Idee als Realität.

Es spricht vieles dagegen, solche Projekte durchzuführen: Jedes Semester wechseln die Teilnehmer/innen. Jedes Semester muss man mit einer Einarbeitung beginnen, dann werden einige wenige Schritte getan, dann muss man das alles bereits dokumentieren. Es geht mühsam langsam voran.

Es spricht aber auch einiges dafür: Sie haben oft die Gelegenheit, ihre praktischen Arbeiten im Projekt in einem anderen Modul in MA fortzusetzen. Sie können im 5. Semester auch das Projektstudium nutzen um einen großen Schritt zu machen. Und Sie können eine Abschlussarbeit schreiben in einem Projekt, das Sie bereits kennen. Und in allen Projekten haben wir nach kurzer Zeit Unternehmen oder andere Einrichtungen gefunden, die gut finden, was wir tun und uns unterstützen. Alle Projekte zeichnet aus:

Arbeitsphasen

Software ist nie fertig, aber man kann unterschiedliche Stadien unterscheiden. In unseren Projekten unterscheiden wir folgende Phasen:

Planungsphase: Die Software wird geplant. Es entsteht ein Dokument, dass die Architektur der Software, die angebotenen Schnittstellen und die genutzten anderen Komponenten beschreibt. Es entsteht ebenfalls ein (grober) Plan der weiteren Arbeiten.
Ergebnis der Phase: Architektur der Software und definierte Schnittstellen.

Prototyp: Es existiert Software, die einige wesentliche Funktionen realisiert. Wichtig aber ist: Der Prototyp zeigt, dass die Architektur wie geplant realisierbar ist. Die notwendige Drittsoft- und Hardware wurde getestet und als anwendbar befunden.
Ergebnis der Phase: Man weiß, dass man das System so bauen kann. Architektur und notwendige externe Komponenten leisten was benötigt wird.

Alpha-Version: Nicht selten wird die Software aus der Prototyp-Phase komplett verworfen und das Projekt wird nun dauerhaft aufgesetzt. Die Alpha-Version zeichnet sich durch einen stabilen Entwicklungsprozess aus. Es existiert eine wachsende Anzahl von systematischen Tests. Die Software ist dokumentiert. Die Alpha-Version bietet unbedingt nicht alle geplanten Funktionen an. Funktionen funktionieren bei gutwilliger Nutzung. Wir reden von einer vollen Alpha-Version, wenn alle geplanten Funktionen implementiert sind - auch wenn die ggf. noch instabil laufen.
Ergebnis der Phase: stabiler Entwicklungsprozess, wesentliche Funktionen sind implementiert.

Beta-Version: Die Beta ist eine direkte Fortsetzung der vollen Alpha mit dem gleichen Entwicklungsprozess und den gleichen Dokumenten. Der Unterschied ist die Qualität. Eine Beta bietet alle geplanten Funktionen an. Die Funktionen sind umfänglich getestet und arbeiten stabil bei normaler Nutzung (was normal bedeutet ist in einer Nutzerdokumentation zu beschreiben).
Ergebnis der Phase: alle Funktionen implemementiert und laufen unter normaler Nutzung.

Produktiv-Version: Das System läuft stabil. Es treten nur wenige (was wenig heißt, ist jeweils zu definieren) Fehler auf.
Ergebnis der Phase: System läuft stabil.

Wir arbeiten mit einer dreistelligen Versionsnummer (auch Releasenumber), z.b: 1.20.123. Die Nummern nennen wir Majornumber.Minornumber.Buildnumber
Die Majornumber wird immer dann erhöht, wenn die Software signifikante neue Funktionen anbietet. (Was signifikant heißt, ist jeweils zu entscheiden.)
Die Minornumber wird erhöht, wenn es signifikante Verbesserungen in der Qualität der Software gibt oder weniger siginifikante Funktionen hinzugefügt wurden.
Die Buildnumber wird immer erhöht, wenn ein neues Release erzeugt wird. Man muss mit Buildnummern nicht sparsam sein.
Mit jedem Release wird dokumentiert, welche Änderungen das System aufweist. Die Versionierung nach diesem Schema beginnt mit der Alphaversion. Die Majornumber jeder Alpha ist die 0. Die Majornumber 1 zeigt die erste Beta an. Wir legen nicht fest, welche Majornumber das produktive System benennt. In der Regel ist leider sowieso das, was Entwickler/innen als produktiv empfinden für Nutzer erst eine Beta :-( ( aber bitte keine Alpha!)

Projektmanagement

Das Projektmanagement liegt in den Händen der Studierenden.

Unsere Projekte sind immer in Teilprojekte (TP) unterteilt die in unterschiedlichen Projektphasen stehen. Das ist für das Gesamtsystem auch sinnvoll: Das Ziel ist immer, möglichst schnell ein produktives System (oder eine Beta) zu erstellen mit einem minimalen Satz an sinnvollen Funktionen. Dieses System wird dann schrittweise um neue Funktionen erweitert. Das erfolgt in weiteren Teilprojekten.

Jedes Teilprojekt hat eine/n Teilprojektleiter/in (TPL). TPL sind automatisch für die Tests und die Dokumentation zuständig. Sie müssen dafür weniger implementieren.

Jedes Projekt hat eine/n Projektleiter/in (PL). Die PL koordinieren die TP. Sie haben keine Implementierungsarbeiten zu erledigen. Sie sind zuständig für die Gesamtdokumentation und die Gesamttests des Systems. Ihre Aufgabe besteht vor allem in der Koordinierung (das schließt Kontrolle ein). Die Projektleitung ist ihre alleinige Aufgabe für die Übung. Anfang des Semester machen wir eine Zielvereinbarung anhand derer die Bewertung am Semesterende erfolgen kann.

Ein Wechsel in der (Teil-)Projektleitung ist bei schlechter Arbeit immer möglich.

Es ist in jedem Fall sinnvoll, die Projektleitung für mehrere Semester zu übernehmen. Das gilt meistens auch für Teilprojekte.

Projekte

Rollen und Aufgaben in den Projekten

Open Historical Data Map (OHDM)

Infos zum Projekt
Unsere Karte erzeugt mit Open Layers (nein, wir sind nicht fertig :)).

Indoor Navigation, Ortung und Infosysteme

Infos zum Projekt

Shark

Grundidee
Quellen und Teilprojekte

SharkNet

Ist ein (sehr wichtiges) Teilprojekt von Shark. Laufendes drittmittelfinanziertes Forschungsprojekt.
Quellen