Team Foundation Server Siemens Healthcare09232011

heise Developer - Team Foundation Server bei Siemens Healthcare im weltweiten Einsatz Page 1 of 10

c't iX Technology Review Mac & i mobil Security Netze O
Download Telepolis Resale Foto Autos Preisvergleich Stelle

Arnold Rudorfer, Gerold Herold, Carsten Schu
Team Foundation Server bei Siemens Healthcare im weltweiten Einsatz
Eingeführt und gewonnen

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)

http://www.heise.de/developer/artikel/Team-Foundation-Server-bei-Siemens-Healthcare-i... 9/27/2011


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 mehrere hundert Entwickler).

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

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[1] [5] und www.scrummed.de[2] [6].

Der Team Foundation Server im Zusammenhang mit laufenden
Technologie-Initiativen (Abb. 3)

Das Projekt- und Change-Management verwendet einen "Backlog", der alle
Entwicklungsaufgaben für ein Produkt-Release enthält[3]. 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[4], 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, angepasst
für medizintechnische Regularien sowie skalierbare Produkte und Plattformen (in Bezug auf
Geographie und Anzahl der Anwender) 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 angepasst an 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.

Das angepasste Work Item "Single Backlog Item" (Abb. 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 gemachten 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 stellt das TFS-Thema 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[5], die unabhängig von SYNGO gerechnet wurden, kommen
auf ähnliche Größenordnungen.



Der größte Nutzen wurde im Bereich "Konfigurations-, Integrations-
und Build-Management" erzielt (Abb. 5).

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 lassen 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[6], mit der Entwickler Unit-Testfälle vom Code automatisch generieren können.

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 publizierten
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 so 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. (ane)

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[7]; 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[8], March 15, 2011; Munich



4. Crimson White Paper, ALM-Vergleichsanalyse: Warum IBM Rational Anwender zu
Microsoft wechseln[9], September 2009
5. Arnold Rudorfer, Gerold Herold: MS Team Foundation Server (TFS) Program @
SYNGO, Experiences and Lessons Learned[10], Keynote Address @ InfoTeam
TechTalk; March 15, 2011; Bubenreuth, Germany
6. Carsten Schu, Lars Roith: Supporting the Agile Transition with MS Team Foundation
Server (TFS)[11]; 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[12] 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 mehreren hundert Entwicklern in
Standorten auf mehreren Kontinenten. Die Entwicklungsprojekte sind geographisch verteilt.
Das Produkt besteht aus mehreren tausend Anforderungen, die in mehreren 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ße etablierte 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.


heise Developer - Team Foundation Server bei Siemens Healthcare im weltweiten Eins... Page 10 of 10

Herausforderungen an die Produktentwicklung der Medizintechnik
(Abb. 6).

URL dieses Artikels:
http://www.heise.de/developer/artikel/Team-Foundation-Server-bei-Siemens-Healthcare-im-weltweiten-Einsatz-
1349216.html

Links in diesem Artikel:
[1] http://www.infoteam.de/index.php?file=forms_de_downloads_files&mode=info&form%5bnumber%
5d=9099&clean=yes
[2] http://www.scrummed.de/tl_files/scrummed/site/Vortragsabstracts/ScrumMed2011_Siemens_AIT_Schu_Roith.pdf
[3] http://2011.reconf.de/anwenderberichte/siemens-und-vector/
[4] http://msdn.microsoft.com/en-us/vstudio/aa718795.aspx
[5] http://download.microsoft.com/.../Warum_Anwender_von_IBM_Rational_zu_Microsoft_wechseln_Crimson-
Studie.pdf
[6] http://research.microsoft.com/en-us/projects/pex/
[7] http://www.fda.org/cdrh/qsr/01qsreg.html
[8] http://2011.reconf.de/anwenderberichte/siemens-und-vector/
[9] http://http;/download.microsoft.com/.../Warum_Anwender_von_IBM_Rational_zu_Microsoft_wechseln_Crimson-
Studie.pdf
[10] http://www.infoteam.de/index.php?file=forms_de_downloads_files&mode=info&form%5bnumber%
5d=9099&clean=yes
[11] http://www.scrummed.de/tl_files/scrummed/site/Vortragsabstracts/ScrumMed2011_Siemens_AIT_Schu_Roith.pd
[12] http://www.heise.de/developer/artikel/Werkzeugkette-fuer-das-Test-Management-mit-dem-Team-Foundation-
Server-2010-1224807.html

715858 Copyright © 2011 Heise Zeitschriften Verlag Content Management by InterRed
International: The H, The H Security, The H Open Source


Team Foundation Server Siemens Healthcare09232011

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (12)

More from Arnold Rudorfer

More from Arnold Rudorfer (20)

Team Foundation Server Siemens Healthcare09232011