Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Software Engineering © Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010. 3Software.

Ähnliche Präsentationen


Präsentation zum Thema: "Software Engineering © Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010. 3Software."—  Präsentation transkript:

1 Software Engineering © Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, Software Engineering 3.1 Fortschritte in Hard- und Software 3.2 Grundideen des Software Engineerings 3.3 Probleme und Chancen des Software Engineerings

2 3.1Fortschritte in Hard- und Software

3 Moores 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

4 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

5 Fortschritte bei Hard- und Software Entwicklung von 1960 bis

6 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

7 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

8 Betrachtung des Gesamtnutzens - 1 Extrem einfaches Modell Der Gesamtnutzen N ist das Produkt aus Hardware-Nutzen und Software-Nutzen. N = N HW * N SW N HW = k HW * G HW, N SW = k SW * G SW Steht das Geld G zur Verfügung, so gilt außerdem G HW + G SW = G. Die Ableitung nach N HW (oder N SW ) ergibt: N erreicht sein Maximum für N HW = N SW = N/2 8

9 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

10 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

11 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

12 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

13 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 (1990)

14 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

15 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

16 3.2Grundideen des Software Engineerings

17 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 Terminesind in der Regel mit genügender Genauigkeit planbar sind wegen der Abhängigkeit von der Inspiration nicht planbar Der Preisist 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 Urheberbleibt 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

18 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

19 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

20 Beispiel Die 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 p n. 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,90,950,990,999 dann ist p 100 0, ,0060,370,90

21 3.3Probleme und Chancen des Software Engineerings

22 SE als globale Optimierung Ziel: 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

23 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

24 SE als ein Gestrüpp von Problemen Eine 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

25 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


Herunterladen ppt "Software Engineering © Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010. 3Software."

Ähnliche Präsentationen


Google-Anzeigen