Software Engineering Rationale: Wissen über Software erheben und erhalten KurtSchneider kurt.schneider@inf.uni-hannover.de Lehrstuhl Software Engineering Leibniz Universität Hannover
Welfengarten 1 30167 Hannover
Software Engineering Rationale: Wissen über Software erheben und erhalten 2AEE42E441F7617E7F3BF5405CF92E75 GROBID - A machine learning software for extracting information from scholarly documents

Damit Software lange genutzt werden kann, muss sie fortwährend korrigiert, erweitert und verändert werden. Dabei werden Entscheidungen und Annahmen getroffen, Domänenwissen wird in die Software eingearbeitet und in Modellen interpretiert. Programme zu warten, bei denen dieses Wissen fehlt, ist schwierig. Das ergänzende Wissen müsste eigentlich zusammen mit dem Programm aufgebaut, gepflegt und weitergegeben werden. Auf längere Sicht kann sich sogar das Programm selbst als weniger langlebig erweisen als das damit assoziierte Wissen. Dieser Beitrag betont den komplementären Charakter von Programm und Rationale, codiertem und ergänzendem Wissen und zeigt Forschungsherausforderungen auf dem Weg, diesem Charakter gerecht zu werden.
Einleitung

Von Anforderungsanalyse bis zu Test und Wartung werden unzählige große und kleine Entscheidungen gefällt und Informationen über Software in diese eingearbeitet. Verliert man das Wissen über die Gründe (das "Rationale"), so verliert man zunehmend auch die Fähigkeit, die Software zu pflegen. Durch innovative Techniken und Werkzeugen soll es gelingen, dieses Zusatzwissen zu sichern, ohne viel spürbaren Zusatzaufwand zu treiben. Entwurfsbegründungen, Erfahrungen und Feedback aus dem Betrieb helfen dann, die Software beweglich und nützlich zu erhalten.

Software altert relativ zu den veränderten Kontextbedingungen: Mitarbeiter gehen und nehmen ihr Wissen mit. Neue Mitarbeiter kommen und verändern die Software, ohne frühere Entscheidungen und ihre Grundlagen zu kennen. Nur wenn man schnell genug bemerkt, dass sich da eine Lücke auftut, kann man reagieren und die Veralterung aufhalten. Das gilt nicht nur in der Entwicklung, sondern auch später im Betrieb der Software. Zusammen mit dem Programm muss auch Wissen bewahrt werden.

Je nach Art und Granulat des bewahrten Wissens kann es in unterschiedlicher Weise später genutzt werden, wie die folgenden Beispiele zeigen.

Dabei geht es um ein weites Spektrum von Aspekten, nicht nur um Codefeinheiten:

• Es ist wichtig zu wissen, ob ein Programm eigentlich als "Prototyp" gedacht war und dann doch weiter gewachsen ist. Das erklärt viele Besonderheiten und Schwächen; man glaubt ja anfangs, der Prototyp werde bald weggeworfen. • Wenn eine Sicherheitsnorm wie ISO 61508 der Grund dafür war, sicherheitskritische von eher unkritischen Programmteilen zu trennen, so muss man das später wissen -sonst sind die darauf aufbauenden Architekturentscheidungen nicht nachvollziehbar und werden vielleicht verletzt. • Begriffe, Regelungen und Terminologie aus einer Domäne können sich für spätere Entwickler "falsch" anhören, weil diese die Domäne nicht kennen.

Trotzdem sollte man sie beibehalten. • Am codenahen Ende des Spektrums muss man wissen, wo und warum ein Design Pattern angewendet wurde, damit man es nicht später "kaputtoptimiert".

IEEE Std 610.12 -1990 definiert Software als "Computer programs, procedures and possibly associated documentation and data pertaining to the operation of a computer system". Es kann geschehen, dass dieses ergänzende Wissen in Form von Modellen, Entscheidungen und Erfahrungen wichtiger wird als das Programm selbst. "Die Software" lebt weiter, obwohl das ursprüngliche Programm ersetzt wird. Verschiedene Typen von ergänzendem Wissen sind besonders wichtig, werden aber häufig nicht erfasst:

• Annahmen über die Randbedingungen. Ändern sich die Bedingungen, so können sich auch darauf aufbauende Entscheidungen ändern. • Das Verfahren kann mit mehreren Demonstrationen und mehreren Erklärungssitzungen angewendet werden und führt so -als Nebenproduktdazu, dass FOCUS jedes Mal einen "Ausführungspfad" und einen "Erklärungspfad" aufzeichnet und zu den bestehenden hinzufügt. Diese Pfade können sich überscheiden und parallel laufen, oder sie können divergieren. In der ersten Version von FOCUS in Smalltalk [Sc96]

• Domänenwissen: Zusammenhänge im Anwendungsbereich schlagen sich einerseits direkt im Code nieder, andererseits bilden sie die Begründung für Entscheidungen. • Prüfergebnisse: Review-und Testberichte können Informationen zur Bewertung von Code liefern. Diese sind nicht aus dem Code selbst abzulesen. • Feedback aus der Programmnutzung: Rückmeldungen der Nutzer können Divergenzen zwischen Annahmen und realer Situation oder zwischen Anforderungen und Programmeigenschaften erkennen lassen. Sie sind ebenfalls naturgemäß nicht im Code repräsentiert. • Erklärungen über das Umfeld oder absehbare Änderungen. Sie können sich teilweise in flexiblerem Code niederschlagen (z.B. durch den Einsatz von Design Patterns [GHJV95]). • Erfahrungen verschiedener Art entstehen während der Entwicklung und Wartung eines Programms. Zum Beispiel kann man feststellen, dass ein Modul bisher besonders fehleranfällig war und bei neuen Fehlern zuerst geprüft werden sollte. Design Patterns sind typische Resultate von Erfahrungen. • Modelle: Sie stellen gewisse relevante Merkmale der Software dar. Die Liste ist sicher nicht vollständig. Sie nennt vor allem Informations-und Wissensarten, die Begründungen, Bewertungen und darauf aufbauende Schlussfolgerungen oder Entscheidungen enthalten. Daher ist es sinnvoll, kurz von "Software Engineering Rationale" zu sprechen. Der Begriff schließt "Design Rationale" ein, geht aber darüber hinaus. Eine besonders wichtige Rolle für die Vermittlung zwischen einem Programm und dem Wissen über dieses Programm spielen zunehmend "Modelle", oft in UML. Wie bereits von Stachoviak [St73] 1973 festgestellt, erweist ein Modell seine Nützlichkeit stets im Hinblick auf ein Original, einen Modellzweck und einen Nutzer. Das Original von UML-Entwurfsmodellen kann beispielsweise der später erzeugte Code sein. Das UML-Modell wird zum Zweck der Codeerstellung (manuell oder generiert) entwickelt, entweder für Entwickler oder für Generatoren. In der MDA [PM06] oder der Modellgetriebenen Software-Entwicklung [SV05] wird Code aus den Modellen generiert. Damit enthält der Code keine zusätzlichen Informationen, die Modelle allein sind die Träger des Wissens. An dieser Stelle sind zwei alternative Konsequenzen denkbar: • Entweder werden die Modelle (anstelle des Codes) mit ergänzendem Wissen verbunden. Das Gesamtwissen der Software ist dann in zwei verschiedenen, jedoch miteinander verbundenen Modellen repräsentiert: im UML-Modell und im Wissensmodell.
•Abbildung 3: Traces und Erklärungspfade werden in FOCUS mit Code vernetzt
•Oder der Modellzweck nach Stachoviak wird umdefiniert und erweitert: Das Modell dient dann nicht mehr nur der Codeerstellung, sondern außerdem der Sicherung ergänzenden Wissens. In diesem Fall wären Metamodelle zu erweitern. Neben Codegenerierung wären Wissensspeicherung und -pflege die Zwecke des Modells. Die Adressaten im Stachoviakschen Sinn sind dann nicht mehr allein die Erstentwickler, sondern alle, die im Lebenszyklus einer Software an dieser arbeiten. Verschiedene, aber verbundene Modelle für Produkt und Wissen bzw. Rationale Diese Überlegung verdeutlicht, wie unterschiedlich technische Realisierungen für ergänzendes Wissen aussehen können. In den folgenden Abschnitten wird für die enge Integration und Verbindung argumentiert. Dafür bieten Metamodellerweiterungen mit UML-Profilen natürlich einen interessanten technischen Ansatz. Dieser Aspekt ist hinlänglich bekannt und soll daher hier nicht weiter ausgeführt werden.Software wird eingesetzt, so lange sie nützlich ist, also ihren Betreibern einen Nutzen verspricht. Weichen die Funktionen oder die nicht-funktionalen Eigenschaften zunehmend von den -möglicherweise veränderten -Erfordernissen ab, wird eine Möglichkeit gesucht, die Abweichung wieder zu verringern. In der Regel wird man versuchen, die Software an die neue Situation anzupassen. Wenn das zu aufwändig erscheint oder überhaupt nicht mehr geht, beginnt man, das eigene Verhalten und die eigenen Geschäftsprozesse an die Möglichkeiten der alternden Software anzugleichen. Das ist ein deutliches Zeichen für das nahende Ende des Software-Lebenszyklus. Symptomatisch ist auch, wenn keine Verbesserungen mehr gewagt werden. Die Software kann nur noch so verwendet werden, wie sie gerade ist. In dieser Phase des Lebenszyklus wird die Software als Last oder Legacy wahrgenommen, die nur deshalb weiter eingesetzt wird, weil es kurzfristig keine Alternative gibt.Man kann sich die obigen Effekte aus den Wirkzusammenhängen zwischen dem Programm und dem ergänzenden Wissen erklären. In diesem Ablauf zeigt sich eine typische, aber nicht wünschenswerte Entwicklung, die man aufhalten müsste:• FOCUS kann nun mit Hilfe der Traces die technische Erklärung des Prototypen anleiten: Im Browser werden die Methoden der Reihe nach angezeigt, die während der Demo ausgeführt wurden. So lassen sich -von der Oberfläche bis zu Algorithmen, Architekturentscheidungen und sogar fragwürdigen Kompromissen -viele relevante Punkte erläutern, indem man den Traces folgt.• Es steht dem Entwickler frei, kommentarlos weiterzuschalten -oder die Wirkungsweise einer Methode zu erklären. Wieder ergibt sich ein Pfad aus den Methoden, die erklärt wurden. Er folgt teilweise den Traces, weicht dann aber wieder ab.3 Lebenszyklus von Software und "ergänzendem Wissen" 6. Nur im Idealfall werden die Änderungen ebenfalls dokumentiert und das so Die Ideen hinter FOCUS sind einfach, aber nicht ganz einfach umzusetzen:gesicherte Wissen mit dem zuvor gesammelten, ergänzenden Wissen integriert. In der späten Lebensphase eines (Legacy-) Systems, in der man kein • Während ein kenntnisreicher Entwickler seinen Prototypen vorführt, wird diesegrundlegendes Refactoring und keine Umstrukturierung mehr wagt, wird kaum Demonstration aus mehreren Perspektiven aufgezeichnet: die Bildschirm-mehr Energie in Wissenssammlung gesteckt werden. Ohnehin ist das System anzeige und ein Trace (aufgezeichnete Sequenz) ausgeführter Methodennun nur noch schwer zu verstehen, was die Wissensintegration weiter erschwert ergeben zwei, durch FOCUS miteinander verbundene Resultate.und zunehmend sinnlos erscheinen lässt.7. Ein Teufelskreis ist in Gang gekommen, der letztlich zu Lücken undInkonsistenzen im gesamten Wissen (bestehend aus Code, Modellen undergänzendem Wissen) führt. Der Code hat sich durch die lokalen Patches vonden ursprünglichen Plänen wegentwickelt. Die Pläne und Entwürfe selbstkönnen mangels Überblick nicht mehr konsistent gepflegt werden.UML-ModellOntologie bzw. WissensbasisaUMLClass aUMLClassanotherClass anotherClassaFeedbackaCommentaRationaleaRationaleaSubClass aSubClassanotherSubCl anotherSubClaRationale5. Daher wird oft versucht, nur kleine, lokale Änderungen vorzunehmen. Dies führt allerdings erst recht zu einer schwer durchschaubaren Struktur mit vielen Ausnahmen und möglicherweise Inkonsistenzen: die "Patches" passen nicht mehr zueinander und zu der grundlegenden Systemstruktur. Die Struktur verwildert zusehends. Es gibt mehrere Beispiele, wie das "By-Product"-Konzept umgesetzt werden kann. Als Beispiel wird hier das Werkzeug FOCUS verwendet, das die Konzepte besonders Abbildung 2: Andererseits sollte man auch nicht aus den Augen verlieren, dass aus dem Wissens-deutlich zeigt: Mit FOCUS kann man während Software-Vorführungen (Demos) Wissen management Konzepte wie Ontologien zur Verfügung gestellt werden, die den Aspekt extrahieren, das zuvor in dem Programm und seinem Entwickler steckte. Schon 1996 der Wissensrepräsentation gezielter abdecken als ein kurzfristig erweitertes UML-Metamodell. Es wird eine der Forschungsfragen sein, hier eine Abwägung zu treffen. wurde eine Smalltalk-Version von FOCUS auf der ICSE vorgestellt [Sc96].
Da sowohl UML-Modelle als auch Ontologien formal fassbar und sogar strukturell ähnlich sind, gibt es viele Möglichkeiten, sie miteinander zu verbinden. Abbildung 2 zeigt eine davon. 1. Während der Entwicklungsphase tragen die Kunden, Entwickler und anderen Projektbeteiligten die wichtigsten Informationen in sich. Es gibt persönliche Notizen, Protokolle und auch Modelle. Entscheidungen werden auf dieser Basis wohlüberlegt und gut informiert getroffen. 2. Durch die hohe Geschwindigkeit der Entwicklung und durch den meist hohen Zeitdruck werden die Aufzeichnungen nicht mehr systematisch erfasst und gepflegt. Manche Modelle sind nicht mehr aktuell, auch Anforderungen, die sich ändern, werden nicht bis in alle Konsequenz nachgeführt. 3. Nach und nach verlassen ursprüngliche Mitarbeiter und Stakeholder das Projekt. Sie nehmen ihr Wissen mit und lassen nur den Teil im Projekt, der sich inzwischen in Code oder expliziter Dokumentation niedergeschlagen hat. In der Praxis geht dabei viel ergänzendes Wissen verloren. 4. Unter den Effekten (2, 3) leidet die Software zunächst scheinbar nicht, da das Programm ja an und für sich "funktioniert". Kommt es jedoch zu Änderungsbedarf (auf Grund von Fehlern, Weiterentwicklung oder Anpassung an die geänderte Umwelt), so fehlen immer mehr Informationen. Für die Entwicklung langlebiger Softwaresysteme müsste man an mehreren Stellen in den skizzierten Lebenszyklus eingreifen: In Schritt (1) werden Anforderungen, Rationale und weiteres Wissen zusammen getragen. Wenn man sie in Schritt (2) wirkungsvoll erfassen könnte, dann könnte die nachteilige Wirkung der folgenden Schritte gemildert werden. In unseren Arbeiten nimmt Schritt (2) hier eine Schlüsselstellung ein: Die Phase, in der zwar die Entwicklungstätigkeit alle Energie an sich zieht, in der aber andererseits auch die Entscheidungen und das Rationale noch präsent sind, betrachten wir als geeigneten Einstiegspunkt für die Rettung von ergänzendem Wissen: Im "By-Product Approach" [Sc06] ist beschrieben, wie man durch gezielte Computerunterstützung in dieser Situation Wissen einsammelt, das sonst flüchtig und "flüssig" (in der Terminologie der Informationsflüsse [SSK08]) bliebe und rasch versickern würde. Es stünde dann in der Wartung nicht mehr zur Verfügung. Wenn es zusätzlich gelingt, das gesammelte Wissen bei Änderungen nutzbar zu machen (Schritt 5), so steigt die Chance, die kombinierte Struktur länger zu achten. Wiederum sollte man aufwandsschonende Computerunterstützung nutzen, um auch bei Änderungen die Begründungen und Entwurfsentscheidungen einzusammeln. Dabei muss man wieder ganz konkret bedenken: auch bei Änderungen muss jeder Aufwand durch einen persönlichen Nutzen kompensiert werden. Es ist kaum zu erwarten, dass man den Alterungsprozess ganz zum Stillstand bringen kann. Aber eine merkliche Verlangsamung wäre bereits ein wichtiger Erfolg. 4 In Zukunft: Programme, Modelle und Wissen verbinden
erhielten die Pfadelemente durch Vererbung die Fähigkeit, das gesamte Netzwerk in der oben geschilderten Weise in html auszugeben und mit dem Group Memory der Abteilung zu verbinden. Bildschirmaufzeichnungen und der Quellcode einzelner Methoden wurden darin zur Veranschaulichung eingebettet. Die Pfade wurden durch Links abgebildet. Diese Darstellung ist gut lesbar, aber nicht ausführbar und stellt eindeutig einen Bruch im Sinne von Lebenszyklus Schritt (6) dar. Daher sollte so lange wie möglich mit der integrierten Variante gearbeitet werden. Andererseits ist die so entstehende Wissensdarstellung nicht mehr auf Smalltalk-Umgebungen angewiesen; ein Browser reicht.Die Integration von Rationale und Wissen in den Code bedeutet übrigens nicht, dass in einem Softwareprodukt auch alle eingebetteten Wissenselemente an den Kunden ausgeliefert werden müssten oder sollten. Lediglich solche Mechanismen, die für die Erfassung von Feedback von den Bedienern gedacht sind, müssen dort verbleiben -was zu vielen weiteren interessanten Fragestellungen führt[LS06,LK07]. Es muss jedoch eine Referenzinstallation bei der Entwicklung geben, die das ergänzende Wissen enthält. Bei Bedarf wird eine neue Produktversion extrahiert und ausgeliefert. Der oben vorgestellte Ansatz, ergänzendes Wissen durch Computerunterstützung mit Programmartefakten zu integrieren, steht noch am Anfang seiner Entwicklung. FOCUS ist ein relativ codenahes und leicht erklärbares Beispiel für seine Umsetzung; viele andere Arten von Wissen können nach ähnlichen Prinzipien bewahrt werden. Dabei ist die Idee, Wissenmanagement-Methoden auf Software Engineering anzuwenden, nicht neu: Es gibt sogar Tagungsreihen zu dem Thema (wie SEKE: Software Engineering und Knowledge Engineering, KBSE: Knowledge-Based Software Engineering) mit internationalem Journal dazu. Auch der Workshop LSO (Learning Software Organizations) bearbeitet seit Jahren verwandte Themen. Der Workshop ist manchmal einer Software-Engineering-Tagung, dann wieder einer Wissensmanagement-Veranstaltung angegliedert. Die Relevanz des Themas ist grundsätzlich schon lange bekannt. Allerdings ist der hier besprochene Aspekt der "nebenbei wirksamen", auf die Software-Engineering-Aktivitäten fein abgestimmten Strukturen und Werkzeuge noch nicht im Zentrum der Aufmerksamkeit. Ohne Werkzeuge -insbesondere ohne akzeptierte Werkzeuge -können Wissenserhebung und -nutzung aber nicht funktionieren. Eine ganze Reihe von Forschungsfragen lässt sich aus diesem Ansatz ableiten. Sie bilden einen Kern dieses Beitrags, weil sie Möglichkeiten aufzeigen, den Problemen langlebiger Softwaresysteme einen Schritt näher zu kommen: Wie verhalten sich die Modelle des Softwaresystems und Modelle des ergänzenden Wissens zueinander? Sind die Metamodelle integriert oder stehen sie nebeneinander (z.B. UML und Wissensschema)? Wie kann man sie trennen, wenn dies erforderlich wird? • Welche Mechanismen können bei der Wiederverwendung des Wissens eingesetzt werden? Auch hier ist an eine aufwandsoptimierte Lösung aus Sicht der Beteiligten zu denken. Die Computerunterstützung beim Erfassen kann auch das Wiederverwenden erleichtern, wie das Beispiel der html-Ausgabe von FOCUS-Pfaden zeigt. Keinesfalls reicht es aus, Informationen "auf dem Internet verfügbar" zu machen. Sie müssen aktiv viel näher an die Arbeitsaufgaben der Entwickler und der Wartungsingenieure gerückt werden. Viele weitere Fragen aus dem Bereich des Wissensmanagement und der Psychologie können interdisziplinär angegangen werden. Im vorliegenden Beitrag sieht man, dass schon aus der reinen Software-Engineering-Perspektive viele interessante Fragen auftauchen [Sc09]. Für manche Aspekte haben wir bereits Vorarbeiten geleistet. Aber die meisten Fragen sind noch offen. Manche der Vorarbeiten adressieren einzelne Fragen, während andere versuchen, eine durchgängige Lösung für ein spezielles Anwendungsproblem anzubieten [Vo06, Vr06]. Es entstehen auch praktisch einsetzbare Werkzeuge, die sich an die Modelle oder Code anlehnen, um Wissen zu erheben und zu erhalten. Dahinter sind semantisch weitergehende Aufbereitungen und Auswertungen möglich. Zunächst ist es aber am wichtigsten, an viel versprechenden Stellen in Entwicklung und Betrieb Feedback einzusammeln und Erfahrungen zu erheben -damit sie für langlebigere Konzepte und Software genutzt werden können. Dieser Beitrag hebt die Bedeutung von "ergänzendem Wissen", insbesondere von Software Engineering Rationale, für langlebige Software hervor. Für das Software Engineering ist es wichtig, dieses Wissen wirksam zu sammeln und mit den Programmen oder Modellen so zu verbinden, dass es bei der Wartung an Ort und Stelle ist und nicht mühsam gesucht werden muss. Das verlangt nach neuen Konzepten, spezialisierten Techniken und Werkzeugen. Ihre Entwicklung ist schwieriger, als es zunächst erscheinen mag: Eine Reihe dabei relevanter Forschungsfragen wurde genannt. Es reicht nicht aus, sich einmal mit einer davon zu beschäftigen. Um Software langlebiger zu machen, muss man das ergänzende Wissen retten -und seine Beziehung zu den Programmen und Modellen ohne ständigen Zusatzaufwand aktuell halten.• Was ist der primäre Wissensträger? Bisher wird außer dem Code kaum etwasaufgehoben; Code ist dann der primäre Wissensträger, zu dem ergänzendesWissen hinzukommen kann (in Ontologien, Büchern, FOCUS-Pfaden). Wiesieht das aber aus, wenn Code aus Modellen generiert wird?• Welche Informationen und Wissensarten braucht man? Zunächst müssen solche Wissensarten identifiziert werden, die in der Wartung (Lebenszyklus Schritt 4-6) gebraucht würden, aber oft fehlen. Diese können dann gezielt gesammelt werden. Die Beispiele in Abschnitt 2 werden dazu gehören. • Wie kann man ergänzendes Wissen nebenher erheben? Der hier vorgestellte Ansatz sieht vor, durch spezifische Computerunterstützung aufzunehmen und zu indizieren. Dabei ist genau auf das Verhältnis von Aufwand und Nutzen zu achten. • Wie integriert man die Wissenserhebung und -verwendung in den Arbeits-und • 7 FazitLernprozess einer lernenden Software-Organisation [Bi06]? Nach Kellowayund Baring [KB03] kommt Lernen am Arbeitsplatz nur in Gang, wenn dafür die(1) Fähigkeit des Einzelnen, die (2) Gelegenheit durch Aufgabe und Umfeldund (3) Motivation zusammenkommen. Wie das in der Softwareentwicklung zugewährleisten ist, geht über das reine Software Engineering hinaus. Aber auchfür das Software Engineering ergeben sich konkrete Konsequenzen, wennwirksame Unterstützung angeboten werden soll.• Wie bringt man die Experten dazu, ihr Wissen für andere preiszugeben? DieseFrage ist ein Spezialfall der vorigen und hat ihrerseits viele Facetten, von derGestaltung von Incentives [DP00] bis hin zur Bedienbarkeit der eingesetztenWerkzeuge, einem Aspekt der Usability im Software Engineering [La05].
KBeck Extreme Programming Explained Addison-Wesley 2000 Learning Software Organisation and Requirements Engineering: The First International Workshop Birk, A., et al. 2006 J.UKM Electronic Journal of Universal Knowledge Management BBoehm Software Engineering Economics
N.J.; Engelwood Cliffs
 Prentice Hall 1981 ACockburn Agile Software Development Addison Wesley 2002 Rationale Management in Software Engineering AHDutoit RMccall IMistrik BPaech
Berlin
 Springer 2006 Knowledge Management Case Book -Best Practises TDavenport GProbst 2000 Publicis MCD, John Wiley & Sons München, Germany EGamma RHelm RJohnson JVlissides Design Patterns -Elements of Reusable Object-Oriented Software Addison-Wesley Publishing Company 1995 Knowledge work as organizational behavior EKKelloway JBarling International Journal of Management Reviews 2 3 2000. 2000 User Interface Design -A Software Engineering Perspective SLauesen 2005 Addison Wesley Harlow, London Dealing with User Requirements and Feedback in SOA Projects DLübke EKnauss Workshop on Software Engineering Methods in Service Oriented Architecture
Hannover, Germany
 2007 Leveraging Feedback on Processes in SOA Projects DLübke KSchneider EuroSPI
Joensuu; Berlin-Heidelberg
 Springer-Verlag 2006 RPetrasch OMeimberg Eine praxisorientierte Einführung in die MDA
Heidelberg
 Dpunkt Verlag 2006 Model-Driven Architecture Rationale as a By-Product KSchneider DMMp06 Experience and Knowledge Management in Software Engineering KSchneider 2009 Springer Berlin Prototypes as Assets, not Toys. Why and How to Extract Knowledge from Prototypes KSchneider 18th International Conference on Software Engineering (ICSE-18)
Berlin, Germany
 1996 Beyond Documents: Visualizing Informal Communication KSchneider KStapel EKnauss Third International Workshop on Requirements Engineering Visualization (REV 08)
Barcelona, Spain
 IEEE Xplore 2008 HStachoviak Allgemeine Modelltheorie
Wien, New York
 Springer Verlag 1973 TStahl MVölter Modellgetriebene Softwareentwicklung. Techniken
Heidelberg
 Dpunkt Verlag 2005 Engineering, Management CVolhard Unterstützung von Use Cases und Oberflächenprototypen in Interviews zur Prozessmodellierung 2006 Fachgebiet Software Engineering ; Gottfried Wilhelm Leibniz Universität Hannover LDVries Konzept und Realisierung eines Werkzeuges zur Unterstützung von Interviews in der Prozessmodellierung 2006 Fachgebiet Software Engineering ; Gottfried Wilhelm Leibniz Universität Hannover