Benutzer:Martin Rösch

Martin Rösch (ehem. Wagenleiter 2005-2011)

Martin Rösch (verw. Wagenleiter 1.11.2005-22.2.2011)

Jahrgang 1952

• 1. Heirat 1980, 2 Kinder, Scheidung 1998
• 2. Heirat 2005. Hierbei hatte ich den Namen meiner Frau angenommen (Wagenleiter). Leider wurde bei meiner Frau 4 Monate nach der kirchlichen Hochzeit Krebs festgestellt. 2009 ist sie gestorben. Ich vermisse sie. 2011 habe ich wieder meinen Geburtsnamen angenommen.
• Ab 7.5.2012 habe ich diese neue (zweite) Autoren-Seite bei Wikipedia. Meine alte Autorenseite ist: "Martin Wagenleiter". Unter diesem Namen habe ich den Wikipedia-Artikel "Geschäftsobjekt" angelegt.

Ausbildung

Nach einem altsprachlichen Abitur (Latein und Alt-Griechisch) habe ich Informatik studiert (Nebenfach Betriebswirtschaft). Seit 1979 bin ich Diplom-Informatiker. Die ersten 7 Jahre war ich bei Arthur Andersen und Cincom Systems. Diese Jahre betrachte ich als meine Lehrzeit.

Berufliches

1986 habe ich ein eigenes Unternehmen gegründet (Unternehmensberatung Rösch GmbH). Das Arbeitsgebiet war Konfigurationsmanagement. In einem sehr anspruchsvollen Projekt habe ich dann die Vorteile der Objektorientierung entdeckt, und wie man sie auch für alte Mainframe-Systeme nutzen kann, z.B. für COBOL, DB2 und IMS. Das Projekt wurde 1992 von der OMG ausgezeichnet, als bestes Projekt, das ohne Objekt-Werkzeuge erstellt worden ist.

1992 Umbenennung in "Rösch Consulting Gesellschaft für innovative Softwareentwicklung mbH". Doch Innovation ist ein bewegliches Ziel. Es hat sich im Lauf der Zeit daher immer gewandelt:

• Zuerst durch Einführen von Objektorientierung
• Dann durch Ergänzen von Anforderungsmananagement
• Dann durch Ergänzen von Automatisierung, für Codierung und für Tests
• Dann durch Ergänzen von Wissensdokumentation vor Software-Projekten, vollständig (LIVE 1) und präzise (LIVE 2).

Vision

Unsere Sicht auf die Software-Entwicklung wird sich verändern: Wurde sie noch 2006 als Schöpfungsprozess wahrgenommen, bei dem Software aus dem Nichts entstand, wird sie bald ein präziser Herstellungsprozess sein, in dem wir fachliches Anwender-Wissen vollständig, präzise und messbar in Software verwandeln. Die Voraussetzungen hierfür sind bereits vorhanden:

• Die Fähigkeit, fachliches Handlungs-Wissen vollständig zu erfassen: z.B. mit LIVE 1
• Die Fähigkeit, das Wissen präzise und maschinenlesbar zu speichern: z.B. mit LIVE 2
• Die Fähigkeit, aus dem gespeicherten Wissen große Teile von Software-Systemen zu generieren: z.B. mit LIVE 3
• Internationale Standards für die erforderlichen Techniken: SKOS, UML, CORBA und MDA

Alle diese Voraussetzungen sind in echten Kundenprojekten entwickelt worden und haben sich auch schon in der Praxis bewährt. Deshalb hängt der weitere Fortschritt jetzt nicht mehr von technischen Voraussetzungen ab - sie sind alle gegeben - , sondern nur noch von der Bereitschaft von Software-Entwicklern und Managern, die neuen Wege zu prüfen und Schritt für Schritt zu begehen.

Wenn diese Sicht in einigen Jahren allgemein akzeptiert ist, wird Software genauso zuverlässig entstehen können wie der Rest unserer technischen Umwelt, wie z.B. Flugzeuge, Fernseher und Autos. Und wir werden sie genauso effizient herstellen können.

Erfahrungen

Ich habe an einigen sehr großen Projekten mitwirken dürfen und dabei viel gelernt (z.B. KONTES (Kunde: Telekom AG, ca. 5.000 Personenjahre), FISCUS (Kunde: Finanzverwaltungen, ca. 10.000 PJ), Cheops (Kunde: RWE AG, 1.500 PJ) und Basel II (Kunde: eine Autobank, 500 PJ ). Die Quintessenz dieser Erfahrungen:

• Software-Projekte verarbeiten Wissen. Genauer: Handlungswissen.
• Wissen ist der Rohstoff (Material) von Software-Projekten und ihr Ergebnis ist ein Ökonomisches Gut: die fertige Software.
• Als Rohstoff ist das Wissen nur für Menschen verstehbar. Für Computer wird es verstehbar, sobald es in Software umgeformt ist.
• Macht man dieses Wissen messbar, kann man durch Messungen nachweisen, dass seine Verarbeitung richtig war: nichts vergessen, nichts verfälscht und nichts aus Versehen hinzugefügt.
• Die Entwicklung von Software wird dann eine präzise Produktion: Sie erzeugt mehr Software als heute und sie ist auch effizienter, schneller und besser.
• Optimierungsverfahren aus der Produktion werden übertragbar (Just-in-time-Produktion, Kaizen, TQM, Schlanke Produktion, Schlankes Management, ...)

Erkenntnisse

Zusammen mit Kunden und Mitarbeitern hatte ich das Glück, praxistaugliche Antworten auf folgende Fragen finden zu können:

• Wie kann man auch mit "alten" Techniken (z.B. COBOL, DB2 und IMS) klare Software-Architekturen aufbauen? (Objekt-Softwarearchitekturen, CORBA-Vorläufer, 1991)
• Wie kann man die "richtigen" Objekte für seine Objektmodelle finden? (Objektorientierte Analyse (OOA, 1992)
• Wie kann man sicherstellen, dass Objektmodelle als "fehlerfrei" wahrgenommen werden? (Geschäftsobjekte, 1994)
• Was heißt eigentlich "fehlerfrei"? Und: Wie fehlerfrei kann Software sein? (Verifikation, 1997)
• Wie kann man Software aus Modellen generieren? (MDA-Vorläufer, 1997)
• Wie kann man sicherstellen, dass Software-Komponenten - einzeln und gemeinsam - "richtig" arbeiten? (2000)
• Wie kann man auch in großen und sehr großen Projekten den Überblick behalten? (bzgl. Inhalt und Projektfortschritt) (Earned Value Analysis, 2001)
• Wie kann man fachliche Dokumentationen übersichtlicher machen, indem sich ihre Inhalte untereinander selbst (d.h. automatisch) verlinken? (2003)
• Wie kann man aus Anforderungen und Beispielen Tests generieren? (2004)
• Wie kann man erreichen, dass Software genau zu den sie benutzenden Prozessen passt? (Business/IT-Alignment) (2006)
• Wie kann man auch in einer SAP-Umgebung Software und Test-Programmen generieren? (Model Driven Architecture (MDA), 2007)
• Wie kann man mit akzeptablem Aufwand Software erstellen, in der Anwender keine Fehler mehr finden? (2008)
• Wie kann man Softwaretechnik nutzen, um Wissen zu erschließen und zugänglich zu machen? (Wissensdokumentation) (2010)
• Wie kann man von einer Wissensdokumentation zu Prozess-Beschreibungen kommen? (sowohl für Geschäftsprozesse als auch für Bedienprozesse von Geräten und Anlagen) (2011)
• Wie kann man Software so schnell erstellen, dass ihre Entwicklung als live wahrgenommen wird? (LIVE 123, 2013)

Diese Erfahrungen will ich - soweit sie hierher passen - in der Wikipedia zur Verfügung stellen.

Ansonsten lebe ich davon, sie als Berater, Trainer und Coach weiterzugeben und weiterzuentwickeln (Link zu meinen Web-Seiten, E-Mail: mr@roesch.com).

Buch

Die Zukunft der Software-Entwicklung / Software für die Wissensgesellschaft / Eine Prognose, 2011, ISBN-13: 978-3000341830 http://www.amazon.de/Zukunft-Software-Entwicklung-Software-Wissensgesellschaft-Prognose/dp/3000341838

Wikipedia-Artikel

Geschäftsobjekt