Wie läuft eigentlich ein Assessment mit SOPHIST ab?

Bevor wir hier in die Vollen gehen, ist es sinnvoll, unsere beiden bereits erschienen Artikel zu Assessments zu lesen. Im ersten Artikel „Assessments machen wir bei SOPHIST schon seit Jahren…“ haben wir aufgezeigt, wie eine Beurteilung der Prozesse und Methoden durch SOPHIST aussehen kann. Und im zweiten Artikel „A… wie Assessments mit SOPHIST“ haben wir beispielhaft beschrieben, wie wir Probleme im Requirements and Systems Engineering in einem Assessment erkennen und Vorschläge einbringen, um die erkannten Probleme zu lösen.

So, und jetzt kommt ein kurzer werblicher Teil .-)
SOPHIST bietet auch vorbereitende Assessments (nachfolgend Vor-Assessments genannt) im Bereich Requirements and Systems Engineering für verschiedene Assessments wie beispielsweise A-Spice an.

In diesem Artikel stellen wir Ihnen den Ablauf eines Vor-Assessments mit SOPHIST-Unterstützung vor. Sie bekommen einen Einblick, wie die Zusammenarbeit mit SOPHIST abläuft und welche Schritte nötig sind, um auf ein Assessment vorbereitet zu sein.     

Vorbereitung

Die Vorbereitung = der erste Schritt im Prozess von Vor-Assessments.
Hier werden die Ziele (z.B. die Zertifizierung des A-Spice Level 2) und der Umfang des Vor-Assessments definiert. Die Ziele müssen klar und konkret sein, um eine effektive Bewertung zu ermöglichen. Es könnte beispielsweise ein Ziel sein, nur einen begrenzten Umfang der Anforderungen (Requirements) zu beurteilen, um eine Aussage über die Qualität eben dieser zu bekommen.
Ein anderes Ziel könnte sein, den ganzen Systems Engineering Prozess zu beurteilen. 
 
Es ist auch wichtig, den Umfang des Vor-Assessments zu definieren, um sicherzustellen, dass alle relevanten Inhalte einbezogen werden. Hierbei ist der Umfang begrenzt auf Themen im Requirements and Systems Engineering. Jedoch können in Abhängigkeit der gesetzten Ziele ein unterschiedlicher Umfang im Hinblick auf die betrachteten Anforderungen und betrachteter Architektur, aber auch betrachteter Prozesse, Methoden und Artefakten wie Gesetze, Anleitungen, Handlungsanweisungen etc. gewählt werden.

Nachdem Ziele und Umfang gesetzt wurden, ist der nächste Schritt in der Vorbereitung (der Durchführung des Vor-Assessments mit SOPHIST) eine Selbstbeurteilung durch das Kundenunternehmen. Diese Beurteilung beruht auf dem identischen Fragenkatalog und Bewertungsmechanismus, welche auch im Vor-Assessment verwendet werden. Und diese werden dann auch auf den für das Vor-Assessment gewählten Umfang angewandt. Dadurch erlangt das Kundenunternehmen eine statistikbasierte Eigenwahrnehmung über die Qualität ihrer gewählten Inhalte und zudem ein Gefühl für die Fragen, die im Vor-Assessment gestellt werden.  

Schließlich ist es wichtig, organisatorische Aspekte zu klären.
Einerseits, um den Zugriff auf Werkzeuge vorzubereiten, den die SOPHIST-Assessoren benötigen, um Prozesse und Methoden einzusehen. Und andererseits werden damit auch gleich die Termine für das Assessment geklärt.

Weiterlesen

Verschwendung bei der Entwicklung von Architekturen – so entgegen steuern…

Wundern Sie sich auch, wie aufwendig die Erstellung einer guten Systemarchitektur ist? Vielleicht sind einige diese Aufwände überflüssig und das Resultat einer offensichtlichen oder verdeckten Verschwendung von Ressourcen. In unterschiedlichen Kontexten haben wir als Berater für Systems Engineering ähnliche Symptome wahrgenommen. Wir haben uns gefragt, was die Ursache dieser Symptome sein könnte, um bewusst dieser Ursache entgegenwirken zu können. Dabei sind wir auf eine Sammlung von wiederkehrenden Problemen gestoßen, die für eine gewisse Verschwendung und auch für Konfliktpotenzial sorgen.

Weiterlesen

Ein RE-Vortrag auf einer Entwickler-Konferenz?

Auch als Entwickler sollte man über seinen fachlichen Spezialbereich hinausblicken und auch die anderen „Stationen“ einer Systementwicklung kennen und verstehen. Ein Blick auf das Ganze bringt immer nur zusätzliche Vorteile. Umso wichtiger ist es für Entwickler vor allem zu verstehen, was die ursprünglichen Ideen und Forderungen hinter dem zu entwickelnden System waren. Oder anders ausgedrückt:

Ein guter Entwickler versteht die Sprache der Spezifikation, die ihm vorgelegt wird. Dabei stellt sich eine weitere wichtige Frage: Wie viel Spezifikation braucht man als Entwickler maximal, um seinen Job erfolgreich durchzuführen? Und was davon sind nur unnötige Notationskosten?
Wie viel und wie, wird SOPHIST-Chefin Chris Rupp in Ihrem Vortrag auf der diesjährigen .NET Developer Conference im Mai in Nürnberg vortragen.

Unser Vortrag
14.05.2012 17:00 – 18:00 Uhr Weiterlesen

Validierung von System-Architekturen gegenüber Anforderungen mit UML

In diesem Blog-Beitrag möchten wir Ihnen einen Prozess zur Validierung von System-Architekturen gegenüber den System-Anforderungen vorstellen, um den System-Architekten im Umgang mit den sich ständig ändernden Anforderungen und bei der Analyse der Auswirkungen dieser Änderungen (Impact-Analyse) auf die System-Architektur zu unterstützen. Dazu verwenden wir die Modellierungssprache Unified Modelling Language (UML), die Sie im optimalen Fall bereits für die modellbasierte Dokumentation Ihres Systems einsetzen. Mit Hilfe des Validierungsprozesses lassen sich reproduzierbare Validierungsergebnisse erstellen, wobei der Arbeits- und Zeitaufwand des Architekten durch Automatisierungen und Werkzeugunterstützung reduziert wird. Er lässt sich an den aktuellen Entwicklungsstand anpassen, so dass zu Beginn der Entwicklung weniger detaillierte Informationen zur Validierung verwendet werden, die dann im Laufe der Entwicklung durch immer detailliertere ersetzt werden können. Auf diese Weise erhalten Sie auch eine fortschreitende Dokumentation des Architektur-Designs. Weiterlesen

Szene Ticker: UML für die Systemarchitektur

Unser langjähriger Mitarbeiter Dr. Stefan Queins, Co-Autor des Buchs „UML 2 glasklar“, hat bei Computerwoche.de einen Artikel über die UML in der Softwareentwicklung veröffentlicht.
Die UML gilt in der Softwareentwicklung seit einiger Zeit als gängiges Notationsmittel, um die Ergebnisse der Analyse und Architektur zu dokumentieren.
Wer sie zur Entwicklung kompletter Systeme einschliesslich Hardware verwendet, muss auf einige Anpassungen in der Notation achten. Weiterlesen