1. Software Spezifikation Projektdefinition, Planung

2. Design und Implementierung Detailplanung

3. Software Validierung Überprüfung in Bezug auf Kundenwünsche

4. Software Evoluion Weiterentwicklung

1. Requirements (Anforderungen) - (user/customer view)

   Ewartungen von Kunde an Softwareprodukt

   Anforderungen müssen testbar sein und getestet werden!

2. Specification - (engineering view)

   Beschreibung für Implementierung

3. Planning (project management)

   Projektplan, berücksichtigt Zeit, Dauer, Kosten

4. Entwurf / Design

   Komponentenarchitektur (Komponenten, Packages, Datenbankdesign)

5. Implementierung (Erzeugung des Softwareprodukts) und Testen

6. Integration und Testen

   Zusammenfügen und testen (integration test) Test der einzelnen Komponenten (unit tests) auf Architektur- und Systemebene.

7. Operation and Maintenance (Einsatzphase)

   Unterstützung, Erweiterungen während laufenden Betriebes.

8. Retirement (Ende des Produktlebenszyklus)

   Softwareprodukt wird aus Betrieb genommen

Planung, Kontrolle, Steuerung, Organisation

Technische, finanzielle, planerische Aspekte

Überprüfung der Qualität (Qualitätssicherung QS) mit Verifikation / Validierung

• Test-Techniken

  • Unit Test

    Komponenten - Umsetzung technischer Spezifikation

  • Integrationstest

    Interfaces und Verbindungen zwischen Komponenten innerhalb des (Sub)Systems

  • Systemtest

    Gesamtsystem

  • Regressionstest

    Testen von geänderten Komponenten → Fehler, die durch Änderungen / Fehlerkorrektur, entstanden sind

  • Akzeptanztest

    ob Kunde akzeptiert

  • Installationstest

    während Installation

Erstellen die Anforderungen

1. Kunden (bezahlen software-produkt)

   Anforderung: z.B. schnelle und kostengünstige Lieferung

2. Anwender (benutzen)

   Anforderung: z.B.: Usability, Einfachheit, Stabilität, usw.

3. Entwickler (erstellen)

Gemeinsames Verständnis zwischen Stakeholders (Kunde/Anwender, Entwickler, usw.) und Entwickler.

Entweder beschrieben oder grafisch dargestellt (UML Diagramm).

Müssen testbar sein (tools: requirements management mit z.B. Doors, Rational Requisite Pro)

Anforderungs-Phase (Requirements-Definition)

Anforderungs-Analyse und Spezifikation

In der Praxis ändern sich Anforderungen häufig → Agiler Ansatz

Funktional Systemverhalten, Datenformate

Nicht-Funktional Qualitätsmerkmale, zB Leistungsfähigkeit, UI, Sicherheit

Design-Bedingung techn. Rahmenbed., Software Architektur, IDE, verteilte Entwicklung

Prozess-Bedingung Rahmenbedingungen für Vorgehen (Vorgehensmodelle)

Vorgehensmodell für Erhebung von Anforderungen.

Vollständige Erhebung von allen Rollen / Stakeholdern, Prioritisierung, Überprüfung

Phasen:

$\cdot$ Netzpläne / Pert-Diagramme → stellt Abhängigkeiten dar

$\cdot$ Work-Breakdown-Structure WBS / Projektstrukturplan → Aufteilung in Organisationseinheiten

$\cdot$ GANTT → Zeitliche Abfolge und Daue

$\cdot$ Milestone-Trend-Analysis MTA → setzt Meilensteine und Termine

Entwurf grobe Planung, grobe Architektur, zB Datenbankmodell skizzieren

Design Grobentwürfe werden im Detail ausgearbeitet

$\cdot$ Definition von Architektur, Komponenten, Interfaces, usw → Architecture Tradeoff Analysis Method ATAM um zwischen den Architekturen zu wählen.

$\cdot$ Test und Dokumentations-Anforderungen

Sicht (view) beschreibt Teil der Architektur mit UML diagramm

1. Abstraktion

2. Kapselung

3. Trennung von Schnittstelle und Implementierung

4. Dekomposition, Modularisierung

5. Balance zwischen Kopplung (äußere Abhängigkeit) und Kohäsion (innerer Zusammenhalt)

   Coupling (Kopplung) vs Cohesion (Bindung)

   $\uparrow$ Coupling = $\uparrow$ Abhängigkeit zwischen Komponenten

   Coheison = innerer Zusammenhalt in einer Komponente. Unabhängigkeit.

   Ziel: Balance

   UML: Sequence- und Collaboration Diagramms

6. Zentrale vs. verteilte Kontrolle

   fork = zentral

   Anpassung nur an wenigen Objekten nötig - leichtere Wartbarkeit

   Hohe Abhängigkeit Systems von diesem Objekt

   Wiederverwendung von Datenobjekten leichter

   stair = verteilt / dezentral

   Schrittweise Ausführung von Funktionen, dadurch wechselt die Kontrolle - schwierigere Wartung

   Bessere Wiederverwendbarkeit der Methoden z.B. durch Vererbung

   Ausfall eines Teiles nicht so schlimm

   Hohe Fehleranfälligkeit

• Komponenten Diagramm

  Komponente = logischer Teil / Implementierung der Schnittstelle

• Klassen Diagramm

• Zustands Diagramm / Aktivitätsdiagramm

• Datenbankmodell → Extended Entity Relationship Diagramm EER

• GUI Design

• Tests auf System und Integrations Ebene

Gemeinsame Normen, Regelungen

• Nationale & Internationale Standards

• Unternehmensweite Standards

• Projektspezifische Standards

Vorgaben für

• Dokumentationen

• Namenskonventionen

• Formatierungsrichtlinien

• Versionierungen

  Überblick aller (Teil-)Produkte innerhalb eines Projektes und die Verwendung der letztgültigen Versionen

• Headerblocks in Komponenten (code headers)

• Kommunikationsprotokolle (Nachricht Format und Inhalt)

• Programmiersprachen (Syntax, Semantik)

• Werkzeuge (Notation wie UML)

Namenskonventionen

Formatierung

Dokumentations / Formatierungsrichtlinien

Kommentare und Headerblocks

Sinnvolle commit-Nachrichten

Rückverfolgbarkeit durch gesamten Entwicklungszyklus - Änderungsverfolgung

Informationen aus dem Headerblock → automatisiertes Requirements Tracing z.B. in IDEs

1. Zeitlich

   Unterschiedliche releases, versionen

2. Vertikal

   Beziehungen eines Artefakttyps: z.B. System – Subsystem – Komponente.

3. Horizontal

   Beziehungen von Entwicklungsartefakten: z.B. Anforderungen – Implementierung – Testfälle

Zusammenbauen der Komponenten zu einem größeren Teilsystem / System

Integrationstest auf Architekturebene

Integrationsstrategien

Testberichte (auch Regressionstests = Tests nach Korrekturen)

1. Standard Software breiter Markt, viele Beta-Tests

2. Individual Software formeller Abnahmetest durch Auftraggeber

Akzeptanztest durch Auftraggeber

Komplette Übergabe aller Dokumentationen

Process-View

Activity-View

Phase-Oriented-View

korrektive Wartung (Correction) → Fehlerbeseitigung

Erweiterungen (Enhancement)

Reaktiv → durch Anwender / Kunde angestoßen, Änderungswunsch

Proaktiv → bevor angestoßen wurde

• Detailierter

  1. Reaktive Wartung
     1. Korrektiv (Corrective): Bug- und Fehlerkorrektur (patches, workarounds, updates).
     2. Adaptiv (Adaptive): Anpassung an neuen Anforderungen (Hardware, Softwareänderungen).

  2. Pro-Aktive Wartung
     1. Verbesserung (Perfective): Erweiterungen, Verbesserung der Effizienz.
     2. Vorbeugend (Preventive): Verbesserung für zukünftige Wartung (z.B. Ergänzung der Dokumentation).

Mehr als 80 % der Wartungsarbeiten für nichtkorrektive Tätigkeiten benutzt.

Change requests vom Kunden

Daten aus Issue tracking System

Ende der Betriebsphase (Betrieb + Wartung): Stilllegung des Softwareproduktes.

Kontrolliertes Außer-Betrieb-Setzen - Übergang zu Nachfolgeprodukt

Gründe:

Definition der Anforderungen → Inbetriebnahme bei Kunden

Wann sollte welche Software bis zu welchem Freistellungsgrad verfügbar sein?

Ablaufplan, Notwendig bei größeren Projekten

1. Konstruktive Methoden

   Software Produkte machen für: z.B. Spezifikation, Code, Testfälle, Protokolle

2. Analytische Methoden

   Qualitätsüberprüfung: z.B. Reviews, Inspektionen, Tests