Dieser Artikel wurde maschinell übersetzt.

ALM Rangers

Eine Schatzsuche zur ALM Readiness

ALM Rangers

Downloaden des Codebeispiels

In diesem Artikel wir einführen die Windows-Speicher-Beispielanwendung ALM Bereitschaft Schatzkarte, und das Design, Codierung und Erfahrungen der Visual Studio ALM Rangers im Gebäude der app testen. Es ist entworfen, um einen master-Katalog zur Verfügung, um Entwicklern Application Lifecycle Management (ALM) Praktiken beherrschen Inhalte bieten. Die ALM Rangers sind eine Gruppe von Experten, die Zusammenarbeit zwischen der Produktgruppe Visual Studio , Microsoft Services und der Microsoft MVP-Gemeinschaft durch Adressierung fehlende Funktionalität, fördern, Annahme-Blocker entfernen und best Practices und Anleitung basierend auf realen Erfahrungen zu veröffentlichen.

Was haben wir getan und warum?

Wir haben ein Geständnis zu machen: Wir lieben Visual Studio und Visual Studio Team Foundation Server (TFS). Microsoft stellt einige der besten Software-Entwicklungswerkzeuge zur Verfügung. Wir sagen, dass nicht nur, weil wir für Microsoft zu arbeiten — fühlten wir uns so lange vor Eintritt in die Firma. Diese Suiten bieten eine unglaubliche Anzahl von Funktionen aber entmutigend für neue Benutzer nachweisen können. Wie starte Entwickler lernen diese Tools verwenden? Diese Frage präsentierte sich uns in eine etwas andere Art und Weise.

ALM Rangers TechReady-Konferenzen in der Regel eine Anzahl von Sitzungen, die beschreiben verfügt, wie zur Verbesserung der Kenntnisse von Microsoft-Entwicklungstools anwesend. Die Konferenzen halten sogar interaktive Sitzungen wo können Teilnehmer Feedback der internen Gruppen diese Bauprodukte bereitstellen. Wir fanden diese spannende Möglichkeiten für Entwickler und Berater zu sein. Nach Eintritt in das ALM Rangers -Team haben wir begonnen zu prüfen die veröffentlichte Anleitungen und schnell merkte, daß es eine erhebliche Menge an Inhalt zu verdauen; Wir waren nicht sicher, wo Sie Unterricht beginnen.

Was wir wirklich wollten, war eine Ressource, die uns in ALM Praktiken beherrschen helfen. Wir begann mit dem Bau der ALM Bereitschaft Treasure Map Windows speichern-app, um Benutzer über die Materialien auf ihrer Reise wird zum Experten führen. Abbildung 1 zeigt Ihnen die Ergebnisse unserer Arbeit. Es enthält fünf Kategorien, jeweils mit mehreren Themen der Studie:

  1. Vorbereitung
  2. Kurze Einführung
  3. Hilfsmittel und Anleitungen
  4. Werkzeugmaschinen
  5. Werkstätten

The Treasure Map Windows Store App
Abbildung 1 die Treasure Map Windows-Speicher-App

Diese Bereiche enthalten Anleitungen, praktische Übungen und Videos machen es so einfach wie möglich für Benutzer zu holen, die Fähigkeiten, die sie, schnell und effektiv benötigen. Navigieren in die Materialien funktioniert besonders gut auf neue Touch-fähigen Geräten wie der Microsoft Surface.

Um die optimale Erfahrung bieten, eingetragen wir Hilfe ein Experte UX-Designer und leitende Entwickler um die Anwendung zu erstellen.

Die ALM Bereitschaft Treasure Map Lösung: UX-Design-Nuggets

Einen guten ersten Eindruck die Schatz-Karte-Fliese (siehe Abbildung 2) ist Blickfang und hell, mit einem orangefarbenen Hintergrund verwendet, um Sand zu symbolisieren. Der Benutzer sieht sofort, das Thema der app – das ergibt sich aufgrund der Palme und den Weg zum wo "X" die Stelle des Schatzes markiert. Der app-Titel ist deutlich sichtbar auf der Fliese. Dafür sorgen, dass die Fliese zeigt, was ist Ihre app erstellt über tatsächlich einen guten ersten Eindruck. Das letzte, was, das Sie wollen, ist für Benutzer öffnen Sie Ihre app und werden verwirrt, warum sie es verwenden und wie sie ihnen helfen kann.

The Treasure Map Windows Store App Tile
Abbildung 2 die Treasure Map Windows Store App-Kachel

Wir haben den Splash-Screen eingesetzt (siehe Abbildung 3), ein bisschen mehr von der app Persönlichkeit zeigen und helfen, einen guten Start zu gewährleisten. Die Schatzkarte-Splash-Screen rendert einen erweiterten Pfad zu dem Schatz, der eine glatte, polierte laden-Erfahrung ist. Es ist übersichtlich und einfach durch Design, reflektieren, wie die UX werden. Darüber hinaus kann ein einzigartiger Bildschirm helfen, die Marke zu stärken.

The Treasure Map Windows Store App Splash Screen
Abbildung 3 der Schatz Karte Windows Store App-Begrüßungsbildschirm

Homepage — die Schatzkarte selbst — erscheint, sobald die app geladen hat. Auch hier bestätigt unser klares, Content-orientierten Design sofort den Zweck der app. Wir wollten diese Seite fantastisch machen, so dass der Benutzer den Rest der app erkunden wollen. Die Homepage ist, wo die Reise beginnt, und auf einen Blick, der Benutzer weiß, dass dies eine Reise sein wird. Die Titel sind die Quelle für die Navigation und aufgrund unserer Designs "Inhalten über Chrom" sie hervorstechen. Der app-Inhalte wird betont durch nicht-funktionale Elemente entfernen. Alle um Informationen schnell zu finden, finden alle Links auf dem Bildschirm ohne zum Navigieren durch die app, die eine tolle Erfahrung für alle Arten von Benutzern bietet.

Manchmal übersehen, aber entscheidende The Windows 8 UI benutzt das Prinzip einer Grid-System über alle seine apps. Dieses Prinzip fördert eine übersichtlichen Design.

Die Schatzkarte-app beschäftigt das Grid-System überall außer auf der Homepage und das Ergebnis ist, dass Inhalte ist unübersehbar — mehr Inhalt, weniger Chrom. Diese Inhalte über Chrom-Prinzip ist eines der einzigartigen Prinzipien von der Windows-Speicher-app-Stil, wo trägt visuelle Einheit zu einem großen UX. Die Homepage ist die einzige Seite, die eine Ausnahme von dieser Regel ist. Wir sind Darstellung eine Reise und ein Piratenthema, das wir in der Lage, ohne visuelle Darstellungen zu erreichen gewesen wäre.

Typografie wird manchmal übersehen, und viele Menschen wissen nicht, wie viel es die Marke der app stärken kann. Mit Schriften korrekt und konsistent hilft, Klarheit zu erreichen und gibt einen übersichtlichen Blick, der macht die app einfacher zu lesen und daher verwenden. Die empfohlenen Schriftarten sind Segoe UI (hauptsächlich verwendet für UI-Elemente wie Schaltflächen), (zum Lesen und schreiben, wie z. B. e-Mails) Calibri und Cambria (für größere Textblöcke). Wir haben für alle Texte außer den Headern Segoe UI verwendet. Für diejenigen, wir Blackadder ITC verwendet, um eine stärkere Thema zu etablieren (siehe Abbildung 4). Wir brechen die Schriftart-Regel hier, weil wir die app Aussehen mit einem papierbasierten Map, in Einklang stehen wollten, da dies dazu beiträgt, um das Piratenthema zu verstärken. Also, in diesem Fall gut funktioniert es.

The Typography We Used in the Treasure Map Windows Store App
Abbildung 4 die Typografie, die wir in der App Treasure Map Windows speichern verwendet

Nahtlose und flüssige Navigation ist entscheidend für die Anwenderfreundlichkeit und große UX bieten Zwei Formen der Navigations-Muster werden empfohlen: Das hierarchische System und das flache System (siehe Abbildung 5). Das hierarchische System ist, was die meisten apps verwenden. Es ist die häufigste und werden die bekannteste Art der Navigation zu viele Benutzer. Es ist auch das beste System zu erstellen, die flüssige spüren noch immer noch einfach zu bedienen sein. Das flache System wird hauptsächlich in Spiele, Browser oder Dokumenterstellung apps, wo der Benutzer kann nur gehen rückwärts und vorwärts auf der gleichen hierarchischen Ebene verwendet. Die Schatzkarte-app nutzt das hierarchische System, und wir glauben, dass er sie gut nutzen. Die Homepage würde als Hub klassifiziert werden, und jeder Abschnitt erstellt die erste hierarchische Verzweigung aus wo jeder Abschnitt dann einen anderen hierarchischen Zweig erstellt. Beispielsweise kann der Benutzer von der Homepage, zum Abschnitt "vorbereiten", navigieren wo der Benutzer andere vorbereiten-Unterabschnitte erkunden können.

Recommended Navigational Patterns
Abbildung 5 empfohlen Navigations-Muster

Verwendbarkeit ist es wichtig zu beurteilen, die UX der app um das Design zu verbessern, damit die app ist:

  • Einfach zu bedienen
  • Wertvoller Benutzern — zum Beispiel in den Funktionen können
  • Wünschenswerter verwenden

Beurteilung Ihres Designs können Sie darauf vertrauen, dass die app eine herausragende UX und Anwender es hilfreich, verwendet und wünschenswert finden.

Wie beurteilen wir die UX der app? Es gibt viele Möglichkeiten, dies zu tun, aber zwei gemeinsame sind Selbstbewertungen und kognitive Exemplarische Vorgehensweisen, wie in Abbildung 6.

Abbildung 6 Beurteilung der UX der App

  Self-Assessment Cognitive Walkthrough
Warum Dies basiert auf den Zielen, die der Benutzer zu erreichen oder finden soll. Es wird sichergestellt, dass das Design auf der Strecke mit Ihren wichtigsten Absichten. Dies ist ein wenig mehr in die spezifischen Aufgaben gegliedert, die ein Benutzer möglicherweise zu erfüllen, zum Beispiel, um Informationen über "VM Fabrik Werkzeug- und Richtlinien." zu finden
Wann Es ist eine gute Idee, Selbstbewertungen jeden Sprint tun oder wenn jedes Ziel erreicht wurde; Sie dauern bis zu 30 Minuten. Während des Entwurfsprozesses und durch jeden Sprint.

Es gibt vier Erfolg-Metriken, die beide die Selbstbewertung der app sowie die cognitive Walkthrough der app hilft. Im Folgenden werden diese Attribute aufgeführt:

  • Great an: Was ist die app zu groß? Was sind die Schwerpunkte der Grafiken?
  • Verwendbar: Welche sollte Benutzer in der Lage zu verstehen, wissen oder mehr erfolgreich wegen der app zu tun?
  • Nützlich: Was Sie tun möchten, die Benutzer Wert?
  • Wünschenswert: Welche Teile der app möchten Sie Benutzer begeistern oder sie Liebe machen?

Wir verwendeten Selbstbewertungen und cognitive Walkthroughs. Die Selbstbewertung wurden durch jeden Sprint durchgeführt und an unsere pro Stand-Ups überprüft. Die kognitiven exemplarischen Vorgehensweisen wurden während des Entwurfsprozesses und durch jeden Sprint durchgeführt. Beurteilung der UX unsere App half uns zu verstehen, der Wunsch und die emotionale Verbindung zu Erfahrungen, die ein Benutzer erkennen kann.

UX-Entwurf zusammenzufassen:

  • Stellen Sie sicher, dass die Fliese zeigt, worum es in Ihrer app geht.
  • Erstellen Sie einen einzigartigen Splash-Screen, um Ihre Marke zu stärken.
  • Schreiben Sie Inhalte mit einem klaren Fokus.
  • Verwenden Sie das empfohlenen Grid-Layout, um eine einfache und saubere Design zu erstellen.
  • Don' t, über Typografie vergessen. Empfohlenen Schriftarten zu verwenden, soweit möglich, wie Segoe UI, Calibri und Cambria.
  • Haben Sie eine klare Navigation-Muster. Wählen Sie entweder das hierarchische System oder das Deckelsystem.
  • Bewerten Sie die Usability Ihrer Anwendung während des gesamten Entwicklungszyklus.

Die Codierung Juwelen

Vor dem Beginn Kodierung festgelegten wir eine Reihe von Codierung Ziele für dieses Projekt. Diese Ziele wurde das Mantra für wie wir konzipiert und entwickelt die Codebase.

  • Anpassungsfähigkeit: Anforderungen können sich ändern, Funktionen hinzugefügt oder geschnitten werden können und Entwürfe können weggeworfen werden, zugunsten von etwas ganz anderes. Anpassungsfähigkeit ist der Name des Spiels!
  • Einfachheit: Einfachheit ist besonders wichtig für viele Vorteile in Software-Design, Wartbarkeit und Fixability.
  • Testbarkeit: Qualitätssicherung muss für jedes Projekt eine hohe Priorität, und die Codebase muss ermöglichen umfassende und "einfaches" testen.
  • Leistung und Mobilität: Die app UX muss von Anfang an positiv sein. Die app muss zeitnah Informationen anzeigen, muss immer auf Benutzereingaben reagiert werden und darf nicht zurückbleiben.
  • Teamumgebungen: Selten wird eine app von als einzelner Mitarbeiter oder sogar ein individuelles Team gebaut. Wir sorgten dafür, dass die app in einer Weise gebaut wurde, die für viele weitere Teammitglieder zugeschnitten werden konnte.

Also jetzt, dass wir unsere Ziele definiert hatte, wie in der Welt erreichen wir eine app in so kurzer Zeit zu schreiben — arbeiten Teilzeit — gleichzeitig erfüllen nicht nur die funktionalen Anforderungen, sondern auch unsere nicht-funktionalen Anforderungen als auch? Zum Glück für uns, dieses Rad entstanden vor und der Bau unserer app war eine Frage der Anwendung von bewährten Muster und Verhaltensweisen auf unsere app:

  • C# und XAML: Wir beschlossen, c# und XAML verwenden, vor allem, weil die Mehrheit der Mitwirkenden an diesem Projekt mit diesem Konzept vertraut sind. Dazu gehören die Sprachen selbst und die Werkzeuge sowie Unterstützung für sie.
  • Model-View-ViewModel (MVVM): Dies ist ein Muster für die Darstellungsschicht von Ihre Geschäftslogik aus Ihren Objekten zu trennen. Wir wählten dieses bestimmte Muster, da die c#- und XAML-Technologien sich sehr gut dazu eignen. Aber noch wichtiger ist, mit einem einzelnen Muster, konnten wir beginnen, meißeln entfernt an unsere nicht-funktionalen Anforderungen. Die Ziele, die MVVM am meisten positiv beeinflusst waren, Anpassungsfähigkeit, Testbarkeit, Teamumgebungen und Einfachheit. Anpassungsfähigkeit wird verbessert, insofern Sie eine funktionale Stücke Ihrer App austauschen können. Vielleicht eine neue Präsentation für eine bestimmte Ansicht-Modell ist abgeschlossen und Sie können es sofort ohne jeden anderen Code ersetzen. Testbarkeit wird verbessert, da jede funktionale Kernstück des Codes in ihre eigene individuelle Verantwortung getrennt sind, welche Mittel-Tests geschrieben gegen diejenigen direkt und automatisiert werden können. Teamumgebungen werden verbessert, weil man eine definierte Gruppe von Verträgen unter der app beweglichen Teile, wodurch Mannschaften parallel miteinander arbeiten. Einfachheit wird verbessert, in dem jedes bewegliche Teil eigene definierte bewegliche Teil und in einer bestimmten Weise interagiert. Weitere Informationen finden Sie unter "What's New in Microsoft Test Manager 2012" unter msdn.microsoft.com/magazine/jj618301.
  • Ressourcen: Wir beschlossen nach dem Geist des MVVM und Trennung von Rollen und austauschbare Teile Ressourcen für die Definition von unserer Schriften, Buttons und andere ähnliche Designelemente hinzufügen. Dieses half verbessern Teamumgebungen, Einfachheit und Anpassungsfähigkeit.
  • Aber was haben wir getan, über Leistung und Flüssigkeit? Wir folgte dem Async/erwarten Muster für lang andauernde Prozesse. Dies ist einer der Bereiche, wo Entwickler beim Aufbau von Windows Store apps kämpfen könnte, aber es muss nicht sein. Zum Glück sind Windows-Speicher-Anwendungen mittels c# und XAML wird von der Microsoft .NET Framework 4.5, können Sie leicht zählen asynchrone Arbeitslasten in Ihre app durch dieses Muster. Wenn es so leicht gemacht wird, warum kämpfen Leute mit ihm? Die Antwort auf diese Frage läuft in der Regel auf Logik, die lang andauernde und ist nicht Out of the Box vom .NET Framework verwenden. Ein Beispiel hierfür könnte Logik Handlung Punkte für ein Diagramm basierend auf komplexen Mathematik berechnen. A volle Verständnis der Async und erwarten ist entscheidend für die Bereitstellung einer Flüssigkeit, hoch performante app. Weitere Informationen finden Sie unter "Async-Performance: Grundlegendes zu den Kosten der Async und Await"bei msdn.microsoft.com/magazine/hh456402.

Andere Überlegungen enthalten:

  • Berühren Sie Sprache: Dies könnte nicht einfacher sein, aus Sicht der Entwicklung. Fast jeder aus-of-the-Box-Steuerelement unterstützt Note in alle Möglichkeiten, die Sie erwarten. Aus Sicht der Codierung war dies der einfachste Teil der app zu bauen.
  • Charme: Interaktion mit den Charme war auch einfach. Registrieren Sie diese in Ihren Appxmanifest und fügen Sie im Ereignis Handler auf jeder Seite für die spezifische Reize, z. B. Suche oder Freigabe registrieren möchten. Wir hatten keine Probleme mit Charme. Sie funktioniert gut, wie ein Zauber funktionieren sollte.
  • Fliesen, Splash-Screens und Ausrichtungen: Alle diese wurden in den Appxmanifest und dann durch Ereignis-Hooks in der app auf der app-Ebene behandelt. Es war einfach, und alles ist detailliert im Beispielcode.

Wie es funktioniert wirklich alles ist hier, wie Dinge in der Praxis erarbeitet:

  • MVVM-Befehle: MVVM war fantastisch in der Theorie. Jedoch bewies es in Wirklichkeit ein bisschen anders als die üblichen Windows Presentation Foundation (WPF) und Silverlight-Entwicklung, insbesondere für die Befehle, Implementierung, da unsere alten Proben nicht funktionierte. Glücklicherweise Befehl <T> war ziemlich einfach, in dem neuen Rahmen zu implementieren und zu sehen in unserer Beispielanwendung. Aber unsere Leiden noch nicht zu Ende mit Befehlen, weil ListViewBase Elemente eine beigefügten Command-Eigenschaft nicht! Wir beschlossen, dies zu Vorführzwecken auf zwei Arten lösen:

Zuerst entschieden wir uns zur Lösung dieses Problems, die Verwendung einer nicht verwendeten Eigenschaft:

<ListView Grid.Column="2"
          SelectedItem="{Binding Selected,Mode=TwoWay}" 

Die Eigenschaft, die es gebundenen gibt "Null" und keine Ausnahmen auslösen, (selbst wenn Sie alle Ausnahmen einschalten), das ist schön, aber der Schlüssel ist in der Menge. In der Menge, anstatt alles machen wir eine Navigation aufrufen und den Index des ausgewählten Elements als Parameter zu übergeben.

Zweitens haben wir beschlossen eine angefügte Abhängigkeitseigenschaft vom Typ ICommand erstellen. Die Beispielimplementierung ist in der Klasse "ItemClickCommand" im Ordner "MVVMSupport."

  • Mehrere Ansicht Status führen zu massiven Ansichtsdateien: Unsere Ansichtsdateien wurde extrem große und schwieriger zu handhaben, vor allem durch mehrere Staaten in Sicht. Ein anderes Layout pro Ansichtszustand ist in der Regel erforderlich, und Sie könnte sogar haben verschiedene Ansichten für verschiedene Display-Abmessungen oder wechselnden Dimensionen, und so weiter. Unser Ansatz war es, ihnen aufgeteilt in mehrere XAML-Dateien, mit einer XAML-Datei pro Ansicht pro Staat. Zum Beispiel hätten wir eine Ansicht namens "HomePageView", hätten "HomePageView.xaml" in einem vollen, eingerasteten und gefüllte Ordner, jeweils in den Ordner für ihren Zustand wir.
  • Anpassung in der realen Welt: Dies war eine gute Geschichte. Nachdem wir die großen Teile unserer App entwickelt, hatte — Data Provider wechseln, switching UIs und neue charm Interaktionen aller den entsprechenden Stellen — Anpassung an wechselnde Anforderungen wurde ein Stück Kuchen. Fragen waren leicht auf die Spur, und viel der Planung ausgezahlt, weil die Designer parallel zu den Entwicklern und den Sponsoren funktionieren könnte.

Zusammenfassend lässt sich dieser Abschnitt, aus Sicht der Codierung sind Windows Store apps einfach richtig zu entwickeln. Nach ein paar vordefinierte Regeln, Mentalitäten und Muster können Sie eine gute app schnell zu erstellen. Die Hauptanliegen sind Ansichtszustand app, app-Status, Charme Interaktion, Flüssigkeit und sicherstellen, dass Sie Code in einer Weise, die Ihre Design-Team zu Hause durchlaufen ermöglicht wird. Weitere Informationen finden Sie unter dev.windows.com.

Testen und Überprüfen der Lösungsqualität

Die Kernanforderungen Akzeptanz, die wir definiert, von Anfang an gehörte die Beispiel-Code-Qualität zu erhöhen und werden Teil unserer Gesamtqualität-Hund-Fooding-Programm (siehe aka.ms/df_tooling). Strenge Qualitätskontrollen Tore für geopolitische, Namespace, Codeanalyse und StyleCop (siehe stylecop.codeplex.com) Einhaltung half uns eine bessere Lösung, produzieren, wenn auch nur ein Beispiel.

Prüfung sollte keine Nebenrolle spielen und ist so wichtig, bei Proben, wie es bei geschäftskritischen Lösungen. Es ist einfacher, Codequalität, durchzusetzen und zu Verwalten von Benutzererwartungen und Anforderungen von Anfang an, anstatt mit Hunderten von Konformität Bugs und zornigen Tester konfrontiert werden und während eines verspäteten Qualitätsverbesserung Feature und Code-Änderung beschäftigen.

Weil die Absicht eine schnelle Beispiellösung war, haben wir in erster Linie eine "Black Box" Teststrategie Schwerpunkt Verhalten als Bestandteil der System- und Akzeptanztests (UAT) verabschiedet. Erstere wurde manuell durchgeführt, durch das Team, die Konzentration auf erwarteten Funktionen und nicht funktionalen Anforderungen und Erkundung Rand-Fällen, wo die Interna verstanden wurden. Die Gemeinschaft wurde eingeladen, um Unterstützung bei der Validierung UAT, leistungsstarke unsystematische Tests basierend auf realen Szenarien und Erwartungen, und nicken Bugs und Features fehlen, unpraktisch und unklar.

Siehe Abbildung 7 (mit den Zahlen, hier entspricht die rot eingekreiste Zahlen in der Abbildung), wir in der Regel verwendet das Microsoft-Test-Manager explorative testen-Feature (1) und der Simulator (2) zur Bewertung von der Probelösung auf einem Surface-Typ-Gerät erfasst EINZELANMERKUNGEN (3) und nahm die Test-Session (4) für die Zukunft.

Exploratory Testing
Abbildung 7 unsystematische Tests

In Zukunft werden wir ernsthaft in Erwägung ziehen die Definition der Testfälle mehr strukturierte und die Verwendung von Microsoft Fakes um das Gerät zu implementieren und Feuerproben. Dies wird uns ermöglichen, automatisch und kontinuierlich Featureänderungen überprüfen und zugehörige Änderungen am Code.

Ausblick

Wir werden die ALM Bereitschaft Treasure Map-app entwickeln, und wir erwägen eine online-Update-Funktion für die Bereitschaft-Referenz-Anlagen. Weitere Informationen finden Sie unter "unter­stehen die Visual StudioALM Rangers" bei aka.ms/vsarunderstand; Visual Studio ALM Ranger Solutions"bei aka.ms/vsarsolutions; der ALM-Readiness-Schatzkarte-Beispielcode auf aka.ms/almtreasure; und die app selbst im Windows-Speicher bei aka.ms/vsartmapapp. Wir freuen uns Ihr ehrliches Feedback und Ideen!

Anisha Pindoria UX Entwickler Consultant bei Microsoft Consulting Services im Vereinigten Königreich ist.

Dave Crook ist Entwickler Consultant bei Microsoft Consulting Services East Region, wo sein Schwerpunkt Visual Studio und Team Foundation Server ist.

Robert Bernstein ist ein senior-Entwickler mit den Microsoft Consulting Services weltweit öffentlichen Sektor Cyber Security Team.

Robert MacLean ist ein Softwareentwickler eingebettet in eine typische offene Entwicklungsbüro bei BBD (bbd.co.za).

Willy -Peter Schaub ist leitender Programmmanager bei den Visual Studio ALM Rangers im Microsoft Canada Development Center.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Patricia Wagner (Microsoft)