In der neusten Ausgabe der Zeitschrift IT-Freelancer (www.it-free.info) erschien unser Artikel "Entscheidungen im Software Engineering". In diesem Artikel geht es (kurz) darum, welche Entscheidungen im Software Engineering zu treffen sind und wie man sie durch Entscheidungsmethoden unterstützen kann. Nähere Informationen dazu gibt es natürlich in unserem zweitägigen Kurs, den Sie über die SIGS DATACOM buchen können. Den Artikel können Sie hier herunterladen:

Call for Papers: Workshop LehRE: „Lehre für Requirements Engineering“

http://www.haw-hamburg.de/index.php?id=31332
Termin: 25.02.2014 (oder 26.02.2014), Halbtag
Einreichungsfrist: 16.12.2013
Ort: Kiel, auf der SE2014

Der Workshop ist eine Veranstaltung des Arbeitskreises „Requirements Engineering in der Lehre“ der Fachgruppe 2.1.6, Requirements Engineering (RE), der Deutschen Gesellschaft für Informatik e.V. (GI).

*** Thema
Der Workshop richtet sich an Personen, die Requirements Engineering (RE) im Informatikumfeld schulen und lehren. Von Interesse sind Erfahrungsberichte aus der Lehre im Hochschulbereich, aber auch aus Schulungen in der beruflichen Weiterbildung, wie Aspekte des Requirements Engineering effektiv vermittelt, Problembewusstsein für Requirements Engineering erzeugt und relevante Kompetenzen trainiert werden können. Insbesondere sollen die Teilnehmer/innen Übungen etc., die sich in ihrem Umfeld bewährt haben (oder sich als problematisch erwiesen haben) vorstellen, diskutieren und möglichst praktisch vorstellen.


*** Einreichungen
Wir freuen uns über Einreichungen über Ihre Erfahrungen in der Lehre des Requirements
Engineering an Hochschulen und in der Praxis. Wir suchen 30-minütige Beiträge: Vorträge,
Übungen, Lehrprojekte, gerne auch interaktiv. Einzureichen ist eine mindestens zweiseitige
Beschreibung des Beitrags im LNI-Format: http://www.gi.de/service/publikationen/lni.html.
Reichen Sie Ihren Beitrag bitte per E-Mail ein unter herrmann-at-herrmann-ehrlich.de.
Die Beiträge sollen nach Annahme zu einem sechsseitigen Artikel ausformuliert werden für die Verteilung als Handouts auf dem Workshop.

*** Termine:
16.12.2013 Einreichung der Beiträge
13.01.2014 Benachrichtigung über die Annahme
27.01.2014 Einreichung der endgültigen Beiträge
25.02.2014 Workshop (ggf. 26.02.)

*** Organisator/innen

Andrea Herrmann, Herrmann & Ehrlich
Anne Hoffmann, Siemens AG
Dieter Landes, Hochschule für Angewandte Wissenschaften Coburg
Rüdiger Weißbach, Hochschule für Angewandte Wissenschaften (HAW) Hamburg

Vortrag von Prof. Dr. Georg Herzwurm, Universität Stuttgart,
in der GI-Regionalgruppe Stuttgart am Mittwoch, 6. November 2013.

In diesem Vortrag wurden zur Erheiterung einige frühere Prognosen genannt, die sich als völlig falsch herausstellten, wie z.B. die, dass der weltweite Bedarf an Computern nie die Zahl fünf übersteigen werde. Oder dass das Telefon als Kommunikationsmittel nicht geeignet sei. Grund für diese Fehlprognosen waren anfängliche technische Mängel dieser Erfindungen, die inzwischen behoben sind.

Doch die Gefahr bleibt, dass Unternehmen teure geschäftliche Fehlentscheidungen treffen, weil sie einen Trend verschlafen haben und zu spät kommen. Ganze Konzerne sind daran schon zugrunde gegangen.

Um neue Technologien richtig einzuschätzen, hilft u.a. Gartners Hype Cycle: Jeder neue Trend durchläuft zunächst einen Peak der aufgeblähten Erwartungen, die zunächst überhöht sind. Darauf folgt das Tal der Desillusionierung. Und erst später wird die neue Technologie produktiv nutzbar. Das heißt einerseits: Nicht jede Enttäuschung bedeutet das Aus für den Hype. Andererseits: Nicht jeder Hype wird ein Trend!

Um vorherzusehen, welche Hypes es wert sind, weiterverfolgt zu werden, setzt man Prognosemethoden ein wie die Expertenbefragung, Delphi-Studie oder eine Literaturstudie.

Meist setzen sich Trends weniger durch neue technische Möglichkeiten durch, denn diese können auch zu früh kommen. Der Anfang liegt immer in Trends in Wirtschaft und Gesellschaft, also dem Bedarf. Daraus folgen Trends in der IT und im IT-Business. Und daraus werden schließlich Unternehmenssoftware-Trends.

Was sind die aktuellen Megatrends?

• Globalisierung
• New Work (neue Arbeitsformen)
• female Shift
• Connectivity
• Urbanisierung
• "Now"-Haltung (Ungeduld)
• Silver Society
• Neo-Ökologie
• Bildung und Talentismus
• Nachhaltige Mobilität
• Gesundheit und "well-being"
• Individualisierung

Daraus folgen dann IT-Trends und Business Trends wie die Shareeconomy, in der Dinge wie Autos und Geräte nicht mehr gekauft, sondern gemietet und geteilt werden.

Wenn es nicht so traurig wäre, wäre es lustig. Erschreckend oft höre ich in der Praxis:
"Requirements Engineering / UML / Use Cases haben wir schonmal probiert, aber das hat nicht geklappt. Also lassen wir es." Das ist genauso gruselig wie: "Ich finde ja schon, dass man Requirements Engineering machen sollte, aber jetzt muss ich erstmal die Software erstellen und ausliefern. Danach kann ich mich wieder mit Requirements beschäftigen."
Ähäm?

Bei jeder komplexeren Tätigkeit muss gelten: "First plan, then do!" Man begibt sich doch auch nicht auf eine Reise, ohne zu wissen, wo man hin will und wozu. Ich recherchiere immer vor der Reise genau, wie ich hin komme und wie lange ich dafür brauche, damit ich weiß, wann ich los fahren muss, um pünktlich anzukommen. Daher kann ich mir gar nicht vorstellen, wie man ohne Requirements Engineering und Entwurf eine ordentliche Software produzieren kann. Natürlich kann man etwas hinbasteln, das nach außen hin wie eine Software aussieht, und wenn irgendwelche Funktionalitäten fehlen, behauptet man einfach: "Das ist technisch nicht möglich." Aber das ist wie wenn ich bei einer Reise dann streckenweise mein Gepäck zu Fuß tragen muss, aus Ermangelung eines Transportmittels, oder immer wieder zurück fahre zum letzten Umsteigeknoten, weil es auf dieser Route leider doch nicht ans Ziel geht. Mal abgesehen davon, dass ich am Ziel feststellen könnte, dass ich eigentlich ein anderes Ziel hätte ansteuern müssen.

Man könnte ja vermuten, die Profis machen durchaus RE, denn offensichtlich liefern sie ja lauffähige Software aus. Vielleicht meinen sie mit "RE" einfach nur alles, was aufwändiger ist als ihre handgekritzelten Workflows und White-Board-Architektur-Skizzen. Dann bestünde kein Verbesserungsbedarf: Die leichtgewichtigen Modellierungsansätze, die sie verwenden, funktionieren ja. Allerdings zeigt gerade ihre Hektik à la "Wir haben keine Zeit für RE, weil unsere Software so viele Fehler enthält" oder "Unsere Software ist so komplex, dass man sie gar nicht modellieren kann", dass hier irgendetwas dann doch nicht ganz rund läuft. (Tipp: Ist Ihre Software zu komplex, um modelliert zu werden, brauchen Sie entweder mehrere Modelle oder eine besser strukturierte Software, also ein gründliches Refactoring. Ich weiß: Dafür hat auch wieder keiner Zeit. Aber zu komplexe, nicht modellierte und nicht verstandene Software ist eine tickende Zeitbombe!)

Worauf ich aber hinaus will:
1.) Requirements Engineering ist nichts, was auf Anhieb klappen muss. Diese Tätigkeit, die nicht nur die Kenntnis von Standard-Notationen voraussetzt, sondern auch gewisse erfahrungsbedingte Fingerfertigkeit und kommunikative Softskills, erlernt man nicht auf den ersten Versuch. Beispielsweise auf die Frage "Wie detailliert muss ich denn modellieren?" lautet die richtige Antwort immer: "Das kommt darauf an, für welchen Zweck Sie modellieren!" Und letztlich findet man dies heraus durch... Ausprobieren.
2.) Requirements Engineering und Modellierung machen Probleme sichtbar, die vorher schon vorhanden waren, aber nicht so greifbar. Die Software war ja allmählich zu einem komplexen, undurchschaubaren und unmodellierbaren Gestrüpp angewachsen. Bisher war es den Beteiligten vermutlich nur intuitiv klar, nun erhalten sie den schmerzhaften Beleg dafür. Modellierung dokumentiert nicht nur das vorhandene Wissen, sondern eben auch
Wissenslücken.

Und das ist ja auch der Nutzen von Requirements Engineering: Es zwingt zu klaren Aussagen,
zu Entscheidungen, die man ansonsten unbemerkt offen gelassen hätte, zu Überlegungen
à la "Wie ist es denn nun genau? A sagt X und B sagt Y!"

Gestern trugen Frau Prof. Paech und Frau Dipl. Zorn-Pauli in der GI-Regionalgruppe Stuttgart-Böblingen vor über Release-Planung und deren Zusammenarbeit mit dem Änderungsmanagement. Entwickelt wurde dazu das RASM (Requirements Abstraction and Solution Model), denn die Zuordnung von Anforderungen zur richtigen Ebene ist eine wesentliche Voraussetzung für ihre Priorisierung. Andernfalls vergleicht man Äpfel mit Birnen. Das RASM unterscheidet drei Ebenen, zu denen Anforderungen und Change Requests gehören können:

1. detail level,
2. bundle level,
3. strategy level.

Die Features werden nach Business Features und Software Features unterschieden. Die Business Features müssen mit der Strategie abgeglichen werden. Die Software Features, die zum bundle level gehören, enthalten und bündeln mehrere detaillierte Anforderungen.

Es wurde in einem Unternehmen für die Inhouse-Entwicklung eine Fallstudie mit dieser Methode erfolgreich durchgeführt. Weitere Zusammenarbeit mit Firmen ist erwünscht, zu diesem oder zu weiteren Themen des Software Engineering.

Hinter diesem Vortrag steckt die Vision des Instituts Software Engineering der Universität Heidelberg, unter dem Motto "Software Engineering Intelligence" Wissen zu sammeln und für praktische Entscheidungen nutzbar zu machen.