Das 3RPC-Konzept
Im folgenden möchten wir Ihnen das neue Denkmodell vorstellen, mit dem wir die zu Beginn festgestellten Probleme vermeiden und das Ziel - die industrielle Softwareentwicklung - erreichen können.
graphic
Trennung von Systementwicklung und Programmierung
Wie wir gezeigt haben, stehen die Ziele des programmorientierten Ansatzes den eigentlich gewünschten, zukunftsorientierten Zielen diametral gegenüber. Dadurch versagen die dauernd wechselnden Ansätze und Paradigmen der letzten Jahre beim eigentlichen Ziel: Die Erstellung von Software so zu steuern, daß mit wesentlich höherer Sicherheit ein Produkt herauskommt, das genau das bietet, was man auch wollte.
Zur Wiederholung: sie müssen hier versagen, denn sie stellen nur eine Technisierung entweder der Designmittel (entsprechend der Technisierung der Konstruktion in der Industrie) oder der Fertigungsmittel (entsprechend der Automatisierung) dar.
graphicDas soll nicht heißen, daß diese Tools und Methoden überflüssig wären. Im Gegenteil, sie sind sehr wichtig, denn letztendlich können sie eine deutliche Produktionssteigerung bewirken - wenn die Arbeitdavor richtig getan ist.
Unser Ansatz wird deshalb weitestmöglich die Systemspezifikation von der Programmierung trennen. Wir werden die Systemspezifikation auch möglichst von einer Methode freihalten, denn dies fördert zum einen die Gefahr, daß das Augenmerk unmerklich auf die Einhaltung der Methode übergeht ("Der Weg wird zum Ziel"), und außerdem soll doch jeder das Tool benutzen, mit dem er am besten zurecht kommt.
Wir stellen daher lediglich Vorschriften auf, welcheSpezifikationen erfaßt werden müssen, aber nicht wie. Wir definieren, was Bestandteil des Entwicklungsplans sein muß, aber nicht welche Linien, Pfeile und Kästchen Sie dafür verwenden müssen.
graphic
Systemspezifikation durch 3RPC
graphic Damit eine Systemspezifikation als Konstruktionsschablone benutzt werden kann, muß sie vollständig sein. Die Zeichnungen unserer Schiffsbauer aus unserer Satire waren es nicht und daher paßte auch dauernd irgendetwas nicht zusammen. Immer Sachen, an die vorher keiner gedacht hat.
Ach, sie kennen das?
graphic Damit die Systemspezifikation Sinn macht, muß sie alle wesentlichen Anforderungen und auch alle impliziten, versteckten Anforderungen beinhalten. Versteckte Anforderungen sind vorher naturgemäß nicht bekannt, also müssen die wesentlichen Anforderungen so ermittelt werden, daß die versteckten Anforderungen "hervortreten".
graphic Damit die Systemspezifikation in der Fertigung (=Programmierung) "as is" benutzt werden kann, muß sie allgemeine Konstruktionsprinzipien erfüllen, die alle kennen. Ein technischer Zeichner muß sich an die Symbolbibliotheken und Zeichentechniken seines Unternehmens halten, sonst verstehen weder seine Kollegen noch die Produktion, was eigentlich gemacht werden muß: Sie verstehen seine Sprache nicht.
Sie kennen das: stundenlang erklärte Person A der Person B, was benötigt wurde. Wochenlang programmierte Person B. Was herauskam, ist ein wenig, aber nicht ganz das, was Person A eigentlich meinte.
graphic Damit die Spezifikation zu zügig erstellbarer (=bezahlbarer) Software führt, muß sie bewährte Bestandteile wiederverwenden können. Selbst die Automobilindustrie hat die Vorteile dieses Verfahrens mittlerweile begriffen. Die Objektorientierung greift den Ansatz auch auf und wird auch zur Realisierung benötigt, setzt eigentlich aber einen Schritt zu spät an.
graphic Eine Spezifikation zu erstellen ist nur die halbe Arbeit. Sie muß zusätzlich auch die Möglichkeit bieten, einen Abgleich zu den Ergebnissen zu ermöglichen. Sonst betreiben Sie Planung ohne Steuerung. Das ist wirklich teure Planung, weil hinausgeschmissenes Geld. Der Entwicklungsplan muß deshalb auch die Grundlage des Projektcontrolling sein.
graphic
Faßt man diese Forderungen zusammen, dann sind im Ergebnis drei wesentliche Anforderungen zu erfüllen - diese müssen eine Planung ergeben und eine Steuerung sowohl des Entwicklungs- als auch des Fertigungsprozesses ermöglichen. Planung und Steuerung ergeben zusammen das Potential eines echten Projekt-Controllings.
All das leistet das "3RPC"
- das "3 requirements planning and controlling".
graphic "User requirements" beinhaltet die umfassende und vollständige Erfassung der Anwenderanforderungen. Diese teilen sich wiederum auf in die Bereiche "Funktionale Anforderungen", "Prozeßorientierte Anforderungen" und "Informations-Anforderungen".
graphic "Transaction requirements" beinhaltet die umfassende und vollständige Spezifikation, wie der Anwender mit dem System kommunizieren kann.Sie beinhaltet im einzelnen "Bedienungselemente", mehrschrittige "Bedienungsabläufe" und komplexe "Prozeß- und Workflow-Steuerungen".
graphic "Implementation requirements" beinhaltet die Vorschriften an die Programmierer, wie das System zu fertigen ist. Dazu gehören die "Implementierungs-Guidelines", die "Methoden- und Verfahrensnormen" und der "Systementwurf".
Mehr Details zu den drei Anforderungen erfahren Sie in den nachfolgenden Kapiteln. Dort werden auch im Detail die Ziele und Folgen der jeweiligen Anforderung vorgestellt.