Der „Konzepte“ – Beitrag bringt mich zu einer Frage, die ich schon lange in mir trage: Warum glaubt eigentlich die Software-Industrie, ohne Prototypen auszukommen? Ein neues Automodell wird erst einmal aus Plastilin modelliert, später werden Millionen-teuere Prototypen von Hand gefertigt, bevor man in Serienfertigung geht. Bei Airbus habe ich Holzmodelle von Rumpfteilen gesehen – die Software-Industrie erstellt Grobkonzepte, Feinkonzepte, Datenmodelle, Spezifikationen und dann wird oft über Monate anhand eines dicken Pflichtenhefts programmiert (und ja, das kann man gut outsourcen – auch nach Indien) – mich wundert nicht, dass dabei oft etwas herauskommt, was nicht praktikabel ist.
Man muß ja nicht soweit gehen wie im Beitrag von FSC, statt eines Konzeptes einen völligen Fehlversuch zuzulassen (obwohl ich diese Idee absolut sinnvoll und verführerisch finde) – aber man könnte doch auf ganz anderen Plattformen (z.B. Excel oder Access), auf der man wesentlich schneller und kostengünstiger programmieren kann einen Prototypen bauen, bei dem natürlich wesentliche Funktionalitäten (Multiuser-Fähigkeit, Security, Massendaten-Verarbeitung, Geschwindigkeit, ….) fehlen – das Holzmodell von Airbus fliegt auch nicht. Man könnte aber Algorithmen, User-Interfaces, Workflows, Berichte, etc. testen und verfeinern und bräuchte weniger Bedenken haben, etwas falsch zu machen oder völlig neu zu designen. Enduser können sich doch oft an Hand eines Pflichtenheftes überhaupt nicht vorstellen, wie sich das fertige Produkt „anfühlt“.
Der Prototyp kann dann direkt als „lebendes Pflichtenheft“ dienen – zu mehr aber nicht. Das ist oft der wichtigste Kritikpunkt, den ich höre: „Das muß man doch nachher wegwerfen – man hat gar nichts von den Kosten dafür!“ Wenn ich aber Dank eines 30.000-Euro-Wegwerfprototypen bei einem 700.000-Euro Software-Projekt um nur 10% besser werde, hat sich das auch wirtschaftlich gerechnet!
E2E
Wird geladen ...
Eine Antwort
I have a related suggestion for software development.
In a couple of projects, I was free and clever enough to build a test system before starting on the development itself. It was good to get much of this work out of the way, before concentrating on the real product. This test system contained a sort of prototype, as well as masses of data (partly database, partly test data). The test data files were fed to the prototype and to the real product. The results were compared automatically. Any difference in results had to be explained and corrected (in the prototype or in the product).
In effect, the product was being developed twice in different languages, one properly, the other quick and dirty. If both had the same bug, it could only be a design bug. At the end, one had an easily expandable regression test for checking that bug corrections did no damage.