1 Einführung und Motivation
1.1 Einführung
1.2 Motivation des Themas
1.3 Gliederung der Arbeit
I Stand des Software Engineering und Prinzipien wissensintensiver Prozesse
2 Wissensgebiete und Prozesse im Software Engineering
2.1 Einführung
2.2 Exkurs: Was ist eine Ingenieursdisziplin
2.3 Wissensstand im Software Engineering
2.4 Wissensgebiete eines Software Ingenieurs
2.5 Anforderungsanalyse und -erfassung
2.5.1 Einführung und Definition
2.5.2 Der Anforderungsprozess
2.5.3 Erfassung der Anforderungen
2.5.4 Analyse der Anforderungen
2.5.5 Spezifikation der Anforderungen
2.5.6 Überprüfung der Anforderungen
2.6 Design von Software
2.6.1 Einführung und Definition
2.6.2 Hauptinteressensgebiete
2.6.3 Software Architekturen
2.6.4 Software Design Qualität
2.6.5 Software Design Notationen
2.6.6 Software Design Strategien
2.6.7 Software Konstruktion
2.7 Testen von Software
2.7.1 Einführung und Definition
2.7.2 Testgrundlagen
2.7.3 Ebenen des Testens
2.7.4 Arten des Testens- was wird getestet
2.7.5 Arten des Testens- wie wird getestet
2.7.6 Testmetriken
2.7.7 Der Testprozess
2.8 Softwarekonfigurationsmanagement
2.8.1 Einführung und Definition
2.8.2 Planung des Konfigurationsmanagements
2.8.3 Änderungsmanagement
2.8.4 Versionsmanagement
2.8.5 Releasemanagement
2.8.6 Systemzusammenstellung
2.9 Weitere Wissensgebiete des Software Engineering
2.9.1 Softwarewartung
2.9.2 Software Engineering Management
2.9.3 Software Engineering Prozesse
2.9.4 Software Engineering - Werkzeuge und Methoden
2.9.5 Qualität und Software
2.10 Fazit und Folgen für die Arbeit
3 Software Engineering Prozesse als wissensintensive Prozesse
3.1 Einführung und Motivation
3.2 Wissensmanagement
3.2.1 Motivation
3.2.2 Definitionen
3.2.3 Wissensmanagementansätze
3.2.4 Wissensmanagement im Rahmen dieser Arbeit
3.3 Prozessorientierung
3.3.1 Der Prozessbegriff
3.3.2 Begriff des Geschäftsprozesses
3.3.3 Geschäftsprozessmodellierung
3.4 Wissensintensive Geschäftsprozesse
3.4.1 Definition und Merkmale wissensintensiver Prozesse
3.4.2 Wissens- und Geschäftsprozessmanagement
3.4.3 Ansätze zum prozessorientierten Wissensmanagement
3.5 Wissensintensive Prozesse im Software Engineering
3.5.1 Software Engineering Prozesse
3.5.2 Klassifikation der SE Prozesse
3.6 Fazit und Folgen für diese Arbeit
4 Stand der Prozessunterstützung im Software Engineering
4.1 Einführung
4.2 Unterstützung der Anforderungsanalyse
4.2.1 Der Anforderungsprozess
4.2.2 Das Anforderungsdokument
4.2.3 Werkzeugunterstützung des Prozesses
4.2.4 Ausblick zur Unterstützung
4.3 Unterstützung des Designprozesses
4.3.1 Der Designprozess
4.3.2 Entwicklungsmodelle
4.3.3 Das Patternkonzept
4.3.4 Die UML
4.3.5 Ausblick zur Unterstützung
4.4 Unterstützung des Testens
4.4.1 Der Testprozess
4.4.2 Testtechniken
4.4.3 Dokumentation von Testfällen
4.4.4 Automatisierte Unit Tests
4.4.5 Ausblick zur Unterstützung
4.5 Unterstützung des Konfigurationsmanagements
4.5.1 Der Konfigurationsmanagementprozess
4.5.2 Toolunterstützung
4.5.3 Configuration Management Patterns
4.5.4 Ausblick zur Unterstützung
4.6 Fazit und Folgen für diese Arbeit
4.6.1 Anforderungsanalyse
4.6.2 Design von Software
4.6.3 Testen von Software
4.6.4 Konfigurationsmanagement
4.6.5 Generelle Anforderungen durch die Softwareentwicklung
II Integration von Wissensflüssen und Software Engineering
5 Integration von Modellierung und Entwicklung
5.1 Erstellung einer Modellierungslösung zur Unterstützung der Softwareentwicklung
5.2 Stand des Wissensmanagement in der Softwareentwicklung
5.2.1 Einführung
5.2.2 Ziele des Wissensmanagement in der Softwareentwicklung
5.2.3 Typen von untersuchten Wissen und Arten von Prozessen
5.2.4 Methoden der Unterstützung
5.2.5 Anforderungen an eine Wissensmanagementlösung für die Softwareentwicklung
5.2.6 Zusammenfassung und Ausblick
5.3 Anforderungen an die Sprache zur Modellierung
5.3.1 Anforderungen durch Wissensmanagement im SE
5.3.2 Anforderungen durch die Definition von Wissen
5.3.3 Anforderungen durch die Softwareentwicklung
5.3.4 Anforderungen zur Unterstützung wissensintensiver Prozesse
5.3.5 Anforderungen an Modellierungssprachen
5.3.6 Fazit
5.4 Die KMDL
5.4.1 Einführung in die KMDL
5.4.2 Objekte
5.4.3 Wissenskonversionen
5.4.4 Beschreibung des stillschweigenden Wissens
5.4.5 Erzeugung von Wissens- und Informationsobjekten
5.4.6 Die Sichten der KMDL
5.4.7 Weiterentwicklung zur KMDL SE
5.4.8 Einbindung in die Softwareentwicklung
5.4.9 Ausgewählte Konzepte der KMDL SE
5.5 Zusammenfassung und Ausblick
6 Zusammenfassung und Ausblick
6.1 Zusammenfassung der Kapitel
6.2 Ausblick für weitere Arbeiten im Bereich
Literaturverzeichnis
Stichwortverzeichnis
Abkürzungsverzeichnis
III Anhang
A Die Arbeit im Kontext des Projektes M-Wise
A.1 Die unterstützten Pakete in der Übersicht
A.1.1 2.UO Review KMDL
A.1.2 8.UO Entwurf und Spezifikation der KMDL-SE
A.1.3 9.O Survey: Einsatz von Wissensmanagement in der Softwareentwicklung in Deutschland
A.1.4 14.O KMDL-SE als UML-Erweiterung
A.1.5 22.O Entwurf einer flexiblen Architektur für Wissensmanagementsysteme
A.2 Unterstützung der Pakete
A.2.1 Review der KMDL
A.2.2 Entwurf und Spezifikation der KMDL SE
A.2.3 Einsatz von Wissensmanagement in der Softwareentwicklung in Deutschland
A.2.4 Die KMDL-SE als UML Erweiterung
A.2.5 Entwurf einer flexiblen Architektur für Wissensmanagementsysteme
B UML Erweiterung der KMDL SE
C Wissensgebiete aus [Let99]
2.1 Entwicklung einer Ingenieursdisziplin
3.1 Wissensdimensionen nach Aristoteles
3.2 Wissenstreppe nach North
3.3 Wissensbausteine nach Probst
3.4 Die vier Wissenskonversionen nach Nonaka/Takeuchi
3.5 Die organisationale Wissensspirale nach Nonaka/Takeuchi
3.6 Umfeld und Einflussfaktoren auf Geschäftsprozesse
3.7 Klassifikation von Geschäftsprozessen nach Eppler et al
3.8 Eigenschaften wissensintensiver Geschäftsprozesse nach Gronau
3.9 Integration von Geschäfts- und Prozessmanagement nach Nägele und Schreiner
4.1 Requirements Engineering-Prozess nach Kotonya und Sommerville
4.2 Screenshot des Tools DOORSrequireIT
4.3 Screenshot des Tools IBM Rational Requisite Pro 6.3
4.4 Das allgemeine V-Modell
4.5 Das Iterative Modell des RUP über seine zwei Dimensionen
4.6 Einfache Darstellung des RUP
4.7 Screenshot JUnit TestRunner
4.8 Screenshot WinCVS
5.1 Zusammenhang der Objekte der KMDL 1.0
5.2 Objekte und Relationen der KMDL 1.1
5.3 Aufgabensicht der KMDL 1.1
5.4 Einfache Prozesssicht der KMDL 1.1
5.5 Erweiterte Prozesssicht der KMDL 1.1
5.6 Wissenssicht der KMDL 1.1
5.7 Erweiterte Prozesssicht der KMDL 1.1
5.8 Erweiterte Prozesssicht der KMDL 1.1
5.9 Internalisierung in der KMDL 1.1
5.10 Externalisierung in der KMDL 1.1
2.1 Wichtigste Wissensgebiete in der Ausbildung eines Softwareentwicklers
2.2 Wissensgebiete, die im Job nachgearbeitet werden mussten
2.3 Wissensgebiete, die in der Ausbildung vernachlässigt werden
3.1 Wissenstaxonomien und Beispiele
3.2 Wissensmanagementstrategien nach [FKR02]
3.3 Wissensintensive Prozesstypen nach Remus
3.4 Wissensintensive Prozesse im Software Engineering - eine Klassifikation
B.1 UML Erweiterung der KMDL
Kapitel 1
Einführung und Motivation
Software is neither land nor sea, but swamp.
A hybrid to thin for the army (Software Engineering) and too thick for the navy (Computer science).
(Brad Cox)
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 Wis- sensgebiete 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 wissensin- tensive Prozesse identifiziert und ihre jeweiligen Schwerpunkte und Prozessunterstützungen dargestellt werden. Aus den Erkenntnissen über wissensintensive Prozesse, Wissensgebiete der Softwareentwick- lung und der Unterstützung der Wissensgebiete lassen sich zusammen mit dem Stand der Unterstüt- zung der Softwareentwicklung durch Wissensmanagement und Anforderungen an Modellierungspra- chen 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 possi- bility to identify the main focus and process support for knowledge-intensive processes. From the gai- ned knowledge about the knowledge areas of software engineering, the characteristics of knowledge- intensive 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 Mode- ling 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.
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 ComputerIndustrie, 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.
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 Wissensma- nagements 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.
Oldenburg, den 21.9.2004
Mathias Uslar
Software findet sich heutzutage fast überall. Im Haushalt, in der Industrie, der Verwaltung, der Finanz- welt 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 demsel- ben 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 Auseinander- brechen 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 Sonnen- partikel 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.
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 Soft- wareprodukten 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 ver- ursachten. 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 damali- ge 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äu- fer eines 2 Millionen Dollar Grossrechners bereit, noch einmal 250.000 Dollar beispielsweise in ein angepasstes Buchhaltungsprogramm zu investieren3. Die Programme wurden immer komplexer, Sys- teme 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 Sech- ziger 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 Engineering4 als
„.. 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 Disziplin5 nicht 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 IEEE6 definiert 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 softwa- re.“
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 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.
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 Projektmana- gement 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 Programmier- paradigmas, 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 Softwareentwick- lung 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 Stan- dards (State of the Art, Best Practices) und Unterstützung der Unternehmen beim Einsatz. Da- zu gehört auch das systematische Erarbeiten der Datenbasis zur Einschätzung unterschiedlicher Techniken in der Softwareentwicklung und das Zuschneiden von Techniken auf bestimmte An- wendungsgebiete.
- 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 ver- wendet12. Peter Heisig stellt die Planbarkeit des Wissensbedarfs in den Vordergrund und definiert die Wissensintensität über des Vorhandenseins von Variabilität und Ausnahmebedingungen13. Andere 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 zusammenfassend16 Quellen- 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 unter- sucht 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-SE18 und eine UML Erweiterung auf deren Basis gemacht werden.
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. Wissens- gebiete in diesem Kapitel erfolgt nach der Gliederung19 des „Software Engineering Body of Knowled- ge“ der IEEE20. Dabei werden Anforderungen, Entwurfs-, Entwicklungs- und Testprozesse beschrei- ben, 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 wis- sensintensiven Prozesses. Dabei stellt das Kapitel dar, was wissensintensive Prozesse sind und über- trä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 her- kömmlicher Geschäftsprozessmodellierung nicht ausreichend genug abgebildet werden können. Die 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. Pat- tern 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 wer- den und ausgewählte Muster in der Modellierung erkannt und als Potenzial zur Prozessverbesserung durch Schwachstellenanalyse o.ä. genutzt werden. Dabei liegt der Fokus auf der Anforderungsanaly- se, 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 Pro- zesse 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 Kon- text des M-Wise Projektes, die Spezifikation der UML Erweiterung der KMDL SE auf Basis von UML 2.021 sowie die Selbständigkeitserklärung zur Abfassung der Arbeit.
Kapitel 2
You can’t control what you can’t measure. (Tom DeMarco)
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 „Sound principles of enginee- ring “ 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 Zeit- plan 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 funk- tioniert, 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üh- renden Köpfen in der Software Entwicklung, wahrscheinlich hat sich auch deshalb keine Ingenieurs- wissenschaft herausgebildet. In den Siebziger Jahren stießen in die Community Vertreter der Elektro- technik 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 ein- gefü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.
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. Shaw5 definiert 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.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Entwicklung einer Ingenieursdisziplin
Eine Technologie beginnt mit dem Handwerk, eine Reihe von Problemen muss gelöst werden. Ama- teure 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 ei- ne 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 Rohmate- rialien, 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 nut- zen. 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.
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 Zertifi- zierung 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 Stan- dardisierungsbemü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 ACM9 fü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 Tech- nical 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 Applica- tions “ vorgestellt. Der derzeitige Stand des Projektes ist in der „Trial Version 1.00“10 vom Mai 2001 dokumentiert und liegt frei im Netz verfügbar unter der Adresse http://www.swebok.org vor11.
Der SWEBOK gliedert sich in folgende Wissensbereiche (Knowledge Areas) auf. Diese Wissenbereiche sind in der bisherigen Version, dem sogenannten Stoneman-Release:
- Software Requirements
- 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 betei- ligten 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 Curriculum12 dienen soll und daher andere Wissengebiete vernachlässige, die für einen Software Entwickler wichtig sind (etwa Mathematik, Management, Software Ergonomie). Offensicht- lich wäre beispielsweise der Mangel zum Thema Software Komponenten, was heutzutage durchaus als eigene Knowledge Area gelten sollte. Weitere Informationen hierzu finden sich beispielsweise un- ter [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 bereitzu- stellen, 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 the- menbezogenen Zugang zum Software Engineering zu bieten und die Basis für das Curriculum13 eines Software Engineers zu bieten, um die herum ein Studiengang bzw. eine Ausbildung aufgebaut werden kann.14
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 Be- trachtungen dazu dienen herauszufinden, wo möglicherweise Prozesse im Software Engineering nicht 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 Ent- wickler oder Manager?
4. Wieviel Einfluss hatte das Lernen diese Wissensgebietes auf ihr Denken oder wieviel des Gebie- tes haben Sie angewendet?
Mit Hilfe dieser Fragen wurden die 75 Gebiete analysiert und eine nach verschiedenen Aspekten aufge- teilte 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 empfun- den. 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 Be- reichen 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.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.1: Wichtigste Wissensgebiete in der Ausbildung eines Softwareentwicklers
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.2: Wissensgebiete, die im Job nachgearbeitet werden mussten
Diese Gebiete sind in der Ausbildung nicht verstärkt unterrichtet worden, da sie im Lehrbetrieb nicht in größeren Projekten eingeführt und überprüft werden können. Sämtliche Prozesse sind für kommer- zielle Software wichtig, bei denen auch eine anschließende Wartung von Bedeutung ist. Die Fehler- freiheit steht bei Lehrprojekten nicht im Vordergrund, da meist nur eine abschließende Präsentation mit einem vorher vorbereiteten Test-Case erfolgt und Fehler leicht überspielt oder versteckt werden können. Fehler in kommerzieller Software verursachen jedoch leicht Kosten, die wieder auf den Soft- warehersteller zurückfallen19. Die Erfassung der Anforderungen für eine vertragsgemäß hergestellte Software ist von überragender Bedeutung, damit ein Kunde auch ein System bekommt, welches seinen Ansprüchen genügt.
Häufig werden in den Lehrprojekten die Anforderungen zwecks Verkürzung der Zeit oder Vergleichbarkeit identischer Gruppen jedoch vorgegeben. Diese drei Prozesse werden im Verlauf der Arbeit noch weiter beleuchtet. Die Konzepte der objekt-orientierten Entwicklung sind im Rahmen größerer Projekte von erhöhter Bedeutung, Das Reengineering tritt in den Vordergrund, wenn es um die Integration von Legacy-Systemen über Middleware-Konzepte geht.
Das Projektmanagement als allgemeiner Problembereich von unerfahrenen Entwicklern soll im wei- teren nur noch als Unterpunkt betrachtet werden, weitere Informationen zu Wissensgebieten im Pro- jektmanagement finden sich im Project Management Body of Knowledge (PMBOK).20 Die Tabelle 2.3 enthält die Wissensgebiete, in denen die Software Ingenieure auch heutzutage ihrer Meinung nach nicht ausreichend ausgebildet sind. Die Abschätzung der Entwicklungskosten ist aufgrund der aktuel- len Probleme aktueller denn je, die Kosten für Projekte im vornherein richtig abschätzen zu können könnte viele aktuelle Softwareprojekte fördern. Management und Verhandlungserfahrungen sind für Rang: Themengebiet:
1. Verhandlung
2. Mensch-Computer Schnittstellen
3. Führungseigenschaften
4. Real-Zeit Systeme und - Entwurf
5. Management
6. Software Kosten Abschätzungen
Tabelle 2.3: Wissensgebiete, die in der Ausbildung vernachlässigt werden
den ökonomischen Erfolg einer Softwarefirma von besonderer Bedeutung, ebenso die Führungseigen- schaften eines Ingenieurs. Die Gebiete der Mensch-Maschine Interaktion und Real-Zeit Systeme sind für bestimmte Gruppen von Entwicklern von besonderer Bedeutung, auch wenn die Schnittstelle zu einem System für die meisten Entwickler von höherer Bedeutung als die Entwicklung von Real-Zeit Systemen ist.
Aus den Ergebnissen der Studie sollen auch für diese Arbeit Erkenntnisse gezogen werden. In folgenden soll der Fokus auf Wissensgebiete gesetzt werden, die in der Berufstätigkeit noch nachgelernt werden müssen oder allgemein Prozessunterstützung bereitstellen. Diese stehen nach einer allgemeinen Betrachtung der Wissensgebiete des SWEBOK im Blickpunkt, vor allem unter der Berücksichtigung des Aspektes von wissensintensiven Prozessen.
Die folgenden Unterkapitel stellen exemplarische Wissensgebiete des SWEBOK jeweils kurz und überblicksartig vor. Dabei wir ein genereller Überblick geboten, der die Untergliederung des IronmanSWEBOK21 aufgreift und erst die sogenannten „fundamentals“, gefolgt von einzelnen Teildisziplinen in Kürze beschreibt. Dabei wird jedoch die Prozessunterstützung ausgelassen, da diese in einem späteren Kapitel Untersuchungsgegenstand sein wird.
Betrachtungen großer Softwareprojekte weisen immer wieder gescheiterte Projekte auf, bei denen die Entwickler am Bedarf der Kunden schlichtweg vorbeiprogrammiert und -entwickelt haben. Es wurde zwar meist das Programm richtig (gemäß den Spezifikationen), aber nicht das richtige Programm (im Sinne der Endkunden) entwickelt. Meist lässt sich der Hauptfehler in diesen Projekten, wenn auch nicht immer, auf eine verfehlte Anforderungsanalyse reduzieren. Fehler in der Anforderungsanalyse sind kostenintensiv, sie verzögern ein Projekt länger als jede andere Art von Fehlern, wenn sie besei- tigt oder nachgearbeitet werden müssen. Der Prozess der Anforderungsermittlung22 an ein System ist daher im Software Engineering von besonderer Bedeutung. Es ist eine Herausforderung, Anforderun- gen aufzustellen, die man nicht anhand von gegebenen Daten überprüfen kann. Um die Bedeutung und die Prozesse der Anforderungsanalyse zu verstehen, muss jedoch erst einiges an Basiswissen gelegt werden.
Kotonya und Sommerville definieren eine Anforderung (Requirement) als „a statement of a system service or constraint“, also eine Aussage über einen Dienst oder eine Nebenbedingung23. Das Requi- rements Engineering (RE) befasst sich mit dem Prozess der Entwicklung der Anforderungen für ein System. Die Literatur ist sich bei den Kosten für das RE nicht einig. Kotonya nennt Kosten im Rah- men von 10-15 Prozent der Entwicklungskosten, je nach Größe des Projektes, Brown et al. gehen von etwa 30 Prozent aus24. Sinn und Zweck des Aufwandes dieser Kosten ist es, späte, unzuverlässige und den Kundenwünschen nicht entsprechende Systeme zu verhindern. Die Anforderungen werden in so- genannten Anforderungsdokumenten erfasst. Wie diese Dokumente erstellt werden, wird in späteren Abschnitten beispielhaft erläutert.
Es lassen sich mehrere Arten von Anforderungen unterscheiden. Die Literatur25 unterscheidet die funktionalen (functional), die nicht-funktionalen (non-functional) , die Problembereichs- (emergent) , die Benutzer- (user) , die System-26, die Prozess- und die Produktanforderungen.
Funktionale Anforderungen sind Aussagen zu Diensten, die das System leiten soll, zur Reaktion des Systems auf bestimmte Eingaben und zum Verhalten des Systems in bestimmten Situationen. Manchmal werden funktionale Anforderungen auch dazu genutzt, auszudrücken, was ein System nicht tun soll.
Nicht-funktionale Anforderungen sind Beschränkungen der durch das System angebotenen Diens- te oder Funktionen. Dies umfasst Zeitbeschränkungen, Beschränkungen des Entwicklungspro- zesses, einzuhaltende Standards etc.27
Problembereichsanforderungen sind Anforderungen, die sich erst aus dem gesamten System und nicht nur aus seinen Komponenten ergeben. Sie spiegeln die Charakteristika des Systems wieder. Dabei kann es sich um funktionale als auch um nicht-funktionale Anforderungen han- deln.
Benutzeranforderungen beschreiben die funktionalen und nicht-funktionalen Anforderungen so, dass sie für den Systembenutzer verständlich sind. Diese haben meist kein detailliertes techni- sches Wissen, deswegen enthalten diese Anforderungen keine Charakteristika des Systement- wurfs.28
Systemanforderungen sind genaue Beschreibungen der Benutzeranforderungen an das System als Ganzes. Sie dienen daher als Basis für eine Vertrag über die Implementierung des Systems. Sie sollten daher eine komplette und widerspruchsfreie Spezifikation des Systems darstellen.
Prozessanforderungen sind Bedingungen, die der Entwicklungsprozess dem Softwareentwickler auferlegt. Prozessanforderungen sind meist nicht-funktionale Anforderungen, etwa an die Pro- grammiersprache oder das Entwicklungsmodell.
Produktanforderungen werden die Anforderungen an die Dienste und Funktionen der zu entwi- ckelnden Software genannt. Produktanforderungen sind daher stets funktionale Anforderungen.
Um die im vorherigen Abschnitt genannten Anforderungen zu erheben, wurden verschiedenste Tech- niken entwickelt und genutzt. In den 70er Jahren wurde die Systems Analysis and Design Technique, kurz SADT entwickelt, die zur Ist-Aufnahme der Daten im Unternehmen genutzt wird29. Eine weitere Methode ist die Analyse aufgrund von Use-Cases mit der UML, die bei den einzelnen Anspruchs- gruppen mittels eines fall-basierten Verfahrens versucht, Dienste und Beschränkungen zu ermitteln30. Neben diesen beiden gebräuchlichen Verfahren existieren eine Menge weiterer Best-Practice Verfah- ren, auf die später noch einmal eingegangen wird. Ihnen allen ist gemein, das die Anforderungsanalyse kein der Entwicklung vorgelagerter Prozess ist, sondern vor dem Start des Projektes beginnt und bis zum Ende der Nutzung der Software dauert. Der Prozess muss an die bestehende Organisation an- gepasst werden, um die Anforderungen als Konfigurationsitems für den Prozess zu erfassen.Typische Aktoren im Prozess sind Nutzer der Software, die Kunden und Auftraggeber, Marktanalysten31, Regu- lierungsbehörden und Softwareentwickler. Jede dieser Gruppen nimmt am Prozess teil und versucht, ihre Vorstellungen in den Prozess einzubringen.
Dieses Teilwissensgebiet befasst sich mit den Fragen, wie und wo die Anforderungen erhoben werden. beide Fragen spielen bei der Qualität der Daten eine wichtige Rolle. Als Quellen für die Anforderungen identifiziert der SWEBOK folgende:
Ziele Beschäftigt sich mit den übergeordneten Zielen des Unternehmens, der Zweck weswegen die Software überhaupt eingeführt werden soll.
Domänenwissen Der Softwareentwickler muss Wissen über die Anwendungsdomäne besitzen. Dies ermöglicht es ihm, implizites Wissen, dass bei Interviews mit den Anspruchsgruppen nicht aus- gesprochen wird, einzubringen.
Anspruchsgruppen Die im vorherigen Abschnitt genannten Gruppen können ihr Wissen und ihre Wünsche an die Software kommunizieren und zum Erfolg des Projektes beitragen. Dabei müssen die einzelnen Interessen der Gruppen jedoch sorgfältig abgewogen werden.
Operationelles und Organisatorisches Umfeld Beide Umfelder bieten sehr schnell Zugang zu nicht-funktionellen Anforderungen wie Betriebssystem oder Skalierbarkeit.
Neben den Quellen für die Anforderungen spielen die Methoden der Erhebung eine wichtige Rolle. Für die Ist-Analyse haben sich Interviews, Szenarien, Prototypen, erleichternde Treffen sowie die Beobachtung als nützlich erwiesen32.
Dieses Teilgebiet beschäftigt sich mit dem Auflösen von Konflikten zwischen den Anforderungen, den Grenzen des Systems zur Umgebung und überprüft die Systemanforderungen, um daraus Benutzeran- forderungen abzuleiten. Die Analyse versucht darüberhinaus, eine Klassifikation der Anforderungen gemäß den in den Grundlagen genannten Kategorien33 vorzunehmen. Darüberhinaus müssen die An- forderungen priorisiert werden um abschätzen zu können, welche Punkte für den folgenden System- entwurf von besonderer Bedeutung sind und wo die Anforderungen eher Empfehlungen oder Wünsche sind. Neben der Klassifizierung und Priorisierung ist die Stabilität der Anforderungen von Bedeutung. Wenn sich verändernde Anforderungen bekannt sind, können die Entwickler ein Design entwickeln, welches gegenüber Veränderungen tolerant ist. Um die Anforderungen weiter zu analysieren, können konzeptuelle Modelle entwickelt werden. Dies kann mittels der UML erfolgen oder aber auch in einer Sprache wie Z34 zur formalen Spezifikation. Am Ende dieser Phase sollte die Architektur entwickelt werden und die Anforderungen den einzelnen Komponenten zugewiesen werden.
Die Spezifikation der Anforderungen erfolgt typischerweise aufgrund der großen Anzahl der Anforde- rungen in einem Dokument, welches danach systematisch überprüft, evaluiert und genehmigt werden kann. Die Erstellung des System Definition Document definiert eine Beschreibung aus Anwendungs- sicht. Er bietet eine Übersicht über das System samt der Zielumgebung, Annahmen, Nebenbedingun- gen und Anforderungen. Es kann weiterhin konzeptuelle Modelle aus der vorherigen Phase enthalten. Um den Unzulänglichkeiten von natürlicher Sprache aus dem Weg zu gehen, werden hier meist forma- le oder semi-formale Methoden benutzt, um die Anforderungen zu dokumentieren. Es haben sich Me- thoden wie QML35 (Quality Modeling Language) durchgesetzt, die es ermöglichen, nicht-funktionale Anforderungen für Quality of Service zu spezifizieren.
Die Anforderungsokumente werden üblicherweise noch validiert und verifiziert. Es wird überprüft, ob der Software Entwickler die Anforderungen verstanden und korrekt formalisiert hat. Es wird verifi- ziert, ob das Dokument den Standards der Firma entspricht und komplett, konsistent und verständlich ist. Dazu werden die Dokumente von verschiedenen Anspruchsgruppen überprüft. Diese Review fin- det mehrfach im gesamten Prozess statt. Für die Überprüfung haben sich verschiedene best-practices herausgebildet.
Bei einem Review in einer Gruppe mit verschiedenen Anspruchsgruppenvertretern lesen diese die Dokumente auf Fehler, falsche Annahmen oder Unklarheiten durch und tauschen sie danach erneut aus. Am Ende wird in einer Sitzung das Dokument verändert verabschiedet. Eine weitere Möglichkeit, die Annahmen zu Prüfen ist das Prototyping. Vorteile sind in einer besseren Abprüfung von dynami- schen Verhalten und den damit verbundenen nicht-funktionalen Anforderungen zu erkennen. Oftmals kann über Skalierbarkeit ermittelt werden, ob die getroffenen Architekturen die Anforderungen erfül- len kann oder nicht. Das Model Checking wird vor allem bei formalen Spezifikationen genutzt, um zu überprüfen, ob die Anforderungen die Spezifikationen des Systems möglich machen. Ein letzter Punkt sind die Akzeptanztests, die wichtige Anforderungen direkt von End-Nutzer abprüfen lassen.
Design wird als der Prozess und das Ergebnis der Definition von Architektur, Komponenten, Schnittstellen und anderen Charakteristika eines Systems oder einer Komponente aufgefasst36. Die Designphase liefert eine Art Blaupause für die zu implementierende Lösung. Diese Blaupause kann im Hinblick auf die Anforderungen analysiert werden. Alternativen können in dieser Phase noch mit vergleichsweise geringem Kostenaufwand erstellt und verglichen werden. Ist die Wahl getroffen, wird das Design als Basis für die Entwicklung genutzt.
Man unterscheidet in der Designphase vor allem zwei Aktivitäten. Zum einen das Top-Level Design, in dem die Architektur entworfen wird und zum anderen das detaillierte Design, bei dem die Komponenten ausreichend für eine Implementierung spezifiziert wurden. Die Prinzipien, nach denen dieser Entwurf geschieht, werden im Software Engineering auch „enabling techniques“ genannt37. Dabei handelt es sich im Wesentlichen um die sechs folgenden Prinzipien:
Abstraktion Informationen werden weggelassen um es zu ermöglichen, Dinge die verschieden sind, so zu behandeln als seien sie das Gleiche.
Kopplung und Kohäsion Definiert und stellt die Stärke der Verbindung zwischen den einzelnen Modulen dar.
Dekomposition und Modularisierung Ermöglicht die Untergliederung der Software in kleinere, teilweise unabhängige Funktionseinheiten.
Kapselung, Information Hiding Verstecken der inneren Strukturen einer Abstraktion. Ziel ist es, den Zugriff auf die Interna der Implementierung durch die Clients zu verhindern, die sichtbare Komplexität zu verringern und Kopplung zu minimieren.
Trennung von Schnittstelle und Implementierung beschäftigt sich damit eine Komponente zu definieren durch Spezifizieren einer öffentlichen Schnittstelle, die den Clients bekannt ist um die Details, wie eine Komponente intern realisiert ist, zu verstecken.
Angemessenheit, Vollständigkeit und Einfachheit Ein Erreichen dieser Ziele bedeutet, dass die Software Komponente abstrakt genug ist und die Schnittstelle alle Anforderungen erfüllt.
Diese Prinzipien sind die Basis zur Lösung der meisten Design Probleme im Software Engineering und haben ihren Nutzen in der Praxis hinlänglich bewiesen.
Die oben genannten Prinzipien benötigen einen Einsatzbereich. Die folgenden Aspekte, die sich nicht primär mit der funktionalen Dekomposition beschäftigen, sondern eher Eigenschaften sind, die die Ef- fizienz und oder die Semantik von Komponenten betreffen, müssen beachtet werden. Dabei handelt es sich vor allem um die Aspekte der Nebenläufigkeit, die Kontrolle und Behandlung von Ereignissen, die Verteilung und Aufteilung der Komponenten, Fehler und Ausnahmebehandlung und Fehlertoleranz, Interaktion und Darstellung und die Datenpersistenz. Die generellen Eigenschaften von Software müssen beim Entwurf berücksichtigt werden38.
Die Idee, Konzepte aus der Architektur auf die Software Entwicklung zu übertragen ist nicht neu39. Buschmann definiert Softwarearchitektur als eine Beschreibung von Subsystemen und Komponenten eines Softwaresystems und die Verbindung zwischen diesen. Architektur versucht die innere Struktur zu definieren. Mitte der 90er Jahre hat sich Softwarearchitektur als eigene Disziplin etabliert. Shaw und Garlan40 identifizieren drei Designebenen für den Entwurf von Software. Die erste Ebene, Ar- chitektur beschäftigt sich mit der generellen Verknüpfung von Systemfunktionen und Komponenten. Die zweite Ebene ist der Code, die Komponenten dieses Levels sind Programmierprimitive, Zeiger, Zahlen, Zeichen oder Felder. Die dritte Ebene ist die Ausführungsebene, die sich mit dem Abbilden auf Speicherstrukturen, Registerzuweisungen, und Datenstrukturen, die in Maschinensprache abgebil- det werden, beschäftigt. Die Architektur beschränkt sich also auf die Ebene der Komponenten- und Ablaufbeschreibung und an der unteren Grenzen mit generellen Konzepten zur Gestaltung von Co- de. Verschiedene Sichten werden zu einem Stil aggregiert, diese sogenannten Architekturstyle, die eine Menge von Bedingungen an eine Architektur darstellen und eine Menge von Architekturen defi- nieren, die diese Bedingungen erfüllen, lassen sich in Makro- und Mikroarchitekturen unterscheiden. Unter den Makroarchitekturen lassen sich Architekturen wie Pipes-and-Filter, Client-Server, Model- View-Controller oder Batch zusammenfassen. Die Mikroarchitekturen werden durch Design Patterns beschrieben, die in der Arbeit in den folgenden Kapiteln zur Prozessunterstützung noch vertieft darge- stellt werden41. Dabei handelt es sich um allgemeine Lösungen für ein Problem in einem bestimmten Zusammenhang42. Hier unterscheidet man Erzeugungs-, Struktur- und Verhaltensmuster.
Um die Qualität des Softwareentwurfs zu sichern wurden verschiedene Techniken entwickelt. Eigenschaften wie Wartbarkeit, Portabilität, Testbarkeit sowie Korrektheit und Robustheit von Software gelten als Qualitätsmaßstäbe, die im Entwurf durch Reviews, statische Analyse oder Simulation und Prototypen überprüft werden können und sollen. Die Messung erfolgt dabei oftmals eher nach subjektiven Kriterien und Erfahrungswerten, da echte Metriken sich noch nicht etabliert haben43.
Viele Notationen und Sprachen haben sich entwickelt, um den Softwareentwurfsprozess zu unterstüt- zen und seine Artefakte adäquat darzustellen. Diese Notationen werden meist im Entwurf der Archi- tektur, aber auch beim detaillierten Design eingesetzt. Dabei werden vor allem zwei Sichten auf die Software durch Notationen unterstützt, zu einem die statische Sicht, die sich mit den Strukturen be- schäftigt und zum anderen die dynamische Sicht, die mehr auf das Verhalten des Systems und seine inneren Abläufe fokussiert44. Folgende Notationen haben sich für die statische Darstellung herausge- bildet:
Architecture Description Languages Die sogenannten ADLs bieten eine textuelle, oft sogar for- male Darstellung der Komponenten und Konnektoren einer Software45
Klassen- und Objektdiagramme werden benutzt um den Zusammenhang zwischen Objekten dar- zustellen, dabei haben sich im Besonderen die Diagramme der UML als Standard etabliert46
Komponentendiagramme werden dazu genutzt, um Komponenten und ihre Schnittstellen und Funktionalitäten darzustellen, ohne jedoch ihre inneren Strukturen zu modellieren (Black-Box- Prinzip).47
Collaboration Responsibility Cards (CRCs) werden dazu genutzt, die Namen von Komponen- ten, deren Verantwortlichkeiten und die mit ihnen kollaborierenden Komponenten zu erfassen Verteilungsdiagramme vor allem in der UML genutzt, dienen dazu, eine Menge von physischen Systemen und die Verteilung von Software auf diesen Systemen sowie Verbindungen zwischen den Systemen darzustellen48
ER-Diagramme werden vor allem zur Darstellung der konzeptuellen Struktur der zu speichernden persistenten Daten genutzt49
Interface Description Languages definieren Schnittstellen für Softwarekomponenten, d.h. Na- men und Typisierung von Methoden50
Neben diesen strukturorientierten Diagrammen haben sich vor allem folgende dynamische Beschreibungen etabliert51:
Aktivitätsdiagramme stellen den Kontrollfluss von Aktivität zu Aktivität dar.
Kollaborationsdiagramme zeigen die Aktivitäten in einer Gruppe von Objekten oder Komponen- ten, wobei der Fokus auf den Objekten, ihren Verbindungen und denen über diese Verbindungen ausgetauschten Nachrichten liegt.
Datenflussdiagramme zeigen den Fluss von Daten in einem Prozess auf.
Entscheidungstabellen und -diagramme bieten die Möglichkeit, komplexe Entscheidungsal- ternativen und ihre Folgen zu formalisieren.
Flowcharts und strukturierte Flowcharts werden genutzt, um den Kontrollfluss und damit ver- bundene Aktionen darzustellen.
Sequenzdiagramme werden dazu genutzt, Interaktionen zwischen einer Gruppe von Objekten mit Fokus auf den zeitlichen Ablauf darzustellen.
State-Machines werden dazu genutzt, Zustandsübergänge bei der Modellierung als Automaten zu definieren.
Formale Sprachen wie Z bieten auch die Möglichkeit, das Verhalten, die Schnittstellen und die Logik von Systemen darzustellen, häufig durch Vor- und Nachbedingungen.
Pseudo-Code und Program Design Languages Programmiersprachen-ähnliche Konstrukte er- möglichen es, das Verhalten und den Kontrollfluss von Software darzustellen
Es gibt verschiedene Strategien wie beim Erstellen von Software vorzugehen ist52. Unter den allge- meinen Strategien finden sich Divide-and-Conquer, Top-Down , Bottom-Up, Pattern-Nutzung oder Information Hiding. Daneben gibt es vier spezielle Formen, die oftmals genutzt werden. Das Funktions-orientierte Design versucht, die Hauptfunktionen zu identifizieren und per Top-Down Entwurf umzusetzen. Dabei werden Datenfluss- und Prozessbeschreibungen genutzt. Das heutzutage weit verbreitete Objekt-orientierte Design identifiziert Objekte und stellt diese als Klassen ins Zentrum des Codes für den Entwurf. Methoden der Objekte stellen die Funktionen zur Verfügung. Vererbung und Polymorphismus spielen eine wichtige Rolle. Das Data-Centered Design beginnt beim Entwurf mit den Datenstrukturen, die das Programm bearbeitet, die Funktionen stehen erst einmal im Hinter- grund. Auf Basis der Datenstrukturen werden die Kontrollstrukturen entwickelt. Als letzte und neueste Methode gilt das Komponenten-basierte Design. Softwarekomponenten werden dabei ausgewählt und zu einem Gesamtsystem zusammengefügt. Dabei steht die Integration, Verteilung und Wiederverwen- dung der Komponenten im Vordergrund.
Die Erstellung von Software, oft auch Konstruktion oder Programmierung genannt, ist zwischen dem Entwurf und dem Testen von Software angesiedelt. Es ist am besten definiert als die detaillierte Erzeugung von Software durch die Kombination von Programmierung, Verifikation, Unit Tests, Integrationstests und Debugging53.
Die Programmierung selbst lässt sich schwerlich klar von Entwurf und vom Testen unterscheiden oder trennen, weswegen hier neben dem Design und Testen auch die Konstruktion kurz angerissen wird.
Während der Programmierungsphase fallen die meisten Artefakte der Softwareentwicklung (Quell- code, Testfälle, Dokumentation etc.) an. Dabei ist das wichtigste Artefakt natürlich der Quellcode. Zur Erstellung dieser Artefakte werden meist Tools eingesetzt. Die Konstruktionsphase verfolgt vor allem die Ziele, den Entwurf umzusetzen und dabei einige Rahmenbedingungen zu beachten. Die Komple- xität des Entwurfes ist angemessen in einer Programmiersprache umzusetzen. Während der Entwurf lediglich die Architektur definierte, kommen in der Programmierung zu diesem Entwurf programmier- spezifische Elemente und Probleme hinzu. Dabei liegt jedoch auch ein Augenmerk auf der Komplexität des Systems. Je einfacher der Code des Programmes, desto besser ist er les- und wartbar. Diese mini- male Komplexität wird durch Standards in der Programmierung und durch Qualitätssicherung erfüllt. Diese Standards können Normen wie die ISO 900154 oder Programmierrichtlinien zur Codeerstellung sein, die sich mit Dokumentation, Kontrollstrukturen, Codeverbesserungen etc, befassen.
Eine weitere Rahmenbedingung ist das Vorausahnen von Veränderungen der Umgebung des Sys- tems. Hier sollte auf Schnittstellen und Erweiterbarkeit geachtet werden. Von der Software wird oft durch externe Ansprüche immer wieder neue Funktionalität und Kompatibilität abverlangt. Fehler soll- ten schon während des Entwurfes durch die Programmierer gefunden und fertige Teilfunktionalitäten durch Unit Tests, Pair Programming oder Code Reviews gefunden werden55. Die Qualität wird durch Einhalten von Standards, seien es interne oder auch externe (UML, CORBA, Web Services) verbessert und gesichert.
Die Einführung dieser Arbeit hat bereits gezeigt, dass Fehler in Software heutzutage mit steigender Komplexität der Software zunehmen. Tests, die diese Fehler finden und die Qualität der programmier- ten Software damit verbessern, sind daher von einer hohen Bedeutung im Software Engineering56. Nicht nur deshalb haben sich bereits verschiedene Standards etabliert, vor allem in Großbritannien, die eine Zertifizierung eines Testers ermöglichen57. Verschiedene Phasen und Techniken des Testens haben sich dabei etabliert und werden im Folgenden beschrieben. Doch zunächst soll eine Definition für das Software Testen erarbeitet werden, die Basis des Begriffs Testen in dieser Arbeit sein wird. Der Informatik-Duden58 definiert Testen als Überprüfung des Ein-/Ausgabeverhaltens eines Programmes anhand einer Spezifikation. Diese Definition ist ein wenig knapp, weswegen weitere betrachtet werden sollen. Die IEEE59 definiert Testen wie folgt:
Testing is the process of analyzing a software item to detect the differences between exis- ting and required conditions (that is, bugs) and to evaluate the features of the software items.
Diese Definition ist richtig, vernachlässigt jedoch einige wichtige Aspekte des Testens. Die Definition vernachlässigt die Aspekte, wie, womit und wie lange getestet wird. Eine Definition des Testens, die diese Eigenschaften berücksichtigt, ist im Ironman-Release des SWEBOK zu finden60. Hier wird das Testen von Software wie folgt definiert:
Testing is an activity performed for evaluating product quality and for improving it by identifying defects and problems. Software testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain against the expected behavior.
Diese Definition geht auf verschiedene spezifische Aspekte des Testens ein.
Dynamisch ist der Test in dem Sinne, dass das Testen immer mit Eingabedaten erfolgt, die zur Lauf- zeit genutzt werden.
Endlich ist die Anzahl der Testfälle, theoretisch könnten beliebig viele Testfälle ausgewählt werden.
Ausgewählt heißt im Fall des Testens, dass bestimmte Techniken von den Testern je nach Art der zu testenden Einheit ausgewählt werden müssen, um die Effektivität sicherzustellen.
Erwartetes Verhalten ist durch die Tester zu definieren, ob ein Test bestanden ist oder nicht, muss durch Kriterien festgelegt werden.
Diese Definition macht verschiedene potenzielle Probleme des Testens sichtbar. Die IEEE unter- scheidet die Begriffe Fehler (fault) und Versagen (failure). Der Begriff Versagen bezeichnet ein nicht
erwartetes Verhalten des Systems auf einen Test, der Begriff Fehler bezeichnet die Ursache für dieses nicht erwartete Verhalten. Wann getestet werden muss, wird jedoch noch nicht ausgesagt. Testen beginnt mittlerweile nicht mehr nach Beendigung der Programmierphase, sondern bereits beim Überprüfen der Anforderungen der Kunden (vgl. S. 14). Testen begleitet den gesamten Entwicklungsprozess und es wird auch bei der Wartung und Aufrechterhaltung der Software noch getestet. Fertige Produkte enthalten auch im Betrieb in der Regel immer noch jede Menge Fehler, teils sogar schwerwiegende, die gefunden und beseitigt werden müssen.
Das Testen beschäftigt sich mit 7 Hauptsachverhalten, die sich jeder Tester immer vor Augen führen muss, wenn er einen Test durchführt61.
Testauswahlkriterien Damit ist gemeint, dass jeder Tester sich immer im klaren sein muss, welche Menge von Tests er durchführen wird. Ein Kriterium, ob ein Test gewählt wird oder nicht kann beispielsweise das Wissen sein, ob der Test terminieren wird oder nicht.
Testeffektivität Testen kann und wird mit verschiedenen Zielsetzungen durchgeführt. Ein beispiel- hafter Durchlauf des Programmes wird beobachtet. Die Wahl des Testes sollte dem Ziel und dem betrachteten Programm angemessen getroffen werden, im Hauptblickpunkt steht dabei meist die Effektivität und Effizienz des Tests.
Testen um Defekte zu finden Ein erfolgreicher Test um einen Fehler zu finden bringt das System zum Versagen. Solch ein Test ist anders als ein Test, der zeigt, dass ein System diese oder jene Spezifikation erfüllt.
Das Orakel-Problem Ein Orakel im dem Sinne dieses Aspektes ist ein Vertreter, sei es Mensch oder Maschine, der entscheidet, ob ein Programm richtig oder falsch auf eine Test reagiert hat. Die Entscheidung, ob ein Test bestanden oder nicht bestanden wurde ist nicht immer leicht zu treffen- schon gar nicht automatisiert.
Theoretische und praktische Grenzen des Testens Egal wie viele Tests ein Programm be- steht, diese Anzahl sollte nie überbewertet werden. Das Halteproblem beispielsweise lässt er- kennen, das Tests nie die vollständige Abwesenheit von Fehlern zeigen können, sondern immer nur deren Anwesenheit. Ein vollständiges Testen oder auch Validieren eines allgemeinen Pro- grammes ist nicht möglich.
Problem der nicht durchführbaren Pfade Beim Pfadorientierten Testen gibt es immer Pfade im Kontrollfluss, die durch die Eingabedaten nicht erreicht werden können, der Kontrollfluss ist im Besonderen bei verschachtelten if-Bedingungen zu überprüfen.
Testbarkeit Dieser Begriff hat zwei Bedeutungen. Zum einen geht es um den Grad, wie einfach ein Programm ein Testabdeckungskriterium erfüllen kann, zum anderen, ob eine Software im speziellen Test einen Fehler zeigt62.
Diese Aspekte werden im Folgenden teilweise wieder aufgegriffen und sollten Testern immer wieder bewusst gemacht werden. Das Testen hat eine starke Beziehung zum Qualitätsmanagement, zur formalen Verifikation, zum Fehlerbeseitigen und zur Programmierung. Aspekte dieser Gebiete können dazu dienen, das Testen besser zu verstehen und einordnen zu können.
Es können drei verschiedene Ebenen des Testens unterschieden werden. Zum ersten der sogenannte Unit Test, bei dem isolierte Codefragmente getestet werden. Hierfür werden spezielle Testmethoden der einzelnen Funktionen erstellt. Die zweite Testebene ist der Integrationstest63. Dabei werden ver- schiedenste Ansätze, Big-Bang, Top-Down oder Bottom-Up genutzt, um das System zusammenzuset- zen und die Zusammenarbeit der Komponenten als ganzes System zu testen. Als letzte Ebene kommt es dann zum Systemtest, bei dem das gesamte System getestet wird. In dieser Phase sollten bereits durch die vorherigen Ebenen die meisten Fehler gefunden sein, so dass hier vor allem nicht-funktionale An- forderungen getestet werden sollten.
Es gibt mehr als ein dutzend verschiedener Testmöglichkeiten. Im Folgenden soll ein kurzer Überblick zu jeder Testart gegeben werden, für weitere Informationen sei der Verweis auf Thaller (im Folgenden Th+Seitenzahl als Quelle genannt)64 als ausführliche Quelle gegeben.
Fagan Inspections Dieses statische Verfahren basiert auf einer Inspektion des Quellcodes durch Kollegen des Entwicklers, die jeweils einzeln das Produkt überprüfen (Th40).
Walkthrough In diesen statischen Verfahren werden in einem Prozess, an dem Autor, Tester, Schrei- ber und Moderator beteiligt sind, Quellcodeteile besprochen, Verbesserungen vorgeschlagen, vereinbart und letztlich implementiert (Th47f).
Akzeptanztests überprüfen das Verhalten des Systems gegenüber den vom Kunden formulierten Anforderungen.
Installationstests werden in der Einsatzumgebung mit der geplanten Hardware und Orgaware durch- geführt.
Alpha und Beta Tests werden vor Veröffentlichung kommerzieller Software durch repräsentative potenzielle Nutzergruppen durchgeführt, deren Eindrücke und Anregungen noch in das entgülti- ge System eingehen können.
Funktionstest überprüft, ob das Verhalten des Systems die Spezifikation erfüllt (Th121).
Zuverlässigkeitstest Durch zufällige Tests gemäß dem Einsatzprofil sollen Statistiken entwickelt werden, die Aussagen über die Zuverlässigkeit des Systems ermöglichen sollen.
Regressionstest überprüfen, ob durch Erweiterungen und neuen Code das System immer noch so zuverlässig ist wie vor der Erweiterung (Th278).
Volume-Test Diese Art des Tests überprüft, ob das System die geplante Workload erfüllen kann (Th124).
Performanztests überprüfen vor allem, ob das System die nicht-funktionalen Anforderungen wie Antwortzeiten oder Kapazität erfüllen (Th131).
Überlastungstest Ähnlich wie beim Volume Test wird hier die Workload des Systems getestet mit dem Unterschied, dass diese Load sehr schnell erreicht wird, also unter Stress (Th128).
Recovery-Test überprüfen das Verhalten des Systems nach einem Absturz beim erneuten Hochfah- ren (Th129).
Konfigurationstests werden auf verschiedenen Plattformen mit verschiedener Hardware durchge- führt, um die Anforderungen des Systems objektiv zu ermitteln (Th135).
Bedienbarkeitstest werden durch die Endnutzer durchgeführt, die anhand des Systems und seiner Dokumentation ermitteln, ob das alle Funktionen des täglichen Bedarfs erfüllt.
Neben den bekannten Arten des Testens wie Black-Box Test, bei dem die inneren Strukturen eines Moduls unbekannt sind und dem White-Box Testen, bei dem Informationen über das Design des Moduls bekannt sind und für den Test auch ausgenutzt werden, gibt es folgende Techniken:
Äquivalenzklassentests Das Anwendungsgebiet wird in Untermengen aufgeteilt, Klassen gebil- det und auf ausgewählten Elemente Tests durchgeführt, deren Ergebnisse auf die äquivalenten Probleme übertragen werden (Th87).
Grenzwerttests Grenzen der Eingabewerte werden ermittelt und gezielt eingegeben, um die klassi- schen ±1-Fehler zu finden und Grenzen von Variablentypen mit Überläufen zu ermitteln (Th90).
Entscheidungstabellen In einer Matrix werden Kombinationen von Aktion und Bedingung syste- matisch abgeprüft.
Endliche Automaten werden zur Darstellung genutzt, dann kann das System anhand von Zustän- den und Übergängen überprüft werden.
Formale Spezifikation wird als Testmethode genutzt, häufig in der Form von algebraischen Spezi- fikationen.
Zufallstests werden einfach zufällig generiert und durchgeführt, um eine gewissen Abdeckung zu erreichen.
Kontrollflussbasierte Kriterien werden eingesetzt, um zu versuchen, alle Befehle eine Program- mes möglichst gut zu überdecken.
Datenflussbasierte Kriterien Die Belegung, Freigabe und Benutzung der Variablen und der Da- tenfluss wird getestet.
Fehlerbasierte Techniken Vordefinierte typische Fehler sollen abgeprüft werden, die plausibelsten Fehler sollen im Vornherein erraten werden (Th93).
Mutationstests versuchen durch Veränderung des Programmes auf syntaktischer Ebene und Ermitt- lung dieser Veränderung gleichzeitig komplexere Fehler zu finden (Th130).
Einsatzprofil die zukünftige Zuverlässigkeit kann durch Reproduktion des Einsatzumgebung und Installation des Systems den eigentlichen Einsatz simulieren.
Techniken basierend auf der Natur der Anwendung sind etwa objekt-orientierte Tests, Kom- ponententests, Oberflächentests oder Nebenläufigkeitstests.
Häufig kann nicht genau das wie und was einer Testtechnik getrennt werden. In diesen Abschnitt sind Einsatzprofil, Konfigurationstests und Zuverlässigkeitstest sehr ähnlich.
Wenn DeMarco schreibt65, dass man nicht managen kann, was nicht gemessen werden kann, hat er damit teilweise recht. Es haben sich Testmetriken etabliert, die nicht nur aussagen, wie erfolgreich ein Test ist bzw. war, sondern auch Metriken, die Aussagen über die Qualität eines zu testenden Pro- grammes machen. Es gibt Metriken, die auf Grund der Programmgröße Aussagen treffen, Metriken, die Fehler typisieren, klassifizieren und Statistiken über ihr Auftreten bieten. Bestimmte Tests können dann ausgewählt werden, weil sie einige Fehlerklassen besser finden. Weiterhin werden Metriken ge- nutzt, um die Fehlerdichte im Programm zu ermitteln. Weitere Statistiken liefern Aussagen über die Zuverlässigkeit der Software, den Zuwachs an Zuverlässigkeit im Prozess und die Abnahme von Feh- lern oder prozentuale Überdeckung des Programmes durch Tests. Durch Einstreuen von künstlichen Fehler und Messen der Aufdeckung dieser Fehler durch Tests kann überschlagsweise ermittelt werden, wieviele reale Fehler in Relation zu den gefundenen noch im Programm vorhanden sein müßten66.
Der Testprozess benötigt verschiedenste Dinge. Über den egolosen Programmierer, Testhandbücher, Prozessmanagement, Dokumentationen, unabhängige und interne Tester, Kosten/Nutzen Rechnungen, Wiederbenutzungspläne für Tests bis hin zu Kriterien für den Abschluss des Testens müssen Dinge durch die Organisation geregelt werden. Diese verschiedenen Faktoren spielen in den Aktivitäten eine Rolle. Als primäre Aktivitäten identifiziert der SWEBOK die Planung, die Erzeugung von Testfällen, das Einrichten der Testumgebung, die Ausführung des Tests, die Überprüfung der Testergebnisse, das Melden und Verzeichnen eines Fehlers und letztendlich die Fehlersuche und -beseitigung. Eine vertiefende Darstellung des Prozesses wird in Kapitel 4 gegeben.
Ein System kann als eine Sammlung von Komponenten aufgefasst werden, die organisiert sind, um eine spezifische Menge von Funktionen bereitzustellen. Die Konfiguration eines Systems ist die funktionelle und/oder physische Charakteristik von Hardware, Firmware, Software oder einer Kombination aus diesen Gebieten67. Das Konfigurationsmanagement wird durch die IEEE definiert als68:
Configuration management is a discipline applying technical and administrative direction and surveillance to: identify and document to physical and functional characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with the specified require- ments.
Das Konfigurationsmanagement unterstützt den gesamten Softwarelebenszyklus. Eine enge Beziehung besteht zur Qualitätssicherung. Sich weiterentwickelnde Systeme müssen verwaltet werden, da sich im Zuge der Evolution viele verschiedene Versionen entwickeln. In diese Versionen werden Änderungen, Fehlerkorrekturen und Anpassung an konkrete Plattformen integriert69. Dabei sind unter Umständen mehrere Versionen gleichzeitig in der Entwicklung und Praxis im Einsatz. Es muss möglich sein, fest- zustellen, welche Änderungen wann erfolgten und wie sie in die Software eingepflegt wurden. Das Verfahren des Konfigurationsmanagement legt fest, wie Änderungen festgehalten und eingearbeitet werden, welche Beziehung sie zu den einzelnen Komponenten haben. CASE-Werkzeuge werden dazu benutzt, sie speichern beispielsweise in CVS Systemen Versionen des Quellcodes, bieten die Mög- lichkeit, das System auch zu erstellen und zu erfassen, welche der erstellten Releases an die Kunden ausgeliefert wurden.
Das Konfigurationsmanagement beschäftigt sich vor allem mit fünf Aktivitäten, der Planung des Kon- figurationsmanagements, dem Änderungsmanagement, dem Versionsmanagement, dem Releasemana- gement und der Systemzusammenstellung. Diese Tätigkeiten werden in den folgenden Unterabschnit- ten angerissen. Eine vertiefende Darstellung des Prozesse findet sich im SWEBOK70 und in Kapitel 4 dieser Arbeit.
Für einen geregelten Ablauf der Konfigurationsmanagementprozesses hat sich das Aufstellen und Be- folgen eines Konfigurationsplans in der Praxis als sinnvoll erwiesen. Der Plan wird auf Basis von allgemeinen firmenweiten Standards für das Konfigurationsmanagement erstellt und auf das jewei- lige Projekt angepasst. Um den Plan aufstellen zu können, muss identifiziert werden, welche Soft- waregegenstände kontrolliert werden müssen. Dies erfordert, die Softwarekonfiguration im Rahmen der Systemkonfiguration zu verstehen und nach bestimmten Kriterien die Softwarekonfigurationsitems auszuwählen.
Unter einer Softwarekonfiguration wird in diesem Kontext eine Menge von funktionellen und physi- kalischen Charakteristiken der Software verstanden, wie sie in der technischen Dokumentation oder im
Produkt dargelegt wurde. Ein Softwarekonfigurationsitem ist eine Ansammlung von Software, die für das Konfigurationsmanagement vorgesehen wurde. Neben dem Code selber sind dies typischerweise Pläne, Spezifikationen, Testmaterialien, Datenbankschemata und Installations-, Wartungs-, Betriebsund Softwaredokumentation71.
Der Konfigurationsplan enthält eine Definition der zu verwaltenden Objekte und ein formales Schema zur Bezeichnung der Objekte. Im Plan wird auch festgelegt, wie die Abläufe des Konfigurationsmanagement sind und wer für die jeweiligen Objekte zuständig ist. Daneben werden Regeln aufgestellt, die festlegen, wie die Änderungskontrolle oder das Versionsmanagement ablaufen müssen. Ferner wird eine Beschreibung der Aufzeichnungen, die zum Konfigurationsmanagement aufbewahrt werden müssen, sei es bei späterer Nutzung von früheren Releases oder zur Nachvollziehbarkeit aktueller Releases, abgespeichert. Diese ganzen Informationen werden in der sogenannten Konfigurationsdatenbank, die zum Protokollieren dieser Informationen genutzt wird, abgelegt72.
Nachdem die Software von der Entwicklung in den Live-Betrieb geht, werden durch die Anwender Fehler entdeckt und Verbesserungsvorschläge gemacht. Diese Änderungen sollen, gerade in großen verbreiteten Softwaresystemen, so schnell wie möglich aufgenommen werden. Ein Änderungspro- zessmanagement dient dazu, diese Änderungen sinnvoll zu koordinieren, in einem Workflow über die Aufnahme von Änderungen zu entscheiden und Prioritäten zu setzen. Einen Prozess für das Än- derungsmanagement zu etablieren macht insbesonders dann Sinn, wenn die Software der Kontrolle durch ein Konfigurationsmanagementteam unterstellt wird. Der Prozess sollte nach dem Systemtest und der Auslieferung an den Kunden etabliert werden. Der Prozess sollte so entworfen sein, dass auch Kosten/Nutzen-Aspekte von vorgeschlagene Änderungen analysiert werden können.
Der Prozess wird meist IT-gestützt durchgeführt73. Ein typisches System zur Unterstützung des Änderungsmanagements bietet einen Formulareditor, der die Formulare zur Eingabe der Änderun- gen bereitstellt und in den Workflow der Genehmigung übergibt. Das Formular enthält typischerweise Daten zum Projekt, Antragsteller, Beschreibung der Änderung, Datum, betroffene Komponenten, Kos- tenschätzung der Änderung und Priorität. Das Workflowsystem ermöglicht es, das Formular nun an verschiedene zuständige Mitarbeiter weiterzuleiten. Die Mitarbeiter legen die Reihenfolge der Bear- beitung fest und überprüfen, ob nicht doch eine Falschmeldung eines eventuellen Fehlers vorliegt. Hier erfolgt nun eine detaillierte Analyse, welche Module die Änderung betrifft, was für Wechselwirkun- gen die Änderung hervorrufen könnte und welche Kosten diese Änderung verursachen könnte. Diese Beurteilungen werden typischerweise in der bereits vorgestellten Konfigurationsdatenbank dokumen- tiert. Danach geht der Workflow weiter an das Konfigurationsmanagementboard, welches auf Basis der vorliegenden Daten entscheidet, ob die Änderungen genehmigt werden oder nicht. Wird die Änderung genehmigt, werden sie an das Implementierungsteam übergeben, die die Änderung implementieren. Nach den Änderungen wird die Software erneut validiert und eine neue Version der Software durch das Konfigurationsmanagementteam erstellt. Dieses Team veranlasst auch die Dokumentation mit Hil- fe einer Versionshistorie für die Änderungen am Code. Diese Historie wird typischerweise in einer Änderungsdatenbank abgelegt, die mit einem CVS verknüpft wird und dessen Daten übernimmt.
Das Versionsmanagement beschäftigt sich mit dem Prozess der Bezeichnung und Verfolgung verschiedener Softwareversionen. Es werden meist computergestützt Verfahren etabliert, die sicherstellen, dass es möglich ist, verschiedene, meist ältere Versionen einer Software wieder herstellen zu können und zum Release zu bringen. Neue Systemversionen werden dabei primär durch das Konfigurationsmanagementteam erstellt und weniger durch die Entwickler selbst, dies erleichtert die Konsistenzhaltung in der Konfigurationsdatenbank74.
Sommerville versteht unter einer Systemversion eine Ausprägung eines Systems, die in irgendeiner Weise von anderen Ausprägungen abweicht. Neue Versionen enthalten oftmals andere Funktionalitäten als alte, haben weniger Fehler oder sind lediglich auf andere Systemplattformen angepasst. Bestehen nur kleine Unterschiede zwischen Versionen wird oftmals lediglich von einer Variante gesprochen.
Zentraler Aspekt der Versionsverwaltung ist die Unterstützung durch Versionierungssysteme. Die Systeme beschäftigen sich mit einem zentralen Zweck des Versionsmanagements, der Versionsbe- zeichnung, die im Folgenden noch vertieft dargestellt wird. Neben der Möglichkeit, Bezeichnungen zur Unterscheidung zu vergeben bieten die Systeme auch ein Speichermanagement, es hat sich heraus- gestellt, das sich bei Quellcode Dateien zwischen Versionen oft nur Änderungen im Umfang von etwa 2 Prozent vorgenommen werden, um Platz zu sparen wird daher nur das Delta gespeichert und diese Information mit der Quellcodedatei verknüpft75. Ebenfalls ist die Erfassung der Änderungsgeschichte, sprich die Versionierung samt Angaben zu den Änderungen, Zeitpunkten und Autoren in die Systeme integriert. Die Systeme ermöglichen es durch das Konzept der Repositories und Modules, verschiedene Codelines gleichzeitig in einem System vorzuhalten, es kann an Release 3 schon gearbeitet werden, während 2 noch in der Entwicklung ist und 1 gepatcht wird76.
Das grundlegende Konzept des Versionsmanagement ist die Versionsbezeichnung. Dabei haben sich drei Konzepte durchgesetzt. Zum einen gibt es die Versionsnumerierung, bei der Versionen einfach durchnumeriert werden77. Dieses Verfahren ist das Gebräuchlichste. Weiterhin existieren die attributs- basierte Bezeichnung, bei der jede Komponente einen Namen (der ja nicht eindeutig sein muss) und eine Menge von Attributen zugeteilt bekommt78. Als letztes gibt es die änderungsorientierte Bezeich- nung. Diese basiert auf der attributbasierten Bezeichnung, zusätzlich werden jedoch ein oder zwei Änderungsanträge mit dem Namen verknüpft. Diese Änderungen können auf eine stabile Version über Änderungssätze nacheinander angewendet werden um das gewünschte System zu erhalten79.
Das Releasemanagement ist eng mit dem Versionsmanagement verbunden. Bei einem Systemrelease handelt es sich um eine an den Kunden ausgelieferte Version eines Systems oder einer Software. Jedes neue Release enthält dabei typischerweise neue Funktionen oder unterstützt neue Plattformen. Ein Re- leasemanager entscheidet, wann eine neue Version für den Release an den Kunden freigegeben wird.
Er überwacht die Erstellung dieses Release, die Dokumentation und die Vertriebsdaten der Kunden.
Ein Release ist mehr als nur ausführbarer Code. Zusätzlich gehören zum Release typischerweise Konfigurationsdateien, Datenfiles, Installationsprogramm, elektronische und gedruckte Dokumentation sowie Verpackung und Werbung. Diese zusätzlichen Artefakte lassen schon vermuten, dass die Erstellung eines Releases mit einiger zusätzlicher Arbeit verbunden ist und daher sinnvoll geplant werden muss. In der Releasepolitik ist es von Bedeutung, wie oft ein Wechsel erfolgt. Wechseln die Releases zu oft, dann wird der Kunde nicht jeden Wechsel mit machen und man muss weiterhin Support und Daten für die alten Releases vorhalten und bieten, wechselt man selten, werden sich die Kunden Mitbewerber suchen, die ihre Änderungs- und Erweiterungswünsche schneller umsetzen.
Sommerville80 definiert die Systemerstellung als Prozess des Kompilierens und Bindens von Softwa- rekomponenten zu einem Programm, das auf einer bestimmten Zielkonfiguration ausgeführt wird. Bei der Erstellung muss auf korrekte Erstellanweisungen, Wahl der richtigen Versionen einzelner Kompo- nenten, Verfügbarkeit aller Datenfiles und die Verwendung der korrekten Versionen von Bibliotheken und Compilern geachtet werden. Durch Make- oder Ant-Skripte werden heutzutage große Systeme meist durch Werkzeuge automatisiert erstellt. Der Releasemanager muss nur noch darauf achten, dass das Erstellungsskript korrekt erzeugt wurde und alle benötigten Dateien zur Verfügung stehen.
[...]
1 kompletter Absturzbericht der ESA [Lio96]
2 eine genauere Darstellung der Fehler findet sich in [Lev95]
3 siehe auch Brooks in [Bro87]
4 siehe [NR68]
5 siehe auch [Som01], S. 22
6 Institute of Electrical and Electronics Engineers, http://www.ieee.org
7 IEEE Standard 610.12
8 Unified Modelling Language, http://www.omg.org
9 neben Arbeit, Boden und Kapital; siehe [HMP01], S. 206ff oder [Dru94]
10 siehe auch [Coc01], S. 6
11 Quelle: [GFF00]
12 siehe auch [Gro03]
13 siehe [Hei02], S. 56
14 [Rem02b], S. 92
15 [DP98]
16 [Gro03], S. 5
17 Knowledge Modelling Description Language
18 Knowledge Modelling Description Language for Software Engineering
19 siehe [Swe01]
20 Sommerville gliederte sein Standardwerk [Som01] ebenfalls nach diesem Report
21 Spezifikation gemäß [JRH+03], da noch nicht verabschiedet zum Zeitpunkt der Erarbeitung
1 siehe auch S. 2 der Arbeit
2 vgl. [GFF00]
3 siehe [Sne00]
4 siehe auch [Sne00]
5 siehe [SG96], S. 6
6 Vertiefung in [SG96]
7 in Anlehnung an [SG96]
8 vgl. [Sne00]
9 Association for Computing Machinery, siehe auch http://www.acm.org
10 siehe [Swe01]
11 Vertiefende Informationen finden sich in [BDA+99]
12 unter 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
13 einen Studienplan eines Software-Ingenieurs findet man exemplarisch beim Hasso-Plattner Institut für Software Systemtechnik unter http://www.hpi.uni-potsdam.de/deu/studium/studord.de.html, einen Entwurf für Wirtschaftsinformatiker in [LS04]
14 Anmerkung: 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] unter http://www.swebok.org
15 siehe auch Spillner in [SWW03], S.22ff
16 siehe die Gesamtstudie unter [Let99] oder http://www.site.uottawa.ca/~tcl/edrel/
17 eine Gesamtaufsteleung der Themen ist unter [Let99], S.6 oder im Anhang dieser Arbeit zu finden
18 siehe [Let00]
19 zum Beispiel auf Grund von Schadensersatzforderungen oder wegen notwendiger Rückrufaktionen
20 [Pro01]
21 Im Gegensatz zum Strawman-Release bietet der Ironman-Release eine einheitliche Gliederung der Wissensgebiete
22 Im Folgenden wird das deutscheWort Anforderung statt Requirement genutzt, da es in der deutschen Software Engineering Gemeinschaft weiter verbreitet ist
23 vgl. [KS98], S.6
24 siehe [BMMM98], S. 77
25 hier: [KS98], [Swe04], [Som01]
26 siehe [Som01], S. 109, 116, 119
27 eine Übersicht bietet [Som01], S. 111
28 der SWEBOK definiert die Benutzeranforderungen anders als Sommerville, im Folgenden wird dessen Definition genutzt
29 [KFG02], S.77
30 [RJB98], S.66 und [Coc00], S. 26
31 vgl. auch [HHP03], S.33ff
32 vgl. auch [KFG02], S. 55
33 siehe S.14
34 vgl. [Som01], S. 215 und [SG96]
35 siehe auch http://www.hpl.hp.com/techreports/98/HPL-98-10.html
36 vgl. IEEE Standard 610.12-1990, [IEE90]
37 siehe [BMR+96], S. 397ff bzw. [Bus98], S. 392ff
38 vgl. [BMR+96] und [BCK03]
39 [Ale79]
40 siehe [SG96], S. 4
41 siehe [GHJV95]
42 Definition nach [RJB98]
43 vgl. [Let00]
44 siehe [JRH+03]
45 vgl. [SG96], S.147ff oder [Szy02]
46 vgl. [BRJ98] und [JRH+03]
47 Neu in UML 2.0, siehe [JRH+03], S. 140ff
48 siehe [JRH+03], S. 151ff
49 [ACPT99]
50 [Szy02], S. 208f
51 vornehmlich nach [JRH+03], [Bal01], [BRJ98] und[MM88]
52 vgl. hierzu auch [Bus98], S. 397
53 vgl. [Swe01], 4-1
54 vgl. [Tha99]
55 vgl. [Bec99]
56 [Tha02]
57 [SWW03], S.24
58 [CSE93], S.720ff
59 [IEE90], S.76
60 [Swe04], 5-1
61 vgl. [Swe04], S. 5-3
62 siehe auch [Som01], S.457
63 vgl. [Som01], S. 459
64 siehe [Tha02]
65 vgl. [Dem86]
66 eine gute Übersicht findet sich in [Tha00], S. 91ff
67 vgl. [IEE90]
68 vgl. [IEE90], S. 20f
69 siehe [Som01], S. 651
70 vgl. [Swe04], S. 7-1ff
71 vgl. [Swe04], S.7-6
72 nach [Som01], S. 653f
73 [Som01], S. 667
74 vgl. [Som01], S. 660
75 vgl. [Est00]
76 einen schönen Überblick über den technischen Prozess des SCM bietet [BA02]
77 bsp.weise also Version 1.3; 2.0 o.ä.
78 bsp.weise Windows 2000 (Sprache=Deutsch, Datum=Januar 2001, Plattform=Intel)
79 siehe [Est00], S. 280
80 vgl. [Som01], S. 665
