tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Der Projektstrukturplan ======
Es gab eine lange [[applications:prom:projectstructure|Suche]] nach dem richtigen Modell für die Projektstruktur. Das [[http://de.wikipedia.org/wiki/CAP-Theorem|CAP]] Theorem sagt uns ja, dass man immer nur maximal 2 von 3 gewünschten Zielen erreichen kann: Konsistenz, Verfügbarkeit, Partitionstoleranz. In der Suche nach der optimalen Projektstruktur habe ich mich immer wieder im Kreis((besser //im CAP Dreieck//)) gedreht, weil mal die Konsistenz der Schwerpunkt der Analyse war, dann die Partitionstoleranz, dann die Verfügbarkeit.
\\ \\
Hier sind die Regeln, die eingehalten werden müssen, und die zur letztendlichen Struktur geführt haben:
  * Die Projektstruktur muss immer konsistent sein. Es darf also in der Baumstruktur keine Zirkelbezüge geben, und ein Projekt darf nicht mehrmals im Baum erscheinen,
  * Die Projektnummern müssen global eindeutig sein, und es muss die Möglichkeit geben, sie fortlaufend und lückenlos zu erzeugen,
  * Projekte müssen frei verschiebbar sein, innerhalb eines Hauptprojektes, und auch zwischen Hauptprojekten,
  * Ein Projektleiter muss Teilprojekte anlegen können und diese komplett an Teilprojektleiter abgeben können,
  * Wenn Teilprojektleiter an ihren Projekten arbeiten, soll dieses unabhängig voneinander geschehen, d.h. dass der Projektstrukturplan pro Teilprojekt isoliert von den anderen Projektstrukturplänen verwalten und gestalten werden können muss.
Die ersten 3 Regeln sagen nichts anderes, als dass es eine globale Projektstruktur geben muss. Nur so kann man diese Regeln konsistent einhalten. Da eine Projektanlage aber ein Punkt ist, bei dem die Konsistenz absolut vorrangig ist, wird der Anwender verstehen, wenn es dort eventuell zu Zeitverzögerungen kommen kann((Gleichzeitiger Zugriff auf die Projektstruktur muss serialisiert werden)).
\\ \\
Die letzten beiden Punkte besagen, dass Änderungen innerhalb eines Projektes aber nicht global serialisiert werden dürfen. Sobald ein Projekt angelegt wurde, sollten Änderungen maximal innerhalb des Projektes serialisiert werden. Die globale Projektstruktur bestimmt also nur die Position des Projektes im Baum. Jedes Projekt hat dann wiederum eine eigene Projektstruktur für //Produkte//, //Arbeitspakete// und //Aufgaben|Vorgänge//.
{{ :applications:prom:projectstructuremultilevel.png?nolink |}}
Die mehrstufige Projektstruktur löst das Problem der gleichzeitigen Zugriffe auf unterschiedliche Teilprojekte. Da die Projekt von der Baumstruktur lediglich referenziert werden((Schwach referenziert, über eine ID)), hängen sie nicht alle gemeinsam im Projektbaum Aggregate und kommen sich nicht in die Quere.
\\ \\
Dass der Projektbaum für eine Neuanlage eines Projektes/Teilprojektes komplett serialisiert werden muss //fühlt sich noch unschön an//. Was für eine schreckliche Aussage! Wenn aber Konsistenz der Schwerpunkt ist, und zwar sofortige, transaktionale Konsistenz, und keine //schließliche Konsistenz//, muss das so sein. Was man zumindest optimieren kann, ist nicht immer den gesamten Baum laden zu müssen. Wenn z.B. ein neues Projekt angelegt wird, braucht man den Baum gar nicht zu laden, denn durch ein neues Projekt kann es nicht zu Zirkelbezügen kommen. Man muss nur das Projekt dem Baum hinzufügen. ORM((Object Relational Mapping)) Tools wie EF((Entity Framework von Microsoft)) bieten das mit //lazy loading// an.
\\ \\
Es ist ja nicht in Stein gemeißelt, und vielleicht kann man die globale Projektstruktur später noch aufteilen. Wenn man z.B. die Regel aufheben kann, dass ein Teilprojekt zum Hauptprojekt werden kann, oder ein Hauptprojekt zum Teilprojekt, dann hat man keinen globalen Projektbaum mehr, sondern einzelne Hauptprojektbäume. Wenn die Projekte in solch einem Hauptprojektbaum diesen nicht verlassen können, braucht man kein globales Aggregate, weil die Hauptprojektbäume vollkommen unabhängig voneinander existieren können.
===== Projektneuanlage =====
Die Projektneuanlage wird so ablaufen, dass erst ein neues Projekt angelegt wird, und es danach im Baum an der richtigen Stelle eingesetzt wird. Das Lesemodell wird das Projekt erst anzeigen, wenn beide Aktionen erfolgreich ausgeführt wurden. Ein neues Projekt in den Baum zu hängen sollte immer funktionieren, daher sollte es selten dazu kommen, dass Projekte brach rum liegen. Und auch wenn, haben sie noch keine Projektnummer erhalten, und sind sonst auch nirgendwo verwendet worden((weil noch nicht sichtbar)), stören also nicht weiter.
===== Projekt umhängen =====
Ein Projekt wird im Projektbaum umgehängt. Das ist ein Vorgang, der einen Schritt benötigt, somit immer konsistent durchgeführt wird. AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!! Die Regel, dass man keine Projekte und andere Teilelement vermischen darf, kann man in dieser Struktur nicht strikt einhalten!!!!!!!! So ein MIST!!!!!!!!!!!
tawiki

User Tools

Site Tools

Page Tools
