Software Engineering (eBook)
712 Seiten
dpunkt (Verlag)
978-3-96088-547-4 (ISBN)
Das Handbuch fürs Selbststudium, für den Job oder vorlesungsbegleitend
- erfahrungsbasierter Über- und Einblick ins Software Engineering, der sowohl die Theorie als auch die Praxis abdeckt
- umfassend, verständlich und praxiserprobt
Das Buch vermittelt die Grundlagen, Erfahrungen und Techniken, die den Kern des Software Engineerings bilden. Es ist als Material zu Vorlesungen über Software Engineering konzipiert. Auch für Praktiker, die mit der Softwareentwicklung und -bearbeitung und den dabei auftretenden Problemen vertraut sind, ist das Buch sehr gut geeignet, um die Kenntnisse im Selbststudium zu ergänzen und zu vertiefen. Der Inhalt des Buches ist in fünf Hauptteile gegliedert:
- Grundlagen
- Menschen und Prozesse
- Daueraufgaben im Softwareprojekt
- Techniken der Softwarebearbeitung
- Verwaltung und Erhaltung von Software
Auch auf die Ausbildung zukünftiger Software Engineers wird eingegangen. Ergänzende Informationen sind auf der Webseite der Autoren verfügbar: https://se-buch.de.
Prof. Dr. rer. nat. Jochen Ludewig geboren 1947 in Hannover. Studium der Elektrotechnik (TU Hannover) und Informatik (TU Mu?nchen); Promotion 1981. 1975 bis 1980 Gesellschaft fu?r Kernforschung, Karlsruhe, dann Brown Boveri Forschungszentrum in Baden/Schweiz. 1986 Assistenzprofessor an der ETH Zu?rich, 1988 Ruf auf den neuen Lehrstuhl Software Engineering an der Universität Stuttgart. Arbeitsgebiete: Softwareprojekt-Management, Software-Pru?fung und Software-Qualität, Software-Wartung. Ab 1996 Konzeption und Aufbau des Diplomstudiengangs Softwaretechnik, der inzwischen in einen Bachelor- und einen Masterstudiengang umgewandelt wurde. Seit 2009 Fellow der Gesellschaft fu?r Informatik (GI). Prof. Dr. rer. nat. Horst Lichter geboren 1960 in Trier. Studium der Informatik und Betriebswirtschaftslehr (TU Kaiserslautern). Wissenschaftlicher Mitarbeiter (ETH Zu?rich und Universität Stuttgart), Promotion 1993. Anschließend Schweizerische Bankgesellschaft Zu?rich und ABB Forschungszentrum Heidelberg. 1998 Ruf an die RWTH Aachen University, Leiter des Lehr- und Forschungsgebiets Software-Konstruktion. Arbeitsgebiete: Software-Architektur, Qualitätssicherung, Software-Evolution. Seit 2005 Lecturer an der Thai German Graduate School of Engineering (TGGS) in Bangkok. Von 2018-2021 Adjunct Lecturer an der Universiti Teknologi Petronas (UTP) Malaysia.
Prof. Dr. rer. nat. Jochen Ludewig geboren 1947 in Hannover. Studium der Elektrotechnik (TU Hannover) und Informatik (TU München); Promotion 1981. 1975 bis 1980 Gesellschaft für Kernforschung, Karlsruhe, dann Brown Boveri Forschungszentrum in Baden/Schweiz. 1986 Assistenzprofessor an der ETH Zürich, 1988 Ruf auf den neuen Lehrstuhl Software Engineering an der Universität Stuttgart. Arbeitsgebiete: Softwareprojekt-Management, Software-Prüfung und Software-Qualität, Software-Wartung. Ab 1996 Konzeption und Aufbau des Diplomstudiengangs Softwaretechnik, der inzwischen in einen Bachelor- und einen Masterstudiengang umgewandelt wurde. Seit 2009 Fellow der Gesellschaft für Informatik (GI). Prof. Dr. rer. nat. Horst Lichter geboren 1960 in Trier. Studium der Informatik und Betriebswirtschaftslehr (TU Kaiserslautern). Wissenschaftlicher Mitarbeiter (ETH Zürich und Universität Stuttgart), Promotion 1993. Anschließend Schweizerische Bankgesellschaft Zürich und ABB Forschungszentrum Heidelberg. 1998 Ruf an die RWTH Aachen University, Leiter des Lehr- und Forschungsgebiets Software-Konstruktion. Arbeitsgebiete: Software-Architektur, Qualitätssicherung, Software-Evolution. Seit 2005 Lecturer an der Thai German Graduate School of Engineering (TGGS) in Bangkok. Von 2018-2021 Adjunct Lecturer an der Universiti Teknologi Petronas (UTP) Malaysia.
1Modelle und Modellierung
Modelle sind ein fundamentales Konzept unseres Umgangs mit der Welt. Alle Naturwissenschaftler und Ingenieure verwenden und schaffen Modelle, um allgemeingültige Aussagen zu treffen und um ihre Vermutungen zu konkretisieren. Oft markieren die Modelle Zwischenschritte auf dem Weg zu neuen Artefakten, also zu Brücken, Autos oder Funktelefonen. Im Software Engineering ist die Bedeutung der Modelle noch größer, weil sie nicht Zwischenschritte, sondern Endpunkte unserer Arbeit darstellen: Eine Spezifikation, aber auch ein Programm ist ein Modell. Natürlich gehören auch die Prozessmodelle dazu, nach denen die Projekte organisiert werden. Wir legen also mit diesem Kapitel, das auf Ludewig (2003) basiert, den Grundstein für unser Buch. Das gilt auch für die beiden letzten Abschnitte, die sich mit Skalen und Skalentypen befassen.
1.1Modelle, die uns umgeben
1.1.1Die Bedeutung der Modelle
Lebenswichtig für uns sind die Modelle, die wir als Begriffe kennen und verwenden, um uns ein Bild (d. h. ein Modell) der Realität zu machen. Ohne die Begriffe wäre für uns jeder Gegenstand ganz neu; weil wir aber zur Abstraktion fähig sind, können wir die Identität eines Gegenstands, seinen Ort, seinen Zustand und u. U. viele andere individuelle Merkmale ausblenden, um ihn einer Klasse von Gegenständen, eben dem Begriff, zuzuordnen. Auf diese Weise erkennen wir auch einen Gegenstand, den wir noch nie gesehen haben, als Bleistift, Stuhl, Auto oder was immer in unserer Vorstellung am besten passt.
Diese Fähigkeit ist uns bereits von Natur aus gegeben; sie ist weder bewusst steuerbar, noch lässt sie sich unterdrücken. Darum sind wir auch nicht davor geschützt, falsche (d. h. ungeeignete) Modelle zu wählen. Wir erleben das erheitert bei optischen Täuschungen, wir erleiden es, wenn wir direkt oder indirekt Opfer von Vorurteilen werden: Auch das sind Modelle.
Dagegen steht es uns frei, Modelle bewusst einzusetzen, um auf diese Weise Phänomene zu erklären oder Entscheidungen zu überprüfen, bevor sie wirksam werden. Beispielsweise können wir ein geplantes Bauwerk durch eine Zeichnung oder ein Papiermodell darstellen und dann den Entwurf anhand des Modells überprüfen.
Wo Modelle offensichtliche Schwächen zeigen, neigen wir dazu, sie zu belächeln. Das gilt etwa für die Puppe, die ein spielendes Kind in einem länglichen Stück Holz sieht. Wo Modelle dagegen sehr überzeugend wirken, besteht die Gefahr, dass sie mit der Realität verwechselt werden. Darum ist zunächst festzuhalten: Ein Modell ist ein Modell, es ist nicht die Realität. Die Schwierigkeit, die wir haben, wenn wir von Modellen auf die Realität zu schließen versuchen, hat bereits der griechische Philosoph Platon (428/427–348/347 v. Chr.) in seinem berühmten Höhlengleichnis angesprochen. Darin beschreibt er die Situation eines Menschen, der, seit seiner Kindheit in einer Höhle mit dem Gesicht zur Wand gefesselt, nur die Schatten der Menschen sieht, die an der Höhle vorbeilaufen. Der Gefangene muss die Schatten als Realität nehmen, da ihm die wirkliche Realität nicht zugänglich ist. Die Botschaft dieses Gleichnisses ist, dass wir alle in dieser Situation sind, also nicht die Realität sehen können, sondern nur die Schatten.
1.1.2Beispiele für Modelle
Alle Begriffe sind Modelle; diese sehr allgemeine Betrachtungsweise spielt hier weiter keine Rolle mehr, wir konzentrieren uns auf »richtige« Modelle. Auch diese sind uns so geläufig, dass wir sie in der Regel nicht mehr als Modelle wahrnehmen: Jedes Bild, jedes Schema ist ein Modell. Beispielsweise sind Modelle eines bestimmten oder unbestimmten Menschen
- ein Personenfoto,
- die anatomische Darstellung der Blutbahnen,
- Strichmännchen und Piktogramme, die einen Menschen zeigen,
- ein Fingerabdruck,
- ein Gemälde, das einen Menschen zeigt,
- ein Steckbrief (mit oder ohne Bild),
- eine Matrikelnummer.
Unmittelbar leuchtet das für solche Modelle ein, die (wie das Foto oder die anatomische Darstellung) eine optische oder strukturelle Ähnlichkeit mit dem Original aufweisen. Aber auch die übrigen Beispiele sind, wie unten gezeigt wird, korrekt.
Im Software Engineering treffen wir Modelle auf verschiedenen Ebenen an:
- Software wird auf unterschiedliche Arten repräsentiert, typischerweise durch eine Spezifikation, einen Entwurf, durch Diagramme und Quellcode, Kennzahlen (Metriken) und Prospekte. Offenkundig haben wir hier Modelle vor uns; dabei bleibt zunächst noch unklar, welcher Gegenstand denn eigentlich das Original darstellt. Wenn man bedenkt, dass man (nach dem Lehrbuch) den Code auf der Grundlage einer Spezifikation entwickelt, dass andererseits in der Praxis sehr oft versucht wird, den Sinn eines Programms (d. h. seine Spezifikation) aus dem Code abzuleiten, dann sieht man, dass die Frage nicht eindeutig zu beantworten ist.
- Die Abläufe bei der Arbeit an Software werden durch Prozessmodelle beschrieben. Gutes Software Engineering ist weitgehend gleichbedeutend mit der Wahl eines geeigneten Prozessmodells und seiner Umsetzung in die Praxis.
Allgemeiner gesagt ist jede Theorie ein Modell. Im Software Engineering steckt die Theoriebildung noch in den Kinderschuhen, wir müssen uns gerade darum mit ihr befassen (siehe Abschnitt 1.6).
1.2Modelltheorie
Herbert Stachowiak (1921–2004) hat das Standardwerk zur Modelltheorie verfasst. Die folgenden Aussagen zur Modelltheorie geben Gedanken aus diesem Buch wieder (Stachowiak, 1973).
1.2.1Deskriptive und präskriptive Modelle
Modelle, wie wir sie aus dem Alltag kennen, sind entweder Abbilder von etwas oder Vorbilder für etwas; sie werden auch als deskriptive (d. h. beschreibende) bzw. präskriptive (d. h. vorschreibende) Modelle bezeichnet. Eine Modelleisenbahn ist ein Abbild; eine technische Zeichnung, nach der ein Mechaniker arbeitet, ist ein Vorbild. Wenn ein Gegenstand fotografiert wird und dann Änderungen im Foto skizziert werden, geht das eine in das andere über. Den Modellen kann man im Allgemeinen nicht ansehen, ob sie deskriptiv oder präskriptiv sind; eine Modelleisenbahn kann auch der Entwurf für eine erst zu bauende reale Bahn sein, eine Zeichnung kann nach einem realen Gegenstand entstanden sein.
1.2.2Die Modellmerkmale
Jedem Modell (wie in Abb. 1–1 schematisch dargestellt) sind drei Merkmale zu eigen (sonst ist es kein Modell):
- Das Abbildungsmerkmal
Zum Modell gibt es das Original, ein Gegenstück, das wirklich vorhanden, geplant oder fiktiv sein kann. (Beispiel: Zu einem Foto gibt es das fotografierte Motiv, zum Rauschgoldengel gibt es den – wenn auch fiktiven – Engel der Fantasie.) - Das Verkürzungsmerkmal
Ein Modell erfasst nicht alle Attribute des Originals, sondern nur einen Ausschnitt (der vor allem durch den Zweck des Modells bestimmt ist, siehe pragmatisches Merkmal).
Abb. 1–1Original und Modell nach Stachowiak
Damit fallen die präterierten Attribute weg (von lat. praeter: außer, ausgenommen). Das sind alle Attribute des Originals, die im Modell nicht repräsentiert sind. Das Modell weist stattdessen abundante Attribute auf (von lat. abundans: übervoll, überreich), die nichts mit dem Original zu tun haben. So sind auf dem Foto einer Person die meisten ihrer Attribute präteriert (ihr Gewicht, ihr Name, ihre Blutgruppe usw.). Andererseits sind Attribute des Modells abundant, sie haben nichts mit der Person zu tun (die Qualität des Fotopapiers, das Format). Der Fingerabdruck gibt nur einen winzigen Ausschnitt der Merkmale eines Menschen wieder, alle anderen Merkmale sind präteriert; die Farbe des Abdrucks ist dagegen ein abundantes Attribut.
- Das pragmatische Merkmal
Modelle können unter bestimmten Bedingungen und bezüglich bestimmter Fragestellungen das Original ersetzen. (Beispiel: Ein Foto erlaubt die Beurteilung eines Unfalls, der sonst nur durch Anwesenheit am Unfallort zu beurteilen gewesen wäre. Der Fingerabdruck gestattet es eventuell, die Identität einer Person festzustellen, auch wenn die Person selbst nicht zur Verfügung steht.)
1.3Ziele beim Einsatz von Modellen
Modelle werden mit unterschiedlichen Zielen (Zwecken) eingesetzt. Diese Ziele sind nicht präzise unterscheidbar, sie gehen ineinander über.
1.3.1Modelle für den Einsatz in der Lehre und zum Spielen
Modelle werden vielfach in der Ausbildung, in der Werbung, für Spiele usw. eingesetzt, wo die Originale aus ethischen oder praktischen...
Erscheint lt. Verlag | 28.2.2023 |
---|---|
Verlagsort | Heidelberg |
Sprache | deutsch |
Themenwelt | Mathematik / Informatik ► Informatik ► Software Entwicklung |
Schlagworte | Agile Softwareentwicklung • Agile Teams • Agilität • Aufwandsschätzung • Dokumentation • Komplexität • Konfigurationsverwaltung • Metriken • Modellierung • Projektmanagement • Prozessmodelle • Reengineering • Softwareentwicklung • Softwareentwurf • Softwareprojekt • softwareprozess • Softwareprüfung • Softwarequalität • Softwarequalitätssicherung • software science • Softwarewartung • Vorgehensmodelle |
ISBN-10 | 3-96088-547-4 / 3960885474 |
ISBN-13 | 978-3-96088-547-4 / 9783960885474 |
Informationen gemäß Produktsicherheitsverordnung (GPSR) | |
Haben Sie eine Frage zum Produkt? |
Größe: 11,3 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich