Team Foundation Server bei Siemens Healthcare im weltweiten Einsatz

Inhaltsverzeichnis

Entwicklungsumgebungen wie der Team Foundation Server unterstützen große verteilte Entwicklungsorganisationen. heise Developer zeigt, wie SYNGO, ein Geschäftsgebiet von Siemens Healthcare, den TFS eingeführt hat, und berichtet über Erfahrungen im Einsatz.

Entwicklungsorganisationen in der Medizintechnik sind ständig gezwungen, die Zusammenarbeit – auch über Landesgrenzen hinweg – effizienter zu gestalten. Das ist bedingt durch medizinisch-technische Produkte, die in immer kürzeren Zyklen auf den Markt kommen und einen immer größeren Prozentsatz ihrer Funktionen in Software realisieren (siehe "Anforderungen in der Medizintechnik").

Die globale Ausrichtung komplexer Softwareprojekte erfordert unterstützende Prozesse, Methoden und integrierende Werkzeuge, die Kommunikationswege verkürzen, Automatisierung der Softwareentwicklung vorantreiben und den Stand der Arbeit jederzeit darstellen können. Daneben muss mit geeigneten Tools die Kostenentwicklung und Qualitätssicherung überprüfbar sein.

Betrachtet man die Geschichte der Softwareentwicklungsumgebungen, erkennt man einen Trend in Richtung kompletter Werkzeugeinbindung, einer ausgefeilten Prozesssteuerung und integrierter Workflow-Abläufe (siehe Abb.[1]).

Das TFS-Projekt wird gestartet

Das Ziel des Projekts war die Einführung des TFS als die Entwicklungsumgebung, die ein Team-Portal, Integrations-, Konfigurations- und Build-Management mit einem Work Item Tracking, einer Prozessführung und einer zentralen Datenbank zusammenführt. Der TFS soll die Entwicklung effizienter machen und die Kosten optimieren. Mit einer erstellten Kosten-Nutzen-Rechnung ergibt sich folgender Implementierungsfokus (in Form der TFS-Themen):

• Thema 1: Projekt- und Change Management, Backlog- und Sprint-Planung unter Verwendung von Scrum-Techniken
• Thema 2: Konfigurations-, Integrations- und Build-Management
• Thema 3: Software- und Systemtest

Wegen der Nichtverfügbarkeit adäquater Funktionen im TFS sind Requirements Engineering und Architektur in der ersten Phase der Umsetzung ausgeklammert.

Es gab zwei unterschiedliche Implementierungsansätze für das Projekt. Option eins wäre der Einsatz eines Consulting-Partners mit entsprechendem Know-how, die zweite wäre eine In-house-Implementierung mit zeitweisem TFS-Consulting-Support. Sicherlich haben beide Ansätze ihre Vor- und Nachteile. Die Projektverantwortlichen haben sich für die letztgenannte Vorgehensweise entschieden, auch weil sich der TFS als Plattform für die Einführung von Software-Engineering-Methoden gut eignet.

Für die Umsetzung des TFS-Projekts wurden einige Grundprinzipien vereinbart:

• Im Bereich der Standardisierung sollen alle Teams denselben Ansatz inklusive der Methodik und der Werkzeuge verwenden.
• Angestrebt wird die Anwendung am "lebenden Objekt". Soll heißen, die Umsetzung kennzeichnet ein stark iterativer Prototyping-Ansatz unter Einbeziehung der Mitarbeiter aus den Entwicklungsprojekten.
• Bei den Working Tools will man, anstatt das perfekte Werkzeug zu entwickeln, bei einem ersten Ansatz den Fokus auf eine akzeptable Benutzerführung setzen.
• Das TFS-Know-how soll intern aufgebaut werden, um die Akzeptanz bei den Teams sicherzustellen und das Verbesserungspotenzial in den eigenen Reihen zu stärken.

Risiken im Vorfeld erkennen

Jede größere Änderung bei den Entwicklungswerkzeugen geht Hand in Hand mit Risiken, wie die Annahme der neuen Tools durch die Teams und der Projektdurchführung selbst. Darüber hinaus gibt es weitere identifizierte Risiken. Beispielsweise eine nur begrenzte Erfahrung mit der TFS-Technik. Dem will man durch eine enge Zusammenarbeit mit Microsoft und TFS-Experten vorbeugen. Die Komplexität der eigenen Engineering-Umgebung im medizinisch-technischen Umfeld wirft weitere Fragen auf. Eine klare Definition und Priorisierung der Aufgabenliste mit schnellen greifbaren Ergebnissen sollen hierbei helfen.

In der Ablösung des derzeitigen Werkzeugs für das Konfigurationsmanagement liegt das größte technische Risiko. Abhilfe soll eine Durchführbarkeitsprüfung schaffen und ein Informationsaustausch über die "Best Practices" mit einem Unternehmen, das den Umstieg auf TFS Source Control bereits durchgeführt hat. Schließlich besteht ein Risiko in der Verfügbarkeit geeigneter Teams im TFS-Projekt. Auf Basis einer Kosten-Nutzen-Rechnung stellt die Unternehmensleitung das Personal zur Verfügung. Unter Einbeziehung der aufgeführten Grundsätze lassen sich die Risiken für die Implementierung steuern und verfolgen.

Die Einführung des TFS sollten die Teams in den Entwicklungsabteilungen selbst übernehmen. Jedem Thema ist ein "Topic Owner" zugeordnet (z.B. "Software- und System-Test"). Er agiert als vollverantwortlicher Teilprojektleiter mit eigenen Ressourcen, Budget und zu erstellenden Ergebnissen. Mit seinem Team baut er den entsprechenden Prototypen, pilotiert diesen und erreicht dadurch die Akzeptanz bei den Entwicklungsteams.

Der TFS-Programm-Manager stellt sicher, dass alle Projektressourcen (intern und extern) zum richtigen Zeitpunkt zur Verfügung stehen. Er treibt gesamtverantwortlich die Kommunikation in der Entwicklungsorganisation und die Zusammenarbeit mit anderen Organisationseinheiten im Unternehmen. Ein TFS-Steering-Komitee bestehend aus Mitgliedern der Geschäftsleitung autorisieren Budgets, genehmigen die Implementierungsstrategie und nehmen die Ergebnisse ab (siehe Abb. 2). Unternehmen, die TFS bereits komplett umgesetzt haben, berichten von 7 bis 12 Vollzeitkräften für ein TFS-Projekt einer globalen Entwicklungsorganisation (mehrere Standorte und einige hundert Entwickler).

Projektmanagement nach Scrum

Von den SYNGO-TFS-Themen ist das Projekt- und Change-Management bereits operativ umgesetzt. Die Autoren beschreiben, wie das Prozess-Template für ein Projektmanagement nach Scrum angepasst wurde, welche Probleme auftreten können und welche Lösungen sich anbieten.

Beim TFS-Thema "Projekt- und Change Management (TFS PM&CH)" handelt es sich um ein Scrum-Projektplanungs-, Tracking- sowie Fehler-Management. Während der Implementierung des Projektmanagements ergab sich eine Reihe wichtiger Erkenntnisse in der Anpassung des Prozess-Templates. In Kombination mit dem TFS-Projekt wurden auch andere Bereiche der Softwareentwicklung optimiert, wie der Umstieg auf einen Concurrent-Engineering-Ansatz (mit Lean/Agil) sowie das Requirements Engineering. Näheres hierzu findet sich auf www.infoteam.de[5] und www.scrummed.de[6].

Das Projekt- und Change-Management verwendet einen "Backlog", der alle Entwicklungsaufgaben für ein Produkt-Release enthält. Der Backlog ist sozusagen die Zentrale für die Projektdurchführung. Jede Rolle im Entwicklungsprojekt hat darauf Zugriff und erhält Informationen darüber, woran gerade gearbeitet wird. Der Produktmanager definiert den Inhalt der Funktionen und die Rangordnung der Implementierung. Das Scrum-Team implementiert die Anforderungen und stellt sicher, dass dieser Vorgang fehlerfrei ist. Nach jeder Iteration ist das Produkt lauffähig.

Der Requirements-Ingenieur betreibt die Verfeinerung der funktionalen Beschreibung und verständigt sich mit dem Testingenieur, um die Testfälle korrekt spezifizieren zu können. Für Designfragen zeichnet der Architekt verantwortlich inklusive einer Abschätzung für die technische Implementierung. Ein Projekt-Manager stellt die Planung und die Fortschrittsverfolgung sicher und handhabt auftretende Risiken.

Der Team Foundation Server stellt jeweils ein Prozess-Template für CMMI, Scrum und Agile zur Verfügung. Ersteres definiert die Prozesselemente, den Ablauf, die Dienste (Services) und Berichte. Die SYNGO-Anforderungen an ein geeignetes Prozess-Template lassen sich folgendermaßen charakterisieren: Es muss ein lean/agiles Vorgehen unterstützen, für medizintechnische Regularien sowie skalierbare Produkte und Plattformen (in Bezug auf Geographie und Anzahl der Anwender) angepasst sein und eine hohe Benutzbarkeit (geringe Anlernzeiten, effiziente Handhabung) aufweisen.

Nach einer Analyse der Stärken und Schwächen sowie dem Pilotieren kam heraus, dass das "Out of the box"-Template für die SYNGO-Anforderungen wegen eines komplexen Aufbaus und langer Lernzeiten ungeeignet war. Um das zu umgehen, bestand nur die Möglichkeit, das Template entsprechend zu adaptieren. Die folgenden Ausführungen gehen auf zwei der wichtigsten "Best Practices" ein, die sich aus der Anpassung ergeben haben: TFS-Prozess-Templates und Single Backlog Item.

Benutzbarkeit des Template

Softwareentwickler gewöhnen sich schneller an neue Werkzeuge, wenn sie direkt bei der Erstellung der Konzepte, beim Design sowie bei der Implementierung dabei waren. Aus dem Grund führte die Projektgruppe mehrere "Usability"-Workshops durch, um die Benutzertauglichkeit des Template zu optimieren.

In der TFS-Vorlage war der Arbeitsablauf im Prozess-Template unstrukturiert, die Informationselemente waren nicht an dem Platz, an dem die Entwickler sie erwarteten. Daher verloren sie unnötig Zeit mit zu vielen Klicks für Navigation und Dateninput. Das Ergebnis der Workshops war ein völlig neues Design des Prozess-Templates, nun abgestimmt auf die Anforderungen von SYNGO. Die Erfahrung belegt, dass eine einzige Benutzerschnittstelle zu 90 Prozent angepasst effizienter ist als viele rollenspezifische Schnittstellen. Ein solches Vorgehen reduziert zudem den Wartungsaufwand und hilft, die Lernkurve flach zu halten.

Die nächste Baustelle war die Informationsarchitektur. Die Kategorien der Datenfelder waren nicht logisch für den Entwickler aufgebaut. Als Lösung wurde ein zweiteiliges Format entwickelt. Die relevante Information sollte nicht über viele Reiter verteilt sein. Dadurch können die Entwickler den Navigationsaufwand durch das ständige Wechseln zwischen den Reitern vermeiden. Zusätzlich verringert die zugrunde liegende Informationsarchitektur die "Denklast". Ein Entwickler kann darauf vertrauen, dass er dieselbe Information immer am gleichen Ort findet.

Der Vorteil der Anpassungen war der maximal mögliche Raum für die Dateneingabe. Im Datenformular ist es zudem notwendig, durch eine saubere logische Struktur die Arbeitsweise der Entwickler zu unterstützen. Insgesamt waren für die Optimierung der Benutzerschnittstelle neun Iterationen notwendig; das finale Design zeigt Abbildung 4.

Single Backlog Item als "Best Practice"

Ein Prozess-Template-Formular ist der Container für die Daten der Entwicklung sowie die zugrunde liegende Benutzerführung. Neben einer standardisierten Benutzerschnittstelle liefert der TFS Techniken zur Optimierung von Routineaufgaben, zum Beispiel die Erstellung von Standardberichten wie Burn-down Charts, Populieren von Werten, Daten-Aggregation der einzelnen Work Items.

Die Logik ist von ausschlaggebender Bedeutung. Sie kann Work Items wie Anforderungen, Softwaredefekte, Architektur-Redesigns, Prozessverbesserungsmaßnahmen und vieles andere mehr vorbereiten. Der erste Ansatz war, für jeden Backlog-Typen eine optimierte Zustandsmaschine zu bauen. Anfangs gab es mehr als zehn unterschiedliche Backlog-Typen. Daraus ergab sich die Notwenigkeit, ebenfalls mehr als zehn unterschiedliche Zustandsmaschinen abzubilden. Aus der schieren Anzahl für beides wird sofort klar, dass der Wartungsaufwand inakzeptabel hoch wäre. Ein weiteres Problem, das sich neben dem Wartungsaufwand ergibt, ist die Berichtserstellung.

Das Ergebnis des Diskussionsprozesses war schließlich eine einzige Zustandsmaschine. Damit lassen sich zukünftige Änderungen kostengünstig in der TFS-Automatisierung einpflegen. Die notwendige Reduktion der Anzahl der Zustände auf ein Minimum führt zu Transparenz und Einfachheit sowie einem minimalen Wartungsaufwand. Durch das einfache Design hat sich zudem der Aufwand für die Berichtsanpassung vermindert (vom Scrum-Team bis zur komplettem Produktlinie).

Die beiden aufgeführten Beispiele sollen exemplarisch verdeutlichen, dass der Team Foundation Server mitnichten ein Produkt "out of the box" ist, sondern sich in weiten Teilen an die unternehmensspezifischen Erfordernisse anpassen lässt und auch anzupassen ist.

Analyse der Kosten-Nutzen-Rechnung

Aufgrund der Erfahrungen kann man festhalten, dass ein globales Optimum effizienter ist als viele lokale Lösungen, die gegeneinander wirken können. Der TFS liefert für SYNGO eine domänenspezifische Programmierumgebung. Die einfache Benutzbarkeit für die Entwicklungsmannschaft führt zu einer hohen Akzeptanz beim Team.

Auf Basis einer von SYNGO erstellten Kosten-Nutzen-Rechnung ergeben sich erhebliche Einsparpotenziale (unterteilt in Kostenoptimierung und Erhöhung der Entwicklungseffizienz). Den größten Hebel stellen die TFS-Themen Konfigurations-, Integrations- und Build-Management mit etwa 40 Prozent Nutzenanteil, gefolgt vom Projekt- und Change Management mit 35 sowie dem Software- und Systemtest mit 25 Prozent (siehe Abb. 5). Andere veröffentlichte Analysen, die unabhängig von SYNGO entstanden, kommen auf ähnliche Größenordnungen.

Die folgenden Vorteile sind entweder realisiert oder sind noch zu erwarten: Eine native Integrationsfähigkeit vom TFS mit Visual Studio und Microsoft Office reduziert den Wartungsaufwand bei der Werkzeuganpassung. Nach der Anpassung des Prozess-Templates ist der Lernaufwand für die Entwicklungsmannschaft gering, weil die Struktur auf bekannte Interaktionsprinzipien von Microsofts Benutzerschnittstellen aufgebaut ist. Nach der bisherigen Erfahrung ist das ein Hebel zur Akzeptanz bei Entwicklern.

Microsoft verwendet den TFS seit Jahren in der eigenen Produktentwicklung. Daher besteht die Sicherheit, dass der TFS langfristig verfügbar bleibt und laufend optimiert wird. Da der Team Foundation Sever seit mehr als fünf Jahren im Einsatz ist, hat sich eine große Community zur Verbreitung der Erfahrungen etabliert, die auch Add-on-Tools liefert.

Für den Entwicklungsleiter stellt der TFS Investitionssicherheit dar, weil sich damit innovative Softwareentwicklungsmethoden einführen lassen. Beispielsweise kann man sich mit einem modellbasierten Systemtest etwa 30 Prozent der Aufwände reduzieren. Weitere Ideen in Richtung Modell-basiertes Engineering ist der Einsatz von Modell-basierten Tracing sowie der Pex-Technik, mit der Entwickler Unit-Testfälle vom Code automatisch generieren können.

Mehr Infos

Kritische Betrachtung des TFS

Eine TFS-Instanz muss auf einer soliden IT-Infrastruktur aufgebaut sein, was im Zweifel hohe Investitionen bedarf. Um den TFS für eine große, verteilte Entwicklung nutzen zu können, ist es notwendig, ein Prozess-Template zu konfigurieren. Dazu gibt es von Microsoft keine publizierte Erfahrung oder Unterstützung. Ein enthaltenes Template ist nur für Pilotieren und kleine Teams anwendbar. Da der Team Foundation Server ein hohes Maß an Freiheitsgraden bietet, besteht die Gefahr des Over-Engineering. Es gibt keine generelle Regel, wann ein TFS-Template optimal gestaltet ist. Unternehmen, die Unterstützung zur TFS-Einführung suchen, werden sich schwer tun, da es nur wenige ausgewiesene Experten in diesem Umfeld gibt. Unterm Strich unterstützt der TFS mit seinen robusten Techniken die geforderten Engineering-Prozesse.

Doch obwohl der TFS seine Stärken in der Durchgängigkeit und Anpassbarkeit an bestehende Entwicklungsumgebungen hat, gibt es Löcher, die Microsoft schnell stopfen muss. Für Requirements Engineering im Enterprise-Umfeld fehlen brauchbare Funktionen für die Definition und Analyse von Anforderungen, Feature Modeling sowie eine einfache Konfigurierbarkeit des Tracing. Was für ein professionelles Testen, Produktlinien-Management und Requirements Engineering essenziell ist, ist das Baselining und die Versionierung von Work Items.

Fazit

ALM-Tools wie der TFS bieten großen, weltweit agierenden Entwicklungsorganisationen die Möglichkeit, Prozesse, Methoden und Praktiken zu standardisieren. Über die gute Tool-Integration erreicht man schnell eine positive Akzeptanz und auf Plattformebene betrachtet die Chance, neue effektivere Ansätze im Engineering einzubauen.

Das Projekt- und Change-Management ist operativ bei SYNGO im Einsatz und hat die anfängliche Erwartungshaltung erfüllt. Die Vorteile, die sich in der diesjährigen Release erfahren ließen, lassen sich wie folgt zusammenfassen: zentrale Übersicht über alle Team-Aufgaben und den Team-Status, eine verbesserte Vorhersagbarkeit von Entwicklungstrends und Erkennen von Projektrisiken und damit deren effektivere Lösung. Die Entwicklungsmannschaft hat den TFS positiv aufgenommen.

Weitere Teile des Application Lifecycle Management (der Umstieg von ClearCase auf "TFS Source Control" und die Ablösung der intern entwickelten Test-Tools durch Microsofts Testwerkzeuge) sind derzeit in unterschiedlichen Implementierungsphasen: Darauf aufbauend wird es sicherlich weiterhin kontinuierliche Verbesserungsaktivitäten geben.

Arnold Rudorfer
ist der Programm Manager der Next Generation IVD System Platform bei Siemens Healthcare Diagnostics in Flanders, NJ (USA). Er war verantwortlich für die Führung des TFS-Programms bei SYNGO.

Gerold Herold
ist Prozess-Manager bei Siemens Healthcare SYNGO. Er war verantwortlich für den Roll-out des TFS-Projektmanagements und leitet jetzt das TFS-Programm bei SYNGO.

Carsten Schu
ist Programm-Manager in der syngo.via-Produktentwicklung und mitverantwortlich im globalen Roll-out vom TFS.

Unterstützt wurden die Autoren von den Siemens-Kollegen Thomas Baer, Olaf Curtze, Thomas Dasch, Ralf Fritscher, Adrian Gerhäußer, Peter Kiesel, Oliver Gradl, Klaus Moritzen und Josef Niedermeier sowie von Martin Künzle (evosoft) und Sven Hubert (AIT).

Onlinequellen & Literatur

1. US Food & Drug Administration, Design Control Guidance for Medical Device Manufacturers; March 11, 1997,
2. Medical Device & Diagnostic Industry 101, Carey Smoak, Roche Molecular Systems Inc., Pleasanton, CA, Pharma SUG 2010, Paper 1B01
3. Arnold Rudorfer, Christof Ebert: Lean Requirements Engineering – Erfahrungen aus der Praxis, March 15, 2011; Munich
4. Crimson White Paper, ALM-Vergleichsanalyse: Warum IBM Rational Anwender zu Microsoft wechseln, September 2009
5. Arnold Rudorfer, Gerold Herold: MS Team Foundation Server (TFS) Program @ SYNGO, Experiences and Lessons Learned, Keynote Address @ InfoTeam TechTalk; March 15, 2011; Bubenreuth, Germany
6. Carsten Schu, Lars Roith: Supporting the Agile Transition with MS Team Foundation Server (TFS); February 23, 2011; Munich, Germany
7. Sam Guckenheimer: Agile in the Impossibly Very Large – Experiences from the Microsoft Developer Division, Agile, 2009
8. Sven Hubert; Alles unter Kontrolle; Werkzeugkette für das Test-Management mit dem Team Foundation Server 2010; Artikel auf heise Developer

Anforderungen in der Medizintechnik

SYNGO, ein Geschäftsgebiet der Siemens AG Healthcare Sektor Imaging & Therapy Division, ist ein Hersteller von bildgebenden Softwareapplikationen mit einigen hundert Entwicklern in Standorten auf mehreren Kontinenten. Die Entwicklungsprojekte sind geographisch verteilt. Das Produkt besteht aus mehreren tausend Anforderungen, die in vielen Millionen Zeilen C++ und C# umgesetzt sind. Auf syngo.via, der Image Reading Software, können Teams klinische Anwendungen der Computer-Tomographie, Röntgen, Magnetresonanz, Onkologie, PET/SPECT, Angiographie und Ultraschall entwickeln.

Gesetze zum Schutz vor allem der Patienten, wie das deutsche Medizin Produktgesetz oder die U.S. Federal Drug and Food Administration (FDA) Part 11, erfordern die vollständige Erfüllung dieser im Produktentwicklungsprozess hinterlegten Anforderungen (z.B. Verfolgbarkeit und Auditierbarkeit von Anforderungsänderungen). Ohne die Erfüllung dieser Anforderungen haben Medizintechnikunternehmen keinen Marktzugang. Andererseits steigt der Wettbewerb mit dem Eintritt von Unternehmen aus den BRIC-Ländern (Brasilien, Rußland, China und Indien) sowie großen etablierten IT-Firmen. Das führt dazu, dass Medizintechnikunternehmen kontinuierlich die Entwicklungszeiten, Kostenposition und die Entwicklungseffizienz optimieren müssen. Ein anderer wichtiger Faktor ist die Steigerung des Grades der Softwarefunktionalität von etwa 30 Prozent im Jahr 2000 auf mehr als 60 Prozent im Jahre 2009. Das geht Hand in Hand mit dem Wachstum technischer Geräte von 52 Prozent von 2000 bis 2009 [2]. Die aufgezählten Faktoren motivieren daher Medizintechnikunternehmen, in die nächste Generation von Software-Engineering-Umgebungen zu investieren, um damit den Herausforderungen zu begegnen.

(ane)