© Excellent backgrounds/Shutterstock.com
Java Magazin
Qualität von Websystemen fassbar machen

Konzeptionelle Integrität

Schon Altmeister Brooks diskutierte in seinem berühmten Buch „The Mythical Man Month“ [1] die konzeptionelle Integrität. Er nannte sie als maßgeblich für die Einheitlichkeit des Designs und behauptete, dass ohne Integrität keine Bedienbarkeit möglich sei. Freilich galt ein System damals als bedienbar, wenn es ein Handbuch gab, in dem jeder Kommandozeilenbefehl mit allen Parametern verständlich dokumentiert war. Es waren also andere Zeiten, aber wir finden: Brooks hat heute noch recht.

Christoph Huber, Daniel Takai


Interessanterweise ist der Begriff der konzeptionellen Integrität in der Literatur nicht definiert, er wird aber oft erwähnt. Er taucht interessanterweise auch nicht in den ISO-Normen zur Softwarequalität auf. Wir finden jedoch, dass dieses Qualitätsmerkmal für unsere Systeme sehr wichtig ist, da es viele andere Systemqualitäten beeinflusst. Unter konzeptioneller Integrität verstehen wir den Grad von Kohäsion und Widerspruchsfreiheit von Anforderungen, die ein System in sich vereinen muss. Mit Kohäsion meinen wir, wie eng die Anforderungen der Software zueinander in Beziehung stehen.

In diesem Artikel beschreiben wir verschiedene Szenarien, die helfen können, die Integrität zu gewährleisten, und weisen die Beziehungen zu anderen Qualitätsmerkmalen genauer aus. Dies kann dann zur Kommunikation mit dem Fach genutzt werden, denn es handelt sich bei der Integrität um ein abstraktes Merkmal, das Fachfremden schwierig zu vermitteln ist.

Stefan Toth hat in seinem Buch [2] die Qualitätsmerkmale klassifiziert nach Akzeptanzkriterien, Qualitätsgeschichten und allgemeinen Merkern. Bei der Integrität handelt es sich um einen allgemeinen Merker, der allen Projektbeteiligten präsent sein sollte, aber aus dem sich nur schwer konkrete Qualitätsszenarien oder Taktiken ableiten lassen. Vielmehr leiten wir aus der gewünschten Integrität organisatorische und methodische Maßnahmen ab.

Zu beachten ist, dass in der Literatur der Begriff der Integrität vielfach belegt ist. Wie eingangs erwähnt, nutzt Brooks ihn als Voraussetzung, beispielsweise für Usability, definiert den Begriff an sich aber nicht. In der Qualitätssicherung bezeichnet Integrität die Fehlerrate einer Komponente. In der Informationssicherheit meint Integrität die Unleugbarkeit von Daten. Die unklare Terminologie über die verschiedenen Disziplinen hinweg ist ein bekanntes Problem, aber auch nicht unbedingt eines, das man lösen muss, wenn der Kontext bekannt ist. Sprache ist nun mal mehrdeutig.

Einflussfaktoren

Abbildung 1 zeigt, wie die konzeptionelle Integrität über verschiedene Ebenen eines Projekts beeinflusst wird. Schon die Organisation und Prozesse, in der die Software entsteht, sind entscheidend. Haben Sie beispielsweise eine eigene Abteilung für die Frontend-Entwicklung und ist diese nicht schlüssig in die Gesamtentwicklung integriert, dann wird Ihre Benutzeroberfläche ziemlich statisch werden. Das liegt daran, dass, wenn Frontend und Backend nicht gemeinsam an den Features arbeiten, kein Zusammenspiel entst...

Java Magazin
Qualität von Websystemen fassbar machen

Konzeptionelle Integrität

Schon Altmeister Brooks diskutierte in seinem berühmten Buch „The Mythical Man Month“ [1] die konzeptionelle Integrität. Er nannte sie als maßgeblich für die Einheitlichkeit des Designs und behauptete, dass ohne Integrität keine Bedienbarkeit möglich sei. Freilich galt ein System damals als bedienbar, wenn es ein Handbuch gab, in dem jeder Kommandozeilenbefehl mit allen Parametern verständlich dokumentiert war. Es waren also andere Zeiten, aber wir finden: Brooks hat heute noch recht.

Christoph Huber, Daniel Takai


Interessanterweise ist der Begriff der konzeptionellen Integrität in der Literatur nicht definiert, er wird aber oft erwähnt. Er taucht interessanterweise auch nicht in den ISO-Normen zur Softwarequalität auf. Wir finden jedoch, dass dieses Qualitätsmerkmal für unsere Systeme sehr wichtig ist, da es viele andere Systemqualitäten beeinflusst. Unter konzeptioneller Integrität verstehen wir den Grad von Kohäsion und Widerspruchsfreiheit von Anforderungen, die ein System in sich vereinen muss. Mit Kohäsion meinen wir, wie eng die Anforderungen der Software zueinander in Beziehung stehen.

In diesem Artikel beschreiben wir verschiedene Szenarien, die helfen können, die Integrität zu gewährleisten, und weisen die Beziehungen zu anderen Qualitätsmerkmalen genauer aus. Dies kann dann zur Kommunikation mit dem Fach genutzt werden, denn es handelt sich bei der Integrität um ein abstraktes Merkmal, das Fachfremden schwierig zu vermitteln ist.

Stefan Toth hat in seinem Buch [2] die Qualitätsmerkmale klassifiziert nach Akzeptanzkriterien, Qualitätsgeschichten und allgemeinen Merkern. Bei der Integrität handelt es sich um einen allgemeinen Merker, der allen Projektbeteiligten präsent sein sollte, aber aus dem sich nur schwer konkrete Qualitätsszenarien oder Taktiken ableiten lassen. Vielmehr leiten wir aus der gewünschten Integrität organisatorische und methodische Maßnahmen ab.

Zu beachten ist, dass in der Literatur der Begriff der Integrität vielfach belegt ist. Wie eingangs erwähnt, nutzt Brooks ihn als Voraussetzung, beispielsweise für Usability, definiert den Begriff an sich aber nicht. In der Qualitätssicherung bezeichnet Integrität die Fehlerrate einer Komponente. In der Informationssicherheit meint Integrität die Unleugbarkeit von Daten. Die unklare Terminologie über die verschiedenen Disziplinen hinweg ist ein bekanntes Problem, aber auch nicht unbedingt eines, das man lösen muss, wenn der Kontext bekannt ist. Sprache ist nun mal mehrdeutig.

Einflussfaktoren

Abbildung 1 zeigt, wie die konzeptionelle Integrität über verschiedene Ebenen eines Projekts beeinflusst wird. Schon die Organisation und Prozesse, in der die Software entsteht, sind entscheidend. Haben Sie beispielsweise eine eigene Abteilung für die Frontend-Entwicklung und ist diese nicht schlüssig in die Gesamtentwicklung integriert, dann wird Ihre Benutzeroberfläche ziemlich statisch werden. Das liegt daran, dass, wenn Frontend und Backend nicht gemeinsam an den Features arbeiten, kein Zusammenspiel entst...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang