UP&SM Projektmethodik

Transkript

1 , Stöckackerstrasse 30, CH-4142 Münchenstein Ph:++41 (0) , Fax:++41 (0) UP&SM Projektmethodik UNIFIED PROCESS & SOFTWARE MANAGEMENT MANAGEMENT SUMMARY Dieses Whitepaper erläutert die UP&SM-Projektmethodik. Sie basiert auf dem UP&SM-Ansatz. Die UP&SM-Projektmethodik ist vollständig mittels eines UP&SM-Portal computerunterstützt; sie kann nur mit einem entsprechenden UP&SM-Portal betrieben werden. In diesem Papier wird nur auf die UP&SM-Methodik selbst eingegangen und nicht auf den UP&SM-Ansatz selber. Dieser ist ausführlich im entsprechenden Whitepaper ausgeführt. Aufgrund des UP&SM-Ansatzes spricht man bei der UP&SM-Methodik von einer kontinuierlichen, permanenten Prozess-Verbesserung (continuous permanent process improvement). Die UP&SM-Methodik basiert einerseits auf der traditionellen Daten-Normalisierung und auf der neuartigen Verarbeitungs-Normalisierung. Die wesentlichen Merkmale der UP&SM Projektmethodik sind: 1. Permanent-Continuous Process Improvement 2. Open-Transparent Process Improvement 3. Collaborative Process Improvement Version Januar 2008 Seite 1

2 Inhaltsverzeichnis: 1 Permanent Process Improvement Service-Orientierte Prozess-Modellierung Service-Orientiertes Prozess-Metamodell Typologie der Prozesse Der Prozess Prozess-Kompetenz Management Verarbeitungs-Normalisierung Aufbau des UP&SM-Modelles Corporate Process Layer (CP-Layer) Process Layer (P-Layer) Task Layer (T-Layer) Normalisierungs-Prozess Normalisierung CP-Layer Normalisierung P-Layer Normalisierung T-Layer Qualitäts-Sicherung Anhang: UP&SM-Dokumentation Sprachliche Gleichbehandlung Das vorliegende Dokument verwendet Rollenbezeichnungen, die unabhängig vom Geschlecht einer Person und von Stellen einer Organisation sind. Die Rollen können sowohl von Frauen als auch von Männern wahrgenommen werden. Version Januar 2008 Seite 2

3 1 Permanent Process Improvement Aufgrund des UP&SM-Ansatzes spricht man bei der UP&SM-Methodik von einer permanenten, kontinuierlichen, modellbasierten Prozess-Verbesserung (Bild 1.1): - Das Projektteam arbeitet als Workgroup webbasiert am UP&SM-Portal und entwickelt vom Portal gesteuert das UP&SM-Modell. - Aufgrund der Ausführbarkeit haben die Projektmitarbeitenden die durch das Modell definierten Anwendungen/Prototypen (im Bild 1.1 UP&SM Apps ) unmittelbar verfügbar. Damit testen die Projektmitarbeitenden die Anwendungen parallel zur Modellierung. Modell und Anwendungen sind immer synchron. - Das UP&SM-Portal liefert die Dokumentation des Modelles und damit auch die der Anwendungen. - Die einzelnen Anwendungen werden getestet, indem mit den vom Produkt AutoPate, das mit dem UP&SM-Portal integriert ist, generierten Testfällen getestet wird. Ist eine Anwendung getestet worden, dann wird sie mittels des darunterliegenden Versionierungssystem (wie SVN oder CVS) versioniert. Die Testfälle ergeben sich der Prozess-Modellierung. - Ist eine Anwendung erfolgreich getestet worden, dann kann diese released werden. Bild 1.1: Überblick UP&SM Auf diese Art wird permanent verbessert und permanent werden neue Releases von Anwendungen produziert (Bild 1.2). In der Entwicklungs-Umgebung werden die Prozesse gestaltet und automatisiert. Ist eine Anwendung (in Bild 1.2 mit Task bezeichnet) getestet, dann wird diese Anwendung released ; das heisst es wird ein neuer Release erstellt. Dieser Release wird in der Test-Umgebung, die der Produktions-Umgebunge entspricht, eingespielt, und es werden die Produktions-Tests durchgeführt. Sind diese auch erfolgreich, dann wird der Release produktiv gemacht. Version Januar 2008 Seite 3

4 Bild 1.2: Entwicklungs- und Testumgebung mit neuen Releases Bei der UP&SM-Projektmethodik steht die Modell-Entwicklung im Zentrum. Das folgende Kapitel zeigt die Modellierungsschritte. 2 Service-Orientierte Prozess-Modellierung 2.1 Service-Orientiertes Prozess-Metamodell UP&SM führt eine service-orientierte Prozess-Modellierung inkl. Verarbeitungs-Normalisierung ein (siehe Bild 2.1). Die Service-Orientierte Prozess-Modellierung startet mit einem Prozess-Metamodell. Bild 2.1 illustriert die Service-Kette von Lieferant bis zum Kunden. Im Zentrum stehen die Geschäftsprozesse der Firma (Business Processes Company in Bild 2.1), die Services direkt an die Kundenprozesse liefern. Diese sind kundenorientiert und generieren den Kundenmehrwert. Die Geschäftsprozesse liefern dem Kunden ein Produkt oder eine Dienstleistung. Dazu benötigen sie Services von anderen Prozessen: Einerseits Value-Services und andererseits Resource-Services. Value-Services entstehen, wenn die Generierung eines Teils der Kundenmehrwerte ausgelagert wird und damit von externen Lieferanten (Business Processes Supplier Bild 2.1) und/oder firmeninternen Lieferanten (Business Processes Company in Bild 2.1) generiert werden. Version Januar 2008 Seite 4

5 Bild 2.1: Metamodell der Service-Orientierten Prozess-Modellierung Resource-Services ermöglichen die Geschäftsprozesse, indem sie diesen die notwendigen Ressourcen liefern. Wesentliche Ressourcen sind: - Human Resources (HR): Es sind die Mitarbeitenden, die die Prozesse durchführen. - System Resources (SR): Es sind Ressourcen wie IT-Infrastruktur, Datenbanken und die Prozess und Software Management Plattform (UP&SM-Plattform). Weitere Ressourcen sind Büromaterial sowie Produktionsmittel und Verbrauchsmaterialien bei Produktionsprozessen. 2.2 Typologie der Prozesse Die Geschäftsprozesse einer Firma müssen auf die Prozesse der Kunden optimal abgestimmt werden. Die Service-Orientierte Prozess-Modellierung von UP&SM führt zur Kundenprozess- Orientierung und nicht nur zur Kunden-Orientierung! Die Resource-Services werden von den entsprechenden Resource-Management Prozessen geliefert. Bild 2.1 illustriert, dass die Resource-Services von internen Resource-Management Prozessen sowie von externen Resource-Management Prozessen geliefert werden. Die externen Resource-Management Prozesse sind vom Lieferanten hergesehen seine Business Prozesse, von der Firma hergesehen sind es Resource-Management Prozesse, da diese der Firma Resource- Services liefern. Auch die Resource-Management Prozesse benötigen wie alle Prozesse Resource- Services. Eine zentrale Stellung nimmt die Ressource Wissen ein in UP&SM Prozess-Kompetenz oder Prozess-Logik genannt. Sie ist das Wissen, wie die Prozesse durchgeführt werden. Wird der Prozess der Geschäftsprozess-Optimierung vom Wissen her betrachtet, dann kann dieser auch Prozess- Kompetenz Management genannt werden. Das heisst, beim Prozess Geschäftsprozess- Optimierung nach UP&SM ist die Ressource die Prozess-Kompetenz. Version Januar 2008 Seite 5

6 Beim UP&SM erhält die Geschäftsprozess-Optimierung einen starken Wissens-Fokus. Die Value- und Resource-Services müssen vom Service-Provider verkauft und vom Service- Consumer eingekauft werden. Die entsprechenden Prozesse sind die Marketing- und Verkaufsprozesse einerseits und andererseits die Einkaufprozesse, die zueinander komplementär sind und viele gemeinsame Schnittpunkte haben. Sie müssen optimal aufeinander abgestimmt werden. Die gelieferten Leistungen müssen verrechnet und die bezogenen Leistungen müssen bezahlt werden. Die entsprechenden Prozesse sind das Rechnungs-Management und der Zahlungs- Prozess. Das Prozess-Metamodell von UP&SM umfasst somit die folgenden Arten von Prozessen: - Business Prozess: Die Geschäfts-Prozesse oder auch Kernprozesse sind für das operative Geschäft einer Firma zuständing. Mit diesen Prozessen wird der Kundenmehrwert generiert und damit der Umsatz. Diese Prozesse definieren die Firma und sind für die Differenzierung verantwortlich. Beispiele sind Produktentwicklungs-, Produktions- und Produktmanagement- Prozesse. - Resource-Management Prozess: Die Resource Management Prozesse liefern den Geschäfts- Prozessen die Ressourcen und ermöglichen damit diese. - Marketing- und Verkaufs-Prozess - Einkaufs-Prozess - Rechnungs-Management Prozess - Zahlungs-Prozess - Controlling Prozess: Die Controlling Prozesse dienen der Überwachung der Business Prozesse und deren operativen, taktischen und strategischen Steuerung.Zahlungs-Prozess - Accounting Prozess: Der Accounting Prozess dient Bezahlung der Kosten und der Einforderung der Erträge. - Prozesskompetenz-Prozess oder Geschäftsprozess-Optimierungsprozess: Dazu gehören auch die elearning Prozesse für das Kurs- und Event-Management. Aufgrund der Service-Orientierung ergeben sich unter diesen Typen von Prozessen die folgenden Beziehungen: - Die Geschäftsprozesse müssen sich an den Prozessen des Kunden orientieren. - Die Resource-Management Prozesse müssen sich an den Prozessen der Firma ausrichten. - Die Marketing- und Verkaufs-Prozesse müssen sich an den Geschäftsprozessen der Firma und den Einkaufs-Prozessen der Kunden ausrichten. - Die Einkaufs-Prozesse müssen sich an den Prozessen der Firma und den Verkaufs-Prozessen der Lieferanten ausrichten. - Die Rechnungs-Management Prozesse müssen sich an den Geschäftsprozessen der Firma und den Zahlungs-Prozessen der Kunden ausrichten. - Die Zahlungs-Prozesse müssen sich an den Rechnungs-Prozessen der Lieferanten ausrichten. Diese Beziehungen unter den Prozessen beeinflussen das Vorgehen zur Modellierung der Prozesse: - Im Zentrum steht die Modellierung der Geschäftsprozesse. Dabei wird von den Kunden- Requests ausgegangen, welche zu den Prozess-Fällen führen jeder Kunden-Request führt zu einem Prozess-Fall. - Die Modellierung der Resource-Management Prozesse geht von den Requests der Geschäftsprozesse nach Resource-Services aus. Version Januar 2008 Seite 6

7 2.3 Der Prozess Prozess-Kompetenz Management Prozess-Eigentümer ist die Firma, die Eigentümerin der Prozess-Kompetenz ist. Sie kann diese Prozess-Kompetenz einer anderen Firma zur Nutzung verkaufen. Zum Beispiel kann eine Firma die Prozess-Kompetenz einer anderen Firma zur Nutzung liefern, damit diese mit ihren Ressourcen die Leistungen erzeugt, die dann von der ersten Firma wieder abgenommen werden. Beispielsweise wird dies in der Pharma-Industrie oft praktiziert. Grundsätzlich gehört der erzeugte Service dem Nutzer, egal ob die Firma auch Eigentümer ist. Die Ressourcen HR oder SR können dem Prozess-Nutzer gehören, weil der diese gekauft hat, oder er kann diese auch nur mieten (Leasing). Die Ressource Prozess-Kompetenz wird typischerweise von den Firmen für deren Geschäftsprozesse selber aufgebaut. Oft kaufen Firmen auch externe Prozess-Kompetenz und bringen diese mit ihrer eigenen zusammen. Oft geschieht dies in Form von Standard- Softwarelösungen. Der Käufer muss sich aber bewusst sein: Traditionelle Standard-Softwarelösungen können kaum einen Beitrag zur Differenzierung leisten. Der Grund liegt darin, dass erstens die in der Standard-Softwarelösung vorhandene Prozess- Kompetenz standard ist und damit nicht differenziert, dass zweitens diese Prozess-Kompetenz im Code verborgen ist, und dass drittens die traditionellen Standard-Softwarelösungen schlecht individuell anpassbar und noch schlechter individuell erweiterbar sind. Traditionelle Standard- Software-Lösungen eignen sich schlecht zur Automatisierung der Geschäftsprozesse einer Firma. Zur Automatisierung der Geschäftsprozesse einer Firma muss diese einen Prozess- Kompetenz Management Prozess implementieren, um die zur Differenzierung notwendigen Prozess-Kompetenzen und Innovationen aufzubauen. Firmen wie die liefern diesen Prozess, der auch Geschäftsprozess-Optimierungs-Prozess bezeichnet wird, und der bei der nach dem UP&SM-Ansatz durchgeführt wird. Dieser Prozess ist wie jeder andere Prozess in UP&SM modellbasiert. Der Prozess-Fall ist die Prozess-Kompetenz und beginnt mit der Idee für eine neuen Dienstleistung oder ein neues Produkt. Rund um diesen Prozess-Fall gibt es die weitere Prozesse: - Forschung & Entwicklung: Neue Prozess-Kompetenz wird erforscht und entwickelt. - Aufbau & Modellierung der Prozess-Kompetenz: Strategische und taktische Entwicklung der Prozess-Kompetenz. - Schulung der HR mit der Prozess-Kompetenz: HR werden mittels elearning geschult. Anlässe werden verwaltet. - Analyse, Monitoring und Auswertung des Verhaltens der Prozess-Kompetenz: Es werden Daten über das Processing analysiert. - Zugriff auf Prozess-Kompetenz: HR können mittels Knowledge Retrieval auf die Prozess- Kompetenz zugreifen. - Operative Änderung der Prozess-Kompetenz: Mittels administrativen Tasks 2.4 Verarbeitungs-Normalisierung Neben dem Normalisierten Daten-Modell ist das Normalisierte Prozess-Modell von fundamentaler Bedeutung. Zudem sind diese beiden Modelle stark korreliert. Zwischen beiden besteht eine weitreichende Analogie: Version Januar 2008 Seite 7

8 Kriterium Normalisiertes Daten-Modell Normalisiertes Prozess Modell Logik: Die Datenlogik ist modell-basiert. Die Prozesslogik ist modell-basiert. Transformation: Transformation von nicht normalisierten Tabellen in normalisierte Tabellen. Transformation von nicht normalisierten Abläufen in normalisierte Abläufe. Kriterium: Redundanzfreiheit Redundanzfreiheit Vorgehen: Auslagerung von redundanten Tabellenteilen mittels Fremdschlüssel. Auslagerung von redundanten Ablaufteilen mittels Service- Orientierung. Herkömmliche Prozess-Modelle sind nicht normalisiert, da sie nicht redundanzfrei sind. Sie können damit nur als Beschreibungen und als Anforderungen dienen; genau gleich wie die nicht normalisierten Datentabellen nur als Anforderungen für das normalisierte Datenmodell dienen. 2.5 Aufbau des UP&SM-Modelles Das Normalisierte Prozess-Modell umfasst den Corporate Process Layer (CP-Layer), den Process Layer (P-Layer) und den Task Layer (T-Layer) (Bild 2.2). Bild 2.2: Normalisiertes Prozess-Modell der Verarbeitungs-Logik Ein Beispiel des CP-, P- und T-Layer befindet sich in den Bildern 2.3, 2.4 und 2.5. Version Januar 2008 Seite 8

9 Bild 2.3: Ausschnitt aus CP-Layer Bild 2.4: Ausschnitt aus P-Layer Version Januar 2008 Seite 9

10 Bild 2.5: Ausschnitt aus T-Layer Corporate Process Layer (CP-Layer) Der CP-Layer ist in diverse Corporate Process Models (CPM) unterteilt und umfasst alle Prozesse. Ein Prozess besteht aus diversen Tasks. Ein Prozess für einen bestimmten Fall kann Monate dauern. Als Input hat ein Prozess einen Request und als Output einen oder mehrere Services. Die Prozess-Bausteine sind miteinander über ein Forward- und ein Backward-Chaining verbunden. Damit wird der Prozess- Ablauf (Prozess-Flow) gebildet (Bild 2.3, 2.4, 2.6 und 2.7): - Forward-Chaining: Ein Baustein ruft einen anderen auf und gibt die Kontrolle an den anderen ab. Der Teil a) von Bild 2.6 zeigt den Request für den Process und den Service, den der Prozess erzeugt. Dieser Service kann Input oder Request für einen nächsten Prozess sein. Das Forward- Chaining wird auch Value-Chaining genannt. - Backward-Chaining: Ein Baustein (PA) ruft einen anderen (PB) auf und wartet auf dessen Service. Dieser Service wird vom Baustein PA weiter bearbeitet. Der Teil b) von Bild 2.6 zeigt, dass der Prozess PA einen Request absetzt. Dieser verlangt vom Prozess PB einen Service, der an PA zurückgeht. Darauf kann PA weiterfahren. Das Backward-Chaining entspricht der Service-Orientierung. Damit werden gemeinsame Teile von Prozessen in neue Prozesse ausgelagert. Bild 2.6: Forward- und Backward- Chaining Version Januar 2008 Seite 10

11 2.5.2 Process Layer (P-Layer) Der P-Layer (P-Layer) besteht aus den diversen Process Models (PM). Pro Prozess gibt es ein PM, das aus Tasks besteht. Eine Task führt innerhalb eines Prozesses eine Aufgabe durch. Die Aufgabe hat einen Start. Sie wird dann von User und System durchgeführt oder vom System alleine, und liefert darauf ein Resultat, das persistent abgelegt wird. Damit ist die Task beendet. Die Task-Bausteine sind wie die Prozess-Bausteine miteinander über ein Forward- und ein Backward-Chaining verbunden. Damit wird der Task-Ablauf (Task-Flow) gebildet (Bild 2.4) Task Layer (T-Layer) Der T-Layer besteht aus Atomic Activities, Composite Activities, Superactivities und Connector Activities: Die Atomic Activities werden auch atomare Services genannt. Die Activities rufen über gerichtete Verbindungen, die mit einem Label bezeichnet werden können, andere Activities auf. Damit wird ein Activity-Ablauf (Activity-Flow oder auch Micro-Workflow genannt) gebildet (siehe Bild 2.5). Die atomaren Services bilden die Bibliothek der Basis-Bausteine, die man sich als Lego-Bausteine vorstellen kann. Die Composite Activities umfassen einen Activity Flow. Mittels der PartTask Activity können komplexe Tasks einfach modelliert werden. Mittels der SubTask Activity werden wiederkehrende Teilabläufe verhindert und damit Redundanzen eliminiert. Dazu kommen noch weitere Composite Activities wie die Loop Activity. Die Superactivities dienen der weiteren Reduktion von Redundanz. In den diversesten Tasks treten immer wieder die gleichen Abläufe auf. Mittels Activity Patterns oder Superactivities genannt können diese ähnlichen Abläufe vereinheitlicht werden. Superactivities sind parametrisierbar wie die Atomic Activities und bestehen aus Atomic Activities. Die Connector Activities oder auch Konnektoren genannt übernehmen die Integration von Third-Party-Software. Standardmässig über Web-Services integrieren sie Third-Party-Software. 2.6 Normalisierungs-Prozess Der Normalisierungs-Prozess umfasst die Normalisierung des CP-, des P- und des T-Layer Normalisierung CP-Layer Zur Erstellung des CP-Layer und damit der CPM werden die folgenden Schritte durchgeführt: 1. Identifikation der Prozesse 2. Erstellung der Prozess-Abläufe (Prozess-Flows) 3. Auslagern von redundanten Prozessteilen Schritt 1.1: Identifikation der Prozesse Die Prozesse werden aus dem Normalisierten Datenmodell abgeleitet. In jeder Unternehmung gibt es die wesentlichen Objekte (Hauptobjekte). Dies sind die Objekte, die eine eindeutige Identifikation haben wie: - Stakeholder z.b Kunde, Mitarbeiter, Lieferant, etc. - Produkte - Vertrag -... Pro Branche können diese Objektklassen eindeutig identifiziert werden. Version Januar 2008 Seite 11

12 Für jede Klassen gibt es einen Prozess. Es resultieren Prozesse wie: - Kunden-Management - Mitarbeiter-Management - Lieferanten-Management - Produkt-Management: Dieses kann in diverse Prozesse pro Produktsegment aufgeteilt werden Weitere Prozesse werden von den Prozessfällen abgeleitet wie: - Verkaufs-Fall - Support-Fall - Einkaufsfall -... Diese Fälle sind auch Hauptobjekte. Prozessfälle entstehen aufgrund eines Requests wie Kunden-Request und Support-Request. Die Request kommen von den Stakeholdern. Man geht somit durch die diversen Stakeholders durch und identifiziert deren Requests. Damit werden die Prozessfälle erhalten. Hinter jedem Prozessfall steht wieder ein Prozess wie: - Verkaufs-Prozess - Support-Prozess - Einkaufs-Prozess -... Kriterium: Jeder Prozess ist für ein bestimmtes Hauptobjekt und damit Datenbereich verantwortlich. Alle Daten müssen so durch die Prozesse abgedeckt sein. Schritt 1.2: Erstellung der Prozess-Abläufe Ausgehend von den event-basierten Prozessen werden die Abläufe erstellt. Bei diesen Prozessen wird gefragt, welche anderen Prozesse sie benötigen. Beispielsweise wird mit einem Kundenrequest begonnen. Der Kundenrequest geht an den Verkaufsprozess. Damit der Verkaufsprozess durchgeführt werden kann, benötigt dieser den Kunden-Management und den Produkt- Management Prozess als Service-Prozesse (siehe Bild 2.7). Es entsteht eine service-orientierter, modellbasierte Prozess-Ablauf. Auf diese Weise werden die Abläufe modelliert, und es wird der CP-Layer mit den CPM erhalten. Bild 2.7: Service-orientiertes CPM Schritt 1.3: Auslagern von redundanten Prozessteilen Sind Teile von unterschiedlichen Prozessen gleich, dann müssen diese Teile in einen neuen Prozess ausgelagert werden. Oft werden redundante Prozessteile erst erkannt, wenn die Prozesse selbst modelliert werden. Version Januar 2008 Seite 12

13 2.6.2 Normalisierung P-Layer Zur Erstellung des P-Layer und damit der diversen Prozess-Modelle werden die folgenden Schritte durchgeführt: 1. Übergang vom CP- zum P-Layer 2. Identifikation der Tasks 3. Erstellung der Task-Abläufe (Task Flows) 4. Auslagern von redundanten Taskteilen Schritt 2.1: Übergang vom CP- zum P-Layer Bild 2.8 illustriert die möglichen Beziehungen zwischen dem Verkaufs-Prozess (PA) und dem Kunden-Mgt (PB). Im PA gibt es sicher eine Task A (TA). Diese kann mit der entsprechenden Task von Prozess B (TB) auf die Arten a1), a2) und a3) kommunizieren. Die Task von Prozess B kommuniziert mit TA entweder auf die Art b1) oder b2). Beim Fall a1) ist die Service-Chain synchron. Beim Fal a2) und a3) ist die Service-Chain asynchron. Bild 2.8: Übergang vom CP- zum P-Layer Mittels der Übergangsregeln von Bild 2.8 werden die diversen PM initial erstellt. Schritt 2.2: Identifikation der Tasks Ein Prozess besteht aus Tasks. Ein Prozess ist für ein Hauptobjekt verantwortlich. Die Tasks eines Prozesses sind für die Zustände eines Hauptobjektes verantwortlich. Beispiel Prozess Projekt-Management : Version Januar 2008 Seite 13

14 Das Bild 2.3 illustriert den CPM Ausschnitt mit dem Prozess Project Management, der sich für das Hauptobjekt Projekt verantwortlich zeigt. Die Zustände des Hauptobjektes Projekt sind: - New Project - Project Opened - Project Started - Project Performing (with efforts) - Project Closed Diese Zustände beschreiben den Lebenszyklus des Hauptobjektes Projekt. Um diese Zustände zu erreichen, müssen Tasks durchgeführt werden. So gibt es pro Zustand eine Task. Damit sind die Task identifiziert, und es wird das Bild 2.4 erhalten. Der Service Advisor Service wird vom Prozess StakeholderMgt geliefert. Der Datenbereich des Hauptobjektes Projekt (UP&SMProject) ist in Bild 2.9 dargestellt. Die Tasks OpenProject, StartProject, PerformProject und CloseProject sind für die diversen persistenten Zustände verantwortlich. Bild 2.9: Datenbereich des Prozesses Projekt Management Schritt 2.3: Erstellung des Task Abläufe (Task Flows) Die Tasks, die für die Zustände verantwortlich sind, sind aufgrund der Zustandsänderungen als Value-Chain miteinander verbunden (Bild 2.4). Bei jeder Task wird untersucht, ob diese von anderen Tasks Services benötigt wird. Es entsteht ein service-orientierter, modell-basierte Task-Ablauf. Schritt 2.4: Auslagern von redundanten Taskteilen Sind Teile von unterschiedlichen Tasks gleich, dann müssen diese Teile in eine neue Task ausgelagert werden. Oft werden redundante Taskteile erst erkannt, wenn die Tasks selbst modelliert werden. Version Januar 2008 Seite 14

15 2.6.3 Normalisierung T-Layer Zur Erstellung des T-Layer mit den diversen Task-Modellen (TM) werden die folgenden Schritte durchgeführt: 1. Übergang vom P- zum T-Layer 2. Erstellung des Main Activity Flow pro TM 3. Verfeinerung des TM Main Activity Flow 4. Auslagern von redundanten Activity-Teilabläufen Schritt 3.1: Übergang vom P- zum T-Layer Synchrone Service-Chain: Verlangt eine Task einen Service synchron von einer anderen Task, dann geschieht dies im Task Model mit einer Service Task Activity. Besteht der Service nur als Lieferung von persistenten Daten, dann kann anstelle der Service Task Activity auch die RetrieveDB Activity genommen werden; der entsprechende Filter kommt vom Datenbereich der Service Task. Besteht der Service nur aus einem Store oder Modify von Daten, dann kann anstelle der Service Task Activity auch die StoreDB Activity genommen werden. Asynchrone Service-Chain: Verlangt die aufrufende Task (TA) den Service von der Service-Task (TB) asynchron, dann ruft TA die Task TB mittels der Task Activity über den Request Entrypoint auf. Es wird damit ein Request von TB erstellt. Ist der Service von TB erstellt, dann ruft TB die Task TA mittels der Task Activity über den Receive-Service Entrypoint auf. Der Service von TB wird von TA entgegengenommen. Anstelle der Task Activity kann auch die Store Activity genommen werden. Schritt 3.2: Erstellung des Main Activity Flow pro TM Ein TM besitzt nur einen Main Activity Flow. Der TM Main Activity Flow besteht aus den PartTask Activities und den Branch Activities. Schritt 3.3: Verfeinerung des TM Main-Workflow Jede PartTask Activity besitzt ihren eigenen Activity-Flow, der aus einem Flow von Activities besteht inkl. PartTask Activities. Damit kann die Verfeinerung über beliebige Stufen gehen. Schritt 3.4: Auslagern von redundanten Activity-Teilabläufen Werden in diversen PartTasks gleiche Teilabläufe identifiziert, dann werden diese in Sub-Tasks ausgelagert. Die Sub-Tasks können darauf mittels Sub-Task Activities aufgerufen werden. 3 Qualitäts-Sicherung Die Qualitäts-Sicherung basiert primär auf den Eigenschaften von UP&SM und vom UP&SM-Modell: - Aufgrund des UP&SM-Modelles werden mittels Auto-Pate die Testfälle erstellt. - Aufgrund der direkten Ausführbarkeit des UP&SM-Modelles werden die resultierenden Anwendungen dauernd getestet. Der von Auto-Pate aus dem Modell heraus erstellte vollständige und hinreichende Test-Set ist die Grundpfeiler der Qualitäts-Sicherung. Dieser Testset ist in der Entwicklungs- und Test-Umgebung verfügbar. Version Januar 2008 Seite 15

16 Anhang: UP&SM-Dokumentation Version Januar 2008 Seite 16