Managementprozesse: Kapitel 9\nspeichernManagementprozesse.pdf für später speichern\n3 Ansichten55 Seiten\nCal Id Ad en Mode Los Uml\n066926 SP 2011 Fassung2012 Mas BusinessInformatics\nManagementprozesse befassen sich mit den verschiedenen Vorgehensweisen und Arbeitsabläufen, die eine geregelte Durchführung eines Software-Projekts innerhalb eines Unternehmens gewährleisten. Haben wir einen unternehmensspeziﬁschen Ar- beitsablauf vor uns, der sich in gleicher oder ähnlicher Form kontinuierlich wieder- holt, so sprechen wir von einem Prozess. Formal wird jeder Prozess über eine Reihe von Aktionen deﬁniert, die aus einer gegebenen Menge von Eingangsgrößen schritt- weise eine Menge von Ausgangsgrößen bilden (vgl. Abb. 9.1). Für die Durchfüh- rung einer einzelnen Aktion werden unterschiedliche Ressourcen benötigt, die sich auf der obersten Ebene in drei Kategorien einteilen lassen. Der ersten Kategorie wer- den alle produktspeziﬁschen Ressourcen wie Quelltexte und Planungsdokumente zugeordnet. Die zweite Kategorie umfasst die Software- und Hardware-Infrastruktur und die dritte Kategorie wird durch das zur Verfügung stehende Personal gebildet. Im Bereich des Software-Managements werden Vorgehensmodelle und Reife- gradmodelle unterschieden:\n■ Vorgehensmodelle Ein Vorgehensmodell legt fest, wie die Ausgangsgrößen eines Prozesses erar- beitet werden und bildet damit das Rückgrat des Projektmanagements. Typische Vorgehensmodelle zerlegen den Projektablauf in mehrere, konsekutiv durchlau- fene Phasen. Durch die zeitliche und inhaltliche Begrenzung der verschiedenen Phasen wird die Projektdurchführung überschaubar und damit in ihrer Gesamt- komplexität verringert. Über die letzten Jahrzehnte haben sich verschiedene stan- dardisierte Vorgehensmodelle herausgebildet, die konzeptuell erheblich vonein- ander abweichen. Nur in wenigen Fällen lassen sich Standardmodelle reibungsfrei auf eine ge- gebene Firmenorganisation abbilden. Ein Vorgehensmodell beschreibt stets einen idealisierten Projektverlauf und muss zunächst an die tatsächlichen Gegebenhei- ten angepasst werden (Individualisierung). Daher sind die weiter unten vorge- stellten Vorgehensmodelle in der Praxis nur vereinzelt in ihrer Reinform anzu- treffen.\nAbb. 9.1 Prozesse beschreiben sich stets wiederholende Arbeitsabläufe eines Unternehmens\n■ Reifegradmodelle Reifegradmodelle verfolgen das Ziel, die Arbeitsabläufe eines Unternehmens zu analysieren und zu optimieren. Hierzu werden die Prozesse einer Organisation anhand einer deﬁnierten Systematik auf Projekt- und Unternehmensebene be- wertet und die gewonnenen Ergebnisse anschließend in Maßnahmen zur Pro- zessverbesserung umgesetzt. Neben der Schaffung produktiver Entwicklungsprozesse zielen Reifegradmo- delle vor allem auf die Optimierung der Organisationsstrukturen ab. Hierzu zäh- len unter anderem die eindeutige Verteilung von Rollen und Verantwortlichkei- ten, die Etablierung transparenter Kommunikationswege und die Deﬁnition klar geregelter Eskalationsmechanismen. Damit unterscheidet sich die Zielsetzung ei- nes Reifegradmodells grundsätzlich von der eines Vorgehensmodells. Während Vorgehensmodelle Eckpunkte und Maßnahmen für die konkrete Projektdurch- führung deﬁnieren, liefern Reifegradmodelle die quantitative Basis, um steuernd in die Arbeitsabläufe und Organisationsstrukturen einzugreifen.\nIm Folgenden werden wir diejenigen Vorgehens- und Reifegradmodelle genauer beleuchten, die in der industriellen Software-Entwicklung heute eine bedeutende Rolle spielen. Wir beginnen unseren Streifzug in Abschnitt 9.1 mit der Vorstellung der gängigen Vorgehensmodelle. Neben einem Rückblick auf die historischen Wur- zeln werden wir das V-Modell, den Rational Uniﬁed Process (RUP) sowie das ver- gleichsweise neue Modell des Extreme Programmings (XP) im Detail betrachten. Im Anschluss daran werden wir in Abschnitt 9.2 mit dem CMM, CMMI und SPI- CE drei der am weitesten verbreiteten Reifegradmodelle genauer unter die Lupe nehmen.\nOperational Speci ﬁ cation\nProgram Speci ﬁ cation\nCoding speci ﬁ cations\nParameter Testing (Speci ﬁ cations)\nAssembly Testing (Speci ﬁ cations)\nMachine Speci ﬁ cation\nAbb. 9.2 Ein Stück Geschichte: Das Stagewise model aus dem Jahre 1956\nDie steigende Komplexität moderner Software-Systeme macht es heute in immer stärkerem Maße erforderlich, die Entwicklung zu systematisieren und in Form von bewährten Methodiken (best practices) durchzuführen. Die Wurzeln moderner Vor- gehensmodelle lassen sich bis in die frühen Tage der Software-Technik zurückver- folgen. Der erste Grundstein wurde von Herbert D. Benington im Jahre 1956 und damit zeitgleich mit der Entwicklung der ersten Hochsprachen gelegt. Mit dem Sta- gewise model schlug er eine phasenorientierte Vorgehensweise für die Software- Entwicklung vor, die bereits viele Elemente moderner Vorgehensmodelle in sich trägt (vgl. Abb. 9.2) . Winston W. Royce entwickelte die Ideen von Benington weiter und veröffent- lichte im Jahre 1970 ein Vorgehensmodell, das heute vor allem unter dem Namen Wasserfallmodell bekannt ist . Royce selbst bezeichnete die von ihm postulier- te Vorgehensweise schlicht als “Implementation steps to develop a large program for delivery to a customer”. Der heute geläuﬁge Name Wasserfallmodell wurde erst 11 Jahre später durch den amerikanischen Software-Ingenieur Barry W. Boehm ge- prägt . Abb. 9.3 zeigt den Aufbau des Wasserfallmodells in der ursprünglich von Roy- ce publizierten Form. Das Modell besteht aus insgesamt 7 Phasen, die kontinuier-\nAbb. 9.3 Das Wasserfallmodell aus dem Jahre 1970\nlich durchlaufen werden. Jedes Projekt beginnt mit der Analyse der Anforderun- gen. Royce sieht hierfür zwei Stufen vor, in denen die System- und die Software- Anforderungen in zeitlich getrennter Reihenfolge erstellt werden. Anschließend werden die Analyse-, Entwurfs- und Implementierungsphase durchlaufen. Sind die- se vollständig abgearbeitet, so liegt als Ergebnis das fertige Software-System vor, das in den beiden letzten Phasen getestet und an den Kunden übergeben wird. In einem idealisierten Projektverlauf werden die verschiedenen Phasen des Was- serfallmodells streng sequenziell durchlaufen. Wie in Abb. 9.3 bereits eingezeich- net, sieht Royce zusätzliche Rückkopplungsschleifen vor, die ein gewisses Vor und Zurück zwischen den Phasen zulässt. Um die serielle Natur des Modells nicht auf- zubrechen, ist ein Rücksprung jedoch auf die jeweils direkt vorangehende Phase beschränkt. Wurde eine Phase erfolgreich abgeschlossen, so wird der Projektfort- schritt in einem Dokument ﬁxiert. Royce verwirklichte damit bereits sehr früh zwei Schlüsselkonzepte, die in den meisten modernen Vorgehensmodellen in ganz ähnli- cher Form vorhanden sind: Dokumente und Meilensteine.\n■ Dokumente Das Wasserfallmodell ist dokumentengetrieben und unterstreicht hierdurch die Tatsache, dass Software aus mehr als nur den Quelltexten besteht. Wie ein Blick in die Originalarbeit zeigt, nimmt die Dokumentation für Royce eine zentrale Rolle in der gesamten Software-Entwicklung ein:\n“At this point it is appropriate to raise the issue of – «how much docu-\nmentation?» My own view is «quite a lot;» certainly more than most pro- grammers, analysts, or program designers are willing to do if left to their own devices. The ﬁrst rule of managing software development is ruthless\nenforcement of documentation requirements. [\nis simply impossible without a very high degree of documentation. As an example, let me offer the following estimates for comparison. In order to\nprocure a 5 million dollar hardware device, I would expect that a 30 page speciﬁcation would provide adequate detail to control the procurement. In order to procure 5 million dollars of software I would estimate a 1500 page speciﬁcation is about right in order to achieve comparable control.”\n■ Meilensteine Die systematische Erstellung von Dokumenten trägt dazu bei, dass die einzelnen Projektphasen durch klar deﬁnierte Meilensteine voneinander getrennt werden. Diese machen den Projektfortschritt messbar und stellen für Royce gleichzeitig eine Art Rückfallposition dar. Stagniert der Projektfortschritt in einer Phase, so kann ein Projekt jederzeit auf einem klar deﬁnierten Zwischenstand wieder auf- setzen:\n“At any point in the design process after the requirements analysis is com- pleted there exists a ﬁrm and closeup, moving baseline to which to return in the event of unforeseen design difﬁculties. What we have is an effecti- ve fallback position that tends to maximize the extent of early work that is salvageable and preserved.”\nZurückblickend stellt das Wasserfallmodell ein wichtiges Etappenziel in der Ent- wicklung der Vorgehensmodelle dar – insbesondere ﬁnden sich die Kernelemente in nahezu allen modernen Modellen in der einen oder anderen Form wieder. In sei- ner Reinform hat das Wasserfallmodell heute jedoch keinerlei praktische Relevanz. Zwei entscheidende Nachteile sind hierfür maßgeblich verantwortlich:\n■ Mangelnde Flexibilität Die streng konsekutive Abarbeitung der einzelnen Phasen ist in der Praxis nicht durchzuhalten. So beruht das Modell, wie leider viele andere auch, auf der idea- lisierten Annahme, dass die Anforderungen an ein Software-System von Anfang an vollständig vorliegen und über die gesamte Projektdauer stabil bleiben. In der Praxis ist diese Annahme schlicht nicht gegeben – in nahezu allen Projekten sind die Anforderungen zu Projektbeginn unvollständig, zweideutig oder sogar in Teilen widersprüchlich. Zusätzlich äußern die meisten Kunden im Laufe eines Projekts Änderungswünsche, die in geeigneter Weise zu berücksichtigen sind. Modelle, die an dieser Stelle die realen Gegebenheiten außer Acht lassen, sind in der Praxis schlicht zum Scheitern verurteilt. Zu diesen gehört auch das Wasser- fallmodell, das auf einer völlig statischen Sichtweise beruht.\n■ Trennung von Implementierung und Test Im Wasserfallmodell sind die Software-Implementierung und der Software-Test zwei voneinander getrennte Vorgänge. Der Software-Test ﬁndet ausschließlich am Ende des Projekts statt und wird erst dann durchgeführt, wenn die Imple- mentierung bereits abgeschlossen ist. Diese Vorgehensweise konterkariert nahe-\nzu alle gängigen Praktiken der Software-Entwicklung. Selbst unerfahrene Pro- grammierer lernen schnell, wie wertvoll eine frühzeitige Fehlererkennung für die produktive Arbeit ist. Die Behebung spät erkannter Fehler verursacht nicht selten einen erheblichen Mehraufwand und zieht in einigen Fällen sogar grund- legende Änderungen in der Software-Architektur nach sich. Aus diesem Grund verzahnen erfahrene Programmierer die Implementierungs- und Testaktivitäten lückenlos ineinander und brechen den Phasengedanken des Wasserfallmodells an dieser Stelle vollständig auf.\nViele Experten sehen in der strikten Trennung von Implementierung und Test den eigentlichen Schwachpunkt des Wasserfallmodells. Bemerkenswerterweise ist sich Royce dieser Kehrseite seines Modells durchaus bewusst, wie ein erneuter Blick in die Originalarbeit aus dem Jahre 1970 belegt:\n“I believe in this concept, but the implementation described above is risky\nThe testing phase which occurs at the end of the\ndevelopment cycle is the ﬁrst event for which timing, storage, input/output\ntransfers, etc., are experienced as distinguished from analyzed. These phe-\nYet if these phenomena fail to\nsatisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not ﬁx these kinds of difﬁculties. The required design changes are likely to be so disruptive that the software requirements upon which the design is ba- sed and which provides the rationale for everything are violated. Either the requirements must be modiﬁed, or a substantial change in the design is re- quired. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.”\nand invites failure. [\nnomena are not precisely analyzable. [\nDas V-Modell ist eine Erweiterung des Wasserfallmodells, das zahlreiche Aspekte der Software-Qualitätssicherung zusätzlich in das Modell integriert. Wie in Abb. 9.4 dargestellt, bleiben die Kernphasen des Wasserfallmodells erhalten, werden jedoch durch einen zusätzlich hinzugefügten Ast komplettiert. Jede vertikale Ebene spie- gelt eine bestimmte Entwicklungsstufe wider, deren Abstraktionsgrad sich von oben nach unten kontinuierlich verringert. Der linke Zweig des Modells repräsentiert die einzelnen Entwicklungsschritte und der rechte Zweig die hieraus abgeleiteten Qua- litätsmaßnahmen der gleichen Abstraktionsebene. Wie die Achsenbeschriftung in Abb. 9.4 zeigt, führt das V-Modell eine Unter- scheidung der Begriffe Veriﬁkation und Validation ein:\n■ Validation Im Rahmen der Validation wird die Speziﬁkation eines Produkts im Hinblick auf den geplanten Einsatzzweck überprüft. Ob die Speziﬁkation im Rahmen der\nSpezi ﬁ kation\nVeri ﬁ kation\nAbb. 9.4 Das V-Modell\nSoftware-Entwicklung fehlerfrei implementiert wurde, spielt für die Validation eine untergeordnete Rolle. Im Vordergrund steht die prinzipielle Tauglichkeit des Endprodukts und damit die Frage, ob das speziﬁzierte System den Anforderun- gen und Wünschen des Kunden entspricht.\n■ Veriﬁkation Im Zuge der Veriﬁkation wird überprüft, ob das entwickelte Produkt die Spe- ziﬁkation erfüllt. Kurzum: Die Implementierung wird gegen die Speziﬁkation abgeglichen. Die Speziﬁkation selbst wird nicht in Frage gestellt und als korrekt vorausgesetzt. Der klassische Software-Test fällt vollständig in den Bereich der Veriﬁkation – hier wird das gemessene Ist-Ergebnis mit dem aus der Speziﬁkati- on abgeleiteten Soll-Ergebnis abgeglichen.\nInsgesamt forciert das V-Modell, wie auch das Wasserfallmodell, den klassischen Top-Down-Entwurf . Die einzelnen Phasen werden im Idealfall konsekutiv durch- laufen, wobei zwischen zwei benachbarten Phasen Übergänge in beide Richtun- gen möglich sind. Zwischen den Entwicklungsphasen des linken Zweigs und den Veriﬁkations- und Validationsphasen des rechten Zweigs besteht ein unmittelbarer Zusammenhang, der in Abb. 9.4 durch die waagerechten Pfeile symbolisiert wird. Es werden die Ergebnisse der verschiedenen Entwicklungsphasen unmittelbar für die Ableitung der Testfälle verwendet, die in den späteren Veriﬁkations- und Vali- dationsphasen zur Überprüfung der Programm- und Systemkomponenten eingesetzt werden. Die Ableitung der Testfälle erfolgt bereits während der Entwicklung, so\n* zu anderen\nAbb. 9.5 Vorgehensbausteine des V-Modells XT\ndass zwischen den beiden Zweigen eine engere Bindung besteht, als die klassischen Visualisierungen des Modells auf den ersten Blick suggerieren.\n9.1.2.1 V-Modell XT\nDas in Abb. 9.4 skizzierte V-Modell wurde in den Folgejahren in verschiedene Rich- tungen weiterentwickelt. Eine dieser Weiterentwicklungen ist das V-Modell XT (XT = eXtreme Tailoring), das im Jahre 2005 in der Version 1.0 veröffentlicht wurde und heute für die Planung und Durchführung von IT-Projekten des Bundes verbindlich vorgeschrieben ist [70, 219]. Jeweils zum 1. Februar und 1. August eines Jahres sieht das Modell eine Aktualisierungsmöglichkeit vor. Die bis dato letzte Aktualisierung wurde am 1. Februar 2006 mit dem Erscheinen der Version 1.2 vollzogen . Mit dem V-Modell XT wurde ein umfangreiches Vorgehensmodell geschaffen, das die V-förmige Vorgehensweise aus Abb. 9.4 in sich integriert, darüber hinaus jedoch nur wenig mit dem ursprünglichen Modell gemeinsam hat. Das Fundament des V-Modells XT wird durch verschiedene Vorgehensbaustei- nen gebildet (vgl. Abb. 9.5). Für die gängigen Aufgabenstellungen eines Projekts hält das Modell eine Reihe vordeﬁnierter Bausteine vor, die das Zusammenspiel von Produkten, Aktivitäten und Rollen festlegen. Die Produkte eines Bausteins entspre- chen den Arbeitsergebnissen, die durch die festgelegten Aktivitäten erzeugt werden. Innerhalb eines Vorgehensbausteins lässt die Deﬁnition von Teilaktivitäten und un- tergeordneten Produkten (Themen) eine hierarchische Gliederung entstehen. Über deﬁnierte Rollen legt jeder Vorgehensbaustein die Verantwortlichkeiten für die ver- schiedenen Produkte und Aktivitäten fest. Die Vorgehensbausteine sind in sich ab- geschlossen, interagieren jedoch miteinander über den Austausch der Arbeitsergeb- nisse. Die Deﬁnition entsprechender Abhängigkeiten und Querverbindungen ist ex- pliziter Bestandteil des Modells. Das V-Modell XT trägt der Tatsache Rechnung, dass verschiedene Projekte in der Praxis unterschiedlich ablaufen und einer individuellen Anpassung der Arbeitsab- läufe bedürfen. Um ein möglichst breites Spektrum abzudecken, wird jedes Projekt anhand gewisser charakteristischer Eigenschaften klassiﬁziert und einem hieraus\nabgeleiteten Projekttypus zugeordnet. Der Typ eines Projekts wird zum einen durch den Projektgegenstand und zum anderen durch die Projektrolle bestimmt:\n■ Projektgegenstand Mit dem Begriff des Projektgegenstands wird im V-Modell XT das Ergebnis be- zeichnet, das im Rahmen eines Projekts erarbeitet wird. In den meisten Fällen ist der Projektgegenstand ein zu erstellendes System, das einer der folgenden fünf Kategorien zugeordnet werden kann:\n– Komplexes System\n– Eingebettetes System\nAlternativ kann sich der Projektgegenstand auf die Einführung und Pﬂege ei- nes organisationsspeziﬁschen Vorgehensmodells beziehen. Dieser Projektgegen- stand nimmt im V-Modell XT eine besondere Stellung ein.\n■ Projektrolle Das V-Modell XT deﬁniert 6 verschiedene Projektrollen, die primär das Auftraggeber- und Auftragnehmerverhältnis charakterisieren. Von außen be- trachtet kann ein Projekt als Auftraggeber (AG), als Auftragnehmer (AN) oder in beiden Rollen zusammen (AG/AN) agieren. Werden zusätzlich die verschie- denen Möglichkeiten der Unterauftragsvergabe berücksichtigt, ergeben sich die folgenden 6 Projektrollen des V-Modells XT:\n– Auftraggeber mit einem Auftragnehmer\n– Auftraggeber mit mehreren Auftragnehmern\n– Auftragnehmer ohne Unterauftragnehmer\n– Auftraggeber mit Unterauftragnehmern\n– Auftraggeber/-nehmer ohne Unterauftragnehmer\n– Auftraggeber/-nehmer mit Unterauftragnehmern\nJede Rolle ist im V-Modell XT mit zusätzlichen Aufgaben assoziiert, die den Besonderheiten der jeweiligen Projektkonstellation Rechnung tragen.\nAnhand des Projektgegenstands und der Projektrolle wird im V-Modell XT der Typ eines Projekts abgeleitet. Jeder Projekttyp wird durch eine bestimmte Projektdurch- führungsstrategie beschrieben. Diese deﬁniert eine Menge verpﬂichtender sowie ei- ne Menge optionaler Vorgehensbausteine, die zur Projektdurchführung zwingend\nKon ﬁ gurationsmanagement\n5 Lieferung und Abnahme (AG)\n6 Vertragsabschluss (AG)\n8 Evaluierung von\n11 Messung und Analyse\n12 Lieferung und Abnahme (AN)\nEinführung und P ﬂ ege eines\nDieser Baustein ist Bestandeil\nder folgenden Projekttypen\nTyp 1: Systementwicklungsprojekt (AG)\nTyp 2: Systementwicklungsprojekt (AN)\nTyp 3: Systementwicklungsprojekt (AG/AN)\nAbb. 9.6 Zuordnung der Vorgehensbausteine zu den verschiedenen Projekttypen\nvorgeschrieben sind oder zusätzlich in die Arbeitsabläufe integriert werden können. Abb. 9.6 fasst die Zuordnung der Vorgehensbausteine in Abhängigkeit des Projekt- typs zusammen. Die verschiedenen Vorgehensbausteine eines Projekttyps werden in Form eines Ablaufrahmens miteinander verknüpft, der jedes Projekt auf natürliche Weise in verschiedene Projektabschnitte gliedert. Um einen Projektabschnitt erfolgreich ab- zuschließen, muss ein entsprechender Entscheidungspunkt erfolgreich durchlaufen werden. Entscheidungspunkte sind ein wesentliches Element des V-Modells XT und dienen zum einen der Überprüfung der geforderten Qualitätsparameter und zum an- deren der Messung des Projektfortschritts.\n■ Systementwicklungsprojekt (AG)\n■ Systementwicklungsprojekt (AG/AN)\n■ Systementwicklungsprojekt (AN)\n■ Vorgehensmodell (Einführung und Pﬂege)\nSystementwicklung Organisationsspezi ﬁ sches Vorgehensmodell\nAbb. 9.7 Ablaufrahmen und Entscheidungspunkte der vier Projekttypen des V-Modells XT\nInsgesamt unterscheidet das V-Modell XT vier verschiedene Projekttypen, die sich bezüglich des Ablaufrahmens und den zu durchlaufenden Entscheidungspunk- ten deutlich voneinander unterscheiden (vgl. Abb. 9.7):\n■ Systementwicklungsprojekt (AG) Hier agiert das betrachtete Unternehmen als Auftraggeber. In Projekten dieses Typs liegt der erste Schwerpunkt auf der Delegation der Projektdurchführung an einen geeigneten Auftragnehmer. Die hierzu benötigten Vorgehensbausteine umfassen unter anderem die Projektausschreibung, die Bewertung sowie die Be-\nauftragung des ausgewählten Auftragnehmers. Bei der Entwicklung des Systems ist das Unternehmen selbst nicht beteiligt. Folgerichtig wird der zweite Schwer- punkt dieses Projekttyps durch die Systemabnahme gebildet.\n■ Systementwicklungsprojekt (AN) In Projekten dieses Typs agiert das betrachtete Unternehmen als Auftragnehmer. Im Rahmen des Projekts müssen zunächst Angebote erstellt und im Falle einer Auftragserteilung entsprechende Verträge geschlossen werden. Nach einem er- folgreichen Vertragsabschluss wird das vereinbarte System entwickelt, getestet und anschließend an den Auftraggeber ausgeliefert.\n■ Systementwicklungsprojekt (AG/AN) Auftraggeber und Auftragnehmer sind nicht in jedem Fall getrennte Unterneh- men. In vielen Projekten agiert ein Unternehmen in beiden Rollen zugleich. Dies ist immer dann der Fall, wenn ein Projekt vollständig innerhalb einer Organisa- tion durchgeführt wird – in diesem Fall werden der Auftraggeber und der Auf- tragnehmer häuﬁg durch verschiedene Fachabteilungen repräsentiert. Ebenfalls in diese Kategorie fallen Projekte, in denen zwei oder mehrere Unternehmen im Rahmen einer speziellen Kooperation sehr eng zusammenarbeiten. Im Gegensatz zu Projekten, in denen das Unternehmen entweder als Auftraggeber oder als Auf- tragnehmer auftritt, erübrigt sich bei dieser Konstellation die Ausschreibungs- und Vertragsphase. Zusätzlich entfällt die im Falle zweier unabhängig operieren- den Unternehmen unvermeidliche Doppelorganisation.\n■ Einführung und Pﬂege eines organisationsspeziﬁschen Vorgehensmodells Dieser Projekttyp beschäftigt sich mit der Etablierung eines Vorgehensmodells innerhalb eines Unternehmens und unterscheidet sich damit grundlegend von al- len anderen der hier vorgestellten Typen. Die hierfür notwendigen Schritte um- fassen die Analyse eines etwaig vorhandenen Vorgängermodells, die Erarbeitung von Verbesserungsmaßnahmen sowie das Ausrollen des optimierten Modells auf die verschiedenen Abteilungen des Unternehmens.\n9.1.3 Rational Uniﬁed Process\nDer Rational Uniﬁed Process (RUP) wurde von der Firma Rational ins Leben ge- rufen und ist eng mit deren Unternehmensgeschichte verknüpft. In den Achtziger- und Neunzigerjahren entwickelte das Unternehmen mit dem Rational Approach ein inkrementelles Vorgehensmodell, das in seinen Grundzügen auf das Spiralmodell von Barry W. Boehm zurückgeht [28, 29]. Im Jahre 1995 fusionierte Rational mit dem Unternehmen Objectory AB, das mit dem Objectory Process ein eigenes Vor- gehensmodell in das neue Unternehmen einbrachte. Der Rational Approach und der Objectory Process wurden im Jahre 1996 zum Rational Objectory Process vereint. Dieser wurde in den Folgejahren stetig weiterentwickelt und mit dem Erscheinen der Version 5.0 im Jahre 1998 schließlich in den Rational Uniﬁed Process umbe- nannt. Heute wird die Entwicklung vor allem durch die Firma IBM vorangetrieben,\ndie durch den Kauf von Rational im Jahre 2003 auch das Vorgehensmodell über- nahm. Das Fundament des Rational Uniﬁed Process besteht aus insgesamt 6 best prac- tices, die allgemein anerkannte und in der Vergangenheit bewährte Arbeitsabläufe und Vorgehensweisen in sich vereinen:\n■ Iterative Software-Entwicklung Der Rational Uniﬁed Process trägt der Tatsache Rechnung, dass komplexe Software-Systeme in der Praxis nicht in Form eines streng sequenziell durchlau- fenen Modells entwickelt werden können. RUP forciert stattdessen ein iteratives Vorgehen, das ein Produkt schrittweise wachsen lässt. Am Ende jeder Iteration steht ein funktionsfähiger Software-Prototyp. Die kontinuierliche Erstellung von Zwischenprodukten besitzt mehrere ent- scheidende Vorteile. Zum einen lässt sich hierdurch der aktuelle Projektfort- schritt auf objektive Art und Weise ermitteln. Zum anderen wird die Kommu- nikation mit der Kundenseite deutlich erleichtert und Abweichungen zwischen dem real entwickelten und dem gewünschten Produkt in einer frühen Projekt- phase erkannt. Die Entwicklung wird dabei stets durch ein aktives Risikomana- gement begleitet. Hierzu werden die Risiken in jeder Projektphase bewertet und in die Planung der nächsten Arbeitsschritte einbezogen.\n■ Anforderungsmanagement Der Rational Uniﬁed Process beschreibt ausführlich die verschiedenen Bereiche des Anforderungsmanagements. Hierzu gehören die Herausarbeitung, die Orga- nisation und die Dokumentation der Anforderungen eines Software-Systems. Für die Anforderungsbeschreibung greift RUP extensiv auf den Formalismus der Use cases zurück, die wir bereits in Abschnitt 4.3.4 im Zusammenhang mit der Kon- struktion von Black-Box-Tests kennen gelernt haben.\n■ Komponentenbasierte Architekturen Durch die iterative Vorgehensweise entsteht das erste funktionsfähige Software- System zu einem vergleichsweise frühen Projektzeitpunkt. Um eine schrittweise Weiterentwicklung in verschiedene Richtungen zu ermöglichen, wird eine ro- buste und ﬂexible Software-Architektur angestrebt. RUP verfolgt hierzu einen komponentenbasierten Ansatz. Eine Komponente im Sinne des Rational Uni- ﬁed Process ist ein nichttriviales Software-Modul, das eine semantisch klar um- rissene Aufgabe vollzieht. RUP beschreibt ein systematisches Vorgehen für die Erstellung einer adäquaten Software-Architektur. Die Wiederverwendbarkeit be- stehender Komponenten wird hierbei explizit angestrebt.\n■ Visuelle Software-Modellierung Für die Verhaltens- und Strukturbeschreibung eines Software-Systems greift der Rational Uniﬁed Process auf visuelle Modelle zurück. Der Einsatz einer graﬁ- schen Repräsentation erlaubt es, von den technischen Details eines Software- Systems zu abstrahieren und ist mit der Hoffnung verbunden, die Systemkom- plexität auf ein handhabbares Maß zu reduzieren. Die Grundlage für die visuelle\nDarstellung von RUP bildet die Uniﬁed Modeling Language (UML). Dass in diesem Modell ausgerechnet die UML als Modellierungssprache zum Einsatz kommt ist bei weitem kein Zufall. Schließlich war es das Unternehmen Ratio- nal selbst, das die UML in den Neunzigerjahren als Modellierungssprache ent- wickelte.\n■ Software-Qualitätskontrolle Die Software-Qualitätssicherung ist ein weiteres Kernelement des Rational Uni- ﬁed Processes. Das Vorgehensmodell unterstützt den Software-Entwickler bei der Planung, dem Entwurf, der Implementierung und der Ausführung speziel- ler Tests, die der Sicherstellung der verschiedenen Qualitätsparameter dienen. Hierzu gehören insbesondere die Zuverlässigkeit, die Funktionalität und die Applikations- und System-Performance der erstellten Software-Artefakte. RUP integriert zahlreiche Assessment-Maßnahmen in den Prozess, mit deren Hilfe die verschiedenen Qualitätsparameter sowie der Projektfortschritt einer möglichst objektiven Messung unterzogen werden sollen.\n■ Software-Änderungskontrolle Durch ein deﬁniertes Change-Management trägt der Rational Uniﬁed Process der Tatsache Rechnung, dass Software ständigen Änderungen unterliegt. Das ite- rative Vorgehen von RUP fordert, dass Modiﬁkationen kontrolliert eingepﬂegt werden, ohne die Stabilität des erreichten Projektzustands zu gefährden. Das Vor- gehensmodell deﬁniert hierzu mehrere Arbeitsabläufe für die Verwaltung und die geregelte Durchführung von Änderungen. Eine wichtige Rolle spielt in diesem Zusammenhang die Versionskontrolle, die zum einen alle Artefakte transparent verwaltet und durch die Schaffung individuell abgeschotteter Arbeitsumgebun- gen die Voraussetzung für die Team-Arbeit innerhalb eines Projekts schafft.\nDer Rational Uniﬁed Process wird in zwei Prozessdimensionen beschrieben, die in Abb. 9.8 auf der x- bzw. y-Achse aufgetragen sind. Die horizontale Achse beschreibt den zeitlichen Ablauf eines Projekts und stellt damit die dynamischen Aspekte in den Vordergrund. Die Entwicklung eines Software-Systems ﬁndet im Rational Uni- ﬁed Process in mehreren Zyklen statt. In jedem einzelnen wird ein neues Software- System erstellt, das sich von Generation zu Generation dem speziﬁzierten Endpro- dukt annähert. Jeder Zyklus besteht aus insgesamt vier Phasen, die nacheinander durchlaufen werden:\n■ Konzeptionsphase (Inception Phase) Zu Beginn werden die Ziele für den aktuellen Entwicklungszyklus deﬁniert und ein erster Grobentwurf des zu erstellenden Software-Systems angefertigt. Für die Entwurfsbeschreibung werden zunächst die wichtigsten Geschäftsvorfälle bestimmt und deren Ablauf anschließend mit Hilfe von Use cases modelliert. Des Weiteren werden in dieser Phase der Projektumfang und die zu erwarten- den Kosten geschätzt sowie die größten Gefahren des Projekts im Rahmen einer Risikoanalyse identiﬁziert.\nCon ﬁ guration and\nWork ﬂ ows\nAbb. 9.8 Rational Uniﬁed Process (RUP)\n■ Entwurfsphase (Elaboration Phase) In dieser Phase werden die genauen Produkteigenschaften deﬁniert und in Form einer Speziﬁkation niedergeschrieben. Darauf aufbauend wird die Systemarchi- tektur entworfen und das weitere Vorgehen geplant. Hierunter fallen die Festle- gung der in den nächsten Phasen durchzuführenden Aktivitäten sowie die Bereit- stellung der benötigten Ressourcen.\n■ Entwicklungsphase (Construction Phase) Die eigentliche Produktentwicklung ﬁndet in dieser Phase statt. Hierzu gehören die Ausarbeitung der Feinarchitektur, die Erstellung der Implementierung sowie alle Aspekte der Veriﬁkation und Validation. Am Ende dieser Phase steht ein voll funktionsfähiges Produkt, das für die Übergabe an den Kunden vorbereitet ist.\n■ Produktübergabe (Transition Phase) Diese Phase fasst alle Aktivitäten zusammen, die sich mit der Übergabe des ent- wickelten Produkts an den Kunden beschäftigen. Die Tätigkeiten umfassen die Produktfreigabe, die Durchführung von Abnahmetests sowie die Auslieferung und Installation des fertigen Systems. Aktivitäten, die nach der Auslieferung des Produkts durchgeführt werden, sind ebenfalls dieser Phase zuzuordnen. Neben den üblichen Support- und Wartungsarbeiten fallen z. B. auch Beratungs- und Trainingsmaßnahmen in diese Rubrik.\nDie vertikale Achse des in Abb. 9.8 dargestellten Prozessmodells spiegelt die stati- sche Prozesssicht wider. RUP deﬁniert insgesamt 9 sogenannte Workﬂows, die eine inhaltliche Gruppierung der Aktivitäten und Arbeitsabläufe des Prozesses vorneh- men. Die Workﬂows\n■ Project management workﬂow,\n■ Conﬁguration and change management workﬂow,\n■ Environment workﬂow\nüben eine unterstützende Funktion innerhalb eines Software-Projekts aus. Unter an- derem sind dort alle Aktivitäten enthalten, die der Bereitstellung der technischen Infrastruktur dienen und die Projektdurchführung in organisatorischer Hinsicht un- terstützen. Im Gegensatz hierzu decken die Workﬂows\n■ Business modeling workﬂow,\n■ Requirements workﬂow,\n■ Analysis and design workﬂow,\n■ Implementation workﬂow,\n■ Test workﬂow,\n■ Deployment workﬂow\nalle Aktivitäten ab, die sich in direkter Weise mit der Erstellung des Software- Systems beschäftigen. Sie werden in der RUP-Terminologie auch als Core enginee- ring workﬂows bezeichnet. Obwohl die Namen der Workﬂows große Gemeinsam- keiten mit den Phasenbezeichnungen des Wasserfallmodells aufweisen, unterschei- den sich beide Vorgehensmodelle in einem zentralen Punkt. Während das Wasser- fallmodell eine streng konsekutive Abarbeitung der verschiedenen Phasen verfolgt, sind diese im Rational Uniﬁed Process ineinander verschränkt. Wie die Verlaufs- kurven in Abb. 9.8 andeuten, werden die einzelnen Workﬂows zeitgleich bearbeitet, wenn auch mit unterschiedlicher Intensität. Die zeitliche Überlagerung ist eine we- sentliche Stärke des Rational Uniﬁed Processes und bildet die Realität der Software- Entwicklung weit besser ab, als alle streng sequenziell konzipierten Vorgehensmo- delle.\n9.1.4 Extreme Programming\nZwischen der Publikation des ersten Vorgehensmodells in Form des Stagewise mo- dels und dem Erscheinen moderner Varianten wie dem V-Modell XT oder dem Ra- tional Uniﬁed Process liegen rund 40 Jahre. Während der gesamten Zeit wurde die Entwicklung durch einen eindeutigen Trend geprägt: Mit jeder neuen Modellvari- ante stieg der Umfang und die Komplexität der postulierten Vorgehensweisen und Arbeitsabläufe kontinuierlich an. Reichten für die Beschreibung des Wasserfallmo- dells noch ein paar Textseiten aus, so erfordert die Einarbeitung in das V-Modell XT ein wochenlanges Dokumentenstudium. Als Gegengewicht zu den immer schwergewichtiger werdenden Vorgehensmo- dellen wurden Mitte der Neunzigerjahre die ersten agilen Modelle entwickelt, die mit zahlreichen Traditionen der bis dato im Einsatz beﬁndlichen Varianten brachen.\nIm Gegensatz zu den schwergewichtigen Modellen, zu denen auch der Rational Uni- ﬁed Process und das V-Modell XT gehören, versuchen agile Modelle, den Software- Entwicklungsprozess zu verschlanken und komplexe Arbeitsabläufe durch wenige, ﬂexibel anwendbare Regeln zu ersetzen. Die Flexibilität ist dabei eine tragende Säu- le der verfolgten Philosophie. Anstatt die Vorhersagbarkeit und Planbarkeit des Pro- jektverlaufs in den Vordergrund zu stellen, zeichnen sich agile Modelle durch eine dynamische Projektsicht aus und sind explizit darauf ausgerichtet, auf unvorherge- sehene Änderungen schnell und ﬂexibel zu reagieren. Zu den bekanntesten Vertretern zählt das Extreme Programming, kurz XP. Hinter diesem Begriff verbirgt sich ein Vorgehensmodell, das von Kent Beck, Howard Cun- ningham und Ron Jeffries im Rahmen des C3-Projekts (Chrysler Comprehensive Compensation System) der ehemaligen DaimlerChrysler AG entwickelt wurde. Ex- treme Programming zielt vor allem auf Software-Projekte ab, die von Teams kleiner oder mittlerer Größe durchgeführt werden. Die grundlegende Philosophie von XP wird durch fünf zentrale Werte charakterisiert, aus denen konkrete Handlungsprak- tiken abgeleitet werden. Im Einzelnen handelt es sich um die Werte Kommunikation, Einfachheit, Rückmeldung, Mut und Respekt:\n■ Kommunikation (Communication) Die Ursache vieler Fehler und Probleme lässt sich im alltäglichen Projektge- schäft auf die mangelhafte Kommunikation zwischen den Beteiligten zurück- führen. XP trägt dieser empirischen Tatsache Rechnung und sieht in dem regen Informationsaustausch ein Schlüsselelement für den Projekterfolg. Aus diesem Grund deﬁniert das Vorgehensmodell viele Vorgehensweisen und Arbeitsabläu- fe, die ein erhebliches Maß an Kommunikation bedingen. Beispiele sind das Pro- grammieren in Paaren oder die gemeinsame Durchführung von Aufwandsschät- zungen.\n■ Einfachheit (Simplicity) Entwickler sind durch den XP-Prozess angehalten, sich stets auf die einfachste Lösung zu konzentrieren. Diese Vorgehensweise ist mit der Einsicht verbunden, dass die Schwierigkeit, ein Software-System fehlerfrei zu entwickeln, mit zu- nehmender Systemkomplexität überproportional zunimmt. Wird an den richti- gen Stellen auf unnötige Komplexität verzichtet, kann zum einen die Anzahl der Fehler reduziert und zum anderen das gleiche Produkt in deutlich geringerer Zeit entwickelt werden.\n■ Rückmeldung (Feedback) Die Aktivitäten und Prozesse von XP sind darauf ausgelegt, efﬁzient arbeiten- de Rückmeldemechanismen zu schaffen, die zu jeder Zeit über den aktuellen Zustand des Projekts bzw. des entwickelten Systems Auskunft geben. Entspre- chende Feedback-Kanäle werden auf verschiedenen Ebenen eingerichtet:\n– System-Feedback XP forciert die Erstellung umfassender Unit-Tests während der gesamten Software-Entwicklung. Die automatisierte Ausführung einer Test-Suite gibt nach kurzer Zeit Auskunft über den aktuellen Zustand der Software, ohne\neinen nennenswerten Zusatzaufwand zu generieren. Durch den extensiven Einsatz von Unit-Tests wird ein efﬁzienter Feedback-Kanal zwischen Soft- ware und Entwickler geschaffen.\n– Kunden-Feedback Im Rahmen eines XP-Projekts werden in regelmäßigen Abständen Akzep- tanztests erstellt. Bei der Ausarbeitung der Testfälle ist sowohl die Kundensei- te als auch die Herstellerseite in Person der Software-Tester beteiligt. Durch dieses Vorgehen erhält der Auftraggeber in regelmäßigen Abständen Feed- back über den aktuellen Zustand des bestellten Systems. Zusätzlich werden die Anforderungen und Wünsche des Kunden ohne Umwege an das Projekt- team kommuniziert.\n– Team-Feedback Reicht der Auftraggeber einen Änderungswunsch (change request) in Form einer Story card ein, wird diese durch eine sich unmittelbar anschließende Aufwandsschätzung quittiert. Auf diese Weise erhält der Kunde eine unmittel- bare Rückmeldung über die Machbarkeit, den Aufwand und die entstehenden Kosten der nachgefragten Änderung.\n■ Mut (Courage) XP appelliert wie kaum ein anderes Vorgehensmodell an den Mut der Entwickler. So werden grundlegende Änderungen an der Systemarchitektur akzeptiert, wenn sie aus Software-technischer Sicht gerechtfertigt sind. Das Festhalten an subopti- malen Architekturen oder Implementierungen wird selbst dann abgelehnt, wenn die Änderungen einen erheblichen Aufwand verursachen. Hinter diesem Para- digma verbirgt sich die Sichtweise, dass die Fokussierung auf die Produktquali- tät eine essentielle Rolle für den Projekterfolg spielt. Wird diese Vorgehensweise konsequent verfolgt, so übersteigen die Ersparnisse, die durch eine kontinuierlich optimierte Software-Struktur langfristig entstehen, den kurzfristig zu erbringen- den Refactoring-Aufwand um ein Vielfaches.\n■ Respekt (Respect) Die ursprüngliche Beschreibung des XP-Modells leitete die postulierte Vorge- hensweise aus den bisher vorgestellten Werten Kommunikation, Einfachheit, Rückmeldung und Mut ab . Mit dem Erscheinen der zweiten Ausgabe von Extreme Programming Explained wurden diese um den fünften Wert Respekt er- gänzt . Die Erweiterung bringt zum Ausdruck, dass das Gelingen eines Pro- jekts nicht zuletzt von einer gut funktionierenden Team-Psychologie abhängt. Faktoren wie Motivation und Teamgeist sind Erfolgsbausteine, die in anderen Vorgehensmodellen häuﬁg stiefmütterlich behandelt oder gar vollständig igno- riert werden. In XP nehmen diese einen prominenten Platz ein.\nDie fünf Werte des Extreme Programmings charakterisieren die Philosophie des Vorgehensmodells, legen jedoch selbst noch keine konkreten Arbeitsabläufe und Handlungen fest. Stattdessen dienen sie als Nährboden, aus denen die verschie- denen XP-Praktiken erwachsen. Die meisten Praktiken sind auch hier sogenannte\nAbb. 9.9 Die 12 XP-Praktiken im Zusammenspiel (nach Beck )\nBest practices und damit Vorgehensweisen, die ihren Nutzen in der täglichen Arbeit vielfach unter Beweis stellen konnten und im Zusammenspiel ihre volle Wirkung entfalten. Die aus den fünf Werten abgeleiteten Praktiken lassen sich in insgesamt 12 Hauptverfahrensbereiche einteilen (vgl. Abb. 9.9):\n■ Planungsspiel (Planning Game) Das Planungsspiel dient dem Zweck, die Rahmendaten der nächsten Software- Iteration bzw. des nächsten Release festzulegen. Die Planung ﬁndet unter aktiver Beteiligung des Kunden statt und wird in erster Linie mit Hilfe spezieller Sto- ry cards durchgeführt. Jede dieser Karten deﬁniert eine bestimmte Anforderung an das Software-System und dient als Diskussionsgrundlage zwischen Auftrag- geber und -nehmer. Story cards werden unmittelbar nach ihrer Erstellung einer Aufwandsschätzung unterzogen, die insbesondere auch die Erfahrungen der vor- hergehenden Iterationen einbezieht. Innerhalb des Planungsspiels hat der Kunde die Möglichkeit, neue Anforderungen einzubringen, bestehende Anforderungen zu ändern oder neu zu priorisieren.\n■ Kurze Release-Zyklen (Small Releases) XP verfolgt das Ziel, viele Releases in kurzen Abständen zu produzieren. Die Zeitintervalle zwischen zwei Iterationen sind dabei nicht konstant gewählt und orientieren sich stattdessen an den inhaltlichen Anforderungen. Jedes Release soll ein für sich abgeschlossenes System darstellen und als Ganzes sinnvoll be- trieben werden können – insbesondere ist das Einpﬂegen halbgarer Teillösungen zu vermeiden. Kurze Release-Zyklen besitzen nicht zu unterschätzende Vorteile. Zum einen beﬁndet sich das Software-System nach einer Änderung rasch wie- der in einem konsistenten Zustand. Auftretende Fehler lassen sich aufgrund der\nüberschaubaren Änderungen vergleichsweise schnell lokalisieren und korrigie- ren. Zum anderen erstreckt sich die Release-Planung stets über einen überschau- baren Zeitraum. Anstatt die vollständige Funktionalität eines Software-Systems zu Beginn des Projekts in einem Atemzug zu planen, müssen die durchzufüh- renden Arbeitsschritte lediglich für die nächsten Wochen oder Monate festgelegt werden. Diese Vorgehensweise kommt nicht zuletzt dem Änderungsmanagement zugute, da sich Änderungswünsche aufgrund der kurzen Planungszeiträume ﬂe- xibel in die Projektplanung einﬂechten lassen.\n■ Metapher (Metaphor) Im literarischen Sinne ist eine Metapher die bildliche Umschreibung eines kon- kreten Sachverhalts. Der XP-Gedanke legt die Verwendung solcher bildlicher Beschreibungen für die Speziﬁkation eines Software-Systems auf oberster Ebe- ne nahe. Die Vorgehensweise ist mit der Hoffnung verbunden, eine teamüber- greifende Grundidee für die zu erstellende Software zu generieren, ohne diese in umfangreichen Dokumenten umständlich niederlegen zu müssen. So gibt die Metapher Rechenblatt für eine Software zur Gehaltsberechnung bereits eine ers- te Idee, wie die zu erstellende Applikation später aussehen wird. Die gewählte Metapher ist dabei nicht in jeder Hinsicht wörtlich zu nehmen – sie deﬁniert lediglich eine Richtung, die in einzelnen Aspekten von dem gewählten Begriff abweichen darf. Sie beschreibt wesentliche Aspekte eine Systems, die durch die Software-Architektur im Detail festgelegt werden. Damit unterstützen Me- taphern die Beschreibung der Software-Architektur, können diese aufgrund ihrer abstrakten Natur aber nicht ersetzen.\n■ Einfaches Design (Simple Design) Die Komplexität ist einer der größten Feinde eines Software-Entwicklers. XP trägt dieser empirischen Wahrheit Rechnung und sieht in der Einfachheit einen Schlüssel für den Projekterfolg. In  deﬁniert Beck vier Merkmale, die ein gutes Software-Design zu jedem Zeitpunkt der Entwicklung aufzeigen soll:\n– Die Software besteht alle Tests.\n– Die Software ist frei von Redundanz.\n– Die Implementierung lässt die Intention des Programmierers klar erkennen.\n– Die Anzahl der verwendeten Klassen und Methoden ist minimal.\nDie ersten drei Merkmale sind anerkannte Vorgehensweisen, die lange vor dem Erscheinen von XP Einzug in die Software-Technik hielten. Nichtsdestotrotz werden diese Richtlinien in der Praxis häuﬁg verletzt. Das vierte Merkmal ist eher untypischer Natur und nicht selten Gegenstand kontroverser Diskussionen. Bei genauerer Betrachtung mündet die Beschränkung auf die minimale Anzahl von Klassen und Methoden in der Konsequenz, dass sich die Implementierung stets auf die aktuell geforderten Anforderungen beschränkt und darauf verzich- tet, Raum für zukünftige Erweiterungen zu lassen. Die Konzentration auf die\nheutigen Belange wird von XP bewusst angestrebt und steht im Gegensatz zur klassischen Lehrmeinung, die einen eher weitsichtigen Entwurf forciert. Obwohl dieses Vorgehen berechtigte Fragen aufwirft, bietet es einige beachtliche Vor- teile. Im Besonderen wird der ausufernden Komplexität eines Software-Systems aktiv entgegengewirkt.\n■ Test (Testing) Das Rückgrat von XP wird nicht zuletzt durch die auf allen Ebenen angestrebte Testautomatisierung gebildet. Testfälle sind für XP das Mittel der Wahl, um den aktuellen Zustand eines Software-Systems an den Entwickler oder den Kunden zurückzumelden. Die Automatisierung derselben ist nicht minder wichtig. Zum einen werden die Testergebnisse aufgrund ihrer Reproduzierbarkeit auf eine ob- jektive Basis gestellt, zum anderen reduziert die automatisierte Durchführung den zu erbringenden Zusatzaufwand auf ein Minimum. Der Software-Test ist in diesem Vorgehensmodell so tief verankert, dass für jede Programmeigenschaft explizit die Erstellung eines Testfalls gefordert wird. Typische XP-Projekte be- ginnen daher in der Regel mit der Erstellung von Unit-Tests und nicht mit der Implementierung des eigentlichen Codes.\n■ Refactoring XP ermutigt seine Entwickler, stets die beste Software-Architektur und -Implementierung für das aktuell zu lösende Problem zu wählen. Wartungsar- beiten an der inneren Code-Struktur gehören hierdurch zur täglichen Arbeit und werden durch das Vorgehensmodell explizit eingefordert. In diesem Punkt un- terscheidet sich XP von der landläuﬁgen Vorgehensweise in IT-Projekten. Re- factorings, d. h. die Durchführung von Code-Änderungen bei gleichzeitiger Be- wahrung der alten Funktionalität, werden in der Praxis vergleichsweise selten durchgeführt und durch das Management in der Regel nicht gefördert (vgl. Ab- schnitt 7.3.1). Der Hauptgrund liegt zum einen in einer fehlenden Weitsicht – die Bedeutung einer sauberen Architektur und Implementierung wird für den lang- fristigen Erfolg eines Produkts häuﬁg unterschätzt. Zum anderen wird an dieser Stelle Arbeit investiert, die nach außen hin nicht sichtbar ist. Wird der vorhan- dene Termindruck in einem Projekt entsprechend groß, so wird das Refactoring oft hinten angestellt und die zur Verfügung stehende Arbeitskraft auf Tätigkeiten verlagert, die einen scheinbaren Projektfortschritt nach außen hin dokumentie- ren.\n■ Programmieren in Paaren (Pair Programming) Eine seit jeher kontrovers diskutierte Eigenschaft von XP ist die vorgesehene Art und Weise der Programmerzeugung. Die Quelltexte der Software werden stets von zwei Entwicklern erstellt, die in einem Team an einem einzigen Rechner arbeiten. Jeder Entwickler übernimmt hierbei eine andere Rolle. Während einer von beiden einen Implementierungsvorschlag über die Tastatur eingibt, hat sein Partner die Aufgabe, den gewählten Ansatz auf abstrakterer Ebene zu durch- denken. Die Vorgehensweise wird insbesondere durch die empirische Tatsache motiviert, dass es einem einzigen Entwickler in der Regel schwer fällt, verschie-\ndenen Abstraktionsebenen gleichzeitig im Auge zu behalten. So sind Program- mierer während der Codierung einer Funktion oder Methode kaum in der Lage, gleichzeitig über alternative Lösungsansätze nachzudenken. Genau hier kommt der zweite Entwickler ins Spiel, der die Aufgabe des strategischen Denkers über- nimmt. Als zusätzlicher Nebeneffekt wird die erstellte Implementierung einer neutralen Sichtprüfung unterzogen, bei der viele kleinere Programmierfehler auf- grund des Vieraugenprinzips sofort erkannt werden. Das Programmieren in Paaren lässt einen tieferen Blick in die XP-Philosophie zu. Wie schon der Name Extreme Programming andeutet, wird auf bewährte Praktiken zurückgegriffen, diese jedoch in einer extremen Art und Weise einge- setzt. Im Falle des Programmierens in Paaren wird die bewährte Review- bzw. Inspektionstechnik (vgl. Abschnitt 5.5) herangezogen und die Kernidee rigoros auf den gesamten Bereich der Code-Erstellung übertragen.\n■ Gemeinsame Verantwortlichkeit (Collective Ownership) Die Frage, wer in einem Projekt für welchen Teil des Codes verantwortlich ist, wird in verschiedenen Unternehmen traditionell unterschiedlich beantwortet. In einigen Firmen sind die Verantwortlichkeiten nicht explizit geregelt, so dass für den Quellcode im Ganzen oder zumindest für bestimmte Teile keine verantwort- liche Person existiert. Insbesondere junge Firmen, deren Produkt sich noch in einer vergleichsweise frühen Evolutionsphase beﬁndet, verzichten häuﬁg auf die explizite Festlegung von Verantwortlichkeiten. Erfahrungsgemäß leiden diese Unternehmen recht schnell unter den typischen Problemen der Software-Alterung (vgl. Abschnitt 7.1). Um dem entstehenden Chaos entgegenzuwirken, gehen viele Firmen dazu über, die einzelnen Modu- le und Komponenten in die Verantwortlichkeit einzelner Entwickler oder Ent- wicklergruppen zu übergeben – Änderungen an der Software sind dann nur noch durch die verantwortlichen Programmierer möglich. Das Chaos, das durch die gleichzeitige Änderung der Code-Basis durch eine Vielzahl verschiedener Pro- grammierer entsteht, wird hierdurch zwar effektiv eingedämmt, allerdings geht auch jegliche Flexibilität verloren. In derart organisierten Projektgruppen ten- dieren Programmierer nicht selten dazu, umständliche lokale Änderungen einer sauberen globalen Lösung vorzuziehen, um den hohen Kommunikationsaufwand mit den verschiedenen Code-Verantwortlichen zu umgehen. XP versucht das Problem zu lösen, indem die Verantwortung der gesamten Code-Basis in die Hände aller Projektbeteiligten gelegt wird. Von jedem Ent- wickler wird erwartet, sich nicht auf einen bestimmten Code-Abschnitt zu kon- zentrieren. Stattdessen sind alle Beteiligten aufgerufen, Code-Verbesserungen permanent durchzuführen, unabhängig davon, welches Modul oder welche Klas- se hiervon betroffen ist. Wie schon im Fall des Programmierens in Paaren geht das Vorgehensmodell an dieser Stelle sehr mutig vor. Durch die Übergabe der gesamten Quelltextba- sis in die Verantwortung aller Programmierer wird das gemeinsame Verantwor- tungsgefühl innerhalb des Projekt-Teams unbestritten gestärkt. Das Vorgehen ist jedoch auch mit Risiken verbunden. Erreicht das Projekt-Team eine gewisse Grö-\nße, so besteht die Gefahr, dass die gemeinsame Verantwortung schwindet und das Projekt in den initialen, ungeregelten Zustand zurückfällt. An dieser Stelle gilt es zu bedenken, dass XP vor allem für Projekte kleinerer und mittlerer Größe konzipiert ist. Hier erweist sich das Prinzip der gemeinsamen Verantwortlichkeit durchaus als eine vielversprechende Vorgehensweise.\n■ Fortlaufende Integration (Continuous Integration) XP hält die Programmierer dazu an, den erstellten Programmcode in kurzen Ab- ständen wieder in die bestehende Code-Basis zu integrieren. Empfohlen wird ein Zurückschreiben der Änderungen nach wenigen Stunden, spätestens jedoch am Ende eines Arbeitstags. Vor der Integration werden sämtliche Unit-Tests durch- geführt und die Entwicklung erst dann fortgesetzt, wenn alle Testfälle zu 100 % fehlerfrei ausgeführt werden. Hinter der fortlaufenden Integration verbirgt sich die Idee, die erstellte Soft- ware nicht über längere Zeit in einem inkonsistenten Zustand zu belassen. Durch die strikt konsekutive Integration einzelner Änderungen wird insbesondere die Fehlersuche stark vereinfacht. Zudem unterstützt diese Vorgehensweise den so- genannten Rollback. Stellt sich beispielsweise heraus, dass gewisse Programm- änderungen nicht den gewünschten positiven Effekt zeigen, werden diese im Rahmen eines Rollback-Szenarios wieder aus der Code-Basis entfernt. Durch die kontinuierliche Integration entstehen in regelmäßigen Abständen in sich stimmi- ge Konﬁgurationen, so dass die Rücknahme einzelner Änderungen durch das Zurückgehen auf einen der vorher erzeugten Software-Stände vergleichsweise problemlos möglich ist.\n■ Vierzigstundenwoche (40-Hour Week) Hinter diesem Unternehmensgrundsatz steht die Überzeugung, dass sich die per- manente Überschreitung der persönlichen Belastungsgrenze negativ auf die Ge- samtleistung auswirkt. Die Erfahrung vieler Projekte hat gezeigt, dass sich Ter- minverzögerungen durch das übermäßige Ableisten von Überstunden kaum aus- gleichen lassen. Auf zwei häuﬁg angetroffene Fehlinterpretationen soll an dieser Stelle expli- zit hingewiesen werden: XP gibt nicht vor, dass eine Arbeitswoche aus exakt 40 Stunden besteht. Die Vierzigstundenwoche steht stellvertretend für die persönli- chen Belastungsgrenzen, die zwischen den einzelnen Team-Individuen deutlich schwanken. Des Weiteren ist der Verzicht auf Überstunden nicht im Sinne eines gewerkschaftlichen Dogmas zu verstehen. Auch Sechzigstundenwochen stehen mit der XP-Philosophie im Einklang, sofern diese in begründeten Einzelfällen anfallen und nicht zur Regel werden.\n■ Kunde vor Ort (On-Site Customer) Dem Kommunikationsgedanken von XP folgend, ist mindestens ein Mitarbeiter der Kundenseite vor Ort und fest in das Entwicklungsteam eingebunden. Hier- durch soll der Kommunikationsweg zwischen Auftragnehmer und -geber auf ein Minimum verkürzt und ein insgesamt produktives Arbeitsumfeld geschaf- fen werden. Bei der Auswahl der Vor-Ort-Mitarbeiter wird darauf geachtet, dass\ndie betreffenden Personen zum aktiven Nutzerkreis der entwickelten Software gehören. Die Aufgabe des Mitarbeiters ist zweigeteilt. Auf der einen Seite dient er dem Entwicklungsteam als direkter Ansprechpartner für die Klärung offener Fragen. Auf der anderen Seite hat der Kunde eine direkte Einsicht in den aktuel- len Projektfortschritt und kann z. B. durch die Änderung von Prioritäten ﬂexibel in den Entwicklungsprozess eingreifen.\n■ Programmierstandards (Coding Standards) Die von XP forcierte gemeinsame Code-Verantwortung hat zur Folge, dass viele verschiedene Entwickler an den unterschiedlichsten Stellen einer Software ar- beiten. Aus diesem Grund wird der Einheitlichkeit der Programmquellen eine besondere Bedeutung zugemessen. Mit Hilfe entsprechender Programmierstan- dards versucht XP, das Erscheinungsbild der Quelltexte von der individuellen Handschrift einzelner Entwickler zu befreien. Standards sind dabei so zu wäh- len, dass unnötiger Mehraufwand vermieden wird und sich die einzelnen Team- Mitglieder darin wiederﬁnden. Nur durch eine entsprechende Identiﬁkation kann eine freiwillige Einhaltung derselben erreicht werden.\nWährend die im letzten Abschnitt vorgestellten Vorgehensmodelle einen idealisier- ten Projektverlauf beschreiben, dienen Reifegradmodelle zur Bewertung und Opti- mierung der Prozesse eines Unternehmens. In der Vergangenheit haben sich ver- schiedene Modelle etabliert, die mehrheitlich durch die folgenden Eigenschaften charakterisiert sind:\n■ Stufen Die Reife einer Organisation wird mit Hilfe eines Stufenmodells beschrieben. Hierzu wird das Unternehmen entweder als Ganzes klassiﬁziert oder die Be- wertung für inhaltlich getrennte Schlüsselbereiche individuell durchgeführt. Die verschiedenen Stufen werden in der Regel konsekutiv durchlaufen, so dass kein Reifegrad übersprungen werden kann.\n■ Anforderungen und Maßnahmen Jeder Reifegrad ist mit einer Menge von Anforderungen verbunden, die ein Un- ternehmen für dessen Erreichung erfüllen muss. Die meisten Reifegradmodelle schlagen zudem konkrete Maßnahmen vor, die eine Organisation in die Lage ver- setzen sollen, die Anforderungen des angestrebten Reifegrads zu erfüllen. Trotz- dem sind Reifegradmodelle keine Prozessbeschreibungen im eigentlichen Sinne. Stattdessen geben die entsprechenden Maßnahmenkataloge Eckpunkte vor, aus denen sich eine konkrete Prozessbeschreibung ableiten lässt. Alle Reifegradmo- delle sind aufgrund ihrer allgemeinen Natur explizit darauf ausgelegt, auf die speziellen Gegebenheiten und Bedürfnisse einer Organisation angepasst zu wer- den.\n■ Assessments Die Anforderungen einer Reifestufe sind so angelegt, dass sie einer objektiven Prüfung unterzogen werden können. Die Bewertung der Reife wird in Form ei- nes Assessments durchgeführt. Die vorgefundenen Arbeitsabläufe und Strukturen werden hierzu systematisch mit den Anforderungen des Reifegradmodells abge- glichen und die erreichte Reifestufe festgelegt. Assessments sind ein wesentlicher Kern aller Reifegradmodelle und verfol- gen zwei maßgebliche Ziele: Zum einen wird durch die Reifegradbestimmung die Leistungsfähigkeit verschiedener Unternehmen messbar und untereinander vergleichbar. Zum anderen werden im Rahmen eines Assessments Hinweise und Vorschläge erarbeitet, wie die Prozess- und Arbeitsstrukturen verbessert werden können. Je nachdem, von wem und in welcher Form die Bewertung durchgeführt wird, fällt ein Assessment in eine von mehreren Kategorien:\n– Selbst- versus Fremd-Assessments Selbst-Assessments dienen zur Bewertung der unternehmenseigenen Reife. Im Rahmen eines Fremd-Assessments wird dagegen die Leistungsfähigkeit eines anderen Unternehmens evaluiert. Eingesetzt wird die Fremdbewertung insbesondere in der Auswahl von Subunternehmern und Zulieferern.\n– Interne versus externe Assessments Interne Assessments werden durch das Unternehmen selbst durchgeführt. Die Vorteile liegen vor allem in einer erheblichen Kostenersparnis und einer höhe- ren Flexibilität. Im Gegensatz hierzu werden externe Assessments durch einen neutralen Assessor durchgeführt. Assessments dieser Art bilden die Grundla- ge für die formale Zertiﬁzierung eines Unternehmens.\nIn den folgenden Abschnitten werden wir wichtigsten der in der Vergangenheit vor- gestellten Reifegradmodelle einer genaueren Betrachtung unterziehen. Nach einem kurzen Abstecher in die historischen Anfänge werden wir mit dem CMM, CMMI und ISO 15504 (SPICE) die heute bedeutendsten Vertreter im Bereich der Software- Entwicklung kennen lernen.\n9.2.1 Historische Entwicklung\nFür den Einsatz von Reifegradmodellen im Bereich der Informationstechnologie wird seit Ende der Achtzigerjahre verstärkt geworben, in anderen Bereichen wur- den entsprechende Modelle jedoch bereits viel früher eingesetzt. So postulierte der US-amerikanische Psychologe Abraham Harold Maslow bereits Anfang der Vier- zigerjahre ein Stufenmodell, das die Bedürfnisse eines Menschen in eine hierar- chische Ordnung bringt und bereits viele der zentralen Grundideen moderner Rei- fegradmodelle verwirklicht (vgl. Abb. 9.10) . Zum einen ﬁndet sich bereits in der Maslow’schen Bedürfnispyramide die heute populäre Fünfereinteilung wie- der. Zum anderen sind die einzelnen Stufen der Pyramide aufeinander aufbauend angeordnet und werden streng konsekutiv durchlaufen. Mit anderen Worten: Erst\nAbb. 9.10 Bedürfnispyramide nach Maslow\nwenn die Bedürfnisse einer Stufe vollständig erfüllt sind, werden die Bedürfnisse der nächsthöheren für den Menschen relevant. Ein anderes populäres Reifegradmodell ist das Quality Management Maturity Grid (QMMG), das in den Siebzigerjahren von dem Amerikaner Philip Crosby po- stuliert wurde . Mit einfachen Sätzen beschreibt das Gitter, wie sich Organi- sationen unterschiedlicher Reife in Bezug auf verschiedene Qualitätsaspekte ver- halten. Mit dem Reifegradgitter verfolgte Crosby zwei Ziele. Zum einen versetzt die eigenschaftsbasierte Beschreibung ein Unternehmen in die Lage, eine schnelle und präzise Kategorisierung der eigenen Organisation vorzunehmen. Zum anderen geben die Charakteristika der noch nicht erreichten Reifegrade Leitlinien für die weitere Entwicklung der Organisationsstrukturen vor. Wie die Bedürfnispyramide von Maslow unterscheidet auch das Reifegradmodell von Crosby fünf verschiedene Stadien, die evolutionär durchlaufen werden. Inhaltlich werden die Stadien durch die folgenden Eigenschaften charakterisiert:\n■ Stadium 1: Unsicherheit (uncertainty) Die Unternehmensführung begreift den Faktor Qualität nicht als Managementin- strument. Präventive Maßnahmen zur Fehlervermeidung werden nicht durchge- führt, d. h., Probleme werden erst dann gelöst, wenn sie auftreten. Ein Verständ- nis für die geordnete Durchführung von Aktivitäten besteht in diesem Stadium genauso wenig wie die Fähigkeit, die Ursachen der unternehmenseigenen Quali- tätsprobleme systematisch zu ergründen.\n■ Stadium 2: Erwachen (awakening) Die Unternehmensführung beginnt, das Qualitätsmanagement als eine mögliche Lösung für die Probleme der Organisation zu sehen. Dringliche Herausforderun-\nEin Qualitätsmanager ist in die Geschäftsleitung integriert. Die Handlungspriorität liegt auf der Fehlerprävention. Das Denken orientiert sich an der Qualität.\nProbleme werden erst\nbekämpft, sobald sie\ndigungen prägen das\nAbb. 9.11 Quality Management Maturity Grid nach Crosby\ngen werden durch speziell zusammengestellte Teams angegangen, jedoch weiter- hin keine Maßnahmen zur Fehlerprävention ergriffen. Die Organisation beginnt, sich mit der Frage auseinanderzusetzen, ob die unternehmenseigenen Qualitäts- probleme wirklich unvermeidlich sind.\n■ Stadium 3: Erkenntnis (enlightment) Die Unternehmensführung sieht sich in der Verantwortung, den Mitarbeitern mit den Mitteln eines aktiven Qualitätsmanagement beratend und unterstützend unter die Arme zu greifen. Eine direkt unter dem Top-Level-Management angesiedelte Qualitätsabteilung sorgt für eine unternehmensweite Hilfestellung in den Projek- ten. Maßnahmen zur regelmäßigen Beurteilung der Qualität sind jetzt fest in die Arbeitsabläufe integriert und die Organisation ist in der Lage, Problemursachen zu identiﬁzieren und systematisch zu lösen.\n■ Stadium 4: Verständnis (wisdom) Die Mitarbeiter des Unternehmens bekennen sich zu den Maßnahmen des Qua- litätsmanagements und erachten das Streben nach Qualität als eine persönliche Verpﬂichtung. Die Organisationsstruktur ist auf ein unternehmensweites Quali- tätsmanagement ausgerichtet – ein Qualitätsmanager ist Teil der Führungsebene und efﬁziente Kommunikationskanäle zwischen der Führungs- und der Projek- tebene wurden etabliert. Unternehmen dieser Reifestufe sind in der Lage, Fehler in frühen Entwicklungsstadien zu erkennen und durch die Einleitung geeigneter Maßnahmen nachhaltig zu beheben.\nQualitätskosten in Prozent des Umsatzes\nAbb. 9.12 Reifegradgetriebene Entwicklung der Qualitätskosten nach Crosby\n■ Stadium 5: Sicherheit (certainty) Das Qualitätsmanagement ist ein integrales Element der Organisationsstruktur. Qualitätsverbesserungen werden permanent und systematisch durchgeführt. Die entsprechenden Maßnahmen werden als fester Bestandteil der regulären Ar- beitsabläufe angesehen und durch entsprechende Unternehmensstrukturen un- terstützt. In Unternehmen dieser Reifestufe sind Qualitätsprobleme weitgehend überwunden.\nZusätzlich erfasst Crosby die Reife einer Organisation quantitativ, indem er die Qua- litätskosten in Bezug zum Umsatz eines Unternehmens stellt. Wie in Abb. 9.12 gezeigt, unterscheidet Crosby zwei Messgrößen. Die erste Kurve beschreibt die berichteten Qualitätskosten, d. h. diejenigen Kosten eines Unternehmens, die nach eigenen Angaben entstanden sind. Dieser Kurve stehen die tatsächlichen Qualitäts- kosten gegenüber. Wenngleich die absoluten Zahlen schon aufgrund ihres Alters mit Vorsicht zu genießen sind und als allgemein gehaltenes Modell die Besonderheiten der Software-Entwicklung außer Betracht gelassen werden, treten zwei wesentliche Eigenschaften der Prozessreife deutlich hervor:\n■ Gesenkte Gesamtkosten Die Investition in Qualität führt mittel- und langfristig zu einer Senkung der Ge- samtkosten. Im Modell von Crosby sinken die Qualitätskosten von 20 % des Umsatzes auf nur noch 2.5 % . Auf der anderen Seite ist die Investition in Qualität mit erheblichen Initialkosten verbunden, vor denen viele Unternehmen im Stadium der Unsicherheit zurückschrecken.\n■ Präzise Vorhersagen Je weiter sich eine Organisation entwickelt, desto präziser lassen sich projekt- und unternehmensbezogene Parameter schätzen. Die von Crosby gemessenen\nQualitätskosten sind einer dieser Parameter. Während Organisationen in Stadi- um 1 über keinerlei Schätzgrößen verfügen, nähern sich die vorhergesagten und die realen Kosten mit jeder Reifestufe weiter aneinander an. Neben den Quali- tätskosten kommen in der Praxis weitere Schätzgrößen wie der Zeit-, Personal- oder Ressourcen-Bedarf eines Projekts hinzu.\nDas Quality Management Maturity Grid gilt als ein Meilenstein im Bereich der Reifegradmodelle und wurde nach seinem Erscheinen in mehrere Richtungen fort- entwickelt. Crosby selbst entwickelte seinen Ansatz zum Quality Management Pro- cess Maturity Grid weiter . Von vielen Experten wird dieses Modell als der Vorgänger des Capability Maturity Models erachtet, das wir im nächsten Abschnitt, zusammen mit seinen Vor- und Nachteilen, in ein helleres Licht rücken werden.\nIn den späten Sechzigerjahren wurde der Begriff der Software-Krise (software cri- sis) geprägt. Heute wie damals steht er stellvertretend für die Probleme und Symp- tome ins Wanken geratener Software-Projekte – Budget- und Zeitüberschreitungen, Qualitätsdeﬁzite, nicht oder unzureichend erfüllte Anforderungen sowie Probleme im Projektmanagement sind wenige Beispiele von vielen. Bekannt wurde der Aus- druck vor allem durch die Dankesrede des niederländischen Computerwissenschaft- ler Edsger W. Dijkstra, die er während der Verleihung des ACM Turing Awards im Jahre 1972 hielt:\n“As the power of available machines grew by a factor of more than a thou- sand, society’s ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded ﬁeld of tension between ends and means. The increased power of hardware, together with the perhaps even more dramatic increase in its reliability, made solutions feasible that the programmer had not dared about them and, even worse, he had to transform such dreams into reality! Is it a wonder that we found ourselves in a software crisis? No, certainly not, and as you may guess, it was even predicted well in advance; [ ]”\nMitte der Achtzigerjahre rückte die Software-Krise aufgrund zahlreicher verspäte- ter oder gescheiterer Software-Projekte immer stärker in das Bewusstsein der Öf- fentlichkeit. Etwa zur gleichen Zeit wurde am Software Engineering Institute (SEI) mit der Entwicklung des Capability Maturity Model, kurz CMM, begonnen (vgl. Abb. 9.13). Das CMM sollte die Antwort auf die sich immer weiter verschärfen- de Software-Krise geben und baut auf der Idee von Watts Humphrey auf, bewährte Praktiken der Software-Entwicklung in einem formalen Modell systematisch zu ver- einen [132, 133]. Hinter dem viel zitierten Software Engineering Institute verbirgt sich eine staat- lich geförderte Institution, die im Jahre 1984 an der Carnegie Mellon University in\nAbb. 9.13 Zeitliche Entwicklung der verschiedenen Reifegradmodelle in der Übersicht\nPittsburgh angesiedelt wurde. Gegründet wurde das SEI mit dem Ziel, die Fähig- keiten der US-amerikanischen IT-Industrie im Bereich des Software-Engineerings zu verbessern. Im Jahre 2007 unterhielt das SEI fünf verschiedene Bereiche, von denen insbesondere das Software Engineering Process Management Program inter- nationale Bedeutung erlangen konnte. Das SEI fasst die Aufgaben des Programms – zu denen auch die Fortentwicklung des Capability Maturity Models gehört – im Rahmen einer Selbstdarstellung wie folgt zusammen:\n“The Software Engineering Process Management Program at the SEI provides leadership to software-dependent organizations through proven, process-focused methods for improving product costs, schedule and qua- lity. This program also manages the SEI’s work on the internationally re- cognized Capability Maturity Model Integration, a framework that helps organizations improve their processes enterprisewide.”\nIm Jahre 1991 erschien die Version 1.0 des CMM und sorgte für einen regelrech- ten Popularitätsschub im Bereich der Reifegradmodelle . Zwei Jahre später erschien mit dem CMM 1.1 eine weiterentwickelte und in zahlreichen Punkten ver- besserte Variante [202, 204, 203]. Die Version 1.1 hatte sieben Jahre lang Bestand, bis sie im Jahre 2000 durch das Nachfolgemodell CMMI ersetzt wurde (vgl. Ab- schnitt 9.2.3). Die Grundstruktur des CMM ist in Abb. 9.14 dargestellt und besteht aus den folgenden Komponenten:\n■ Reifegrade (maturity levels) Die oberste Ebene des CMM wird durch fünf Reifegrade gebildet. Die Anforde- rungen, die eine Organisation zur Erlangung eines gewissen Reifegrads erfüllen\n(key process areas)\nAbb. 9.14 Grundstruktur des Capability Maturity Models (CMM)\nmuss, spiegeln die evolutionäre Entwicklung eines Unternehmens wider. Die ein- zelnen Stufen sind aufeinander aufbauend ausgelegt und spannen den Bogen von Unternehmen ohne erkennbare Planungsaktivitäten (Level 1) bis hin zu Organi- sationsstrukturen auf Basis selbstoptimierender Prozesse (Level 5).\n■ Befähigung (process capability) Jeder Reifegrad ist mit einer Reihe von Fähigkeiten verbunden, die eine Orga- nisation durch den Einsatz eines Software-Prozesses erlangt. Die Prozessbefä- higung gibt der Organisation ein Mittel an die Hand, um den Verlauf und die Ergebnisse eines Folgeprojekts zu steuern und zu prognostizieren.\n■ Schlüsselbereiche (key process areas) Jeder Reifegrad besteht aus mehreren Schlüsselbereichen, den key process are- as. Jeder Schlüsselbereich legt eine Reihe von Aktivitäten fest. Die gemeinsame Durchführung der Aktivitäten versetzt die Organisation in die Lage, bestimmte Ziele zu erreichen, die für die Prozessbefähigung auf einer bestimmten Reifestufe als besonders wichtig erachtet werden.\n■ Ziele (goals) Ob eine Organisation die Maßgaben der verschiedenen Schlüsselbereiche er- reicht, wird über die Erfüllung oder Nichterfüllung der Ziele gemessen. Durch\ndie Formulierung klarer Ziele treten der Geltungsbereich und die Intention eines Schlüsselbereiches hervor. Durch den direkten Vergleich der assoziierten Ziele wird insbesondere die gegenseitige Abgrenzung zweier Schlüsselbereiche deut- lich vereinfacht.\n■ Allgemeine Fähigkeiten (Common features) Jeder Schlüsselbereich setzt sich aus fünf verschiedenen Fähigkeitskategorien zusammen. Hierzu gehören die Bereiche Commitment to perform (Selbstver- pﬂichtung), Ability to perform (Handlungsbefähigung), Activities performed (Ak- tive Handlungen), Measurement and Analysis (Messung und Analyse), Verifying Implementation (Nachweisführung). Die Fähigkeiten sind so konzipiert, dass sie ein Unternehmen in die Lage versetzen sollen, effektiv, wiederholbar und nach- haltig zu operieren.\n■ Schlüsselpraktiken (key practices) Jeder Schlüsselbereich wird durch konkrete Maßnahmen, die sogenannten Schlüsselpraktiken, beschrieben. Diese beziehen sich zum einen auf die Infra- struktur und zum anderen auf die Aktivitäten innerhalb einer Organisation. Die Umsetzung der Maßnahmen befähigt ein Unternehmen, die Ziele eines Schlüs- selbereichs mit hoher Wahrscheinlichkeit zu erfüllen.\nAbb. 9.15 fasst die verschiedenen Reifegrade mit ihren jeweiligen Schlüsselberei- chen graﬁsch zusammen. In den folgenden Abschnitten werden die Reifegrade des Capability Maturity Models genauer vorgestellt und ein tieferer Einblick in die er- hofften Fähigkeiten einer zertiﬁzierten Organisation gegeben.\n9.2.2.1 CMM Level 1: Initial\nBei dieser Stufe handelt es sich um keinen Reifegrad im eigentlichen Sinne. Or- ganisationen der Stufe 1 sind vor allem durch lose Strukturen und einen Mangel an Planungsaktivitäten charakterisiert. Der Erfolg einer Firma ist mit der Leistung einzelner Personen verbunden und lässt sich aufgrund der fehlenden Strukturen nur sehr schwer oder gar nicht wiederholen. Organisationen dieser Stufe sind aus die- sem Grund nur bedingt in der Lage, Parameter wie Umfang, Zeitbedarf und Kosten eines Folgeprojekts adäquat vorherzusagen. Alle nicht zertiﬁzierten Firmen werden automatisch diesem CMM-Level zugeordnet.\n9.2.2.2 CMM Level 2: Repeatable\nOrganisationen der Stufe 2 zeichnen sich vor allem durch ein geplantes und doku- mentiertes Vorgehen auf Projektebene aus. Die Schaffung grundlegender Kommu- nikationsstrukturen und Arbeitsabläufe versetzen die Mitarbeiter eines Projekts in die Lage, Prozesse wiederholt durchzuführen und den Erfolg oder Misserfolg von der Leistung Einzelner, zumindest teilweise, abzukoppeln. Organisationen der Stufe 2 besitzen feste Arbeitsabläufe für die Bereiche Projektplanung, Anforderungsma- nagement, Konﬁgurationsmanagement, Fortschrittsverfolgung und Qualitätssiche- rung.\nOrganization Process De ﬁ nition\nSoftware Project Tracking and\nSoftware Con ﬁ guration Management\n3: Deﬁ ned\nAbb. 9.15 Reifegrade und Schlüsselbereiche des Capability Maturity Models\nDurch den zusätzlich verursachten Aufwand kann sich die mittlere Bearbeitung eines Projekts im direkten Vergleich mit einer Stufe-1-Organisation sogar verlän- gern. Verringert wird dagegen der Streuungsgrad (Varianz), so dass sich die Para- meter Umfang, Zeitbedarf und Kosten zwischen ähnlichen Projekten weniger stark unterscheiden. Die Vorteile einer Organisation dieser Stufe liegen damit vor allem in einer besseren Planbarkeit und Termintreue. Dieser Reifegrad besitzt die folgenden Schlüsselbereiche:\n■ Requirements Management Die Anforderungen eines Software-Systems müssen in geordneter Art und Wei- se erfasst, verwaltet und im Rahmen eines deﬁnierten Änderungsmanagements systematisch aktualisiert werden. Die Organisation muss in der Lage sein, ein\ngegenseitiges Verständnis zwischen dem Unternehmen und dem Kunden herzu- stellen. Hierzu gehört die Einrichtung transparenter Kommunikationswege zwi- schen Auftraggeber und -nehmer sowie die Etablierung von Review-Prozessen, die im Rahmen einer geregelten Anforderungsanalyse durchgeführt werden.\n■ Software Project Planning Alle Aktivitäten innerhalb eines Projekts werden geplant. Hierzu gehören die Auswahl des Mitarbeiterstabs, die Erstellung von Termin- und Kostenschätzun- gen sowie die Identiﬁkation von Projektrisiken und möglichen Gegenmaßnah- men. Die Planung wird systematisch durchgeführt und ist damit selbst ein inte- graler Bestandteil des Software-Prozesses.\n■ Software Project Tracking and Oversight Die Planung des Projekts geht Hand in Hand mit der Überwachung desselben. Der Schlüsselbereich ist mit dem Ziel verbunden, den Projektfortschritt durch geeignete Maßnahmen zu überwachen und mit entsprechenden Gegenmaßnah- men problemgerecht zu reagieren. Angestrebt wird eine maximale Transparenz des Projektfortschritts auf Entwickler-, Management- und Kundenebene.\n■ Software Subcontract Management Der Schlüsselbereich ist für diejenigen Unternehmen relevant, die Teile eines Projekts im Rahmen des Outsourcings durch einen oder mehrere Unterauftrag- nehmer (sub contractor) bearbeiten lassen. In Organisationen dieser Reifestufe werden die zwischen dem Unternehmen und den Kunden bestehenden Formalis- men auf alle Unterauftragnehmer übertragen. Der maßgebliche Unterschied liegt in diesem Fall in einem Wechsel der Perspektive, da das Unternehmen jetzt selbst in der Rolle des Auftraggebers agiert.\n■ Software Quality Assurance Organisationen dieser Stufe verfolgen das Prinzip einer unabhängigen und integrierten Qualitätssicherung. Mit anderen Worten: Die Software- Qualitätssicherung ist ein eigenständiger Bestandteil des organisatorischen Ab- laufmodells und in allen Phasen eines Projekts präsent. Die Aufgabe der Qua- litätssicherung ist zweigeteilt. Zum einen besitzt sie eine unterstützende Funkti- on, in der den Mitarbeitern der verschiedenen Projekte beratend unter die Arme gegriffen wird. Zum anderen verfolgt die Qualitätssicherung das Ziel, die Trans- parenz zwischen den einzelnen Projekten und dem Management zu erhöhen. In Abschnitt 9.2.5 werden wir auf diesen Punkt zurückkommen und uns genauer mit der Frage beschäftigen, ob der hier abverlangte Spagat in der Praxis überhaupt zu leisten ist.\n■ Software Conﬁguration Management Die im Rahmen eines Software-Projekts erstellten Artefakte werden systema- tisch verwaltet. Hierzu gehört unter anderem die Deﬁnition klarer Ablagestruk- turen, die dem häuﬁg vorherrschenden Chaos in der Dokumentenverwaltung ent- gegenwirken. Des Weiteren müssen Änderungen dokumentiert und nachvollzieh- bar sein. Zur Erreichung der Ziele werden Artefakte in der Regel mit Hilfe von\nVersionsverwaltungssystemen kontrolliert, die in Abschnitt 8.1 ausführlich dis- kutiert wurden.\n9.2.2.3 CMM Level 3: Deﬁned\nOrganisationen der Stufe 3 heben die in Stufe 2 etablierten Planungsabläufe auf die Unternehmensebene. Die Durchführung eines Projekts wird durch ein standardisier- tes Vorgehensmodell beschrieben, das als unternehmensweite Vorlage dient und an die speziellen Bedürfnisse einzelner Projekte individuell angepasst werden kann. Der organisationsweite Fokus eröffnet die Möglichkeit, Erfahrungen und Vorge- hensweisen eines Projekts auf andere zu übertragen. Hierzu werden die kontinuier- lich anfallenden Daten eines Projekts systematisch erfasst, analysiert und archiviert. Erstmals liegt in dieser Stufe auch ein Augenmerk auf der Qualität der etablierten Methoden. Hierzu gehören Aspekte wie die Schulung von Mitarbeitern oder die Durchführung von Peer reviews. Dieser Reifegrad besitzt die folgenden Schlüssel- bereiche:\n■ Organization Process Focus Es werden Maßnahmen ergriffen, die den Software-Entwicklungsprozess von der Projektebene auf die Unternehmensebene heben. Organisationen dieses Reife- grads sind langfristig bereit, in Software-Prozesse zu investieren. Typischerwei- se spiegelt sich die Einsatzbereitschaft direkt in der Unternehmensstruktur wie- der, z. B. durch die Etablierung einer Software Engineering Process Group, kurz SEPG, die organisationsweit operiert.\n■ Organization Process Deﬁnition Im Kern steht die Deﬁnition eines unternehmensweiten Vorgehensmodells, das projektübergreifend eingesetzt wird. Die Deﬁnition eines standardisierten Mo- dells verfolgt das Ziel, die erfolgreichen Praktiken (best practices) aus unter- schiedlichen Projekten zu vereinen und organisationsweit zu nutzen.\n■ Training Program Die Weiterbildung des Personalstabs wird als ein Schlüsselelement für den lang- fristigen Erfolg einer Organisation angesehen. Hierzu werden Trainingsprogram- me als fester Bestandteil in die Unternehmensprozesse integriert. Typische Maß- nahmen umfassen in diesem Zusammenhang die Erfassung des Weiterbildungs- bedarfs sowie die Durchführung von Schulungen auf Entwickler- und Manage- mentebene.\n■ Integrated Software Management Das unternehmensweit erarbeitete Vorgehensmodell wird für jedes Projekt auf die speziellen Bedürfnisse zugeschnitten. Die Anpassung erfolgt anhand unter- nehmensweiter Richtlinien, die den Kern dieses Schlüsselbereichs bilden. Haupt- sächlich werden die Maßnahmen der Bereiche Project Planning und Project Tracking and Oversight fortgeschrieben, die bereits in Rahmen einer Level-2- Zertiﬁzierung etabliert wurden.\n■ Software Product Engineering Die Methoden und Techniken der Produktentwicklung entsprechen dem Stand der Technik. Inhaltlich bezieht die Bewertung zum einen die eingesetzten Me- thoden des Software-Engineerings und zum anderen die zur Verfügung stehen- den Werkzeuge und Infrastrukturmaßnahmen mit ein. Zeitlich erstreckt sich die Bewertung über sämtliche Phasen eines Projekts, angefangen von der Anforde- rungsanalyse über die verschiedenen Entwicklungsstufen bis hin zum ﬁnalen Ab- nahmetest.\n■ Intergroup Coordination Dieser Schlüsselbereich beschäftigt sich mit den organisatorischen Strukturen und Maßnahmen, die eine produktive Zusammenarbeit zwischen den Mitarbei- tern verschiedener Arbeitsgruppen sicherstellen. Ein besonderer Fokus liegt auf der effektiven Kommunikation zwischen Software-Entwicklern und Ingenieu- ren anderer Fachrichtungen. Die fachübergreifende Zusammenarbeit wird als ein Schlüsselelement für die erfolgreiche Produktentwicklung auf Systemebene an- gesehen.\n■ Peer Reviews Peer Reviews sind ein leistungsfähiges Instrument der Software- Qualitätssicherung. In Organisationen dieses Reifegrads ist die Durchführung entsprechender Reviews institutionalisiert und damit ein fester Bestandteil des Entwicklungsprozesses. Neben der Verbesserung der Produktqualität wird das Wissen eines Software-Entwicklers zugleich an eine größere Entwicklergrup- pe weitergegeben. Damit helfen Reviews, zwei weitere Ziele des CMM zu erreichen. Sie entpuppen sich als ein Instrument der Mitarbeiterfortbildung und tragen gleichzeitig dazu bei, den Unternehmenserfolg aktiv von einzelnen Individuen abzukoppeln.\n9.2.2.4 CMM Level 4: Managed\nIn Unternehmen der Stufe 4 werden verschiedene Aspekte eines Projekts quantitativ erfasst und für die Überwachung des Projektfortschritts verwendet. Hierzu werden zu Beginn eines Projekts verschiedene Termin-, Aufwands- und Kostenschätzungen durchgeführt und in dessen Verlauf mit den realen Messdaten abgeglichen. Zur Er- höhung der Präzision werden gesammelte Daten aus alten Projekten systematisch in die Schätzung einbezogen. Die Maßnahmen der Stufe 4 geben dem Management wertvolle Werkzeuge an die Hand, um Projektverzögerungen frühzeitig zu erkennen und damit in angemessener Art und Weise reagieren zu können. Mit der systema- tischen Einbeziehung historischer Daten ist die Hoffnung verbunden, die durchge- führten Schätzungen kontinuierlich präzisieren zu können. Dieser Reifegrad besitzt die folgenden Schlüsselbereiche:\n■ Quantitative Process Management Das Unternehmen ist in der Lage, die Güte der eingesetzten Software-Prozesse quantitativ zu erfassen. Die Messung der relevanten Prozessparameter erfolgt\nebenfalls in einem deﬁnierten Prozess und bezieht alle Phasen eines Projekts mit ein. Durch die permanente Analyse der Messdaten werden Abweichungen erkannt und frühzeitig mit deﬁnierten Maßnahmen beantwortet. Transparente Messverfahren sowie der Rückgriff auf historische Daten versetzen die Orga- nisation in die Lage, die Leistungsfähigkeit der unternehmenseigenen Prozesse selbst zu messen und in objektiven Maßzahlen auszudrücken.\n■ Software Quality Management Neben der Bewertung der Software-Prozesse ist das Unternehmen in der Lage, die verschiedenen Qualitätsparameter der entwickelten Produkte quantitativ zu erfassen. Zudem ist die Organisation befähigt, die Software-Prozesse auf vor- her festgelegte Qualitätsziele auszurichten und durch geeignete Maßnahmen zu erreichen. Die Zielerreichung kann zu jeder Zeit quantitativ gemessen werden.\n9.2.2.5 CMM Level 5: Optimizing\nOrganisationen der Stufe 5 heben das Änderungsmanagement von der Projekt- auf die Prozessebene. Diese Unternehmen zeichnen sich dadurch aus, dass Prozesse nicht nur systematisch eingesetzt, sondern zusätzlich permanent evaluiert und op- timiert werden. Die Veränderung eines Prozesses wird damit selbst zu einem stan- dardisierten Prozess. Die Grundlage für die Prozessverbesserung bilden die statisti- schen Daten, die mit den Methoden und Techniken aus Level 4 erhoben wurden. Die Maßnahmen der Stufe 5 sind vor allem mit der Hoffnung verbunden, ein Unterneh- men schaffen zu können, das Veränderungen regelmäßig und systematisch vollzieht und in selbstoptimierender Weise sowohl die Qualität als auch die Efﬁzienz konti- nuierlich steigert. Dieser Reifegrad besitzt die folgenden Schlüsselbereiche:\n■ Defect Prevention Das Unternehmen ist in der Lage, Fehler systematisch zu analysieren. In einem geregelten Prozess werden Maßnahmen ergriffen, die ein erneutes Auftreten mit hoher Wahrscheinlichkeit verhindern. Neben den Ursachen werden im Rahmen der Analyse auch die Auswirkungen der aufgetretenen Fehler auf den weiteren Projektverlauf evaluiert. Das Fehlermanagement wird sowohl auf Projekt- als auch auf Unternehmensebene durchgeführt und hierdurch ein geregelter Infor- mationsﬂuss zwischen den Einzelprojekten ermöglicht.\n■ Technology Change Management Neue Technologien werden regelmäßig begutachtet und auf den möglichen Ein- satz innerhalb des Unternehmens untersucht. Erweist sich eine Technologie als aussichtsreicher Kandidat, so wird dessen Eignung in speziell ausgewählten Pro- jekten detailliert untersucht. Ein solches Pilotprojekt unterliegt einer besonderen Planung und wird durch organisationsweit operierende Teams unterstützt. An- gestrebt wird ein kontinuierlicher Wissenstransfer unter gleichzeitiger Minimie- rung der Risiken, die mit der Änderung bestehender Technologien und Arbeits- abläufe zwangsläuﬁg verbunden sind.\n■ Process Change Management Genau wie neue Technologien einer regelmäßigen Evaluierung unterzogen wer- den, strebt die Organisation eine kontinuierliche Optimierung der eingesetzten Software-Prozesse an. Ziel der Verbesserung ist zum einen die Steigerung der verschiedenen Software-Qualitätsparameter und zum anderen die Erhöhung der unternehmenseigenen Produktivität. Die Prozessverbesserung wird organisati- onsweit durchgeführt und durch das Senior-Management gefördert. Genau wie im Falle des Technology Change Managements werden Prozessverbesserungen zunächst in einem oder mehreren Pilotprojekten evaluiert und anschließend unter Berücksichtigung der gewonnenen Erkenntnisse auf sämtliche Unternehmensbe- reiche ausgedehnt.\nHat ein Unternehmen die Maßnahmen zur Erreichung eines Reifegrads vollständig umgesetzt, so kann die Prozessreife innerhalb eines Assessments festgestellt wer- den. Ein CMM-Assessment wird in Form eines formalen Audits durchgeführt. Um die Objektivität der Zertiﬁzierung zu gewährleisten, wird das Audit durch eine ex- terne Zertiﬁzierungsorganisation geleitet. Verläuft das Assessment erfolgreich, so wird der Reifegrad der Organisation durch ein Zertiﬁkat formal bescheinigt. Ob- wohl eine vollständig durchgeführte Zertiﬁzierung erhebliche Kosten verursacht, ist der Erhalt eines Prozessreifezertiﬁkats für ein Unternehmen in zweierlei Hinsicht von Bedeutung:\n■ Innenwirkung Die Zertiﬁzierung unterstreicht das unternehmenseigene Qualitätsverständnis. Durch das Erlangen eines Zertiﬁkats bekennt sich eine Organisation zu den Zie- len des attestierten Reifegrads und signalisiert dem Personalstab, die deﬁnierten Arbeitsabläufe und Maßnahmen mit hoher Priorität zu befolgen. Des Weiteren wird die Prozessreife der Organisation von einer neutralen Instanz bestätigt, so dass die formale Zertiﬁzierung das Vertrauen eines Unternehmens in die eige- nen Prozesse deutlich erhöhen kann. Zusätzlich werden im Rahmen eines Audits Verbesserungsvorschläge ausgearbeitet, die für die zukünftige Entwicklung der Organisationsstrukturen gewinnbringend eingesetzt werden können.\n■ Außenwirkung Viele Unternehmen erreichen durch ein Prozesszertiﬁkat eine nicht zu unter- schätzende Außenwirkung. Zum einen trägt die Zertiﬁzierung weite Teile der Unternehmensphilosophie nach außen, zum anderen kann ein erfolgreich erwor- benes Zertiﬁkat helfen, das kundenseitige Vertrauen in die Leistungsfähigkeit des Unternehmens zu stärken. In einigen Bereichen setzten Auftraggeber bei der Auswahl ihrer Unterauftragnehmer eine Zertiﬁzierung sogar zwingend voraus. Üblich sind solche Vorgehensweisen insbesondere in sicherheitskritischen Be- reichen, wie z. B. in der Automobil- und Luftfahrtindustrie. In diesen Fällen er- übrigt sich die Frage nach dem Sinn einer Zertiﬁzierung gänzlich – sie ist hier eine Grundvoraussetzung für den Erhalt eines Auftrags.\nFinal ﬁ ndings\nDauer: 1-2 Wochen, abhängig von der Projektgröße\nMeldung an SEI\nAbb. 9.16 CMM-Audit\nWie in Abb. 9.16 skizziert, erfolgt ein formales Reifegradaudit in drei Phasen, die nacheinander durchlaufen werden.\n■ Phase 1 Nach der Auftragserteilung erfolgen zunächst mehrere vorbereitende Gespräche zwischen der gewählten Zertiﬁzierungsorganisation und dem Auftraggeber. Es wird ein Audit-Team gebildet, das sich aus einem externen Auditleiter sowie mehreren Co-Auditoren zusammensetzt. Anschließend werden im Rahmen ei- nes Dokumenten-Reviews die Strukturen und Abläufe der Organisation erfasst. Die Analyse wird durch vorgefertigte Fragelisten unterstützt. Aufgrund der ge- wonnenen Ergebnisse erstellt der Auditleiter eine Vorbeurteilung, die einen ers- ten Rückschluss auf die Erfolgsaussichten der Zertiﬁzierung ermöglicht. Fällt die Beurteilung positiv aus, werden die Inhalte der restlichen Phasen geplant und der zeitliche Ablauf festgelegt.\n■ Phase 2 Die zweite Phase des Reifegradaudits wird vollständig vor Ort durchgeführt und erstreckt sich in Abhängigkeit der Projekt- und Organisationsgröße über einen Zeitraum von 1 bis 2 Wochen. Die Prozessreife der Organisation wird im Rah- men mehrerer Interviews überprüft, die mit den verschiedenen Personengruppen des Unternehmens getrennt geführt werden. Entwickler-Interviews werden meist in Form von Gruppenbefragungen durchgeführt und haben zum Ziel, die Ar- beitsabläufe mit dem festgelegten Vorgehensmodell abzugleichen. Projektleiter- und Management-Interviews werden zumeist in Einzelgesprächen abgehalten und dienen zur Evaluierung der technischen und organisatorischen Arbeitsab-\nläufe auf Projekt- und Unternehmensebene. Nach jedem Interview werden die gesammelten Stellungnahmen bewertet und mit den Anforderungen und Zielen der angestrebten Reifestufe abgeglichen. Zusätzlich wird die Konsistenz der ge- tätigten Aussagen gruppenübergreifend geprüft.\n■ Phase 3 Die in der Interview-Phase gesammelten Informationen werden zusammengetra- gen und der Unternehmensleitung durch das Audit-Team in Form eines vorläuﬁ- gen Untersuchungsergebnisses präsentiert (Draft ﬁndingsdraft ﬁndings). Im An- schluss daran werden verschiedene Gruppen-Interviews durchgeführt, in denen vorher getätigte Aussagen präzisiert oder etwaig entstandene Missverständnisse ausgeräumt werden können. Die Ergebnisse der Gruppen-Interviews werden mit den Draft ﬁndings abgeglichen und der endgültige Untersuchungsbericht erstellt (ﬁnal ﬁndings). Die Ergebnisse der Final-Findings entscheiden über die Zerti- ﬁkaterteilung und enthalten zusätzliche Vorschläge und Empfehlungen für die Prozessoptimierung und -weiterentwicklung. Zu guter Letzt wird das Ergebnis der Zertiﬁzierung für statistische Zwecke an das Software Engineering Institute (SEI) gemeldet und das Audit hierdurch ofﬁziell abgeschlossen.\nDas in Abschnitt 9.2.2 im Detail vorgestellte Capability Maturity Model wurde vom SEI speziell für den Bereich der Software-Entwicklung konzipiert. Um diesen Zusammenhang deutlich zu machen, wird das Modell mitunter auch als Software- CMM, kurz SW-CMM, bezeichnet. Mit der steigenden Popularität des Capability Maturity Models entstanden in den Neunzigerjahren vergleichbare CMMs für an- dere Anwendungsdomänen. Hierzu zählen die Bereiche System engineering (SE- CMM, ), Software acquisition (SA-CMM, ), Integrated product development (IPD-CMM, ) und Human ressources (P-CMM, ). Die anhaltende Diversiﬁzierung blieb nicht ohne Folgen. Unternehmen, die sich der Reifegradphilosophie des SEI ernsthaft verschrieben, waren mehr und mehr gezwungen, verschiedene CMM-Modelle parallel zu implementieren. Durch die hiermit verbundenen Doppelarbeiten sowie ab und an auftretenden Inkonsistenzen wuchs das Risiko, den Nutzen eines solchen Reifegradmodells ad absurdum zu füh- ren. Dem fortschreitenden Wirrwarr machte das SEI mit dem CMMI- Reifegradmodell (CMM Integration) ein Ende [2, 44, 152]. Die bereits begonnenen Arbeiten an der Version 2.0 des Software-CMMs wurden eingestellt und stattdessen mit dem CMMI ein universelles Modell konzipiert, das mehrere Disziplinen in sich vereint. Die bereits geleisteten Arbeiten an der Version 2.0 des SW-CMM waren jedoch nicht umsonst – zahlreiche Elemente der Draft-Version wurden ohne Änderungen in das CMMI-Modell übernommen. Wie schon sein Vorgänger wurde auch CMMI zunächst als Entwurf veröffentlicht und in einer zweijährigen Erprobungsphase optimiert. Im Jahre 2000 wurde das CMMI in der Version 1.02 veröffentlicht und ein Jahr später durch die Version 1.1 ersetzt [246, 245]. Im\nAugust 2006 erschien mit der Version 1.2 die bis dato letzte Überarbeitung des Standards . Der konzeptuelle Entwurf von CMMI wurde durch drei Ziele maßgeblich beein- ﬂusst:\n■ Universalität Anders als das CMM ist das CMMI nicht speziell für den Bereich der Software- Entwicklung konzipiert. Stattdessen stellt das CMMI ein universelles Modell- gerüst zur Verfügung, das die erfolgreichsten Elemente der diversen CMM- Vorgängermodelle in sich vereint und bereichsübergreifend eingesetzt werden kann. Durch die individuelle Erweiterung dieses Grundgerüsts werden andere Disziplinen mit einbezogen. Den Kern des Modells bildet das CMMI-SE/SW, das die Bereiche System Engineering (SE) und Software Engineering (SW) abdeckt. Das Reifegradmodell CMMI-SE/SW/IPPD/SS erweitert den Kern um die Berei- che Integrated Product and Process Development (IPPD) und Supplier Sourcing (SS).\n■ Flexibilität Das strenge Stufenmodell des CMM empfanden vielen Unternehmen als zu starr, da im Rahmen einer Zertiﬁzierung die entsprechende Reife in ausnahmslos allen Schlüsselbereichen nachgewiesen werden musste. Unternehmen waren dadurch gezwungen, Schlüsselbereiche der nächsten Stufe zurückzustellen, auch wenn diese für das Erreichen der Geschäftsziele hätten vorrangig behandelt werden müssen. Mit dem CMMI wurde aus diesem Grund ein kontinuierliches Bewertungs- schema eingeführt (continous representation), das das starre Korsett der Reife- stufen beseitigt. Durch die erhöhte Flexibilität können die Prozesse besser den Geschäftszielen angepasst werden und stehen seltener mit diesen im Konﬂikt.\n■ Kompatibilität Die Transition von CMM zu CMMI sollte so einfach wie möglich gestaltet wer- den, um die getätigten Investitionen bereits zertiﬁzierter Unternehmen weitge- hend zu erhalten. Gelöst wurde dieses Problem durch die Einführung paralleler Bewertungsschemata. Neben der bereits erwähnten kontinuierlichen Bewertung unterstützt CMMI weiterhin ein Stufenmodell (staged representation), das sich stark an den Inhalten des ursprünglichen CMM orientiert. Die gestufte Bewer- tung zeigt die altbekannten Flexibilitätsdeﬁzite, erlaubt es CMM-zertiﬁzierten Firmen jedoch, mit vergleichsweise geringem Aufwand in die CMMI-Welt zu migrieren.\nObwohl sich das kontinuierliche und das gestufte Bewertungsschema nach außen hin erheblich unterscheiden, decken sie inhaltlich dieselben Bereiche ab. Wie in Abb. 9.17 gezeigt, bestehen beide Schemata aus insgesamt 22 Schlüsselbereichen, die matrixartig angeordnet sind. Die vertikale Anordnung folgt dem Stufenmodell des CMM. Wie im Fall des ursprünglichen Capability Maturity Models entspricht die Stufe 1 keinem Reifegrad im eigentlichen Sinne und ist dementsprechend mit keinen Schlüsselbereichen assoziiert.\nVeri ﬁ cation\nAbb. 9.17 CMMI unterstützt sowohl die gestufte (vertikal) als auch die kontinuierliche Bewertung (horizontal) der Prozessreife\nDie horizontale Anordnung reﬂektiert das kontinuierliche Bewertungsschema des CMMI. Das Modell deﬁniert vier verschiedene Process area categories (PACs), die jeweils mehre Schlüsselbereiche zusammenfassen. An die Stelle der Maturity levels treten Capability levels, mit deren Hilfe die erreichten Fähigkeiten für jeden Schlüsselbereich individuell bewertet werden können. CMMI deﬁniert insgesamt 6\nAbb. 9.18 Zusammenhang zwischen den Maturity levels und den Capability levels von CMM und CMMI\nTabelle 9.1 Der Equivalent-Staging-Mechanismus des CMMI erlaubt, Reifeproﬁle des kontinu- ierlichen Modells auf die Reifegrade des Stufenmodells abzubilden\nKPAs der Stufe 2\nKPAs der Stufe 3\nKPAs der Stufe 4\nKPAs der Stufe 5\nReifestufe 1 ist erfüllt, wenn\nReifestufe 2 ist erfüllt, wenn\nReifestufe 3 ist erfüllt, wenn\nReifestufe 4 ist erfüllt, wenn\nReifestufe 5 ist erfüllt, wenn\nverschiedene Capability levels, die in Abb. 9.18 den Reifegraden des CMM- bzw. CMMI-Stufenmodells gegenübergestellt sind. Aufgrund der separaten Bewertung der einzelnen Schlüsselbereiche kann die Reife eines Unternehmens nicht mehr länger durch eine einzige Stufe charakteri- siert werden. Stattdessen wird der aktuelle Prozesszustand einer Organisation in Form eines Reifeproﬁls gemessen, das jedem Schlüsselbereich einen Capability le-\nvel zwischen 0 (incomplete) und 5 (optimizing) zuordnet (vgl. Abb. 9.19). In der\nTerminologie des CMMI wird das entstehende Ergebnis auch als Capability level\nEin solches Reifeproﬁl spiegelt das kontinuierliche Bewertungsschema des CM-\nMI wieder, lässt sich jedoch auf direkte Weise auf das gestufte Schema abbilden.\nHierzu deﬁniert das CMMI für jeden Schlüsselbereich und jeden Reifegrad eine Mindestanforderung, die für die Erreichung der entsprechenden Stufe erfüllt sein muss. Die Zuordnung wird als Equivalent staging bezeichnet und ist in Tabelle 9.1 detailliert aufgeschlüsselt. Um beispielsweise die Reifestufe 3 zu erlangen, müssen\nIm Schlüsselbereich RM\nwird der Capability-Level 3\nabgebildete Reifepro ﬁ l der\nReifestufe 2 entspricht.\nAbb. 9.19 Im kontinuierlichen Bewertungsmodell des CMMI wird die Prozessreife einer Orga- nisation in einem Reifeproﬁl festgehalten, das alle Schlüsselbereiche unabhängig voneinander be- wertet. Reifeproﬁle lassen sich auf Reifegrade abbilden\ndie Schlüsselbereiche der Stufen 2 und 3 eine Bewertung von mindestens 3 auf- weisen. Die Schlüsselbereiche der Stufen 4 und 5 spielen dagegen keine Rolle. Ein Blick auf das Reifeproﬁl in Abb. 9.19 zeigt, das die Erfordernisse hier nicht erfüllt sind, da der Schlüsselbereich Risk Management (RM) nur einen Capability level von 2 aufweist. Insgesamt entspricht das abgebildete Proﬁl damit der Reifestufe 2 –\ndiese ist nach Tabelle 9.1 erreicht, sobald alle Schlüsselbereiche der Stufen 2 und 3 mit mindestens 2 bewertet sind. Um eine objektive Bewertung der Prozessreife zu gewährleisten, müssen die ver- schiedenen, für die Begutachtung eingesetzten Methoden vergleichbare und konsi- stente Ergebnisse liefert. Zu diesem Zweck wurden durch das Software Enginee- ring Institute die Appraisal Requirements for CMM (ARC) entwickelt, die ein Un- ternehmen in die Lage versetzen sollen, bestehende Methoden zu bewerten bzw. eine entsprechende Assessment-Methode nach vorgegebenen Richtlinien selbst zu entwickeln . Das SEI führt mit ARC drei Assessment-Typen ein, die sich be- züglich des Ressourcen-Verbrauchs erheblich unterscheiden. Class-B- und Class-C- Assessments ﬁnden in kleinen Gruppen von 2 bis 7 Personen statt und werden un- ternehmensintern ohne Beteiligung eines Lead-Assessors durchgeführt. Ein Lead- Assessor wird nur für Class-A-Assessments benötigt. Diese Assessment-Variante ist die formalste der drei und gleichzeitig die Voraussetzung für die ofﬁzielle Bewer- tung einer Organisation in Form eines Reifeproﬁls (kontinuierliches Bewertungs- schema) oder eines Reifegrads (gestuftes Bewertungsschema). Eine in der Praxis häuﬁg eingesetzte Bewertungsmethode ist die Standard CMMI Assessment Method for Process Improvement. Die kurz als SCAMPI bezeichnete Bewertungsmethode wurde durch das Software Engineering Institute entwickelt und erfüllt vollständig die Anforderungen eines Class-A-Assessments [249, 1].\n9.2.4 ISO 15504 (SPICE)\nAnfang der Neunzigerjahre wurde das SPICE-Projekt (Software Process Improve- ment and Capability dEtermination) ins Leben gerufen. Eine gemeinsame Arbeits- gruppe der ISO (International Organization for Standardization) und der IEC (In- ternational Electrotechnical Commission) erhielt die Aufgabe, einen internationa- len Standard für die Bewertung von Software-Entwicklungsprozessen zu erarbeiten. Der erste Arbeitsentwurf der geplanten Norm erschien im Jahre 1995 und wurde an- schließend in einer dreijährigen Erprobungsphase verfeinert. Im Dezember erschien mit der ISO/IEC 15504:1998(E) TR die Vorläuferversion der heute gültigen ISO- Norm. Der Entwurf erstreckte sich über insgesamt 9 Teile und enthielt mit Teil 2 unter anderem ein vollständig ausgestaltetes Referenzmodell. In der Folgezeit wurde der Entwurf weiterentwickelt und die ursprünglich vor- handenen neun Dokumente auf zunächst fünf reduziert. Der erste Teil wurde im Jahre 2003 publiziert, mit dem fünften Teil erschien im Jahre 2006 der vorerst letz- te. Teil 6 und 7 sind zurzeit in Bearbeitung. Im direkten Vergleich mit dem Refe- renzentwurf unterscheidet sich die verabschiedete Norm nicht nur in der Anzahl der Dokumente. So wurde das Referenzmodell aus der Vorläuferversion von 1998 wie- der entfernt und durch einen allgemeiner gehaltenen Anforderungskatalog für Refe- renzmodelle und Assessment-Methoden ersetzt. Beispiele für ISO-15504-konforme Referenzmodelle sind die ISO/IEC-Norm 12207 (software life cycle processes) und die ISO/IEC-Norm 15288 (system life cycle processes). Aufgrund seiner allgemeineren Natur tritt SPICE nicht in Konkurrenz zu CMM und CMMI. Während die beiden letztgenannten konkrete Modelle und Methoden\nidenti ﬁ ziert\nAbb. 9.20 Assessment-Modell von SPICE\ndeﬁnieren, postuliert die ISO-Norm 15504 eine Reihe von Anforderungen, die ein Modell bzw. eine Methode erfüllen muss. Insgesamt ist mit der ISO 15504 ein Mo- dell entstanden, dessen Vorgaben von CMM und CMMI sowohl inhaltlich als auch methodisch weitgehend erfüllt werden. Die Kompatibilität kommt an dieser Stelle nicht von ungefähr – das SEI war sowohl im Rahmen von Managementaufgaben als auch in der Rolle eines technischen Zulieferers (technical contributor) an der Entwicklung der Norm beteiligt. Inhaltlich erstreckt sich SPICE über drei Aufgabenbereiche (vgl. Abb. 9.20). Im Kern des Standards steht das Prozess-Assessment, das auch hier zwei Ziele ver- folgt: Mit Hilfe eines Assessments werden die Reife von Unternehmensprozessen strukturiert bewertet und zum anderen Verbesserungsvorschläge für deren Optimie- rung erarbeitet. SPICE legt den Fokus erstrangig auf die Selbstbewertung einer Organisation und nur zweitrangig auf die Zertiﬁzierung. Die Durchführung eines Prozess-Assessments ist durch das SPICE-Referenzmodell festgelegt, das sich aus zwei Dimensionen zusammensetzt: Der Prozess- und der Reifegraddimension (vgl. Abb. 9.21).\n9.2.4.1 Prozessdimension von SPICE\nDas Prozessmodell von SPICE unterscheidet drei verschiedene Prozesskategorien. Jede Kategorie ist ihrerseits in verschiedene Prozessgruppen aufgeteilt, die eine in- haltliche Gruppierung der typischen Arbeitsabläufe eines IT-Unternehmen vorneh- men (vgl. Tabelle 9.2 bis 9.4). Auf der obersten Ebene werden die folgenden Pro- zesskategorien unterschieden:\n■ Primary Life Cycle Processes Hier ﬁnden sich alle Arbeitsabläufe wieder, die sich in direkter Weise mit der\nProzesse werden in SPICE\nzu Kategorien und Gruppen\nwerden beschrieben durch\nfür die Erreichung der\nProzesse werden in sechs\nProzesse sind der\nDer Reifegrad eines\nProzesses wird über\nAbb. 9.21 Die zwei Dimensionen von SPICE\nDurchführung eines Projekts beschäftigen. Zum einen beinhaltet diese Kategorie alle Prozesse, die den Kunden und Lieferanten unmittelbar einbeziehen. Hierzu gehören unter anderem die Bereiche Beratung, Akquisition, Betreuung, Beliefe- rung und Support. Zum anderen fallen alle Prozesse in diese Kategorie, die sich mit der eigentlichen Produkterstellung beschäftigen. Beispiele sind die Anfor- derungsanalyse und die verschiedenen Facetten des Software-Entwurfs genauso wie die Bereiche Implementierung, Test und Wartung.\n■ Organizational Life Cycle Processes Diese Kategorie deckt die klassischen Bereiche des Software-Managements ab und umfasst die Projektplanung, die Fortschrittsüberwachung, das Qualitäts- und Risikomanagement sowie die Koordination und Überwachung der Zulieferer. Zusätzlich beinhaltet diese Kategorie alle Arbeitsabläufe, die eine Umsetzung der Unternehmensziele unterstützen oder überhaupt erst ermöglichen. Hierzu gehört die Aufrechterhaltung der Infrastruktur, die systematische Bereitstellung von Ressourcen sowie die Deﬁnition und Verbesserung der Prozesse selbst.\nTabelle 9.2 Primary Life Cycle Processes von SPICE\nAcquisition Process Group (ACQ)\nSupply Process Group (SPL)\nEngineering Process Group (ENG)\nOperation Process Group (OPE)\nTabelle 9.3 Organizational Life Cycle Processes von SPICE\nManagement Process Group (MAN)\nProcess Improvement Process Group (PIM)\nRessource and Infrastructure Process Group (RIN)\nReuse Process Group (REU)\n■ Support In dieser Kategorie sind alle Prozesse zusammengefasst, die eine unterstützende Funktion für andere Prozesse besitzen. Beispiele sind die Dokumentation, das Konﬁgurationsmanagement, die Veriﬁkation und Validation sowie die Qualitäts- sicherung.\nJeder Einzelprozess ist mit einem oder mehreren fest deﬁnierten Zielen assoziiert. Um ein Unternehmen in die Lage zu versetzen, die Ziele zu erreichen, wird in SPI- CE jeder Prozess durch eine Menge von Top-Level-Aktivitäten – den Base practi- ces – beschrieben. Exemplarisch sind in Abb. 9.23 die Kernelemente des SPICE-\nTabelle 9.4 Supporting Life Cycle Processes von SPICE\nSupport Process Group (SUP)\nProzesses SUP.8 (Konﬁgurationsmanagement) zusammengefasst. Um einen direk- ten Vergleich zu ermöglichen, ist in Abb. 9.22 eine Beschreibung des entsprechen- den Schlüsselgebiets Conﬁguration Management (CM) des CMMI dargestellt. Die großen inhaltlichen Gemeinsamkeiten der beiden Modelle werden hier mit wenigen Blicken deutlich. Der höhere Detaillierungsgrad von CMMI führt in der Praxis dazu, dass ein CMMI-zertiﬁziertes Unternehmen in den allermeisten Fällen die Vorgaben von SPICE erfüllt, nicht jedoch umgekehrt.\n9.2.4.2 Reifegraddimension von SPICE\nDie zweite Dimension von SPICE erstreckt sich über die Reife der Prozesse eines Unternehmens. Hierzu führt SPICE 6 Reifegrade ein, die in Abb. 9.24 zusammenge- fasst sind. Die Reife eines Prozesses wird anhand festgelegter Prozessattribute be- urteilt. Im Rahmen eines Assessments wird jedem Prozessattribut ein prozentualer Erfüllungsgrad zugewiesen, der anschließend auf eine vierstuﬁge Skala abgebildet wird. Die Skalenstufen unterscheiden die vollständige Erfüllung (86 % – 100 %), die weitgehende Erfüllung (51 % – 85 %), die teilweise Erfüllung (16 % – 50 %) und die Nichterfüllung (0 % – 15 %) der entsprechenden Anforderungen. Inhalt- lich erinnern die Reifestufen des SPICE-Modells sehr an die Maturity levels des CMM und CMMI, unterscheiden sich jedoch in zwei wesentlichen Punkten. Zum einen beurteilt SPICE, im Gegensatz zu CMM und CMMI, nicht die Reife einer Organisation, sondern ausschließlich die Reife von Prozessen. Zum anderen deﬁ- niert SPICE mit dem Reifegrad Performed eine zusätzliche Stufe, die kein direktes CMM- bzw. CMMI-Gegenstück besitzt und inhaltlich zwischen der ersten und der zweiten Stufe des CMM angeordnet ist. Sinnvoll ist dieser Reifegrad durchaus, da er denjenigen Organisationen bereits eine gewisse Reife attestiert, in denen Prozesse schon etabliert, jedoch noch nicht in Form eines komplexen Management-Überbaus manifestiert sind.\nSUP.8 Conﬁguration Management\nThe purpose of the process is to establish and maintain the integrity of the work products/items of a process or project and make them available to concerned parties.\n■ A conﬁguration management strategy is developed.\n■ Work products/items generated by the process or project are identiﬁed, deﬁned and baseli- ned.\n■ Modiﬁcations and releases of the work products/items are controlled.\n■ Modiﬁcations and releases are made available to affected parties.\n■ The status of the work products/items and modiﬁcations are recorded and reported.\n■ The completeness and consistency of the work products/items is ensured.\n■ Storage, handling and delivery of the work products/items are controlled.\n■ SUP.8.1: Develop conﬁguration management strategy\n■ SUP.8.2: Identify conﬁguration items\n■ SUP.8.3: Establish branch management strategy\n■ SUP.8.4: Establish baselines\n■ SUP.8.5: Maintain conﬁguration item description\n■ SUP.8.6: Control modiﬁcations and releases\n■ SUP.8.7: Maintain conﬁguration item history\n■ SUP.8.8: Report conﬁguration status\nAbb. 9.22 Der SPICE-Prozess SUP.8 (Konﬁgurationsmanagement)\n9.2.5 Bewertung und Kritik\n“Fundamentally, you get good software by thinking about it, designing it well, im- plementing it carefully, and testing it in- telligently, not by mindlessly using an ex- pensive mechanical process.”\nThe purpose of Conﬁguration Management is to establish and maintain the integrity of work products using conﬁguration identiﬁcation, conﬁguration control, conﬁguration status accounting, and conﬁguration audits.\nSpeciﬁc and Generic Goals\n■ SG 1: Establish Baselines\n■ SG 2: Track and Control Changes\n■ SG 3: Establish Integrity\n■ GG 4: Institutionalize a Managed Process\nPractices by Goal\n■ SP1.1: Identify Conﬁguration Items\n■ SP 1.2: Establish a Conﬁguration Management System\n■ SG 1.3: Create or Release Baselines\n■ SP 2.1: Track Change Requests\n■ SP 2.2: Control Conﬁguration Items\n■ SP 3.1: Establish Conﬁguration Management Records\n■ SP 3.2: Perform Conﬁguration Audits\nAbb. 9.23 Der Schlüsselbereich Conﬁguration Management des CMMI \nMit der Einführung des Capability Maturity Models erlebten die Reifegradmo- delle Ende der Achtzigerjahre einen regelrechten Boom, der bis heute in ungebro- chener Form anhält. Trotzdem sollte die Einführung eines Prozessmodells stets mit Bedacht und Sorgfalt geschehen. Neben den vielen unbestrittenen Stärken, die in der Vergangenheit mehrfach unter Beweis gestellt wurden, ist die Einführung eines schwergewichtigen Prozessmodells auch mit Nachteilen und Risiken verbunden. Ei- nige der am häuﬁgsten geäußerten Kritikpunkte sind im Folgenden zusammenge- fasst:\n■ Die Qualitätssicherung in der Zwickmühle In nahezu allen Reifegradmodellen spielt die Software-Qualitätssicherung eine zwiespältige Doppelrolle. Auf der einen Seite ist sie mit dem Auftrag ausgestat- tet, eine beratende Funktion innerhalb der Projekte auszuüben. Auf der anderen Seite ist sie ein zentrales Steuerungsinstrument des Managements. Diese Rolle wird insbesondere dadurch untermauert, dass die Software-Qualitätssicherung in Form einer eigenständigen und unabhängig operierenden Abteilung organisiert\nFully achieved (86%-100%)\nLargely achieved (51%-85%)\nPartially achieved (16%-50%)\nNot achieved (0%-15%)\nAbb. 9.24 Die Reifegraddimension von SPICE\nist und direkt an das Management berichtet. In der Praxis ist diese Doppelrolle kaum in angemessener Form zu erfüllen. Aufgrund ihrer kontrollierenden Funk- tion wird die QS-Abteilung nicht selten als Fremdkörper oder gar als Feind emp- funden – als der „Big Brother“ oder die „dunkle Seite der Macht“. Die Idee einer beratenden und unterstützenden Institution wird hierdurch faktisch ad absurdum geführt. Nichtsdestotrotz ist das Interesse des Managements, durch die Etablie- rung entsprechender Strukturen mehr Transparenz in die Projekte zu bringen, be- rechtigt und in vielen Fällen unvermeidlich. Vergessen wird an dieser Stelle nur allzu oft, dass die Messung, welcher Projektparameter auch immer, einen Eingriff in ein zum Teil fragiles System menschlicher Individuen nach sich zieht. Wird die Kontrolle innerhalb der Projekte als zu stark empfunden, werden die Projekt- beteiligten in einer natürlichen Reaktion versuchen, sich dagegen abzuschotten. Physiker unter den Lesern mögen sich an Schrödingers Katze erinnert fühlen – diese stirbt ebenfalls mit der Messung (vgl. Abb. 9.25). Die gängigen Reife- gradmodelle werden der Problematik an dieser Stelle nur unzureichend gerecht und suggerieren mit der großﬂächigen Installation schwergewichtiger Prozesse eine einfache Lösung für ein Problemspektrum, das mit einfachen Mitteln in der Praxis kaum zu bewältigen ist.\nNach der Kopenhagener Deutung der Quan- tenphysik führt die Messung durch einen Be- obachter dazu, dass ein Teilchen, das sich in einem Überlagerungszustand beﬁndet, schlag- artig in einen der beiden möglichen Zustände wechselt. Im Jahre 1935 leitete Erwin Schrö- dinger hieraus das folgende Gedankenexperi- ment ab: Eine Katze wird in einen geschlos- sen Raum gesperrt, in dem sich eine Cyanid- phiole beﬁndet. Das Zerbersten der Phiole ist an ein Quantenereignis gekoppelt, so dass sich der Quantentheorie zufolge auch die Katze in einem Überlagerungszustand aus lebend und tot beﬁnden muss. Erst die Messung entschei- det über das Leben oder Sterben des Tieres. In 50 % der Fälle bringt die Messung der Katze den Tod.\nAbb. 9.25 Schrödingers Katze. Parallelen zum Projektmanagement?\n■ Wo bleiben die individuellen Stärken? Die Wiederholbarkeit und die Planbarkeit eines Projekts sind zwei Kernaspek- te aller hier vorgestellten Reifegradmodelle. Um die Ziele zu erreichen, wer- den zahlreiche Maßnahmen ergriffen, um die Leistungsfähigkeit des Unterneh- mens von der Leistung einzelner Individuen zu entkoppeln. In der Tat wird dem Heldentum durch die Etablierung deﬁnierter Prozesse erfolgreich vorge- beugt – mit unbestritten positiven, aber auch mit negativen Auswirkungen. Selbst wenn die Reifegradmodelle die Entfaltungsmöglichkeiten des einzelnen Software-Entwicklers nicht per se in Fesseln legen, stellt sich diese Symptoma- tik in der Praxis häuﬁg ein. Die Gefahr ist an dieser Stelle eminent groß, das Potenzial der sogenannten Helden versiegen zu lassen oder die entsprechenden Mitarbeiter gar unbemerkt zu verlieren. Immer mehr prozessgetriebene Organi- sationen gehen beispielsweise dazu über, Programmierer in Ressourcen-Pools zu organisieren – getrieben von der Annahme einer uniformen Leistungsfähigkeit und der beliebigen Austauschbarkeit der Ressource Mensch. Empirische Unter- suchungen der Vergangenheit werden an dieser Stelle genauso beharrlich wie ve- hement mit Füßen getreten. So ist seit Mitte der Achtzigerjahre belegt, dass sich die Produktivität einzelner Software-Ingenieure um den Faktor 4 (Boehm ) bis 10 (DeMarco, Lister ) unterscheidet – weit mehr als in jeder anderen In- genieursdisziplin. Wer die individuelle Leistungsfähigkeit einzelner Mitarbeiter hier schlicht ignoriert, bewegt sich auf sehr dünnem Eis. Der Erfolg eines Unter- nehmens wird am Ende auch davon abhängen, wie gut es in der Lage ist, für die individuellen Stärken der Software-Ingenieure Freiräume zu schaffen und diese gewinnbringend für das Unternehmen zu nutzen. Die hiermit verbundenen Fra- gestellungen werden durch die vorgestellten Reifegradmodelle nur unvollständig beantwortet.\n■ Ist Innovation planbar? Die Frage, ob sich Innovation planen lässt, wird von verschiedenen Experten un- terschiedlich beantwortet. Verfechter schwergewichtiger Prozessmodelle beant- worten die Frage nicht selten mit einem deutlichen Ja. Einige Unternehmen ma- chen diese Sichtweise durch die Implementierung spezieller Innovationsprozesse klar nach außen sichtbar. Ein solcher Prozess ist mit der Hoffnung verbunden, das Innovationspotenzial der Mitarbeiter systematisch nutzen zu können, indem auf- keimende Ideen kompetent evaluiert und in geordneten Bahnen weiterverfolgt werden. Andere Experten sehen in einer geregelten Prozesslandschaft die Anti- these einer innovativen Umgebung verwirklicht. Stattdessen wird die Sichtweise verfolgt, dass sich Innovation und Kreativität der Mitarbeiter ganz von selbst entfalten – wenn man sie nur lässt. Um entsprechende Freiräume zu schaffen, fordern einige Unternehmen ihre Mitarbeiter explizit auf, einen bestimmten Teil der Arbeitszeit auf eigene Projekte zu verwenden. Zu diesen Unternehmen ge- hört unter anderem der Suchmaschinenbetreiber Google, der dieses Prinzip als festen Bestandteil seiner Firmenkultur postuliert:\n“We work in small teams, which we believe promotes spontaneity, creati- vity and speed. Any Googler might have our next great idea, so we make sure every idea is heard. Because great ideas need resources to grow into reality, at Google you’ll always get the resources you need to make your dreams a reality. Google engineers all have “20 percent time” in which they’re free to pursue projects they’re passionate about. This freedom has already produced Google News, Google Suggest, AdSense for Content, and Orkut – products which might otherwise have taken an entire start-up to launch.”\nThe engineer’s life at Google \nGoogle selbst sieht in der 20-Prozent-Regel einen maßgeblichen Faktor für die Innovationskraft des Unternehmens:\n“Virtually everything new seems to come from the 20 percent of their time engineers here are expected to spend on side projects.”\nEric Schmidt, CEO, Google Inc. \nUm Missverständnissen an dieser Stelle vorzubeugen: Die Schaffung entspre- chender Freiräume wird durch keines der vorgestellten Reifegradmodelle unter- bunden. Nichtsdestotrotz ist in Organisationen höherer „Reife“ das Prozessden- ken so tief verwurzelt, dass die Etablierung eines genauso schwergewichtigen wie formalen Innovationsprozesses nahezu reﬂexartig als der Königsweg er- scheint.\n■ Wird Software entwickelt oder produziert? Die Frage, ob es sich bei der Erstellung von Software um einen künstlerischen Akt oder schlicht um einen herstellenden Vorgang handelt, wird seit jeher kontro- vers diskutiert. Die meisten Verfechter schwergewichtiger Prozesse sehen in der\nErstellung von Software einen herstellenden Vorgang und nicht selten wird die Entwicklung in diesen Unternehmen auch als Software-Produktion bezeichnet. Auf den ersten Blick scheint die Frage rein philosophischer Natur und von gerin- ger praktischer Relevanz zu sein. Auf den zweiten Blick wird deutlich, dass die unterschiedlichen Sichtweisen weitreichende Auswirkungen auf den gesamten Software-Entwicklungsprozess besitzen. So basiert das gesamte Fundament der Reifegradmodelle auf einer produktionstechnischen Sichtweise – insbesondere Zielparameter wie die Planbarkeit und Wiederholbarkeit sind mit einer künstle- rischen Tätigkeit nur bedingt vereinbar. Aber lässt sich qualitativ hochwertige Software tatsächlich „produzieren“ oder werden in Wirklichkeit Prozesse benötigt, die den Bereich der Software- Entwicklung als eine Art künstlerisches Schaffen begreifen? Die folgende Um- schreibung der Programmierertätigkeit stammt aus dem Buchklassiker The My- thical Man Month von Frederick Brooks und wirft erste Zweifel an einer rein produktionsorientierten Sicht auf:\n“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so ﬂexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.”\nAuch ein Blick in die Open-Source-Szene verstärkt die Skepsis, ob eine ausschließlich produktionsorientierte Sichtweise dem Bereich der Software- Entwicklung voll und ganz gerecht wird. Projekte wie das freie Betriebssystem Linux, die zahlreichen Werkzeuge der GNU Foundation oder der freie Web- Browser Firefox sind eindrucksvolle Beispiele qualitativ hochwertiger Software- Produkte. Nahezu alle der beteiligten Entwickler erkennen künstlerische Ele- mente in dieser Tätigkeit und ziehen einen großen Teil ihrer Motivation und damit auch ihres Qualitätsbestrebens aus der Möglichkeit des kreativen Schaf- fens. Die Implikationen, die eine Anerkennung der künstlerischen Aspekte der Software-Entwicklung nach sich ziehen, werden durch die gängigen Reifegrad- modelle heute nicht aufgefangen. Zu wünschen wären an dieser Stelle Prozesse, die beide Sichtweisen in sich vereinen und eine ausgewogene Gratwanderung zwischen kreativer Freiheit und organisatorischer Kontrolle ermöglichen.\nDokumente ähnlich wie Managementprozesse.pdf\nMehr von Holz