Team Foundation Server bei Siemens Healthcare im weltweiten Einsatz

Architektur/Methoden  –  1 Kommentare
Anzeige

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

Evolution des Software Engineering in den letzten Jahrzehnten (Abb. 1)

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.

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

Die Organisationstruktur des TFS-Projektes bei SYNGO (Abb. 2).
Anzeige