Softwaretechnologie

Grundlagen der Softwaretechnik. Behandelt Prozesse, Entwurfsrinzipien, Modelle und Konzepte.


Kapitel 1 - Einführung Softwaretechnik

multi-person construction of multi-version software

Parnas (1987)

Software Engineering - charakteristische Eigenschaften und Ziele

Es geht darum Fehler zu beheben, die Funktionalität zu erweitern, Altes Entfernen oder an neue Umgebungen anzupassen. Gemeinsame Prinzipien sind

  1. Separation der Belange / Anforderungen
  2. Modulatität (Dekomposition komplexer Probleme, d.h. Top Down oder Zusammensetzen eines komplexen Systems aus bestehenden Fabrikteilen, d.h. Buttom-up)
  3. Abstraktion (wichtige Dinge herausheben und Details ignorieren und gegebenfalls verschiedene Abstraktionen der gleichen Realität darstellen)
  4. Voraussicht auf Änderungen (d.h. bei Entwicklung bedenken, daß sich Anforderungen im Laufe der Zeit ändern werden. Somit Version Managment notwendig)
  5. Generalisierung (d.h. Probleme versuchen zu generalisieren, um diese auf einer höheren Ebene anzugehen)
  6. Inkrementelles Vorgehen (Incrementality / schrittweises Vorgehen ermöglicht einen evulotionären Entwicklungsprozess bei dem ein frühes Feedback die initialen Anforderungen erreicht)

Teildisziplinen der Softwaretechnik

SW-Entwicklung, SW-Management, SW-Qualitätssicherung und Wartung und Pflege

Programmieren im Kleinen und im Großen, Unterschiede

Engineering - systematischer Ansatz zum Problemlösen

Warum ist Software Engineering so kompliziert?

Geschichte des Software Engineering

Probleme der Entwicklung von großen Softwaresystemen und Ursachen

Lebenszyklus eines Softwaresystems

Wasserfallmodell des Lebenszyklus eines Softwaresystems

  1. Analyse
  2. Design
  3. Implementation und Modultest
  4. Inegration und Systemtests
  5. Inbetriebnahme und Wartung

Phasen des Wasserfallmodells

Programmiersprachen und SE (Einfluss)

Grund für Datenbanken

Datenunabhängigkeit, d.h. Verwendung von Daten, ohne die zugrundeliegende Datenrepräsentation kennen zu müssen

Trennung von Spezifikation und Implementierung

Datenbanken und SE (Einfluss)

Management und Software Engineering - Ziele und Struktur

Technisches Managment

Personalmanagment

Kapitel 2 - Eigenschaften und Prinzipien

Was ist Software ?

"Sammelbezeichnung für Programme, die für den Betrieb von Rechensystemen zur Verfügung stehen, einschließlich der zugehörigen Dokumentation" (Brockhaus-Enzyklopädie)

Besondere Eigenschaften der Software als Produkt

Eigenschaften von Software

  1. Korrektheit
  2. Wiederverwendbarkeit
  3. Zuverlässigkeit
  4. Wachstum/Evolution
  5. Robustheit
  6. Portabilität
  7. Effizienz / Leistung
  8. Verständlichkeit
  9. Benutzerfreundlichkeit
  10. Interoperabilität
  11. Verifizierbarkeit
  12. Produktivität
  13. Wartbarkeit
  14. Pünktlichkeit/Aktualität
  15. Korrigierbarkeit
  16. Sichtbarkeit
  17. Korrektheit von Software

Zuverlässigkeit von Software

Das Programm macht das, was es soll und was erwartet wird.

Zuverlässigkeit ist relatives Qualitätsmerkmal, denn inkorrekte Software kann trotzdem zuverlässig sein, geringes inkorrektes Verhalten kann toleriert werden.

Robustheit von Software

Ein Programm ist robust, wenn es sich selbst unter Bedingungen "vernünftig" verhält, mit denen nicht in der Anforderungsspezifikation gerechnet wurde. (z.B. inkorrekte Eingabedaten, Fehlfunktion der Hardware).

Leistung von Software

Benutzerfreundlichkeit von Software

Verifizierbarkeit von Software

Wartbarkeit von Software

Kategorien:

  1. korrigierende Wartung
  2. Anpassende Wartung
  3. vervollkommende Wartung

Korrigierbarkeit von Software

Erweiterbarkeit von Software (Wachstum, Evolution)

Wiederverwendbarkeit von Software

Portabilität von Software

Verständlichkeit von Software

Ein Programm ist verständlich, wenn sein Verhalten vorhersehbar ist

Intern:

  1. Wie verständlich ist das SW-System?
  2. Einfluss auf Erweiterbarkeit und Verifizierbarkeit

Extern:

  1. SW-System ist verständlich, wenn es vorhersagbares Verhalten aufweist
  2. Verständlichkeit ist Teil der Benutzerfreundlichkeit

Interoperabilität von Software

Ist die Möglichkeit eines Systems mit andern Systemen zu koexistieren und zu kooperieren. Offene Systeme haben standartisierte Schnittstellen, die Kommunikation von Systemem verschiedener Hersteller ermöglichen.

Produktivität der Software-Entwicklung

Möglichkeit der rechtzeitigen Lieferung des Produktes(Pünktlichkeit/Aktualität)

Notwendig sind dafür Vorsichtige Kostenberechnung, Aufwandsabschätzung und Planung, Einsetzung Milestones und Projektmanagment mit computergestützten Projektmanagmenttools.

Sichtbarkeit

Prinzipien des Entwurfs

Prinzip des Filtern und Trennen - Zerlegen von Komplexität

Zerlegung auf Basis von:
  1. Zeit: Zeitplan von Aktivitäten
  2. Qualitätsmerkmalen: z.B. erst Korrektheit, dann Effizienz
  3. Sichten: z.B. einerseits Datenfluss, andererseits Kontrollfluss
  4. Größe: Modularisierung
  5. Verantwortlichkeiten: Arbeitsverteilung auf verschiedene
  6. Personen mit verschiedenen Fähigkeiten

Prinzip der Modularisierung

Zerlegbarkeit eines Systems: Zusammensetzbarkeit eines Systems:

Prinzip der Abstraktion

Prinzip des Vorgriff von Änderungen

Ist ein Prinzip, das Software stark von anderen Typen von Industrieprodukten unterscheidet.

  1. neue Anforderungen werden gefunden
  2. alte Anforderungen werden aktualisiert
Deshalb Vorsorge für Veränderungen treffen (z.B. durch entspr. Entwurf)

Prinzip der Allgemeinheit / Allgemeingültigkeit

Wenn ein bestimmtes Problem gelöst werden soll, sollte man versuchen, ein allgemeineres Problem als dieses zu identifizieren und das allgemeinere Problem zu lösen (denn das wahrscheinlich eher wiederverwendbar).

Prinzip der Inkrementalität

Warum wird Software so oft geändert?

  1. Anforderungen des Kunden wachsen
  2. Es werden Fehler gemacht
  3. Bei Spezifikation wurden Teile vergessen

Kapitel 3 - Analyse und Spezifikation

SE als Ingenieurarbeit (ingenieurgemäßes Herangehen)

  • Definiere klar das Problem, das es zu lösen gilt.
  • Entwickle Standardwerkzeuge, -technologien und -methodologien, um das Problem lösen zu können

Funktionsmodellierung: Datenflussdiagramme, Data Dictionary,Prozessspezifikationen

Datenmodellierung: ER-Modell

Ereignismodellierung: Endliche Automaten, Petri-Netze

Ziele, Struktur und Prozess der Analyse

Folgende Punkte gehören zur Analyse:

  1. Spezifikation der Hauptziele
  2. Informationsquellen beschaffen
  3. Anforderungsanalyse
  4. Abgrenzung des Problembereiches
  5. Festlegung der Beteiligten
  6. Inhaltsbeschreibung
  7. Use Cases erstellen
  8. Prioritäten festlegen
  9. alternative Lösungen suchen
  10. Empfehlungen vergeben

Erfassung der Anforderungen

Kategorien von Anfroderungen

  1. funktionale: Was soll das neue System leisten?
  2. qualitative: Qualitätsfaktoren, die durch zu erfüllen sind
  3. operationelle: zu erwartende Bedingungen beim praktischen Einsatz

Phasen der Analyse

1. Ist-Analyse:

2. Soll-Konzept:

2 Verfahren:

Strukturierte und Objektorientierte Analyse

Strukturierte Analyse

modifizierte strukturierte Analyse:

Analyse

Datenflussdiagramm - Konstruktion, Vorteile, Nachteile

Konsistenz eines Datenflussdiagramms

Was steht alles in einem Datenkatalog?


Termine = Datum + Anfang + Ende + Status + Zweck

Anfang = Zeit

Zeit = Stunde + Minute

Datum = Tag + Monat + Jahr

Adresse = PLZ + Ort + Strasse

Gruppendaten = Gruppenname

Optionen = {Farbe + Terminart}

Minute = Ziffer + Ziffer

Mitarbeiter_ID = Ziffer + Ziffer 

Nutzername = {Zeichen}

Passwort = {Zeichen}

Nachricht = {Zeichen}

PLZ = {Ziffer}

Prozessspezifikation

Wie beschreibt man Prozesse in der strukturierten Analyse? Für alle elementaren Prozesse werden Prozessspezifikationen angefertigt.

elementarer Prozess:

Prozess auf der untersten Ebene der Prozesshierarchie, welcher nicht mehr weiter verfeinert wird (Blatt des Hierarchiebaums)

vier Möglichkeiten der Beschreibung

  1. strukturierte Sprache (Pseudo-Code)
  2. Entscheidungstabellen
  3. endliche Automaten
  4. logische Spezifikation

Was ist eine Entscheidungstabelle?

vier Komponenten

  1. Bedingungen: logische Ausdrücke
  2. Aktionen: semantische Einheiten, werden später durch entsprechende Programmabschnitte implementiert
  3. Regeln: Eine Regel bezeichnet eine Kombination von Bedingungen
  4. Aktionsanzeiger: Ein Aktionsanzeiger repräsentiert eine Zuordnung zwischen einer Regel und einer Auswahl von Aktionen, die bei Gültigkeit der Regel durchgeführt werden

Was modelliert man mit einem endlichen Automaten, wie und warum?

Darstellungsmöglichkeiten

  1. Zustandsdiagramm
  2. Zustandstabelle
  3. Zustandsmatrix

Endliche Automaten - Grenzen des Einsatzes, Vorteile, Nachteile

Petri Netze

Ist ein für Modellierung eines Systems konkurrierender/kooperierender Prozesse geeignetes Werkzeug.

Petri

Problem der Synchronisation und Petri-Netze

Marken repräsentieren den Kontrollfluss, sind jedoch anonym und deshalb ist der Inhalt der Marke unbekannt.

Bsp.:

Eine Marke in einem Puffer beschreibt das Vorhandensein einer Nachricht, aber nicht, ob diese wohl formuliert ist oder nicht. So kann eine Auswahl auf Basis des Inhalts der Marke nicht durch das Petri-Netz beschrieben werden, wenn mehrere Transitionen geschalten werden können.

Desweiteren ist keine Beschreibung von Prioritäten oder auch Zeitbeschränkungen möglich.

Bsp.: Wenn länger als eine Sekunde gewartet wird, soll eine Meldung generiert werden

Konstruktion eines Modells mit einem Petri-Netz

Darstellungselemente:

  1. Stelle: Zustand eines Prozesses; repräsentiert eine Bedingung
  2. Transition: gesteuerter Zustandsübergang; modelliert ein Ereignis, welches durch das Schalten ("Feuern") der Transition ausgelöst wird
  3. Pfeil: zwischen Stelle und Transition und umgekehrt
  4. Marke: ihre Anwesenheit in allen vor einer Transition liegenden Stellen ist die notwendige Bedingung, dass die Transition schalten (feuern) kann
Mutual Exclusion ist mit Petri Netzen einfach umsetzbar, dafür sind aber Deadlocks möglich...

Warum und wie werden Petri-Netzen erweitert?

OO Analyse

"Im Mittelpunkt stehen Objekte, welche Abbilder von Real-Welt- Objekten des zu analysierenden Problembereichs darstellen. Jedes Objekt besitzt eine eindeutige Identität (Objektidentität), bestimmte Eigenschaften (Attribute) sowie ein bestimmtes Verhalten (Methoden). Die Objekte kommunizieren miteinander durch das Senden von Botschaften. Wie ein Objekt auf erhaltene Botschaften reagiert, wird jeweils durch die in ihm vorhandenen Methoden definiert. Weitere wichtige Konzepte der OOA sind u.a.: Klasse, Datenkapselung, Vererbung und Polymorphismus (überladen)."

Objektorientierte Analyse

Konzepte der objektorientierten Programmierung

Schritte der objektorientierten Analyse

Grammatische Inspektion

Modellierung von Beziehungen

Modellierung von Restriktionen (Constraints)

Einschränkungen die zu den Klassen definiert werden (Max-Werte oder Min-Werte...)

Kapitel 4 - Prozess der Analyse

Wozu gibt es die Risikoanalyse und wie wird sie durchgeführt?

Wie identifiziert man Systemgrenzen und Akteure?

Es gibt interne Systemgrenzen und Externe (nicht unsere Aufgabe, aber evt. Schnittstellen dazu). Akteure ist all das, was mit dem System interagieren muss.

  1. Wer benutzt das System (Mensch oder System)?
  2. Wer wartet es?
  3. Wer fährt es herunter?
  4. Wer bekommt Infos aus dem System?
  5. Wer füttert es mit Daten?
  6. Was passiert automatisch im System?

Wie identifiziert man Anwendungsfälle? (Use Cases)

Ein Use Case beschreibt was ein Akteur machen möchte. Was passiert, was wird ausgetauscht und welche Ereignisse gibt es dabei?

Use Case

Modellierungshilfen

Scenarien, UML und Klassendiagramme...

Was ist ein Szenario?

Was ist der Umfang eines Projektes und warum ist er so wichtig?

Szenarien sollten vollständig sein, um Fehler schnell erkennen zu können.

Modellierung in UML- grundlegende Fragen

Basiert auf OO

Fragen

  1. Wer sind die User des Systems? = Akteure
  2. Welche sind die Hauptobjekte?
  3. Welche Objekte werden für welchen Use Case gebraucht?

Was beschreibt man alles in einem Klassendiagramm?

Klassendiagramm

Wie modelliert man ein GUI (Graphical User Interface)?

Wozu gibt es die Robustness-Analyse?

Hier werden drei Arten von Objekte eingeführt...
  1. Boundary Objects (Akteure welche mit System kommunizieren)
  2. Entity Objects (Objekte des Domänenmodells-Hauptentities)
  3. Control Objects (Verbinden Boundary und Entity Objekte)

Warum und wie konstruiert man Sequenzdiagramme?

Beschreiben, wie die Objekte zusammenarbeiten und in welchem zeitlichen Ablauf die Methoden aufgerufen werden. Sequenzdiagramme sind mit den Klassendiagrammen konistent. Sie beziehen sich auf einen konkreten Ablauf (Szenario) eines Use Case!

Klassendiagramm

Eine Alternative zu Sequenzdiagrammen sind Kollaborationsdiagramme. Sie verdeutlichen besser die Struktur des Diagrammes, dafür ist die zeitliche Abfolge der Methodenaufrufe schlechter erkennbar als in Sequenzdiagrammen.

Was modellieren die Kollaborations- und Zustandsdiagramme?

Aktivitätsdiagramme sind relativ neu in UML und dienen zur Beschreibung von Abläufen und zwar nicht nur am Bsp. eines Use Cases. Es werden vielmehr die Verhalten von Objekten in mehreren Use Cases aufgezeigt. Dabei ist Synchronistation und Nebenläufigkeit der Aktivitäten modellierbar.

Spezifikatioen

Softwaretechnik, Software Engineering:

"Bezeichnet das geplante, systematische Vorgehen bei der Softwareentwicklung unter Anwendung von Methoden, Verfahren und Softwarewerkzeugen mit dem Ziel, qualitativ hochwertige Softwareprodukte wirtschaftlich herzustellen und zu nutzen."

Welche Rolle spielen Spezifikationen in der Software-Entwicklung?

Welche Eigenschaften sollte eine Spezifikation haben?

Qualitätsmerkmale einer Spezifikation
  1. Konsistenz (keine Widersprüche)
  2. Komplettheit (alle benötigten Anforderungen)
  3. Klar und deutlich (alle benutzten Wörter erklären und definieren)
  4. eindeutig und verständlich

Wie unterscheidet sich eine operationelle von einer deskriptiven Spezifikation?

Data Flow Diagramme beschreiben Operationen aber nicht die benutzten Datenstrukturen oder Relationen. Ein Prototyp ist ein operationales Modell

Wie formal werden Spezifikationen formuliert?

Informal (normale Sprache), semiformal (präzise Syntax aber unpräzise Semantik) oder Formal (präzise Syntax und Semantik).

Was ist die Verifikation einer Spezifikation?

ER-Modell

Entities (Objekttypen), Beziehungen und Attribute (Objekteigenschaften)

Logische Spezifikation

Entwicklungszyklus
Quelle: Uni Münster

Logisches Prototyping - Methoden, Probleme

Algebraische Spezifikation - wie beschreibt man die Syntax?

Elemente (Char, Nat, Bool) und Operationen (Funktionen der Algebra wie new, append, add, lenght, isEmpty...)

Eine algebraische Spezifikation ist die operationale Modellierung auf der Grundlage einer Algebra.

Bsp: Algebraische Spezifikation eines Stacks

Algebraische Spezifikation

Quelle: Uni Zürich

Algebraische Spezifikation - wie beschreibt man die Semantik?

Axiome der Algebra, welche immer Wahr sein müssen.

Algebraische Spezifikation - Probleme

Unvollständig, Überspezifizierung, Widersprüchlich, Redundanz

Kapitel 5 - Entwurfsprozess

Entwurf

Ziel des Entwurfs

"Umwandlung der während der Analysephase gewonnenen Anforderungsspezifikation in die Architektur des künftigen Software-Produkts."

Dient später als Vorlage für Implementierung...

Entwurf - Ziele, Struktur und Prozess

Auf welche möglichen künftigen Änderungen soll im Entwurf vorgegriffen werden?

Änderungen im Algorithmus, Datenrepräsentation, Perepheriegeräte oder sozialem Umfeld

Was sind Patterns?

Sich wiederholende Muster, welche erkannt werden müssen, um Templates einsetzen zu können. Eine Pattern-Beschreibung enthält immer Kontext, Problem und Lösung.

Was ist eine Softwarearchitektur?

Motivation:

Welche Patterns werden in der Softwarearchitektur benutzt (Beispiele)?

Modularisierung

Was ist ein Modul (Programmbaustein)

Modularisierung - USES, IS_USED, IS_COMPONENT_OF

Wie kommunizieren Module (Klassifikation von Moduln)?

Schnittstelle - EXPORTED, IMPORTED, Entwurf

Eine Schnittstelle sollte nur das nötigste so kurz wie möglich anbieten

  1. sonst zu komplex und unverständlich
  2. sonst Fehleranfälligkeit in Implementierung
  3. zu viele Informationen könnten missbraucht werden

Notation des Modulentwurfs

Was ist ein generisches Modul oder Unterprogramm?

Mit Hilfe der generischen Module können mächtige und wiederverwendbare Programmteile produziert werden. Dabei werden Module, die eine ähnliche Leistung liefern und sich nur im Interface in den Typen und den exportierten Funktionen unterscheiden, durch einen höheren Abstraktionsgrad mit Hilfe generischer Module realisiert.

Dazu werden die variierenden Bereiche alle in einem Modul gesammelt und abstrahiert. Durch die dadurch entstehenden generischen Module können Inkonsistenzen in Modulen vermieden werden und sie sind leicht änderbar. Ein generisches Modul wird in bezug auf einen Typ parametrisiert - man spricht auch voneiner Programmschablone.

Ein Client kann so ein generisches Modul nicht direkt nutzen, dazu muss es erst mit den aktuellen Parametern instantiiert werden.

Schrittweises Vorgehen und Verfeinern - Vorteile, Nachteile

Probleme:
  1. bei großen Programmen schlecht umsetzbar
  2. führt nicht immer zur besten Lösung
  3. Entwurf ist ein kreativer Prozess, der so nicht umgangen werden kann
  4. entdecken anderer Lösungen bleibt so oft auf der Strecke
Nachteile:
  1. Unterprobleme werden isoliert betrachtet, deshalb keine Generalisierung möglich
  2. kaum eine Wiederverwendbarkeit
  3. keine Vereinigung mehrerer Subproblems
  4. kein Information Hiding, da keine Kapselung
  5. falls sich was in Struktur ändern, muss alles überarbeitet werden

Bearbeitung von Anomalien - Ausnahmen

Verifikation und Tests

Verifikation, kleine Programme, große Systeme, Ansätze

Testen - Problem von Kontinuität

Theoretische Probleme des Testens, vollständiges Testauswahlkriterium

Empirisches Testen

Unterschiede zwischen White-Box-Testen und Black-Box-Testen

Abdeckung von Anweisungen, Kanten, Bedingungen, Pfaden

Syntaxgesteuertes Testen, Testen von Grenzwerten

Testen im Großen, Bottom-Up-Integration und Top-Down-Integration, Vorteile, Nachteile

Modultests zum verifizieren der korrekten Implementierung

Integration Tests verifizieren die Zusammenarbeit der beteiligten Module

System Tests prüfen das gesamte System mit allen Modulen

Was ist Debugging?

Entwurf der Benutzerschnittstelle

Das UI ist Maßstab nach dem Systeme von Nutzern bewertet werden. Falls Software schwer benutzbar:

Verwendet werden Highresolution Graphic Displays, Maus und verschiedene Schnittstellen für verschiedene Nutzerklassen

Konsistenz der Benutzerschnittstelle

System Kommandos, Menüs und andere Oberflächen sollten

Eingebaute HELP-Unterstützung

Schablonen für Benutzerschnittstelle

Es werden Metapher verwendet, welche einfach assoziierbar sind

WIMP-Schnittstelle

WIMP = Windows, Icons, Menues, Pointing (Mausklick)

Vorteile

Nachteile

Systeme mit Menü

Nachteile:

Graphische Schnittstelle

Textuelle Schnittstelle

Nachteile:

Entwurf von Fehlermeldungen

Anwendung von Farbmonitoren

Ist zwar neue Dimension, nützt aber blinden oder Farbblinden nichts und es gibt auch keine Standarts.

Tips:

Kapitel 6 - Prozessmodelle

Probleme der industriellen Softwareproduktion

Lebenszyklus eines Softwareprodukts

... - Aufgabenstellung - Entwicklung - Nutzung - Aufgabenstellung - ...

Deailiert z.B. durch Phasen des Wasserfallmodells

Software Produktionsprozess - Prozessmodelle

Code-and-Fix-Modell, Wasserfallmodell

Code-and-Fix-Modell und Softwarekrise

Software Krise

Software Engineering wurde geboren, um nach einem Ausweg aus diesen Problemen zu suchen

Softwarekrise:

"In verschiedenen Erscheinungsformen uns ständig begleitende Erscheinung, die ausdrückt, dass der zu leistende Aufwand für Softwareherstellung und -betrieb die dafür zur Verfügung stehenden Kräfte übersteigt oder in Kürze übersteigen wird."

Wasserfallmodell

  1. Machbarkeitsstudie
  2. Anforderungsspezifikation und -analyse
  3. Entwurf
  4. Coding und Modultests
  5. Implementation und System Tests
  6. Übergabe und Wartung
Nachteil ist der streng sequentielle Ablauf der Phasen.

Machbarkeitstudie

Kosten abschätzen und alternative Lösungen suchen.

Ziel:

Spezifikation und Analyse der Anforderungen

Notwendige Qualitätsmerkmale spezifizieren:

Beschreibt das "Was" umzusetzen ist, nicht das "Wie"!

Ziel: Anforderungsspezifikation (Pflichtenheft)

Entwurf

Hier erfolgt die Dekomposition des Systems in Module. Die Entwurfsspezifikation beinhaltet

Codieren und Testen

Lieferung und Wartung

Wartung macht über 60% der Produktkosten aus:

Vor- und Nachteile des Wasserfallmodels

Evolutionäres Modell

Inkrementelles Modell für die Implementierung

Prototyping

Transformationsmodell

Softwareentwicklung hier eine Folge von Schritten, welche Spezfifikation in Implementation überführt. Die Transformationenen erfolgen Manuell oder Semi-automatisch.

Zwei Hauptschritte:

  1. Anforderungsanalyse (und Verifikation dieser)
  2. Optimierung (und Tuning an dieser)

Spiralmodell

Spiralmodell

Bewertung von Prozessmodellen

Prototyping:

Softwaremethodologien - Vorteile, Nachteile

Vorteile: Nachteile:

Comparison of Life Cycle Models

Comparison of Life Cycle Models
Build-and-Fix Fine for small programs that do not require much maintenance Totally unsatisfactorily for nontrivial programs
Waterfall Disciplined approach
Document driven
Delivered product may not meet client's needs
Rapid Prototyping Ensures that delivered product meets client's needs A need to build twice. Cannot always be used
Incremental Maximizes early return on investment.
Promotes maintainability
Requires open architecture.
May degenerate into buildand-fix.
Synchronize and stabilize Future user's needs are met.
Ensures components can be successfully integrated
Has not been widely used other than in Microsoft.
Spiral Incorporates features of all the above models Can be used only for largescale products.
Developers have to be competent at riskanalysis
Quelle: University Of California

Strukturierte Analyse und Entwurf


Qualitätskriterien für Entwicklung

Integration, Einsetzbarkeit, Adäquatheit, Erlernbarkeit Wiederverwendbarkeit , Werkzeugunterstützung und Wirtschaftlichkeit

Jacksons strukturierte Programmierung

Kapitel 7 - Configuration Management und CASE

Konfigurationsmanagement

Configurationmanagement

Teilung von Komponenten

Problem des Mehrfachzugriffes auf ein gemeinsamen Pool von Komponenten

Verwaltung von Produktfamilien

Lösungsmöglichkeiten

Versionierung

CASE-Werkzeuge - Vorteile, Nachteile

CASE Tools garantieren, daß nichts vergessen wird:

Nachteile:

Reverse-Engineering

Auswahl eines CASE-Werkzeugs

Architektur eines CASE-Werkzeugs

Technisches Management:

Projektabschätzung, Projektplanung, Planung des Personalbedarfs, Aufteilung und Zuweisung von Aufgaben, Projektsteuerung und -überwachung

Personalmanagement:

Personal einstellen, Mitarbeiter motivieren, die richtigen Leute den richtigen Aufgaben zuweisen

Projektmanagement - Ziele und Probleme

Projektmanager können sein

Allgemeine Aufgaben des Managements

Planung eines Projekts

Methoden der Projektabschätzung

3 Methoden

Methode der quantitativen Abschätzung

Methode der Abschätzung auf Basis der Erfahrung

Methode der Beschränkungen

Zeitplan eines Projekts (Scheduling)

Gantt-Diagramme

Nachteile:

PERT/CPM-Diagramme

Die "Kritischer Weg" - Methode mit einem gerichtetenr Graph mit: Nachteile:

Kritischer Weg

Kritischer Pfad ist ein Weg welcher aus Knoten besteht bei denen kein Buffer vorhanden (ECT == LCT)

Kosten-Nutzen-Analyse

Stragtegien:

Pay-back-Analyse

Return-and-Investment-Analyse

Present-value-Analyse

Kapitel 8 - Software-Metriken

Software-Metriken

Gründe fürs Messen

Direktes und indirektes Messen

Direktes Messen

Indirektes Messen

Kategorien von Software-Metriken

Größe-orientierte Metriken

Probleme:

Funktionsorientierte Metriken

Beispiel: (pro Messung ein Count und 3 Wichtungen, wie simple, average und complex)

Function-Points-Methode

Feature-Points-Methode

Nachteil:

Metriken und Sprachen

Abschätzungen wieviel LOF für einen Funktionspunkt durchschnittlich benötigt werden BSP:

Argumente für Software-Metriken

Ohne würde es keinen Anhaltspunkt geben, auf denen Verbesserungen entstehen können. Es sind Antworten auf folgende Fragen möglich:

Wie kann die Qualität von Software definiert werden?

Faktoren der Software-Qualität

Messen der Qualität

Testplan

Audit

Das Qualitätssicherspersonal prüft ob die Tests sinnvoll durchgeführt wurden.

Systematische, unabhängige Untersuchung, um festzustellen, ob die qualtitätsbezogenen Tätigkeiten und die damit zusammenhängenden Ergebnisse den geplanten Anordnungen entsprechen und ob diese Anordnungen wirkungsvoll verwirklicht und geeignet sind, die Ziele zu erreichen. [ISO 8402]

Software-Reviews

Kosten von Fehlern in der Software

Fehlervermehrung im Lauf der Softwareentwicklung

Qualitätszertifikat

Software-Metriken und Software-Qualität

BSP:

McCabe's zyklomatische Komplexität

Metriken für den Entwurf

Lokale Flüsse Globale Flüsse

Anwendung von Metriken

Kapitel 9 - Reengineering und Programmierungskonzepte

Legacy-Systeme - Charakteristik und Probleme

Probleme mit der veralteten Softwarearchitektur

Reengineering - wann und warum?

Methoden des Reengineerings

Source Code Translation Programm Neustrukturierung System Neustrukturierung Inkremental Evolution bei Systemersetzung weniger Riskobehaftet als Bing Bang

Wartung von Software - Ursachen, Methoden

Die Drei Arten der Wartung

  1. Korrigierende (Fehler beheben)
  2. Adaptive (neues Umfeld in HW/SW)
  3. Perfektive (neue Anforderungen)

Programmierungskonzepte

Generische Progammierung, Templates, Patterns und Frameworks...

Generische Progammierung und Templates

STL Library - die Idee

Patterns

Jedes Pattern besteht aus Arten von Patterns

Frameworks

Wiederverwendbar steigt, aber auch Nachteile:

Metaprogrammierung (generative Programmierung)

Adaptive Programmierung

Aspektorientierte Programmierung

Funktionalität ist bei OO in Klassen gekapselt

Problem:


Quellen

Petr Kroha
Softwaretechnologie
Prof. Kroha
Vorlesungsskript
L. Rosenhainer
Vorlesungsskript