Begriffe Systemkontext

Ein zu entwickelnde System interagiert immer in irgendeiner Art und Weise mit seiner Umwelt. Es bietet Benutzern und externen Systemen bestimmte Funktionalitäten an und fordert Daten von diesen ab.

Das Abstecken der Systemgrenze sollte früh im Projekt passieren durch die Erstellung eines Systemkontext-Diagramms. Neben den Interaktionspartnern liefert die Modellierung des Systemkontextes die Antwort auf die Frage, was zum System gehört und was nicht. Als Faustregel kann dabei gelten: Alles, was im Verantwortungsbereich des Systems liegt, gehört zum System. So wird klar, dass dies unabhängig von der Tatsache ist, ob eine Komponente extern entwickelt wird oder nicht.

Bsp. Systemkontext Mobiltelefon

Bei der Modellierung wird für das Systemkontext-Diagramm ein SysML Use Case Diagram verwendet. In der Mitte steht das System (Block vom Stereotyp «System»). Um das System herum gruppieren sich die sog. Akteure. Das sind die Benutzer oder externen Systeme, die mit dem System interagieren. Ein Akteur wird dabei als Rolle verstanden (engl. actor).

Das Standard-Symbol für einen Akteur ist das Strichmännchen – auch für Systeme. Es macht aber durchaus Sinn, sich eigene Stereotypen zu definieren, die mit anderen Symbolen kennlich machen, um was es sich handelt. Ein Symbol für ein externes System ist dabei sehr empfohlen.

Je nach Bedarf lassen sich noch Symbole für Sensoren, Aktuatoren oder Umwelteinflüsse (Wetter, Wärme und dergleichen) einführen. Die SysML definiert diese Typen bereits in den Non-Normative Extensions, also Erweiterungen, die nicht zum Standard selbst gehören. Auch ein Akteur «Mechanical element» kann für viele Projekte Sinn machen.

Akteur Stereotypen

Was aber ist überhaupt der Nutzen? In der Regel geben diese Konzepte eine Marschrichtung vor, auf der sich die Organisation befindet. Sie sollen verhindern, dass jeder in eine andere Richtung rudert und sich das Boot im Kreis dreht. Diese Konzepte legen den Fokus auf bestimmte Aktivitäten und helfen bei Entscheidungen zwischen Alternativen, diejenige zu wählen, welche die über alles gestellte Vision am besten unterstützt.

Vision

Eine Vision besteht in der Regel aus einem Satz und beschreibt einen zu erreichenden Zustand in der fernen Zukunft. ‘Fern’ bezieht sich dabei normalerweise eher auf einen Zeitrahmen von zehn Jahren oder mehr. Der beschriebene Zustand klingt meist sportlich, sollte aber dennoch grundsätzlich realistisch sein. Die Vision sollte griffig formuliert sein, so dass jeder Mitarbeiter sie auswendig weiß. Die regelmäßige Vermittlung der Vision ist Aufgabe der Managements. Wenn Sie einen Mitarbeiter nachts aus dem Schlaf holen und nach der Vision fragen, sollte er nicht lange drüber nachdenken müssen.

Werte

Werte (values) oder auch Thesen werden vielfach formuliert, um grundsätzliche Aussagen zu manifestieren. Die Aussagen ändern sich normalerweise nicht. Sie geben oft auch zwischenmenschliche und ehtische Aspekte wieder, denen sich die Organisation verschreibt. Ein Blick in die ISO 26000 lohnt vielleicht in diesem Zusammenhang.

Ein paar Beispiele für Formulierung von Werten:

• Wir begegnen Menschen mit Respekt und Würde.
• Wir fördern Teamwork und Zusammenarbeit.
• Wir gehen ehrlich, direkt und vertrauenswürdig miteinander um.
• Wir respektieren Gesetze, Vorschriften und ethische Grundsätze.
• Wir verstehen die Bedürfnisse unserer Kunden.
• Wir honorieren den Einsatz Einzelner für Kunden, Zulieferer, die Gesellschaft und untereinander.
• Wir verbessern unsere Leistungen fortwährend.
• Wir bieten unseren Mitarbeitern gute Arbeitsbedingungen in einer innovationsfördernden Arbeitsatmosphäre.
• Wir leben standardisierte Prozesse und verbessern diese kontinuierlich.

Ziele

Prozessverbesserung leitet sich aus Geschäftszielen ab. Im CMMI-Modell ist dies in mehreren Process Areas reflektiert. Das ganze Modell zielt darauf ab, mit Prozessen die business objectives zu erreichen. Im Prozessgebiet Organizsational Process Focus geht es zunächst darum, die Bedürfnisse an die Standard-Prozesse aus den Geschäftszielen und Unternehmens-Standards abzuleiten. Während dies auf Maturity Level 3 noch qualitativ passiert, leitet das Prozessgebiet Organizational Process Performance auf Maturity Level 5 quantitative Prozessziele aus den Geschäftszielen ab.

Management gibt Jahresziele vor, die konkrete Schwerpunkte für die Prozessverbesserungsaktivitäten eines Kalenderjahres setzen. Idealerweise sind Ziele SMART formuliert, d.h.

• spezifisch (so präzise wie möglich)
• messbar (quantitativ erfassbar)
• anwendbar (akzeptiert und nützlich für die Stakeholder)
• realistisch (umsetzbar, erreichbar)
• terminiert (mit Datum, zu dem es erfüllt sein soll)

Bei der Fomulierung von Prozesszielen kann und muss man allerdings davon oft abweichen. Sind Ziele zu spezifisch formuliert, bleibt dem Prozessteam kein Handlungsspielraum mehr in der Umsetzung. Vielfach muss die optimale Lösung erst erarbeitet werden. Die Messbarkeit gestaltet sich gerade bei weniger reifen Organisationen oft als problematisch, da bisher zu dem Thema keine verlässlichen Daten erhoben wurden. Gerade im Hinblick auf die verfügbaren Ressourcen sollten nicht zu viele Ziele formuliert werden; jedes einzelne sollte vom Aufwand her, aber von der grundsätzlichen Machbarkeit umsetzbar sein. Für Jahresziele ist das “T” automatisch gesetzt.

Aber auch bei nicht-SMARTen Zielen macht es Sinn, den eigentlich Zweck, sowie eine grobe Umsetzungsstrategie zu formulieren, etwa

• Wir verbessern … durch die Etablierung konsistenter …
• Wir erhöhen … durch Verbesserung unserer XY-Methodik.
• Wir verringern … um 5% im Vergleich zum Vorjahreswert durch …

Leitlinien

Jede Organisation strebt es an, einheitliche Prozesse zu etablieren. Die “Leitplanken”, in denen sich diese Prozesse bewegen, sind die Leitlininen (oder policies) der Organisation. Leitlinien formulieren Rahmenbedingungen für das tägliche Handeln und sind insofern wesentlich konkreter formuliert als Vision, Werte oder Ziele. Dennoch stehen die Leitlinien natürlich noch über den konkreten Prozessbeschreibungen und sind insofern so abstrakt, dass sie noch keinen Prozess beschreiben, aber so konkret, dass sie bestimmte Themen direkt ansprechen.

Der Satz an Leitlinien ändert sich entsprechend öfters als Werte oder gar Vision. Von Jahr zu Jahr mag mal eine Leilinie umformuliert werden. Einige Leitlinien werden vielleicht ergänzt, weil es notwendig wird, bestimmte Management-Erwartungen zu formulieren. Nach Jahren wird evtl. auch mal eine Leitlinie entfernt, da die darunter liegenden Prozesse so etabliert sind, dass die Einhaltung der Leitlinie als selbstverständlich gilt.

In der Regel gibt es wesentlich mehr Leitlinien als Werte. Sinnvoll ist es dabei, die einzelnen Leitlinien zu gruppieren unter Überschriften wie Kunden, Mitarbeiter, Prozesse und darunter etwa Prozessmanagement, Projektmanagemen, Entwicklung, Unterstützende Prozesse (angelehnt an die CMMI-Prozessgebietkategorien).

Beispiele:

• Wir entwickeln Anforderungen in enger Abstimmung mit unseren Kunden.
• Wir validieren Anforderungen mit den Beteiligten durch Prototypen, Simulationen, Analysen und andere geeignete Methoden.
• Wir verwalten Anforderungen aller Ebenen strukturiert und pflegen Attribute und Traceability.

CMMI fordert für jede Process Area eine Organizational Policy (Generic Practice 2.1); das sind die Leitlinien. Dabei ist es nicht relevant für jede Process Area eine eigene Leitlinie zu formulieren; eine Leitlinine kann auch für mehrere Process Areas herhalten.

Leitlinien sind immer so konkret formuliert, wie es nötig ist, um die Arbeit der Mitarbeiter entsprechend zu leiten. Die Prozessgruppe hilft den Projekten und Mitarbeitern, die Leitlinien des Managements zu befolgen, indem Methoden, Vorlagen und Guideline schafft. Somit werden die Prozessmenschen zu den “Guten”. Wenn Sie diese Sichtweise etablieren können, haben Sie’s geschafft ;-)

In Buchform findet man das Modell in der neuen Version schon bei Amazon.

Bei Anywhere24 gibt es ein Poster zum Download in deutsch oder englisch oder gegen 5€ Unkostenbeitrag per E-Mail zu bestellen. Die Poster basieren auf der vom SEI freigegebenen Übersetzung.

“Die SOPHISTen”, wie sich die Mitarbeiter selbst nennen, sind bekannt als die Experten in Sachen Requirements Engineering. Gegründet wurde die Firma vor 15 Jahren durch Chris(tine) Rupp, Autorin zahlreicher Methodiken und Bücher wie etwa das sehr zu empfehlende Standardwerk Requirements-Engineering und -Management oder aber UML 2 glaskar.

Warum erzähl ich das, wenn ich doch eigentlich etwas zum CPRE schreiben will? Nun, durch den Jahresend-wir-haben-noch-Geld-Effekt vieler Firmen, sind alle Sophist-Trainer ausgebucht und so habe ich das Glück, dass die OberSOPHISTin höchstpersönlich das Training hält. Super spannend, zwischen den Folien ab und zu etwas von dem reichen Erfahrungsschatz abzugreifen. Schade, dass ich jetzt schon weiß, dass die ganzen Ideen, die ich mir notiere, aus Zeitgründen erstmal wieder im Off verschwinden werden.

However, Chris Rupp ist auch Hauptgestalterin des CPRE und damit sind wir wieder beim Thema. Das Zertifikat wird ausgegeben vom International Requirements Engineering Board (IREB), ein Gremium, das sich rechtlich als eingetragener Verein (e.V.) formiert und inzwischen international aktiv ist. Das IREB wurde 2007 von Chris Rupp gegründet; sie ist derzeit auch 1. Vorsitzende. Um dem IREB einen hohen Stellenwert zu verschaffen, wurden in das Board nur Mitglieder aufgenommen, die einen Namen in der RE-Szene haben und insofern einige Kriterien erfüllen (Buchauflagen über 10.000 u.ä.).

Man kann ohne Zweifel sagen, dass das CPRE-Zertifikat das international anerkannteste Zertifikat im Requirements Engineering ist. Auch wenn derzeit noch viele der Board Members aus Europa sind, werden CPRE-Kurse weltweit absolviert und dementsprechend in alle möglichen Sprachen übersetzt. Manche Staaten wie Malaysia haben CPRE an Universitäten eingeführt.

Vorbereitung

Auf der IREB-Website gibt es den offiziellen Lehrplan des Foundation Level zum Download; er ist gerade in Version 2.1 erschienen. Jeder Trainer darf den Lehrplan für Seminare verwenden; Trainingsanbieter sind in keinster Weise akreditiert.

Der Lehrplan listet alle Kapitel und Abschnitte auf mit der Benennung der beabsichtigten Lernziele und einer groben Erläuterung des Stoffes. Der Lehrplan kann insofern nur als Übersicht gelten; für ein Selbststudium ist er zu dünn.

Wer sich das Geld für ein Seminar sparen will, kann zum Buch greifen (siehe Abbildung). Das Buch gliedert sich in die neun Hauptthemen des Lehrplans und bietet einen hervorragenden Überblick zum Basiswissen im Requirements Engineering. Die Lehrinhalte sind wie folgt:

1. Einleitung und Grundlagen. Warum RE?; Definitionen von Grundbegriffen; Einbettung in gängige Vorgehensmodelle; Grundlagen Kommunikationstheorie; die Rolle des Requirements Engineer; Arten von Anforderungen (funktionale, nicht-funktionale usw.)
2. System und Systemkontext abgrenzen. Systemkontext, Systemgrenze, Kontextgrenze; Datenflussdiagramm (DFD); UML Use Case Diagramm
3. Anforderungen ermitteln. Anforderungsquellen; Stakeholder; das Kano-Modell; verschiedene Ermittlungstechniken (Interview, Fragebogen, Brainstorming usw.)
4. Anforderungen dokumentieren. Warum dokumentieren?; Struktur-, Funktions- und Verhaltensperspektive; natürlichsprachliche vs. modellbasierte Dokumentation; Standardgliederungen von Anforderungsdokumenten; Gliederungen von nicht-funktionalen Anforderungen, Randbedingungen, Qualitätsanforderungen; Qualitätskriterien (bewertet, eindeutig, korrekt usw.); Glossar
5. Anforderungen natürlichsprachlich dokumentieren. Probleme der Kommunikation; Transformationseffekte (Tilgung, Verzerrung, Generalisierung); Satzschablone (Requirement Template)
6. Anforderungen modellbasiert dokumentieren. Modellbegriff; Zielmodelle (natürlichsprachlich, Und-Oder-Bäume); UML Use Case Diagramme (Use Case, Akteur, Systemgrenze, include/exclude-Beziehung); Use Cases Spezifikation (Vorbedingung, Ergebnis usw.); Strukturperspektive mit UML Klassendiagrammen (Assoziation, Generalisierung, Aggregation/Komposition, Multiplizitäten) und Entity-Relationsship-Diagrammen (Entitätstyp, Beziehungstyp, Attribut, Kardinalitäten); Funktionsperspektive mit UML Aktivitätsdiagrammen (Aktion, versch. Knoten, Fork/Join usw.) und Datenflussdiagrammen (Prozess, Terminator, Datenspeicher, Datenfluss); Verhaltensperspektive mit UML-Zustandsdiagrammen (Zustand, Ereignis, Bedingung, Eintrittspunkt, Super-/Subzustand)
7. Anforderungen prüfen und abstimmen. Ziele von Prüfungen (d.h. Reviews); Qualitätsaspekte von Anforderungen (Inhalt, Dokumentation, Abgestimmtheit); Prinzipien der Prüfung von Anforderungen; Techniken zum Prüfen (Stellungnahme, Walkthrough, Inspektion); Konfliktmanagement bei der Abstimmung von Anforderungen
8. Anforderungen verwalten. Attribute von Anforderungen (Priorität usw.); schablonenbasierte Attributierung; verschiedene Attributtypen; Sichten auf Anforderungen; Priorisierung von Anforderungen; Verfolgbarkeit (Traceability) von Anforderungen; Versionierung von Anforderungen (Versionsnummern, Konfigurationen, Basselines); Anforderungsänderungen (CCB, Änderungsantrag, Impact-Analyse
9. Werkzeugunterstützung. allgemein, Modellierungs-Tools, Requirements Management Tools, Einführung von Tools

Schwierigkeitsgrad

Ich mache die Prüfung erst morgen, daher kann ich mir noch nicht wirklich ein abschließendes Urteil erlauben, aber die Übungsfragen während des Seminars waren für mich alle ohne große Probleme zu beantworten.

Wer nicht erst seit gestern Anforderungen spezifiziert oder in ähnlicher Mission unterwegs ist und vielleicht schon mal in das ein oder andere Buch hineingeschaut hat, dem werden die meisten der vorgestellten Konzepte schon mal begegnet sein.

Ein großer Schwerpunkt der Prüfung liegt wohl auf dem modellbasierten Dokumentieren mit UML. Wer schon mit UML modelliert hat, braucht hier nichts zu fürchten; es werden nur die grundlegenden Elemente verwendet. Man muss aber schon wissen, was ein Use Case-, Klassen-, Aktivitäts- und Zustandsdiagramm ist, welche Elemente es enthält und wofür man es im Rahmen des modellbasierten RE einsetzt.

Es ist ein Multiple-Choice-Test. Die Fragestellungen lauten etwa

• Welches sind die beiden wahrscheinlichsten Gründe…? (zwei Kreuzchen machen)
• Welche der folgenden Aussagen ist falsch? (ein Kreuzchen machen)
• Welche drei der folgenden… sind nicht…? (drei Kreuzchen machen)
• Kreuzen Sie ‘richtig’ oder ‘falsch’ an für die folgenden Aussagen! (für jede Aussage ein Kreuzchen machen)

Ein Frage bringt unterschiedlich viele Punkte. Bringt eine Frage bspw. 3 Punkte, zählt jedes richtige Kreuz 1/3 Punkt; für jedes Kreuz, das aber falsch gesetzt wurde, wird wieder 1/3 Punkt abgezogen. Man kann für eine Frage keine Minuspunkte bekommen, aber, wenn zwei Kreuzchen korrekt sind und eins falsch, bekommt man für die Frage nur 1 Punkt. Raten lohnt also nicht!

Man hat für 45 Fragen 75 Minuten Zeit. Das ist nicht übermäßig viel, wenn man bedenkt, dass manche Fragen zunächst mal in 15 Zeilen Prosatext die Fragestellung einleiten. Mit 60% hat man bestanden.

Dann mal viel Erfolg!

Es ist etwa 340 Seiten stark und bietet auf den ersten knapp 80 Seiten eine Einführung in UML und im zweiten Teil eine Einführung in das Tool selbst. Die gegenwärtige Version enthält die Anpassungen bis zur aktuellen Enterprise Architekt Version 9.1.

• Das API für das Merge-Plugin ist nun frei verfügbar.
• Generic Tables können nun als HTML-Tabellen exportiert werden.
• Funktionalitäten bzgl. Darstellung und Refactoring sind nun per API für Plugins zugänglich.
• Performance-Verbesserungen beim Aktualisieren von TeamWork-Server-Projekten.

Das Zertifikat wurde in den letzten zwei Jahren von der GfSE in Anlehnung an das INCOSE SE Handbook entwickelt. Es ist komplett auf deutsch und soll dem Berufsbild des System-Ingenieurs ein neues Profil geben.

Inhaltlich beinhaltet die Zertifizierung neun Trainingsmodule:

• Grundlagen des Systems Engineering
• Übergreifende SE-Schnittstellen
• Schnittstellen zum Projektmanagement
• Systems Engineering Management
• Anforderungsmanagement und V&V
• Realisationsprozesse
• Querschnittsfunktionen
• Operationelle Aspekte des SE
• SE Soft Skills

Ab sofort kann man sich bei rücker+schindele (München) oder bei oose (Hamburg) zum Level C (“Verstehen”) ausbilden lassen. Für 2012 ist Level B (“Anwenden”) geplant; irgendwann folgt Level A (“Beherrschen”), für das schon eine eigene Studienarbeit geschrieben werden muss.

Aber auch Level C hat es schon in sich und hat dadurch aber auch einen gewissen Wert.

• Gesamtdauer etwa fünf Monate
• Schulungsdauer je nach Anbieter etwa 12 Präsenztage
• 2 Stunden Prüfung (durch TÜV Rheinland und GfSE-Assessoren)

Wie ich von Sven-Olaf Schulze erfahre, lassen sich Level C und Level B in die internationalen INCOSE-Zertifikate ASEP und entsprechend CSEP übertragen. Level A wird allerdings nicht für ESEP anerkannt werden. Für ESEP sind 25 Jahre Berufserfahrung notwendig. Die GfSE ist hier bewusst einen anderen Weg gegangen, da diese Anforderung nicht angemessen schien.

Weitere Informationen gibt es zukünfitg unter http://sezert.de.

Auch wenn ich durch Tims Consulting-Tätigkeiten bei uns das Vorgehensmodell schon kenne, habe ich ich doch wieder einige Best Practices und Infos notieren können. Teilweise waren es Details, die mir noch nicht so klar waren, teilweise aber auch nur Dinge, die ich vielleicht noch deutlicher in unserer eigenen MBSE-Guideline klarstellen könnte.

Nach einem zügigen Durchlaufen über den Sinn und Zweck von MBSE (schließlich war es ein Anfänger-Tutorial), haben wir als Beispiel ein Waldbrandmelde-System in MagicDraw modelliert.

Hier mal in Kurzform meine Notizen, vielleicht hilft es jemandem:

• Um Pakete global unterscheidbar zu machen, sollten sie immer den Systemnamen enthalten. Für das Forest Fire Detection System (FFDS) also bspw.  FFDS_Requirements, FFDS_Structure usw.
• So wie ein Buch ein Inhaltsverzeichnis hat, sollte jedes Paket ein Content-Diagramm haben. Das ist ein Package-Diagramm, das den Inhalt des Pakets aufzeigt. In MagicDraw gibt es übrigens ein spezielles Content Diagram, das auch Inhalte der eingebunden Diagramme anzeigen kann.
• SysML kennt als Akteur nur die Strichmännchen. Man sollte sich eigene Kategorien (Akteur-Stereotypen) definieren, mindestens aber «External System», um zwischen menschlichen und nicht-menschlichen Akteuren unterscheiden zu können.
• Bei der Definition des Systemkontextes ist es oft schwierig abzugrenzen, ob es zum System gehört oder zum Systemkontext, also als Akteur modelliert wird. Als Faustregel kann gelten: Alles, was im Verantwortungsbereich des Systems liegt, gehört zum System. So wird klar, dass dies unabhängig von der Tatsache ist, ob eine Komponente extern entwickelt wird oder nicht.
• Es ist zu beachten, dass es sich bei der Modellierung des Systemkontexts um eine logische Systemgrenze handelt, nicht um eine physikalische.
• Als Akteure modelliert man die eigentlichen Fachadressaten, also im Beispiel das Fire Department und nicht etwa Internet.
• Stakeholder werden in der Regel nicht als Akteure des Systemkontextes modelliert, da sie nicht mit dem System interagieren. Dennoch kann es Sinn machen, wichtige Stakeholder zu modellieren, dann aber als Akteure in einem eigenen Diagramm.
• Die «include»-Beziehung zwischen Use Cases sollte nur verwendet werden, wenn der referenzierte Anwendungsfall von mehr als einem Anwendungsfall eingebunden wird, wenn als Redundanz vermieden wird.
• Beim Modellieren von Anwendungsfällen identifiziert man zunächst alle Anwendungsfälle zu einem bestimmten Akteur und assoziiert dann zu jedem gefundenen Anwendungsfall die anderen beteiligten Akteure.
• Das Modellieren von Aktivitätsdiagrammen ist eine Gradwanderung der Abstraktionsebene. Gewisse Design-Entscheidungen sind an dieser Stelle schon notwendig, damit die Aktivitäten nicht zu abstrakt und somit nutzlos bleiben. Andererseits befindet man sich bei der Modellierung von Anwendungsfällen immer noch in der Analyse, so dass die Aktivitäten nicht zu konkret werden dürfen, um sich spätere Design-Entscheidungen nicht zu verbauen.
• Nicht jeder Use Case muss durch ein Aktivitätsdiagramm verfeinert werden. Überlegen, was wirklich hilft!
• Anwendungsfälle können in Ausnahmefällen auch durch Zustandsdiagramme beschrieben werden. In der Regel passen aber Aktivitätsdiagramme besser. Zustandsdiagramme nur verwenden, wenn der Use Case sehr zustands-fokusiert ist.
• Use Cases sind eine Verfeinerung von funktionalen Anforderungen, so dass man eine «refine»-Beziehung vom Use Case zum Requirement zieht.
• Die SysML hat drei Abstraktionsebenen: (1) die Typebene in den Blockdefinitionsdiagrammen, (2) die Rollenebene in den Internen Blockdiagrammen, (3) die Instanzebene in den Parametrischen Diagrammen.
• In den bald erscheinenden SysML 1.3 sind einige Verbesserungen zum Einheitensystem (bspw. Umrechnung zwischen Einheiten) sind zu erwarten.
• In SysML sind für Anforderungen nur Name, ID und Text definiert. Alles andere (wie Priorität und dergleichen) wären Vorgaben, die dem SysML-Standard nicht zustehen.
• Im Produktbaum stellt man die Blöcke, aus denen das System besteht, mit einer gerichteten Kompositionsbeziehung dar. Im internen Blockdiagramm des System-Blocks werden diese Blöcke dann als Part Properties dargestellt. Diese entsprechen im bdd den Pfeilen (Assoziationsende) der gerichteten Komposition und bedeutet, dass das Part Property  nach dem Bauplan des entsprechenden Blocks gebaut ist.
• Die Konnektoren im Internen Blockdiagramm (ibd) stehen für Kommunikation im weitesten Sinne zwischen den beteiligten Parts.
• Man sollte für jeden Aspekt (information, electrical, mechanical) ein Internes Blockdiagramm erstellen.
• Der Name “Standard Port” ist eigentlich unglücklich, “Service Port” wäre netter gewesen, denn die Ports bieten Dienste an.
• Das SysML-Interface (Lolli-Darstellung) steht für eine Liste von Funktionen und hängt an einem Standard-Port.
• Um die drei Aspekte (information, electrical, mechanical) entsprechend darzustellen, erhält man auch drei Ports. Damit man weiß, dass diese zusammen gehören, sollten diese alle auf einem Standard Port liegen. Solche Nested Ports sind in SysML explizit erlaubt.
• In SysML 1.3 sind die Interfaces (Lollies) nicht mehr notwendig. Funktionen stehen dann in der Port-Definition selbst.

Ich werde bestimmt einige der Punkte in Zukunft nochmal aufgreifen.

Ich hatte heute Kontakt mit einem Berater von Seibert-Media, eine in Wiesbaden ansässige Firma, die viel Erfahrung aufweisen kann mit der Einführung firmenweiter Wikis.

Dabei ist der Begriff Wiki noch zu wenig und für viele ein vorbelegtes Unwort, denkt man doch zu leicht an Wikipedia. Confluence ist eigentlich eine komplette Kollaborations-Platform, die es ermöglicht, verschiedene Bereiche (Spaces) zu definieren, in denen man sich austauschen kann. Der entscheidende Unterschied in der Denkweise des Informationsaustausches ist der Übergang vom Push- zum Pull-Prinzip.

Während ich mit E-Mails jeden belästigen muss, der vielleicht an der Information interessiert sein könnte (push), kann man sich in einem Wiki bestimmte Inhalte abonnieren und erhält somit die Informationen, die für mich relevant sind (pull). Kommentare an Wiki-Seiten bieten einen direkten Austausch und bewirken einen enormen Mehrwert.

Durch diese Art der Informationsbereitstellung bin ich besser darüber informiert, wer sich mit welchen Themen auskennt oder welches Projekt gerade welches Problem gelöst hat. Gerade in verteilten Standorten ermöglicht dies erst die Zusammenarbeit. Microblogging (Statusmeldungen á la Facebook) informieren darüber, woran ein Mitarbeiter gerade arbeitet.

Die oberste Prämisse dabei ist natürlich, dass ein solcher Wissensaustausch auch vom Unternehmen gewollt ist. Manche Firmen müssen hier erst einen Kulturwandel durchlaufen – das ist nicht einfach und erfordert Zeit und viel Fingerspitzengefühl bei der Einführung.

Die folgenden zwei Bücher seien nach Meinung des Experten äußerst wertvolle Quellen zu dem Thema:

• Martin Seibert et al.: Enterprise Wikis
• Stewart Mader: Wikipatterns, siehe auch wikipatterns.com

Paarvergleichsanalyse der Kriterien für die Tool-Auswahl

Die Bewertung dürfte bei jedem Unternehmen etwas unterschiedlich ausfallen. Man sieht hier deutlich, dass die Zusammenarbeit mehrerer Mitarbeiter an einem Modell einen hohen Stellenwert hat und die Bedienung des Tools für ebenso wichtig erachtet wird.

Wir haben unsere Auswahl nicht zuletzt aus Kostengründen auf drei Tools beschränkt.

• Enterprise Architect von SparxSystems
• MagicDraw von Nomagic
• objectiF von microTOOL

objectiF wurde schon eingesetzt, unterstützt aber kein SysML. Die Entscheidungsmatrix (siehe Artikel Entscheidungsfindung mit Entscheidungsmatrix) sah nach Bewertung der einzelnen Optionen wie folgt aus:

Entscheidungsmatrix zur Auswahl eines SysML-Tools

MagicDraw hat das Rennen gemacht. Mit dem Teamworks-Server lässt sich komfortabel zusammen an einem Modell arbeiten. Letztlich ist die Implementierung des SysML-Standards wesentlich besser, da die komplette Semantik hinterlegt ist, so dass das Tool an vielen Stellen sinnvoll unterstützt. Wir arbeiten jetzt seit einigen Monaten mit MagicDraw und sind bisher recht zufrieden.