Software Engineering SE

Software

Source Code

Software Engineering

systematische ingenierursmäßige Herstellung von Software nach dem "best-practice"

Qualitätsmaßstäbe wie in klassischen Ingenieurs-Disziplinen für große und komplexe Projekte

"no surprise software" - vorhersehbares Verhalten

Unterscheidung durch:

  1. Projektdauer
  1. Projektgröße
  1. Anwendungsdomäne
  1. Projektkomplexität

Größe von Software Projekten:

Klein 1-2 Personen, Anwendung und Datenbank am selben Rechner

Mittel 3-20 Personen, Anwendung und Datenbank auf unterschiedlichen Rechnern

Groß >20 Personen, international, verteilte Anwendung

Große Software Projekte sind schwierig:

Projekt-Arten

a) Wartungsprojekt

b) Migrationsprojekt

c) Projekt mit öffentlichen Ausschreibungen

d) Klassische Software-Entwicklungsprojekte

Produkt-Komplexität

Anzahl der Komponenten, Code-Zeilen

Größe, Domäne, Qualifikation des Teams, "cutting-edge-technologies" die nicht erprobt sind.

Anwendungs-Domäne / Problem-Domäne (ein Fachgebiet, ein Wissensgebiet) macht den größten Unterschied

Qualitätsmanagement

Capability Maturity Model Integrated CMMI

Norm für Bemessung der Software Engineering Qualität.

Reifegrade der Software Entwicklung - Welches Ausmaß an Management existiert?

  1. Level: ad hoc processes - Initial

    Sourcecode. Software nicht mehrfach anwendbar, nur für eine spezifische Aufgabe.

  1. Level: basic project management - Managed

    Wiederholbare anwendung mit Quality Assurance

  1. Level: process definition - Defined

    Das Level dass die meisten Unternehmen erreichen möchten

  1. Level: process measurement - Quantitatively managed
  1. Level: process control - Optimizing

Projekt-Typen

Komponenten eines Software Systems

UI - User Interface (Benutzer Schnittstelle)

APP - Application (Anwendung, Geschäftslogik)

OS - Operating System (Betriebssytem)

Produkt-Typen / Projekt-Typen

Bestimmt Schwerpunkt der Komponenten-Entwicklung

Design-Strategien - Software kaufen vs. selber entwickeln

Kaufen, wenn …

Anforderungen existieren

Anpassung leicht möglich ist (ausführliche Dokumentation + Support)

billiger als Eigenentwicklung.

Risiko minimieren

Kommerzielle Software vs. Eingebettete Systemen

Kaufen oder selbst Entwickeln?

Kaufen nicht billiger!

Risikofaktoren

  1. Unvollständige Anforderungen, Anwender nicht involviert
  1. Budget nicht ausreichend, Unrealistische Zeit- und Kostenpläne
  1. Keine Management Unterstützung, keine Planung
  1. Häufige Änderung der Anforderungen
  1. Qualitätsmängel bei extern vergebenen Komponenten / Aufgaben
  1. Projekt wird nicht mehr benötigt (wenn Produktion zu lange dauert)

Strukturierung des Entwicklungsprozesses

Beispiel: Online Shop / Katalog an dem man bestellen kann, Produkte in ein Warenkorb legt und verschickt

Produktbaumstruktur (PBS)

Anforderungen verfolgen

Überstimmen Anforderungen mit dem was Kunde will?

Früh Prototyp machen → validieren (vergleichen mit Anforderungen)

Eigenschaften von Anforderungen:

⋅\cdot Gültigkeit, Konsistenz, Vollständigkeit, Realismus

⋅\cdot Überprüfbarkeit, Verständlichkeit, Verfolgbarkeit, Anpassbarkeit

Priorisierung und Kontrolle

  1. Value-driven requirements

    Geschäftsfall-Analyse

  1. Shared-vision-driven requirements

    Stakeholder bewerten ständig Anforderungen

  1. change-driven requirements

    Skalierbarkeit

  1. risk-driven requirements

    Detailiertheit