VO 8

• vollständig sequentiell

• erlaubt Rückwärtsschritt von einer Phase auf den direkten Vorgänger

• Arbeitsschritt kann erst dann abgeschlossen, wenn alle vorgesehenen Produkte fertig gestellt

• Als Risikoreich betrachtet -> entwicklung von iterativen Modellen

• Korrelierende Phasen

• Validierung und Verifikation

Sie erfolgt inkrementell:

1. Abgrenzung der Gesamtfunktionalität & Priorisierung der einzelnen Funktionen

2. Zuordnung von Funktionen gemäß ihrer Priorität zu Ausbaustufen

3. Ergebnis der Stufe Enanwendern zur Verfügung gestellt

-> Umfang des Systems wächst ausgehend von der Basisfunktion stetig an

• Skalierbarkeit der Projektgrößen

  reduzierte Menge an Aktivitäten und Produkte für kleinere Projekte

• Mehr Orientierung Richtung agilem Vorgehen

  keine Vorschriften über die zeitliche Abfolge von Vorgehensbausteinen

• Iterativ aufgebaut

  (Berücksichtigt die möglichen Projektrisiken der sequentiellen Entwicklung)

• Vier Phasen

  (Die mehrmals durchlaufen werden)

1. Definition von Zielen

2. Risikoanalyse

3. Durchführen der Arbeitsschritte

4. Planen der nächsten Phase

-> Anzahl der Durchläufe von auftretenden Risiken abhängig

• Iterative Entwicklung von Software

• Management von Anforderungen

• Verwendung von komponentenbasierten Architekturen

• Visuelle Modellierung von Software (UML)

• Prüfung der Qualität von Software

• Kontrolliertes einbringen von Änderungen

Eine selektive Adaption von RUP für jedes Projekt/Organisation

Das Tool IBM Rational Method Composer

• Detailliertes Anpassen an spezifische Gegebenheiten

• Erzeugen eines komplett eigenen Modells

• Mischen mit anderen Prozessmodellen

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Ein von Personen geprägtes Prozessmodell

• hohe Produktivität und Anpassungsfähigkeit

• wenig Risiko und Ungewissheit

• größerer Komfort für die Projektmitglieder

Innerhalb eines Sprints wird versucht, so schnell wie möglich zum zuvor definierten Sprint Goal zu kommen.

Ein Meeting das immer zur selben Zeit am selben Ort statt findet

Eine nach Dringlichkeit geordnete Liste aller Anforderungen Die von allen Projektbeteiligten jederzeit eingesehen werden kann

Bei Scrum entsteht ein Softwareprodukt in Inkrementen, wobei schon der erste, aber spätestens der zweite Sprint ein lauffähiges Softwaresystem (mit Kernfunktionalität) liefert

Ein Diagramm in dem vom Scrum Master tagesaktuelle Aufwandsschätzungen für den aktuellen Sprint eingetragen

• Product Owner

• Scrum Team

• Scrum Master

• die Erstellung und Priorisierung des Product & Release Backlogs

• Team frei von Störungen und Unterbrechungen halten

• Umsetzung der über den Sprint Backlog geforderten Funktionalität

• Erreichung des Sprint Goals

• Die Dynamik von Scrum zur ungestörten Entfaltung zu bringen

• Auf die Umsetzung der Grundsätze und Regeln von Scrum achten

• Das Team von äußeren Einflüssen abschotten

Eine kompakte Methode zur Entwicklung von Software in kleinen bis mittelgroßen Teams, deren Arbeit vagen oder sich rasch ändernden Anforderungen unterliegt

Das termingerechte Abliefern von auftragsgemäßer Software

• Kommunikation

• Einfachheit

• Feedback

• Mut

  zur Offenheit und Transparenz/ notwendigen Änderungen

• Respekt

  vor sich selbst, dem Team und dem Produkt

Zusätzliche Feedbackschleifen über XP-Techniken:

• Pair Programming

• Code Reviews

• Continous Integration

Ursprünglich aus der Automobilindustrie (1978 Toyota Production System – Just in Time Production)

Es gibt keine vorgeschriebenen Rollen, Meetings, Artefakte, außer:

• Kontinuierlichen “Pull” Workflow

• Das Kanbandboard

• Ein Work in Progress Limit

z.B.: Für Softwareentwicklungsprojekte mit einer raschen time-to-market

• Teamstruktur (Personnel)

• Dynamik der Anforderungen (Dynamism)

• Entwicklungskultur (Culture)

• Teamgröße (Size)

• Kritikalität (Criticality)

die Qualifikation des Teams bzw. der beteiligten Personen beim Einsatz agiler Methoden höher sein muss als beim Einsatz plangetriebener Methoden.

Je häufiger Anforderungen geändert werden, desto einfacher muss dies möglich sein.

Je nach organisatorischem Umfeld bzw. Entwicklungskultur können agile Methoden eingesetzt werden.

Agile Methoden sind in kleinen bis mittelgroßen Teams effizient einsetzbar

Wenn Menschenleben von einem Softwaresystem abhängig sind, werden natürlich viel höhere Maßstäbe an die rigorose Prüfung und Nachvollziehbarkeit auf allen Ebenen gelegt.

• Funktionalität

• Zuverlässigkeit

• Benutzbarkeit

• Effizienz

• Änderbarkeit

• Übertragbarkeit

• Anforderungen:

  • Fehlerhafte Definitionen in den Anforderungsdokumenten

  • Falsche Interpretation von Kundenanforderungen

• Designdokumente:

  • Logische Designfehler

  • Fehlinterpretationen des Designdokuments

• Fehler bei der Test-Datenauswahl

• Nichteinhaltung von Coding Standards

Aus den Herstellungskosten und den Qualitätskosten

Analytische Aktivitäten zur Prüfung eines Testobjektes, ohne dass dieses dynamisch ausgeführt wird

Bereits sehr früh im Projektlebenszyklus möglich, noch bevor ausführbarer Code zur Verfügung steht

Die innere Qualität kann ermittelt werden.

-> Basis einer Strukturanalyse sind Abhängigkeitsgraphen und Qualitätsmetriken

• Analytische Aktivitäten zur Prüfung eines Testobjektes

• Statische Codeanalysen

• Strukturanalyse

• Überprüfung der Einhaltung von Entwicklungsrichtlinien

• Fehlermusteranalyse

Sie ermöglichen, die Qualität von Software zu interpretieren

Um quantitative Daten des Softwareentwicklungsprozesses

z.B.: wie schnell werden Fehler im Prozess entdeckt/ welchen Aufwand verursachen sie

Die Software oder Teile davon selbst:

• Umfangsmetrik: Lines of Code (LOC)

• Entwurfsqualität: Modularität, Kopplung,...

• Produktqualität: Testergebnisse, Testabdeckung,...

Als eine formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen Überprüfung eines Produktteils

Grundsätzlich können alle Entwicklungsergebnisse mit Reviews geprüft werden

• Frühe Durchführung möglich (No Test-cases needed)

• Verkürzung der Latenzzeit eines Fehlers

• Kosten für Behebung des Fehlers geringer (kompensieren den Review-Aufwand)

• Manager

• Moderator oder Review-Leiter

• Schreiber

• Autor

• Gutachter/ Reviewer

• Leser

Projektleiter, der den Auftrag zur Erstellung des Testobjektes gegeben hat und sich für die Freigabe verantwortlich zeichnet.

plant, organisiert und leitet das Review

-> sucht Teilnehmer aus, stellt die benötigten Unterlagen des Softwareelements bereit und organisiert die Review-Sitzung

notiert alle während der Sitzung anfallenden Erkenntnisse des Review-Teams in einem Protokoll

Er ist der Urheber des Testobjektes oder Repräsentant des Teams, das das Testobjekt erstellt hat

Hat die Aufgabe das zuprüfende Material in der Vorbereitung zu begutachten und in der Sitzung über ihre Erfahrungen zu berichten

• Aufbereitung der zu prüfenden Softwareelemente

• Zeitlich angemessene Durchführung der Sitzung

• Stellungnahme

• Walkthrough

• Technisches Review

• Inspektion

• Round Robin Review

• Peer Review

1. Autor stellt Kopien zur Verfügung

2. Kollegen begutachten die Unterlagen und retournieren die Papiere mehr oder weniger ausführlich kommentiert

3. Autor analysiert Stellungnahmen und korrigiert Arbeit

• Weniger formell

• Regt Diskussionen an

Beurteilung der beabsichtigten Verwendung und die Identifikation von Abweichungen von der Spezifikation

-> ähnlich der Inspektion

• Formellstes/ Wirkungsvollstes Verfahren

• Finden und die Identifikation von Anomalien im Source-Code

• Softwareelement auf die Erfüllung seiner Spezifikation und die Einhaltung von Richtlinien und Standards untersucht

Gutachter erhalten abwechselnd die Möglichkeit, die Führungsrolle zu

übernehmen (verschiedene Testobjekte)

• Prozess nicht definiert

• Keine speziellen Techniken zur Fehlersuche

• Ad-hoc zusammengstelltes Team

• Selbstbstimmung bei Aufgabenaufteilung und Vorgehensweise

Das Systemverhalten gegenüber dem spezifizierten Verhalten während der Laufzeit

das System wird mit Testdaten ausgeführt und beobachtet

• Untersuchung der Interaktion von verschiedenen Komponenten

• Ausführung des Programms mit zB Debuggern

• Progamm-Trace

• Informationen wo Unregelmäßigkeiten aufgetreten

Bereitstellung von Infrastrukturkomponenten zur Vermeidung von Softwarefehlern oder zumindest zur Verringerung der Fehlerrate

Die Verbesserung einer Organisation auf allen Ebenen durch den gezielten Umgang mit der Ressource Wissen

• Fähigkeiten

• Erfahrungen

• Fertigkeiten

• Normen

• Routinen

Bei der Organisatorischen Qualitätssicherung:

• beinhaltet alle Softwareentwicklungsaktivitäten

• verwaltet sämtliche Objekte

  z.B. Spezifikationen, Dokumentationen

• steuert Versionslinien, Änderungsstände und Freigaben der „Configuration Items“

1. Objekt wird eingereicht.

2. Objekt wird identifiziert, versioniert und archiviert.

3. Objekt wird zur Prüfung freigegeben (Test, Review, ...)

4. Objekt wird freigegeben.

5. Änderung wird eingereicht.

6. Änderung wird veranlasst

• Sicherung von Vollständigkeit und Qualität von Dokumenten

• Einparung von Zeit bei Vorbereitung

• Erhöhte Effizienz und Effektivität

• Richtlinien und Hypothesen in Frageform

• Antwortbar mit ja oder nein

• aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität

• verbessern des wechselseitigen Verständnisses und der Koordination

• höhere Transparenz und Berechenbarkeit eines Qualitätssicherungssystems

• Zertifizierungs-Standards

• Assessmentstandards (Bewertungsstandards)

die Vergleichbarkeit und Qualität von Softwareprozessen im Rahmen der Vergabe an externe Lieferanten zu verbessern

Liefert eine Analyse des Ist-Zustandes eines Unternehmens und ist kein international anerkanntes Zertifikat wie ISO 9000-3

Es beurteilt die Fähigkeit einer Organisation, Software unter bestimmten Rahmenbedingungen erstellen zu können