Das Microsoft Solutions Framework (Teil 2)

Veröffentlicht: 18. Nov 2001 | Aktualisiert: 16. Jun 2004

Von Michael W. Dietrich

In dieser Folge widmen wir uns dem Thema der Konzeption und Dokumentation. MSF weist mit den
"lebenden Dokumenten" ein sehr praxisgerechtes Modell auf. Des weiteren geht es um Entscheidungsprozesse,
die Anwendungsarchitektur und das Risiko-Management.

Auf dieser Seite

 Lebende Dokumente
 Vorgefertigte Entscheidungen nach Entscheidungs-Schema
 Das Applikations-Architekturmodell des MSF
 Proaktives Risikomanagement nach MSF
 Risikoidentifikation
 Risikoanalyse
 Wer bewertet
 Welche Werte werden ermittelt?
 Die Top 10-Liste
 Risikoplanung
 Risikoverfolgung
 Risikosteuerung
 Weitere Module
 Fazit

Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:

Wichtige Prinzipien eines erfolgreichen Prozesses sind laut MSF "lebende Dokumente" und die Festlegung einer Entscheidungsmatrix. Während sich das Prinzip der versionierten Releases bereits aus dem Spiral- (oder RAD-) Modell ergibt, sollen die beiden anderen Prinzipien hier Gegenstand einer weiteren Betrachtung sein.

Lebende Dokumente

Oft werden zu Beginn eines IT-Projektes große Mengen an Dokumenten mit schillernden Namen wie Pflichten-, Lastenheft, Fach- oder Feinkonzept produziert. Diese stellen dann die Grundlage für Angebote und die Durchführung des Projektes dar und werden oft nach Jahren noch Gegenstand einer gerichtlichen Interpretation, wenn sich die Vertragsparteien nicht über das Projektergebnis einigen können. Solche Projekte würde die Standish Group klar als "gescheitert" einstufen. Wie nun entsteht dieser Teufelkreis und wie kann er durchbrochen werden?

Ein erster Fehler der oben genannten klassischen Projektdokumente ist, dass sie unter der sogenannte Analyseparalyse leiden. Das heißt: um eines dieser klassischen Dokumente in einer Weise zu erstellen, die gewährleistet, dass es während der Gesamtdauer eines Projektes unverändert Bestand hat, müssten die Parteien schier Übermenschliches leisten.

Die Analyse der bestehenden und/oder geplanten Geschäftsprozesse müsste mit absoluter Sicherheit lückenlos sein, was sie in der Praxis nie ist. Die daraus erstellten Konzepte müssten in 100% der Fälle genau die geplanten Geschäftsprozesse abbilden, wozu die Systemarchitekten diese Geschäftsprozesse zu 100% verstehen und die Analysten die Konzepte der Systemarchitekten zu 100% kontrollieren können müssten. Nichts davon ist in der Praxis der Fall.
Schließlich aber, selbst wenn Analyse und die Systemarchitektur 100% korrekt wäre, läge dem Projekt der größte Stolperstein noch im Wege. MSF nennt diese Stolperstein "Scope Slip". Dieser Begriff nimmt Bezug auf die Tatsache, dass sich während der Laufzeit eines Projektes der Fokus eines Projektes verändern kann.

Die Zukunft ist unsicher - sonst wäre sie nicht die Zukunft. Selbst wenn der Kunde seinen Laden so "im Griff" hätte, dass nicht durch einen Wechsel im Management "die Wahrheiten von gestern plötzlich Lügen" sind. Auch ein solcher Kunde hätte wohl nicht alle von außen auf sein Unternehmen wirkenden Faktoren im Griff. Selbst wenn sich der Markt des Kunden während der Laufzeit des Projektes nicht ändert, so können und werden sich dennoch zum Beispiel gesetzliche Rahmenbedingungen ändern.

Selbst wenn all das nicht eintritt und das Projekt zufällig erfolgreich ist, so ist eben dieser Erfolg, wie schon eingangs erwähnt, nicht planbar und nicht wiederholbar, sondern ein einmaliger Glücksfall. Was also tun? MSF empfiehlt sogenannte lebende Dokumente nach dem Grundsatz "baseline early - freeze late".

Lebende Dokumente funktionieren wie folgt: Ein erster grob strukturierter und leidlich vollständiger Entwurf aller Analysen und Konzepte steht allen Teammitgliedern so früh wie möglich zur Verfügung. Diese Entwürfe erheben keinerlei Anspruch auf Vollständigkeit. Stattdessen kann jedes Teammitglied bereits zu einem frühen Zeitpunkt Einblick in die Ideen und Überlegungen der Analysten, Planer und Systemarchitekten nehmen.
Während diese Dokumente im Rahmen eines sorgsam gepflegten "Change Control"-Prozesses weiterentwickelt werden, erhalten die Teammitglieder beständig Updates der Dokumente, welche die Änderungen gegenüber der Vorversion deutlich hervorheben und wichtige Änderungen sowie die Diskussionsprozesse, die zu diesen Änderungen geführt haben, dokumentieren. Die Dokumente - insbesondere die der Systemarchitekten - sind auch zu Beginn und sogar lange Zeit während der Development Phase noch nicht geschlossen und werden erst kurz vor Fertigstellung des gesamten Featuresets eingefroren. Die funktionale Spezifikation wird also erst mit Erreichen des letzten Meilensteins der Entwicklungsphase eingefroren, also unmittelbar vor dem major Meilenstein "Scope Complete/First Use".

Was sich zunächst anhört wie die Hölle auf Erden für jeden Entwickler und Codierer, ist in Wirklichkeit ihr Paradies und ihre Existenzberechtigung zugleich. Mal ehrlich - wer könnte sich schon vorstellen, aufgrund einer von Anfang an vollständigen und unveränderlichen Spezifikation zu codieren. Gäbe es einen langweiligeren Job auf der Welt - außer vielleicht Steine klopfen? Was aussieht wie die Hölle für Programmierer, fordert und fördert in der Realität ihre Kreativität und ihren ohnehin bereits scharfen Verstand.

Wie aber mit lebenden Dokumenten leben (besonders überleben)? Wie lebt man mit kreativen Entwicklern und ständig wachsenden Featurelisten? Wie schafft man es, gleichzeitig Zeitpläne einzuhalten und Budgets nicht über Gebühr zu strapazieren? Hier nun gibt MSF als Antwort die bereits zu Beginn des Projektes festgelegte Entscheidungsmatrix, die als von allen Projektbeteiligten abgesegnete Entscheidungsgrundlage dient. Diese Entscheidungsmatrix legt nichts weiter fest, als die Antwort auf die Frage, welche Parameter während des Projektes fix und welche variabel sein sollen, wo gespart werden darf und wo investiert werden muss.

 

Vorgefertigte Entscheidungen nach Entscheidungs-Schema

Bei der Entscheidungsmatrix des MSF handelt es sich nicht um eines jener betriebswirtschaftlichen akademischen Monster, die den Analysten bei der Erinnerung an ihr Studium Schweißperlen auf die Stirn treten lassen. Das Konzept sieht vor, sich ausschließlich um drei Parameter und eine von drei Einstellungsmöglichkeiten für jeden dieser Parameter Gedanken zu machen. Es wird gleich gezeigt werden, dass durch einen weiteren produktiven Vorschlag diese drei mal drei Matrix noch weiter vereinfacht wird. Diese fördert somit harte und beständige Entscheidungen nach einem vorher festgelegten und von allen Projektbeteiligten inklusive dem Kunden akzeptierten Entscheidungsschema.

Um es gleich vorweg zu nehmen, die in dieser Matrix gesetzten Häkchen sind nur einer von vielen möglichen Vorschlägen, wie die Pyramide aus Ressourcen, Zeitplan und Featureliste in der Balance gehalten werden kann. Eine Regel für diese Entscheidungsmatrix gilt jedoch: In jeder Zeile und in jeder Spalte darf nur ein Häkchen stehen. Dies vorausgesetzt, kann das Entscheidungsschema für das Projekt und das Release, zu dem die in B1 gezeigte Matrix gehört, wie folgt abgeleitet werden:

1. Die Ressourcen (wahrscheinlich Personal und/oder Geld) sind beschränkt.

2. Der Zeitplan soll möglichst optimiert, das heißt soweit möglich verkürzt werden. Daraus folgt:

3. Es muss akzeptiert werden, dass in diesem Projekt und diesem Release Features möglicherweise nicht realisiert werden.

Wenn es nun also für das Projektteam zum "Schwur" kommt wenn sich tatsächlich, wie oben beschrieben, ein wichtiges Planungsdokument während der Development Phase ändert wenn also zum Beispiel neue unbedingt notwendige Features in das Projekt eingeführt werden - wie sehen dann die Entscheidungsalternativen aus? Können zusätzliche Entwickler in das Projekt gesteckt werden? Nein, die Ressourcen sind ja als beschränkt definiert. Kann eine Verzögerung des Zeitplanes hingenommen werden? Nein, die Definition gibt vor, dass in diesem Projekt und für dieses Release der Zeitplan zu optimieren ist (Auslieferung so schnell wie irgend möglich). Die einzig mögliche Entscheidung in diesem Projekt und diesem Release in der oben genannten Situation kann also sein, dass Features mit einer geringen Priorität gestrichen und/oder auf ein späteres Release verschoben werden müssen.

Da alle Projektbeteiligten sich von Anfang an auf dieses Entscheidungsschema als Grundlage für alle kritischen Projektentscheidungen geeinigt haben, kann es an dieser Entscheidung keinen Zweifel geben und die Frage kann nur lauten, welches sind die Features, die wir streichen und/oder verschieben müssen?
Natürlich sind in anderen Projekten und für andere Releases andere Entscheidungsschemata denkbar. In allen Fällen muss aber im Auge behalten werden, dass

1. alle kritischen Entscheidungen unter den so "eingeschworenen" Projektbeteiligten nur und ausschließlich nach dem vorher festgelegten Schema erfolgen, und

2. sich nur die variablen Parameter ändern dürfen, während der festgelegte (constraint) festgelegt bleibt.

So ist es im oben genannten Entscheidungsschema zum Beispiel möglich, selbst bei absolut negativem Projektverlauf innerhalb des Budgets und des Zeitplanes, wenn auch mit etwas eingeschränktem Featureset im ersten Release, zur Auslieferung des durch das Team gemeinsam getragenen Produktes zu gelangen.

 

Das Applikations-Architekturmodell des MSF

Über das Applikations-Architekturmodell des MSF erlaube ich mir an dieser Stelle hinwegzugehen. Die von MSF vorgeschlagene Architektur ist eine mehrschichtige Service-basierte Architektur, wie sie in der Vergangenheit von COM/COM+ zur Verfügung gestellt wurde und wie auch die .NET-Plattform sie wieder favorisiert.
Da in dieser Zeitschrift zu diesen Themen bereits ausführliche Darstellungen erschienen sind und weiterhin erscheinen werden, kann sich dieser Artikel weitgehend mit anderen Themen befassen.

 

Proaktives Risikomanagement nach MSF

Natürlich ist jeder schief gewickelt, der glaubt, in seinem Unternehmen nur ein Vorgehensmodell wie MSF einführen zu müssen und schon gehörten sämtliche möglichen Projektprobleme ein für allemal der Vergangenheit an. Im Gegenteil definiert das MSF sogar einen eigenen Regelkreis, mit Hilfe dessen mögliche Probleme frühzeitig erkannt, bekämpft und vermieden werden können.

Wer kennt das nicht, da sitzen in einem Projektteam einerseits jene Leute zusammen, die von der Sache überzeugt sind, die die Vision verstanden haben und endlich loslegen wollen. Diese Anpacker, wie sie mal genannt werden sollen, wollen endlich loslegen und realisieren. Im gleichen Team sitzen aber auch die Nörgler, die "Reichsbedenkenträger", denen keiner was recht machen kann, die bei jedem noch so guten Vorschlag Bedenken haben und "aus dem Bauch heraus" schon wissen, was da wieder alles schief gehen wird.

Wie können diese beiden Gruppen versöhnt werden? Wie können beider Interessen gewahrt und beider wertvolle Fähigkeiten für das Projekt genutzt werden? Was kann Risikomanagement dazu beitragen?

Risikomanagement nach MSF stellt einen Regelkreis dar. An dessen Anfang steht wie so oft die Definition des Wortes Risiko:
Ein Risiko ist ein Problem, das auf seinen Einsatz wartet, sprich: ein Problem in Lauerstellung.

 

Risikoidentifikation

Der Einstieg in den Regelkreis des Risikomanagement geschieht über die Identifikation von Risiken. Dazu wird ein kreativer Prozess der Zusammenarbeit im Team innerhalb eines sogenannten Risk Assesment etabliert (zum Beispiel Brainstorming, Brainwriting etc.). Die Suche nach "potentiellen Problemen" kann dabei aus zwei Richtungen erfolgen und beide sind gleichberechtigt:

• Potentielle Probleme und ihre wahrscheinlichen Konsequenzen werden aufgezählt.

• Potentielle Konsequenzen und ihre wahrscheinlichsten Ursachen werden aufgezählt.

So entsteht eine Liste von potentiellen Problemen (Risiken), die nicht mehr ausschließlich von Bauchgefühlen beherrscht wird, sondern neben einer Risikoquelle auch die Bedingung (Trigger) nennt, unter der eine bestimmte Konsequenz eintreten und damit zum Problem werden könnte. Risikomanagement kann so

• auf klar ausgedrückte potentielle Probleme aufsetzen, die in eindeutiger Weise Risikobedingung und Problemkonsequenz aufzeigen (Risk-Statement) und

• leicht verständlich definierte potentielle Probleme beschreiben und für alle Projektbeteiligten sichtbar machen.

 

Risikoanalyse

Im nächsten Schritt muss für jedes einzelne Risk Statement eine Analyse erfolgen, die eine Quantifizierung der Risiken zum Ziel hat. Im Risikomanagement großer Versicherungsgesellschaften gibt es eine Menge zum Teil hochmathematisch begründeter Verfahren, um Risiken zu quantifizieren, das heißt

1. die Wahrscheinlichkeit zu bestimmen, mit der ein Risiko zum Problem werden wird, und

2. die Schadenshöhe zu bestimmen, die aus dem zum Problem gewordenen Risiko folgt.

Es spricht wenig dafür, im Projektmanagement ähnlich genaue und umfangreiche Untersuchungen zur Quantifizierung von Risiken durchzuführen. Auch hier ist wieder die Fokussierung auf das eigentliche Ziel wichtig. Das eigentlich Ziel aber ist, die wichtigsten Risiken in Form einer Top 10 oder Top 100 Liste zu identifizieren und sich in der Folge hauptsächlich mit diesen Risiken auseinander zu setzen.

 

Wer bewertet

Grundsätzlich werden für jedes Risiko sechs Bewertungen entsprechend den sechs Teamrollen abgegeben. Sollten Function Teams gebildet worden sein, muss jedes Function Team für sich genau eine Bewertung je Risiko gegebenenfalls durch Diskussion ermitteln.

 

Welche Werte werden ermittelt?

Die Wahrscheinlichkeit des Eintretens des Triggerereignisses, welches aus dem Risiko ein Problem macht, wird mit einem Prozentwert zwischen 0 und 99 geschätzt. Bewährt haben sich hier Stufen von 5-10 %, so dass eine Wahrscheinlichkeit zum Beispiel mit 0,2 (=20%) angegeben werden kann.

Die Schadenshöhe wird nicht in Geldbeträgen notiert, wenn auch diese Geldbeträge ein wichtiger Hinweis auf die möglichen Schadensfolgen sein können und, soweit ohne weitere Recherchen bekannt, entsprechend notiert werden sollten. Die Bewertung der Schadenshöhe erfolgt entsprechend "nur" relativ mit einer Maßzahl auf einer willkürlich gewählten Skala. Bewährt hat sich hier eine Skala von 0-5. Diese gibt sowohl die Möglichkeit, einen möglichen Schaden mit 0 (wie kein Schaden) oder aber auch mit 5 (Projekt gestoppt, gefährdet etc.), sowie mit ganzzahligen Zwischenstufen zu bewerten.

Der Wert 0 bei Wahrscheinlichkeit und Schadenshöhe ist oft umstritten, hat jedoch den Vorteil, dass es einzelnen Teamrollen möglich ist, ein Risiko, dass sie für unwichtig halten, stärker abzuwerten, als dies mit einem Wert größer Null möglich wäre.

Nachdem die Wahrscheinlichkeit mit der relativen Schadenshöhe multipliziert wurde, entsteht für jedes Risiko genau eine relative Maßzahl je Teamrolle

 

Die Top 10-Liste

Die Bewertungen der Teamrollen je Risiko können nach einfachen mathematischen Verfahren zusammengefasst werden. Zunächst reicht es für die meisten Anwendungsfälle aus, je Risiko einen Durchschnittswert der Bewertungen der einzelnen Teamrollen zu bilden. Bewährt hat sich hier das arithmetische Mittel. Das arithmetische Mittel hat den Vorteil, dass die Bewertungen der einzelnen Teamrollen gleich gewichtet werden. Das heißt, das Risiko wird aus allen sechs Blickwinkeln mit der selben Ernsthaftigkeit und Professionalität bewertet.

In manchen Fällen wurde auch schon zusätzlich zum arithmetischen Mittel die sogenannte Standardabweichung der von den sechs Teamrollen abgegebenen Bewertungen ermittelt. Diese hat den Vorteil, dass sie eine Aussage darüber gibt, bei welchen Risiken die Bewertungen der Teammitglieder noch am weitesten auseinander liegen. Eine hohe Standardabweichung legt den Schluss nahe, dass ein Risk-Statement missverständlich formuliert ist, und nicht alle Teammitglieder wirklich von den selben Voraussetzungen ausgehen. Bei solchen Risiken könnte noch Diskussionsbedarf im Team bestehen. Eine entsprechend notwendige Diskussion darf jedoch nicht zu dem Ergebnis führen, dass Teammitglieder unter Druck gesetzt werden, ihre Bewertung zu ändern.

Am Ende der Risikoanalyse steht nun also eine Rangliste von Risiken, welche das Risiko mit der höchsten relativen Maßzahl an erster Stelle und alle weiteren in der Reihenfolge ihrer Maßzahl dahinter auflistet. Diese hilft sehr, weil es in den meisten Projekten weder sinnvoll noch wünschenswert ist, den Planungs-Aufwand für sämtliche Risiken hoch zu treiben. Stattdessen wird nun nur für die "Charts" geplant, das heißt für jene Risiken, die innerhalb unserer Rangliste auf den obersten Plätzen liegen.

 

Risikoplanung

Bei der Planung sind verschiedene Strategien möglich. Dies sind im einzelnen

• Risikovermeidung

• Schadensminderung

• Risikodelegation

• Krisenmanagement

Eine Risikovermeidungsstrategie ist bei vergleichbarem Aufwand natürlich immer den anderen Möglichkeiten vorzuziehen.

Eine Schadensminderungsstrategie kann zum Beispiel im Abschluss einer Versicherung gegen das entsprechende Schadensereignis bestehen. Von Risikodelegation spricht MSF zum Beispiel, wenn das entsprechende Risiko auf einen Subcontractor verlagert wird. Eine der beliebtesten Arten der Risikodelegationsstrategie auf Seiten des Kunden besteht entsprechend in der Vergabe von Festpreisprojekten.

Krisenmanagement kann ebenfalls eine erfolgreiche Risikomanagementstrategie sein, wenn es für den Krisenfall einfache und günstige Ausweichmöglichkeiten gibt. Auf Krisenmanagement sollte immer dann bevorzugt zurückgegriffen werden, wenn zur Risikovermeidung einfach nichts getan werden kann, das heißt man mit dem Risiko leben muss. Es muss für alle Top-Risiken neben einer möglichen Risikovermeidungsstrategie auch ein Krisenmanagementplan existieren.
Der entscheidende Mehrwert des Risikomanagement wird spätestens in der Planungsphase sichtbar. Für alle wichtigen Risiken bestehen jetzt nämlich Pläne, die den Schaden möglichst gering halten. Das heißt, selbst bei Eintritt des Trigger-Ereignisses muss das Team nicht mehr lange überlegen und diskutieren, wie reagiert werden soll. Stattdessen kann in einer solchen für das Projekt gegebenenfalls kritischen Situation sofort gehandelt werden.

 

Risikoverfolgung

In der nun folgenden Projektphase wird nun das Risikomanagement alleine darauf reduziert, zu beobachten, ob für eines der Risiken, welche sich im Fokus der Rangliste befinden, das Trigger-Ereignis eintritt und entsprechend der Krisenreaktionsplan ausgelöst werden muss.

 

Risikosteuerung

In der Phase unmittelbar vor der nächsten Bewertung der Risiken findet nun ein erneutes Risk Assesment statt. Dabei werden Statusreports für die bestehenden Risiken der Rangliste erstellt, neue Risiken identifiziert und überwundene Risiken aussortiert.

Es spricht an dieser Stelle übrigens viel dafür, überwundene Risiken nicht einfach zu vergessen und in der Schublade oder dem Papierkorb verschwinden zu lassen. Stattdessen sollte eine Art Wissensdatenbank bestehen, die es ermöglicht, ganz besonders auch die überwundenen Risiken, mit allen dazu vorhandenen Informationen, zu speichern. Schließlich beinhalten gerade diese Risikodaten wertvolle Informationen über erfolgreiche Managementstrategien und gelungene Risikovermeidung. Dieses Wissen kann in weiteren Projekten von großem Nutzen sein.

Natürlich muss unmittelbar im Anschluss an die Risikosteuerungsphase der Regelkreis erneut durchlaufen werden, das heißt eine erneute Analyse/Bewertung der Risiken stattfinden und für neu hinzugekommene Risiken eine Risikomanagementstrategie geplant werden.

Der Regelkreis wird in einem Projekt mindestens zu den nach außen sichtbaren Meilensteinen einmal, also bis zum Ende des Projektes insgesamt vier Mal durchlaufen. Bei besonders risikoreichen Vorhaben ist es ratsam, die Anzahl der Durchläufe signifikant zu erhöhen (zum Beispiel auch zu jedem Interim-Meilenstein)

 

Weitere Module

Ein wichtiger Vorteil des MSF gegenüber anderen Projektmanagementmethoden wurde bereits Eingangs erwähnt. Das MSF beschränkt sich nicht auf die Applikationsentwicklung alleine, sondern beinhaltet auch ein Modell für Infrastrukturprojekte. Darüber hinaus konzentriert sich das ESF nicht alleine auf das Projektmanagement mit Hilfe von MSF. Entsprechend gibt es integriert im ESF ein Modul MOF (Microsoft Operations Framework), dass sich nahe an ITIL anlehnt und einen Geschäftsprozess für die auf das Projekt folgende Phase des Betriebs eines IT-Systems beschreibt.

Schließlich vergisst das ESF auch die Phase der Planung einer IT-Infrastruktur/-Anwendungsstruktur nicht. Das Modul Enterprise Architecture beschreibt entsprechend, wie in einem schnell wachsenden Unternehmen ein Geschäftsprozess etabliert werden kann, der dem Unternehmen hilft, seine IT-Infrastruktur und -Anwendungsstruktur so zu planen, dass diese auch nach dem Wachstum noch den Notwendigkeiten der Unternehmens-IT angemessen ist.

Nicht zuletzt ist die rechtzeitige Planung der IT-Landschaft für ein schnell wachsendes Unternehmen der entscheidende Erfolgsfaktor für die aus dieser Planung resultierenden Projekte. Ein Projekt kann nur erfolgreich sein, wenn auch nach seinem Abschluss das erstellte IT-System noch sinnvoll benutzt werden kann und nicht etwa der Auftraggeber inzwischen aufgrund von Änderungen in der Unternehmensstruktur und/oder Unternehmensgröße ein ganz anderes System bräuchte.

 

Fazit

Das MSF stellt ein Vorgehensmodell zur Verfügung, das einerseits in ein Geschäftsprozess-Modell für den gesamten Lebenszyklus einer IT-Landschaft eingebettet ist, es somit also ermöglicht, große Projekte mit Hilfe dieses Vorgehensmodells zu stemmen. Andererseits aber ist es als Framework auch leichtgewichtig genug, um zarte Projektpflänzchen nicht unter unnötigem Verwaltungsaufwand zu begraben und gibt so einen guten Einstieg für Unternehmen oder IT-Abteilungen, die bisher keinen organisierten Geschäftsprozess zur Durchführung von IT-Projekten eingeführt haben.

Wer ausgiebigere Informationen zu diesem Thema sucht, sollte den Workshop zum Thema MSF im Rahmen der Advanced Developers Conference am 6. November dieses Jahres nicht versäumen (www.ms-adc.de).
Zusätzliche Informationen sowie Seminare und Consulting-Angebote finden Sie unter folgenden Links:
http://www.modulo3.de/soq/step_on_quality.html
http://www.modulo3.de/seminare/seminare.html
https://www.microsoft.com/msf/
http://cis.cs.tu-berlin.de/~icsewow/v2n2/v2n2-10.html
http://www.advanced-developers.de