Differences

This shows you the differences between two versions of the page.

--- applications:prom:projectstructure [2013/02/26 11:26]
rtavassoli
+++ applications:prom:projectstructure [2013/02/27 10:54] (current)
rtavassoli
@@ Line 134: / Line 134: @@
 === Zirkelbezüge ===
 Zirkelbezüge in der Projektstruktur können auch mit bidirektionalen Beziehungen nicht verhindert werden. Dazu müsste man die Projektstruktur wie in einigen der Modelle weiter oben verwenden. Entweder die System-weite, globale Projektstruktur, oder aber Projektstrukturen pro Hauptprojekt. Das führt aber zu ganz anderen Problemen, vor allem dazu, dass wir zwar Konsistenz haben, aber keine Teilbarkeit des Systems, bzw. keine Verfügbarkeit((siehe CAP Theorem)).
+====== Der Projektstrukturplan ======
+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. Wenn es bloß so einfach wäre. Es gibt ja noch die Regel //auf einer Ebene dürfen Projekte, Produkte, Teilaufgaben, Arbeitspakete, Aktivitäten und Vorgänge nicht vermischt werden//. Das Projekt als logische
+===== Nächster Versuch =====
+Es gibt Projekte mit Teilprojekten((Erweiterbar auf Teilprojektelemente, also auch Produkte, Teilaufgaben, Arbeitspakete, Aktivitäten, usw.)). Ein Hauptprojekt ist Teil seiner eigenen Teilprojektliste - ein Projekt muss immer Teil mindestens einer Teilprojektliste sein, zum //Schutz// der gleichzeitigen Verschiebung des Projektes durch mehrerer User:
+{{ :applications:prom:projectwithsubprojectsextended.png?nolink |}}
+==== Hauptprojektanlage ====
+  - Lege neues Projekt an,
+  - Füge Hauptprojekt als ID-Referenz in der eigenen Projektliste an.
+Beide Schritte müssen ausgeführt worden sein, damit das Projekt im Lesemodell erscheint. Zudem wird der zweite Schritt immer nur nach dem ersten ausgeführt werden können, da das Hauptprojekt für den zweiten Schritt ja das Aggregate Root ist.
+==== Teilprojektanlage ====
+  - Füge Teilprojekt als //schwebende// ID-Referenz im übergeordneten Projekt an. Dadurch wird sicher gestellt, dass das übergeordnete Projekt ein Teilprojekt akzeptieren wird, und dass es nichts anderes als ein weiteres Teilprojekt akzeptieren wird. D.h. die Regel der nicht-Vermischung von Elementen unterschiedlicher Art auf einer Eben wird hierdurch geschützt. Zudem garantiert das Projekt, dass es das Teilprojekt akzeptiert, aber auch, dass die schwebende Referenz wieder gelöscht werden kann.
+  - Lege neues Projekt an,
+  - Mache im übergeordneten Projekt aus schwebender ID-Referenz eine feste.
+Wie in der Hauptprojektanlage müssen alle Schritte durchgeführt werden bevor das neue Projekt im Lesemodell erscheint.
+==== Projekt umhängen ====
+  - Markiere ID-Referenz des Projekts im übergeordneten Projekt zum Löschen vormerken. Das übergeordnete Projekt kann das Projekt selbst sein, sollte es sich um ein Hauptprojekt handeln. Dadurch verschwindet das Projekt im übergeordneten Projekt. Es wird auch vom übergeordneten Projekt garantiert, das das Löschen funktionieren wird, und dass die Kennzeichnung rückgängig gemacht werden kann,
+  - Füge Projekt als ID-Referenz im der Teilprojektliste des neuen Projektes hinzu - es kann sich dabei auch um das eigene Projekt handeln, wenn es zum Hauptprojekt werden soll. Das muss nicht //schwebend// geschehen, denn nach diesem Schritt sind die folgenden Schritte garantiert. Dadurch erscheint das Projekt im Lesemodell unter dem neuen Projekt, bzw. als Hauptprojekt,
+  - Lösche ID-Referenz aus dem letzten übergeordneten Projekt.
+Das Umhängen des Projektes wird durch das übergeordnete Projekt geschützt, d.h. mann wird es nicht gleichzeitig mehrmals verschieben können. Der erste Schritt schlägt fehl, wenn das Projekt bereits von einem anderen Prozess zum Löschen markiert wurde. Daher auch der Umstand, dass ein Hauptprojekt unter sich selbst hängt, denn ansonsten könnte man es nicht schützen.
+Wie man sieht, hat ein Projekt selbst gar keine Wahl ob es umgehängt wird oder nicht. Man kann in den Prozess einbauen, dass es eine Referenz auf das Hauptprojekt hält, und in Schritt 3 umgehängt wird, nachdem das alte und das neue übergeordnete Projekt ihr Einverständnis erklärt haben.
+\\ \\
+Davon wird aber abgesehen, denn es wird von einem Top-Down Workflow ausgegangen. Der Verantwortliche des übergeordneten Projektes entscheidet, was mit den Teilprojekten passiert, bzw. wo sie zu liegen haben. Der Verantwortliche des Teilprojektes kümmert sich nur um den Inhalt des Teilprojektes, also um weitere Teilprojekte, Produkte, Teilaufgaben, Arbeitspakete, usw.
+==== Zirkelbezüge ====
+Es kann passieren, dass Projekt 1 in der Teilprojektliste von Projekt 2 ist, und umgekehrt. Was wären die Ereignisse?
+  - Projekt 1: Lege Projekt 1 an
+  - Projekt 1: Hänge Projekt 1 unter Projekt 1 (Hauptprojekt)
+  - Projekt 2: Lege Projekt 2 an
+  - Projekt 1: Hänge Projekt 2 unter Projekt 1
+  - Projekt 2: Hänge Projekt 1 unter Projekt 2
+Schritt 4 kann sogar vor Schritt 3 //passieren//, bzw. vom Lesemodell beobachtet werden. Es würde 2 Tabellen im Lesemodell geben. Einmal die Tabelle mit den Projektdetails, dann die Tabelle mit der Projektstruktur:
+^ Project-Id      ^ Details           ^
+|                 |                   |
+^ Project-Id      ^ Parent-Project-Id ^
+|                 |                   |
+Wie sehen die Tabellen nach den einzelnen Schritten aus?
+=== Nach Schritt 1 ===
+^ Project-Id      ^ Details           ^
+| Projekt 1       | ...               |
+^ Project-Id      ^ Parent-Project-Id ^
+|                 |                   |
+=== Nach Schritt 2 ===
+^ Project-Id      ^ Details           ^
+| Projekt 1       | ...               |
+^ Project-Id      ^ Parent-Project-Id ^
+| Projekt 1       | NULL              |
+=== Nach Schritt 3 ===
+^ Project-Id      ^ Details           ^
+| Projekt 1       | ...               |
+| Projekt 2       | ...               |
+^ Project-Id      ^ Parent-Project-Id ^
+| Projekt 1       | NULL              |
+=== Nach Schritt 4 ===
+^ Project-Id      ^ Details           ^
+| Projekt 1       | ...               |
+| Projekt 2       | ...               |
+^ Project-Id      ^ Parent-Project-Id ^
+| Projekt 1       | NULL              |
+| Projekt 2       | Projekt 1         |
+=== Nach Schritt 5 ===
+^ Project-Id      ^ Details           ^
+| Projekt 1       | ...               |
+| Projekt 2       | ...               |
+^ Project-Id      ^ Parent-Project-Id ^
+| Projekt 1       | Projekt 2         |
+| Projekt 2       | Projekt 1         |
+...OK, das reicht, also [[applications:prom:workbreakdownstructure|hier]] ist die endgültige Entscheidung...

tawiki

User Tools

Site Tools

Differences

Page Tools