Eine Werkbank für den Zuschnitt von objektorientierten Softwareprozessen; A workbench for the adaption of object-oriented software processes;

1 Einfuhrung

In der modernen Softwareentwicklungsetzt sich mehr und mehr die Erkenntnisdurch, dass ein einheitliches Vorgehens-modell den Anforderungen und Bedurfnis-sen der betrieblichen Anwendungsent-wicklung widerspricht. Hierfur gibt esmehrere Ursachen. Die Dynamik in derPlattform-Technologie sorgt dafur, dassganz unterschiedliche Entwicklerprofileund Vorgehensweisen notwendig sind, umdie gewachsene Systemlandschaft zu be-treuen. Haufig wird die Organisation derEntwicklungsteams durch die mehrstufigeHardware-Architektur vorgegeben. Einphasenartiges Vorgehen, wie es in der Ver-gangenheit fur die COBOL-Entwicklungauf dem Großrechner praktikabel war, lasstsich nicht ohne Weiteres auf die Kom-ponentenentwicklung fur den Applika-tionsserver nach dem J2EE-Standard oderdie Front-End-Entwicklung fur mobileEndgerate ubertragen. Fortschritte im Soft-ware Engineering beim �bergang vom De-sign zur Implementierung lassen iterativeund inkrementelle Vorgehensweisen in denVordergrund treten.

Schwergewichtige (weil detailliert ausgear-beitete) Vorgehensmodelle wie V-Modell[DrHM98] oder Rational Unified Process(RUP) [Kruc99] werden im Zeitalter der„schnellen“ Anwendungsentwicklung, indem es auf fruh lauffahige Teillosungen an-kommt, aufgrund des inharenten Verwal-tungsaufwands und der stringenten Vor-gaben fur die Projektmitarbeiter kritisiert.Mit Extreme Programming (XP) ist dasPendel genau in die andere Richtung aus-

geschlagen [Beck00]. Die aus dem XP-La-ger propagierten leichtgewichtigen Prozes-se schlagen eine rigorose Entkernungetablierter Vorgehensweisen durch eine Re-duktion auf das nach Ansicht der XP-Be-furworter Wesentliche und eine Neuord-nung der zeitlichen Ablaufe vor. FlexibleZweier-Teams beginnen mit Testaktivitatenund stellen damit den konventionellen Ent-wicklungsprozess auf den Kopf.

In jungster Vergangenheit lasst sich ein all-gemeiner Trend hin zu leichtgewichtigenVorgehensweisen beobachten [KnWi01].Neben XP haben sich weitere leicht-gewichtige, so genannte agile Methodenentwickelt, die alle auf gemeinsamen, in ei-nem Manifest zusammengefassten Prinzi-pien beruhen [Fowl01]. Ein wesentlicherAspekt der agilen Entwicklung besteht da-rin, flexibel auf sich andernde Anforderun-gen reagieren zu konnen. Eine vergleichen-de Gegenuberstellung der verschiedenenagilen Methoden findet sich in [Cold02].

Solche Ansatze sind im betrieblichen All-tag allerdings nicht unumstritten. Vor allembeim Management, welches fur die Bereit-stellung von Anwendungssystemen fur dasKerngeschaft verantwortlich ist, bestehenoft erhebliche Zweifel an ihrer Eignung.Dies mag zum einen daran liegen, dass esnur wenige Programmierer mit den Fertig-keiten eines Kent Beck gibt, und zum an-deren an den veranderten Moglichkeiten,den Status eines Projektes festzustellen.Meilensteine der konventionellen Entwick-lung wie die Fertigstellung des Fachkon-zepts oder der Spezifikation verschwim-men durch kurze Entwicklungszyklen mitpartiellen Ergebnissen.

WIRTSCHAFTSINFORMATIK 44 (2002) 4, S. 315–324

Der Autor

Jorg Noack

Dr. Jorg Noack,SIZ – Informatikzentrum derSparkassenorganisation,Konigswinterer Str. 552,D-53227 Bonn,E-Mail: [email protected]

Eine Werkbank fur den Zuschnittvon objektorientiertenSoftwareprozessen

WI – Aufsatz

In dieser Arbeit geht es weniger um die Su-che nach dem einheitlichen Softwarepro-zess, der allen denkbaren Randbedingun-gen gerecht wird, sondern vielmehr um dieFrage, wie fur eine bestimmte Ausgangs-situation ein optimaler Softwareprozessmoglichst effizient gefunden werden kann.Das Informatikzentrum der Sparkassen-organisation entwickelt zurzeit auf der Ba-sis eines Metamodells fur Softwareprozesse

ein Werkzeug, mit dem Vorgehensmodellean individuelle Softwareprojekte angepasstwerden konnen.

Abschnitt 2 erlautert den Hintergrund derSIZ-Arbeiten und die Aufgabenstellung. InAbschnitt 3 wird das Prozessrahmenwerkvorgestellt, das als Ausgangsbasis fur denprojektindividuellen Zuschnitt eines Pro-zessmodells dient. Der Vorgang des Zu-

schneidens objektorientierter Softwarepro-zesse mit der Vorgehensmodell-Werkbankwird in Abschnitt 4 erlautert. Anschließendwerden in den Abschnitten 5 und 6 die vonder Werkbank generierten Ergebnisse inForm eines elektronischen Projekthand-buchs und eines initialen Projektplans vor-gestellt. Abschnitt 7 fasst die gewonnenenErkenntnisse zusammen und gibt einenAusblick auf die nachste Ausbaustufe derWerkbank.

2 Hintergrund

Mit dem Anwendungsentwicklungsmodell(AE-Modell) gibt das Informatikzentrumder Sparkassenorganisation (SIZ) einenProzessleitfaden heraus, der die Vorgehens-weisen und Leitlinien fur die Anwendungs-entwicklung in der Sparkassen-Finanz-gruppe beschreibt. Vergleichbare Ansatzefinden sich bei vielen Großunternehmenund Organisationen oder werden vonWerkzeugherstellern angeboten. Exempla-risch genannt werden sollen das V-Modellfur die Bundesbehorden [DrHM98], derRational Unified Process [Kruc99] oder dieOPEN Process Specification des OPEN-Konsortiums [GrHY97]. Ein Vergleich desAE-Modells mit diesen und weiteren Vor-gehensmodellen findet sich in [NoSc99].

Die Dynamik der Informationstechnologiemacht es notwendig, dass ein solcher Pro-zessleitfaden – wie jede andere Softwareauch – permanent aktualisiert werdenmuss, um den Kundenbedurfnissen gerechtzu werden. Das AE-Modell unterliegt ei-nem kontinuierlichen Verbesserungspro-zess mit Ruckkopplungsmechanismen zuden Anwendern, der dazu gefuhrt hat, dasssich drei Auspragungen, namlich

& fur die strukturierte Entwicklung& fur die objektorientierte Entwicklung& fur die Internet/Intranet-Entwicklung

herausgebildet haben, die die verschiede-nen Anforderungen der Softwareerstel-lung bundeln [Noac00a]. Um eine Viel-zahl von Softwareprojekten in derSparkassen-Finanzgruppe unterstutzen zukonnen, wurde das ursprungliche, phasen-orientierte Vorgehensmodell revidiert unddurch ein flexibles Prozessrahmenwerk er-setzt.

Des Weiteren hat man anstelle der anfang-lichen Prasentationsform des AE-Modellsals gedrucktes Handbuch eine navigierbareBrowserlosung mit einheitlicher Benut-


Bild 1 Browser-basierte Darstellung des AE-Modells fur die objektorientierte Entwick-lung

Vorgehens -

modell-

Werkbank

Ausbau-

stufe 1

(Prototyp)

Vorgehens -

modell-

Werkbank

Ausbau-

stufe 2

Referenzmodell

Prozessvarianten

VorgehensmodellProjekt "4711"

Vorgehens-modell-

Werkbank

Ausbau-stufe 1

(Prototyp)

Vorgehens-modell-

Werkbank

Ausbau-stufe 2

Bild 2 Aufbau des Prozessrahmenwerks

316 Jorg Noack

zungsoberflache eingefuhrt (Bild 1). Durchdie elektronische Verfugbarkeit konnte dieTransparenz des Prozessleitfadens verbes-sert und der Nutzungsgrad in den Ent-wicklungsprojekten der Sparkassen-Fi-nanzgruppe erhoht werden, was insgesamtzu einer Akzeptanzverbesserung des Pro-zessleitfadens gefuhrt hat.

Die Erfahrungen mit der Browserlosung inEntwicklungsprojekten zeigten jedoch,dass die fehlende Individualisierungsmog-lichkeit der angebotenen Prozessmodellefur die Projektarbeit bemangelt wird. AllenProjekten werden dieselben Hilfsmittel inForm von Leitlinien und Musterdokumen-ten zur Verfugung gestellt. Der Zuschnitteiner Prozessvariante auf den Kontext ei-nes spezifischen Projektes muss bislang aufdem Papier erfolgen.

Um diese Schwachstelle zu beseitigen, wirdbeim SIZ zurzeit ein Werkzeug entwickelt,mit dem die Herleitung eines projektspezi-fischen Vorgehensmodells unter Wahrungvon Rahmenvorgaben und Einhaltung derKonsistenz des Netzes von Vorgehens-modellobjekten moglich ist.

3 Ein Prozessrahmenwerk

Das Prozessrahmenwerk besteht aus ver-schiedenen Schichten, die sich mit Hilfeeiner Metastruktur beschreiben lassen. Einahnlicher Ansatz wird bei der ObjectManagement Group (OMG) verfolgt. DieOMG hat sich im Rahmen einer TaskForce zum Thema Software Process Engi-neering mit der Standardisierung einesMetamodells beschaftigt, um langfristig ei-ne Interoperabilitat zwischen Werkzeugenund Repository-Diensten sicherzustellen[OMG99; IRFS01].

Im Prozessrahmenwerk des SIZ (Bild 2)wird zwischen einem ubergeordnetem Re-ferenzmodell, den projekttypspezifischenProzessvarianten und einem projektspezi-fischen Vorgehensmodell unterschieden.Die Vorgehensmodell-Werkbank liefert ei-ne Werkzeugunterstutzung fur die Herlei-tung von projektspezifischen Vorgehens-modellen. In einer ersten Ausbaustufe(Prototyp) geht es darum, den Vorgang derAnpassung einer vorgegebenen Prozess-variante an die Bedurfnisse eines konkretenProjektes werkzeugtechnisch zu unterstut-zen. Die zweite Ausbaustufe befasst sichdaruber hinaus mit der Herleitung von

Prozessmodellen (so genannte Prozess-varianten) aus dem Referenzmodell.

3.1 Das Referenzmodell

Auf der Ebene des Referenzmodells sinddie Grundbausteine zur Spezifikation vonSoftwareentwicklungsprozessen definiert:

& Aktivitaten bilden die Kernelemente ei-nes Softwareprozessmodells. Sie stellenHandlungsanweisungen fur den Pro-jektablauf dar und tragen zur Erarbei-tung aller Projektergebnisse bei. Aktivi-taten konnen weiter in Teilaktivitatenzerlegt werden. Beispiele fur Aktivitatensind: Projekt starten oder Anforderun-gen analysieren

& Ergebnisse stellen das Resultat derDurchfuhrung von Aktivitaten dar. EinErgebnis kann aus verschiedenen Teil-ergebnissen bestehen. Ergebnisse sind ineiner bestimmten Notation darzustellen.Beispiele fur Ergebnisse sind: Projekt-plan oder Anwendungsfallmodell

& Rollen stellen Qualifikationsmuster imEntwicklungsprozess dar. Inhaber vonRollen sind im Projektverlauf fur dieDurchfuhrung von Aktivitaten verant-wortlich. Beispiele fur Rollen sind: Pro-jektleiter oder Modellierer

& Techniken dienen als Hilfestellung beider Durchfuhrung von Aktivitaten, in-dem sie eine Anleitung liefern, wie einebestimmtes Ergebnis oder Teilergebnishergestellt werden kann. Beispiele furTechniken sind: CRC-Karten oder Ope-rationsmodellierung.

Fur die einzelnen Typen vonGrundbaustei-nen wurde jeweils ein Raster definiert, nachdem die Grundbausteine dokumentiertsind. Tabelle 1 zeigt exemplarisch einenGrundbaustein anhand eines Ausschnittsder Technik Operationsmodellierung.

Techniken liefern den Prozessbeteiligteneine Anleitung und Hilfestellung bei derDurchfuhrung von Aktivitaten. Sie solltendaher selbsterklarend, umfassend, beispiel-haft und klar voneinander abgrenzbar sein.Samtliche Techniken sind nach einem ein-heitlichen Beschreibungsraster (Name, Be-schreibung, Qualitatskriterien, Voraus-gesetztes Wissen, Literatur) dokumentiert,wobei der Abschnitt Beschreibung funfimplizite Paragraphen (Ziel, Nutzen, Vo-raussetzung, Ergebnis, Arbeitsschritte) ent-halt [Noac01].

Tabelle 1 zeigt einen Ausschnitt aus derTechnik Operationsmodellierung. AusPlatzgrunden musste auf die detaillierteBeschreibung der Arbeitsschritte und aufdas hinterlegte Anwendungsbeispiel ver-zichtet werden. Im Prozessrahmenwerkstehen mehr als 90 solcher Techniken vonder Anforderungsanalyse bis hin zum Pro-jektmanagement fur die Komposition vonProzessmodellen zur Verfugung.

Bei der Komposition von Prozessvariantensetzt man die Grundbausteine nach einembestimmten Schema in Verbindung. We-sentliche Aspekte werden durch das ver-einfachte Metamodell in Bild 3 dargestellt.Im Mittelpunkt der Betrachtung stehen da-bei zunachst die Aktivitaten. Fur jede Ak-tivitat, die aus dem Referenzmodell fur den


Kernpunkte fur das Management

Vorgehensmodelle fur die Software-Entwicklung werden haufig als unflexibel, dogmatisch,uberfrachtet und kreativitatshemmend kritisiert.Umgekehrt existiert bei den meisten Entwicklungsprojekten weder der Zeitrahmen noch dasBudget, um das Projektvorgehen von Grund auf neu festzulegen.Der Beitrag skizziert ein Software-Werkzeug, mit dem individuelle Vorgehensmodelle auseiner Wissensbasis etablierter Grundbausteine und Prozessvarianten zusammengestellt undmit geringem Aufwand in Form eines Projektplans und eines Projekthandbuchs bereitgestelltwerden konnen.

Stichworte: Software Process Engineering, inkrementelle Entwicklung, Softwareentwick-lungswerkzeug, Projektplanung, Prozessrahmenwerk

Werkbank fur den Zuschnitt von objektorientierten Softwareprozessen 317

Aufbau einer Prozessvariante ubernom-men werden soll, ist festzulegen, welcheRollen fur die Durchfuhrung verantwort-lich sind, welche Ergebnisse als Output er-zeugt werden und auf welche Technikendabei zuruckgegriffen werden kann. Derangestrebte Abstraktionsgrad des Prozess-modells bestimmt, ob einzelne Aktivitatenweiter in Teilaktivitaten zerlegt werdenmussen. Bild 3 zeigt i. W. die statischenAspekte bei der Komposition von Prozess-modellen. Auf die dynamischen Aspekte,welche sich in konkreten Aktivitatenablau-fen widerspiegeln, gehen wir im nachstenAbschnitt ein.

3.2 Die Prozessvarianten

Eine Ausgangsbasis fur die �berlegungenzu den dynamischen Aspekten der Pro-zessmodellierung bildet die Einheitszellefur Aktivitaten [Hump89]. Das Modell derEinheitszelle (Bild 4) geht davon aus, dassim Rahmen einer Aufgabe(Task) Ein-gaben(Input) zu Ausgaben(Output) ver-arbeitet werden. Vor der Durchfuhrung derAufgabe mussen bestimmte Vorbedingun-gen(Entry) erfullt sein. Nach der Durchfuh-rung werden bestimmte Nachbedingungen(Exit) zugesichert. Durch Maße(Measure-ment) wie Zeitverbrauch kann die Durch-

fuhrung einer Aufgabe bewertet werden.�ber einen Ruckkopplungsmechanismuskonnen Zusammenhange zu anderen Akti-vitaten, wie z. B. �nderungsanforderungen,hergestellt werden. Anhand der verarbeite-ten bzw. erzeugten Ergebnisse konnen Ak-tivitaten in eine zeitliche Reihenfolge ge-bracht werden. Hierdurch ergibt sich eineAblaufstruktur fur Aktivitaten.

Die Erfahrungen in einer großen Entwick-lungsorganisation in der Vergangenheitzeigten, dass es aus Grunden der Know-how-Weitergabe sowie aus Zeit- und Kos-tengrunden nicht sinnvoll ist, die Defini-tion dieser Modelle vollstandig denEntwicklungsprojekten zu uberlassen. DieKonzentration auf einige wenige, aber ty-pische Prozesse, welche die meisten Pro-jektsituationen abdecken, erlaubt es, Akti-vitatenabfolgen vorzudefinieren und alsMuster fur die Projektarbeit bereitzustel-len. Diese Muster werden in der Termino-logie des AE-Modells Prozessvarianten ge-nannt. Hierdurch kann eine Vielzahl vonAnforderungen einer großen Entwick-lungsorganisation abgedeckt werden. In[HeNo99] wird eine Heuristik beschrie-ben, wie aus den Zielen und Randbedin-gungen, die fur das jeweilige Projekt gelten,eine geeignete Prozessvariante ermitteltwerden kann.

In der aktuellen Version des AE-Modellsstehen funf solcher Prozessvarianten zurVerfugung:

& Inkrementelle Entwicklung& Komponentenbasierte Entwicklung& Phasenorientierte Entwicklung& Evolutionares Prototyping& Prasentationssystementwicklung.

Die ersten Vier spezifizieren unterschiedli-che Entwicklungsarten [HeNo99], dieFunfte wurde nachtraglich erganzt, um diesteigende Anzahl von Projekten zu unter-stutzen, die sich mit der Prasentation vonInformationen im WWW beschaftigen.Wir betrachten die Prozessvariante „Inkre-mentelle Entwicklung“ anschließend nochetwas detaillierter.

Ablaufe innerhalb der Prozessvariantenwerden durch einfache Diagramme (so ge-nannte Bubble-Charts) dargestellt, in de-nen Aktivitaten als Ovale und die Abarbei-tungsreihenfolge durch Pfeile dargestelltwerden. Zusatzliche Beschreibungsfelder,die nicht in den Diagrammen eingezeichnetsind, existieren, um eine parallele oder al-ternative Abarbeitung von Aktivitaten aus-zudrucken.

Bei der Bereitstellung der Prozessvariantenwird auf bestimmte Grundmuster zuruck-gegriffen, die als wiederverwendbare Ein-heiten der Softwareprozessmodellierungzu sehen sind. Das Grundmuster der Pro-jektabwicklung unterscheidet sich nichtvon den traditionellen Ansatzen der struk-turierten Entwicklung. Wir betrachten einBeispiel (Bild 5).

Beim Start eines Projekts (Hauptaktivitat„Projekt starten“) sind eine Reihe von Ini-tialisierungs- und Aufbauaktivitaten durch-zufuhren, bevor die eigentliche Projekt-arbeit (Hauptaktivitat „Projekt durchfuh-ren“) erfolgen kann. Diese wird vonAktivitaten zur Projektsteuerung begleitet(Hauptaktivitat „Projekt steuern“). Nacherfolgreicher Entwicklungsarbeit wird dasProjekt mit einer Reihe von Abschluss-arbeiten beendet (Hauptaktivitat „Projektabschließen“). Bild 5 zeigt den Ablauf aufder obersten Ebene, der fur alle Prozess-varianten identisch ist. Unterschiede in denVarianten ergeben sich durch die Verfeine-rung der Hauptaktivitat „Projekt durch-fuhren“.

Wir betrachten exemplarisch die weitereAusgestaltung der Hauptaktivitat „Projektdurchfuhren“ fur die Prozessvariante „In-


Tabelle 1 Beschreibungsraster Operationsmodellierung

Name Operationsmodellierung

Beschreibung Das Ziel ist die Modellierung von Klassenmethoden als Flowchart.Der Nutzen besteht darin, eine Klassenmethode so zu spezifizie-ren, dass sie realisiert oder generiert werden kann.Die Voraussetzung fur die Anwendung der Technik ist eine grobeBeschreibung der Methode.Das Ergebnis der Anwendung der Technik ist ein Operations-modell, reprasentiert durch ein oder mehrere Aktivitats-diagramme.Die einzelnen Arbeitsschritte sind:

1. Kontextbestimmung fur die Operation2. Identifizierung der Vor- und Nachbedingungen3. Spezifizierung von Aktionen4. Festlegung von Verzweigungen5. Festlegung von Nebenlaufigkeiten

Qualitatskriterien Der Kontext der Operation ist bestimmt.. . .

Ein Aktivitatsdiagramm ist erstellt, das einen Namen hat.

Vorausgesetztes Wissen & Kenntnisse von Algorithmen und Berechnungsverfahren& Technik Aktivitatsmodellierung

Literatur [Booch1999], [OMG1999]

318 Jorg Noack

krementelle Entwicklung“. Eine inkre-mentelle Entwicklung startet mit einersystemweiten Analyse (mit optionalerEntwicklung eines explorativen Prototypszur �berprufung der Analyseergebnisse)und besteht dann aus einer Folge von rela-tiv unabhangigen Inkrement-Entwicklun-gen (Bild 6). Das erste „Inkrement‘‘ bildetein Teilsystem mit eingeschrankter Funk-tionalitat, das aber selbstandig lauffahig istund den Systemkern fur die folgenden Er-weiterungen durch Inkremente bildet.Diese werden in eigenen Entwicklungs-zyklen, i. A. sequentiell nacheinander ent-wickelt.

Die Gesamtstruktur einer Prozessvarianteergibt sich durch die hierarchische Ver-knupfung der als Bubble-Charts dargestell-ten Teilablaufe. In der Browser-basiertenDarstellung (Bild 1) werden Verfeinerungs-beziehungen durch Links dargestellt, die inden Knoten hinterlegt sind.

4 Der Zuschnitteiner Prozessvariante

Die bereits fur die Browser-Losung zurPrasentation des Prozessrahmenwerks ent-wickelten Software-Komponenten konn-

ten ohne großere Modifikation auch furdie Werkbank ubernommen werden. Wirgehen daher im Weiteren nicht mehr aufdie Darstellung, sondern auf die Funktio-nalitat der Werkbank in der ersten Ausbau-stufe ein. Der fur das Vorgehensmodell imUnternehmen verantwortliche Prozess-ingenieur und der fur die Planung undUmsetzung eines Projektes verantwortlicheProjektleiter erarbeiten mit Hilfe der Werk-bank ein auf den Projektkontext zuge-schnittenes Vorgehensmodell. Bild 7 zeigtdas Prinzip des Arbeitens mit der Werk-bank, die generierten Ergebnisse und dieinvolvierten Akteure.

Das Projektvorgehensmodell wird zusam-men mit den relevanten Dokumenten alselektronisches Handbuch fur die Projekt-arbeit im Intranet zur Verfugung gestellt.Das Projekthandbuch dient als Orientie-rungshilfe und methodische Unterstutzungfur die Projektarbeit.

Zusatzlich wird ein initialer Projektplanfur ein Projektmanagement-Werkzeug ge-neriert, in den Projektbeteiligte und Kenn-daten eingetragen werden konnen. DerProjektplan dient der Projektekommissionals Informationsbasis fur die Budgetauslas-tung und als Hilfestellung fur die Mit-arbeiterzuordnung durch den Projektlei-ter.

Fur das fokussierte Projekt ist beim Startder Werkbank zunachst die Prozessvari-ante auszuwahlen, auf der das Projektvor-gehen beruhen soll. Anschließend erfolgtdie Auswahl der relevanten Aktivitaten. Zudiesem Zweck wurde anhand der Metaphereines Warenkorbs ein Selektionsmechanis-mus implementiert, der die Konsistenz deszusammengestellten Projektvorgehens-modells gewahrleistet.

Bild 8 zeigt einen Screenshot der Benut-zungsoberflache des Prototypen. Im linkenFenster wird die Prozessvariante der inkre-mentellen Entwicklung als Baum dar-gestellt. Das mittlere Fenster zeigt denAblauf in der aktuellen Ebene des Vor-gehensmodells in einem Bubble-Chart.Das rechte Fenster zeigt den aktuellenStand des mit der Werkbank hergeleitetenProjektvorgehensmodells. Beim Zuschnitteiner Prozessvariante ist zu entscheiden,welche Aktivitaten in das Projektvor-gehensmodell ubernommen werden sollen.

Zunachst wird das Grundmuster der Pro-jektabwicklung (Bild 5) fur das Projektvor-gehensmodell ubernommen, da es sich beiallen vier Aktivitaten um Pflichtaktivitatenhandelt. Anschließend erfolgt eine detail-lierte Betrachtung der Ablaufstrukturen,welche den Aktivitaten des Grundmustershinterlegt sind.


Prozessvariante

Aktivität Ergebnis

Technik

Rolleführt aus

unterstützt

+Subaktivität

+Hauptaktivität

+Teilergebnis

+Hauptergebnis+Input

+Output1..n

1..n

1..n

1..n1..n

0..n

0..n

0..n 0..n

1..n

0..n0..n

) Nachbe-dingung(Exit)Maße (Measurement)

Eingaben

(Input)

Ausgaben

(Output)

Rückkopplung

ein aus

Vorbe-dingung(Entry)

Aufgabe (Task) Nachbe-dingung(Exit)Maße (Measurement)

aus

Vorbe-dingung(Entry)

Projekt

starten

Projekt

steuern

Projekt

durchführen

Projekt

abschließen

Bild 3 Metamodell (Ausschnitt)

Bild 4 Allgemeines Beschreibungsmuster fur Aktivita-ten

Bild 5 Grundmuster der Projektabwicklung


Bild 8 zeigt auf, dass fur die Hauptaktivita-ten „Projekt starten“ und „Projekt steuern“bereits ein Zuschnitt vorgenommen wurdeund dass im Moment der Aufnahme desScreenshots der Baumknoten „Projektdurchfuhren (inkrementell)“ in Bearbeitungist. Als nachstes geht es nun darum, fur dieTeilaktivitaten von „Projekt durchfuhren“zu entscheiden, ob sie in das Projektvor-gehensmodell ubernommen werden sollen.

Die implementierte Zuschneidefunktionali-tat sieht vor, dass der Bediener anhand der

Ablaufstruktur durch den Prozess gefuhrtwird. Die Werkbank markiert alle in einerbestimmten Situation des Zuschnitts selek-tierbaren Aktivitaten in der Prozessvarian-te (Bild 8, linkes Fenster). Mit Hilfe deruber die rechte Maustaste aktivierbarenWarenkorb-Funktion kann der Bedienerdafur sorgen, dass bestimmte der markier-ten Aktivitaten in das Projektvorgehens-modell ubernommen werden. Wahlfreihei-ten bestehen allerdings nur dann, wenn essich bei den markierten Aktivitaten nichtum Pflichtaktivitaten handelt.

Wir betrachten die Situation, die zu dem inBild 8 dargestellten Ergebnis gefuhrt hat.Der Einstieg in die Projektdurchfuhrungbeginnt mit der Aktivitat „Analyse durch-fuhren“. Hierbei handelt es sich um einePflichtaktivitat, die in das Projektvor-gehensmodell ubernommen werden muss.Anschließend markiert die Werkbank diebeiden Aktivitaten „Explorativen Prototypentwickeln“ und „Inkremententwicklungdurchfuhren“. Die Bediener hat sich dafurentschieden, die optionale Aktivitat „Ex-plorativen Prototyp entwickeln“ auszulas-sen und mit der Aktivitat „Inkrementent-wicklung durchfuhren“ fortzufahren.

Die Prozessvariante sieht vor, dass dieseAktivitat beliebig haufig wiederholt wer-den kann. Beim Zuschnitt ist jedoch nunzu entscheiden, wie viele Inkremente imProjekt entwickelt werden sollen. Bild 8zeigt, dass die Aktivitat „Inkrementent-wicklung durchfuhren“ im Moment derAufnahme bereits zweimal in das Projekt-vorgehensmodell ubernommen wurde. Esbesteht nun die Moglichkeit, diese Aktivi-tat ein drittes Mal zu ubernehmen oder dasErgebnis zu speichern und die Planungs-ebene in einem konsistenten Zustand zuverlassen. Die Werkbank erlaubt dann spa-ter eine individuelle Feinplanung der ein-zelnen Inkremententwicklungen anhandder in der Prozessvariante hinterlegtenAblaufstrukturen.

Wie das Metamodell in Bild 3 aufzeigt, gibtes weitere Vorgehensmodellobjekte wie Er-gebnisse, Rollen und Techniken, die netz-artig mit den Aktivitaten verknupft sind.Beim Zuschnitt einer Prozessvariante stehtjedoch zunachst die Sicht auf die Aktivita-ten im Vordergrund.

5 Generierungeines elektronischenProjekthandbuchs

Mit Hilfe der Preview-Schaltflache wird ineine Ansicht des zugeschnittenen Projekt-vorgehensmodells gewechselt, die auch dieweiteren Vorgehensmodellobjekte anzeigt,welche mit den aktuell ausgewahlten Akti-vitaten verknupft sind (Bild 9).

Die Darstellung des Projektvorgehens-modells in der Vorschausicht ist baum-artig angeordnet. Der Einstieg erfolgtuber die vier Hauptknoten Aktivitaten,Rollen, Techniken und Ergebnistypen.


Projekt

starten

Projekt

steuern

Projekt durchführen

Projekt

abschließen

Analyse

durchführen

Explorativen

Prototyp

entwickeln

Inkrement-

Entwicklung

durchführen

Bild 6 Inkrementelle Entwicklung – Projekt durchfuhren

Projektleiter

mitarbeiterProjekt-

Prozessingenieur

Projekthandbuch

Projektplan

ProjektleiterProjektleiter Projekte-kommission

Vorgehensmodellwerkbank

Generierung

(PM-Werkzeug)

(Browser)Generierung

Bild 7 Werkbank-Komponenten und Akteure

320 Jorg Noack

Nach der Selektion eines Vorgehens-modellobjekts im Baum kann uber dierechte Maustaste ein Kontextmenu geoff-net werden, das eine Navigation in derdurch das Metamodell (vgl. Bild 3) be-schriebenen Verknupfungsstruktur er-laubt. So fuhrt fur die Aktivitat „Inkre-mententwicklung durchfuhren“ derEintrag „Ergebnistypen“ zur Liste derErgebnistypen, die wahrend des Entwick-lungsabschnitts zu erstellen sind und diedurch den Zuschnitt der Prozessvarianteimplizit festgelegt wurden. Der Eintrage„Rollen“ und „Techniken“ liefern die mitden ausgewahlten Aktivitaten der Inkre-mententwicklung verknupften Rollen so-wie die vom Projektleiter fur die Projekt-arbeit vorgesehenen Techniken.

Bild 3 zeigt auf, dass zwischen Technikenund Aktivitaten eine m:n-Beziehung im-plementiert wurde, wonach eine Technikbei der Durchfuhrung verschiedener Akti-vitaten helfen kann und umgekehrt eineAktivitat auf verschiedene Art und Weise,d. h. durch verschiedene Techniken, umge-setzt werden kann. Die fur jede Prozess-variante a priori vorgenommenen Ver-knupfungen zwischen Aktivitaten undTechniken konnen vom Projektleiter nach-traglich weiter eingeschrankt werden, umeine projektspezifische Vorgehensmetho-dik zu etablieren [Noac00b].

Die Vorschau dient dazu, den beteiligtenAkteuren Prozessingenieur und Projektlei-ter einen �berblick uber den aktuellenStand des Zuschnitts zu verschaffen. Solltesich herausstellen, dass es noch �nde-rungsbedarf fur das Projektvorgehens-modell gibt, so kann wieder in den Zu-schneide-Modus der Werkbank gewechseltwerden. Andernfalls wird uber die Schalt-flache „Projekthandbuch“ eine Web-ba-sierte Darstellung generiert, welche vonder Aufbereitung und den Navigations-moglichkeiten her der ursprunglichen Aus-lieferungsform des AE-Modells (Bild 1)ahnelt, nun jedoch ein auf den Projektkon-text zugeschnittenes Vorgehensmodell ent-halt.

6 Initialisierungdes Projektmanagement-Werkzeugs

Die Schaltflache „Projektplan“ dient dazu,die erste Fassung eines Projektablaufplanszu generieren. Bild 10 zeigt das Beispiel ei-

nes mit Hilfe des Projektmanagement-Werkzeugs MS Project visualisierten Plans.Die Aktivitatenabfolge wird durch einGantt-Diagramm prasentiert. Aktivitatenwerden in der Terminologie des PM-Werk-zeugs als Vorgange und Hauptaktivitatenwie „Projekt starten“, die weiter unterglie-

dert sind, als Sammelvorgange dargestellt.Anschließend ist mit Hilfe des Projekt-managementwerkzeugs die Dauer der Vor-gange festzulegen.

Die an den Aktivitaten beteiligten Rollenwerden als Ressourcen angezeigt. Das wei-


Bild 8 Zuschnitt einer Prozessvariante

Bild 9 Die Vorschau-Funktion


tere Vorgehen mit dem PM-Werkzeug siehtvor, dass den Aktivitaten nun konkreteProjektmitarbeiter zugeordnet werden.Der Abgleich der Know-how-Profile derfur das Projekt benannten Mitarbeiter mitden Beschreibungsrastern der Rollen imProjektvorgehensmodell dient dazu, um ineinem ersten Schritt festzustellen, welcherMitarbeiter welche Aktivitaten uberneh-men konnte. Die weitere Aufgabe in derProjektplanung besteht nun darin, unterBeachtung der zur Verfugung stehendenKapazitaten die Rollen mit qualifiziertenMitarbeitern zu besetzen. An dieser Stellewerden anhand des Projektvorgehens-modells eventuelle Defizite in der Mitarbei-terausstattung eines Projektes augenschein-lich. Der Projektleiter kann fruhzeitigGegenmaßnahmen einleiten, um den Risi-kofaktor „Fehlende Fahigkeiten und Fer-tigkeiten“ in Griff zu bekommen.

7 Status und Ausblick

Der Prototyp der Vorgehensmodell-Werk-bank wurde inzwischen fertiggestellt undan die IT-Entwicklungseinheiten in derSparkassen-Finanzgruppe ausgeliefert undin verschiedenen Unternehmen evaluiert.Die fur den Zuschnitt eines Prozessmodellsim Prototypen bereitgestellte Funktionali-

tat hat sich als praktikabel erwiesen. Diemit dem Werkbank-Prototypen angebote-nen Individualisierungsmoglichkeiten da-gegen wurden immer noch als unzurei-chend betrachtet. Dies hatte verschiedeneUrsachen. Zum einen bestand Bedarf – ne-ben der inkrementellen Entwicklung, wel-che im Prototypen angeboten wurde –weitere Prozessvarianten als Muster fur dieProjektarbeit zur Verfugung zu haben,zum anderen sollten die angebotenen In-halte starker an die Bedurfnisse des einzel-nen Unternehmens angepasst werdenkonnen. Gefordert wurden zusatzlicheFunktionalitaten, um Beschreibungen vonGrundbausteinen wie Aktivitaten, Rollenund Ergebnistypen abandern zu konnenund um unternehmensspezifische Ent-wicklungsstandards in das generierte Pro-jekthandbuch einbringen zu konnen. Zu-satzlich ergab sich die Anforderung, dassdas zugeschnittene Prozessmodell auchgrafisch im Projekthandbuch visualisiertwerden sollte.

Die Erkenntnisse aus der Evaluierung desPrototypen haben dazu gefuhrt, dass in derzweiten Ausbaustufe, welche nun alle funfProzessvarianten des AE-Modells unter-stutzt, zwischen Prozess- und Projekt-werkbank unterschieden wird. Die Pro-zesswerkbank dient der Herleitung vonProzessvarianten aus dem Referenzmodell,

die Projektwerkbank bietet die bereits mitdem Prototypen bereitgestellte Zuschnei-defunktionalitat.

Aus Sicht der Werkbank-Nutzer bestehendamit mehrere Moglichkeiten, um zu ei-nem individuellen Projektvorgehensmodellzu kommen:

& Einer der angebotenen Prozessvariantenwird mit Hilfe der Projektwerkbank aufdie Projektbedurfnisse zugeschnitten. Inder zweiten Ausbaustufe der Werkbankkonnen dann auch Beschreibungsrasterauf der Projektebene angepasst werden.

& Durch die Prozesswerkbank konnen diemitgelieferten Prozessvarianten an dieBedurfnisse einer IT-Organisationsein-heit so angepasst werden, dass kunftigmodifizierte Prozessvarianten als Mus-ter fur Entwicklungsprojekte in dieserIT-Organisationseinheit zur Verfugungstehen.

& Durch die Prozesswerkbank besteht da-ruber hinaus die Moglichkeit, weitereProzessvarianten wie z. B. fur ein leicht-gewichtiges Projektvorgehen zu spezifi-zieren. Dabei stehen die Grundbausteineaus dem Referenzmodell, die durch dasMetamodell vorgegebene Prozessstruk-tur sowie die Funktionalitaten fur dieProzessvisualisierung zur Verfugung,um mit begrenztem Aufwand zu einertragfahigen Losung zu kommen.

Literatur

[Beck00] Beck, K.: Extreme Programming. Addi-son-Wesley, Reading Mass. 2000.

[Cold02] Coldewey, J.: Multi-Kulti: Ein �berblickuber die agile Entwicklung. ObjektSpektrum1/2002, S. 69–77.

[DrHM98] Droschel, W.; Heuser, W.; Midder-hoff, R. (Hrsg.): Inkrementelle und objektorien-tierte Vorgehensweisen mit dem V-Modell 97.Oldenbourg, 1998.

[Fowl01] Fowler, M.: The New Methodology.http://www.martinfowler.com/articles/new-Methodology.html.

[GrHY97] Graham, I.; Henderson-Sellers, B.; You-nessi, H.: The OPEN Process Specification. Ad-dison-Wesley, Reading Mass. 1997.

[HeNo99] Hesse, W.; Noack, J.: A Multi-variantApproach to Software Process Modelling. Pro-ceedings CAiSE ’99, Springer LNCS 1626, 1999,S. 195–209.

[Hump89] Humphrey, W.: Managing the SoftwareProcess. Addison-Wesley, Reading Mass. 1989.

[IRFS01] IBM, Rational, Fujitsu/DMR, SOFT-TEAM et al.: Software Process EngineeringManagement – The Software Process Engineer-ing Metamodel (SPEM), Second Revised Sub-mission, OMG Document ad/2001-06-05.


Bild 10 Projektplan

322 Jorg Noack

[KnWi01] Kneuper, R., Wiemers, M. (Hrsg.):Leichte Vorgehensmodelle. 8. Workshop der GI-Fachgruppe 5.11, Glashutten/Ts. 2001, ShakerVerlag, 2001.

[Kruc99] Kruchten, P.: The Rational Unified Pro-cess. Addison-Wesley, Reading Mass. 1999.

[NoSc99] Noack, J.; Schienmann, B.: Objektorien-tierte Vorgehensmodelle im Vergleich. Informa-tik-Spektrum, Vol. 22, No. 3, 1999, S. 166–180.

[Noac00a] Noack, J.: Entwicklung, Einsatz undPflege von Vorgehensmodellen in der Sparkas-senorganisation. In: Andelfinger, U.; Herz-wurm, G.; Mellis, W., Muller-Luschnat, G.(Hrsg.): Vorgehensmodelle: Wirtschaftlichkeit,Werkzeugunterstutzung und Wissensmanage-ment. 7. Workshop der Fachgruppe 5.11 der Ge-sellschaft fur Informatik, Bonn 2000, Shaker Ver-lag, 2000, S. 1–16.

[Noac00b] Noack, J.: Extending the Software De-velopment Process with a Toolkit of UML-Centred Techniques. Proceedings SoftwareMethods and Tools 2000, Wollongong, IEEE,S. 87–96.

[Noac01] Noack, J. (Hrsg.): Techniken der objekt-orientierten Softwareentwicklung. Springer-Ver-lag, Berlin/Heidelberg 2001.

[OMG99] OMG: Software Process Engineering(SPE) Management – RFP. OMG Document ad/1999-11-04.


Abstract

A workbench for the adaption of object-oriented software processes

In software industry there is a controversial discussion on the usefulness of a unified softwareprocess. The contribution presents a pragmatic solution. A generic process framework canbe tailored to the needs of an individual development project with the help of a softwareprocess workbench. The core functionalities of the software process workbench, which iscurrently under development, are presented. First experiences from the user community andtheir influence on the next development stage of the workbench are discussed.

Keywords: software process engineering, incremental development, software engineeringtool, project planning, process framework

324 Jorg Noack

Documents

Eine Werkbank für den Zuschnitt von objektorientierten Softwareprozessen; A workbench for the adaption of object-oriented software processes;