Wo Licht ist, ist auch Schatten! - se-konferenzen.dese-konferenzen.de/bisher/se2007/folien/se2007-B2-3.pdf · G ISO/IEC 15504 (SPICE) Markus Sprunck HVB Information Services GmbH

G

ISO/IEC 15504 (SPICE)

Markus Sprunck

HVB Information Services GmbH

SE 2007 am 28. März 2007 in Hamburg

Wo Licht ist, ist auch Schatten!

M. Sprunck, HVB IS, 15.03.2007

Seite 2

n Einleitung

n Grundlagen

n Entwicklungsinfrastruktur

n Erfolgsfaktoren, Chancen & Risiken

n Zusammenfassung

Inhalt


Seite 3

n Die HVB IS ist eine hundertprozentige Tochter der Bayerischen

Hypo- und Vereinsbank AG

n Sie gehört zu den größten IT-Dienstleistern für den

Finanzdienstleistungssektor in Europa

n Unsere Kunden sind in erster Linie alle Geschäftsbereiche der

HVB AG sowie die Töchter der HVB

n 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

Die HVB Information Services:Ein exzellenter Application Service Provider


Seite 4

n Einleitung

n Grundlagen


n Erfolgsfaktoren, Chancen und Risiken

n Zusammenfassung

Inhalt


Seite 5

SPICE – Überblick (1/2)

n SPICE - Software Process Improvement

and Capability Determination

n ISO/IEC 15504 seit März 2006 vollständig

veröffentlicht

n Modell für das Assessment von

Unternehmensprozessen

n Wurzeln liegen bei ISO 9000, CMM

und BOOTSTRAP

n Schwerpunkt auf Softwareentwicklung


Seite 6

SPICE – Überblick (2/2)

Die Planung, Durchführung,

Auswertung von Assessments

sowie Ansätze zur Prozess-

verbesserung werden im

Assessment Modell

beschrieben.

Es beinhaltet:

4Capability Levels (6)

4Process Attributes (9)

4Generic Practices, GP (41)

4Generic Work Product, GWP

(21)

Das beispielhafte Process

Referenz Modell basiert auf

der ISO/IEC 12207 AMD1 &

AMD2. Es ist gegliedert nach

Primary-, Supporting- und

Organizational-Prozessen.

Es beinhaltet:

4Process Areas (9)

4Processes (40)

4Base Practices (326)

4Work Products (185)

ISO/IEC

15504-5:2006(E)

Assessment Modell Process Referenz Modell


Seite 7

Die Anforderungen aller niedrigeren Levels müssen für das Erreichen

des jeweils höheren Levels erfüllt sein

SPICE Level 0 Incomplete

SPICE Level 1 Performed

SPICE Level 2 Managed

SPICE Level 3 Established

SPICE Level 4 Predictable

SPICE Level 5 Optimizing

Pro

zess B

Pro

zess A

Pro

zess C

SPICE – Capability Levels (Fähigkeitsdimension)

Unvollständig: Durchführung und Resultate

des Prozesses sind nicht erkennbar

Durchgeführt: Prozess wird ohne Planung

durchgeführt; Input und Output sind erkennbar

Gemanagt: Prozess und dazugehörige Aktivitäten

werden geplant; Verantwortlichkeiten sind klar definiert

Vorhersagbar: Metriken machen Prozessverlauf und

Resultate zeitlich und vom Aufwand her kontrollierbar

Optimiert: Quantitative Messungen werden verwendet,

um den Prozess laufend zu optimieren

Etabliert: Vordefinierte Standards & Prozeduren

existieren und können angepasst werden


Seite 8

SPICE – Process Attributes (Prozessattribute)

"GP 2.2.2 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 15504-5]

(1) Abbildungsnachweis: ISO/IEC 15504-5:2006(E)

SPICE Level 1 Performed

SPICE Level 2 Managed

SPICE Level 3 Established

SPICE Level 4 Predictable

SPICE Level 5 Optimizing


Seite 9

SPICE - Process Reference Model (1)

(1) Das in ISO/IEC 15504 verwendete Referenzmodel wird in der ISO/IEC 12207 AMD1 & AMD2 definiert.

(2) Abbildungsnachweis: ISO/IEC 15504-5:2006(E)

Für einige Artefakte im

Entwicklungsprozess

werden an diesen

Prozessen konkrete

Forderungen zur

Traceability gemacht.


Seite 10

SPICE - Assessments

Prozess

(Person / Projekt)

Prozess

(Person / Projekt)

Prozess-AssessmentProzess-Assessment

Prozess

Verbesserung

Prozess

Verbesserung

Bestimmung

des Reifegrades

Bestimmung

des Reifegrades

motiviert zu

führt zu führt zu

wird

unterworfen

identifiziert

Änderungen an

identifiziert

Reifegrade +

Risiken von

Alle Prozessänderungen haben Auswirkung auf Personen und Produktqualität.

Deshalb sollten Prozessverbesserung nicht isoliert betrachtet werden.


Seite 11

n Einleitung

n Grundlagen



n Zusammenfassung

Inhalt


Seite 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:

n Die vorwärtsgerichtete Traceability

beschreibt Verbindungen von den

Anforderungen über das Design bis zum

Coding und Test

n Die rückwärtsgerichtete Traceability gibt

den Rückschluss auf ursprüngliche

Anforderungen, z.B. aus dem bestehenden

Code einer Anwendung


Seite 13

Infrastruktur – Traceability Anforderungen (2/4)Gründe für die Dokumentation von Traceability-Links:

n Wird etwas entwickelt, nach dem keiner gefragt hat?

Design Elemente n Systemanforderungen n Kundenanforderungen

n Wird alles getestet?

Kundenanforderungen n Abnahmetests; Systemanforderungen n Integrations-/Systemtests

n Wurde etwas vergessen?

Kundenanforderungen n Systemanforderungen

n Welche Teile des Systems müssen angefasst werden, wenn sich eine bestimmte

Kundenanforderung ändern soll?

Kundenanforderungen n Systemanforderungen n Design Elemente n Quellcode

n Wie ist der Fortschritt der Entwicklung?

Kundenanforderungen n Systemanforderungen n Design Elemente n 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 14


Entwicklungswerkzeuge werden über Surrogat-Module mit DOORS synchronisiert.

Die Verwaltung der Traceability-Links erfolgt in DOORS.

Umsetzungsbeispiel:


Seite 15


Beispiel einer Integration der Werkzeuge DOORS und TestDirector:

n Exporting aus DOORS inkl. "copy and link tool" zur Erstellung

eines Testplans mit den zu testenden Anforderungen

n Importing in DOORS um die im TestDirector existierenden Daten in

DOORS zur Verfügung zu stellen (Test Plan, Defekt und Link Modul)

n Verlinkung von Anforderungen und Testfällen

N M 1 1

DOORS (Anforderung) DOORS (Surrogat-Modul) TestDirector (Testfälle)

Testfallmanagement

Anforderungsmanagement


Seite 16

n Einleitung

n Grundlagen



n Zusammenfassung

Inhalt


Seite 17

Wie kann ein idealer Korridor für ausgewählte Erfolgsfaktoren aussehen?

IT Governance

Budgetkontrolle beim Fachbereich

IT Governance

Budgetkontrolle bei IT

Projektportfolio

homogene Projekte

Projektportfolio

heterogene Projekte

Top-Management Support

strategisches Unternehmensziel

Top-Management Support

untergeordnetes Unternehmensziel

Entwicklungsinfrastruktur

hohe Standardisierung

Entwicklungsinfrastruktur

keine Standardisierung

Qualitätsmanagement

starke Ausprägung (ISO9000, etc.)

Qualitätsmanagement

nicht vorhanden

Finanzielle Ausstattung

sehr gute Unterstützung

Finanzielle Ausstattung

keine Unterstützung

ideal geeignet problematisch

Mitarbeiter Motivation

sehr starke Anreize

Mitarbeiter Motivation

keine Anreize

Einführungszeitraum

sehr schnell (< 1 Jahr pro Level)

Einführungszeitraum

sehr langsam (> 3 Jahre pro Level)


Seite 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 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 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.

SPICE fördert Vorgehensmodelle die

sehr feingranular beschrieben sind,

wobei mehr als 200 Aktivitäten

und/oder Ergebnistypen nicht

ungewöhnlich sind.

SPICE verursacht eine starke

Fokussierung auf die Prozessqualität.

Es fokussiert auf das Messen und

Bewerten von Prozessen und

Aktivitäten.

(1) siehe http://de.wikipedia.org/wiki/Taylorismus

Taylorismus (Fabrikmetapher) in der SW-Entwicklung ist gefährlich; Hier handelt es sich eben

nicht um einen Produktionsprozess sondern ein reinen Entwicklungsprozess.


Seite 20

n Einleitung

n Grundlagen



n Zusammenfassung

Inhalt


Seite 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 Werkzeug-

unterstützung sollte bei der SPICE-Einführung beachtet werden


Seite 22

Markus Sprunck

Leiter SW-Engineering Methods & Process

HVB Information Services GmbH

HIS16EP

Am Eisbach 4

D-80538 München

Telefon: ++49 89 378-21009

E-Mail: [email protected]

Kontakt

Documents

Wo Licht ist, ist auch Schatten! - se-konferenzen.dese-konferenzen.de/bisher/se2007/folien/se2007-B2-3.pdf · G ISO/IEC 15504 (SPICE) Markus Sprunck HVB Information Services GmbH