Ziv’s Law
Die meisten "Gesetze" der Softwareentwicklung oder des Projektmanagement gehen auf Zitate ihrer Urheber zurück (Conway's Law, Hofstadter's Law, Brooks's Law, etc.) und spiegeln daher deren Auffassungen wieder. Ziv's Law, benannt nach Hadar Ziv, Professor der University of California, ist in dieser Hinsicht ein Sonderfall, da es seine ursprünglichen Aussagen verfremdend verkürzt. Bevor wir auf seine eigentliche Form schauen, ist aber hier zunächst die verkürzte:
Software specifications and requirements will never be fully understood
frei nach Hadar Ziv, ca. 1996
Zurückgeführt wird Ziv's Law auf seine im Jahr 1996 zusammen mit Debra J. Richardson veröffentlichte Studie The Uncertainty Principle in Software Engineering. Diese beschäftigte sich trotz ihres Namens allerdings nicht mit der Softwareentwicklung im Allgemeinen, sondern nur mit einem ihrer Teilgebiete: dem Software-Testen. Und in diesem Kontext sollte die Aussage der niemals vollständig verstehbaren Anforderungen und Spezifikationen auch gesehen werden.
Ziv und Richardson legten in ihrer Studie dar, dass sämtliche Anforderungen, und damit auch sämtliche Versuche, durch Tests sicherzustellen, dass sie korrekt umgesetzt wurden, Unsicherheits-fördernden Faktoren unterliegen: die Problembeschreibung muss Umgebungsfaktoren ausblenden um nicht zu ausufernd zu werden, die Lösungsbeschreibung kann nur bekannte mögliche Implikationen enthalten und keine noch unbekannten, und ihre menschlichen Verfasser sind fehlbar und können sich irren.
Bedingt durch diese Faktoren sind praktisch sämtliche Versuche, eine zu erstellende Software zu beschreiben, unvollständig, weshalb sowohl in Bezug auf die Umsetzung als auch in Bezug auf den Test unklar sein muss, ob die zugrunde liegenden Anforderungen wirklich im Sinne ihrer Verfasser verstanden wurden. Diese Unklarheit und ihre Folgen werden bereits auf einer der ersten Seiten von The Uncertainty Principle in Software Engineering adressiert:
Software systems under test include, among others, requirements specications, design representations, source code modules, and the relationships among them. These software artifacts are produced by requirements analysis, architectural design, and coding processes, respectively. Following UPSE [the Uncertainty Principles in Software Engineering], uncertainty permeates those development processes and, consequently, the resulting software artifacts. Plans to test them, therefore, will carry these uncertainties forward
Ziv & Richardson, The Uncertainty Principle in Software Engineering , S.4
Diese Darlegungen wird jeder, der sich schon einmal mit Softwareentwicklung beschäftigt hat, bestätigen können. Ihre grosse Schwäche ist aber, dass sie relativ langatmig und kompliziert formuliert wurden, so dass man sie sich kaum merken kann. Der Versuch, sie auf eine gut zu behaltende Zeile zu verkürzen, ist nachvollziehbar, allerdings kam diese Prägnanz mit einem Preis - der ursprüngliche Bezug zum Software-Test ging verloren, genau wie der Verweis zu den erforschten Unsicherheits-Faktoren.
Die verfälschend verkürzte Version von Ziv's Gesetz, die nur noch besagt, dass Anforderungen und Spezifikationen nie zur Gänze verstanden werden, ist übrigens nicht zwingend unzutreffend. Praxis-Beobachtungen sprechen sogar dafür. Anders als Zivs und Richardsons differenziertere Aussagen ist sie aber nicht mehr durch wissenschaftliche Forschungsergebnisse belegt. Sie ist damit lediglich eine durch anekdotische Evidenz belegte starke Meinung, dessen sollte man sich bewusst sein.
