Software soll zugleich wertschöpfend, kostengünstig, schnell einsetzbar und qualitativ hochwertig sein, aber auch der Entwicklungsprozess soll sich nachvollziehen lassen. Das sind die Herausforderungen vor denen Application Lifecycle Management (ALM) und agile Entwicklung als Lösungsangebote stehen.
Business Technology hat einige ALM-Lösungsanbieter zu diesen Aspekten befragt und wird in den kommenden Wochen deren Antworten veröffentlichen.
ALM-Serie
Heute: Thomas Schröder, Senior Manager Field Application Engineers, Telelogic, an IBM Company und Lothar Kappen, Senior IT Architect, IBM Rational Sales, IBM Deutschland
Lassen Sie uns gleich ins Thema Application Lifecycle Management einsteigen: Wie sieht Ihr Modell eines zeitgemäßen Application Lifecycle Managements aus?
IBM: Generell werden die Rahmenbedingungen des Application Lifecycle Management, auch ALM abgekürzt, durch aktuelle Trends bestimmt. Dazu zählen die Ausrichtung der IT an die strategischen Unternehmensziele, global verteilte Entwicklungsteams, aber auch Compliance-Aspekte. Die Einführung serviceorientierter Architekturen und die automatisierte Codegenerierung beziehungsweise die Produktlinienentwicklung sind ebenfalls wichtige Aspekte.
Jeder dieser Trends ist für den richtigen Aufbau einer ALM entscheidend, deshalb lassen Sie uns auf diese Punkte kurz eingehen: Die IT sollte sich eng an strategischen und taktischen Unternehmenszielen ausrichten. Es muss Firmen klar sein, dass ein wesentlicher Erfolgsfaktor für eine tragfähige Unternehmensarchitektur (Enterprise Architecture) die sorgfältige Steuerung (Governance) der gesamten IT und ihre Verzahnung mit den fachlichen Planungen ist. Ein weiterer Aspekt, den es zu berücksichtigen gilt, ist die zumehmende globale Verteilung der Entwicklungs- und Wartungsteams. Das heißt, ein Gesamtteam besteht aus mehreren einzelnen Teams, zusammen bilden sie so genannte Teams of Teams. Natürlich ist bei einem erfolgreichen ALM auch immer Compliance ein Thema, denn die Einhaltung interner, regulatorischer und rechtlicher Vorgaben betrifft auch das ALM. Hilfreich für ein Application Lifecycle Management mit Schwerpunkt auf Wiederverwendung ist auch die richtige SOA, sprich Service-oriented Architecture, die einer flexiblen Wiederverwendung von Services dient. Aber diese wird nur erreicht, wenn der gesamte Prozess der Anforderung, Erstellung, Dokumentation, Inbetriebnahme und Verwendung geplant, überwacht und gesteuert wird. Und damit kommen wir zum Systems Development: Die Menge der Software in technischen Produkten ist heutzutage immens. Schauen Sie sich nur einmal Produkte wie Handys oder Autos an: Die enge Integration der Entwicklung von Software, Elektronik und Mechanik ist Voraussetzung, um diese und andere Produkte schnell und in hoher Qualität auf den Markt zu bringen. In der System- und Embedded-Softwareentwicklung ist anforderungs- und modellgetriebene Entwicklung daher ein wichtiger Bestandteil eines agilen Application Lifecycles. Als letzten Trend möchten wir hier noch die automatisierte Codegenerierung und Produktlinienentwicklung, auch Software Factories genannt, erwähnen.
Diese Techniken versprechen einen deutlichen Fortschritt auf dem Weg zur Industrialisierung der Softwareentwicklung. Sie lassen sich hervorragend mit agilen Prinzipien kombinieren. Um der wachsenden Konkurrenz wie in der Automobilindustrie, Luft- und Raumfahrt sowie Telekommunikation zu begegnen, bieten wir Softwareentwicklern Werkzeuge zur modellbasierten Entwicklung durch die Generierung von Code aus UML-Modellen. Erweitert wird der Einsatz zusätzlich durch das Reverseengineering, in dem vorhandener Code in Modelle umgewandelt und dort weiter entwickelt wird.
Diese Zeichnung zeigt die Entwicklungsprozesse, basierend auf dem Rational Unified Process (RUP). Das ist ein flexibles Framework, das sich für agile Projekte eignet und sich seit seiner Einführung 1998 bereits in vielen unterschiedlichen Projekten bewährt hat. Das zentrale Element hier ist eine iterative Vorgehensweise mit einer frühen Adressierung von Projektrisiken.
Was würden Sie sagen, passen agile Methoden wie Scrum, XP, Lean etc. nun in dieses Modell?
IBM: Agile Methoden eignen sich hervorragend für die Entwicklung in kleinen Teams. Die Herausforderungen besteht darin, diese erfolgreichen Ansätze zu skalieren, so dass sie auch für größere Projekte, die umfangreicherere Dokumentation zwingend vorschreiben und die allerhöchste Qualität erfordern (z.B. Air Traffic Control Systems), nutzbringend eingesetzt werden können. Bei der Entwicklung der Eclipse-Plattform hat sich der Eclipse Way als eine Ausprägung des RUP bewährt. Auch er beinhaltet viele agile Prinzipien sowie Prinzipien der Open-Source-Entwicklung und findet Eingang in neu entwickelte Werkzeuge mit eingebauter, anpassbarer Prozessunterstützung. Wir nennen das Process Aware. Ein wesentliches Merkmal dieser neuen Entwicklerwerkzeuge ist die Unterstützung einer engen Zusammenarbeit aller Beteiligten, einschließlich des Projektmanagements.
Wie unterstützen Ihre Lösungen agile Entwicklungsprojekte?
IBM: .Auch in agilen Projekten brauchen wir Reporting – ob für Portfolio- und Projektplanung, Nachverfolgbarkeit oder Risikomanagement. Als Werkzeuge für ein automatisiertes Reporting dient Entwicklern, Testern, Analysten aber auch Projektmanagern eine prozess-sensitive Umgebung, in der Aufgaben wie gewohnt erledigt werden. Wir hatten vorhin schon kurz über die Verzahnungen zwischen den einzelnen Prozessen aus Business-, IT-, Strategie- und IT-Operations-Domänen gesprochen. Durch die Verzahnung mit dem hinterlegten Prozess werden auch hier gleichzeitig und möglichst transparent alle Daten zur Ermittlung wichtiger Kenngrößen gesammelt. Ein entscheidender Punkt bei agilen Prinzipien ist, dass sie „skaliert“ sind. Das heißt, dass sie in Projekten angewendet werden, die dafür traditionell schlecht zugänglich waren – durch große Teams, verteilte Entwicklungen, geschäftskritische Anwendungen.
Legt sich der Kunde damit auf eine Methode fest? Lassen sich beispielsweise Testing-Tools oder Projektmanagementtools einbinden?
IBM: Die IBM Rational Software Delivery Platform (SDP) ist eine offene und konfigurierbare Lösung für das gesamten ALM. Sie stellt eine eng integrierte Teaminfrastruktur bereit, mit Prozess- und Portfoliomanagement, Anforderungsmanagement, Architekturmanagement, Modellierung und Codegenerierung, Qualitätsmanagement, Change- und Release-Management.
Wie die Übersicht hier darstellt, liefert die SDP den Fachanalytikern, Testern, Entwicklern und Projektmanagern Prozessanleitungen, einen Zugriff auf gemeinsame Projektinformation wie Anforderungen, Change Requests, Code, Testpläne und Testresultate und damit einen zentralen Ort für Projektstatus und Projektkenngrößen.
Um Ihre Frage zu beantworten: Die Werkzeuge zwingen dem Anwender keinen bestimmten Prozesse auf. Sie können mit Prozessdefinitionen hinterlegt und auf den bevorzugten Prozess angepasst werden. Häufig liefern wir auch Best-Practice-Prozessdefinitionen mit, beispielsweise im Rational Method Composer, die vom Kunden übernommen werden können. Wie gesagt, die IBM Rational Software Delivery Platform (SDP) ist eine offene Lösung. Offene Schnittstellen in unseren Produkten erleichtern damit die Integration in existierende Infrastrukturen. Fertige Integrationen für einige unserer Werkzeuge vereinfachen den Übergang zu einer einheitlichen Umgebung. Allerdings bleibt zu beachten, dass die Lösungsentwicklung nicht isoliert vom Fachbereich und Betrieb gesehen werden sollte. Deswegen unterstützen wir über offene Schnittstellen die Integration mit den anderen Phasen der IT- und Governance-Prozesse und den dafür vorhandenen Werkzeugen wie unsere Tivoli- und WebSphere-Produkte. Damit kann IBM den kompletten ALM-Prozess über alle Domänen mit aufeinander abgestimmten Werkzeugen unterstützen und eine Nachvollziehbarkeit über den gesamten Zyklus erreichen.
Wo sehen Sie für ALM die Vorteile von agilen Entwicklungsprozessen und wo die Grenzen?
IBM: Sie liegen bei Lösungen, die ein Unternehmen schnell entwickeln muss, um rechtzeitig auf Marktänderungen zu reagieren. Hier steht Geschwindigkeit klar vor allerhöchster Qualität und optimaler Wiederverwendbarkeit. Wissen Sie, genauso wie eine Programmiersprache nicht alle Anforderungen abdecken kann, ist eine Vorgehensweise nicht für alle Projekte geeignet. Eine Software, die in medizinischen Apparaten oder Flugüberwachungssystemen große Verantwortung trägt, wird anders entwickelt, als eine Software für eine Community-Website. Allerdings können viele Projekte von den Ideen der agilen Entwicklung profitieren.
Entwickeln Sie selbst agil
IBM: Natürlich. Und wir benutzen dazu auch die gleichen Werkzeuge, die wir unseren Kunden verkaufen. Jazz wird mit Jazz entwickelt. Das kann jeder im Internet unter jazz.net sozusagen Live beobachten. Wir übertragen den agilen Open-Source-Prozess von Eclipse nun bei Jazz auf eine kommerzielle Entwicklung. Im Sinne eines Open Commercial Software Development werden Kunden und Partnern Schnittstellenspezifikation und Betacode frühzeitig zur Verfügung gestellt.
Wie Sie an dieser Übersicht zum Jazz-Projekt sehen, wird Jazz, anders als bei traditionellen Produktentwicklungen, offen auf jazz.net entwickelt. Das heißt, Kunden und Partner können die Entwicklung verfolgen, aktuelle Builds sofort herunterladen und so Einfluss auf Qualität und Effizienz nehmen.
Wie und warum machen Sie das?
IBM: Für IBM hat die Kombination aus agilen Methoden und Open-Source-Entwicklung unterschiedliche Vorteile: Die frühe Einbindung von Kunden und Partnern verhilft zu marktgerechteren Produkten, der Eclipse Way erhöht Termintreue und Qualität, die Unterstützung durch integrierte Werkzeuge erlaubt eine globale verteilte und dennoch agile Entwicklung in großen Teams.
