User:Martin Rösch

1. marriage 1980, 2 children, divorced 1998
2. marriage 2005. At this marriage I had adopted the name of name of my wife (Wagenleiter). Sadly, only 4 months after our marriage in church, her cancer was diagnosed. 2009 she died. I miss her. 2011 I re-adopted my birth name: Rösch.
On 7 May 2012 I created the original german version of this page in the german Wikipedia, which is the second page I have at Wikipedia. My old (also german) page is: "Martin Wagenleiter". Under this name I created the Wikipedia article "Geschäftsobjekt" in german, which means "Business Object".

Education[edit]

After an ancient languages Abitur (latin and ancient greek) I have studied computer science (secondary topic: economics). I carry the title Diplom-Informatiker (computer scientist). The first 7 years I spent with Arthur Andersen and Cincom Systems. These years I regard as my apprenticeship.

Career[edit]

After founding my own company (Unternehmensberatung Rösch GmbH) in the late 80s, the first area of work was Configuration Management. In a very challenging project I learned about the advantages of object-orientation, and how to make objects work for "old" mainframe system like e.g. COBOL, DB2 und IMS, on the language level and in the architecture of systems. A project I developed for a large government agency won the Object Application Award at the OMG Object World conference in 1992, in San Francisco, as the "best object-oriented system built with NON-object-oriented tools".

1992 the company was renamed "Rösch Consulting Gesellschaft für innovative Softwareentwicklung mbH". But innovation is a moving target. It has been changing all the time, ever since:

First it meant introducing object-orientation (1992)
then it meant adding requirements analysis (1994)
then adding automation, for coding and for tests (1997)
then adding knowledge documentation before the start of a software project. More precisely, first documenting the Mental Lexicon of the Problem Domain and then its Mental Model .

Vision[edit]

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[edit]

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[edit]

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[edit]

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[edit]

Geschäftsobjekt