Ein grafisch orientiertes Prozessmodell unterstützt komplexe Prozessabläufe
Management von Steuergeräte-Software-Entwicklung
Fortsetzung des Artikels von Teil 1
Management von Steuergeräte-Software-Entwicklung
Darüber hinaus existieren aus dem Projektumfeld unterschiedliche Prämissen, die gar nicht oder nur mit großem Aufwand in Aktivitätsdiagrammen realisiert werden können. Als Beispiel für derartige Anforderungen werden hier die nachfolgenden Prämissen genannt, die in einem großen Projekt gefordert waren:
- Für jede Aktivität sind Verantwortliche für jeden Input und Output zu bestimmen.
- Die wichtigsten eingehenden und ausgehenden Artefakte pro Aktivität müssen genannt werden.
Jobangebote+ passend zum Thema
Das Konzept der entwickelten Prozessdarstellungen
Der erarbeitete Ansatz zur Darstellung von Prozessmodellen basiert auf den bekannten und weit verbreiteten UMLAktivitätsdiagrammen, jedoch beschränkt er sich auf zwei vertikal verlaufende „swim lanes“ (Bild 3). Auf der linken Seite ist der eigentliche Prozessablauf abgebildet, wohingegen die rechte Seite die zu liefernden Artefakte für jede Aktivität und den dazugehörigen Verantwortlichen auflistet.
Die Notation für den Prozessablauf ist folgendermaßen definiert (Bild 4 ): Jede Aktivität (Rechteck) ist mit einer eindeutigen ID (Kreis in der linken oberen Ecke einer Aktivität) gekennzeichnet. Diese Nummerierung wird verwendet, um einen Referenzpunkt für andere Aktivitäten bzw. die Artefakte (rechte Seite des Diagramms) zu ermöglichen. Darüber hinaus ist die ID mit einer Farbe versehen. Jede Rolle im Projekt ist mit einer projektweit geltenden Farbe versehen (Bild 5). Für projektexterne Rollen oder derzeit undefinierte Rollen ist die weiße Farbe reserviert.
Die Färbung der ID zeigt also an, welche Rolle die Verantwortung für diese Aktivität und somit für das zu erzeugende Ergebnis (Output) hat. Keine Verantwortung beziehungsweise Mehrfachverantwortung ist somit nicht zulässig.
Die Kästchen oberhalb der Aktivitäten symbolisieren die Rollen, die ein eingehendes Artefakt (Input) zu erbringen haben, um die Aktivität erfolgreich auszuführen. Die Färbungen haben dieselbe Bedeutung wie bei der ID. Es ist unbedingt darauf hinzuweisen, dass die Kästchen nicht alle beteiligten Rollen für diese Aktivität darstellen, sondern lediglich diejenigen Rollen, die einen Input liefern müssen. Zum Beispiel muss der Projektleiter in der Review-Aktivität (vgl. Bild 3) überprüfen, ob ein Review erfolgreich durchgeführt wurde (Qualitätsvorgabe). Da hierfür keine Inputs erforderlich sind, wird diese Rolle in der Prozessabbildung nicht explizit definiert. Die Nennung des Projektleiters erfolgt in einem separaten Dokument. Um die Prozesse leicht verständlich zu halten, wurde die Symbolanzahl auf sechs reduziert. Im Vordergrund stehen die normalen Aktivitäten, Subprozesse (vgl. Bild 3, zweite Aktivität), Entscheidungen, Parallelitäten innerhalb eines Prozesses und die Referenzierung auf externe Prozesse.
Auf der rechten Seite ist jeder Aktivität, gekennzeichnet durch eine ID, ein Textblock zugeordnet. In ihm sind die Eingangsartefakte (Input) und Ergebnisse (Output) definiert, sowie eine entsprechende Rolle, die das jeweilige Input zu erbringen hat. Die Farben entsprechen der linken Seite des Diagramms. Darüber hinaus wird jeder Rolle eine Zahl zugewiesen (vgl. Bild 3, Spalte „Erstellt in“), die den spätestens Erstellungszeitpunkt des Artefaktes liefert. Eine Analyse der zweiten Aktivität aus Bild 3 zeigt, dass zum Review der KM-Plan vom Konfigurations-Verantwortlichen (gelb) zu erbringen ist.
- Management von Steuergeräte-Software-Entwicklung
- Management von Steuergeräte-Software-Entwicklung
- Verwendung des Prozessmodells
