Referenzmodelle und Pattern in der Modellierung wissensintensiver Prozesse im Software Engineering E-Book
Mathias Uslar
39,99 €
Mehr erfahren.
- Herausgeber: GRIN Verlag
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2005
Diplomarbeit aus dem Jahr 2004 im Fachbereich Informatik - Wirtschaftsinformatik, Note: 1,3, Carl von Ossietzky Universität Oldenburg (Abteilung Informationssysteme), Sprache: Deutsch, Abstract: Kurzfassung Im Rahmen dieser Arbeit wird eine Methode für die Modellierung wissensintensiver Prozesse im Software Engineering entworfen. Ausgehend von den Prozessen im Software Engineering, welche gemäß dem SWEBOK der IEEE dargestellt werden, wird nach einer Darstellung der einzelnen Wissensgebiete der Softwareentwicklung ein Überblick über allgemeine Aspekte geboten. Diese Gebiete werden nach einer Definition und Darstellung des Begriffes der wissensintensiven Geschäftsprozesse kategorisiert und auf Eigenschaften wissensintensiver Prozesse untersucht. Dadurch können wissensintensive Prozesse identifiziert und ihre jeweiligen Schwerpunkte und Prozessunterstützungen dargestellt werden. Aus den Erkenntnissen über wissensintensive Prozesse,Wissensgebiete der Softwareentwicklung und der Unterstützung der Wissensgebiete lassen sich zusammen mit dem Stand der Unterstützung der Softwareentwicklung durch Wissensmanagement und Anforderungen an Modellierungsprachen Anforderungen für die im Rahmen der Arbeit zu entwickelnde Modellierungssprache KMDL SE (Knowledge Modeling Description Language for Software Engineering) ableiten. Diese wird im letzten Kapitel der Arbeit entwickelt und stellt eine Unterstützung zur Modellierung wissensintensiver Prozesse in der Softwareentwicklung auf Basis von fundierten Erkenntnissen aus den Gebieten der Softwareentwicklung und des Wissensmanagements dar. Dabei werden ausgewählte Teilaspekte der KMDL SE vertieft dargestellt.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Ähnliche
Page 1
Eingereicht von:CAND. INF.MATHIAS USLAR
Erarbeitet: 10. Semester
Fertiggestellt: Oldenburg, 21.09.2004
Page 2
Kurzfassung
Im Rahmen dieser Arbeit wird eine Methode für die Modellierung wissensintensiver Prozesse im Software Engineering entworfen. Ausgehend von den Prozessen im Software Engineering, welche gemäß dem SWEBOK der IEEE dargestellt werden, wird nach einer Darstellung der einzelnen Wissensgebiete der Softwareentwicklung ein Überblick über allgemeine Aspekte geboten. Diese Gebiete werden nach einer Definition und Darstellung des Begriffes der wissensintensiven Geschäftsprozesse kategorisiert und auf Eigenschaften wissensintensiver Prozesse untersucht. Dadurch können wissensintensive Prozesse identifiziert und ihre jeweiligen Schwerpunkte und Prozessunterstützungen dargestellt werden. Aus den Erkenntnissen über wissensintensive Prozesse, Wissensgebiete der Softwareentwicklung und der Unterstützung der Wissensgebiete lassen sich zusammen mit dem Stand der Unterstützung der Softwareentwicklung durch Wissensmanagement und Anforderungen an Modellierungsprachen Anforderungen für die im Rahmen der Arbeit zu entwickelnde Modellierungssprache KMDL SE (Knowledge Modeling Description Language for Software Engineering) ableiten. Diese wird im letzten Kapitel der Arbeit entwickelt und stellt eine Unterstützung zur Modellierung wissensintensiver Prozesse in der Softwareentwicklung auf Basis von fundierten Erkenntnissen aus den Gebieten der Softwareentwicklung und des Wissensmanagements dar. Dabei werden ausgewählte Teilaspekte der KMDL SE vertieft dargestellt.
Abstract
The aim of this diploma thesis is to develop a language for modeling knowledge-intensive business processes within the software engineering domain. Beginning with the description of the processes in software engineering which are covered in the extent of the SWEBOK by the IEEE, it will cover the knowledge areas of the SWEBOK and provide an overview about single areas which will be discussed in depth focusing on the relevant characteristics for this work. The areas are categorized afterwards by the means and characteristics of knowledge-intensive business processes. This provides the possibility to identify the main focus and process support for knowledge-intensive processes. From the gained knowledge about the knowledge areas of software engineering, the characteristics of knowledgeintensive processes and the support of the focused software engineering processes combined with the state-of-the art of knowledge management within the software engineering domain and requirements for modeling languages, we can draft requirements for a modeling language for knowledge-intensive processes in software engineering. This language which will be called KMDL SE (Knowledge Modeling Language for Software Engineering) is described and defined in the last chapter of the thesis. It is based on the sound knowledge about the software engineering knowledge areas and their requirements and knowledge management. Special aspects of the language are discussed more in depth, e.g. the patterns in processes and the UML extension.
Page 3
Vorwort
Betrachtet man Software, die sich aktuell auf dem Markt findet, fällt es nicht schwer, sich vorzustellen, dass diese extrem fehlerbehaftet ist. Zwar gewöhnt man sich mit der Zeit an die Fehler und Macken der Software; folgender altbekannter Witz überträgt jedoch die Macken der aktuellen Software am Beispiel der heutzutage weitestverbreiteten Betriebssystemfamilie auf die Auto-Industrie:
Auf der Computermesse Comdex hat Bill Gates die Computer-Industrie mit der Auto-Industrie verglichen und das folgende Statement gemacht:
„Wenn General Motors (GM) mit der Technologie so mitgehalten hätte wie die Computer-Industrie, dann würden wir heute alle 25-Dollar-Autos fahren, die 1000 Meilen pro Gallone Sprit fahren würden.“
Als Antwort darauf veröffentlichte General Motors eine Presse-Erklärung mit folgendem Inhalt:
Wenn General Motors eine Technologie wie Microsoft entwickelt hätte, dann würden wir heute alle Autos mit folgenden Eigenschaften fahren:
1. Ihr Auto würde ohne erkennbaren Grund zweimal am Tag einen Unfall haben.
2. Jedes Mal, wenn die Linien auf der Straße neu gezeichnet werden würden, müsste man ein neues Auto kaufen.
3. Gelegentlich würde ein Auto ohne erkennbaren Grund auf der Autobahn einfach ausgehen, und man würde das einfach akzeptieren, neu starten und weiterfahren.
4. Wenn man bestimmte Manöver durchführt, wie z.B. eine Linkskurve, würde das Auto einfach ausgehen und sich weigern, neu zu starten. Man müsste den Motor dann neu installieren.
5. Man kann nur allein im Auto sitzen, es sei denn, man kauft „Car95“ oder „CarNT“ . Aber dann müsste man jeden Sitz einzeln bezahlen.
6. Apple würde Autos herstellen, die mit Sonnenenergie fahren, zuverlässig laufen, fünfmal so schnell und zweimal so leicht zu fahren sein, aber sie laufen nur auf 5% der Straßen.
7. Die Rückfahr-Kontroll-Leuchte, die Warnlampen für Temperatur und Batterie würden durch eine „Genereller Auto-Fehler“ -Warnlampe ersetzt.
8. Neue Sitze würden erfordern, dass alle dieselbe Gesäßgröße haben.
9. Das Airbag-System würde fragen: „Sind Sie sicher?“ , bevor es auslöst.
10. Gelegentlich würde das Auto Sie ohne erkennbaren Grund aussperren. Sie können nur wieder mit einem Trick aufschließen, und zwar müsste man gleichzeitig den Türgriff ziehen, den Schlüssel drehen und mit einer Hand die Radioantenne anfassen.
11. General Motors würde Sie zwingen, mit jedem Auto einen DeLuxe Kartensatz der Firma Rand McNally (seit neuestem eine GM Tochter) mit zu kaufen, auch wenn Sie diesen Kartensatz nicht brauchen oder möchten. Wenn Sie diese Option nicht möchten, würde das Auto sofort 50% langsamer werden (oder schlimmer). Darüber hinaus würde GM deswegen ein Ziel von Untersuchungen der Justiz.
Page 4
12. Immer dann, wenn ein neues Auto von GM vorgestellt werden würde, müssten alle Autofahrer das Autofahren neu erlernen, weil keiner der Bedienhebel genauso funktionieren würde wie in den alten Autos.
13. Man müsste den „Start“ -Knopf drücken, um den Motor auszuschalten.
Unabhängig von der Tatsache, ob diese Geschichte sich tatsächlich so zugetragen hat oder eher einer urbanen Legende zuzuordnen ist, verdeutlicht sie doch, wie sehr die Softwareentwicklung den Anforderungen der Kunden nicht gerecht wird. Qualitätssicherung, Kompatibilität, Zukunftssicherheit, sinnvolle Nutzerschnittstellen müssen entwickelt oder verbessert werden. Leider besteht das Dilemma der Softwareentwicklung bereits seit den 60er Jahren und scheint immer noch nicht gelöst. Im Rahmen dieser Arbeit wird ein Ansatz untersucht, der sich mit der Anwendung der Methoden des Wissensmanagements auf die Softwareentwicklung befasst. Die Diplomarbeit ist sicherlich auch bei weitem nicht die lang gesuchte „silver bullet“ , kann jedoch sicher ihren Beitrag leisten, die Softwareentwicklung zu verbessern.
Zur Erstellung dieser Diplomarbeit haben zahlreiche Ansätze und Gedanken beigetragen, die ich sammelte und zusammenfügte. Dabei erwies sich die Literaturrecherche als ergiebiger als gedacht und die Literatur zeigte auch in Zeiten des Zweifels, dass der Ansatz einer der richtigen Wege sein kann. Bedanken möchte ich mich bei meinem Erstgutachter Prof. Appelrath, der kurzfristig das Gutachten übernehmen konnte und bei meiner Zweitgutachterin Dipl.-Oec. Liane Haak, die zwischenzeitlich ihre Karamelcappucinovorräte freiwillig dezimieren ließ. Ein besonderer Dank gilt meinem Betreuer Dipl.-Inf. Frank Laskowski, der nun als Studienrat i.D. sein Wissen anderweitig verbreiten wird. Auch wenn er mich nicht überzeugen konnte, den Tractatus von Wittgenstein ([Wit63]) im Text zu zitieren, brachte er doch zahlreiche Vorschläge ein und ertrug perfektionistische Diskussionen über die Gliederung und den Umfang, wenn ich mal wieder einen wichtigen Punkt für zu kurz geraten hielt. Danke. Weiterer Dank gilt meine Kollegen in der Abteilung Wirtschaftsinformatik der Universität Oldenburg, der AG Wissensmanagement der Universität Potsdam und den Kollegen der Abteilung BI am OFFIS, die mit aufmunternden Worten, Schaffen von Freiräumen und Ideen ihren Teil zum Gelingen dieser Arbeit beigetragen haben.
Dank geht noch an meine Freundin, die mit ihrer vorhandenen Toleranz gegenüber meinen Arbeitszeiten und durch regelmäßige Nahrungsbereitstellung mich in den sechs Monaten der Erstellung unterstützt hat. Abschließender Dank geht an meinen Großvater und meine Eltern, speziell an meine Mutter, die mir durch ihre Unterstützung, sowohl im finanzieller als auch moralischer Hinsicht das Studium erst ermöglichte. Ihr sei diese Arbeit gewidmet.
Page 9
Abbildungsverzeichnis
2.1 Entwicklung einer Ingenieursdisziplin . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Wissensdimensionen nach Aristoteles . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2 Wissenstreppe nach North . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3 Wissensbausteine nach Probst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4 Die vier Wissenskonversionen nach Nonaka/Takeuchi . . . . . . . . . . . . . . . . . . 48 3.5 Die organisationale Wissensspirale nach Nonaka/Takeuchi . . . . . . . . . . . . . . . 49 3.6 Umfeld und Einflussfaktoren auf Geschäftsprozesse . . . . . . . . . . . . . . . . . . . 52 3.7 Klassifikation von Geschäftsprozessen nach Eppler et al. . . . . . . . . . . . . . . . . 54 3.8 Eigenschaften wissensintensiver Geschäftsprozesse nach Gronau . . . . . . . . . . . . 57 3.9 Integration von Geschäfts- und Prozessmanagement nach Nägele und Schreiner . . . . 58
4.1 Requirements Engineering-Prozess nach Kotonya und Sommerville . . . . . . . . . . 68 4.2 Screenshot des Tools DOORSrequireIT . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.3 Screenshot des Tools IBM Rational Requisite Pro 6.3 . . . . . . . . . . . . . . . . . . 72 4.4 Das allgemeine V-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5 Das Iterative Modell des RUP über seine zwei Dimensionen . . . . . . . . . . . . . . 77 4.6 Einfache Darstellung des RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.7 Screenshot JUnit TestRunner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.8 Screenshot WinCVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.1 Zusammenhang der Objekte der KMDL 1.0 . . . . . . . . . . . . . . . . . . . . . . . 116 5.2 Objekte und Relationen der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.3 Aufgabensicht der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.4 Einfache Prozesssicht der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.5 Erweiterte Prozesssicht der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.6 Wissenssicht der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.7 Erweiterte Prozesssicht der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 124 5.8 Erweiterte Prozesssicht der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.9 Internalisierung in der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.10 Externalisierung in der KMDL 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Page 1
Kapitel 1
Einführung und Motivation
1.1 Einführung
Software findet sich heutzutage fast überall. Im Haushalt, in der Industrie, der Verwaltung, der Finanzwelt oder der Medizin. Die Systeme greifen jedoch nicht nur auf immer mehr Bereiche des täglichen Lebens über, sondern werden auch immer komplexer und unübersichtlicher. Immer häufiger kommt es zu Ausfällen, die Kosten in enormer Höhe für Institutionen, Privatpersonen und für die Gesellschaft verursachen.
Im Juni 1996 kam es zum ersten Start der neu entwickelten europäischen Trägerrakete Ariane-51. Während der Fluges lief unnötigerweise ein Programm zur Kalibrierung der Trägheitssensoren, welches lediglich vor dem Start der Rakete aktiv sein sollte. Das System wurde wahrscheinlich aus Kostengründen aus der Vorgängerin, der Ariane-4 übernommen. Es wurde nicht beachtet, dass die neue Rakete ganz andere Eigenschaften und Werte aufwies. Die Horizontalgeschwindigkeit der neuen Ariane-5 Rakete konnte wesentlich höher sein als der der alten Ariane-4. Im System kam es dadurch zu einem Überlauf bei der Konvertierung eines 64-bit Floating-Wertes in eine 16-Bit Integer Zahl. Die Variable war jedoch nicht geschützt und die Fehlerbehandlung bestand in einem Herunterfahren des Systems und Übergabe der Kontrolle an ein identisches Backup-System. Da beide System mit demselben Programm arbeiteten war dies wegen der Identität beider Systeme fatal und führte zum Absturz als das Stand-By System mit demselben Fehler abschaltete und vorher noch Diagnose-Daten an den On-Board-Computer schickte. Dieser interpretierte die Daten als aktuelle Flugdaten und zündete sämtliche Steuerdüsen der Rakete. Dadurch wurde der Flugwinkel um 20 Grad geändert was zum Auseinanderbrechen der Rakete führen würde und die automatische Selbstzerstörung auslöste. Beim Absturz der Rakete wurden 4 Cluster-Satelliten, die der Erforschung der Magnetosphäre der Erde und der Sonnenpartikel dienen sollten, zerstört. Der Schaden belief sich dabei auf etwa 600 Millionen Euro und warf das Ariane-5 Programm soweit zurück, dass es erst 1999 zum ersten erfolgreichen kommerziellen Flug kam.
Neben solchen kommerziellen Fehlschlägen kann es auch zu lebensgefährlichen Fehlern kommen.
1kompletter Absturzbericht der ESA [Lio96]
Page 2
Ein weiterer berühmter Softwarefehler ist der im Therac-25 der kanadischen AECL . Dabei handelte es sich um eine computergestütztes Tumorbestrahlungsgerät, welches zwischen 1985 und 1987 im Einsatz war. Die eingesetzte Software wurde über Jahre von einem einzigen Programmierer geschrieben, es gibt keinerlei Hinweise darauf, dass diese 20.000 Zeilen an Code auch tatsächlich getestet worden sind. Fehlermeldungen wurden in einem kryptischen Code ausgegeben, davon gab es im durchschnittlichen Betrieb am Tag ca. 40, von denen die meisten nichts mit dem Patienten zu tun hatten. Durch eine fehlerhafte Programmierung des Keyboardhandlers und eine überlaufenden Variable kam es zu schweren Fehlfunktionen, der den direkten Tod von 6 Menschen durch Strahlungsüberdosen in fast 1000facher Höhe der gewünschten Dosen nach sich zogen2.
Neben diesen beiden Beispielen gibt es noch ein gutes Dutzend weiterer schwerer Fehler in Softwareprodukten in den letzten Jahrzehnten, weiterhin gibt es beliebig viele Beispiele für gescheiterte Softwareprojekte, die ihre Termine überzogen haben und wesentlich mehr Kosten als kalkuliert verursachten. Doch das Problem ist nicht neu. Mitte der Sechziger Jahre etablierte sich der Begriff der Softwarekrise. Die Einführung der Computer der sogenannten „Dritten Generation“ mit für damalige Verhältnisse sehr leistungsfähiger Hardware ermöglichte bislang unrealisierbare Anwendungen und führte zu immer größeren und komplexeren Softwaresystemen. Die damals vorherrschenden Techniken zur Softwareentwicklung und Ansätze waren nicht ausreichend um die Komplexität zu beherrschen. Während die Hardwarekosten sanken explodierten die Kosten für die Software. Dennoch war ein Käufer eines 2 Millionen Dollar Grossrechners bereit, noch einmal 250.000 Dollar beispielsweise in ein angepasstes Buchhaltungsprogramm zu investieren3. Die Programme wurden immer komplexer, Systeme wurden nicht termingerecht fertig und ausgeliefert und entsprachen oft nicht den Vorstellungen und Anforderungen der Benutzer. Kommt der Begriff „Bugs“ ursprünglich von durch Falter ausgelöste Kurzschlüsse und dadurch verursachten Fehlfunktionen eines Rechners, so mehrten sich ab den Sechziger Jahren die Fehler durch Software.
Der Begriff des Software Engineering wurde 1968 auf der NATO Conference zur Software Krise vorgeschlagen. F.L. Bauer schlug damals den Begriff Software Engineering4als
„..The establishment and use of sound engineering principles in order to obtain economically software that is reliable and runs on real machines.“
vor. Software Engineering als Unterdisziplin der Systementwicklung beschäftigt sich als technische Disziplin5nicht nur mit allen technischen Prozessen der Softwareentwicklung, sondern auch mit Aktivitäten der Projektverwaltung, Werkzeug-, Methoden- und Theorieentwicklung zur Unterstützung der Softwareherstellung. Die Definition der IEEE6definiert Software Engineering wie folgt7:
„The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.“
Zum Erreichen dieses Ziels wurden in den letzten 30 Jahren viele Techniken und Methoden entwickelt. Für die Einführung von Systemen wurden Modelle entwickelt, ebenso für die Entwicklung selbst. Die
2eine genauere Darstellung der Fehler findet sich in [Lev95]
3siehe auch Brooks in [Bro87]
4siehe [NR68]
5siehe auch [Som01], S. 22
6Institute of Electrical and Electronics Engineers, http://www.ieee.org
7IEEE Standard 610.12
Page 3
Programmierung wird durch integrierte Entwicklungsumgebungen unterstützt, die dem Programmierer durch Syntaxhervorhebung, Kodekomplettierung oder Refaktorierungsfunktionen die Entwicklung erleichtern. Die verschiedenen Anwendungsgebiete für Software, seien es Embedded Systems, Webanwendungen oder Client-/Server Architekturen haben umfangreiche Frameworks hervorgebracht. Neuere Ansätze wie die UML8, Entwurfsmuster, die sich mit Mustern in der Softwareentwicklung befassen oder Extreme und Pair- Programming begreifen den Prozess der Softwareentwicklung wieder mehr als einen zu strukturierenden Prozess geistiger Schöpfung und Kreativität, der verschiedenste Anspruchsgruppen und Anforderungen integrieren muss.
1.2 Motivation des Themas
Wissen hat sich mittlerweile als 4. Produktionsfaktor etabliert9. In der Softwareentwicklung ist Wissen essentiell. Nicht nur die Programmierung an sich, in der es auf Kenntnis über Programmiersprachen, Datenstrukturen oder Algorithmen ankommt ist sehr wissensintensiv, sondern auch das Projektmanagement oder die Definition von Anforderungen an das Softwaresystem, die durch die Einsatzumgebung und die Benutzer gestellt werden. Durch die Entwicklung immer besserer und schnellerer Hardware, wie in vorherigen Abschnitt bereits erwähnt, werden immer mehr Anwendungsgebiete erschlossen und neue Architekturen entstehen. Die objektorientierte Programmierung ist Teil eines neuen Programmierparadigmas, Softwareentwickler sind ein klassisches Beispiel für die Verpflichtung zum lebenslangen Lernen. In der Softwareentwicklung sind strukturierte Prozesse für die Entwicklung notwendig10. Eine BMBF Studie aus dem Jahr 2000, durchgeführt durch die GfK11, die den Stand der Softwareentwicklung in Deutschland dokumentiert, stellt fest, dass bislang die Softwarefirmen mit den angesprochenen Problematiken konfrontiert sind, jedoch noch zu wenig Unterstützung bekommen. Konkret gibt die Studie folgende Handlungsempfehlungen:
•Verbesserung des Softwarereifegrads in den Unternehmen durch Weiterentwicklung der Standards (State of the Art, Best Practices) und Unterstützung der Unternehmen beim Einsatz. Dazu gehört auch das systematische Erarbeiten der Datenbasis zur Einschätzung unterschiedlicher Techniken in der Softwareentwicklung und das Zuschneiden von Techniken auf bestimmte Anwendungsgebiete.
•Grundlagenforschung zur wissenschaftlichen Fundierung der Softwaretechnik in kritischen und zukunftsentscheidenden Bereichen (Safety, Security, Methodik, Werkzeuge, Modelle etc.).
•Erarbeiten von und Experimentieren mit innovativen Konzepten in der Softwaretechnik.
Im Rahmen der BMBF Projektes M-Wise aus dem Förderprogramm IT2006, in dessen Kontext auch diese Arbeit entsteht, werden einige dieser Handlungsempfehlungen umgesetzt.
Zur Beschreibung oder Definition wissensintensiver Prozesse werden unterschiedliche Ansätze verwendet12. Peter Heisig stellt die Planbarkeit des Wissensbedarfs in den Vordergrund und definiert die Wissensintensität über des Vorhandenseins von Variabilität und Ausnahmebedingungen13. Andere
8Unified Modelling Language, http://www.omg.org
9neben Arbeit, Boden und Kapital; siehe [HMP01], S. 206ff oder [Dru94]
10siehe auch [Coc01], S. 6
11Quelle: [GFF00]
12siehe auch [Gro03]
13siehe [Hei02], S. 56
Page 4
Quellen sprechen von wissensintensiven Prozessen, wenn eine Verbesserung mit klassischen Methoden der Geschäftsprozessoptimierung nicht oder nur teilweise möglich ist14. Davenport und Prusak machen die Wissensintensität u.a. anhand der Vielfältigkeit von Input und Output fest15. Als Anhaltspunkte neben den bisher genannten Kriterien gelten zusammenfassend16Quellen- und Medienvielfalt, Varianz und dynamische Entwicklung der Prozessorganisation, viele Prozessbeteiligte, unterschiedliche Expertise, Einsatz von Kreativität, hoher Innovationsgrad und verfügbarer Entscheidungsspielraum. Eine vertiefende Betrachtung zu wissensintensiven Prozessen und was im Rahmen dieser Arbeit als wissensintensiver Prozess gilt findet sich in Kapitel 3.
Schon diese Betrachtung der Kriterien verdeutlicht, dass Softwareentwicklungsprozesse als wissensintensive Prozesse aufgefasst werden müssen. Diese Prozesse werden über nur im geringen Maße strukturierte Wissensflüsse gestaltet. Diese Flüsse werden durch gängige Modellierungstools zumeist nicht modelliert bzw. aufgedeckt. Wichtige Elemente von Wissensflüssen wie die Darstellung von personengebundenem Wissen oder Wissenskonversionen können nicht adäquat und differenziert modelliert werden. Eine Möglichkeit, Wissensflüsse und -konversionen darzustellen bietet die Beschreibungssprache KMDL17, welche am Lehrstuhl für Wirtschaftsinformatik der Universität Oldenburg entwickelt und in Anwendungsfällen evaluiert wird bzw. wurde.
Im Rahmen dieser Arbeit soll der Stand der Prozessunterstützung im Software Engineering untersucht werden und wissensintensive Prozesse ermittelt und modelliert werden. Die Modellierung soll später mit Hilfe der KMDL erfolgen, dazu sollen grundlegende Vorschläge für eine neue Version der KMDL, die sogenannte KMDL-SE18und eine UML Erweiterung auf deren Basis gemacht werden.
1.3 Gliederung der Arbeit
Die Arbeit ist in mehrere Teile gegliedert. Der erste Teil mit dem Titel „Stand des Software Engineering“ beschäftigt sich mit drei Aspekten der Softwareentwicklung.
Seit dem Jahr 1968 haben sich in der Softwareentwicklung einige Prozesse entwickelt und bewährt, die in Kapitel 2 der Arbeit vorgestellt und bewertet werden. Die Gliederung der Prozesse bzw. Wissensgebiete in diesem Kapitel erfolgt nach der Gliederung19des „Software Engineering Body of Knowledge“ der IEEE20. Dabei werden Anforderungen, Entwurfs-, Entwicklungs- und Testprozesse beschreiben, die die aktuellen Wissensgebiete im Software Engineering bilden. Die Trennung zwischen Prozess und Prozessunterstützung wird dabei fließend sein, ausgewählte Prozesse werden in Kapitel 4 vertieft betrachtet. Das Kapitel 3 untersucht die in Kapitel 2 erfassten Prozesse unter den Aspekt eines wissensintensiven Prozesses. Dabei stellt das Kapitel dar, was wissensintensive Prozesse sind und überträgt anschließend das Konzept dieser Prozesse auf die Prozesse des Software Engineering. Der Fokus liegt dabei auf den besonderen Eigenschaften von wissensintensiven Geschäftsprozessen, die mit herkömmlicher Geschäftsprozessmodellierung nicht ausreichend genug abgebildet werden können. Die
14[Rem02b], S. 92
15[DP98]
16[Gro03], S. 5
17Knowledge Modelling Description Language
18Knowledge Modelling Description Language for Software Engineering
19siehe [Swe01]
20Sommerville gliederte sein Standardwerk [Som01] ebenfalls nach diesem Report
Page 5
Prozesse werden untersucht und unter Aspekten der Intensität der Nutzung von Wissen im Prozess ka-tegorisiert. Dabei wird bereits ein Fokus auf spezielle, später noch zu vertiefende Betrachtungen dieser Prozesse gesetzt. Im Kapitel 4 werden auf Basis der Einteilung aus dem zweiten Kapitel nicht nur die einzelnen Prozesse, sondern ihre Unterstützung an Hand von ausgewählten Wissengebieten betrachtet und dargestellt. Dabei werden Referenzmodelle, beispielsweise für die Entwicklung von Software oder das Konzept der (Entwurfs-)Muster in verschiedenen Bereichen des Software Engineering fokussiert.
Den zweiten Teil der Arbeit bildet ein Konzept zur Integration von Wissensflüssen und Software Engineering.
Im Rahmen dieses Kapitels wird ausgehend von der Motivation einiger wissensintensiver Prozesse im Software Engineering aus Teil I der Arbeit und dem Konzept der Modellierung wissensintensiver Prozesse mit der KMDL der Universitäten Oldenburg und Potsdam eine Erweiterung dieses Modells speziell für das Software Engineering angestrebt. Dazu werden ausgewählter Software Prozesse wie Requirements Engineering, Software Configuration Management und Testverfahren modelliert. Pattern und Modelle der bisherigen Prozessunterstützung werden dabei integriert. Der bisherige Stand der KMDL wird dokumentiert und um spezielle Eigenschaften von Software-Prozessen erweitert. Ziel ist es, eine UML-Erweiterung für die Modellierung mit der KMDL SE zu entwickeln. Der aktuelle Stand der Unterstützung durch Muster und Referenzmodelle aus Kapitel 4 soll dabei erneut aufgegriffen werden und ausgewählte Muster in der Modellierung erkannt und als Potenzial zur Prozessverbesserung durch Schwachstellenanalyse o.ä. genutzt werden. Dabei liegt der Fokus auf der Anforderungsanalyse, dem Design von Software, dem Software-Test und dem Software Konfigurationsmanagement. Der zweite Teil schließt mit einem Fazit und einem Ausblick für die Verbesserung wissensintensiver Prozesse im Software Engineering ab.
Im Anhang der Arbeit befindet sich eine Übersicht der von Lethbridge im Rahmen seiner Studie angesprochenen Wissensgebiete des Software Engineering, eine Einordnung dieser Arbeit in den Kontext des M-Wise Projektes, die Spezifikation der UML Erweiterung der KMDL SE auf Basis von UML 2.021sowie die Selbständigkeitserklärung zur Abfassung der Arbeit.
21Spezifikation gemäß [JRH+03], da noch nicht verabschiedet zum Zeitpunkt der Erarbeitung
Page 6
Teil I
Stand des Software Engineering und
Prinzipien wissensintensiver Prozesse
Page 7
Kapitel 2
Wissensgebiete und Prozesse im
Software Engineering
You can’t control what you can’t measure.
2.1 Einführung
Seit der NATO Konferenz im Jahre 1968, auf der der Begriff des Software Engineering eingeführt wurde1, sind mehr als 35 Jahre vergangen. Doch von den geforderten „Soundprinciples of engineering“ sind auch die heutigen Projekte immer noch weit entfernt. Nicht nur, dass auch heutzutage noch Software produziert wird, die nicht den Ansprüchen der Kunden an Funktionalität, Budget oder Zeitplan genügt. Software Engineering ist immer noch mehr ein Wunschtraum als Wirklichkeit- auch, weil anscheinend die derzeitigen Praktiken es erlauben, Software zu produzieren, die tatsächlich auch funktioniert, wenn auch nicht optimal2.
Zum Zeitpunkt der Tagung 1968 stand vor allem die Programmierung im Vordergrund, wenn es um die Diskussion der Prinzipien der Software Entwicklung ging. Beide Begriffe, Programmierung und Software Engineering, wurden von denselben Leuten geprägt3. Dabei handelte es sich vor allem um Mathematiker, unter ihnen Dijkstra, Hoare, Wirth oder Dahl. Es gab kaum Ingenieure unter den führenden Köpfen in der Software Entwicklung, wahrscheinlich hat sich auch deshalb keine Ingenieurswissenschaft herausgebildet. In den Siebziger Jahren stießen in die Community Vertreter der Elektrotechnik wie Gilb, Alford, Parnas oder Boehm hinzu. Das produktorientierte Denken der Mathematiker, die sehr auf Programmierung und Beweisführung bedacht waren wurde durch die Techniken der pro-zessorientiert denkenden Ingenieure ergänzt. Es wurden Begriffe wie Lebenszyklus, Phasenkonzepte, Anforderungsspezifikationen, Entwurf, Verifikation, Validation sowie Konfigurationsmanagement eingeführt4. Mitte der siebziger Jahre begann die IEEE mit der Herausgabe der bis heute bestehenden Zeitschrift „Transactions on Software Engineering“; die IEEE wollte das Software Engineering als Disziplin neben den bis dahin bestehenden konventionellen Ingenieurswissenschaften etablieren.
1siehe auch S. 2 der Arbeit
2vgl. [GFF00]
3siehe [Sne00]
4siehe auch [Sne00]
Page 8
2.2 Exkurs: Was ist eine Ingenieursdisziplin
Um zu erfahren, was für Eigenschaften das Software Engineering als Ingenieursdisziplin erfüllen muss, soll im Folgenden geklärt werden, was für Anforderungen eine Ingenieurswissenschaft stellt. Shaw5definiert zusammenfassend folgende Eigenschaften als zentral für eine Ingenieurswissenschaft, diese Punkte seien fast allen Definitionen von Ingenieurswissenschaft gemein:
„Creating cost-effective solutions to practical problems by applying scientific knowledge to building things in the service of mankind.“
Eine wirkliche Ingenieurswissenschaft soll nicht nur Probleme lösen, sondern diese auch in einem ökonomisch sinnvollen Rahmen betrachten. Sie soll praktische Probleme für Menschen außerhalb der Ingenieursgemeinschaft lösen, vor allem also die der Kunden. Dabei sollen vorrangig die Methoden von Disziplinen wie Mathematik, Wissenschaft und Design Analyse eingesetzt werden. Die Lösung steht im Vordergrund, meist ist die Lösung ein greifbarer Gegenstand. Dabei soll nicht vergessen werden, dass die Lösungen nicht nur dem Kunden dienen, sondern auch Expertise und Technologie erzeugen, die die Gemeinschaft unterstützen können.
Das Ingenieurswesen verlässt sich dabei meist auf kodifiziertes wissenschaftliches Wissen über technische Probleme einer Domäne, die es Praktikern direkt ermöglicht, dieses Wissen anzuwenden. Ingenieure mit normalen Talent können auf Basis der Nutzung dieses Wissens auf diese Art Probleme schneller lösen als ohne diese Hilfe. Virtuose Problemlösungen sind nicht Sinn und Zweck dieser Methode, vielmehr soll eine Lösung geboten werden, die zuverlässig zur Verfügung steht. Routine steht über der innovativen Lösung, die das Rad jedesmal neu erfindet. Heutzutage werden jedoch die erreichten Lösungen nicht ausreichend dokumentiert um sie späteren Teams zur Verfügung zu stellen und es gibt keinerlei dokumentiertes Wissen in einer Art von Handbüchern6. Historisch gesehen entwickelt sich eine Ingenieursdisziplin wie in Abbildung 1 dargestellt7.
5siehe [SG96], S. 6
6Vertiefung in [SG96]
7in Anlehnung an [SG96]
Page 9
Eine Technologie beginnt mit dem Handwerk, eine Reihe von Problemen muss gelöst werden. Amateure und Virtuosen lösen die Probleme, es gibt jedoch keine extra ausgewiesene Berufsgruppe hierfür. Probieren und Intuition führt zur Lösung. Fortschritte werden zwar erreicht, das Rad jedoch wieder und wieder erfunden. Die Kommunikation zwischen den Handwerkern ist unterentwickelt. Durch eine gesteigerte Nachfrage entsteht der Bedarf zur gezielten und massenhaften Produktion von Gütern. Die vorangetriebene Produktion führt zu einem Absatz, der irgendwann nicht mehr ohne eine erhöhte Produktion die Nachfrage befriedigen kann. Diese erhöhte Produktion benötigt wiederum Rohmaterialien, geschulte Arbeiter und ein sinnvolles erprobtes Prozessmodell. Hier nun muss der Prozess wissenschaftlich analysiert und verbessert werden. Die Wissenschaft trägt dann dazu bei, nicht mehr die Intuition zur Verbesserung einzusetzen, sondern stattdessen fundierte Erfahrungen als Basis zu nutzen. Ein Bedarf an ausgebildeten Berufstätigen im Bereich entsteht, ein Bildungsbedarf muss gedeckt werden. Shaw und Garlan übertragen dieses Modell auf das Software Engineering, hierauf wird jedoch nicht im Rahmen dieser Arbeit weiter eingegangen werden und stattdessen auf die Quelle verwiesen.
Zusammenfassend ist festzustellen, dass sich das Software Engineering teilweise noch im Bereich des Handwerks befindet und die Wissenschaft noch mehr ihren Anteil beitragen muss, es gibt noch Lücken im Vergleich zu anderen Ingenieurswissenschaften.
2.3 Wissensstand im Software Engineering
Basis einer Ingenieurswissenschaft ist eine dokumentierte reproduzierbare Wissensbasis. Die Frage, welche Wissensgebiete im Software Engineering von Interesse sind ist also im Folgenden zu klären. Die IEEE als Ingenieursvereinigung versucht dabei, die Wissensgebiete zu ermitteln und einen Aus-bildungstandard für Software Ingenieure aufzustellen. Durch den Standard wäre eine staatliche Zertifizierung möglich, so dass Abschlüsse vergleichbar wären. Bislang ist weltweit lediglich im Bundesstaat Texas in den USA ein Standard etabliert, der Abschlüsse vergleichbar macht8. Im Rahmen seiner Standardisierungsbemühungen hat die IEEE dabei ein Projekt ins Leben gerufen, welches versucht, einen sinnvollen Überblick über die Wissensgebiete mit weiterführenden Literaturhinweisen zu bieten, die nach Meinung der IEEE und der ACM9für einen Software Entwickler bzw. Ingenieur von Bedeutung sind - den sogenannten SWEBOK.
Die Erstellung des SWEBOK koordiniert und überwacht das Software Engineering Coordinating Committee (SWECC) . Das SWECC ist eine gemeinsame Einrichtung der ACM und des IEEE Technical Council on Software Engineering, dem TCSE. Das gesamte Projekt wurde Ende 1999 auf der zwölften internationalen Konferenz zum Thema „Software & Systems Engineering and their Applications “ vorgestellt. Der derzeitige Stand des Projektes ist in der „Trial Version 1.00“10vom Mai 2001 dokumentiert und liegt frei im Netz verfügbar unter der Adressehttp://www.swebok.orgvor11.
Der SWEBOK gliedert sich in folgende Wissensbereiche (Knowledge Areas) auf. Diese Wissenbereiche sind in der bisherigen Version, dem sogenannten Stoneman-Release:
•Software Requirements
8vgl. [Sne00]
9Association for Computing Machinery, siehe auchhttp://www.acm.org
10siehe [Swe01]
11Vertiefende Informationen finden sich in [BDA+99]
Page 10
•Software Design
•Software Construction
•Software Testing
•Software Maintenance
•Software Configuration Management
•Software Engineering Management
•Software Engineering Process
•Software Engineering Tools and Methods
•Software Quality
Jedes dieser Wissengebiete wird weiterhin unterteilt, so dass sich aus diesen 10 Gebieten jeweils ca. 7-8 weitere Gebiete ableiten lassen. Die Frage, ob diese Gebiete bei einem Gremium von 300 beteiligten Mitgliedern überhaupt vollständig definiert werden können oder noch ganz andere Knowledge Areas betrachtet werden müssen, soll hier nicht diskutiert werden. Kritiker merken an, dass der SWE-BOK nicht als Curriculum12dienen soll und daher andere Wissengebiete vernachlässige, die für einen Software Entwickler wichtig sind (etwa Mathematik, Management, Software Ergonomie). Offensichtlich wäre beispielsweise der Mangel zum Thema Software Komponenten, was heutzutage durchaus als eigene Knowledge Area gelten sollte. Weitere Informationen hierzu finden sich beispielsweise unter [ER03]. Ziel war und ist es, einen sogenannten „generally accepted standard of knowledge “ zu finden und zum IEEE Standard zu erheben. Zusammenfassend ist festzustellen, dass die IEEE mit dem SWEBOK anstrebt, eine konsistente Darstellung des Software Engineerings weltweit bereitzustellen, den Kontext und Platz des Software Engineerings in der Welt der Wissenschaft zu erläutern, die Eigenschaften des Software Engineering als Ingenieursdisziplin zu veranschaulichen, einen themenbezogenen Zugang zum Software Engineering zu bieten und die Basis für das Curriculum13eines Software Engineers zu bieten, um die herum ein Studiengang bzw. eine Ausbildung aufgebaut werden kann.14
2.4 Wissensgebiete eines Software Ingenieurs
Es stellt sich nach den Betrachtungen der vorherigen Abschnitte die Frage, in welcher Gewichtung die im SWEBOK genannten Wissengebiete für einen Software Ingenieur von Bedeutung sind und welche weiteren Wissensgebiete er möglicherweise für seine Arbeit benötigt. Im Besonderen sollen diese Betrachtungen dazu dienen herauszufinden, wo möglicherweise Prozesse im Software Engineering nicht
12unter Curriculum wird in diesen Zusammenhang der gesamte Studienplan zur Ausbildung eines Software Engineers verstanden, er umfasst auch Gebiete wie Mathematik, Technische und Theoretische Informatik und Soft Skills
13einen Studienplan eines Software-Ingenieurs findet man exemplarisch beim Hasso-Plattner Institut für Software-Systemtechnik unterhttp://www.hpi.uni-potsdam.de/deu/studium/studord.de.html,einen Entwurf für Wirtschaftsinformatiker in [LS04]
14Anmerkung: Während der Entstehung dieses Kapitels wurde der Ironman-Release des SWEBOK veröffentlicht, wesentliche inhaltliche Änderungen wurden nur in der Gebieten Construction, Management und Quality vorgenommen. Zu finden ist der SWEBOK 2004 [Swe04] unterhttp://www.swebok.org
Page 11
ausreichend gelehrt werden und welche Prozesse von besonderer Bedeutung für Praktiker sind15. Die meisten Universitäten und Ausbildungsbetriebe tendieren sicher dazu, ihr Curriculum an der Meinung von Experten wie der IEEE auszurichten- die Frage, was Praktiker jedoch brauchen soll im Folgenden diskutiert werden.
Timothy Lethbridge, Professor an der Universität Ottawa führte zu diesen Zweck 1998 eine Studie durch16. Im Rahmen der Studie befragten sie 186 Kandidaten aus der Industrie zu 75 Wissensgebieten rund um das Software Engineering17. Dabei handelte es sich um aus Schul- und Universitätsbildung ausgewählte Gebiete einer Ausbildung zum Software Entwickler. Die Kandidaten wurden zu diesen Gebieten jeweils vier Fragen gestellt:
1. Wieviel wissen Sie über dieses Themengebiet durch Ihre Ausbildung, sei es von Universität oder College?
2. Wieviel wissen Sie aktuell über dieses Thema, d.h. wieviel habe Sie in etwas durch ihre Tätigkeit dazugelernt oder vergessen?
3. Wie wichtig waren Details über dieses Wissengebiet für ihren bisherigen Werdegang als Entwickler oder Manager?
4. Wieviel Einfluss hatte das Lernen diese Wissensgebietes auf ihr Denken oder wieviel des Gebietes haben Sie angewendet?
Mit Hilfe dieser Fragen wurden die 75 Gebiete analysiert und eine nach verschiedenen Aspekten aufgeteilte Auswertung erstellt. Dabei kam es zu einigen interessanten Ergebnissen. Wie erwartet wurde bei den Praktikern Mathematik, Physik und Chemie in der Software Entwicklung als unwichtig empfunden. Software Entwickler haben diesen Stoff oftmals schnell wieder vergessen und wenden ihn selten bis nie an. Auf der anderen Seite war schnell zu erkennen, dass es ein große Wissenslücken in den Bereichen Software Prozesse, Soft und Management Skills und Mensch-Computer-Interaktion liegen18. Als Quellen für das Schliessen dieser Lücken gaben die Befragten technische Literatur, Schulungen und Expertenüberblicke über die Themengebiete an. Die Studie bietet Erkenntnisse und Übersichten über die für Software Ingenieure wichtigsten Wissengebiete, Wissengebiete die in der Praxis gefordert werden und in der Bildung vernachlässigt werden, Wissensgebiete, bei denen auch die Praktiker noch Lücken sehen im Vergleich zu den der Erfordernissen ihrer aktuellen Stellung. Die folgenden drei Top 6 Listen bieten eine Übersicht über die Ergebnisse in Bezug auf die drei eben genannten Übersichten. Die Gebiete der Tabelle 2.1 sind nach Ansicht der Praktiker am wichtigsten in der Ausbildung. Die Ergebnisse der wichtigsten Gebiete sind nicht überraschend, sind diese Gebiete doch tatsächlich die essentiellen Gebiete, die zur Entwicklung jeder modernen Software beitragen, die den Erfordernissen der Auftraggeber entsprechen soll.
Die in Tabelle 2.2 aufgeführten sechs Gebiete sind in der Ausbildung nach Meinung der Befragten vernachlässigt worden und mussten im Job größtenteils nachgearbeitet werden.
15siehe auch Spillner in [SWW03], S.22ff
16siehe die Gesamtstudie unter [Let99] oderhttp://www.site.uottawa.ca/~tcl/edrel/
17eine Gesamtaufsteleung der Themen ist unter [Let99], S.6 oder im Anhang dieser Arbeit zu finden
18siehe [Let00]
