Softwareengineering

Über meinen elektrotechnischen Ansatz hinaus hatte ich immer Interesse an methodischem Vorgehen bei der Softwareentwicklung. Erste Berührungspunkte gab es, als mir angetragen wurde, dass ich demnächst  einem Projekt eingesetzt werde, das mit der „Strukturierten Analyse“ mit ProMod begonnen wurde. Ich nutzte also die verbleibenden 2 Wochen um mich autodidaktisch mit der Methode und dem Tool auseinanderzusetzen. Kurz vor dem Einsatz war ich  der Meinung, ich habe es verstanden und das taugt, um das Problem zu strukturieren, zu verstehen und zu dokumentieren. Im Projekt angekommen kam die Ernüchterung – deprimiert stellte ich für mich fest: Du hast nichts verstanden! Es dauerte nochmal 2 Wochen bis die nächste Ernüchterung folgte: Ich bin der einzige in diesem 30 Personen starken Team, der die Methode verstanden hat, alle anderen haben keine Ahnung. Auf diese Weise kommt eine an sich brauchbare Analysemethode in Verruf – nichts verstanden, falsch angewendet, unbrauchbares Ergebnis, ergo Methode ist Mist.

Nach dem Projekt mit ProMod kam Teamwork, ebenfalls mit SA und zusätzlich noch Structured Design. Als Projektleiter hatte ich die Möglichkeit eine gute SA zu erstellen, ohne sich in Details zu verzetteln, was die große Gefahr bei der SA darstellt. Es erfolgte ein automatischer Übergang zum SD. Das Ergebnis ist üblicherweise erst mal unbrauchbar, stellt aber eine Basis für ein brauchbares Design dar, soweit es die Methode SD erlaubt und das ist nicht sehr viel. So ist es unmöglich ein Multitasking-System zu designen, weil das Ergebnis immer ein Aufrufbaum sein muss, beim Multitasking habe ich aber mehrere davon. Es handelt sich also um ein Werkzeug, mit dem man Programme schreiben kann, aber nict ein Softwaresystem entwickeln. Mit Kompromissen und Vereinbarungen lässt sich das dann noch hinbiegen. Nur das der QA des Kunden beizubringen, ist nicht einfach.
Als aus der Praxis geborener „Experte“ wurde der Segen als Tool-Experte irgendwann zum Fluch. Statemate war das Produkt der Wahl und hatte einen damals revolutionierenden Ansatz – hierarchische Statecharts nach Harel. Es handelt sich um eine fantastische Technik, die zum Problemlöser schlechthin hochstilisiert wurde und damit beliebig misbraucht wurde. Es ist einfach schade, wenn dem Vertrieb das benötigte Fachwissen fehlt. Natürlich kann man sagen dass, eine Restaurantrechnung den Zustand €32,20 hat und wenn man ein Getränk weniger gehabt hätte, wäre der Zustand €29,70 gewesen, aber, wer soetwas formuliert, hat Zustände nicht verstanden. Jedenfalls sind Statecharts so stark, dass sie Eingang in die UML gtefunden haben.

Diese Seite verwendet Cookies, um die Nutzerfreundlichkeit zu verbessern. Mit der weiteren Verwendung stimmst du dem zu.

Datenschutzerklärung