applications:prom:workbreakdownstructure
Differences
This shows you the differences between two versions of the page.
|
applications:prom:workbreakdownstructure [2013/02/26 20:23] rtavassoli |
applications:prom:workbreakdownstructure [2013/02/27 17:04] (current) rtavassoli |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| \\ \\ | \\ \\ | ||
| Hier sind die Regeln, die eingehalten werden müssen, und die zur letztendlichen Struktur geführt haben: | 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 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 zweite Regel betrifft die Domäne, sie kann im Lesemodell aufgelockert werden, solange dadurch kein Schaden entsteht((Die erste Regel ist in Stein gemeißelt. Zirkelbezüge, auch temporäre, sind für das Lesemodell Gift, und für sie kann nur schwer kompensiert werden, bzw. korrigiert werden)), |
| * Die Projektnummern müssen global eindeutig sein, und es muss die Möglichkeit geben, sie fortlaufend und lückenlos zu erzeugen, | * 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, | + | * Projekte müssen innerhalb eines Hauptprojektes frei verschiebbar sein, am besten auch zwischen Hauptprojekten((aber nicht zwingend. Die bisherigen 4 Kunden leben seit 10 Jahren damit, dass das nicht geht)), |
| * Ein Projektleiter muss Teilprojekte anlegen können und diese komplett an Teilprojektleiter abgeben können, | * 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. | * 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 Lösung wird im folgenden Bild dargestellt: |
| + | {{ :applications:prom:projectstructurenested.png?nolink |}} | ||
| + | Was hat das auf sich? Relativ einfach: | ||
| + | * Ein neues Hauptprojekt entspricht einem neuen [[http://de.wikipedia.org/wiki/Projektstrukturplan|PSP]] vom Typ //Projekt//. Das bedeutet, dass das oberste Objekt im PSP ein Projekt sein muss. Innerhalb des Strukturplans kann man weitere Element anlegen. Der Plan ist dabei für die Struktur zuständig, die Objekte((Teilprojekte, Produkte|lieferbare Ergebnisse, Teilaufgaben, Arbeitspakete, Aktivitäten)) werden lediglich referenziert, | ||
| + | * Auf einer Ebene dürfen immer nur Elemente desselben Typs liegen. Unter Projekt-ID 1.1 gibt es 3 Teilprojekte. Unter Produkt-ID 1.1.1.1 im Teil-PSP //Produkt-PSP 1.1.1.1// gibt es 3 Arbeitspakete. Der PSP kann diese Regel sicher stellen, | ||
| + | * Ein Strukturelement im PSP kann auch ein Teil-PSP sein. In dem Bild ist z.B. das Produkt 1.1.1.1 unter Projekt 1.1.1 ein eigenständiger PSP. Dieser ist fest vom Typ //Produkt//, muss also ein Produkt auf oberster Ebene haben. Der Produkt Teil-PSP hat wiederum ein Teil-PSP vom Typ //Arbeitspaket//. Auf diesem Weg kann man Teilaufgaben komplett an jemanden anderes delegieren, der den Teil-PSP dann unabhängig und isoliert von den anderen bearbeiten kann, | ||
| + | * Strukturelemente können innerhalb eines PSPs frei verschoben werden. Dabei müssen lediglich die festgelegten Regeln eingehalten werden, nämlich keine Vermischung von unterschiedlichen Elementen auf einer Ebene, sowie keine Zirkel in der Struktur. Da sich das alles im PSP-Aggregate abspielt, ist das kein Problem. | ||
| + | ===== Anlage eines Hauptprojektes ===== | ||
| + | Ein Hauptprojekt wird über 2 Aggregates angelegt. Man braucht dafür aber keinen Prozess. Einfach erst das Projekt anlegen, und wenn das geklappt hat, den PSP vom Typ //Projekt// mit einer Referenz auf das Projekt auf oberster Ebene in der Struktur anlegen. Erst dann ist das Projekt im Lesemodell sichtbar. | ||
| + | ===== Anlage eines Teilelementes in der Struktur ===== | ||
| + | Das läuft genau wie die Anlage eines Hauptprojektes. Wenn z.B. ein Arbeitspaket im PSP angelegt werden soll, wird erst das Arbeitspaket Aggregate erzeugt, danach die Referenz darauf im PSP. | ||
| + | ===== Anlage eines PSP als Teilelement ===== | ||
| + | Auch das ist nicht weiter kompliziert. Hier sind 3 Aggregates betroffen. Angenommen es handelt sich um ein Teilprojekt, das als PSP komplett an einen Teilprojektleiter delegiert werden soll. Dann wird das Teilprojekt angelegt, das PSP vom Typ //Teilprojekt//, und dann wird das PSP im übergeordneten PSP referenziert. Ein Teilprojekt-PSP ist im Lesemodell auch nicht sichtbar wenn es nicht referenziert wird, d.h. es wird kein neues Hauptprojekt rum schweben, sollte der letzte Schritt fehlschlagen. | ||
| + | ===== Wandeln einer Teilstruktur in ein Teil-PSP ===== | ||
| + | Angenommen in dem Beispiel soll Projekt 1.1.1 an einen Teilprojektleiter delegiert werden, obwohl es bereits als Teil des Haupt PSP 1 angelegt wurde. Man würde im ersten Schritt einen Teilprojekt-PSP für das Projekt 1.1.1 anlegen: | ||
| + | {{ :applications:prom:converttosupprojectstructure.png?nolink |}} | ||
| + | Im zweiten Schritt löscht man die ID-Referenzen auf Projekt 1.1.1 und Produkt 1.1.1.1 aus PSP 1 und legt eine neue Referenz auf das neue Teilprojekt PSP 1.1.1 an. | ||
| \\ \\ | \\ \\ | ||
| - | 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//. | + | Auch hier gilt, dass das Ergebnis des ersten Schritts ohne den zweiten Schritt nicht sichtbar sein wird, weil das Teilprojekt PSP von niemanden referenziert wird. Daher ist auch das eine relativ einfache Umwandlung. |
| - | {{ :applications:prom:projectstructuremultilevel.png?nolink |}} | + | ==== Schließliche Konsistenz ==== |
| - | 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. | + | Falls ES((Event Sourcing)) eingesetzt wird, ist nicht sicher gestellt, dass die Ereignisse der Aggregates PSP 1 und dem neuen Aggregate Teilprojekt-PSP 1.1.1 in der gewünschten Reihenfolge beobachtet und denormalisiert werden. Das Lesemodell verwendet immer die Ereignisse aus den PSPs, gemeinsam mit denen der referenzierten Aggregates. Nur was in beiden existiert wird auch angezeigt. Was kann passieren? |
| - | \\ \\ | + | > Das Lesemodell erhält erst die Ereignisse, in denen die Umwandlung in PSP 1 geschieht, d.h. das entfernen der Referenz auf Projekt 1.1.1 und Produkt 1.1.1.1, sowie das Hinzufügen auf das Teilprojekt-PSP 1.1.1. Das Ergebnis wäre, dass die Teilprojekt Referenz ins Leere zeigt, also auch noch nicht im Lesemodell angezeigt wird, und dass Projekt 1.1.1 samt Produkt 1.1.1.1 nicht mehr referenziert werden, also nicht im Lesemodell enthalten sind. Es kann also passieren, dass **die gewandelten Objekte vorübergehend verschwinden**. Schließliche Konsistenz sagt uns aber, dass die Objekte schließlich wieder erscheinen, und zwar mit 100%er Sicherheit - nur nicht wie lange das dauern wird((i.d.R. nur Millisekunden. Da ich aber nicht mit ES arbeiten werden, bzw. nur punktuell, ist das kein Thema)) |
| - | 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. | + | ===== Wandeln eines Teil-PSP in eine enthaltene Teilstruktur ===== |
| - | \\ \\ | + | Wenn der letzte Schritt wieder rückgängig gemacht werden soll, würde in PSP 1 in einem Schritt die Referenz auf das Teilprojekt PSP aufgelöst werden, und das Projekt 1.1.1 und das Produkt 1.1.1.1 als Referenz wieder zurück in die Struktur aufgenommen werden. Danach kann das Teilprojekt PSP gelöscht werden. |
| - | 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. | + | > Auch hier kann es passieren, dass das Löschen von dem Teilprojekt PSP als erstes beobachtet wird, und dass das gewandelte Teilprojekt somit vorübergehend aus dem Lesemodell verschwindet. |
| - | ===== Projektneuanlage ===== | + | ===== Wandeln eines Teil-PSP in ein Haupt PSP ===== |
| - | 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. | + | Das funktioniert ganz ähnlich. Hierbei entsteht aber ein neues sichtbares Aggregate, was bisher nicht der Fall war, es blieb alles noch Teil von PSP 1((Dafür wurden zwar neue Aggregates erzeugt, doch ohne Referenz auf sie waren sie nie Teil des Lesemodells)). Es muss also ein verteilter Prozess her, der am besten von einer Saga gesteuert wird. Wenn aus Projekt 1.1.1 ein Hauptprojekt werden soll, dann wird ein neuer PSP für das Projekt 1.1.1 angelegt, und zugleich das Projekt und das Produkt aus PSP 1 gelöscht: |
| - | ===== Projekt umhängen ===== | + | {{ :applications:prom:converttomainprojectstructure.png?nolink |}} |
| - | 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 | + | Am einfachsten ist der Prozess darüber zu steuern, dass der neue PSP 1.1.1 im Status //schwebend// angelegt wird, was eine Garantie dafür ist, dass er fest geschrieben werden kann und auch wieder gelöscht werden kann. Dann können das Projekt und das Produkt aus PSP 1 gelöscht werden, und der Status von PSP 1.1.1 auf //fest// gesetzt werden. |
| - | + | >Abhängig der Reihenfolge der Ereignisbehandlung kann es sein, dass Projekt 1.1.1 und Produkt 1.1.1.1 entweder vorübergehend verschwinden((Löschen aus PSP 1 wird zuerst behandelt)), oder dass sie zweimal erscheinen((Alle Ereignisse, inkl. dem Festsetzen von PSP 1.1.1 werden behandelt, bevor das Löschen aus PSP 1 behandelt wird)). Das sind aber beides nur vorübergehende Zustände, die i.d.R. gar nicht beobachtet werden, und wenn ja, ist das System ja schließlich konsistent. | |
| - | + | ===== Wandeln eines Hauptprojektes in ein Teilprojekt ===== | |
| - | ===== Nächster Versuch ===== | + | Das wird nicht erlaubt. Das ist genauso //gefährlich// wie das freie Umhängen in der Gesamten Projektstruktur, zwischen PSPs. Wenn ein Element des Hauptprojektes nämlich bereits ein Element aus der PSP referenziert, in die es gehängt werden soll, haben wir einen Zirkelbezug. Wandeln auf derselben Ebene ist erlaubt, Verschieben innerhalb einer PSP, oder Verschieben //nach oben//((Hauptprojekt aus Teilprojekt machen)). Verschieben auf eine Ebene unter der eigenen birgt die Gefahr der Erzeugung eines Zirkelbezugs. Eventuell kann man das noch unter gewissen Umständen einbauen, aber erst mal wird das nicht erlaubt. |
| - | 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: | + | ====== Aufbau des Lesemodells ====== |
| - | {{ :applications:prom:projectwithsubprojectsextended.png?nolink |}} | + | Das einfache Datenmodell((ohne ES)) sieht in etwa aus wie folgt: |
| - | ==== Hauptprojektanlage ==== | + | {{ :applications:prom:projectstructuredatamodel.png?nolink |}} |
| - | - Lege neues Projekt an, | + | Wenn man nur die Haupt Projektstrukturpläne anzeigt, und Teilpläne durch Anklicken im UI aufruft, haben wir in der PSP Element Tabelle samt Detailtabellen alles, was wir zur Anzeige brauchen. Eine Denormalisierung bis zum untersten Element wäre auch sinnvoll, das spare ich mir aber für später auf, denn PRO•M kennt keine Teil-Projektstrukturpläne, und daher brauche ich für die Anzeige und Datenhaltung dafür erst mal keine Gedanken machen. |
| - | - 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 | | + | |
applications/prom/workbreakdownstructure.1361906635.txt.gz · Last modified: 2013/02/26 20:23 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
