ISO/IEC (SPICE)

Transkript

1 ISO/IEC (SPICE) Wo Licht ist, ist auch Schatten! Markus Sprunck HVB Information Services GmbH SE 2007 am 28. März 2007 in Hamburg G

2 Inhalt Einleitung Grundlagen Entwicklungsinfrastruktur Erfolgsfaktoren, Chancen & Risiken Zusammenfassung Seite 2

3 Die HVB Information Services: Ein exzellenter Application Service Provider Die HVB IS ist eine hundertprozentige Tochter der Bayerischen Hypo- und Vereinsbank AG Sie gehört zu den größten IT-Dienstleistern für den Finanzdienstleistungssektor in Europa Unsere Kunden sind in erster Linie alle Geschäftsbereiche der HVB AG sowie die Töchter der HVB Das Leistungsspektrum umfasst drei Kernbereiche: Anwendungsentwicklung Neu- und Weiterentwicklung in zentraler und dezentraler Welt Integration von Fremdsoftware IT-Betrieb und Service Services rund um IT-Betrieb für fehlerfreie Produktion und höchste Sicherheit Consulting Kompetente Beratung rund um die Geschäftsprozesse unserer Kunden & IT-Systemlandschaft Seite 3

4 Inhalt Einleitung Grundlagen Entwicklungsinfrastruktur Erfolgsfaktoren, Chancen und Risiken Zusammenfassung Seite 4

5 SPICE Überblick (1/2) SPICE - Software Process Improvement and Capability Determination ISO/IEC seit März 2006 vollständig veröffentlicht Modell für das Assessment von Unternehmensprozessen Wurzeln liegen bei ISO 9000, CMM und BOOTSTRAP Schwerpunkt auf Softwareentwicklung Seite 5

6 SPICE Überblick (2/2) Assessment Modell Die Planung, Durchführung, Auswertung von Assessments sowie Ansätze zur Prozessverbesserung werden im Assessment Modell beschrieben. Es beinhaltet: Capability Levels (6) Process Attributes (9) Generic Practices, GP (41) Generic Work Product, GWP (21) ISO/IEC :2006(E) Process Referenz Modell Das beispielhafte Process Referenz Modell basiert auf der ISO/IEC AMD1 & AMD2. Es ist gegliedert nach Primary-, Supporting- und Organizational-Prozessen. Es beinhaltet: Process Areas (9) Processes (40) Base Practices (326) Work Products (185) Seite 6

7 SPICE Capability Levels (Fähigkeitsdimension) Optimiert: Quantitative Messungen werden verwendet, um den Prozess laufend zu optimieren Vorhersagbar: Metriken machen Prozessverlauf und Resultate zeitlich und vom Aufwand her kontrollierbar Etabliert: Vordefinierte Standards & Prozeduren existieren und können angepasst werden Gemanagt: Prozess und dazugehörige Aktivitäten werden geplant; Verantwortlichkeiten sind klar definiert SPICE Level 5 Optimizing SPICE Level 4 Predictable SPICE Level 3 Established SPICE Level 2 Managed Durchgeführt: Prozess wird ohne Planung durchgeführt; Input und Output sind erkennbar Unvollständig: Durchführung und Resultate des Prozesses sind nicht erkennbar SPICE Level 1 Performed SPICE Level 0 Incomplete Prozess A Prozess B Prozess C Die Anforderungen aller niedrigeren Levels müssen für das Erreichen des jeweils höheren Levels erfüllt sein Seite 7

8 SPICE Process Attributes (Prozessattribute) SPICE Level 1 Performed SPICE Level 2 Managed SPICE Level 3 Established SPICE Level 4 Predictable "GP Define the requirements for documentation and control of the work products. [ ] Dependencies between work products are identified and understood. Requirements for the approval of work products to be controlled are defined." [Quelle: ISO/IEC ] SPICE Level 5 Optimizing (1) Abbildungsnachweis: ISO/IEC :2006(E) Seite 8

9 SPICE - Process Reference Model (1) Für einige Artefakte im Entwicklungsprozess werden an diesen Prozessen konkrete Forderungen zur Traceability gemacht. (1) Das in ISO/IEC verwendete Referenzmodel wird in der ISO/IEC AMD1 & AMD2 definiert. (2) Abbildungsnachweis: ISO/IEC :2006(E) Seite 9

10 SPICE - Assessments Prozess Prozess (Person (Person/ / Projekt) Projekt) wird unterworfen identifiziert Änderungen an Prozess-Assessment führt zu führt zu identifiziert Reifegrade + Risiken von Prozess Prozess Verbesserung motiviert zu Bestimmung des des Reifegrades Reifegrades Alle Prozessänderungen haben Auswirkung auf Personen und Produktqualität. Deshalb sollten Prozessverbesserung nicht isoliert betrachtet werden. Seite 10

11 Inhalt Einleitung Grundlagen Entwicklungsinfrastruktur Erfolgsfaktoren, Chancen & Risiken Zusammenfassung Seite 11

12 Infrastruktur Traceability Anforderungen (1/4) PA 2.2: "Dependencies between work products are identified and understood. Requirements for the approval of work products to be controlled are defined." Abhängigkeiten zwischen/unter Artefakten und Implementierung lassen sich grundsätzlich in zwei Klassen aufteilen: Die vorwärtsgerichtete Traceability beschreibt Verbindungen von den Anforderungen über das Design bis zum Coding und Test Die rückwärtsgerichtete Traceability gibt den Rückschluss auf ursprüngliche Anforderungen, z.b. aus dem bestehenden Code einer Anwendung Seite 12

13 Infrastruktur Traceability Anforderungen (2/4) Gründe für die Dokumentation von Traceability-Links: Wird etwas entwickelt, nach dem keiner gefragt hat? Design Elemente Systemanforderungen Kundenanforderungen Wird alles getestet? Kundenanforderungen Abnahmetests; Systemanforderungen Integrations-/Systemtests Wurde etwas vergessen? Kundenanforderungen Systemanforderungen Welche Teile des Systems müssen angefasst werden, wenn sich eine bestimmte Kundenanforderung ändern soll? Kundenanforderungen Systemanforderungen Design Elemente Quellcode Wie ist der Fortschritt der Entwicklung? Kundenanforderungen Systemanforderungen Design Elemente Quellcode Traceability bedeutet Aufwand bei der Erstellung/Pflege von Dokumenten und Artefakten. Je größer ein Vorhaben ist, desto höher ist der Bedarf an Werkzeugunterstützung. Seite 13

14 Infrastruktur Traceability Anforderungen (3/4) Umsetzungsbeispiel: Entwicklungswerkzeuge werden über Surrogat-Module mit DOORS synchronisiert. Die Verwaltung der Traceability-Links erfolgt in DOORS. Seite 14

15 Infrastruktur Traceability Anforderungen (4/4) Beispiel einer Integration der Werkzeuge DOORS und TestDirector: Exporting aus DOORS inkl. "copy and link tool" zur Erstellung eines Testplans mit den zu testenden Anforderungen Importing in DOORS um die im TestDirector existierenden Daten in DOORS zur Verfügung zu stellen (Test Plan, Defekt und Link Modul) Verlinkung von Anforderungen und Testfällen Anforderungsmanagement Testfallmanagement N M 1 1 DOORS (Anforderung) DOORS (Surrogat-Modul) TestDirector (Testfälle) Seite 15

16 Inhalt Einleitung Grundlagen Entwicklungsinfrastruktur Erfolgsfaktoren, Chancen & Risiken Zusammenfassung Seite 16

17 Wie kann ein idealer Korridor für ausgewählte Erfolgsfaktoren aussehen? Top-Management Support strategisches Unternehmensziel Projektportfolio homogene Projekte Entwicklungsinfrastruktur hohe Standardisierung Qualitätsmanagement starke Ausprägung (ISO9000, etc.) Einführungszeitraum sehr schnell (< 1 Jahr pro Level) Mitarbeiter Motivation sehr starke Anreize Finanzielle Ausstattung sehr gute Unterstützung IT Governance Budgetkontrolle beim Fachbereich Top-Management Support untergeordnetes Unternehmensziel Projektportfolio heterogene Projekte Entwicklungsinfrastruktur keine Standardisierung Qualitätsmanagement nicht vorhanden Einführungszeitraum sehr langsam (> 3 Jahre pro Level) Mitarbeiter Motivation keine Anreize Finanzielle Ausstattung keine Unterstützung IT Governance Budgetkontrolle bei IT ideal geeignet problematisch Seite 17

18 Ausgewählte Chancen & Risiken + Skalierbarkeit Projekte steigt + Erleichterung Projektstaffing + Vorhersagbarkeit verbessert + Projektrisiken minimiert + Erhöhung der Transparenz + Projektcontrolling erleichtert + Grundlage für Off-/On-Shoring und Unterauftragsmanagement - Neigung zum Taylorismus - Overhead bei Dokumentation - Aufwand für Einführung - Aufwand für laufenden Betrieb - Widerstände bei Stakeholdern - Widerstände bei Mitarbeitern - Sinkende Risikobereitschaft in der Organisation Seite 18

19 Risiken - Neigung zum Taylorismus Trennung Hand- und Kopfarbeit "Analyse und Planung des Arbeitsprozesses wird durch Spezialisten im Management auf wissenschaftlichen Grundlagen basierend vollzogen" 1) One-best-way-Prinzip "Arbeit sollte auf präzisen Anleitungen basieren, die das Management vorgibt." 1) Akkordarbeit, Prämienlöhne "Geld wird als Motivationsfaktor eingesetzt, d.h. die Bezahlung wird von der erbrachten Leistung abhängig gemacht." 1) Arbeitsteilung hoch "Das erste Prinzip kann nur durch eine hohe Arbeitsteilung realisiert werden" 1) SPICE verursacht eine starke Fokussierung auf die Prozessqualität. Es fokussiert auf das Messen und Bewerten von Prozessen und Aktivitäten. SPICE fördert Vorgehensmodelle die sehr feingranular beschrieben sind, wobei mehr als 200 Aktivitäten und/oder Ergebnistypen nicht ungewöhnlich sind. SPICE führt zu einer hohen Anzahl an Artefakten. Durch die hohe Anzahl an Artefakten und deren Prüfung wird die Arbeitsteilung und zeitliche Entkopplung gefördert. Taylorismus (Fabrikmetapher) in der SW-Entwicklung ist gefährlich; Hier handelt es sich eben nicht um einen Produktionsprozess sondern ein reinen Entwicklungsprozess. (1) siehe Seite 19

20 Inhalt Einleitung Grundlagen Entwicklungsinfrastruktur Erfolgsfaktoren, Chancen & Risiken Zusammenfassung Seite 20

21 Zusammenfassung SPICE bietet ein umfangreiches Referenzmodell und ein Assessment- Vorgehen; Es dient der Prozessverbesserung und der Quantifizierung von Reifegraden für Unternehmensprozesse Der Nutzen kann groß sein, jedoch ist SPICE kein Allheilmittel für jedes Unternehmen; Die Einführung kostet viel Zeit und Ressourcen und kann nur dann erfolgreich sein, wenn eine wohl durchdachte Einführung vorliegt Die Zielsetzung der SPICE-Einführung muss allen Stakeholdern klar sein und die Kommunikation aktiv gesteuert werden Gerade für große Entwicklungsvorhaben ist eine standardisierte und automatisierte Infrastruktur von großem Nutzen; Die Werkzeugunterstützung sollte bei der SPICE-Einführung beachtet werden Seite 21

22 Kontakt Markus Sprunck Leiter SW-Engineering Methods & Process HVB Information Services GmbH HIS16EP Am Eisbach 4 D München Telefon: markus.sprunck@hvbis.com Seite 22