Der Artikel bei Elektroniknet behandelt die Einführung von „Application Lifecycle Management“-Werkzeugs (ALM). Software Werkzeug muss an Unternehmen angepasst werden, daher kann eine Standardlösung kaum entwickelt werden.

Hier sind individuelle Adaptionen notwendig.
Im Artikel wird anhand eines fiktiven Fallbeispiels beschrieben, welche Schritte notwendig sind um Software-Werkzeuge an ein Unternehmen anzupassen und worauf es bei der Einführung ankommt. Nachfolgend werden die wichtigen Funktionen beschrieben, wie das Arbeiten mit einer konkreten Geschichte, das Erzeugen eines Domänenmodells und die Fokussierung auf eine schnelle Umsetzung um die Akzeptanz der Nutzer zu erreichen.

• Integration aller Entwicklungsaktivitäten
  Von der Analyse der Kundenanforderungen bis hin zur Wartung. Zwischen den Aktivitäten existieren zahlreiche Abhängigkeiten:·
  • Change Request haben Auswirkungen auf Anforderungen (Requirements)· Anforderungen werden durch Testfälle geprüft
  • Die Möglichkeit diese Abhängigkeiten zu verfolgen nennt man Nachverfolgbarkeit (Traceability) und ist extrem wichtig für das Verständnis und die Beherrschung komplexer Systeme.
• Werkzeuglandschaft als gewachsene Struktur
  Über die Jahre wachsen in Unternehmen sogenannte Patchworklandschaften. Für die verschiedenen Anforderungen werden unterschiedliche Werkzeuge eingesetzt. Z.B. DOORS, Excel bis selbstentwickelte Tools, wodurch das Problem der Schnittstellen gelöst werden muss. Diese Verknüpfungen müssen manuell erstellt und gepflegt werden und sind im Projektalltag nur schwer umsetzbar. Deshalb muss ein Werkzeug eingeführt werden, das eine Verknüpfung der Schnittstellen ermöglicht. Die Firma BetterCars hat sich für das Werkzeug MKS Integrity entschieden, das anfangs mit zwei Workshops in den Projekten eingeführt wird. Teilnehmer sind eine Projekt Managerin, ein Anforderungsentwickler (Requirements Engineer), ein Test Manager aus dem Kundenprojekt und ein Qualitäts-Manager. Um ein konkretes Bild zu erhalten wird die Technik des „Story Tellings“ genutzt und konkrete Geschichten aus Benutzungsszenarien erarbeitet. Daraus ergibt sich ein Bild der Anforderungen die später die erste Realitätsprüfung für die Lösungsentwürfe sind. 
• Eine gemeinsame Sprache
  Ohne ein gemeinsames Verständnis der Konzepte und eine gemeinsame Sprache kann keine effektive Lösung gefunden werden. In einem weiteren Workshop wird daher die erste Version eines Domänenmodells erarbeitet, das bei Änderungen oder neuen Erkenntnissen aktualisiert wird. Es wird eine Liste von Funktionen definiert die sich an einzelnen Schritten aus der vorher definierten Geschichte orientiert. Z.B. „Testfall erstellen und mit Anforderungen verknüpfen“. Ausnahmen und Fehlerfälle müssen berücksichtigt werden. Diese Funktionen werden mit Aufwandschätzungen versehen und priorisiert – analog dem Product Backlog bei der Scrum-Entwicklung. Zum ersten Ausprobieren am System werden hochpriorisiert Funktionen als erstes umgesetzt. Durch resultierende Rückmeldungen kann festgestellt werden, ob die Richtung stimmt. Aufwendige Automatisierungen und Überprüfungen können warten bis das Datenmodell weitgehend stabil ist.
• Agil umsetzten
  Am Anfang der dreiwöchigen Umsetzungsiteration werden Funktionen gewählt die umgesetzt werden sollen. In der ersten Iteration sind es Funktionen wie „Anforderung erstellen“ und „Testfall erstellen und mit Anforderungen verknüpfen“. Diese werden mit den ausgewählten Anwendern detailliert und jeweils eine User Story über die Benutzung des ALM-Werkzeugs als Gesamtbild erstellt. Das Domänenmodell wird durch einen noch nicht berücksichtigten Kommentar, der ein wichtiges Anforderungsattribut darstellt, überarbeitet. Anschließend wird eine Spezifikation erstellt, womit die erste Version des Datenmodells implementiert werden kann. Diese wird von dem Werkzeughersteller auf Probleme hinsichtlich der Leistungsfähigkeit im Betrieb kontrolliert. Bei einem positiven Ergebnis kann mit der Umsetzung begonnen werden. Die erste Version kann ausgewählten Anwendern vorgestellt und alle Mängel werden für die nächste Iteration aufgenommen und eingebracht. Nach drei Monaten ist die Kernfunktion umgesetzt und kann in einem ersten Pilotprojekt, ein kleines Entwicklungsprojekt eingesetzt werden. Die Rückmeldungen aus dem Pilotprojekt zeigen, dass die Grundkonzepte der Lösung tragfähig sind. Alle fehlenden Anforderungen werden in eine Liste aufgenommen, priorisiert und in den nächsten Wochen realisiert.
• Vorbereitung und Einführung
  Alle Rückmeldungen fließen in die Verbesserung der Lösung ein und Benutzer mit dringend nötigen Änderungen versorgt. Zeitgleich wird an Trainingsmaterialen und einem Benutzerhandbuch gearbeitet. Nach zwei Monaten sehen alle Beteiligten keine Probleme mehr und die unternehmensweite Einführung nach Plan kann beginnen. Dies muss allerdings schrittweise erfolgen, da wieder Rückmeldungen von den Benutzern erwartet werden und die Entwicklung schnell überfordert ist. Zu jeder neuen Version gibt es eine Änderungsbeschreibung für alle Nutzer. Zunächst werden alle auf die neuen Lösungen und danach auf die länger laufenden Projekte umgestellt. Auch hier ist es wichtig schrittweise vorzugehen, da der Aufwand für Training, Migration und Unterstützung der Projekte nicht gleichzeitig erbracht werden kann.

Außerdem werden in dem Artikel Goldene Regeln für eine Software Einführung aufgeführt:

• Immer mit konkreten Szenarien arbeiten.
• Analyse-Paralyse vermeiden.
• Das Domänenmodell ist ein lebendes Dokument, das immer aktuell gehalten werden muss
• „Dont fight the tool.“
• „Keep it simple.“
• Hinterfragen der Anforderungen der Benutzer.
• Aktive Kommunikation.
• Von Zeit zu Zeit neue Personen einbinden, damit keine Betriebsblindheit entsteht.
• Die Einführung mit freiwilligen Projekten beginnen.
• Definieren einer Architektur
• Die Umsetzung mit dem Kerndatenmodell beginnen.
• Bedenkenträger müssen ernst genommen werden – aber nicht zu ernst!

Habe ich Ihr Interesse geweckt. Ich freue mich auf Ihre Meinung.