The Capability Maturity Model. Das Modell der Reifegrade.

Größe: px
Ab Seite anzeigen:

Download "The Capability Maturity Model. Das Modell der Reifegrade."

Transkript

1 The Capability Maturity Model. Das Modell der Reifegrade. Seminar Informatik. Shavrov Anton

2 Inhaltsverzeichnis. 1. Einführung in Capability Moturity Model(CMM) Geschichtliche Entwicklung Capability Maturity Model Integration (CMMI) ist ein Nachfolgermodel Andere Prozessbeurteilungsverfahren Unreife vs. reife Software-Organisationen Grundlegende Begriffe des Reife-Prozesses Grundgerüst des Capability Maturity Models Grundebene (Initial Level) Ebene der Wiederholbarkeit (Repeatable Level) Definierte Ebene (Defined Level) Lenkbare Ebene (Managed Level) Ebene der Optimierung (Optimizing Level) Interne Struktur des Capability Maturity Models Praktische Anwendung - C3 Project Chrysler Extreme Programmierung Statistik der Bewertung internationaler Unternehmen durch CMM(I) Zusammenfassung Quellen

3 1. Einführung in Capability Moturity Model(CMM). Fast alle Organisationen haben ein Problem in einer festgelegten Zeit, mit einem begrenzten Budget und der Einhaltung von bestimmten Qualitätsanforderungen eine Software zu entwickeln. Die Problematik wurde sehr ernst genommen nach der Durchführung einer Reihe von Statistiken und dem Scheitern der großen Projekte im Militärbereich inden USA. Ein nicht publizierter Review des Verteidigungsministeriums (Department of Defence) hat ergeben, dass siebzehn bedeutende Projekte im Verzug waren. Ein vier jähriges Projekt wurde nicht nach sieben Jahren abgeliefert. Der Einsatz von B1 Bombenflugzeugn wurde wegen des Softwareproblems verlegt. 1 Das Problem war auch in der Industrie bekannt. In den USA steigen die Ausgaben für Software jedes Jahr ca. um 12%. Außerdem wächst immer mehr das Verlangen nach neuen Funktionen und Anwendungen. Die Situation lässt sich durch die Aussage eines Senior Manager beschreiben : I'd rather have it wrong than have it late. We can always fix it later. Für die Auftraggeber führt dies dazu, dass sie Software nicht wie bestellt bekommen und dadurch typischerweise Zusatzkosten haben, sei es, weil die Entwicklung als solche teurer geworden ist oder weil der von der neuen Software erwartete Nutzen nicht oder zumindest erst später realisiert werden kann. Der Auftragnehmer hat im günstigsten Fall, wenn z.b. die Strafe nicht vertraglich festgelegt ist, nur den Imageschaden. Das allein kann schon für ein Unternehmen schlechte Folge haben. Für die Lösung dieses Problems hat das amerikanische Verteidigungsministerium die Gründung eines Software Engineering Institutes (SEI) veranlasst. Die Aufgabe des Institutes war die Software-Praktiken in der amerikanischen Industrie zu verbessern. Das musste auch die Möglichkeit dem Ministerium geben, seine eigenen Auftragnehmer zu bewerten, damit man sicher sein kann, dass die Software, wie versprochen, geliefert werden kann. Demgemäß ist ein Capability Maturity Model (CMM) entstanden. Die Hauptrichtlinie bei CMM ist die Bereitstellung der Methoden zur Bewertung der Fähigkeiten der respektiven Reife einer Softwareorganisation und die Bestimmung der Maßnahmen zur ihrer Verbesserung. Dabei geht man davon aus, dass die Qualität eines Softwareproduktes von der Qualität der Entwicklungsprozesse abhängt, mit denen es hergestellt wird. Das Bewertungsverfahren durch einen Fragebogen wird als Assessment bezeichnet. Dieser Fragebogen kann auf den in CMM festgelegten Fragen zur Bestimmung der Ebene der Organisation basieren. Eine Ebene wird durch die 18 Hauptkriterien, Schlüsselbereichen (Key Process Areas) definiert. Ein Hauptkriterium wird durch bestimmte Aspekte oder Key Practices bezeichnet. Sie schreiben vor, was getan werden muss, um das jeweilige Hauptkriterium zu erfüllen. 1. The Capability Maturity Model:Guidlines for Improving the Software Process Addison-Wesley publishing company ISBN:

4 Es wird jedoch nicht festgelegt, wie das umgesetzt werden soll. CMM definiert also keine Prozesse sondern lediglich deren Verwendung und Nutzen. Der Fragebogen bildet das Herzstück von CMM. Anhand der Auswertung des Assessments kann der Reifegrad bzw. Ebene der Softwarefirma bestimmt werden. Erreichen einer Ebene liefert ein Kriterium für die Beurteilung der Kompetenz einer Organisation. 1.1 Geschichtliche Entwicklung startete auf Initiative des US-Verteidigungsministeriums das Software Engineering Institute an der Carnegie Mellon University in Pittsburgh, welches dem US-Verteidigungsministerium untersteht, die Entwicklung eines Systems zur Bewertung der Reife von Softwareprozessen wurde die Software Proccess Maturity Framework freigegeben wurde das Modell als Capability Maturity Model 1.0 herausgegeben. Dabei wurde bei Assessments auf Maturity Questionnaire betont wurde es auf Grund von Rückmeldungen aus der Industrie überarbeitet und in der Version 1.1 bereitgestellt wurde CMM 2.0 kurz vor der Verabschiedung vom US- Verteidigungsministeriums zurückgezogen, stattdessen wurde das CMMI-Projekt gestartet wurde im Herbst CMMI - damals noch unter dem Namen Capability Maturity Model Integrated - als Pilotversion 1.0 herausgegeben. Anfang 2002 wurde CMMI unter dem neuen Namen Capability Maturity Model Integration (kurz CMMI) freigegeben. Ende 2003 ist die Unterstützung des SEI für die alte Version CMM ausgelaufen. Jetzt wird nur noch CMMI unterstützt wurde die CMMI-Version 1.2 für Herbst 2006 angekündigt. Die Unterstützung des SEI für CMMI Version 1.1 soll danach noch bis Ende 2007 weiterlaufen. Ende 2005 laufen die Lizenzen der Assessmentleiter für CMM aus, d. h. es gibt keine offiziellen CMM-Assessments mehr. Am 25. August 2006 ist die neue Version 1.2 des CMMI veröffentlicht worden. Mit dem neuen Release sind einige grundlegende Veränderungen einhergegangen. So wurde u. A. die neue Version auf CMMI-DEV umbenannt Capability Maturity Model Integration (CMMI) ist ein Nachfolgermodel. Seit August 2006 ersetzt CMMI die ältere Version des Software Capability Maturity Models. Es wurde ebenso am Software Engineering Institute der Carnegie Mellon University in Pittsburgh im Auftrag des amerikanischen Verteidigungsministeriums entwickelt. Im neuenmodel wird einen größeren Wert auf Modularität gesetzt. Dieses modulare Konzept bewirkt

5 die Integration weiterer Entwicklungsdisziplinen. CMMI sammelt alle aus dem CMM gewonnen Erfahrungen und Verbesserungen. Das Nachfolgemodel verfügt über die einheitlichere Struktur und kann in anderen Bereichen außer der Softwareentwicklung verwendet werden. Außerdem hat das neue Model zwei Arten der Darstellung: eine stufenförmige (Staged Representation) mit ebenfalls fünf Stufen und eine kontinuierliche (Continuous Representation). Die kontinuierliche Art stellt die Reife einer Organisation detaillierter dar. Dabei wird pro Prozessgebiet, einen so genannten Fähigkeitsgrad auf einer Skala von 0 bis 5, gegeben. Darüber hinaus gibt es neben der Unterscheidung zwischen zwei Arten der Darstellung mehrere unterschiedliche Varianten, die eine Abhängigkeit von einem Anwendungsbereich aufweisen. Neuerungen in CMMI gegenüber CMM. Neue Schlüsselbereiche (Key Process Areas). - fasst über Schlüsselbereiche verteilte Anforderungen an einer Stelle zusammen. Umbenennung. - Software Projekt Planning in Project Planning. - Software Projekt Tracking und Oversight in Projekt Monitoring and Control - Software Subcontract Management in Supplier Agreement Management - Software Quality Assurance in Process and Product Quality Assurance - Software Configuration Management in Configuration Manamement. Neue Prozessgebiete. - Anforderungsentwicklung - Technische Umsetzung - Produktintegration - Verifikation - Validation - Integriertes Projektmanagement - Risikomanagement - Entscheidungsanalyse und Entscheidungsfindung Folgende Prozessgebiete fallen weg. - Integrated Softwaremanagement - Software Produkt Engineering entfällt ganz als eigenes Prozessgebiet, Inhalte sind jetzt auf mehreren Prozessgebieten verteilt. - Intergroup Coordination - Partnerreviews ist jetzt Teil von Verifikation geworden. Keine wesentlichen Änderungen. - Organisationsweiter Prozessfokus - Organisationsweite Prozessdefinition - Training Programm ist organisationsweites Training - 5 -

6 3. Andere Prozessbeurteilungsverfahren. Es existiert eine Reihe der anderen Prozessbeurteilungsverfahren beziehungsweise Modele für das Qualitätsmanagement, die dem CMM verwandt sind. Eine kurze Übersicht über einige Modele wird im folgenden Abschnitt der Arbeit dargestellt. ISO Dieses Model ist sehr verbreitet und bekannt in Europa. Es stammt aus der Fertigungsindustrie und im Vergleich mit CMM viel allgemeiner formuliert. Die Allgemeinheit ermöglicht den Einsatz des Verfahrens fast in allen Branchen von Schraubenproduktion bis zur Softwareentwicklung. Andererseits bietet es im Bezug auf konkretes Problem weniger anwendbare Hilfsmittel als CMM auf Grund der Abstraktion an. Es gibt allerdings die Richtlinie ISO 90003:2004 und ISO 9001:2000 für die Anwendung im Bereich Software- und Systementwicklung. Ein Vorteil des dargestellten Model ist es, dass es alle wesentlichen Geschäftsprozesse abdeckt. Bootstrap. Das Verfahren wurde von vieleneuropäischen Organisationen im Auftrag der EU bereitgestellt. Das Model sollte mehr als CMM an die europäischen Anforderungen angepasst werden und mehr zur Konjunktur passen. Bootstrap verwendet eine kontinuierliche Darstellung. Dies kann mit einer Variante im CMMI verglichen werden. Momentan ist das Verfahren von ISO 15504abgelöst. ISO (SPICE). Diese ISO-Norm ist sehr unter dem Namen SPICE verbreitet. Das Akronym SPICE steht für Software Process Improvement and Capability determination. Das Verfahren definiert einen Rahmen für Reihfegrademodelle und zugehörige Bewertungsmethoden. Bei der Entwicklung von CMMI war die Zielsetzung mit SPICE kompatibel und konsistent zu bleiben. European Foundation for Quality Management (EFQM) Das Geschäftsfähigkeitsmodel der EFQM ist ein Modell für ein komplettes Qualitätsmanagement - Total Quality Management. Es ist die Grundlage für den jährlich zu vergebenen Europäischen Qualitätspreis. Das Model besteht aus zwei Teilen, eine Hälfte ist Befähiger, die Qualität ermöglichen und der andere Teil sind die Ergebnisse der Befähiger. Zu den Befähigern gehört die Nutzung definierter und kontinuierlich verbesserter Prozesse. Im Bezug auf CMMI kann man sagen, dass es diesen Bereich zum großen Teil abdeckt, währen die anderen Komponenten in CMMI fast nicht ausgearbeitet werden. Eine weitere Abbildung 1 stellt die Struktur des EFQM-Models dar. Abbildung 1-6 -

7 4. Unreife vs. reife Software-Organisationen. Um es nachvollziehen zu können, welche Verbesserungsmaßnahmen für ein Unternehmen wirklich erforderlich sind, stellt CMM in der ersten Linie einen Unterschied zwischen einer reifen und einer unreifen Organisation vor. Bei einem unreifen Unternehmen wird der Softwareprozess generell im Laufe des ganzen Projektes improvisiert. Selbst wenn der Softwareprozess spezifiziert ist, werden die festgelegten Richtlinien nicht eingehalten. Die unreifen Organisationen sind in der Regel rückschrittlich und ihre Manager sind nur auf die Überwindung der sofortigen Krisen fokussiert. Solche Unternehmen überschreiten oft auf Grund fehlender Basis für die objektive Bestimmung eigener Produktivität Ihren Fristablauf. In äußerst kritischen Fällen, kann für die Einhaltung der Termine, ein bestimmter Teil der Funktionalität bzw. Qualität geopfert werden. Die unreifen Organisationen haben also keine objektive Basis für die Bestimmung der Produktqualität und der Lösung akuter Probleme, wie auch wenig Verständnis für den Zusammenhang zwischen dem Prozess und Qualität. Die Produktqualität ist schwer vor zu bestimmen. Der Auftraggeber hat kaum Einsicht in das Produkt bis zur Abnahme. Die reifen Organisationen sind durch die gesteuerten Softwareentwicklungen und gut definierte, unternehmensweite Entwicklungsprozesse gekennzeichnet. Alle Aktivitäten werden nach einem vorgeschriebenen Plan durchgeführt. Die Planung ist hinreichend exakt und verlässlich. Die Prozessdefinitionen werden bei dem Bedarf aktualisiert und die Verbesserungen werden durch Pilot-Tests respektive Gewinn und Verlust-Analyse gewährleistet. Rollen und Verantwortung bezüglich des Prozesses sind verständlich für das ganze Projekt und die ganze Organisation. In den reifen Unternehmen überwachen Manager die Qualität des Softwareproduktes und damit verbundene Entwicklungsprozesse. Es gibt eine objektive, quantitative Basis zur Bestimmung der Produktqualität und Analyse der Probleme mit dem Produkt und Prozess. Die Erwartungen für die Kosten, Planung, Funktionalität und Qualität des Produktes werden in der Regel erfüllt. Im Allgemeinen folgen die reifen Organisationen konsistent dem disziplinierten Prozess, weil alle Teilnehmer Ihnen gestellten Aufgaben gut nachvollziehen, und die benötigte Infrastruktur vorhanden ist. 5. Grundlegende Begriffe des Reife-Prozesses. In diesem Teil der Arbeit werden die grundlegenden Begriffe vorgestellt, die eine Basis für das Verstehen der Reife eines Softwareprozesses bilden und zur Beschreibung der Reife einer Softwareorganisation dienen. CMM ist auf die Fähigkeit einer Organisation fokussiert, die hoch qualitative Softwareprodukte liefert. Die erste Frage, die beantwortet werden sollte, was ist ein Prozess? Ein Prozess ist eine Sequenz der Schritte zum Erreichen eines bestimmten Ziels. Ein Prozess nimmt die Leute, Werkzeuge und Methoden auf. Dies wird in der nächsten Abbildung 2 veranschaulicht. Ein Softwareprozess kann definiert werden als eine Menge von Aktivitäten und damit zusammenhängenden Ergebnissen, die zur Herstellung eines Softwareprodukts führen. 1 Bei den reifen Organisationen wird ein Software Prozess besser definiert und implementiert. 1. Software Engineering ISBN Auflage

8 Abbildung 2 1 Der Schwerpunkt eines Softwareprozesses legt CMM auf die Befähigung der Leute ihre Arbeit zu leisten. Ein effektiver Softwareprozess bindet die Leute, Werkzeuge und Methoden in eine integrierte Einheit zusammen. Software Process Capability beschreibt eine Reihe der erwarteten Ergebnisse, die bei der Ausführung des Software-Prozesses erreicht werden können. Software Process Capability einer Organisation sorgt dafür, dass es auch für das nächste Projekt die Ergebnisse sowie die Qualität vorhersagbar sein werden. Softwareprozess Performanz stellt die aktuellen Ergebnisse eines Softwareprozesses dar. Dabei wird auf erreichte Resultate fokussiert, währen Software Process Capability sich für die Erwartungen interessiert. Softwareprozess Reife ist ein Maß für die Bezeichnung eines bestimmten Prozesses, der explizit definiert, gesteuert, gemessen, kontrolliert und effizient ist. Die Reife bedeutet ein Potential für das Wachstum der Fähigkeiten und zeigt den Reichtum eines Prozesses einer Organisation an. Außerdem wird es die Konsistenz eines Prozesses für die Projekte innerhalb des Unternehmens aufgedeckt. Infrastruktur ist das grundlegende Gerippe einer Organisation oder Systems. Darin werden die Struktur, Methoden, Standard, Training, Einrichtungen und Werkzeuge eingeschlossen, um die Performanz des Unternehmens zu unterstützen. Institutionalisierung ist die Bildung einer Infrastruktur und Kultur, um die Methoden, Praktiken und Prozeduren zu unterstützen. Das Ergebnis von Institutionalisierung ist die organisationsweite Aufstellung eines effektiven, konsistenten Softwareprozesses. 1. The Software Engineering Institute. CMMI Product Team CMMI for Development, Version

9 6. Grundgerüst des Capability Maturity Models. Die Grundlage eines kontinuierlichen Verbesserungsprozesses ist ehe eine Anzahl von kleinen evolutionären Schritten als eine revolutionäre Innovation. Die Schritte werden in CMM durch fünf Reifenebenen oder -stufen repräsentiert. Diese fünf Stufen definieren eine Scala für die Messung des Reifengrades des Softwareprozesses der Organisation und die Erhöhung der Qualität des Prozesses selbst. Die Reifeebenen stellen eine gut definierte Evolutionsgrundlage für das Erreichen der Reife eines Softwareprozesses dar. Jede Ebene schließt eine Anzahl der Ziele ein, bei deren Erreichen man eine wichtige Komponente des Softwareprozesses stabilisiert. Die fünf Reifeebenen sind in der Abbildung 3 dargestellt. 6.1 Grundebene (Initial Level). Abbildung 3 Auf dieser Ebene gibt es keinen definierten Softwareprozess und keine stabile Umgebung für die Entwicklung. Bei dem Eintreffen von Krisen werden alle geplanten Vorgehensweisen weggelassen und durch Kodieren und Testen(Code&Fix) ersetzt. Im Laufe der Entwicklung werden ständige Änderungen und Modifizierungen vorgenommen. Aus diesem Grund ist die gute Produktion nur von dem gut qualifiziertem Personal und ihrem großem Einsatz abhängig. Man kann auch nicht vorhersagen, mit welcher Qualität und zu welchem Zeitpunkt das Produkt fertig gestellt wird. Das Budget wird meistens überschritten. Durch den Einsatz der guten Manager kann der Prozess zwar gekräftigt werden, hängt aber völlig von dem Personal ab. Die Fähigkeiten der Organisation der Ebene 1 sind personen- und nicht organisationsbezogen. 6.2 Ebene der Wiederholbarkeit (Repeatable Level). Die Ebene zwei kann durch Maßnahmen einer geordneten Steuerung und Verfolgung charakterisiert werden. Das bedeutet, dass der Prozess auf dieser Ebene schon definiert ist. Die Ablaufplanung ist auf der positiven Erfahrung aus den früheren und ähnlichen Projekten aufgebaut. Das erlaubt eine grobe Abschätzung der Projekte aus der Analogie. Prozessfähigkeit wird durch das disziplinierte Management deutlich verbessert. Die Manager verfolgen die Kosten der Software, Ablaufplanung und Funktionalität. Darüber hinaus wird eine einfache Kontrolle eingeführt. Dies führt zu einer gewissen Vorhersagbarkeit und Verbesserung des Prozesses, obwohl man noch bemerken muss, dass die Prozessqualität auf dieser Stufe noch nicht genügend ist

10 6.3 Definierte Ebene (Defined Level). Auf der dritten Ebene sind alle Entwicklungs- und Managementprozesse vollständig definiert, dokumentiert und unternehmensweit eingeführt. Die Integration des Softare-Engineerings und Managementprozesses in ein Ganzes, bildet ein Standard-Softwareprozess der Organisation. Die Organisation verwendet effektiv die Methoden aus dem Bereich Software Engineering während der Standardisierung der Softwareprozesse. Diese Stufe wird auch durch die Bildung einer Gruppe(Software Engineering Process Group) bezeichnet, die für die Prozessaktivitäten beziehungsweise für die Umsetzung verantwortlich ist. Die Definition der Prozesse soll es den Verantwortlichen ermöglichen Ihre Arbeit effizent zu leisten, ohne dabei die Prozesse hemmend und unflexibel werden zu lassen. Ein definierter Prozess folgt einer Reihe der vorgeschriebenen Techniken zur Durchführung und Verwaltung der Arbeit. Dabei existieren Eingans- bzw. Ausgangskriterien, die Maßnahmen zur Sicherstellung der Qualitätund die Methoden für die Steigerung der Performanz der Arbeit. Außerdem werden für die Erhöhung der Qualität der Arbeit und somit des Prozesses die Trainingprogramme für den Entwicklung- bzw. Verwaltungspersonal eingeführt. Die Prozessfähigkeiten der Ebene 3 kann man als konsistent charakterisieren. Ferner werden die Produktrichtlinie, Kosten, Planung, Funktionalität und Softwarequalität kontrolliert und verfolgt. Die Organisation der dritten Ebene hat einen Überblick und Kontrolle über die geführten Aktivitäten. Aber die Qualität des Softwareprozesses ist immer noch Schwankungen ausgesetzt. Lenkbare Ebene (Managed Level). Die vierte Ebene ist durch die Formulierung und Überwachung der quantitativen Ziele für das Softwareprodukt gekennzeichnet. Die Produktivität und Qualität werden als die wichtigen Aktivitäten des Softwareprozesses gemessen, um zahlreiche Aspekte des Prozesses zu erfassen. Die Messungen werden in einer organisationsweiten Datenbank abgelegt, um die Basis für die Analyse und Prozessverbesserungen zu ermitteln. Die Projekte erreichen die Kontrolle über Ihre Produkte und Prozesse bei kleiner Schwankung der Leistung. Die Prozessfähigkeiten der Ebene sind vorhersagbar. Die Organisationen dieser Stufe können die Prozessgüte einschätzen, aber sie verfügen über kein Wissen, wie ihre Prozesse verbessert werden können. 6.5 Ebene der Optimierung (Optimizing Level). Auf der Ebene 5 wird die ganze Organisation auf kontinuierliche Verbesserung des eigenen Prozesses ausgerichtet. Ein Unternehmen ist in der Lage die Schwächen zu erkennen und vorbeugende Maßnehmen zu treffen. Die gesammelten Messdaten werden für die Gewinnund Verlust-Rechnung gebraucht, um den Einsatz der neuen Technologien oder Änderungen an dem Produkte beurteilen zu können. Die festgestellten Verbesserungsmöglichkeiten werden organisationsweit eingeführt. Softwareteams der Ebene 5 untersuchen die Fehler, um Ihre Ursachen zu identifizieren. Auf dieser Grundlage werden die Vorgehensweise so geändert, dass man die Ursachen der Fehler möglichst ausschließt. Die Prozessfähigkeiten der Ebene 5 kann man als selbstverbessernd bezeichnen

11 7. Interne Struktur des Capability Maturity Models. Im folgenden Abschnitt der Arbeit wird ein Überblick über die ganze Struktur des CMMs gegeben. Wie schon bereits erwähnt wurde, bilden die Reifeebenen ein Grundgerüst des Models. Jede Reifestufe wird auf weitere Elemente geteilt. Ausschließlich der Ebene 1(siehe Abbildung 4), enthalten alle Stufen eine Reihe der Komponenten der abstrakten Aufstellungen bis hin zu den Aktivitäten in den Schlüsselpraktiken. Reifeebenen(Maturity Leveles) Abbildung 4 Eine Reifeebene ist eine gut definierte Grundlage für das Erreichen eines reifen Softwareprozesses. Jede Reifestufe zeigt das Niveau der Prozessfähigkeit, wobei Prozessfähigkeit eine Reihe von erwarteten Ergebnissen beschreibt, die bei dem Folgen dem Softwareprozess bereit gestellt werden können. Prozessfähigkeit einer Organisation dient zur Prognose der Erfolge für die erwartenden Softwareprodukte. Schlüsselbereiche(Key Process Areas). Bis auf die Ebene 1 sind alle Reifestufen auf einige Schlüsselbereiche zerlegt. Ein solcher Bereich zeigt einen Mittelpunkt für die Verbesserung des Softwareprozesses an, d.h. es werden Ergebnisse für das Erreichen bestimmter Ebene festgelegt. Jeder Schlüsselbereich legt eine Menge der Aktivitäten fest, deren vollständige Ausführung bei der wichtigen Verbesserung und Erreichung der Prozessziele hilft. Die Schlüsselbereiche aufeinander folgender Stufen bauen aufeinander auf. Die Art und Weise für die Erfüllung der Ziele ist nicht definiert und hängen von dem Projekt und seiner Umgebung ab. Die Ziele eines Schlüsselbereiches fassen seine Praktiken zusammen und können verwendet werden, um nach zu weisen, ob eine Organisation oder ein Projekt effizient den

12 Schlüsselbereich implementiert hat. Die Ziele bezeichnen den Umfang und den Rahmen eines Bereiches. Relevante Aspekte (Common Features). Die Praktiken jedes Schlüsselbereichs sind zwecks besserer Bequemlichkeit in relevante Aspekte organisiert, die eine Reihe von Attributen enthalten, mit deren Hilfe man verfolgen kann, ob die Implementierung und Institutionalisierung eines Schlüsselbereiches effizient, wiederholbar und nachhaltig ist. Man unterscheidet zwischen fünf relevante Aspekte: Commitment to Perform : es werden Aktivitäten beschrieben, die umgesetzt werden sollten, um sicher zu stellen, dass der Prozess aufgestellt ist. Ability to Perform: es werden Vorbedingungen beschrieben, die notwendig sind, um den Prozess mit Kompetenz zu verbessern. Activities Performes: es werden die Rollen und Vorgänge beschrieben, um einen Schlüsselbereich zu entwickeln. Measurement and Analysis: es werden die Bedürfnisse beschrieben, um den Prozess zu messen und Aufmass zu analisieren. Verifying Implementation: es werden notwendige Schritte beschrieben, um sich zu vergewissern, dass die Aktivitäten im Einvernehmen mit dem Prozess ausgeführt werden. Schlüsselpraktiken (Key Practices). Jeder Schlüsselbereich wird durch eine Anzahl der Schlüsselpraktiken festgelegt. Eine Schlüsselpraktik beschreibt die Aktivitäten und Infrastruktur, mit deren Hilfe man in der Lage ist, wirksam einen Schlüsselbereich zu implementieren und institutionalisieren. Ein Schlüsselbereich stellt nur allgemeine Maßnahmen dar. Er schreibt aber nicht vor, wie man das umsetzen sollte und welche Werkzeuge oder Techniken man beispielsweise einsetzen muss. Jeder Schlüsselbereich schließt nur einen einzigen Satz ein, der oft von einer detaillierten Beschreibung gefolgt wird, die Beispiele und die Ausarbeitungen enthalten kann. 8. Praktische Anwendung - C3 Project Chrysler Extreme Programmierung. In diesem Abschnitt wird ein Projekt, nämlich das Chrysler C3 Projekt im Bezug auf Capability Maturity Model dargestellt. Ein Merkmal dieses Projektes ist, dass es auf dem Exterme Programming(XP) beruht. Das kann etwas verwirrend sein, weil es Meinungen gibt, dass die Extreme Programmierung nicht über Ebene 1 des CMMs hinaus geht. Das liegt an der fehlenden Organisation, Dokumentation und nicht genügender Kontrolle über das Projekt. Des Weiteren werden verschiedene Gemeinsamkeiten der Extreme Programmierung mit CMM betrachten, die auf höhere Ebenen abgebildet werden

13 Ebene 1 - Grundebene. Eigenschaften: - keine stabile Umgebung für die Entwicklung. - oft vorhandene Überforderung - im Krisenfall Verzicht auf die Anforderungen - Abhängigkeit des Erfolgs nur vom Personalkompetenz Extreme Programmierung ist in zwei Ebenen der Terminplanung angeordnet, die den Ablaufplan bestimmen. Diese Ebenen heißen Commitment Schedule and Iteration Plan und sind auf der Einschätzung des Entwickler und seiner Erfahrung basiert. Das Resultat des Commitment-Schedule-Prozesses ist eine umfangreiche Bestimmung des zu entwickelnden Produktes und der Frist. Der Iteration Plan ist die Ruckkopplung an Commitmen Schedule, die in kurzen Intervallen stattfindet und die Verfeinerung des Ablaufplans zum Ziel hat. Der Fortschritt von C3 lässt sich auf keinen Fall als kritisch charakterisieren. Das C3-Team verweigert explizit den großen, heroischen Einsatz und arbeitet fast ohne Überstunden. Eine Neigung zur heroischen Taten ist ein Anzeichen für die bestehenden Probleme. In diesem Fall wird die Situation analysiert und der Entwicklungsprozess korrigiert. Die Mitglieder des C3-Teams sind kompetent aber nicht außergewöhnlich. Zur Steigerung der Effizienz wird das Pair-Programming verwendet. Bei diesem Verfahren werden zwei Leute eingesetzt, eine Person, die das bessere Verständnis über den aktuellen Zustand des Ablaufs hat, schreibt den Code, die Andere überwacht den Prozess und den entwickelnde ntrend, dabei korrigiert sie die aufgetretenen Fehler. Der Teammanager bietet keine außergewöhnliche Unterstützung. Der Teammanager dient nur zum Zweck der Verfolgung des Fortschrittes und als Schnittstelle zu Management. Ebene 2 Wiederholbarkeit. Eigenschaften: - effektive Prozessimplementierung auf Grund der vorhandenen Definitionen, Dokumenten, gesammelten Erfahrungen, der Übungen, Messungen und der Möglichkeit zur Verbesserung. Extreme Programmierung offensichtlich spezifiziert eine Menge von Praktiken (Extreme Programming Rules). Diese Regeln sind gut definiert und dokumentiert. Das Team wurde zum Anfang des Projekts gut vorbereitet, hatte Vollzeit-Coaching und übte die Methoden und Vorgehensweise des Teams. Pair Programming und ein offener Prozess gewährleistet allen Entwicklern zu wissen, in welchem Stand sich das Projekt befindet. In seltenen Fällen konnten Entwickler, die die Teampraktiken nicht einhalten, gemahnt oder aus dem Projekt ausgeschlossen werden. Die Praktiken können angereichert werden und sie werden ständig verbessert

14 Weitere Eigenschaften: - Managers des Projekts verfolgen den Aufwand, die Termineinhaltung und Funktionalität - Identifizierung der Probleme bei der Entstehung. In Extreme Programmierung werden vier Komponenten verfolgt, nämlich die Ressourcen, den Rahmen, die Qualität und Zeit. Diese Komponente erlauben fest zu stellen, ob der Terminplan mit entsprechender Qualität erreicht werden kann. Die Information über diese Komponenten werden im Laufe des Projektes regelmäßig dem höheren Management bereitgestellt. Definierte Ebene. Eigenschaften: - Software Engineering-, Managementprozesse sind die Beistandteile des Softwareprozesses. - Prozesscharakteristik mithilfe der Bereitschaftskriterien, den Verifikationsmechanismus, den Outputs, den Inputs, dem Endfertigungskriterium - Leichte Einsicht in technischen Fortschritt. Extreme Programmierung Methoden umfassen die Bereitschaftskriterien Inputs (Benutzer- Geschichte), Standarten und Prozeduren (zahlreiche Extreme Programming Rules ), Verifikationsmechanismus (Unit-Test und Systemtest), Output (Software)und Endfertigungskriterium (Abnahme durch einen Benutzer) Verwendung von vier Komponenten: die Ressourcen, den Rahmen, die Qualität und Zeit ermöglichen dem Management einfache und verständliche Einsicht in die aktuelle Projektperformanz. Lenkbare Ebene. Eigenschaften: - quantitativ qualitative Ziele sowohl für das Softwareprodukt als auch für den Softwareprozess. Für die Extreme Programmierung werden die qualitativen Ziele für das Produkt durch Systemtest nachgeprüft. Außerdem ist es erforderlich, dass das Unit-Test ständig 100% erfüllt hat. Der Auslastungsfaktor wird durch das Verhältnis der vergangenen Zeit zu dem vom Entwickler abgeschätzten Schwierigkeit bestimmt. Der Faktor wird nicht als quantitatives Ziel gesetzt, sondern es erlaubt die Durchführung und Bewertung der Veränderung, die zur Verbesserung des Prozesses führen. Wenn der Terminplan eingehalten ist und die Ergebnisse des Tests positiv sind, werden keine anderen quantitativen Werte untersucht. Einige Kandidaten für die Bewertung könnten zum Beispiel eine bestimmte Anzahl von Unit-Tests bzw. Systemklassen sein. Bei der Betrachtung auf Extreme Programmierung im Zusammenhang mit CMM, besonders wenn XP innerhalb des ganzen Unternehmens eingesetzt wird, könnte man vermuten, dass

15 etwas mehr Messungen bzw. Auswertungen durchgeführt werden müssen als im Rahmen dieses einzelnen Projektes nötig war. Eine interessante Frage unter diesen Umständen ist es, wie viel ist in diese Messungen zu investieren? Eine Empfehlung seitens Extreme Programming wären nur die Werte zu analisieren, bei deren Messung niedrige Kosten entstehen und sich nur dann damit beschäftigen, wenn das wirklich notwendig ist. Ein anderer Ratschlag ist Messungen zu protokollieren, wenn das nicht teuer ist, aber sie nur bei Bedarf aus zu werten. Ansonsten werden die Ressourcen umsonst aufgewendet, die für die weitere Entwicklung eingesetzt werden könnten. Ebene der Optimierung. Eigenschaften: - Fehleranalyse - Verbesserung des Softwareprozesses zwecks der Vermeidung von Fehlern. - Verbreitung der gesammelten Erfahrung innerhalb der Organisation. In einer der Phasen der Extreme Programmierung findet ein Implementierungstest statt. Dabei werden bestimmte Fehler aufgedeckt, die anschießend korrigiert werden müssen, um die Tests zu bestehen. Die Erfahrung aus den erfolgreichen Testfällen wird ferner auf die gleichartigen Anwendungsgebiete übertragen Statistik der Bewertung internationaler Unternehmen durch CMM(I). In diesem Kapitel wird eine Übersicht über den Stand der Reifegrade beziehungsweise Adaptation von CMM(I) verschiedener Organisationen respektive Unternehmen weltweit vermittelt. Die Reifegrade werden durch von dem Software Engineering Institute bereitgestellten Bewertungsmethoden bestimmt. Die Bewertungen werden ab April 2002 innerhalb von 52 Monate, also bis Juli 2006 durchgeführt. In dieser Frist wurden 1581 Bewertungen eingereicht. Abbildung 5 veranschaulicht die Verteilung aller Organisation über die CMM(I) Stufen. Dabei fällt es auf, dass die meisten Unternehmen sich auf den Ebenen zwei und drei positionieren und dabei die Stufen Managed und Defined erreicht haben. 1. Ron Jeffries 01/01/

16 Abbildung 5 1 Die Abbildung 6 zeigt die Statistik über die Verteilung der Branchen, aus denen die bewerteten Organisationen stammen. Es wird zwischen kommerziellen Softwarehäusern, die Auftragnehmer für Militär bzw. Regierung und Militär- bzw. Regierungsbehörden unterschieden. Es lässt sich feststellen, dass die kommerzielle Organisation einen überwiegenden Anteil mit einem Wert von 67,6% aufweisen. Abbildung 6 1 Die nächste Abbildung 7 stellt eine Liste mit allen beteiligten Ländern dar. Daraus kann man entnehmen, wie viele Organisationen eines bestimmten Landes einer CMMI Bewertung unterzogen wurden. 1.Software Engineering Institut Appraisal Results September

17 Der höchste Wert hat die USA mit 598 Bewertungen. Danach kommen Indien, China und Japan mit den Werten 177,158 und 155. Und nur 28 Organisation aus Deutschland haben an der Bewertung teilgenommen. Abbildung 7 Aus den oben vorgeführten Statistiken, lässt sich die Folgerung ziehen, dass das CMMI überwiegend in kommerziellen Organisationen verwendet wird. Die daran beteiligten Organisationen sind meistens relativ ausgereift und haben bereit die Stufen Managed und Defined erreicht. In Deutschland bzw. in Europa hat sich das Verfahren nicht durchgesetzt und es wird in großer Anzahl nur lokal in den USA benutzt. 10. Zusammenfassung. Dieser letzte Teil der Arbeit schließt das Thema Capability Maturity Model ab und stellt die Schlussfolgerung dar. Das oben beschriebene Model stellt eine Reihe von Methoden, Techniken und Vorgehensweisen bereit, die es ermöglichen den Reifegrad einer Organisation bzw. der Softwareprozesse dieser Organisation zu bewerten. Der Reifegrad wird in fünf Ebenen eingeteilt. Jede Reifeebene definiert die Maßnahmen, die zur Prozessverbesserung führen, d.h. erlauben einer Organisation effizienter Ihre Ressourcen auf zu wenden. Das CMM war der erste systematische Ansatz zur Prozessverbesserung. Obwohl das Model zuerst für Softwareentwicklungsprojekte entwickelt wurde, kann vieles davon mit nur geringfügigen Anpassungen auch für andere Bereiche verwendet werden. Das CMM bietet eine systematische Möglichkeit zur Verbesserung der Prozessqualität und Identifizierung von Schwächen, deren Behebung besonders wirksam ist. Außerdem wird Evaluierung und damit

18 Vergleich mit anderen Organisationen erlaubt. Darüber hinaus sind einige Nebenwirkungen und Contraargumenten bekannt. Für die Prozessverbesserung sind zusätzliche Kosten zu kalkulieren. Aber im Gegensatz dazu ergeben die empirischen Untersuchungen, dass der Nutzen wesentlich höher ist als die Kosten. Die Optimierung der Prozesse ist nur für die Standardprobleme möglich. Es ist aus verschiedenen Blickwinkeln unbefriedigend und unvollständig. Die Anwendung ist teuer und langsam, daher nur für große Organisationen geeignet. Das Model ist sehr stark technikbezogen und es wurde wenig Rücksicht auf Personal genommen

19 11. Quellen. 1. The Capability Maturity Model:Guidlines for Improving the Software Process Addison-Wesley publishing company ISBN: Software Engineering ISBN Auflage Ron Jeffries 01/01/ Software Engineering Institut Appraisal Results September

Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007

Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007 Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007 2007-09-27 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD Computing Science, Univ. of Manchester 1989-1995:

Mehr

ISO 9001 und CMM im Vergleich

ISO 9001 und CMM im Vergleich ISO 9001 und CMM im Vergleich internationale Norm ISO 9001 umfasst 20 Forderungen/ Klauseln 1 Vorbereitung Audit Wie wird zertifiziert Wie erfolgt Dokumentation? Handbuch (QMH) Verfahrensanweisungen (QMV)

Mehr

CMMI - Unterschiede und Gemeinsamkeiten zu CMM. 10/16/03 CMMI - Unterschiede und Gemeinsamkeiten zu CMM

CMMI - Unterschiede und Gemeinsamkeiten zu CMM. 10/16/03 CMMI - Unterschiede und Gemeinsamkeiten zu CMM CMMI - Unterschiede und Gemeinsamkeiten zu CMM Universität Tübingen Arbeitsbereich: Informatik und Gesellschaft Thomas Grosser email: tgrosser@informatik.uni-tuebingen.de im Juli 2003 1 Gliederung Einleitung,

Mehr

CMMI und SPICE im Automotive Umfeld

CMMI und SPICE im Automotive Umfeld Vorträge 2006 CMMI und SPICE im Automotive Umfeld Inhalt Motivation Übersicht zu CMMI Anwendung in Entwicklungsprojekten Prozess Management als Lösungsansatz SPICE Motivation Jährliche Kosten für Prozessverbesserung

Mehr

CMMI Der Weg zur erfolgreichen Softwareorganisation CMMI & SPA (Siemens Process Assessment)

CMMI Der Weg zur erfolgreichen Softwareorganisation CMMI & SPA (Siemens Process Assessment) Prof. Dr. Eckhart Hanser, Hanser: BA Lörrach CMMI und & SPA eha technologie service GmbH www.ba-loe errach.de CMMI Der Weg zur erfolgreichen Softwareorganisation CMMI & SPA (Siemens Process Assessment)

Mehr

CMMI als Nachfolger des CMM. Anwendungsbereiche in CMMI v1.1. Konstellationen in CMMI v1.2. Stufenmodell. CMMI als Werkzeug zur eigenen Verbesserung

CMMI als Nachfolger des CMM. Anwendungsbereiche in CMMI v1.1. Konstellationen in CMMI v1.2. Stufenmodell. CMMI als Werkzeug zur eigenen Verbesserung 1 Bei der Entwicklung von Software oder, allgemeiner, von Systemen aus Hard- und Software hat fast jede Organisation Schwierigkeiten, in der vorgesehenen Zeit, im Budget und mit der zugesagten Qualität

Mehr

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008 Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE Heinrich Dreier Elmshorn 17.04.2008 Einleitung Softwareprozesse verbessern Einleitung Softwareprozesse verbessern SPI Software

Mehr

Informationssystemanalyse People Capability Maturity Model 6 1

Informationssystemanalyse People Capability Maturity Model 6 1 Informationssystemanalyse People Capability Maturity Model 6 1 People Capability Maturity Model Neben dem CMM, welches primär zur Verbesserung des Entwicklunsprozesses eingesetzt wird, existiert mit dem

Mehr

Informationssystemanalyse Personal Software Process 8 1

Informationssystemanalyse Personal Software Process 8 1 Informationssystemanalyse Personal Software Process 8 1 Personal Software Process Sehr eng mit dem CMM hängt der PSP (Personal Software Process) zusammen. Der PSP ergänzt das organisationsweite CMM um

Mehr

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Institut für Informatik! Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 7 Prozessqualität" 2007-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen,

Mehr

Requirements Engineering in Prozessmodellen CMMI, V-Modell XT und andere

Requirements Engineering in Prozessmodellen CMMI, V-Modell XT und andere Engineering in Prozessmodellen CMMI, V-Modell XT und andere Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 2012-03-07 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD

Mehr

Projektmanagement und das Reifegradmodell Capability

Projektmanagement und das Reifegradmodell Capability Softwareentwicklungsprozesse systematisch verbessern Projektmanagement und das Reifegradmodell Capability Maturity Model Integration (CMMI) als Qualitätsmodell tsmodell zur Prozessverbesserung Gemeinsame

Mehr

Capability Maturity Model Integration. Eine Einführung in CMMI als ein Werkzeug zur Prozessverbesserung

Capability Maturity Model Integration. Eine Einführung in CMMI als ein Werkzeug zur Prozessverbesserung Capability Maturity Model Integration Eine Einführung in CMMI als ein Werkzeug zur Prozessverbesserung Capability Maturity Model Integration Autoren Malte Foegen, Partner wibas IT Maturity Services GmbH,

Mehr

Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ)

Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ) Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ) Dr. Ralf Kneuper GI-Workshop Vorgehensmodelle 2009 2009-04-09 1 Ralf Kneuper Dipl.-Mathematiker,

Mehr

CMMI alte Ideen neu verpackt?

CMMI alte Ideen neu verpackt? CMMI alte Ideen neu verpackt? VDI Arbeitskreis zur Förderung der Qualität Stuttgart, 18. Januar 2005-1 - Autor Vector Consulting GmbH Ingersheimer Str. 24 D 70499 Stuttgart Fax +49 (711) 8 06 70-444 www.vector-consulting.de

Mehr

CMMI-ITIL Prozessverbesserung für den IT Betrieb

CMMI-ITIL Prozessverbesserung für den IT Betrieb CMMI-ITIL Prozessverbesserung für den IT Betrieb Einbindung der IT Infrastructure Library (ITIL) in die Architektur des Capability Maturity Models Integration (CMMI) CMMI-ITIL Prozessverbesserung für den

Mehr

Capability Maturity Model Integration (CMMI) aus Sicht des IT-Servicemanagements

Capability Maturity Model Integration (CMMI) aus Sicht des IT-Servicemanagements Capability Maturity Model Integration (CMMI) aus Sicht des IT-Servicemanagements Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 1 Agenda CMMI: Capability Maturity Model

Mehr

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Martin Glinz, Samuel Fricker Software-Qualität Ausgewählte Kapitel Kapitel 7 Prozessqualität 2007-2010 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

SPICE in der medizinischen Software-Entwicklung

SPICE in der medizinischen Software-Entwicklung SPICE in der medizinischen Software-Entwicklung MedConf 2012 Matthias Hölzer-Klüpfel Medical SPICE Medizinische Software Regulatorische Grundlagen Referenzmodell Medical SPICE Beispiele 1968: Software-Krise

Mehr

AUF DEM PRÜFSTAND: IST QUALITÄT NUR FREUNDLICHE ZUGABE? MIT ROUNDTABLE-DISKUSSION

AUF DEM PRÜFSTAND: IST QUALITÄT NUR FREUNDLICHE ZUGABE? MIT ROUNDTABLE-DISKUSSION MO. 26. APR. 2004, 17:00 UHR QUALITY ASSURANCE FOR IT PROJECTS SOFTWARE-ENTWICKLUNG AUF DEM PRÜFSTAND: IST QUALITÄT NUR FREUNDLICHE ZUGABE? MIT ROUNDTABLE-DISKUSSION WIRD PRÄSENTIERT VON MEDIENPARTNER

Mehr

CMMI for Embedded Systems Development

CMMI for Embedded Systems Development CMMI for Embedded Systems Development O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software Engineering Gruppe Leiter des Fachbereichs Informatik cs.uni-salzburg.at Inhalt Projekt-Kontext CMMI FIT-IT-Projekt

Mehr

TAV Arbeitskreis Testmanagement. Einführung von Testprozessen. Bedeutung von Reifegradmodellen für das Testmanagement

TAV Arbeitskreis Testmanagement. Einführung von Testprozessen. Bedeutung von Reifegradmodellen für das Testmanagement TAV Arbeitskreis Testmanagement Einführung von Testprozessen Bedeutung von Reifegradmodellen für das Testmanagement Zur Diskussion im Arbeitskreis Testmanagement auf der TAV 25 am 15./16.02.2007 Vorbereitet

Mehr

Lean Warehousing. Realisierungen in der Wirtschaft und. Prof. Dr.-Ing. Harald Augustin

Lean Warehousing. Realisierungen in der Wirtschaft und. Prof. Dr.-Ing. Harald Augustin Lean Warehousing Realisierungen in der Wirtschaft und Zukunftsszenarien Prof. Dr.-Ing. Harald Augustin LOGISTIK HEUTE Forum, CeMAT 2008, Hannover, 28. Mai 2008 Steinbeis-Transferzentrum i t Prozessmanagement

Mehr

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 1 Einführung Universität Zürich Institut für Informatik 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind für den persönlichen,

Mehr

Entwicklungs-Prozess

Entwicklungs-Prozess B e r e i c h e Software-Entwicklungs Entwicklungs-Prozess von Helmut Wolfseher (BWCE) als Partner der IndustrieHansa Kontakt Entwicklung der Kostenverhältnisse für Fehlerbeseitigung Kosten Kosten für

Mehr

Lohnt sich Requirements Engineering?

Lohnt sich Requirements Engineering? Lohnt sich Requirements Engineering? Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss Oleksandr Kazandzhi Gliederung Einleitung Messen

Mehr

SPiCE und Test: Was hat das denn miteinander zu tun?

SPiCE und Test: Was hat das denn miteinander zu tun? SPiCE und Test: Was hat das denn miteinander zu tun? TAV Düsseldorf 15./16.2.2007 Arbeitskreis Test eingebetteter Systeme Dr. Uwe Hehn Uwe.Hehn@methodpark.de Gliederung Reifegradmodelle Übersicht über

Mehr

CMMI und Verwandte ein Überblick Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung

CMMI und Verwandte ein Überblick Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung CMMI und Verwandte ein Überblick Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 2012-03-21 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD Computer Science, Univ. of

Mehr

4 Verbesserung der Prozeßqualität CMM und Spice [erheblich gekürzt]

4 Verbesserung der Prozeßqualität CMM und Spice [erheblich gekürzt] 1 Software-Qualitätssicherung 2 Einführung und Überblick LE 1 V Unternehmensmodellierung 4 Verbesserung der Prozeßqualität CMM und Spice [erheblich gekürzt] Prof. Dr. Helmut Balzert Lehrstuhl für Software-Technik

Mehr

Wissensmanagement Reifegradanalyse (Knowledge Management Maturity) Wissensprozesse bewerten und verbessern Autoren: Tobias Bläsing Marcel Ferber

Wissensmanagement Reifegradanalyse (Knowledge Management Maturity) Wissensprozesse bewerten und verbessern Autoren: Tobias Bläsing Marcel Ferber QUALITY-APPs Applikationen für das Qualitätsmanagement Wissensmanagement Reifegradanalyse (Knowledge Management Maturity) Wissensprozesse bewerten und verbessern Autoren: Tobias Bläsing Marcel Ferber Wissensmanagement

Mehr

Medical SPICE Von der Regulierung zur Praxis

Medical SPICE Von der Regulierung zur Praxis Medical SPICE Von der Regulierung zur Praxis Thomas Wunderlich, Manager, Vector Consulting Services GmbH Markus Manleitner, SW Quality Assurance Officer, Dräger medical GmbH MedConf 2013, 17.10.2013 2013.

Mehr

Werkzeug-gestützte Nachverfolgbarkeit von Anforderungen nach CMMI

Werkzeug-gestützte Nachverfolgbarkeit von Anforderungen nach CMMI IBM Software Group Werkzeug-gestützte Nachverfolgbarkeit von Anforderungen nach CMMI Hubert Biskup, IBM, IT-Specialist Ralf Kneuper, Berater und SEI-autorisierter CMMI Lead Appraiser Agenda IBM Software

Mehr

Inhaltsverzeichnis. Martin Beims. IT-Service Management mit ITIL. ITIL Edition 2011, ISO 20000:2011 und PRINCE2 in der Praxis ISBN: 978-3-446-43087-7

Inhaltsverzeichnis. Martin Beims. IT-Service Management mit ITIL. ITIL Edition 2011, ISO 20000:2011 und PRINCE2 in der Praxis ISBN: 978-3-446-43087-7 sverzeichnis Martin Beims IT-Service Management mit ITIL ITIL Edition 2011, ISO 20000:2011 und PRINCE2 in der Praxis ISBN: 978-3-446-43087-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-43087-7

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung. FHH meets economy 2008-01-17

Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung. FHH meets economy 2008-01-17 ITIL meets CMMI Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 1 Überblick Motivation Überblick CMMI CMMI und ITIL im Lebenszyklus einer Anwendung Best Practices Zusammenfassung

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Quality is our Passion!

Quality is our Passion! Quality is our Passion! Quality is our Passion! Quality is our Passion! 2 Knowledge Department ist ein Dienstleistungsunternehmen im Software-Entwicklungs-Bereich. Das Serviceangebot umfasst Trainings,

Mehr

Kapitel 11: Qualitätsmanagement- Darlegung ( Qualitätssicherung )

Kapitel 11: Qualitätsmanagement- Darlegung ( Qualitätssicherung ) Kapitel 11: Qualitätsmanagement- Darlegung ( Qualitätssicherung ) Inhalt 11.1 Audits 11.2 Publikation von Messgrößen 11.3 Qualitätsdokumentation 11.4 Zertifizierung 11.5 Software-Prozessbeurteilung Schlüsselbegriffe

Mehr

ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006

ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006 ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006 Dr. Ralf Kneuper Dr. Ralf Kneuper Beratung Jan Stender ITIL Berater Überblick Motivation Überblick CMMI Überblick

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 3 Dr. H. Ehler, S. Wagner 8. Februar 2007 Übungen zu Softwaretechnik Aufgabe 23 CMM Das Capability Maturity Model (CMM) wurde entwickelt, um die Fähigkeit von Auftragnehmern

Mehr

Festo und der Weg zur Business Excellence

Festo und der Weg zur Business Excellence Festo und der Weg zur Business Excellence Die Zertifizierung der Managementsysteme ist inzwischen für viele Unternehmen zur reinen Pflichtübung geworden. Die Normenforderungen und deren Einhaltung alleine

Mehr

Gokyo Ri Messung und Bewertung der Qualität von Entwicklungsprozessen

Gokyo Ri Messung und Bewertung der Qualität von Entwicklungsprozessen Gokyo Ri Messung und Bewertung der Qualität von Entwicklungsprozessen Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 11.09.2012 1 Ralf Kneuper Dipl.-Mathematiker, Univ.

Mehr

Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen

Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen Dr. Ernest Wallmüller, Wolfgang Daschner Qualität & Informatik www.itq.ch 1 Qualität & Informatik Kosten der CMMI-Nutzung

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Maturity Assesment for Processes in IT

Maturity Assesment for Processes in IT Maturity Assesment for Processes in IT Was ist MAPIT? Maturity Assessment for Processes in IT Werkzeug zur Reifegradbestimmung von IT Service Management Prozessen hinsichtlich ihrer Performance und Qualität

Mehr

CMMI im Kontext von Agilität

CMMI im Kontext von Agilität CMMI im Kontext von Agilität PMA, 10.05.2012, Zug by mimacom ag Zur Person David Krebs COO, Mitglied der Geschäftsleitung mimacom ag Software Engineer EMBA GM 10.05.2012 2 mimacom ag facts and figures

Mehr

Softwarequalität: Definitionen, Wünsche, Grenzen

Softwarequalität: Definitionen, Wünsche, Grenzen Softwarequalität: Definitionen, Wünsche, Grenzen iks Thementag Mehr Softwarequalität Ausgewählte Themen 22.05.2014 Autor: Christoph Schmidt-Casdorff Agenda Einführung Was ist Softwarequalität? Qualität

Mehr

Die Wahrheit über CMMI PMI Hamburg, 18.01.2013

Die Wahrheit über CMMI PMI Hamburg, 18.01.2013 Die Wahrheit über CMMI PMI Hamburg, 18.01.2013 Turning Visions into Business - 1 - Abstract Was fällt Ihnen als erstes zu CMMI ein? Zertifizierungen irgendwelcher Level? Die meisten Unternehmen kommen

Mehr

TÜV SÜD Informatik und Consulting Services GmbH Bereich Consulting Marcus Giese und Alfons Huber itsm@tuev-sued.de

TÜV SÜD Informatik und Consulting Services GmbH Bereich Consulting Marcus Giese und Alfons Huber itsm@tuev-sued.de Normen und Standards TÜV SÜD Informatik und Consulting Services GmbH Bereich Consulting Marcus Giese und Alfons Huber itsm@tuev-sued.de (...ITSM 3 Assessment, ITIL-, ISO 20000-Know How, Trainer für itsmf

Mehr

Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin

Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin Anwenderforum E-Government QuickCheck:ITIL 18.02.2010/Berlin INFORA GmbH Martin Krause Cicerostraße 21 10709 Berlin Tel.: 030 893658-0 Fax: 030 89093326 Mail: info@infora.de www.infora.de Agenda Die Ausgangssituation

Mehr

Software Assessments verhelfen zur effektiven Prozessverbesserung

Software Assessments verhelfen zur effektiven Prozessverbesserung Assessments verhelfen zur effektiven Prozessverbesserung Ein Erfahrungsbericht Dr. Gunter Hirche Gründe für ein Assessment Anforderungen: Probleme bei der Abwicklung von Projekten mit SW-Anteilen Termine,

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Leverage Consulting April, 2005. Software Prozessverbesserung mit CMMI

Leverage Consulting April, 2005. Software Prozessverbesserung mit CMMI Software Prozessverbesserung mit CMMI Das CMMI Modell 1 CMMI C Capability M Maturity M Model I Integrated Ist ein integrierter Ansatz für die Prozess Verbesserung im Systems- und Software Engineering.

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG. White Paper 08/2007. Seite 1 von 6

Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG. White Paper 08/2007. Seite 1 von 6 Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG White Paper 08/2007 Seite 1 von 6 Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG Einleitung

Mehr

Secure SDLC für die Masse dank OpenSAMM? OWASP 17.11.2011. The OWASP Foundation. Dr. Bruce Sams. http://www.owasp.org

Secure SDLC für die Masse dank OpenSAMM? OWASP 17.11.2011. The OWASP Foundation. Dr. Bruce Sams. http://www.owasp.org Secure SDLC für die Masse dank OpenSAMM? Dr. Bruce Sams 17.11.2011 Copyright The Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the License. The Foundation

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

KMMM. Knowledge Management Maturity Model. Karsten Ehms Siemens AG / ZT IK 1 Fachzentrum Wissensmanagement

KMMM. Knowledge Management Maturity Model. Karsten Ehms Siemens AG / ZT IK 1 Fachzentrum Wissensmanagement Maturity Model KMMM Karsten Ehms Siemens AG / ZT IK 1 Fachzentrum Wissensmanagement 2000 Überblick KMMM Ideen, Grundlagen, Konzepte Prozess eines KMMM Assessments Ergebnisse eines KMMM Assessments KMMM

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

Änderungen ISO 27001: 2013

Änderungen ISO 27001: 2013 Änderungen ISO 27001: 2013 Loomans & Matz AG August-Horch-Str. 6a, 55129 Mainz Deutschland Tel. +496131-3277 877; www.loomans-matz.de, info@loomans-matz.de Die neue Version ist seit Oktober 2013 verfügbar

Mehr

Über sieben Brücken musst Du gehen! Wie organisatorische Hindernisse eine Chance sein können

Über sieben Brücken musst Du gehen! Wie organisatorische Hindernisse eine Chance sein können Über sieben Brücken musst Du gehen! Wie organisatorische Hindernisse eine Chance sein können Agile Center D-IT-BVG2-E1 Christoph Weiss, Michael Schäfer Ausgangssituation Christian Sebastian Müller (CSM)

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Agenda ITIL v3 Framework

Agenda ITIL v3 Framework Agenda ITIL v3 Framework Overview & Allgemeines ITIL Service Lifecycle Service Strategies Service Design Service Transition Service Operation Continual Service Improvement ITIL V3 Continual Service Improvement

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Process Management Office Process Management as a Service

Process Management Office Process Management as a Service Process Management Office Process Management as a Service Unsere Kunden bringen ihre Prozesse mit Hilfe von ProcMO so zur Wirkung, dass ihre IT- Services die Business-Anforderungen schnell, qualitativ

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Anforderungsermittlung und Testmanagement im V-Modell die integrierte Lösung Andreas Plette (Telelogic) - Andreas Reuys (SQS)

Anforderungsermittlung und Testmanagement im V-Modell die integrierte Lösung Andreas Plette (Telelogic) - Andreas Reuys (SQS) Anforderungsermittlung und Testmanagement im V-Modell die integrierte Lösung Andreas Plette (Telelogic) - Andreas Reuys (SQS) 1 Agenda 12:30 13:00 Begrüßung & Vorstellung 13:00 13:45 Einführung Motivation

Mehr

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt Massive Automatisierung von Software-Tests In einem agilen Automotive Projekt Inhalt Die Projektziele Die Projektstruktur und die Rahmenbedingungen Automotive SPICE und Scrum Die Automatisierung der SW-Testfälle

Mehr

esec der sichere Weg zum ganzheitlichen Information-Security-Management-System (ISMS) nach ISO 27001 Version: 2.9 / 29.09.2008

esec der sichere Weg zum ganzheitlichen Information-Security-Management-System (ISMS) nach ISO 27001 Version: 2.9 / 29.09.2008 esec der sichere Weg zum ganzheitlichen Information-Security-Management-System (ISMS) nach ISO 27001 Version: 2.9 / 29.09.2008 WMC Wüpper Management Consulting GmbH Vertriebs-/Projektbüros Unternehmenssitz

Mehr

Agile Verbesserung der Arbeit Der richtige Weg zur professionellen IT

Agile Verbesserung der Arbeit Der richtige Weg zur professionellen IT Malte Foegen, Mareike Solbach, Claudia Raak Agile Verbesserung der Arbeit Der richtige Weg zur professionellen IT IT Maturity S e r v i c e s 1 Der falsche Weg 2 Der richtige Weg -2- Copyright 2007 wibas

Mehr

Qualitätssicherung von Software (SWQS)

Qualitätssicherung von Software (SWQS) Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 4.7.2013: Fazit Folie 2 CMMI: Prozess-Reifegrade Ständige Entwicklung Stufe 5: Optimierend

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

CA Business Service Insight

CA Business Service Insight PRODUKTBLATT: CA Business Service Insight CA Business Service Insight agility made possible Mit CA Business Service Insight wissen Sie, welche Services in Ihrem Unternehmen verwendet werden. Sie können

Mehr

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL INGTES AG Bahnhofstr. 94 CH 5000 Aarau Tel. +4162 836 30 70 www.ingtes.com PRODUKTENTWICKLUNG NACH DEM INGTES-PROZESSMODELL 2 1 PRODUKT- ENTWICKLUNG Bei

Mehr

COBIT. Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach

COBIT. Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach COBIT Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach Gliederung Motivation Komponenten des Frameworks Control Objectives Goals Prozesse Messen in CobiT Maturity Models Outcome

Mehr

Qualität in Projekten

Qualität in Projekten Qualitätssicherung (QS) / Qualitätsmanagement (QM).. was braucht ein Projekt? 1 Inhalte Begrüßen / Vorstellen QS / QM im Unternehmen & QS / QM im Projekt Beispiele (Kosten) Zusammenfassung / Abschluss

Mehr

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz ISIS Das Navigationssystem für angemessene Qualität und hohe Effizienz Inhalt Softwarequalität und Prozessqualität ISIS: das Ziel Messen der Prozessqualität Der Werkzeugzoo Die Wirkung Maßnahmen zur Prozessoptimierung

Mehr

Technische Universität München Fakultät für Informatik. Bewertung des neuen V-Modells XT aus Sicht von Capability Maturity Model Integration (CMMI )

Technische Universität München Fakultät für Informatik. Bewertung des neuen V-Modells XT aus Sicht von Capability Maturity Model Integration (CMMI ) Technische Universität München Fakultät für Informatik Diplomarbeit Bewertung des neuen V-Modells XT aus Sicht von Capability Maturity Model Integration (CMMI ) A CMMI Based Evaluation of the V-Modell

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

IT Prozessmanagement auf Basis anerkannter Prozessreifemodelle wie CMMI und SPiCE / ISO 15504

IT Prozessmanagement auf Basis anerkannter Prozessreifemodelle wie CMMI und SPiCE / ISO 15504 IT Prozessmanagement auf Basis anerkannter Prozessreifegradmodelle wie CMMI und SPiCE / ISO 15504 DI. Walter DÜRR ISO9000 Auditor, SPICE Assessor DI. Andreas NEHFORT IT-Consultant, CMMI & SPICE Assessor

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Inhaltsverzeichnis. 8. Zertifizierung nach Prozessanalyse 9. Zusammenfassung. 1. Messtechnische Erfassung 2. Flowcharts

Inhaltsverzeichnis. 8. Zertifizierung nach Prozessanalyse 9. Zusammenfassung. 1. Messtechnische Erfassung 2. Flowcharts V1.0 Inhaltsverzeichnis 1. Was ist ein Prozess? 2. Intermezzo: Pareto-Prinzip 3. Wozu dient eine Prozessanalyse? 4. Inhalt des Prozessassessments 5. Vorgehen im Prozessassessment 6. Flowcharts und ihre

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

ITIL in der Praxis 4. Secure Linux Administration Conference, 10.12.2009. Dipl.-Inform. Johannes Plötner

ITIL in der Praxis 4. Secure Linux Administration Conference, 10.12.2009. Dipl.-Inform. Johannes Plötner ITIL in der Praxis 4. Secure Linux Administration Conference, 10.12.2009 Dipl.-Inform. Johannes Plötner Johannes Plötner Diplom Informatiker, Uni Karlsruhe (TH) Schwerpunkte Telematik, Kryptographie und

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering 2. Methodologien Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering: 2. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

SPiCE ISO TR 15504 1

SPiCE ISO TR 15504 1 SPICE ISO TR 15504 Klaus Franz Muth Partners GmbH, Wiesbaden 06122 59810 www.muthpartners.de klaus.franz@muthpartners.de SPiCE ISO TR 15504 1 Die SPiCE ISO TR 15504 besteht aus 9 Teilen Part 1: Konzepte

Mehr

1 Einleitung 1. 2 Entwicklung und Bedeutung von COBIT 7

1 Einleitung 1. 2 Entwicklung und Bedeutung von COBIT 7 vii 1 Einleitung 1 Teil I COBIT verstehen 5 2 Entwicklung und Bedeutung von COBIT 7 2.1 ISACA und das IT Governance Institute....................... 7 2.2 Entstehung von COBIT, Val IT und Risk IT....................

Mehr

Design for Six Sigma umsetzen POCKET POWER

Design for Six Sigma umsetzen POCKET POWER Design for Six Sigma umsetzen POCKET POWER 3 Inhalt 1 Einleitung 5 2 Methoden und Werkzeuge 9 2.1 Define 9 2.2 Measure 16 2.3 Analyze 24 2.4 Design 34 2.5 Verify 47 3 Der Einsatz in Systemprojekten 52

Mehr

Repeatable Benchmarking Mahout

Repeatable Benchmarking Mahout Studienarbeitsexposé Repeatable Benchmarking Mahout Entwicklung eines Lasttest-Rahmenwerkes für Apache Mahout von: Oliver Fischer Institut für Informatik Humbold-Universität zu Berlin Matrikelnummer: 19

Mehr

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt Produktqualität in agilen Entwicklungsvorgehen BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt 1 Motivation 2 Agile Entwicklungsvorgehen Status Quo vorwiegend eingesetzte

Mehr