| deutsch | english
Start | Sitemap | RSS | print | Search: 
SOPHIST > Standards > Object Engineering
Object Engineering
Hier klicken

Object Engineering

Object Engineering ist ein agiles Vorgehensmodell, das von SOPHIST für die Systemanalyse entwickelt wurde. Es ist eine Anleitung um Anforderungen so zu dokumentieren, dass diese bestimmten Qualitätskriterien wie Eindeutigkeit, Widerspruchsfreiheit, Testbarkeit, etc. genügen.

Einige Punkte im Überblick:

  • Die Ziele
  • Die natürlichsprachlichen Anforderungen
  • Das Analysemodell
  • Die Abnahmekriterien
  • Das Simulationsmodell (Prototyp)       
Definieren von Zielen

 

Die Ziele

Um ein System erfolgreich zu entwickeln, müssen die Ziele klar definiert werden.
Ziele stellen Anforderungen auf einem hohen Abstraktionsniveau dar. Im Umkehrschluss bedeutet dies auch, dass sie den gleichen Qualitätskriterien unterliegen wie Anforderungen. Bei der Erhebung von Zielen ist es nicht nur wichtig sie zu dokumentieren, sondern diese auch abzugleichen und die bereits bekannten Randbedingungen zu dokumentieren.
Bereits um diese Ziele ermitteln zu können, müssen Sie die Stakeholder Ihres Systems kennen. Eine möglichst umfassende Stakeholderliste bietet Ihnen eine gute Startposition für alle weitere Aktivitäten.

Im Downloadbereich finden Sie eine Stakeholder-Checkliste. Für einen Erfahrungsaustausch zum Thema "Aufzucht, Haltung und Pflege" von Stakeholdern stehen wir Ihnen gerne als Berater zur Verfügung.



Die natürlichsprachlichen Anforderungen

Den zentralen Bestandteil des Object Engineering bilden die natürlichsprachlichen Anforderungen.
Die natürliche Sprache ist das verbreitetste Mittel zur Dokumentation von Anforderungen. Um Prosa-Anforderungen im Entwicklungsprozess sinnvoll nutzen zu können, sollte ein Vorgehensmodell dem Ersteller der Anforderungen ein klares Regelwerk an die Hand geben, an das er sich halten kann, aber nicht muss.

Da die Informatik für die Formulierung von Anforderungen selbst kein Regelwerk etabliert hat, bietet Object Engineering Regeln z. B. in Form des SOPHIST REgelwerkes sowie schablonenbasierte Ansätze an. Diese Ansätze sind eine Hilfestellung, die Sie nutzen können, aber nicht müssen.
Das SOPHIST Regelwerk finden Sie im Downloadbereich.

Das Analysemodell

Das Analysemodell erleichtert es, die meist sehr komplexen fachlichen Zusammenhänge der einzelnen Anforderungen untereinander zu verstehen.  

Da das Modell grafisch dargestellt wird, dient es außerdem als eine Art Gerüst, mit dessen Hilfe sich einzelne Anforderungen thematisch einsortieren und wieder auffinden lassen. Das Analysemodell integriert die Anforderungen in ein Modell und bildet so themenverwandte Anforderungen, die im Anforderungsdokument an weit auseinanderliegenden Stellen verstreut sein können im gleichen Element des Modells ab. Dadurch ergibt sich zusätzlich die Möglichkeit, Widersprüche und Redundanzen systematisch aufzufinden.
                        

Die Abnahmekriterien

Abnahmekriterien beschreiben die Bedingungen für die Entscheidung, ob eine Anforderung erfüllt ist oder nicht.

Abnahmekriterien bewerten nicht nur die Analyse-Ergebnisse, sondern können auch als Ausgangsbasis für die Abnahme des Endproduktes herangezogen werden. Sie prüfen die Vollständigkeit der Anforderungen und spezifizieren konkrete Beispiele für eine abstrakte Anforderung. Damit minimieren sie die Gefahr von Fehlinterpretationen und erhöhen die Klarheit der Anforderungen. Bei der Erstellung der Abnahmekriterien empfiehlt es sich, Mitarbeiter mit Testerfahrung (zum Beispiel den späteren Testmanager) in das Team zu integrieren.
                        

Das Simulationsmodell (Prototyp)

Sobald ein System wirklich eingesetzt wird, fallen fehlende Funktionalitäten auf und vorhandene Eigenschaften können sich als ungeeignet erweisen, sprich: es haben schlicht Forderungen gefehlt. Dann ist es jedoch zu spät - die Systementwicklung ist abgeschlossen.

Die Forderungen an ein System müssen zu einem Zeitpunkt erfasst werden, zu dem noch kein System besteht, also auf der Basis der Vorstellung der Stakeholder. Um diese Vorstellung bereits so konkret wie möglich zu gestalten, werden Prototypen erstellt. Ein Prototyp ist immer eine Implementierung oder Realisierung eines Teils des neu zu erstellenden Systems.
                        
Nur eine genaue Analyse Ihrer Projektrisiken gibt Ihnen Auskunft darüber, welche Methoden aus dem umfangreichen Methodenbaukasten Ihr Problem lösen. Wir stehen Ihnen hier mit unseren Projektberichten zur Seite