Share ZU:
4 December 2012 @ Philip Stolz

Kennen Sie den Unterschied zwischen “logisch” und “physisch”?

Während eines Projektes im Umfeld der Systemanalyse eines eingebetteten Systems für die Automobilindustrie erlebte ich es als eine der Hauptherausforderungen, bei der Systemspezifikation die Problem-Ebene von der Lösungs-Ebene zu trennen.

Die missverständliche Bedeutung der Begriffe in der Systemspezifikation

In diesem Projekt nutzten wir sowohl zur Darstellung des Problems als auch zur Darstellung der Lösung jeweils Datenflussmodelle, die unsere Spezifikationen strukturell zusammen hielten. Um in der Kommunikation mit den Stakeholdern und Entwicklern besser auf die unterschiedliche Bedeutung der Datenflüsse für die Problembeschreibung und der Datenflüsse für die Lösungsbeschreibung aufmerksam zu machen, entschieden wir uns, diese in “physische” (engl. physical) und “logische” (engl. logical) Informationsflüsse zu unterteilen.
Jeder, mit dem ich über diese Klassifikation der Datenflüsse sprach, empfand diese Unterscheidung sofort als einleuchtend und sinnvoll.

Theorie und Praxis bei “logisch” und “physisch”

Als ich jedoch mit den Entwicklern zusammen versuchte, diese Informationsflüsse zu identifizieren und zu klassifizieren, hatte ich plötzlich den Eindruck, dass wir ständig aneinander vorbeiredeten und völlig unterschiedliche Vorstellungen davon hatten, welches denn nun die “logischen” und welches die “physischen” Informationsflüsse seien. Es kristallisierten sich offensichtlich zwei völlig verschiedene Vorstellungen heraus. Hardware-Entwickler schienen tendenziell die Realität, also das Problem, als “physisch” zu betrachten, während sie Informationen über die Realität, die beispielsweise über einen Datenbus gesendet wurden, als “logisch” empfanden. Ich dagegen, sowie der Großteil der Software-Entwickler, war der Meinung, dass Informationen, die die Realität beschrieben, “logisch” seien und die technische Abbildung dieser Informationen im Speicher oder auf Datenbussen deren “physische” Repräsentation darstelle.

Die unterschiedlichen Welten der Hardware und Software-Entwickler

Je mehr ich versuchte, mich mit den Entwicklern auf die eine oder andere Definition zu einigen, desto mehr wurde mir von der jeweils anderen Partei klar gemacht, ich würde ihre Welt einfach nicht verstehen. Letztendlich musste ich dafür sorgen, dass für die Unterscheidung unserer Informationsflussarten neutrale Bezeichnungen geschaffen wurden, die nicht mit vorhandenen Betrachtungsweisen kollidierten und deren Bezeichnungen idealerweise unmissverständlich den Zweck der jeweiligen Informationsart kennzeichnete.

Neutrale Bezeichnungen in der Systemspezifikation

Nach vielen Diskussionen und Erwägungen haben wir uns für die Bezeichnungen “informative” Informationsflüsse (engl. informative) und “technische” Informationsflüsse (engl. technical) geeinigt. Dabei bezeichnete “informativ” diejenigen Informationen, die die Realität (das Problem) beschrieben, während “technisch” die Repräsentation von Informationen durch das System (die Lösung) bezeichnete, z.B. auf Datenbussen oder in Speichertabellen.
Ich will zwar nicht völlig ausschließen, dass die zuletzt gewählten Begrifflichkeiten auch gegensätzlich interpretiert werden könnten, dies ist in dem erwähnten Projekt jedoch nicht vorgekommen.

Hinweise:

Möchten Sie mehr zum Thema “Systemanalyse und Systemspezifikation” erfahren? Dann empfehle ich Ihnen, eines unserer beliebten Trainings zum Requirements Engineering zu besuchen. Ob der Intensivworkshop zur IREB® CPRE-Foundation Level ZertifizierungCPRE Advanced Level, oder das Training zum Certified Agile Requirements Specialist (CARS), es ist sicher etwas für Sie dabei. 

Philip Stolz

Kontaktieren Sie Philip Stolz

Herr Philip Stolz ist als Senior Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung und Prozessverbesserung von Requirements Engineering (RE). Herr Stolz verfügt über eine fundierte Ausbildung im Bereich Software Engineering (Dipl.-Inf., Softwaretechnik). Durch Erfahrung aus unterschiedlichen Entwicklungsprojekten in verschiedenen industriellen Branchen sind ihm typische Projektsituationen sowie das Vorgehen bei der Einführung methodischer Verfahren innerhalb von Projektteams bekannt.