Projektmanagement Klare Strukturen und agiles Vorgehen ...

Experience Nr. 49 Mai 2011
© by ERNI Consulting AG
Experience
ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen
Projektmanagement
Klare Strukturen und agiles Vorgehen
schliessen sich nicht aus
Mitarbeiterentwicklung
Wie durch Mitarbeiterentwicklung
Mehrwert generiert wird
Requirements Engineering
Wie Business und Technik die
gegenseitige Verständigung verbessern
Testing
Wie klare Verantwortlichkeiten
und Automatisierung die Qualität
nachhaltig steigern

ERNI Experience | Editorial
Titelseite: Alain Gayret
Business Area Manager in der Firma ERNI.
Beratertätigkeit: Project Management,
Coaching und Training
Impressum
Herausgeber
ERNI Consulting AG
Zürich · Bern · Baar
ERNI (Deutschland) GmbH, München
ERNI (Slovakia) s.r.o., Bratislava
Redaktion
Adela Papajová
ERNI (Slovakia) s.r.o.
Tel. +421 2 3255 37 37
E-Mail leserservice@erni.ch
Internet www.erni.ch/experience
Editorial
Alain Gayret
Projektmanagement
Philip Lehmann
Thomas Bigler
Mitarbeiterentwicklung
Alain Gayret
David Kurmann
Silvio Tarreghetta
Requirements Engineering
Sascha Nussbaumer
Marco Stöckli
Testing
Marcel Stoop
Severin Dietschi
Lektorat
Daniel Meierhans,
Inhalte.ch, Zürich
Ruedi Häuptli, Sprachagentur Bahia,
Salvador BR
Konzept/Layout
Katarina Beinrohrova
Produktion
von Ah Druck AG, Sarnen
Auflage
10 000 Expl. D 2500 Expl. F
Erscheint quartalsweise
Copyright © 2011
by ERNI Management Services AG
Alle Rechte vorbehalten.
2
Tragfähige Brücken
zwischen Schnittstellen
Das Zusammenspiel der Anspruchsgruppen entscheidet massgeblich über das Gelingen
von Projekten. Fast jeder hat schon erlebt, wie ein Projekt ins Schlingern geriet, weil es an
einer Organisationsschnittstelle ins Stocken geriet. Welche methodischen, organisatorischen
und personellen Brücken geschlagen werden können, damit aus den Schnittstellen produktive
Verbindungen werden, lässt sich am besten aus erfolgreichen Praxisbeispielen lernen.
Entscheidend für die Tragfähigkeit jeder Brücke zwischen organisatorischen Schnittstellen
sind die Menschen, die sie bauen. Sie müssen neben dem notwendigen Fach-Know-how vor
allem auch ausgeprägte soziale Kompetenz und Erfahrungen aus vergleichbaren Herausforderungen
mitbringen.
Der einleitende Beitrag der aktuellen Experience-Ausgabe unterstreicht die Wichtigkeit eines
klar strukturierten Gesamtprojektmanagements, unabhängig davon, ob für die Umsetzung
eine agile Methode wie Scrum oder das klassische Wasserfallmodell eingesetzt wird. Zum
übergeordneten Brückenschlag gehören insbesondere auch die Supportfunktionen wie Stakeholder-,
Risiko-, Change- oder Teammanagement.
Der zweite Artikel thematisiert die Bedeutung der passenden Schulungsmethoden für die
nachhaltige Überführung von Wissen in Praxis. Mehrstufige Konzepte, die möglichst genau
an die spezifischen Bedürfnisse von Unternehmen und Mitarbeitenden ausgerichtet sind, sichern
den langfristigen Mehrwert der Investitionen in die Mitarbeiterentwicklung.
Mit welchen organisatorischen und methodischen Mitteln eine tragfähige Brücke zwischen
Business und Technik geschlagen werden kann, zeigt der dritte Beitrag. Den Abschluss bildet
ein Artikel zu den Verbindungen, die zwischen Business, Entwicklungsabteilung und Testing
etabliert werden, um eine optimale Softwarequalität zu erreichen.
Ich wünsche Ihnen nicht nur eine kurzweilige Lektüre, sondern hoffe, dass Ihnen unser Magazin
auch konkrete Anregungen dazu bringt, welche Brücken die Effizienz Ihrer Organisation
steigern.
Ich freue mich auf Ihr Feedback!
Herzlich
Alain Gayret

Inhalt
Projektmanagement
Mitarbeiterentwicklung
Requirements Engineering
Testing
Zwei Trümpfe in einer Hand 4
Klare Strukturen und agiles Vorgehen schliessen sich nicht aus
Die Supportfunktionen sind zentrale Erfolgsfaktoren im Projektmanagement – unabhängig vom
Vorgehensmodell oder vom eingesetzten Standard. Sie bilden zusammen mit der strukturierten
Gesamtprojektleitung die definierte Basis für eine flexible Umsetzung der Anforderungen.
Vom Wissen zum Können 10
Wie durch Mitarbeiterentwicklung Mehrwert generiert wird
Investitionen in die Mitarbeiterentwicklung sind für innovationsgetriebene Technologiefirmen
und für Dienstleistungsunternehmen essenziell. Umso wichtiger ist die Qualität der Massnahmen.
Es genügt nicht, wenn Trainingskonzepte an die speziellen Bedürfnisse der Firma angepasst sind
und stufengerecht erfolgen. Entscheidend ist vielmehr, ob die Ergebnisse langfristig in der Organisation
verankert werden.
Den Röstigraben überwinden 16
Wie Business und Technik die gegenseitige Verständigung verbessern
Business und Technik sprechen quasi von Natur aus unterschiedliche Sprachen. Eine effektive
Verständigung wird möglich durch definierte Verantwortliche auf beiden Seiten, gemeinsame Methoden,
einheitliche Softwarewerkzeuge und eine institutionalisierte Kommunikation.
Die Qualität nachhaltig steigern 22
Was klare Verantwortlichkeiten und Automatisierung ausmachen können
Softwarequalität lässt sich nicht einfach an die Testingabteilung delegieren. Für eine minimale
Fehlerrate müssen auch das Business und die Entwickler ihren Teil der Verantwortung übernehmen.
Eine Automatisierung kann die Qualität zusätzlich erhöhen und den Aufwand senken.
Alle Artikel online:
www.erni.ch/experience
Inhalt | ERNI Experience
3

Projektmanagement | Zwei Trümpfe in einer Hand
Zwei Trümpfe in einer Hand
Klare Strukturen und agiles Vorgehen schliessen sich nicht aus
Die Supportfunktionen sind zentrale Erfolgsfaktoren im Projektmanagement – unabhängig vom Vorgehensmodell oder
vom eingesetzten Standard. Sie bilden zusammen mit der strukturierten Gesamtprojektleitung die definierte Basis für eine
flexible Umsetzung der Anforderungen. Von Philip Lehmann und Thomas Bigler
4
Die verbreiteten Standards und Zertifizierungsstellen
für Projektmanagement und
Prozesse wie IPMA, PMI, Prince II oder
CMMI geben meist keine spezifischen
Vorgehensmodelle vor. In der Praxis wird
dagegen der Nutzen agiler Vorgehensweisen
intensiv diskutiert.
Die Debatte um die Vor- und Nachteile
agiler und iterativer Methoden wie Scrum
oder RUP (Rational Unified Process) gegenüber
den eher traditionellen Wasserfall-
oder Stage-Gate-Vorgehen überdeckt
den viel wichtigeren gemeinsamen
Nenner: Die strukturierte, übergeordnete
Gesamtprojektleitung und
die Supportfunktionen bleiben unabhängig
davon, nach welchem Modell ein
Projekt umgesetzt wird, zentrale Erfolgsfaktoren.
Die Herausforderung besteht
darin, von den Vorteilen der agilen Vor-
gehensweisen zu profitieren und gleichzeitig
die Pluspunkte des bewährten und
weitverbreiteten Wasserfallmodells zu
nutzen. Ohne eine zielbewusste Teamführung
oder ein aktives Stakeholdermanagement
sind die Projektziele, die
verschiedene Organisationseinheiten
betreffen, kaum zu erreichen.
Das Gleiche gilt für Hauptaufgaben des
Projektmanagements wie das Monitoring
& Controlling. Sie müssen unabhängig
von der gewählten Methode
strukturiert angegangen werden, wenn
die gesetzten Ziele im vorgegebenen
Zeitrahmen erreicht werden sollen.
Die Wahl zwischen den verschiedenen
Vorgehensmodellen hängt im Wesentlichen
vom Umfang und vom Inhalt des
Projekts ab.

Zwei Trümpfe in einer Hand | Projektmanagement
Die Herausforderung besteht darin, von den Vorteilen der agilen Vorgehens-
weisen zu profitieren und gleichzeitig die Pluspunkte des bewährten und
weitverbreiteten Wasserfallmodells zu nutzen.
5

Projektmanagement | Zwei Trümpfe in einer Hand
In umfangreicheren Projekten besteht die Kunst der Gesamtprojektleitung in der optimalen Kombination von Flexibilität und
klaren Strukturen. Während auf der übergeordneten Gesamtprojektebene eine eindeutige Organisation mit definierten Verantwortlichkeiten,
verbindlichen Terminen und Lieferobjekten für die Planungssicherheit unabdingbar ist, können in den einzelnen
Umsetzungsphasen agile Vorgehensweisen markante Qualitäts- und Effizienzsteigerungen bringen.
6
Abb. 1:
Kern und Supportprozess im PM
Abb. 2:
Kombination von Modellen
System
Requirements
SCRUM
RUP
I
Inception Elaboration Construction Transition
Project Setup
Project Monitoring & Control
Risk management
Quality management
E
Team management
Configuration management
Change management
Planning
Stakeholder management
Sprint Backlog
C
T
Any other Model . . .
MS 1 MS 2 MS 3 MS 4
I: Inception
Project Execution Project Closing
Implementation
I
E: Elaboration
E
Daily Scrum
Meeting
Backlog tasks
expanded by team
Product Backlog
As prioritized by Product Owner
One Iteration
C
T
Time
System
Tests
C: Construction
I
24 hours
30 days
E
C
T
T: Transition
I
Operations
E
Demonstrable
new functionality
C
T

Übergeordnete Struktur – bei umfangreichen
Projekten unabdingbar
In umfangreicheren Projekten besteht
die Kunst der Gesamtprojektleitung in
der optimalen Kombination von Flexibilität
und klaren Strukturen. Während
auf der übergeordneten Gesamtprojektebene
eine eindeutige Organisation
mit definierten Verantwortlichkeiten,
verbindlichen Terminen und Lieferobjekten
für die Planungssicherheit
unabdingbar ist, können in den einzelnen
Umsetzungsphasen agile Vorgehensweisen
markante Qualitäts- und
Effizienzsteigerungen bringen. Bedingung
ist eine klare Definition der High-
Level-Anforderungen und des Zeitplans,
innerhalb dessen iterative Zyklen wie
Scrum-Sprints oder RUP-Iterationen zu
Lieferobjekten führen müssen.
Die Flexibilität in der Umsetzung bedingt
allerdings nicht zwangsläufig ein
iteratives Vorgehen. Verbesserungen
und Änderungen können auch im Rahmen
eines herkömmlichen Wasserfallvorgehens
flexibel integriert werden.
Wie im einzelnen Projekt am besten
vorgegangen wird, ist sowohl von der
spezifischen Aufgabenstellung als auch
vom bereits vorhandenen Know-how
abhängig. Für die Definition einer optimalen
Makro- und Mikroprojektorganisation
muss der Gesamtprojektleiter
zudem kulturelle Faktoren, die Teambildung
und das Stakeholdermanagement
berücksichtigen.
Beispiel 1
Webshopmodernisierung
Ein Industrieunternehmen will seinen
Webshop modernisieren. Die Benutzerführung
entspricht nicht mehr den
heutigen Standards. Als Folge davon
brechen viele Kunden den Kaufprozess
vorzeitig ab. Gleichzeitig sollen neue
Features implementiert und die Basis
für künftige Sortimentserweiterungen
gelegt werden. Die Verbesserung der
Nutzerfreundlichkeit des Shops tangiert
alle kundenbezogenen Bereiche
des Unternehmens sowie zahlreiche
interne und externe Inhalts- und Technologielieferanten.
Sie müssen alle ihre
Lieferobjekte koordiniert zum richtigen
Zeitpunkt im definierten Umfang bereitstellen.
Die Aufgabe der Gesamtprojektleitung
bestand darin, die verschiedenen
Anspruchsgruppen von der
Definition der detaillierten Projektziele
und der adäquaten Projektorganisation
über das Anforderungsmanagement
bis zur Fertigstellung des Shops zu koordinieren,
die Businessinteressen gegenüber
den umsetzenden technischen
Abteilungen zu vertreten und die Einhaltung
des Gesamtprojektbudgets zu
garantieren.
Wichtigster Erfolgsfaktor bei der Führung
eines derart umfassenden Projekts
ist die Anpassung von Struktur und
Vorgehensweise an die spezifischen Begebenheiten.
Dafür gab es im Unternehmen
bereits etablierte Projektstandards,
auf die aufgebaut werden konnte. Sämtliche
benötigten Rollen wurden genau
definiert und die entsprechenden Mitarbeitenden
involviert. Die klare Rollenverteilung
half mit, Kompetenzstreitigkeiten
im Projektverlauf weitgehend
zu vermeiden. Zu den wichtigsten Anfangsarbeiten
gehörten zudem die genaue
Abgrenzung des Aufgabenbereichs
(Scope), die Festlegung der Ziele und die
daraus abgeleitete Definition der Anforderungen.
Nicht im Voraus geplante Änderungen
wurden im Projekt situativ durch den
Gesamtprojektleiter und den Vertreter
des Auftraggebers entschieden. Dieses
zentrale Changemanagement bot einerseits
Gewähr dafür, dass nur Änderungen
eingeführt wurden, die sachlich
begründet waren und den übergeordneten
Projektzielen nicht widersprachen.
Andererseits war im Rahmen des
bestehenden Wasserfallvorgehens die
Flexibilität gegeben, die in Projekten
von langer Dauer unabdingbar ist.
Zwei Trümpfe in einer Hand | Projektmanagement
7

Projektmanagement | Zwei Trümpfe in einer Hand
8
Während die Definition der High-Level-Anforderungen sauber und strukturiert
erfolgen muss, kommen die Vorteile von agilen Methoden in der Umsetzung
zum Tragen. Durch Scrum werden nicht nur die einzelnen Anforderungen effizienter
abgearbeitet. Vielmehr erfährt auch das Engagement jedes Einzelnen
durch dessen engen Einbezug in diese Vorgehensweise eine Steigerung.
Die Erfahrung zeigt zudem, dass durch agile Methoden nicht nur die Qualität der
technischen Anforderungsumsetzung merklich steigt, sondern auch die Ressourcenplanung
wesentlich genauer wird. Denn Scrum sieht vor, dass jeder Entwickler
täglich seinen Restaufwand selber einschätzt. Zudem werden die Eigenbeurteilungen
im Verlauf der Zeit immer besser. Ein zweckmässiger Einsatz von Scrum
kann so die Motivation und die Eigenverantwortung der Mitarbeitenden steigern
und gleichzeitig die Projektsteuerung sowie die Kontrolle auf der Ebene der Softwareentwicklung
verbessern, ohne dabei die Planungssicherheit auf der Gesamtprojektebene
zu gefährden.

Beispiel 2
Releasezyklusmanagement
Die Produkte eines Herstellers im Bereich
der Medizinaltechnik enthalten
immer mehr Software. Deren Wartung
erfordert fix definierte Releasezyklen
mit vorgegebenen Releasedaten. Auch
die Entwicklung neuer Software muss
sich an feste Termine halten, damit die
Markteinführung von den vorgeschriebenen
regulatorischen und den notwendigen
marketingbedingten Massnahmen
begleitet werden kann.
Um die definierten Daten einzuhalten,
basiert die übergeordnete Gesamtleitung
der Softwareentwicklung auf einem
herkömmlichen Wasserfallmodell mit
festgelegten Meilensteinen. Diese klare
Struktur hilft zudem, die strengen Anforderungen
im regulierten Umfeld zu
erfüllen.
Während die Definition der High-Level-
Anforderungen sauber und strukturiert
erfolgen muss, kommen die Vorteile
von agilen Methoden in der Umsetzung
zum Tragen. Durch Scrum werden nicht
nur die einzelnen Anforderungen effizienter
abgearbeitet. Vielmehr erfährt
auch das Engagement jedes Einzelnen
durch dessen engen Einbezug in diese
Vorgehensweise eine Steigerung.
Die Erfahrung zeigt zudem, dass durch
agile Methoden nicht nur die Qualität
der technischen Anforderungsumset-
zung merklich steigt, sondern auch die
Ressourcenplanung wesentlich genauer
wird. Denn Scrum sieht vor, dass jeder
Entwickler täglich seinen Restaufwand
selber einschätzt. Zudem werden die
Eigenbeurteilungen im Verlauf der Zeit
immer besser. Ein zweckmässiger Einsatz
von Scrum kann so die Motivation
und die Eigenverantwortung der Mitarbeitenden
steigern und gleichzeitig die
Projektsteuerung sowie die Kontrolle
auf der Ebene der Softwareentwicklung
verbessern, ohne dabei die Planungssicherheit
auf der Gesamtprojektebene zu
gefährden.
Philip Lehmann
Kontakt: philip.lehmann@erni.ch
Beratertätigkeit:
Project Management,
Business Process Improvement
Thomas Bigler
Kontakt: thomas.bigler@erni.ch
Beratertätigkeit:
Project Management,
Requirements Engineering.
Zwei Trümpfe in einer Hand | Projektmanagement
9

Mitarbeiterentwicklung | Vom Wissen zum Können
Vom Wissen zum Können
Wie durch Mitarbeiterentwicklung Mehrwert generiert wird
Investitionen in die Mitarbeiterentwicklung sind für innovationsgetriebene Technologiefirmen und für Dienstleistungsunternehmen
essenziell. Umso wichtiger ist die Qualität der Massnahmen. Es genügt nicht, wenn Trainingskonzepte an die
speziellen Bedürfnisse der Firma angepasst sind und stufengerecht erfolgen. Entscheidend ist vielmehr, ob die Ergebnisse
langfristig in der Organisation verankert werden. Von Alain Gayret, David Kurmann und Silvio Tarreghetta
10

«Der beste Weg in die Zukunft ist, in Menschen
zu investieren.» Diesen Leitsatz des
deutschen Publizisten und Buchautors
Erik Händeler (Die Geschichte der Zukunft 1)
kann wohl jeder Verantwortliche eines
Unternehmens unterschreiben, dessen
Marktleistungen zu einem wesentlichen
Teil durch Wissensarbeit geprägt sind.
Entsprechend viel investieren Dienstleistungsorganisationen
und innovationsgetriebene
Technologiefirmen in die
Weiterbildung und Entwicklung ihrer
Mitarbeitenden. Gemäss dem Bundesamt
für Statistik haben 2009 fast 42 Prozent
der Erwerbstätigen eine berufliche Weiterbildung
absolviert. Bei den Berufstätigen
mit höherer Schulbildung waren es gar
über 60 Prozent.
Mit der im globalen Wettbewerb ständig
weiter wachsenden Komplexität von Produktentwicklungen,
Lieferketten, Herstel-
1Erik Händeler… Die Geschichte der Zukunft.
Sozialverhalten heute und der Wohlstand von morgen. Brendow, 2005.
lungsprozessen sowie Informatik- und
Kommunikationsprojekten steigt der Trainingsbedarf
immer weiter an. Umso wichtiger
wird es, sicherzustellen, dass das vermittelte
Wissen im Unternehmensalltag
auch Mehrwerte generiert.
Der wachsenden Komplexität können Standard-Schulungskonzepte
je länger, je weniger
gerecht werden. Die Erfahrung zeigt,
dass mit Konzepten, die für die spezifische
Situation und die entsprechende Organisation
massgeschneidert sind, ein wesentlich
grösserer Nutzen erzielt werden kann.
Um sowohl den Bedürfnissen des einzelnen
Mitarbeiters als auch denjenigen der
ganzen Organisation gerecht zu werden,
muss sich die Weiterbildung an der mehrstufigen
Kompetenzpyramide (siehe Abb. 1)
orientieren. Deren Fundament bildet das
«Kennen», das theoretische Wissen. Aus
Vom Wissen zum Können | Mitarbeiterentwicklung
der Theorie wird in einer zweiten Stufe
durch praktische Übungen das «Können»,
bei dem Wissen selbständig angewendet
werden kann. In einer dritten Stufe steigert
das Training unterschiedlicher Varianten
die einfache Anwendung zu einem begründeten,
konstruktiven Umgang mit den
Methoden («Vermitteln»). Die Spitze der
vierstufigen Pyramide bildet die Fähigkeit,
Methoden, Theorien und Anwendungspraktiken
zu bewerten, kritisch zu hinterfragen
und zu evaluieren («Beraten»).
Das Erreichen jeder dieser vier Stufen
setzt spezifische Trainingsmethoden voraus.
Aus Unternehmenssicht macht es jedoch
wenig Sinn, alle Mitarbeitenden auf
die höchste Kompetenzstufe zu bringen.
Im Alltag nicht angewandtes Wissen geht
erfahrungsgemäss schnell wieder verloren
und damit auch die Investition, die nötig
war, um es aufzubauen. Zur Zieldefinition
11

Mitarbeiterentwicklung | Vom Wissen zum Können
Mit der im globalen Wettbewerb ständig weiter wachsenden Komplexität von Produktentwicklungen, Lieferketten, Herstellungsprozessen
sowie Informatik- und Kommunikationsprojekten steigt der Trainingsbedarf immer weiter an. Umso wichtiger
wird es, sicherzustellen, dass das vermittelte Wissen im Unternehmensalltag auch Mehrwerte generiert. Der wachsenden
Komplexität können Standard-Schulungskonzepte je länger, je weniger gerecht werden.
12
Abb. 1:
Kompetenzpyramide
Abb. 2:
Kompetenzbereiche Project
Management Training
1.
Projektstart
2.
3.
4.
Beraten
Vermitteln
Können
Kennen
Risiko-
management
Kosten
&
Finanzen
Anforderungen
&
Ziele
Stakeholder-
management
Schätzung
Struktur,
Organisation
& Prozesse
1. Kennen = theoretisches Wissen und Verstehen
Beschreiben, verstehen, definieren, Einsatzmöglichkeiten
erklären, gliedern, strukturieren, Zusammenhänge
erkennen, nachvollziehen.
2. Können = Anwenden
Einmalig anwenden, umsetzen, benützen,
erarbeiten, einsetzen, verwenden, unterscheiden.
3. Vermitteln = Begreifen und konstruktives Umgehen
Mehrmalig anwenden, analysieren, ableiten,
folgern, entwickeln, konstruieren, Alternativen
erarbeiten, vergleichen und abwägen, kritisch
überprüfen, transparent/nachvollziehbar entwickeln,
begründen.
4. Beraten = Beurteilen und Evaluieren
Beraten, kritisch hinterfragen, reviewen, beurteilen,
Expertise erstellen, gewichten, bewertend ableiten,
übergeordnet betrachten.
Qualitäts-
management
Projektplanung
Ressourcenmanagement
Controlling
& Reporting
Führung
& Konfliktmanagement
Konfigurations-
& Changemanagement
Projektende

im Vorfeld eines Trainings gehört deshalb
auch die Festlegung, welche Mitarbeitenden
für eine effiziente Arbeit welches
Kompetenzniveau benötigen.
Beispiel 1
Entwicklungsprozesse im medizintechnischen
Umfeld optimieren
Die Entwicklungsprojekte eines Herstellers
von medizinischen Hilfsmitteln müssen
den ständig wachsenden Marktanforderungen
gerecht werden. Zum einen
müssen die kundenbezogenen Unternehmensbereiche
und die verschiedenen
technischen Abteilungen möglichst effizient
zusammenarbeiten, zum anderen gilt
es, auch externe Partner und wirtschaftliche
Rahmenfaktoren immer stärker einzubeziehen.
Deshalb entschieden sich die
Verantwortlichen zu einer Verbesserung
in Teilbereichen des abteilungsübergreifenden
Projektmanagements.
In der Planungsphase wurden zunächst die
genauen Bedürfnisse des Unternehmens
eruiert. Daraus wurde der Ausbildungsbedarf
bestimmt. Nun folgte die Entwicklung
eines dreistufigen Trainingskonzepts
mit dem Ziel, sowohl die Fähigkeiten der
gesamten Organisation als auch diejenigen
der einzelnen Mitarbeitenden entsprechend
ihren Verantwortlichkeiten auf den
benötigten Stand zu bringen.
In einem ersten Schritt galt es, den theoretischen
Wissensstand in den erforderlichen
Kompetenzbereichen (siehe Abb. 2)
und das Verständnis aller Beteiligten auf
ein gleichmässiges Niveau zu heben. Der
Weg dazu führte über eine Mischung aus
herkömmlichem Frontalunterricht und
stufengerechten Übungen. Die Umsetzung
der Theorie wurde in einem zweiten
Schritt projektspezifisch sichergestellt.
Dazu dienten Workshops, die an
die spezifische Unternehmenssituation
und an die tatsächlichen Bedürfnisse der
einzelnen Funktionsstufen angepasst
waren. Ein regelmässiges Coaching während
der ersten Monate stellte in einer
dritten Trainingsstufe die Verankerung
des Gelernten im Arbeitsalltag sicher.
Dabei überprüfte der Trainer in monatlichen
Sitzungen mit jedem Mitarbeiter
unterstützend die konkrete Umsetzung
der neuen Abläufe. Er sorgte also aktiv
dafür, dass das Gelernte umgesetzt, angewendet
und permanent verankert wurde.
Beispiel 2
Struktur von Softwareentwicklungs-
prozessen verbessern
Ein grosses Versicherungsunternehmen
war gefordert, den massiv gestiegenen
Anforderungen an die Funktionalität und
die Qualität der Applikationen langfristig
gerecht zu werden. Es hat deshalb die
Struktur seiner Softwareentwicklungsprozesse
verfeinert. Insbesondere schuf es an
der Schnittstelle zwischen Business und
IT spezialisierte Rollen für eine effiziente
Anforderungsentwicklung.
Dafür galt es nicht nur die entsprechenden
Mitarbeitenden in ihrer neuen Funktion
zu schulen. Auch die ganze Organisation
musste für die verbesserten Prozesse fit
gemacht werden. Durch ein Coaching in
der ersten praktischen Umsetzungsphase
und die Etablierung von Erfahrungsgruppen
gelang es, die neuen Prozesse schnell
und langfristig zu etablieren.
Ein Fitnesscheck der ganzen Organisation
in Bezug auf die geplanten Änderungen
bildete den Ausgangspunkt des Trainingskonzepts.
Dabei wurden unter anderem
in einem persönlichen Assessment
die vorhandenen Fachkompetenzen erfasst.
Danach wurde in Lernzielen festgelegt,
welche Mitarbeitenden welche
Kompetenzstufe innerhalb welcher Frist
erreichen müssen. Anhand des individuellen
Trainingsbedarfs und der zeitlichen
Priorität konnte für jeden Einzelnen ein
massgeschneidertes Coachingprogramm
erarbeitet werden.
In dessen Rahmen erlernten die beteiligten
Mitarbeitenden die neuen Abläufe
mit individuellen Zielvorgaben im Arbeitsalltag.
Mit dem Ziel einer langfristigen,
selbständigen Prozessoptimierung
der Organisation wurden parallel zum
Vom Wissen zum Können | Mitarbeiterentwicklung
13

Mitarbeiterentwicklung | Vom Wissen zum Können
14
Schulung
Um sowohl den Bedürfnissen des einzelnen Mitarbeiters als auch denjenigen der
ganzen Organisation gerecht zu werden, muss sich die Weiterbildung an der
mehrstufigen Kompetenzpyramide (siehe Abb. 1) orientieren. Deren Fundament
bildet das «Kennen», das theoretische Wissen. Aus der Theorie wird in einer zweiten
Stufe durch praktische Übungen das «Können», bei dem Wissen selbständig
angewendet werden kann. In einer dritten Stufe steigert das Training unterschiedlicher
Varianten die einfache Anwendung zu einem begründeten, konstruktiven
Umgang mit den Methoden («Vermitteln»). Die Spitze der vierstufigen Pyramide
bildet die Fähigkeit, Methoden, Theorien und Anwendungspraktiken zu bewerten,
kritisch zu hinterfragen und zu evaluieren («Beraten»).
Das Erreichen jeder dieser vier Stufen setzt spezifische Trainingsmethoden voraus. Aus Unternehmenssicht
macht es jedoch wenig Sinn, alle Mitarbeitenden auf die höchste Kompetenzstufe
zu bringen. Im Alltag nicht angewandtes Wissen geht erfahrungsgemäss schnell
wieder verloren und damit auch die Investition, die nötig war, um es aufzubauen. Zur
Zieldefinition im Vorfeld eines Trainings gehört deshalb auch die Festlegung, welche Mitarbeitenden
für eine effiziente Arbeit welches Kompetenzniveau benötigen.

Coaching Erfahrungsgruppen gebildet,
in denen die erarbeiteten «guten Beispiele»
teamübergreifend vorgestellt werden
und die unternehmensinterne Praxis
laufend weiterentwickelt wird.
Beispiel 3
Prozesse vereinheitlichen
Ein grösserer Finanzdienstleister will zur
Vereinheitlichung seiner Prozesse den Organisationsgrad
der Softwareentwicklung
erhöhen. Das dafür notwendige, umfangreiche
Trainingsvorhaben basierte auf
einer Kombination aus synchronen und
asynchronen Lerneinheiten.
In einer ersten Phase ging es darum, die
Einzelkompetenzen auf ein gleichmässiges
Niveau zu heben. Dafür kamen webbasierte
Trainingsmethoden zum Einsatz, bei denen
jeder Mitarbeiter mit Hilfe von rollenspezifischen
Lernmodulen den verlangten
Wissensstand selbständig (asynchron)
erarbeitete. Darauf wurden die Mitarbeitenden
in praxisorientierten Lerngruppen
gemeinsam (synchron) durch einen Trainer
weiterentwickelt.
Dieses Coaching liess viel Platz für
Übungen und für den moderierten Erfahrungsaustausch
unter den Mitarbeitenden.
Das aktive Einbinden der Mitarbeitenden
mit ihren Praxiserfahrungen führte zu einer
besseren Verankerung der Abläufe in
der Unternehmenskultur. Die eingesetzten
Workshop-Methoden unterstützten
dies zusätzlich.
Lessons Learned
Der Erfolg von Trainings hängt fundamental
vom Engagement der beteiligten
Mitarbeitenden sowie von der schnellen
Verankerung des Erlernten im Arbeitsalltag
ab. Ein Trainingskonzept muss diese
zwei Erfolgsfaktoren gezielt unterstützen.
Ein massgeschneidertes Training fördert
das Mitarbeiterengagement, denn es trägt
den individuellen Bedürfnissen des Einzelnen
Rechnung und ermöglicht ihm
schnelle Erfolgserlebnisse, wobei der Trainingsinhalt
mit Beispielen aus der Praxis
geübt werden muss.
Ein entscheidender Motivationsfaktor ist
zudem der Trainer. Er muss nicht nur über
die notwendige Fachkompetenz verfügen,
sondern auch professionelle didaktische
und überdurchschnittliche soziale Kompetenzen
mitbringen, um die Lernenden
aus ihren Reserven locken und dafür sorgen
zu können, dass sie die Verantwortung
für ihre Weiterentwicklung selber
übernehmen. Wichtig ist dabei, dass die
Teilnehmenden nicht nur erfahren, was
sie alles noch nicht können, sondern sich
auch bewusst werden, welche Methoden
sie bereits beherrschen und erfolgreich
einsetzen.
Für die Verankerung der Kompetenzen
im Unternehmen sind längerfristige Aktivitäten
wie ein Coaching in der ersten
Umsetzungsphase und die Etablierung
von Erfahrungsgruppen oder Lernzirkeln
notwendig. Dies gilt umso mehr, wenn
etwa durch Verbesserungen im Projektmanagement
ganze Organisationseinheiten
weiterentwickelt werden müssen.
Gerade in diesem Fall zeigt sich: Ohne ein
differenziertes und professionell durchgeführtes
Training versanden theoretisch
vermittelte Verbesserungen schnell im
Alltagstrott – und die Investition verpufft.
Die Anwendung des Gelernten ist
einzufordern.
Alain Gayret
Kontakt: alain.gayret@erni.ch
Beratertätigkeit:
Project Management,
Coaching und Training
Silvio Tarreghetta
Kontakt: silvio.tarreghetta@erni.ch
Beratertätigkeit:
Process Improvement,
Requirements Engineering,
Project Management
David Kurmann
Kontakt: david.kurmann@erni.ch
Beratertätigkeit:
Training und Coaching,
in Process Improvement,
Requirements Engineering
Vom Wissen zum Können | Mitarbeiterentwicklung
15

Requirements Engineering | Den Röstigraben überwinden
Den Röstigraben überwinden
Wie Business und Technik die gegenseitige Verständigung verbessern
Business und Technik sprechen quasi von Natur aus unterschiedliche Sprachen. Eine effektive Verständigung wird möglich
durch definierte Verantwortliche auf beiden Seiten, gemeinsame Methoden, einheitliche Softwarewerkzeuge und
eine institutionalisierte Kommunikation. Von Sascha Nussbaumer und Marco Stöckli
16
Mit dem Marketing, der Strategie der
Geschäftsleitung, dem Verkauf und den
Anwendern definieren verschiedene Anspruchsgruppen
Anforderungen an Produkte,
IT-Anwendungen oder Businessprojekte.
Unternehmen bemühen sich,
bei dieser Vielfalt von Stakeholdern den
Umsetzungsprozess effektiv zu strukturieren.
Die meisten definieren deshalb eine
klare Rollenteilung zwischen der Businessseite
und den Abteilungen, die die
Anforderungen technologisch oder fachlich
in Projekten umsetzen. Doch häufig
sind die Grenzen zu starr gezogen – und
darunter leidet die Kommunikation zwischen
Business und Technik. Die Folge
sind kostspielige Zusatzarbeiten, wenn
das Produkt die Anforderungen nicht im
ursprünglichen Sinn des Business erfüllt
oder wenn technische Barrieren erst in
einem späten Projektstadium erkannt
werden.
Kommunikationsprobleme zwischen Business
und Technik gehören erfahrungsgemäss
zu den grössten Stolpersteinen in
Entwicklungsprojekten. Das hat einen
einfachen Grund: Die Spezialisten in den
beiden Bereichen sprechen unterschiedliche
Sprachen. Sie kommen aus verschiedenen
Fachgebieten, die sich sowohl
in der Ausbildung wie auch in der praktischen
Arbeit kaum überschneiden. Und
auch die persönlichen Interessen sind
unterschiedlich ausgerichtet. Dieser Graben
lässt sich nicht einfach aus der Welt
schaffen. Mit geeigneten Massnahmen
und Strukturen kann er aber überwunden
werden.
So hilft beispielsweise eine über die ganze
Dauer des Produkt-Entwicklungsprozesses
institutionalisierte Kommunikation
zwischen der geschäftlichen und der
technischen Seite, Fehlentwicklungen
aufgrund von Missverständnissen frühzeitig
zu erkennen. Damit die Verständigung
klappt, genügt es aber nicht, klare
Abläufe zu schaffen sowie auf beiden
Seiten die Rollen und Kompetenzen der
Verantwortlichen zu definieren. Wichtig
ist vielmehr auch die Etablierung von
einheitlichen Softwarewerkzeugen und
Methoden zur beidseitigen Verwaltung
der Anforderungen sowie der Lieferobjekte.
Zudem darf sich die Kommunikation
nicht auf die blosse Übergabe und
Abnahme der Aufträge beschränken,
sondern muss vom Projektstart an als periodisch
festgelegter Dialog institutionalisiert
werden.

Den Röstigraben überwinden | Requirements Engineering
Kommunikationsprobleme zwischen Business und Technik gehören erfahrungsgemäss zu
den grössten Stolpersteinen in Entwicklungsprojekten. Das hat einen einfachen Grund:
Die Spezialisten in den beiden Bereichen sprechen unterschiedliche Sprachen.
17

Requirements Engineering | Den Röstigraben überwinden
So hilft beispielsweise eine über die ganze Dauer des Produktentwicklungsprozesses institutionalisierte Kommunikation zwischen der
geschäftlichen und der technischen Seite, Fehlentwicklungen aufgrund von Missverständnissen frühzeitig zu erkennen. Damit die Verständigung
klappt, genügt es aber nicht, klare Abläufe zu schaffen sowie auf beiden Seiten die Rollen und Kompetenzen der Verantwortlichen
zu definieren. Wichtig ist vielmehr auch die Etablierung von einheitlichen Werkzeugen und Methoden zur beidseitigen Verwaltung der
Anforderungen sowie der Lieferobjekte.
18
Abb. 1:
Der Weg von der Geschäftsstrategie
zur Systemspezifikation
Abb. 2:
Handshake zwischen Business Analyst und Requirements
Engineer während der Anforderungsspezifikation
Projektteam
Requirements Analysis & Specifications
Business Analyst
Business
Requirements
Customer
Requirements
Product
Requirements
��
Technical
Requirements
Subsystem
Specifications
Requirements Engineer
Abt. 1
Team 1
Team 2
Business
Validation
Validation
Validation
Verification
System Engineering
Business Geschäftsstrategie
Fachliche Stakeholder
CEO
Abt. 2 Abt. 3
Business Analyst (Business)
��
IT
Team 1
Requirements Engineer (IT)
Technische Stakeholder
Geschäftsprozesse
Product
Integrated
Systems
System
Components
Subsystem
Business Requirements
�
Use Cases
System Requirements
System Specifications
Detaillierungsgrad
System Development & Testing

Beispiel 1
Flexible und geschäftsnahe IT-Systeme
Ein Personentransportunternehmen steht
unter einem wachsenden Konkurrenzdruck.
Nicht nur diverse Anbieter, sondern
auch verschiedene Transportmittel wie
Flugzeug, Eisenbahn, Bus oder Auto buhlen
um die gleichen Kunden. Der Preisdruck
wächst, und das Unternehmen ist
deshalb unter anderem auf flexible Preissysteme
angewiesen, mit denen es schnell
auf neue Kundenbedürfnisse oder eine
sich ändernde Nachfrage reagieren kann.
Der Schlüssel dafür sind entsprechend
flexible und geschäftsnahe IT-Systeme.
Das Unternehmen hat dies erkannt und
darum auch schon länger Anforderungsmanagementprozesse
mit einem hohen
Reifegrad etabliert.
In einem Verbesserungsschritt sollte nun
die Kommunikation an der Schnittstelle
zwischen IT und Business optimiert werden.
Dabei galt das Hauptaugenmerk dem
Aufbau einer konstanten Kommunikation
zwischen den verantwortlichen Business
Analysten auf der fachlichen Seite und
den Requirements Engineers auf der IT-
Seite, und das über den ganzen Projektverlauf
hinweg. Dies wurde durch die
Etablierung von festen Abläufen sowie
einheitlichen Methoden und Werkzeugen
erreicht.
Heute beginnt ein Entwicklungsprojekt
mit einer Analyse der Anforderungen auf
der Basis des aktuellen Geschäftsprozessmodells
des ganzen Unternehmens. Anhand
einer Checkliste wird die Relevanz
der einzelnen Unternehmensprozesse
für das geplante Projekt in einer Anforderungsmanagementsoftware
im Detail
erfasst. So wird sichergestellt, dass alle
Systemgrenzen sauber definiert sind und
keine Bereiche oder Abteilungen vergessen
gehen. Zudem hilft der anfängliche
Fokus auf die Gesamtgeschäftsprozesse,
bei der nachfolgenden Anforderungsdefinition
die übergeordneten Ziele im Auge
zu behalten.
Ausgehend von der Prozessbeschreibung
holt der Business Analyst die Anforderungen
der einzelnen Bereiche bei den
entsprechenden Stakeholdern ab (siehe
Abb. 1). Er lässt sie in Workshops aggregieren
und in einem standardisierten Template
in der Anforderungsmanagementsoftware
erfassen. Das Template übergibt
er dem Requirements Engineer auf der IT-
Seite. Dieser analysiert die Anforderungen
auf Basis der Informatiksysteme und versucht,
alle Interaktionen anhand von Use
Cases abzubilden. Erkennt er Widersprüche,
technische Barrieren oder zu unpräzise
formulierte Anforderungen, gehen
diese zurück an den Business Analysten.
Den Röstigraben überwinden | Requirements Engineering
19

Requirements Engineering | Den Röstigraben überwinden
20

Dabei verwenden Business Analyst und
Requirements Engineer über die ganze
Projektdauer hinweg, die gleiche zentrale
Software.
Beispiel 2
Analyse mit Stakeholdermanagement
Ein internationales Unternehmen, das
auf die Entwicklung von medizinischen
Analysegeräten spezialisiert ist, plant die
Weiterentwicklung eines bestehenden
Gerätetyps für spezifische Messungen.
Bei diesem Erweiterungsprojekt ist es entscheidend,
bereits bei der Anforderungs-
analyse alle relevanten Stakeholder einzubinden
(Product Management, Endkunden,
Geräteentwicklung, Produktion etc.).
Die Herausforderung besteht darin, die
unterschiedlichen Ansprüche aller Stakeholder
frühzeitig zu erkennen und
optimal aufeinander abzustimmen. Dies
verlangt ein strukturiertes Vorgehen und
eine intensive Kommunikation an der
Schnittstelle zwischen Business und Technik.
Zu diesem Zweck wird das Projekt in
zwei Teile gegliedert: Das erste Teilprojekt
befasst sich mit den businessnahen
Anforderungen wie z.B. der Analyse der
Kundenansprüche. Dafür ist der Business
Analyst verantwortlich. Bereits in dieser
Phase ist eine erste Abstimmung mit den
entwicklungsnahen Anspruchsgruppen
erforderlich, denn so können technische
Barrieren frühzeitig identifiziert werden.
Im zweiten Teilprojekt leitet der Requirements
Engineer aus den Businessanforderungen
die System- und Softwareanforderungen
ab. Er baut dabei auf die
Vorarbeit des Business Analysten auf. Da
die Vorwärts- und Rückwärtsverfolgbarkeit
aller Anforderungen über die Grenzen
der Schnittstelle zwischen Business und
Technik hinaus gewährleistet sein muss,
kommt eine von beiden Seiten gemeinsam
genutzte Verwaltungssoftware zum Einsatz.
Zusätzlich zur softwaretechnischen
Unterstützung wird eine intensive, frühzeitige
und fortlaufende Kommunikation
zwischen dem Business Analysten und
dem Requirements Engineer etabliert.
Sascha Nussbaumer
Kontakt: sascha.nussbaumer@erni.ch
Beratertätigkeit:
Businessanalyse,
Requirements Engineering
Marco Stöckli
Kontakt: marco.stoeckli@erni.ch
Beratertätigkeit: Businessanalyse,
Requirements Engineering,
Geschäftsprozessmanagement
Den Röstigraben überwinden | Requirements Engineering
Ausgehend von der Prozessbeschreibung holt der Business Analyst die Anforderungen
der einzelnen Bereiche bei den entsprechenden Stakeholdern ab. Er lässt
sie in Workshops aggregieren und in einem standardisierten Template in der Anforderungsmanagementsoftware
erfassen. Das Template übergibt er dem Requirements
Engineer auf der IT-Seite.
Dieser analysiert die Anforderungen auf Basis der Informatiksysteme und versucht,
alle Interaktionen anhand von Use Cases abzubilden. Erkennt er Widersprüche,
technische Barrieren oder zu unpräzise formulierte Anforderungen, gehen
diese zurück an den Business Analysten. Dabei verwenden Business Analyst und
Requirements Engineer über die ganze Projektdauer hinweg, die gleiche zentrale
Software.
21

Testing | Die Qualität nachhaltig steigern
Die Qualität nachhaltig steigern
Was klare Verantwortlichkeiten und Automatisierung ausmachen können
Softwarequalität lässt sich nicht einfach an die Testingabteilung delegieren. Für eine minimale Fehlerrate müssen auch das
Business und die Entwickler ihren Teil der Verantwortung übernehmen. Eine Automatisierung kann die Qualität zusätzlich
erhöhen und den Aufwand senken. Von Marcel Stoop und Severin Dietschi
22
Applikationsfehler oder Anforderungsumsetzungen,
die nicht den Erwartungen
entsprechen, kosten viel Zeit,
Geld und Kundenvertrauen. Dabei lassen
sie sich zu einem grossen Teil vermeiden,
wenn alle Beteiligten ihren Teil der Verantwortung
übernehmen. Die Verantwortung
für die Endabnahme obliegt
dabei in jedem Fall der auftraggebenden
Fachabteilung. Genauso haben die Entwickler
ihren Teil der Qualitätssicherung
zu übernehmen: Sie müssen die Funktionen
in den einzelnen Programmabläufen
überprüfen und deren Integration
sicherstellen. Die Testingabteilung ist für
die umfassende Funktionsüberprüfung
auf der Systemebene zuständig.
Wirklich effektiv werden die klar definierten
Verantwortlichkeiten und
Abläufe, wenn zusätzlich über die Abteilungsgrenzen
hinweg produktiv zusammengearbeitet
wird. So zeigt sich
etwa, dass ein erster Review der vom
Business formulierten Requirements
durch das Testing und die Entwicklungsabteilung
hilft, Missverständnissen vorzubeugen.
Auf diese Weise können insbesondere
unpräzise Formulierungen in
einer frühen Phase geklärt werden. Auf
der anderen Seite muss das Testing sein
Know-how zur Produktqualität beitragen.
Dies ist umso wichtiger, als ein kompetentes
Testing ein spezielles Denken
voraussetzt. Der Tester will möglichst
jeden Fall finden, mit dem er einen Fehler
provozieren kann. Dieses destruktive
Denken widerspricht grundsätzlich dem
konstruktiven Mindset, mit dem Business
und Entwicklung ihre Projekte vorantreiben.
Ein wichtiges Werkzeug zur Sicherstellung
der gleichbleibenden Qualität der
Tests ist die Automatisierung. Zudem
entlastet sie die Tester von wenig motivierenden,
repetitiven Aufgaben. Bereits
ab zehn Wiederholungen rechnet sich
im Durchschnitt der für die Automatisierung
notwendige Initialaufwand. Vor
allem Regressionstests zur Überprüfung
der Nebenwirkungen einer Modifikation
auf die Grundfunktionen in einem neuen
Release können so sicher und schnell
durchgeführt werden.
Beispiel 1
Testing nach Releasewechsel
In einer Applikation eines grossen Finanzdienstleisters
häufen sich bei Releasewechseln
die Fehler. Die Verantwortlichen
beschliessen darauf, den
Testingprozess auf Schwachstellen zu
untersuchen und entsprechend zu verbessern.
Die Analyse zeigte, dass viele

Die Qualität nachhaltig steigern | Testing
Ein wichtiges Werkzeug zur Sicherstellung der gleichbleibenden Qualität der Tests ist die
Automatisierung. Zudem entlastet sie die Tester von wenig motivierenden, repetitiven
Aufgaben. Bereits ab zehn Wiederholungen rechnet sich im Durchschnitt der für die
Automatisierung notwendige Initialaufwand.
23

Testing | Die Qualität nachhaltig steigern
24
Um die Qualität der Software nachhaltig zu steigern, wurde in der Folge der festgeschriebene
Testingprozess verfeinert. Der Softwareentwicklung, dem Testing und den Geschäftsabteilungen
wurden genau definierte Verantwortlichkeiten übertragen, die jeweils ihren Ebenen entsprachen.
Dabei müssen die Entwickler und die Tester einen gründlichen Review der Anforderungen durchführen,
sobald der Fachbereich die Requirements formuliert hat. Um sicherzustellen, dass die
Tester alle gewünschten Anforderungen mit validen Testcases abgedeckt haben, wurde zudem
eine engere Zusammenarbeit zwischen Testing und Business verankert. Dabei nimmt die auftraggebende
Fachabteilung neu einen Review der Testcases vor.
Die Verantwortung für die Endabnahmetests liegt neu mittels einer Unterschriftserklärung explizit
beim Business. Zu dessen Aufgaben gehört auch die Formulierung eigener Testcases zur Prüfung
der richtigen Anforderungsumsetzung. Das so etablierte Mehraugenprinzip trägt entscheidend zur
Qualitätssteigerung bei. Die Testingabteilung steht dem Business bei seinen Prüfungen unterstützend
zur Seite.
Abb. 1:
Informationsrückfluss und Klärung
dank präziser Sprache
allgemein verständlich (abnehmend nach unten)
natürliche Sprache
(mündliche Kommunikation,
schriftliche Prosa)
formalisierte Sprache
(schriftlich festgehaltene technische
Anforderungen)
Interpretationsspielraum (nach rechts abnehmend)
Fehler,
Ungenauigkeiten,
Ungewissheiten
stark formalisierte Sprache
(Programmiersprache für automatisierte
Tests)
Eindeutigkeit (nach rechts zunehmend)

der Fehler auf Missverständnisse zurückzuführen
sind. Das Testing ist mit seinen
Prüfungen im guten Glauben zu positiven
Resultaten gekommen. Dass die
Anforderungen gar nicht im Sinne des
Business umgesetzt worden waren, war
für die Tester aus den Informationen, die
ihnen zur Verfügung standen, nicht eindeutig
ersichtlich.
Um die Qualität der Software nachhaltig
zu steigern, wurde in der Folge der
festgeschriebene Testingprozess verfeinert.
Der Softwareentwicklung, dem
Testing und den Geschäftsabteilungen
wurden genau definierte Verantwortlichkeiten
übertragen, die jeweils ihren
Ebenen entsprachen. Dabei müssen
die Entwickler und die Tester einen
gründlichen Review der Anforderungen
durchführen, sobald der Fachbereich
die Requirements formuliert hat. Um
sicherzustellen, dass die Tester alle gewünschten
Anforderungen mit validen
Testcases abgedeckt haben, wurde zudem
eine engere Zusammenarbeit zwischen
Testing und Business verankert.
Dabei nimmt die auftraggebende Fachabteilung
neu einen Review der Testcases
vor.
Die Verantwortung für die Endabnahmetests
liegt neu mittels einer Unterschrifts-
erklärung explizit beim Business. Zu
dessen Aufgaben gehört auch die Formulierung
eigener Testcases zur Prüfung der
richtigen Anforderungsumsetzung. Das
so etablierte Mehraugenprinzip trägt entscheidend
zur Qualitätssteigerung bei.
Die Testingabteilung steht dem Business
bei seinen Prüfungen unterstützend zur
Seite.
Beispiel 2
Optimierung der Testprozesse
Die interne Kommunikationsanwendung
eines Überwachungsunternehmens, das
sehr hohe Sicherheitsstandards erfüllen
muss, ist über die Jahre von einer einfachen
Applikation zu einer komplexen
Anwendung mit diversen Modulen gewachsen.
Um die Qualität der Software
langfristig zu gewährleisten, galt es, auch
das Testing an die gestiegenen Anforderungen
anzupassen. Die ursprünglich
sinnvollen, zu einem grossen Teil noch
mündlichen Abläufe mussten dafür in
strukturierte Prozesse überführt werden.
Zudem wurden sowohl für die Testingabteilung
als auch für die Entwickler und
für das auftraggebende Business klare
Verantwortlichkeiten definiert.
Im neuen Prozess übernimmt die Entwicklung
die Verantwortung für die einzelnen
Programmabläufe und die Inte-
Die Qualität nachhaltig steigern | Testing
25

Testing | Die Qualität nachhaltig steigern
26

gration der Komponenten. Das Testing
prüft das wunschgemässe Funktionieren
auf der Systemebene und das Business,
ob die Anforderungen in seinem Sinn erfüllt
werden. Für das Prüfen der Grundfunktionen
über alle Module und Konfigurationsmöglichkeiten
hinweg wurde
auf der Systemebene eine Automatisierung
des Testings eingeführt. Diese senkt
den Aufwand für sich wiederholende
Prüfungen markant, und es steht mehr
Zeit für die genaue Kontrolle der neu
eingeführten Funktionen zur Verfügung.
Das automatisierte Testing brachte nicht
nur eine Arbeitserleichterung. Als interessanten
Nebeneffekt förderte es auch
sehr viele Unvollständigkeiten in den
Anforderungsformulierungen zutage.
Denn im Gegensatz zum menschlichen
Tester, der kleine Unstimmigkeiten häufig
unbewusst abstrahiert, stoppt die Automatisierung
sofort, wenn das Ergebnis
nicht genau der Vorgabe entspricht.
Diese «Sturheit» trägt indirekt dazu
bei, die Qualität der Anforderungs- und
Testcase-Formulierung zu steigern. Auch
nicht kommunizierte Änderungen in
den vom Geschäftsbereich selbständig
gepflegten Business Rules, die Auswirkungen
auf die Funktion der Gesamtapplikation
haben, werden sofort sichtbar.
Die häufige Anpassung der Regeln
zwischen den Releases ist in der Praxis
eine erhebliche Fehlerquelle.
Durch die definierten Prozesse und die
Automatisierung erhält das Business das
Vertrauen, dass die Applikation auf der
Systemebene zuverlässig funktioniert.
Andererseits muss der Geschäftsbereich
im neuen Prozess mit eigenen Testcases
die Verantwortung für die Abnahmeprüfung
seiner Anforderungen selbst
übernehmen.
Marcel Stoop
Kontakt: marcel.stoop@erni.ch
Berufstätigkeit:
Testmanagement,Testdesign,
Testprozessverbesserungen
Severin Dietschi
Kontakt: severin.dietschi@erni.ch
Beratertätigkeit:
Testautomatisierung,
Testmanagementsupport
Die Qualität nachhaltig steigern | Testing
Das automatisierte Testing brachte nicht nur eine Arbeitserleichterung. Als interessanten
Nebeneffekt förderte es auch sehr viele Unvollständigkeiten in den
Anforderungsformulierungen zutage. Denn im Gegensatz zum menschlichen Tester,
der kleine Unstimmigkeiten häufig unbewusst abstrahiert, stoppt die Automatisierung
sofort, wenn das Ergebnis nicht genau der Vorgabe entspricht. Diese
«Sturheit» trägt indirekt dazu bei, die Qualität der Anforderungs- und Testcase-
Formulierung zu steigern. Auch nicht kommunizierte Änderungen in den vom
Geschäftsbereich selbständig gepflegten Business Rules, die Auswirkungen auf
die Funktion der Gesamtapplikation haben, werden sofort sichtbar. Die häufige
Anpassung der Regeln zwischen den Releases ist in der Praxis eine erhebliche
Fehlerquelle.
27

Innovation in Prozess und Technologie
ERNI Consulting AG
Talstrasse 82 · CH-8001 Zürich · Tel. +41 44 215 42 00
Casinoplatz 2 · CH-3011 Bern · Tel. +41 31 381 76 11
Bahnhofstrasse 4 · CH-6340 Baar · Tel. +41 41 227 35 00
Rue du Simplon 37 · Postfach 326 · CH-1006 Lausanne · Tel. +41 21 966 55 37
ERNI (Deutschland) GmbH
Orleansstrasse 34 · D-81667 München · Tel. +49 89 62 28 67 88 0
ERNI (Slovakia) s.r.o.
Ševcenkova 34 · SK-851 01 Bratislava · Tel. +421 2 3255 37 37
www.erni.ch/experience