Embed Size (px)
Citation preview
Software Engineering
© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.
3 Software Engineering
3.1 Fortschritte in Hard- und Software
3.2 Grundideen des Software Engineerings
3.3 Probleme und Chancen des Software Engineerings
3.1 Fortschritte in Hard- und Software
Moore‘s Law
Schon in den Sechzigerjahren bemerkte George Moore, Chef der Firma Intel, dass sich die Integrationsdichte etwa alle 18 Monate verdoppelt, also exponentiell wächst.
(Die physikalischen Grenzen werden voraussichtlich im zweiten Jahrzehnt des 21. Jahrhunderts erreicht.)
Ähnlich entwickeln sich die Prozessorleistung und die Speicherkapazität pro €.
Damit entstand der Eindruck, dass die Hardware-Entwicklung der Software davonläuft.
3
Hardware vs. Software
In den Fünfzigerjahren war der Computer das schwächste Glied der Kette, und die Leistung der Programmierer wurde eingesetzt, um seine Unzulänglichkeiten zu kompensieren.
Beispiel: Algorithmen, die trotz Hardware-Ausfällen ein korrektes Resultat lieferten.
Bald aber waren diese Probleme überwunden, die Rechner wurden kleiner und billiger, schneller und zuverlässiger.
Die Software wurde in dieser Zeit weder billiger noch zuverlässiger.
● Genauer: Die Kosten einer Zeile Code haben sich in Jahrzehnten kaum verändert. In höheren Sprachen leistet eine Zeile Code aber mehr als in den alten, primitiven Sprachen.
Effekt: Die Software war von nun an der Schwachpunkt des Gesamtsystems.
4
Fortschritte bei Hard- und Software
Entwicklung von 1960 bis 1990
5
Die Ausgaben für Hard- und Software
Wegen der unterschiedlichen Entwicklung in Hard- und Software wurde Ende der Sechzigerjahre vorausgesagt, dass zukünftig das meiste Geld nicht mehr für
Hardware, sondern für Software ausgegeben werde (Boehm, 1973).
6
Diskussion
Diese Vermutung hat sich als falsch erwiesen (Gurbaxani und Mendelson, 1987).
Grund: Wenn eine Ware relativ zu anderen knapp und teuer wird, substituieren die Menschen die teure Ware durch billigere.
● Wir verwenden schlechte Software auf gigantischen Rechnern statt guter, teurer Software auf kleinen, billigen Rechnern.
● Einige wenige Basiskomponenten der Software sind heute über die ganze Welt verbreitet, so dass die Kosten pro Exemplar sehr gering sind.
● Viele wichtige Komponenten sind heute kostenlos verfügbar.
Das Verhältnis zwischen Hardware- und Software-Ausgaben bleibt etwa konstant bei 6:4. Dafür kann es viele Gründe geben. Unterstellt man, dass damit tatsächlich das Optimum des Nutzens erzielt wird, so kann man ein Modell suchen, das den Effekt erklärt.
7
Betrachtung des Gesamtnutzens - 1
Extrem einfaches Modell
● Der Gesamtnutzen N ist das Produkt aus Hardware-Nutzen und Software-Nutzen.
● N = NHW * NSW NHW = kHW * GHW, NSW = kSW * GSW
Steht das Geld G zur Verfügung, so gilt außerdem GHW + GSW = G.
Die Ableitung nach NHW (oder NSW) ergibt:
● N erreicht sein Maximum für
● NHW = NSW = N/2
8
Betrachtung des Gesamtnutzens - 2
Die Abweichung (6:4) kann man wie folgt deuten:
● Manager kaufen lieber Hardware als Software, denn Hardware ist in vieler Hinsicht kaufmännisch einfacher zu handhaben (Bilanzierung, Wartungskosten, Abschreibung).
● Der Nutzen ist nicht linear über dem Aufwand, sondern bei der Hardware progressiv und/oder bei der Software degressiv (mehr Geld bringt nicht mehr Leistung).
Effekt: Das Optimum verschiebt sich in Richtung höherer Ausgabenanteile für die Hardware.
9
Historisches - 1
Phänomen der späten Sechzigerjahre:
● Software-Projekte ließen sich selbst mit gigantischem Aufwand nicht zu einem befriedigenden Ende bringen (oder der Abschluss wurde nur mit schlechten Resultaten, viel zu spät und/ oder mit extremen Kostenüberschreitungen erreicht).
Gleichzeitig nahm die Bedeutung der Rechner laufend zu, so dass der Wunsch nach Methoden und Werkzeugen zur schnellen und billigen Entwicklung fehlerarmer Software immer drängender wurde.
Für diese Probleme kam das Schlagwort „Software Crisis“ auf. Die Software-Krise war Anlass für viele Diskussionen und Tagungen.
10
Historisches - 2
Bei der Vorbereitung der NATO-Konferenz in Garmisch verwandte F.L. Bauer das Wort Software Engineering als Provokation:
The whole trouble comes from the fact that there is so much tinkering with software.
It is not made in a clean fabrication process, which it should be.
What we need is software engineering.F.L. Bauer (1968)
11
Beiträge der Frühzeit
Achtung, die Geschichte des Software Engineerings beginnt nach diesem Ereignis, sie entwickelt in den 70er Jahren Eigendynamik.
Wichtige Beiträge in der Frühzeit des Software Engineerings waren:
● die „Entdeckung“ des Software Life Cycles (Royce, 1970)
● die Überlegungen zur Strukturierung der Programme (Parnas, 1972)
● die Sammlung empirischer Daten (Boehm et al., 1973)besseres Verständnis der Kosten-Ursachen und der Kosten-Verteilung
12
Wichtige Definitionen
13
Software Engineering ist die Entdeckung und Anwendung solider Ingenieur-Prinzipien mit dem Ziel, auf wirtschaftliche Art Software zu bekommen, die zuverlässig ist und auf realen Rechnern läuft.
F.L. Bauer
Software Engineering ist die Herstellung und Anwendung einer Software, wobei mehrere Personen beteiligt sind oder mehrere Versionen entstehen.
D.L. Parnas
Software Engineering(1)The application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the application of engineering to software.
2) The study of approaches as in (1).IEEE Std. 610.12 (1990)
IEEE-Definition auf Deutsch
Schwächen dieser Definition:
● An das Software Engineering werden Erwartungen geknüpft, die unrealistisch sind und in der Praxis kaum erfüllt werden.Eine Definition sollte nicht werten!
● Das Ingenieurwesen wird als Fundament verwendet, das leider selbst nicht (besser) definiert ist:
The application of a systematic, disciplined, quantifiable approach to structures, machines, products, systems, or processes.
Hier wird das Bild des edlen Ingenieurs verwendet!
Software Engineering ist das systematische, disziplinierte und quantifizier-bare Vorgehen zur Entwicklung, zum Betrieb und zur Wartung von Software, kurz: die Arbeit an Software nach Ingenieurprinzipien.
14
Eigene Definition
Das heißt:
● Überall, wo Software entwickelt oder bearbeitet wird, um ihre Funktionalität nutzbar zu machen, sehen wir Software Engineering.
● Ausgenommen sind damit vor allem Programme, die nur zum Spaß oder zur Übung (in der Ausbildung) geschrieben werden.
● Softwaretechnik ist die (unbefriedigende) Halbübersetzung von Software Engineering.
Software Engineering ist jede Aktivität, bei der es um die Erstellung oder Veränderung von Software geht, soweit mit der Software Ziele verfolgt werden, die über die Software selbst hinausgehen.
Ludewig (2001)
15
3.2 Grundideen des Software Engineerings
Werstatt versus Atelier
17
Werkstatt (technisches Produkt) Atelier (Kunstwerk)
Die geistige Voraussetzung
ist das vorhandene und verfügbare technische Know-how
ist u. a. die Inspiration des Künst-lers
Die Termine sind in der Regel mit genügender Genauigkeit planbar
sind wegen der Abhängigkeit von der Inspiration nicht planbar
Der Preis ist an den Kosten orientiert und darum kalkulierbar
ist nur durch den Marktwert, nicht durch die Kosten bestimmt
Normen und Standards
existieren, sind bekannt und werden in aller Regel respektiert
sind rar und werden, wenn sie bekannt sind, nicht respektiert
Eine Bewertung, ein Vergleich
kann nach objektiven, quantifizier-ten Kriterien durchgeführt werden
ist nur subjektiv möglich, das Ergebnis ist umstritten
Der Urheber bleibt meist anonym, hat keine emotionale Bindung zum Produkt
betrachtet das Kunst-werk als Teil seiner selbst
Gewährleistung und Haftung
sind klar geregelt, können nicht ausgeschlossen werden
sind undefiniert und praktisch kaum durchsetzbar
Ein Blick in die Software-Steinzeit
● Termine und Kosten werden ohne rationale Grundlage geschätzt und im Verlauf des Projekts vielfach weit überschritten.
● Regeln sind nicht existent oder nicht bekannt oder werden ignoriert, das Gleiche gilt verstärkt für Normen.
● Programmtests liefern nur eine sehr schwache Aussage über die Funktionalität der Programme, andere Eigenschaften (z.B. die Portabilität oder die Robustheit) können nur subjektiv bewertet werden. Für den Vergleich von Software-Produkten fehlen anerkannte Kriterien.
● Der Programmierer baut seine Persönlichkeit in die Software ein, sodass sie für andere Menschen unverständlich ist. Kritik an seinem Werk kann er kaum ertragen.
● Trotzdem übernehmen weder die Entwickler noch ihre Firma die Verantwortung für die Qualität des Produkts.
18
Quantität als Qualität
Software Engineering ist nicht zu verstehen, wenn man sich auf kleine Einheiten konzentriert, z.B. auf einzelne Algorithmen.
Beispiel:
● Ein Rinnsal kann man mit einem simplen Brett überbrücken; für eine Meerenge wie das Golden Gate bei San Francisco brauchte man eine Hängebrücke in einer völlig neuen Konstruktion.
● Die beiden Extreme, das Brett und die Golden Gate Bridge, unterscheiden sich nicht nur in den Dimensionen, sondern sie haben so gut wie nichts gemeinsam, was die Voraussetzungen und die notwendigen Arbeiten betrifft.
Fazit:
● Lösungen für kleine Probleme lassen sich nicht für große Probleme skalieren.
19
BeispielDie Probleme, die durch die Größe entstehen, werden durch einen statistischen Effekt verschärft:
● Während es bei einfachen Systemen aus wenigen Komponenten einfach ist, ihre Korrektheit zu überprüfen, wird das bei Systemen aus vielen Komponenten sehr viel schwieriger.
Ein Software-System sei aus n Modulen zusammengesetzt.
● Jedes Modul sei korrekt mit der Wahrscheinlichkeit p; n Module sind dann korrekt mit der Wahrscheinlichkeit pn.
● Für n = 100 können wir die folgenden Werte berechnen.
● Für ein kleines Programm ist p = 0,9 ausreichend, bei einem System aus 100 Modulen muss dazu jedes Modul zu 99,9 % korrekt sein!
20
Wenn p 0,9 0,95 0,99 0,999
dann ist p100 0,000 027 0,006 0,37 0,90
3.3 Probleme und Chancen des Software Engineerings
SE als globale OptimierungZiel: Wir wollen die Gesamtkosten senken.
Ein Ansatz wäre, die einzelnen SE-Aktivitäten auf Möglichkeiten zur Einsparung abzuklopfen. Dieser naive Ansatz führt aber nicht zum Ziel, denn die Aktivitäten sind miteinander verknüpft.
● Wenn man sparen will, kann man die Spezifikation und den Architekturentwurf weglassen, wird dafür aber später, schon beim Test und bei der Integration, mehr noch in der Wartung, bestraft.
Es ist also notwendig, das globale Optimum zu suchen. Dafür gibt es keine simple Formel!
● Wir müssen ein differenziertes Bild der Kosten und ihrer Beziehungen entwickeln, um uns dem Optimum zu nähern.
● Wir müssen dort, wo uns auch das differenzierte Bild der Kosten nicht weiterhilft, weil es zu viele Details bietet, nach dem Vorbild der Ingenieure das Prinzip der hohen Qualität anwenden
22
SE als defensive Disziplin
Software Engineering spielt in der Informatik eine ähnliche Rolle wie die Hygiene in der Medizin:
● Sie nützt nichts, sondern verhindert vielmehr Schäden und sollte generell beachtet werden.
Ist dieses Ideal erreicht, so ist sie als eigenständiges Fach überflüssig.
Software Engineering ist – wie die Hygiene – langweilig und frustrierend für Leute, die die Abwehr von Fehlschlägen und Katastrophen nicht als positive Leistung betrachten.
23
SE als ein Gestrüpp von ProblemenEine Schwierigkeit ist die wechselseitige Verknüpfung zwischen den Maßnahmen, die zum Software Engineering gerechnet werden.
Beispiel:
● Qualitätssicherung erfordert eine Konfigurationsverwaltung.
● Konfigurationsverwaltung setzt die Stabilität der Teilprodukte voraus, was nur durch Qualitätssicherung möglich ist.
24
SE als Technologie für die Köpfe
Wissenschaftliche Erkenntnis und neue Technologie lassen sich gut in die Anwendung transferieren, wenn sie sich in Produkten niederschlagen
● Einen Compiler oder ein Betriebssystem kann man benutzen, ohne die Technik zu verstehen.
Leider lassen sich die Fortschritte im Software Engineering nur zu einem kleinen Teil in Werkzeuge gießen.
Häufig entstehen im Software Engineering Einsichten und Regeln, die von den Software-Entwicklern umgesetzt werden müssen.
● Software Engineering zielt darauf ab, das Verhalten dieser Leute zu verändern.
Nur, wenn den Entwicklern gute Arbeit, Beachtung der Normen, penible Prüfung usw. selbstverständlich sind, können wir erwarten, solide Produkte zu erhalten.
25
