Advertisement

Grundlagen des Software Engineering

  • Reiner Dumke

Zusammenfassung

Die Anwendung von Software in irgendeiner Form ist heutzutage bereits fester Bestandteil des täglichen Lebens. Und so hat auch schon jeder seine Erfahrung mit dieser nicht sichtbaren aber doch zum Teil sehr wirksamen und hilfreichen Form elektronisch gespeicherter Handlungsvorgaben gemacht. Derartige, überwiegend positive Erfahrungen sind beispielsweise
  • die schnelle und durch eine automatisierte (Softwaregestützte) Rechtschreibkontrolle korrekte Erstellung eines Manuskriptes, Briefes oder einer Titelsammlung mit einem Textverarbeitungssystem,

  • die komfortable Führung bei der Informationssuche (beispielsweise in einem Museum) mittels eines Touchscreens auf der Grundlage eines Wissensbasierten Software-Systems,

  • die beeindruckenden Animationseffekte in Filmen durch die Bildverarbeitende und Bilderzeugende Software,

  • die teilweise emotionale Reaktion auf einen Schachzug des Computers beim Spiel mit einem Schachprogramm,

    das „Surfen“ durch das Internet und das Gefühl, aufgrund von Suchmaschinen überall präsent sein und alles einsehen zu können,

  • das faszinierende Navigieren in virtuellen Welten mittels Cyberhead und der 3D-visualisierten Simulationssoftware.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 1.
    Im Deutschen werden hierfür die Begriffe Software-Technik oder Software-Technologie verwendet. Der letztere Begriff soll vor allem den methodologischen Aspekt stärker betonen.Google Scholar
  2. 2.
    Gemäß der allgemeinen Systemdefinition sind dabei Elemente (Teilprodukte) durch eine Struktur verbunden und weisen auf einen nicht näher spezifizierten Umfang und eine Komplexität hin.Google Scholar
  3. 3.
    Das besondere Gewicht bestimmter nationaler Gremien dieser Art, wie beispielsweise die nordamerikanischen, führt allerdings oftmals dazu, nationale Standards auch international zu verwenden.Google Scholar
  4. 4.
    „Warum in aller Welt sind noch nicht alle beim Kodieren?“Google Scholar
  5. 5.
    Man verwendet heute nahezu ausschließlich diesen englischen Begriff. Die deutschen Formen, wie Ideenkonferenz oder Expertenberatung, werden kaum noch benutzt.Google Scholar
  6. 6.
    Es sei bereits hier ausdrücklich darauf hingewiesen, dass die teilweise bzw. schrittweise Umsetzung der Anforderungen ausschließlich vom Umfang des zu entwickelnden Systems abhängt. Bei kleinen Aufgaben kann sofort entworfen bzw. implementiert werden. Die ausschließliche Berücksichtigung der systembezogenen Anforderungen in der Entwurfsphase hat reine didaktischen Gründe und wird in der Praxis zum Teil auch anders gehandhabt.Google Scholar
  7. 7.
    Wir verstehen hier Komponente im weitesten Sinne. So ist beispielsweise auch eine Phase des Entwicklungsprozesses eine Prozesskomponente.Google Scholar
  8. 8.
    Eine weitere Klassifikation auf dieser Grundlage ist die Einteilung nach der Algorithmenart (deterministisch oder nichtdeterministisch) für die sogenannten polynomialen (nc) Berech-nungskomplexitätsformen, also in P und NP. Wir wollen aber unbedingt darauf hinweisen, dass es sich hierbei um eine algorithmische Komplexität und nicht um die (letztlich implementierte) Programmkomplexität handelt.Google Scholar
  9. 9.
    Bei den Türmen von Hanoi geht es darum, dass Mönche 81 unterschiedlich große Ringe von einem Platz unter Verwendung eines Zwischenplatzes auf einen dritten Platz „übertragen“. Dabei darf immer nur ein kleinerer Ring auf einen größeren gelegt werden. Bei einer „Übertragungsgeschwindigkeit“von einer Sekunde pro Ring wird prophezeit, dass zum Abschluss des Umlegens auch die Weltzeit „abgelaufen“ist.Google Scholar
  10. 10.
    Der Begriff Pseudocode kennzeichnet den Unterschied zu einem von einem Compiler verarbeitbaren Code. Hierbei werden beispielsweise keine Datendefinitionen angegeben, so dass eine Übersetzung im üblichen Sinne nicht möglich wäre.Google Scholar
  11. 11.
    Unter 4GL (Fourth Generation Languages) versteht man problemspezifische Ausrichtungen hinsichtlich Tabellenkalkulation, Datenbanken oder Rechner Systemen.Google Scholar
  12. 12.
    In der Literatur schließt die Bezeichnung Entwurf manchmal auch die Spezifikation mit ein. Wir wollen hier allerdings auch aus didaktischen Gründen die Trennung beibehalten.Google Scholar
  13. 13.
    In der „schlechten“Praxis hat man häufig den Fall, dass zu einem Programm die Dokumentation nachträglich angefertigt wird, während man bereits beim Programmieren des nächsten ist.Google Scholar
  14. 14.
    In der Praxis hat sich die nahezu ausschließliche Verwendung der englischen Bezeichnungen Review und Audit durchgesetzt.Google Scholar
  15. 15.
    Man beachte, dass bei den Assertions eine mathematische Schreibweise (mit indizierten Größen) vorzunehmen ist, im Gegensatz zum Programm, bei denen die Größen Speicherbereiche identifizieren.Google Scholar
  16. 16.
    Bei der Programmverifikation unterstellen wir natürlich der jeweils verwendeten Programmiersprache eine spezielle Interpretation.Google Scholar
  17. 17.
    Die Testfälle sind hierbei sehr einfacher Art, da auch die Problembeschreibung sehr einfach gehalten ist. So fehlen z. B. Angaben zur Zahlenart, der Ausgabeform oder möglicher bzw. notwendiger Fehlerbehandlungsmaßnahmen.Google Scholar
  18. 18.
    Das V-Modell stellt, wie in der erwähnten Literatur beschrieben, einen umfangreichen Standard zur Software-Entwicklung insgesamt — einschließlich aller Dokumentationsformen — dar (siehe auch http://www.v-modell.iabg.de). Wir behandeln es hier nur in seinen grundlegenden Aussagen, da die anderen dort genannten Aspekte hier bereits zum Teil behandelt wurden bzw. in den noch folgenden Abschnitten näher erläutert werden.
  19. 19.
    Eine detaillierte Beschreibung ist unter http://www.sei.cmu.edu/psp/ von den Entwicklern dieses Modell nachzulesen.
  20. 20.
    IT steht für Informationstechnologie und hat die klassischen Begriffe wie EDV (elektronische Datenverarbeitung) oder DV abgelöst.Google Scholar
  21. 21.
    Im Englischen wird der Begriff Tool beim Software Engineering noch weitreichender verwendet. Er bezeichnet hierbei auch Handlungsvorschriften oder Regeln, die nicht rechnergestützt sind.Google Scholar
  22. 22.
    Diese Abkürzung steht für „What you see is what you get“und bringt zum Ausdruck, dass das im Allgemeinen mit (HTML-) Steuerbefehlen erzeugte Seitenlayout unmittelbar auch zu sehen ist.Google Scholar
  23. 23.
    Warum wir hier nicht ein einfaches Graphik-Tool, wie den Designer oder Corel Draw, verwendet haben, gehen wir im nächsten Abschnitt noch näher ein.Google Scholar
  24. 24.
    Eine umfangreiche Übersicht zu weiteren CASE-Tools ist im WWW unter http://www.qucis.queensu.ca/Software-Engineering/tools.html zu finden.
  25. 25.
    Die hier vorgenommene Bewertung geht von der Annahme aus, dass nach ca. 5 Versionen eines Software-Systems eine Abwärtskompatibilität nicht mehr gegeben ist.Google Scholar
  26. 26.
    Gegebenenfalls wird auch nominales oder ordinales „Messen“zugelassen. Dann entfällt die Maßeinheit.Google Scholar
  27. 27.
    Auf die sogenannte Absolutskala gehen wir hierbei nicht ein, da diese beim Software Engineering bisher kaum Anwendung findet.Google Scholar
  28. 28.
    ISO 9000 ist ein allgemeiner, generell in der Industrie eingesetzter Standard zur Bewertung des Herstellungsprozesses und besitzt eine spezielle Ausprägung für die Anwendung im Software Engineering. Wir gehen darauf im folgenden Kapitel noch näher ein.Google Scholar
  29. 29.
    Die Abkürzung COCOMO steht für Constructive Cost Model und wurde von Barry Boehm Anfang der 80-er Jahre entwickelt. Auf diese Methode gehen wir insbesondere unter Berücksichtigung ihrer aktuellen Ausprägung im folgenden Kapitel noch näher ein.Google Scholar
  30. 30.
    metrisch steht hier für intervall- oder ratioskaliertGoogle Scholar
  31. 31.
    LISREL bedeutet Linear Structural Relationship Google Scholar
  32. 32.
    Government off-the-shelf-ToolsGoogle Scholar
  33. 33.
    Im PERT-Diagramm sind die sogenannten Basispfade diejenigen Pfade ohne Scheinübergänge, die auch explizit für die Projektdauer Schätzung zugrunde gelegt werden.Google Scholar
  34. 34.
    erreichbar unter der http://www.ifpug.org
  35. 35.
    Eine Bewertung durch Humphrey 1989 in den USA zeigte als Ergebnis für 86% der Firmen die Stufe 1, 12% die Stufe 2 und 2% die Stufe 3. Die Stufen 4 und 5 konnten zu diesem Zeitpunkt bei keiner Firma festgestellt werden (siehe auch unter „www.sei.edu/“).Google Scholar

Copyright information

© Friedr. Vieweg & Sohn Verlag/GWV Fachverlage GmbH, Wiesbaden 2003

Authors and Affiliations

  • Reiner Dumke

There are no affiliations available

Personalised recommendations