Kapitel 2 - Eigenschaften und Prinzipien

Besondere Eigenschaften der Software als Produkt

• Leute denken Software wäre leicht anpassbar, was falsch ist
• Bei Entwicklung liegt Fokus auf SE, bei Produktion in anderen Branchen
• Ein Produkt ist nicht nur das was der Kunde erhält, sondern auch die Anforderungen, Design, Sourcen und Testdaten

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

• Ein Programm hält sich an die Spezifikation und deren Funktionen
• Daher muss Spezifikation vorhanden und korrekt sein
• Korrektheit ist also eine mathematische Eigenschaft, welche die Beziehung zwischen Spezifikation und software kennzeichnet

Zuverlässigkeit von Software

Robustheit von Software

• Robust gegen erwartete Ereignisse, wie Fehleingaben gehört zur Korrektheit
• Rubustheit hier heißt robust sein gegen unerwartete Ergeignisse, außerhalb der Spezifikation

Leistung von Software

• Ökonomisches Verhalten heißt das ein System effizient arbeitet
• es ist effizient, wenn es die Ressourcen des Computers wirtschaftlich ausnutzt
• In Bezug auf Geschwindigkeit und Speicherbedarf
• Über Monitoring messen um Bottlenecks zu entdecken
• Modell analysieren ist zwar billig aber unsauber
• Modelle simulieren ist teuer aber sauber
• Leistungstests müssen nach der Herausgabe der Erstversion abgeschlossenwerden, nicht vorher, da sich sonst einiges ändern kann

Benutzerfreundlichkeit von Software

• Ein Programm ist benutzerfreundlich, wenn seine Nutzer es einfach zu bedienend empfinden (subjektiv)
• Dabei muss auf unerfahrene (Menüs) und erfahrene Benutzer (commandline)geachtet werden
• Eingebettete Systeme haben kein UI
• Wichtig ist eine Standartisierung des User Interfaces, um Wiedererkennung zu fördern

Verifizierbarkeit von Software

• Ein Softwaresystem ist verifizierbar, wenn seine Eigenschaften einfach geprüft und verifiziert werden können
• Formale Analyse, Tests, Tracing und Debugging...

Wartbarkeit von Software

• Wartung nicht als Verschleißbeseitigung zu sehen, vielmehr als Änderungen
• Änderungen an Software ist extrem teuer und macht 60 % aller Kosten aus
• Software Evulotion ist die Folge
• Vorausdenken ist erforderlich! (Anticipation of changes)

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

Korrigierbarkeit von Software

• Fehler müssen leicht behebbar sein ohne großen Aufwand betreiben zu müssen
• Stellt auch ein Hauptdesignziehl dar
• Anzahl an Einzelteilen verringern und möglichsts Standartteile verwenden, da diese weniger Fehler enthalten

Erweiterbarkeit von Software (Wachstum, Evolution)

• Software Evolution, um neue Funktionen hinzuzufügen und alte zu ändern
• Erweiterbarkeit wird begünstigt durch Modularisierung

Wiederverwendbarkeit von Software

• Gibt an, wie einfach es ist, Teile des SW-Systems (evtl. mit geringen Änderungen) in anderen SW-Systemen wiederverwenden zu können
• Bibliotheken schaffen, welche man wiederverwenden kann
• Software Re-Use ist trotzdem selten
• Wiederverwendbare Komponenten sind auch viel teurer als die die es nicht sind

Portabilität von Software

• Software kann in verschiedenen Umgebungen laufen (Hardware, Software, OS)
• Es sollte daher eine minimale Konfiguration erfordern
• Strafe für Portabilität ist schlechteres Laufzeitverhalten, da nicht mehr so optimiert

Verständlichkeit von Software

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

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

Interoperabilität von Software

Produktivität der Software-Entwicklung

• Zeigt an, wieviel Qualität in welcher Zeitspanne hergestellt werden kann
• Effizienz heißt, das ein gutes hochqualitatives Produkt in kurzer Zeit hergestellt werden kann
• Produktion wiederverwendbarer Systeme senkt die Effizienz, da dies aufwendiger ist
• Produktivität ist schwer zu messen

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

• Probleme sind das Einschätzen von Zeitaufwand, Produktivität und setzen sinnvoller Milestones
• Anforderung vom Kunden wächst schneller, als diese Umsetzbar ist
• Lösung der Probleme durch inkrementelle Entwicklungsmethoden
• SW-Krise: SW-Produkte verspätet und fehlerhaft ausgeliefert

Sichtbarkeit

• Jeder Schritt wird klar dokumentiert
• In Anforderung und Spezifikation
• Einzelne Schritte und der Status des Projektes sind jederzeit verfügbar
• Externe Qualität (Präsentation des Status)
• Interne Qualität (ermöglicht den Programmieren eine genauere Abschätzung und Aufteilung ihrer Handlungen)
• = Pflege der Anforderungs-, Entwurfsspezifikation

Prinzipien des Entwurfs

• Prinzip des Filtern und Trennen
• Prinzip der Modularisierung
• Prinzip der Abstraktion
• Prinzip des Vorgriffs auf Änderungen
• Prinzip der Allgemeinheit
• Prinzip der Inkrementalität

Prinzip des Filtern und Trennen - Zerlegen von Komplexität

• Filtern und Trennen der relevantesten Kernpunkte
• Weglassen nicht benötigter Informationen
• Nur so kann auch Problem dekompositioniert werden (z.B. in Module)
• es ist oft leichter die Teilprobleme zu erfassen, als das Ganze

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

• Dekomposition des Problems in einzelne Module
• komplexe Systeme können in kleine Stücke oder Bausteine = Module aufgeteilt werden -> System ist modular
• Parallel bearbeitbar und testbar
• Kommunikation über eindeutige Schnittstelle
• Vertikale Modularität (jedes Modul in verschiedenen Abstraktionslevelsbeschrieben)
• Horizontale Modularität (Systembeschreibung auf selben Abstraktionsniveau)
• Trennung von Funktionsspezifikation (ER-Diagramme für Daten, DF-Diagramme für Funktionen, Petri-Netze für Steuerung)
• Modularisierung

• Unterteilen des ursprünglichen Problems in Teilprobleme, daraufhin
• rekursives Unterteilen der Teilprobleme (Top-Down) -> divide et impera

• Zusammensetzen des Systems aus elementaren, vorgefertigten Komponenten (Bottom-Up)

Prinzip der Abstraktion

• wichtige Dinge herausheben und Details ignorieren
• Einteilung in relevante, logische Teile
• möglicherweise viele verschiedene Abstraktionen ein- und derselben Realität: verschiedene Sichtweisen und Absichten
• Modelle: Abstraktionen der Realität

Prinzip des Vorgriff von Änderungen

1. neue Anforderungen werden gefunden
2. alte Anforderungen werden aktualisiert

• Werkzeuge zur Verwaltung der verschiedenen Versionen und Revisionen der Software und ihrer Dokumentation nötig
• Problem des Konfigurationsmanagements
• Anforderungen die der Kunde irgendwann mit hoher Wahrscheinlichkeit mal haben möchte oder Anforderungen, welche aus anderen Gründen, wie Änderungen im Umfeld etc. entstehen
• das System muss so programmiert werden, dass Änderungen leicht durchzuführen sind und nicht etwa das halbe System neu entworfen werden muss

Prinzip der Allgemeinheit / Allgemeingültigkeit

• Ähnlichkeiten entdecken und Generalisieren, d.h. Standards nutzen können
• Erhöht Wiederverwendtbarkeit und senkt kosten
• Ohne Generality würden ähnliche Module immer wieder neu entwickelt werden müssen

Prinzip der Inkrementalität

• Schrittweises Vorgehen, um Überblick zu behalten und Fehler zu verringern
• Ist ein evolutionärer Prozess
• "Alles auf einmal"-Methode bei großen Projekten nicht durchführbar deshalb schrittweises Vorgehen
• frühzeitiges Feedback vom Kunden: wichtig, da anfängliche Anforderungen evtl.nicht stabil sind oder nicht völlig verstanden wurden

Warum wird Software so oft geändert?

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