Tests / Qualitätssicherung - aber wie?

[Philipp Hasenfratz]

Halihallo Lude

Was wolltest du eingentlich _genau_ wissen?
Da das Testen ja einen betraechtlichen Mehraufwand generiert, so versprach ich mir von der "UML-Geschichte" eine betraechtliche Minderung dieses Aufwandes.

Jain. UML vermindert genau _eine_ "Gattung" von Fehler: Konzeptionelle Fehler. Logische,
pysikalische, etc. Fehler lassen sich damit genauso wenig beheben wie finden.

Ich würde jetzt mal behaupten, dass genau _diese_ Gattung von Fehlern bei grossen
Softwareprojekten verherend sind und deshalb lohnt sich auch der grosse Aufwand and
Konzeptionierung in der ersten Phase (sei dies nun über UML, ER, ORM oder was auch
immer). Aber nochmals: das Testing ist damit nicht implizit gemacht, sondern nur um einen
Faktor verkürzt (Faktor Modellierungsfehler, ggf. Redundante Programmierung durch
schlecht oder ungenügend atomare Konzeption [sprich: ein Modul hat eine oder mehrere
themenfremde Aufgaben]).

(Zudem wird geruechteweise behauptet, dass mit UML komplexere Anforderungen bearbeitet werden koennen und komplexe Anforderungen effektiver bearbeitet werden koennen)

Das könnte ich mir vorstellen. Denn UML arbeitet ja primär auf einer visuellen Ebene
(vergl. visuelle Use Case-Diagramme) und ist somit sehr überschaubar. Eine textuelle
Fassung aller Use Cases wäre zwar konkreter, jedoch nicht überschaubar. Komplexe
Anfragen lassen sich visuell (eg. Verbindungen zwischen Klassen) wesentlich einfacher
zusammenstellen, als wenn man sie textuell verfasst sind.

Interessieren tat mich Deine Meinung zur "UML-Geschichte". Konkretes wollte ich nicht wissen, bzw. wusste nicht was ich wissen wollte, oder so aehnlich...

here you are ;-)

Viele Grüsse

Philipp