Umfeld von SW-Projekten 2.1 Unternehmensführung 2. Prozessmodellierung Unterstützung Vertrieb Projektmanagement Controlling 2.1 Unternehmensprozesse 2.2 Prozessmodellierung mit Aktivitätsdiagrammen 2.3 Risikomanagement SW-Projekt 18 19 Prozesse in Unternehmen aus SW-Projektsicht (Annahme SW ist wichtiges Kernprodukt) Unternehmensführung gibt Geschäftsfelder und Strategien vor Vertriebsleute müssen Kunden finden, überzeugen und Aufträge generieren Aufträge führen zu Verträgen, die geprüft werden müssen Das Personal für Aufträge muss ausgewählt werden und zur Verfügung stehen Der Projektablauf muss beobachtet werden, Abweichungen z. B. in Zeitplan müssen zu Steuerungsmaßnahmen führen Die SW muss realisiert werden Rollenbegriff Unterschiedliche Menschen arbeiten in verschiedenen Rollen zusammen Rolle: genaue Aufgabenbeschreibung, mit Verantwortlichkeiten (was soll gemacht werden) und Kompetenzen (welche Entscheidungen können getroffen werden, z. B. Arbeit anweisen ) Mensch kann in einem Unternehmen/Projekt mehrere Rollen haben Eine Rolle kann von mehreren Menschen besetzt werden Beispielrollen: Vertriebsleiter, Vertriebsmitarbeiter, Projektleiter, Analytiker, Implementierer, Tester 20 21
Prozessbegriff Prozessbeschreibungen regeln die Zusammenarbeit verschiedene Menschen (genauer Rollen), Was soll in diesem Schritt getan werden? Wer ist verantwortlich für die Durchführung des Schritts? Wer arbeitet in welcher Rolle in diesem Schritt mit? Welche Voraussetzungen müssen erfüllt sein, damit der Schritt ausgeführt werden kann? Welche Teilschritte werden unter welchen Randbedingungen durchgeführt? Welche Ergebnisse kann der Schritt abhängig von welchen Bedingungen produzieren? Welche Hilfsmittel werden in dem Prozessschritt benötigt? Welche Randbedingungen müssen berücksichtigt werden? Wo wird der Schritt ausgeführt? Prozesse sind zu dokumentieren und zu pflegen Prozessmodellierung mit Aktivitätsdiagrammen 2.2 Zur Beschreibung werden folgende elementare Elemente genutzt: genau ein Startpunkt einzelner Prozessschritt (Aktion) Kontrollknoten (Entscheidung) Kontrollknoten (Zusammenführung) Endpunkt (Terminierung) 22 23 Parallelität in Prozessen Waagerechter oder senkrechter Strich steht für mögliche Prozessteilung (ein Pfeil rein, mehrere raus) oder Zusammenführung (mehrere Pfeile rein, ein Pfeil raus) Am zusammenführenden Strich steht Vereinigungsbedingung, z. B. {und}: alle Aktionen abgeschlossen {oder}: (mindestens) eine Aktion abgeschlossen UML 1.1 hatte andere Restriktionen Beteiligte, Produkte, Werkzeuge Beteiligte, Produkte, Werkzeuge werden hier als einfache Datenobjekte modelliert, dabei steht zunächst die Objektart und dann die genaue Bezeichnung In eckigen Klammern kann der Zustand eines Objekts beschrieben werden neben Verantwortlicher noch Mitwirkender möglich auch Entscheidungen können Verantwortliche haben 24 25
Beispiel: Vertrieb (1/4) Beispiel: Vertrieb (2/4) Zu modellieren ist der Vertriebsprozess eines Unternehmens, das SW verkauft, die individuell für den Kunden angepasst und erweitert werden kann Modelle werden wie SW inkrementell erstellt; zunächst der (bzw. ein) typische Ablauf, der dann ergänzt wird Typisches Szenario: Vertriebsmitarbeiter kontaktiert Kunden und arbeitet individuelle Wünsche heraus; Fachabteilung erstellt Kostenvoranschlag; Kunde unterschreibt Vertrag; Projekt geht in den Prozess Projektdurchführung (hier nicht modelliert) Beteiligt: Vertriebsmitarbeiter, Kunde, Fachabteilung Produkt: Individualwünsche, Kostenvoranschlag, Vertrag Aktionen: Kundengespräch, Kosten kalkulieren, Vertragsverhandlung 26 27 Beispiel: Vertrieb (3/4) Beispiel: Vertrieb (4/4) nächster Schritt: Einbau alternativer Abläufe Kunde ist am Angebot nicht interessiert In den Vertragsverhandlungen werden neue Rahmenbedingungen formuliert, so dass eine Nachkalkulation notwendig wird [nächste Folie] Bis zu einem Vertragsvolumen von 20 T entscheidet der Abteilungsleiter, darüber die Geschäftsleitung ob vorliegender Vertrag abgeschlossen werden soll oder Nachverhandlungen nötig sind Die Fachabteilung hat Nachfragen, die der Vertriebsmitarbeiter mit dem Kunden klären muss 28 29
Modellierungsfalle Basierend auf Erfahrungen mit Flussdiagrammen könnte man zu folgender Modellierung kommen Dies würde nach UML-Semantik bedeuten, dass für die Aktion Vertragsverhandlung zwei Kostenvorschläge (initial und aktualisiert) vorliegen müssten Wenn verschiedenen Wege zu einer Aktion führen sollen, muss vor der Aktion ein Zusammenführungs-Kontrollknoten stehen Problem Lesbarkeit Diagramme können leicht komplex werden Lösungsmöglichkeiten: Verteilung von Diagrammen auf mehrere Seiten mit Ankerpunkten Verzicht, alle Elemente in einem Diagramm darzustellen (z. B. Produkte weglassen; dies nur in der immer zu ergänzenden Dokumentation erwähnen) Diagramme hierarchisch gestalten; eine Aktion kann durch ein gesamtes Aktivitätsdiagramm verfeinert werden, z. B. ist Kosten kalkulieren eigener Prozess; dies sollte im Modell sichtbar werden 30 31 Prozessverfeinerung: Kosten kalkulieren Anmerkung: Verantwortliche weggelassen, da immer Projektbegleiter der Fachabteilung Problem Abstraktionsgrad Frage: Wann nur eine Aktion, wann mehrere Aktionen Indikator: Mehrere Aktionen zusammenfassen, wenn nur ein Produkt entsteht, das ausschließlich in diesen Aktionen benötigt wird ( lokale Variable ) oder diese von nur einer Person bearbeitet werden Typischerweise Prozesshierarchie: Unternehmensebene; d.h. ein Diagramm für jeden Prozess der Kern-, Management- und Supportprozesse Prozessebene: Verfeinerung des Prozesses, so dass alle auch nur intern sichtbaren Rollen und Produkte sichtbar werden Arbeitsprozess: Individuelle Beschreibung der Arbeitsschritte einer Rolle für eine/ mehrere Aktionen Probleme: Flexibilität und Akzeptanz 32 33
Querschnittsprozess: Projekt-Risikomanagement 2.3 Projekte stoßen häufig auf Probleme, die man frühzeitig hätte erkennen und auf die man dann reagieren könnte; dieser Prozess heißt (Projekt-) Risikomanagement (RM) Idee: frühzeitig über potenzielle Probleme nachdenken, genauer: Vermeidungsmöglichkeiten zur Verringerung der Eintrittswahrscheinlichkeit beim Eintreffen des Problems ersten beiden Ansätze heißen pro-aktives RM, letzter Ansatz reaktives RM oder Notfall-Plan DeMarco, T.; Lister, T.: Bärentango Mit Risikomanagement Projekte zum Erfolg führen, Hanser, München, 2003 Wallmüller, E.: Risikomanagement für IT- und Software-Projekte, Hanser, München, 2004 Gaulke, M.: Risikomanagement in IT-Projekten, Oldenbourg, München, 2004 Versteegen, G.: Risikomanagement in IT-Projekten, Springer, Berlin, 2003 Beispiel RM bei Projektplanung Risiko: Mangelnder Austausch von Know-How im Projektteam Auswirkungen: Arbeiten werden doppelt gemacht, vorhandenes Wissen nicht eingesetzt Ursache: Neues Projektteam, dass noch nicht zusammengearbeitet hat Maßnahme: (Verringerung) Erste Projektveranstaltung (Kickoff) findet in kleinem Hotel außerhalb des Unternehmens statt; moderierte Workshops zum Aufbau des Verständnisses der Projektaufgabe und zur Findung vorhandener Kompetenzen Messung des erfolgs: Kontrolle auf Doppelarbeiten; Verfolgung der Qualität der Ergebnisse, die von mehreren Personen erstellt wurden (nur weiches Maß) Hinweis: Ursache und Risiko können verwischen, da Ursachen wieder Ursachen haben können (... irgendjemand in den Apfel gebissen hat ) 34 35 Risikomanagement Phasen des Risikomanagements (1/3) Risiken identifizieren Risiken analysieren planen Risiken identifizieren Identifikation eines Risikos, Festlegung der Risikoaussage und des Risikokontextes Aufnahme in die Risikoliste Optimieren Risiko- Datenbank bewerten durchführen Risiken analysieren Festlegung der Eintrittswahrscheinlichkeit, der Auswirkungen, der erwarteten Tendenz und des Ursachenfeldes Priorisierung der vorhandenen Risiken unter Berücksichtigung der Gesamtrisikolage 36 37
Phasen des Risikomanagements (2/3) planen Passende definieren Festlegen der verantwortlichen Personen/Rollen Erfolgsfaktoren für festlegen durchführen Sammeln von Informationen/Daten zu den Veränderungen der Risiken und dem Erfolg der Erstellen von Risikomeldungen für das Management Phasen des Risikomanagements (3/3) bewerten Bewertung der Veränderung von Risiken und des Erfolgs der angewendeten Entscheidungsfindung zur weiteren Behandlung der Risiken und Anpassung der Informationsverteilung zu den Risiken in Richtung Team und Vertragspartnern/Kunde Optimieren zielgerichtet anpassen Hinweise/ Optimierungspotenziale für zukünftige Projekte erkennen 38 39