Gesamtes Fragenkatalog

Was ist ein Projekt? Durch welche Merkmale ist es definiert?
Definiert durch
- Einmaligkeit
- Kooperation mit anderen (Beteiligte)
- Festgelegtem Ziel (Erwartung an Qualität, Leistung)
- Beschränktem Budget (Ressourcen - personal, sachmittel, zeitliche)

Welche drei Kennzeichen hat ein Projekt?
1. Abgrenzbarkeit von: Aufgabe, Ergebnis, Ressourceneinsatz, Zeitrahmen
1. Komplexität der Aufgabe
1. Einmaligkeit der Aufgabe

Was ist Projektmanagement?
Management = getting things done by people
Projektmanagement = getting the project done
Gesamtheit von Methoden zur effizienteren Steuerung von Projekten.
Im engeren Sinne die Projektleitung → die für die Führung/Steuerung eines Projekts verantwortliche Person/Stelle.

Nennen Sie drei Stakeholder, die Einfluss auf die Anforderungen haben. Begründen Sie Ihre Antworten.
Stakeholder und ihr Einfluss auf Anforderungen:
- Kunde
  Hat die eigentliche Idee / Bedürfnis die durch das zu entwickelnde Produkt abgedeckt werden soll.
- Entwickler
  Wissen über technische (Un-)Möglichkeiten.
  Sie müssen die Vorstellung des Kunden technisch Bewerten, Beschreiben und Verwirklichen.
- Betreiber (Abteilung für Betriebs und Wartungsphase des Projekts)
  Will einen reibungslosen Betrieb, einfache Wartung.
- Management
  Ressourcenvergabe und Zeitplan.
- Konkurrent vom Kunden
  Kunde will sich von der Konkurrenz abheben, um am Markt zu bestehen.

5 typische Gründe warum ein Projekt den Zeit-/Kostenrahmen überschreitet
1. Nicht validierbare oder unvollständige Anforderungen
  Anforderungen ≠ Erfordernisse, unklar/mehrdeutig formuliert.
1. Mangelhafte Umsetzung der Anforderungen
  Anforderungen nicht verstanden, falsch umgesetzt, technische Mängel (Implementierung) oder Termin-Not und Ressourcenmangel.
1. Mängel im Projektmanagement
  Mangelhafte Kommunikation, unrealistische Termin- und Kostenrahmen oder Ressourcenmangel (Verfügbarkeit, Qualifikation, Erfahrung).
1. Kunde / Anwender nicht involviert
1. Sich ständig ändernde Anforderungen

Welches Vorgehen verwendet man in der Steuerung?
- Die Aufgabenstellung definieren
- Das Projekt planen
- Das Projekt(team) organisieren
- Aufgaben verteilen
- Den Projektfortschritt kontrollieren
- Bei Bedarf steuernd eingreifen
- Sich mit Risiken beschäftigen
- Entscheidungen vorbereiten und Entscheidungen fällen
- Bürokratische Dinge erledigen

Komponenten vom Projektauftrag
Schriftliche (Ziel)vereinbarung zwischen Auftraggeber und Auftragnehmer).
Voraussetzung dafür ist die Ausarbeitung eines Projektvorschlags.
Beinhaltet:
- Projektname
- Projektbeschreibung
- Rollen und Verantwortlichkeiten
- Ziele, Abgrenzung
- Projektplan (Zeit- und Kostenplan), Komponentendiagramm
- Umfeld- und Risikoanalyse
- Wiederverwendung von Komponenten, Technologiewahl
- Lieferumfang und Abnahme
- Nichtfunktionale Anforderungen (Skalierbarkeit, Performanz oder Verfügbarkeit)
- Arbeitsstruktur
- Informationswesen

Teufelsquadrat
Die vier angegebene Ziele des Quadrates konkurrieren um die verfügbare Produktivität, welche durch die Fläche des äußeren Vierecks dargestellt wird.
Aufgrund der Begrenzungen der Ressourcen ergibt sich automatisch eine Begrenzung der Produktivität, symbolisiert durch die Fläche des inneren Vierecks.
Man kann das Viereck in die eine oder andere Richtung strecken,muss dann allerdings einen geringerem Zielerfüllungsgrad auf der andere Seite hinnehmen.

Was verstehen Sie unter einem Projektstrukturplan?
Der Projektstrukturplan (PSP)
Projekt-Gliederung in Teilaufgaben und Arbeitspakete.
Teilaufgaben müssen weiter unterteilt werden.
Arbeitspakete können nicht mehr unterteilt werden.
Strukturierung der Arbeit
- Nach zweckmäßigen Kriterien - In angemessener Detailierung / Tiefe
Ist (die wichtigste) Planungsgrundlage für:
- Aufwandsschätzung - Ressourcenplanung (Know-How, Skills, ..) - Personaleinsatzplanung (wer mach was wann?)

Aus welchen Ebenen besteht ein Projektstrukturplan?
Projektstrukturplan PSP besteht aus 3 Ebenen:
• Projektname • Komponenten, Teilsysteme oder Teilprojekten • konkrete Arbeitspaketen
Je nach Betrachtungsweise (Gesamtsystem, Teilsystem, Komponente) können zusätzliche Ebenen nach Bedarf verwendet werden.

Skizzieren und erläutern Sie einen (i) funktions- bzw. aufgabenorientierten Projektstrukturplan (ii) objektorientierten Projektstrukturplan. Worin liegen die wesentlichen Unterschiede und wofür werden sie eingesetzt?
Allgemeiner Aufbau
Funktionsorientierter Projektstrukturplan
Bessere Übersicht über die verschiedensten Funktionen des Projektes
Tätigkeiten, Handlungen, Funktionen (FTH)
Aufgabenorientierter Projektstrukturplan
Planung auf Aufgabeebene
Phasen, Abläufe, Entwicklungsprozesse (APA)
Objektorientierter Projektstrukturplan
Objekte, Komponenten, Bauteile

Was versteht man unter einem Projekterfolg?
Abschließen eines Projektes unter 100%iger Zufriedenstellung und Abdeckung des Projektauftrages mit dem Kunden.
Der Kunde muss mit dem Projekt zufrieden sein, er muss damit arbeiten können.

Durch welche Rahmenbedingungen wird der Projekterfolg gefördert? Geben Sie für jede Rahmenbedingung zumindest ein konkretes Beispiel an.
Planung
• Zielvorgaben des Projekts, konkrete Anforderungen an das zu erstellende Produkt • Die Planung braucht Spielräume für Veränderungen
Kontrolle
• Finanzielle, zeitliche und personelle Restriktionen und deren Risiken • Erfüllung der geforderten Aspekte
Steuerung
• Auswahl von Artefakten • Einbettung von Teammitgliedern in die Organisation

Was sind die Aufgaben eines Teamkoordinators?
Der Projektleiter / Teamkoordinator hat die Projektverantwortung.
Aufgaben des Projektleiters
1. Projektablauf – was ist zu tun? (Start, Verfolgung, Abschluss)
1. Arbeitsstruktur – wer ist wofür zuständig?
1. Informationswesen – wer informiert wen, worüber, wann, wie?
Sowie:
- Aufgabenstellung definieren
- Risikomanagement
- Projektplanung, Team organisieren, Aufgaben verteilen
- Fortschritt kontrollieren, soll-ist Vergleich, eingreifen
- ...

Projektmanagement – Erfolgsfaktoren
- Einbringung und Berücksichtigung der Anwender - Adäquates Projektmanagement - Anforderungen müssen eindeutig beschrieben, realisierbar und auch überprüfbar sein - Flexibler, realistischer Projektplan, der mögl. Verzögerungen berücksichtigt - Realistische Kostenabschätzung und Budget, inkl. Risikoanalyse - Angemessene Ziele - Schlüsselteammitglieder haben genügend Projekterfahrung - Gute Teamarbeit, funktionierende Kommunikation im Team

Was verstehen Sie unter einem Projektstrukturplan (Work Breakdown Structure)? Aus welchen Ebenen besteht eine WBS?
1. Projektname
1. Unter- bzw. Teilsysteme (vgl. Architectural Releases)
1. einzelne Arbeitspakete

Was ist ein PERT Diagramm?
Netzplan: PERT-Diagramm

Unterschied zwischen Embedded Systems und kommerzieller Software anhand von fünf Kriterien vergleichen.

Kommerzielle Software zu kaufen günstiger als selbst zu programmieren, embedded Systems umgekehrt (wegen Neuentwicklung / Anpassung)

Kommerzielle Software priorisiert UI, Embedded Systems haben eine sehr minimale / keine UI

Komerzielle Software soll massentauglich und wartbar sein, embedded Systems müssen schnell und exakt sein (hohe Zuverlässigkeit)

Kommerzielle Software Benutzergesteuert, Embedded Systems Ereignisgesteuert

Kommerzeielle Software muss Sicher sein in Bezug auf Datenbanken etc, embedded Systems dürfen nicht ausfallen

Unterschied

Kriterium	Embedded Systems	Kommerzielle Software
Steuerung	Ereignisgesteuert, oft auch vollständig automatisiert	Benutzergesteuert
Kosten	Teuer, wegen Neuentwicklung oder Anpassung	Kaufen billiger als selber entwickeln
Zuverlässigkeit	Sehr wichtig	Oft nicht entscheidend
Wartung	Schwierig, z.T. Hardware-technisch unmöglich	Meist professioneller Support
Sicherheit	Müssen sicher sein (safety)	Unterschiedliche Wichtigkeit: Online-Banking, Datenbank Systeme vs. Photobearbeitung
Usability	Benutzerinterface rudimentär oder nicht vorhanden	Oft entscheidend, vor allem bei großer Konkurrenz
Beispiele	Handysteuerung, Lift-Steuerung, ABS-System, Ampel	Datenbanksystem, Web-Applikationen, Texteditor

Was sind die Unterschiede zwischen zentralen/verteilten Source Code Managern SCM? Nennen Sie jeweils Vor- und Nachteile
Verteilt (Dezentral)
$+$ auf mehreren Rechnern verteilt, dadurch sicherer
es gibt meistens eine „Main-Repository“ mit dem sich die Clients regelmäßig synchronisieren (pull, push, fetch, pull-request, etc.)
$+$ lokal arbeiten möglich.
Repository geklont und lokal auf jedem Client gespeichert, alle Operationen können lokal ausgeführt werden.
$-$ große Menge an Daten beim klonen auf dem Client gespeichert
$+$ schnelleres commiten, merge conflicts bei push oder pull
Arbeitsablauf Git
1. Kopie des Haupt-Repository (klonen) → nur 1x im gesamten Arbeitsablauf
1. Lokale Änderungen
1. Lokale Commits → keine konflikte, deshalb lokal commiten oft möglich
1. Merge → konflikte lösen
  Push
  Pull Request (requesting main branch to pull)
Zentral
$-$ source code nur auf einem Rechner mit dem ständig über einem Server abgeglichen wird.
Der Server ist ein „Single Point of Failure“ und ein Flaschenhals.
Operationen dauern lange (hohe Auslastung, Netzwerkverkehr).
$-$ arbeit lokal nicht möglich
$+$ clients brauchen keine lokalen versionen, brauchen weniger Speicherplatz
$-$ commiten langsamer da merge conflicts von commiter behoben werden müssen
Arbeitsablauf Subversion SVN
1. Update
1. Lokale Änderungen
1. Update → Man kann hier stecken bleiben und ständig updaten müssen
  Änderungen remote und lokal
  Merge → konflikte lokal lösen
1. Commit

Beschreiben Sie Inversion of Control (IOC)
Umkehrung des Kontrollflusses mit einem Hook .
Viele Varianten.
Hollywood Prinzip: "Dont call us, well call you"
Dependency Injection DI
Abhängigkeiten werden von einem Container verwaltet, die Komponenten wissen nichts darüber → Die Abhängigkeiten werden injiziert.
Eine der vielen Arten von IoC.
Konzept:
Die Verantwortung für das Erzeugen und Initialisieren von Objekten wird an eine zentrale Stelle (z.B. eine Klasse) delegiert.
Von der zentralen Stelle kann man die Abhängigkeiten zwischen den Objekten leichter überblicken und steuern.
Implementierung:
Eine Komponente wird über einem Pointer / einer Referenz aufgerufen die urprünglich nicht initialisiert ist.
Kann mit Konstruktor, Setter, Annotation initialisiert werden.
Vorteile:
- Hohe Wiederverwendbarkeit
- Einfaches Austauschen einer Implementierung
- Verwalten von verschiedenen Konfigurationen (dev vs. prod)
- Automatisiertes „verdrahten“, weniger Boilerplate-Code benötigt.
- Verteilung von Aufgaben
zB in Java Spring-Framework benutzt

Was sind die Aufgaben eines Sourcecode Management Systems (SCM)? Beschreiben Sie den Arbeitsablauf, wie bei verteilten SCM Systemen mit Konflikten umgegangen wird!
- parallele Projektentwicklung auf mehreren Zweigen
- transparente Änderungen
- nachvollziehbare Entwicklungsgeschichte
- Zugriff auf ältere Versionen
Arbeitsablauf Git
1. Kopie des Haupt-Repository (klonen) → nur 1x im gesamten Arbeitsablauf
1. Lokale Änderungen
1. Lokale Commits → keine konflikte, deshalb lokal commiten oft möglich
1. Merge → konflikte lösen
  Push
  Pull Request (requesting main branch to pull)
Arbeitsablauf Subversion SVN
1. Update
1. Lokale Änderungen
1. Update → Man kann hier stecken bleiben und ständig updaten müssen
  Änderungen remote und lokal
  Merge → konflikte lokal lösen
1. Commit

Was sind typische Herausforderungen bei global verteilten Entwicklungsteams? Welche Art von Kommunikation kommt hier hauptsächlich zum Einsatz? Nennen Sie hierfür vier verschiedene Beispiele.
- Große geographische distanzen → Kein Face-2-Face, Austauschen von Handzeichnungen erschwert
- Verschiedene Arbeitszeiten
- Verschiedene Zeitzonen
=> asynchrone Kommunikation
- Email
- Wiki, CMS
- Mailingliste/Forum
- Issue-Tracker

Skizzieren Sie den Software Life-Cycle.
Basiskonzept für Vorgehensmodelle.
1. Anforderungen und Spezifikation (Software Spezifikation)
1. Planung (Software Spezifikation & Design)
1. Entwurf und Design (Design & Implementierung)
1. Implementierung und Integration (Implementierung & Validierung)
1. Betrieb und Wartung (Validierung & Evolution)
1. Retirement (Evolution)

Beschreiben Sie Traceability. Welche Arten von Traceability gibt es?
Rückverfolgbarkeit einer Information durch den gesamten Entwicklungszyklus.
z.B. bei sicherheitskritischen Anwendungen gefordert.
Änderungsverfolgung
Anforderung → Entwicklungsartefakte
- Woher kommt eine Anforderung und wo wurde sie umgesetzt?
- Welche Artefakte sind von einer Änderung der Anforderung betroffen?
- Welche Anforderungen sind von einer Änderung der Umsetzung betroffen?
Informationen aus dem Headerblock → automatisiertes Requirements Tracing z.B. in IDEs
1. Zeitlich
  Unterschiedliche releases, versionen
1. Vertikal
  Beziehungen eines Artefakttyps: z.B. System – Subsystem – Komponente.
1. Horizontal
  Beziehungen von Entwicklungsartefakten: z.B. Anforderungen – Implementierung – Testfälle

Wie kann Traceability in einem Softwareprojekt umgesetzt werden?
Durch typische Fragestellungen:
- Woher kommt eine Anforderung und wo wurde sie umgesetzt? - Welche Artefakte sind von einer Änderung der Anforderung betroffen? - Welche Anforderungen sind von einer Änderung der Umsetzung betroffen?
Daraus ergeben sich folgende Vorteile:
- Nachvollziehbarkeit der Information bei Änderung - (Automatische) Benachrichtigung bei Änderung
Umsetzung kann automatisiert werden:
Informationen aus dem Headerblock können zur (automatisierten) Realisierung für Requirements Tracing eingesetzt werden (z.B. in IDE´s)

Welche Phasen umfasst der Wartungsprozess?
Gleich wie Life-Cycle Prozess

Nennen und beschreiben Sie unterschiedliche Sichten auf die Wartung
Process-View
Änderung des Software-Produkts nach Auslieferung (Delivery) und Inbetriebnahme (Deployment bzw. Product Launch).
Activity-View
Wartungs-Aufgabe
Phase-Oriented-View
Wartungsphase endet mit “Stilllegung” des Softwareproduktes.

Nennen Sie drei Techniken zur Wartung.
- Herstellen des Produktverständnisses
  KeyTools, Code-Browsers, klare und präzise Dokumentation.
- Reengineering / Refactoring
  Überprüfung und Überarbeitung des Software Codes.
- Reverse Engineering
  Analyse → meistens auf höheren Abstraktionsniveau z.B. UML-Modelle aus Code

Klassifizierung von Anforderungen
- Funktionale Anforderungen
  Datenformate, Feature, Verhalten vom System in bestimmten Situationen
- Nicht-Funktionale Anforderungen
  Leistung und Performance, Usability, Sicherheit, Warbarkeit
- Designbedingungen
  worauf soll beim technischen Entwurf geachtet werden
  z.B. Schnittstellen, Plattformen und Entwicklungsumgebung
- Prozessbedingungen
  Rahmenbedingungen im Softwareprojekt, z.B: Ressourcen / Dokumentation

5 essenzielle Nicht-Funktionale Anforderungen
- Leistung und Performance
- Usability und menschliche Faktoren
- Sicherheit
- Wartbarkeit
- Erweiterbarkeit

4+1 View Model of Architecture / Nennen und beschreiben Sie die unterschiedlichen Sichten auf die Architektur
Eine Sicht (view) beschreibt einen Teilaspekt der Architektur und des Designs und die jeweiligen Eigenschaften eines Systems.
1. Logical View
  Funktionale Anforderungen, Design Packages, Subsysteme, Klassen
  UML: Klassendiagramme, Package Diagrams ...
1. Implementation View
  Implementierung, Source Code
  UML: Component Diagram
1. Process View
  Nicht-funktionale Anforderungen, System-Integration
  Concurrency, Lastverteilung, Fehlertoleranz
  UML: Sequence, Activity Diagrams, Communication Diagrams
1. Deployment View
  Systems-Engineer: Deployment, Installation, Performance
  UML: Deployment Diagrams
1. Use-Case View
  Integration, Testen, Verifikation
  Schnittstelle zwischen allen vorherigen Sichten aus Architektur-Sicht
  beinhaltet Schlüsselszenarien (key scenarios) → Sicht der Geschäftsprozesse
  UML: Use Case Diagram + Beschreibung, Aktivitätsdiagramme

System Control (Stair vs Fork)
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

Blackbox/Whitebox Multiple Choice
Blackbox
Berücksichtigt nur Eingabe und Ausgabe, nicht interne Funktionalität
- Anforderungen/Spezifikation als Grundlage
- Data driven testing
- Unabhängig von der Realisierung der Module.
- Äquivalenzklassenbildung.
- Keine genaue Fehlerortung möglich
White box
Versucht jede interne Funktion anzusprechen und zu testen
- Sourcecode als Grundlage → Wissen über internen Aufbau notwendig.

Beschreiben Sie den Prozess des Testfallbestimmens. Was muss dokumentiert werden?
Testfall bestimmen nach Anforderungen
- Testdatum / Zeit
- Bezeichnung/ Beschreibung des Tests
- Testtyp
  Normalfall, Fehlerfall, Sonderfall
- Vorbedingung
  Eingabedaten, Zustand des System vor Testausführung.
- Eingabe
  Äquivalenzklasse
- Erwartete Ausgabe
- Erhaltene Ausgabe
- Erfolgreich / Nicht erfolgreich (OK / NOK)

Diskutieren Sie die Begriffe Validierung und Verifikation
Überpüfung der Produkte
1. Verifikation Ob Komponenten der (technischen) Spezifikation entsprechen
  Spezifikation vs. Umsetzung („Wurde das Produkt richtig entwickelt?“)
  Beispiel: Komponententests (Prüfung gegen die technische Spezifikation)
1. Validierung Ob Komponenten dem Kundenwunsch entsprechen
  Erwartung des Kunden vs. Umsetzung („Wurde das richtige Produkt entwickelt?“)
  Beispiel: Akzeptanz- und Abnahmetests (Prüfung gegen Anforderungen).

Was sind Äquivalenzklassen?
Hierbei werden die Eingabedaten in Klassen mit dem selben (äquivalenten) Verhalten eingeteilt und anschließend Repräsentant jeder Klasse für einen Testfall gewählt.
Testfälle müssen gültige (Normalfall, Sonderfall) UND ungültige Eingabewerte (Fehlerfall) berücksichtigen.

Was ist eine Grenzwertanalyse?
Spezialfall einer Äquivalenzklasse, bei welcher man die Repräsentanten um die Klassen-Grenzen wählt, da hier besonders leicht Fehler auftreten.

Beschreiben und skizzieren Sie den Ablauf eines Reviews
Produkt oder Dokument wird kommentiert und abgesegnet (approved).
formale Analyse- und qualitative Beurteilung
Reviewtypen
Unterschieden durch:
1. Vorgehensmodell Wahl
1. Einbeziehungs-Grad des Kunden
Hier: Phasenorientierte Vorgehensweise
Rollenverteilung
3-6 Personen die beteiligt sind.
> Moderator (keeper of process)
Leiter, bestimmt Ablauf, Auswertung, Korrektur
> Leser (keeper of focus and pace)
Ausarbeiter, bestimmt wie detailiert es sein sollte
> Schreiber (preserver of knowledge)
Protokolliert Ablauf
> Gutachter (Reviewer)
Erkennt Fehler nach Befehl von Moderator
> Autor (author)
Besitzer des Review-Objekts
Phasen
Wiederholungen sind möglich.
Oft werden Checklisten verwendet.
1. Planung („planning phase“)
  Objekt, Prüfziele
  Moderator erstellt Arbeitspakete / Checkliste
1. Initialisierung („initialisation phase“)
  Kontrolle ob Code kompiliert
1. Vorbereitung („preparation phase“)
  Einzeldurcharbeitung
  Bearbeitung, Fehler finden (Vorbereitung für die Sitzung)
1. Reviewsitzung („review“)
  Gemeinsam Lesen, Aufzeichnen von Mängeln (nicht Korrektur)
  1. Reviewsitzungen (2h)
    Moderator = Diskussionsleiter
    Alle beschließen gemeinsam welche Nacharbeiten notwendig sind.
  1. "Die dritte Stunde"
    Feedback an Review selbst
1. Sammlung im Team („meeting“)
1. Reviewbericht („reporting“)
  Schreiber protokolliert nach Sitzung
1. Nacharbeit („re-work)
  Review selbst bewerten
  Autor bekommt Feedback und muss Fehler ausbessern.
  Moderator prüft ob ausgebessert wurde
Alternativerweise (lt. Folien):
1. Planung
1. Vorbesprechung
1. Individuelle Vorbereitung
1. Review-Sitzung
1. Nachbearbeitung
1. Bewertung

Welche Qualitätskriterien gibt es in der Softwareentwicklung?
Qualitätssicherung = Durchführung von Verifikation und Validierung in jeder Phase der Software-Herstellung
- Testbare Anforderungen
- Verfolgbare Entwicklung der Anforderungen (mit Modellen) in testbare Produkte.
- Leistung und Performance (z.B. Optimierung des Informationsflusses)
- UI, UX (z.B. Einfachheit der Bedienung, Training)
- Sicherheit (z.B. Zugangskontrolle)
- Wartbarkeit (Trennung von Anwendung und Daten)
- Erweiterbarkeit (z.B. wie Aufwändig ist es ein zusätzliches Modul dem Projekt hinzuzufügen)

Was ist ein Software Review und wozu dient er?
Was ist ein Review?
Produkt oder Dokument wird kommentiert und abgesegnet (approved).
formale Analyse- und qualitative Beurteilung
Wozu dienen Reviews?
qualitativen Beurteilung von Produkten und Prozessen die quantitativ nur schwer oder gar nicht beurteilt werden können (z.B. Modelle, Dokumente)

Welche Arten von Reviews kennen Sie? Erläutern Sie die wesentlichen Aspekte der einzelnen Reviewarten und geben Sie jeweils ein konkretes Beispiel an.
Zu Reviews verwandte Tätigkeiten
Inspektion
Behebung von konkreten Mängeln
Leser ≠ Autor
Spezielle Art von Reviews → "Blick durch Mikroskop"
Höhere Formalisierung.
Lesetechniken die die Fehlerfindung verbessern sollen.
Walkthrough
Behebung von konkreten Mängeln Autor = Leser & Moderator
Audit
Überblickende Kontrolle durch externe Personen
Arten von Reviews
Mit Kunde
SRR - Software Requirements Review
Nach Anforderungsphase.
Review der Anforderungen mit Kunden vor Entwurfs und Design-Phase.
PDR - Preliminary Design Review (Preliminary Design = Vorentwurfsplanung)
Während der Entwurfsphase.
Review der Software-Architektur vor Ausarbeitung im Detail und Kontrolle der Übereinstimmung mit Anforderungen.
CDR - Critical Design Review
Meistens gleichzeitig mit PDR.
Bei besonders kritischen / wichtigen Komponenten, während Entwurf und Design-Phase.
Vor allem in: phasenorientierte, strikt sequenzielle Prozessmodelle → letztmögliche Zeitpunkt, an dem der Kunde das Projekt noch stoppen kann.
IPR - In-Process Reviews
Für sehr große und komplexe Projekte die lange dauern → Kunden Fortschritte in der Implementierung, Prototypen, Testfälle vorlegen.
= kontinuierliche Reviews in agilen Prozessen
Ohne Kunde
MR - Management Review
Bewertung des Projekts, aktueller Projektstatus.
Bei Abweichungen / geänderten Projektzielen steuern.
TR - Technical Review
konkreten Teil der überprüfen und bewerten.
Verifikation (vergleich mit Spezifikation oder Standards).
Auch Fehlersuche.
Kann Bestandteil des Prozesses sein.
Code-Walk-Through
Autor stellt seine Module ablauforientiert vor.
Kontrolle von Implementierungs-Qualität.
Verbesserungsvorschläge einholen.
Neue Mitarbeiter einführen.
Inspektion
formales Review, speziell in frühen Phasen der Entwicklung.
Suche nach schweren Fehlern
IRP (integrierter Review-Prozess)
Nach "pull request".
Diskussion zB nach einem request ein commit in die main branch zu pullen.

Welche Rollen finden sich typischerweise bei Reviews und welche Aufgaben nehmen die unterschiedlichen Rollen wahr?
Rollenverteilung
3-6 Personen die beteiligt sind.
> Moderator (keeper of process)
Leiter, bestimmt Ablauf, Auswertung, Korrektur
> Leser (keeper of focus and pace)
Ausarbeiter, bestimmt wie detailiert es sein sollte
> Schreiber (preserver of knowledge)
Protokolliert Ablauf
> Gutachter (Reviewer)
Erkennt Fehler nach Befehl von Moderator
> Autor (author)
Besitzer des Review-Objekts

Test Driven Development TDD
Entwicklungs- und Designparadigma: Testen von Programmkomponenten dazu verwendet, den gesamten Prozess der Softwareentwicklung zu leiten.
Setzt keine Implementierung voraus.
Automatisiert.
Fixer Bestandteil von den meisten agilen Vorgehensmodellen.
TDD wird meist im Rahmen agiler Methoden und insbesondere beim Extreme Programming verwendet.
Ablauf
1. Think
  Spezifikation / Definition des Tests
1. Red (Fehlgeschlagen)
  Ausführung des Tests → zu testende Klasse existiert nicht
1. Green (Erfolgreich)
  Implementierung der zu testenden Klasse oder Komponent.
  Versuchen status "green" zu erreichen.
1. Refactor
  Nach einer Abänderung / Korrektur muss wieder sichergestellt werden dass der status "grün" ist.

Continuous Integration (CI) beschreiben und skizzieren
CI ist eine best practice für das Nutzen des automatisierten build management Systems (zb maven)
Automatisiertes: Builden, Testen, Integration, Deployment
- nur ein einziges Sourcecode-Repository verfügen, mit dem alle Entwickler arbeiten.
- Ablauf möglichst schnell
- Mindestens 1x täglich committen auf neutralem Rechner → "daily builds"
  „neutraler“ CI-Server automatisiert Build und Tests bei jeder Änderung im SCM-System
  Build-Automatisierungswerkzeuge:
  Entwicklerorientiert: Maven
  Server-basierte IntegratioN: Apache Continuum, Hudson, OpenCIT
  CI Server mit: Apache Continuum oder Hudso
- Danach Berichte erstellen und verschicken
Arbeitsablauf:
1. Entwickler erstellt neue Version im SCM (Commit, Pull-Request...).
1. CI Werkzeug reagiert auf dieses Ereignis, lädt die entsprechende Version.
1. Build Tool wird gestartet, compilierter Code wird mit einem Test-System automatisiert getestet.
1. Entwickler wird mit Bericht verständigt.

Was bringt TDD in Verbindung mit Continuous Integration?
Viele schnelle Unit tests → Integrations-Tests wesentlich einfacher. (bottom-up testing)

Welche Testarten gibt es?
Traditioneller Testprozess
Bei Anforderungen Tests erstellen → First Test / Test Driven Development
Unterschiedliche Schichten / Sichten → Unterschiedliche Testebenen
- Implementierung
  Komponenten Tests / Unit-Tests / Klassen-Tests
  (Entwickler Tests, werden meistens von Entwicklern selbst geprüft)
  genaue Lokalisierung
- Architektur
  Integrations Tests
  Komponenten zu System oder Subsytem zusammenbauen → Zusammenspiel über Schnittstellen testen, auch externe Systeme die benutzt werden.
  Manchmal Mock-Objects benötigt um fehlende Komponenten zu simulieren.
  Automatisiert: Continuous Integration Tests
- Anwender
  Systemtests, Akzeptanztests und Abnahmetests → Verifikation, Validierung
  Alles außer Systemtests: In Produktivumgebung vom Kunden (zb OS vom Kunden)
  (keine Abnahmetests bei Produkte für den breiten Markt)
  Installationstest
  Identifizieren von Fehlern während der Installation.
- Regressionstests
  Bei Änderungen oder Erweiterungen nach einem Test
Äquivalenzklassen-Zerlegung
Mit minimalem Aufwand möglichst hohe case-coverage.
Man wählt Repräsentanten.
```
18 < Alter <= 651.Partition: Alter <= 18 (ungültig)
2.Partition: 18 < Alter <= 65 (gültig)
3.Partition: Alter > 65 (ungültig)
```
Grenzwertanalyse
Werte aus Grenzbereich wählen
Testarten / Test Methoden (statisch vs dynamisch)
- statische Verfahren → kein Code ausgeführt
  Reviews, Inspektionen
- dynamische Verfahren → Software Tests
  White-box
  Whiteboxtests sind meist Modul oder Systemtests
  – Basiert auf SE-Modellen – Wissen über innere Struktur notwendig – Logik-getrieben → Überdeckung von Knoten, Kanten, Pfaden
  Black-box
  innerer aufbau nicht geprüft, nur eingabe - ausgabe (data-driven)
  Unit Tests werden meist als Blackbox ausprogrammiert (TDD) – Wissen über innere Struktur wird ignoriert – Daten-getriebene, Input-Output-getriebene Tests – Anforderungsüberdeckung
Teststufen
Stufe bestimmt Testframework, System Tests (z.B. GUI Tests - sehr mühsam)
Abhängig von Testebene und Anwendungsfall entweder testen auf
Funktion (Funktionstest)
Last (Lasttest)
Unit Testing
Ziel: Dokumentation von Klassen, genaue Lokalisierung von fehlern
In OOP ist ein Unit eine Klasse oder eine Methode
Unit-Tests müssen schnell durchlaufen (Regression-Library), Regressiontest nach Änderungen notwendig
Module Testing
Modultests / Komponententests genau wie Unit Tests
Modul
- hat eine dokumentierte Spezifikation (API)
- ist sichtbar und in Gesamtsystem integriert (z.B. mit Interfaces)
- Es kann kompiliert/interpretiert und getrennt von anderen Modulen getestet werden (z.B. mit Mocking)
1. Komponenten bieten Interfaces an (provides)
1. Komponenten erfordern andere Interfaces (requires)
1. Das macht Komponenten zu abstrakten, austauschbaren Modulen
Integration Testing
Ziel: Test der Interaktion zwischen Modulen (Zusammenführung)
1. „Big Bang“
1. Inkrementell: Top-Down / Bottom-Up (besser)
Häufig: Zusammenführung durch Entwickler
– Weniger Aufwand (weniger Stubs/Treiber nötig) – Frühere Erkennung von Schnittstellenfehlern – Fehler-Lokation besser eingrenzbar (leichteres Debugging)

Was ist System Integration und welche Modelle gibt es? Erstellen Sie jeweils eine Skizze und nennen Vor- und Nachteile
Vorgang diese Module / Komponenten in größere (Sub-)Systeme zu integrieren = Systemintegration.
Es gibt dafür mehrere Strategien / Modelle:
- Big-Bang
  Alle Module werden gleichzeitig integriert (=„Big-Bang“)
  (für kleine Projekte)
  $+$ Keine Test-Stubs/Driver notwendig - alle Module verfügbar.
  $-$ Fehler schwer zu lokalisieren.
- Top-Down
  Integration: Business Cases → Hardware (Low-level)
  $+$ Ausführbares Produkt-Framework (Demo Prototyp) früh verfügbar.
  $-$ Test-Stubs
  $-$ Instabiles System weil Hardware Integration später
- Bottom-Up
  Umgekehrt.
- Build
  Schrittweise nach Business Cases über alle Layer hinweg.
  $+$ Früh Prototyp und Dem
  $+$ Priorisierung der Anforderungen möglich.
  $-$ Regressionstests erforderlich, Test-Stubs nicht wiederverwendbar.

Was ist bei der Systemintegration im Hinblick auf die Qualitätssicherung zu beachten? (Lösung unbekannt)
Automation des Buildprozesses → schnelle automatisierte Unit tests, bessere Dokumentation, Code-Quality-Checks.
Vereinfacht Integrationstests.
Es ist inkrementelle Bottom-Up Integration vorzuziehen

Welche Rolle spielen Requirements im SE Life-Cycle?
Requierements (Anforderungen) zeigen die Wünsche des Kunden in Bezug auf das Softwareprodukt Anforderungen müssen testbar sein und getestet werden.

Skizzieren und beschreiben Sie den Continuous Integration Arbeitsablauf
Continuous Integration CI
= eine Reihe von Best-Practices, die empfohlen werden für build management:
Automatisiertes: Builden, Testen, Integration, Deployment
- nur ein einziges Sourcecode-Repository verfügen, mit dem alle Entwickler arbeiten.
- Ablauf möglichst schnell
- Mindestens 1x täglich committen auf neutralem Rechner → "daily builds"
  „neutraler“ CI-Server automatisiert Build und Tests bei jeder Änderung im SCM-System
  Build-Automatisierungswerkzeuge:
  Entwicklerorientiert: Maven
  Server-basierte Integration: Apache Continuum, Hudson, OpenCIT
  CI Server mit: Apache Continuum oder Hudso
- Danach Berichte erstellen und verschicken
Arbeitsablauf:
1. Entwickler erstellt neue Version im SCM (Commit, Pull-Request...).
1. CI Werkzeug reagiert auf dieses Ereignis, lädt die entsprechende Version.
1. Build Tool wird gestartet, compilierter Code wird mit einem Test-System automatisiert getestet.
1. Entwickler wird mit Bericht verständigt.

Erläutern Sie den Begriff der Systemintegration. Skizzieren und erläutern Sie die vorgestellten Integrationsstrategien und welche Vor- bzw. Nachteile damit verbunden sind
System Integration
Systeme sind modularisiert und umfassen viele (unit-)getestete Komponenten.
Systemintegration = Integration von Komponenten zu größeren (Sub-)Systemen.
Strategien:
1. Big-Bang Integration
  Gleichzeitige Integration von allen Komponenten gleichzeitig
  Kein Zusatzaufwand
  Fehler sind schwer zu finden, viele Seiteneffekte gleichzeitig, riskant → eher bei kleinen Projekten
1. Top-Down Integration
  Nur bestimmte, eingeschränkte Funktionalität, schrittweise
  Business Cases Tests → Hardware Tests
  “ Prototypen ” für Demo-Zwecke.
  Hoher Aufwand für Test stubs (um die fehlende Funktion zu simulieren) - man kann manche Fehler zu spät finden
  Ausführbares Gesamtsystem ist früher verfügbar
1. Bottom Up Integration
  Nur bestimmte, eingeschränkte Funktionalität, schrittweise
  Hardware Tests → Business Cases Tests
  Stabiles System (durch Hardware Interfaces)
  Zusätzlicher Aufwand für Prototypen und Test Drivers .
1. Build Integration
  Nur bestimmte, eingeschränkte Funktionalität
  Phasen-orientierte Integration → eine einzige funktionalität wird durch alle layers durch getestet.
  Wiederverwendung von Komponenten kann schwierig sein.
  Benötigt Regressions-Tests

Planbasierte Methoden
= Systematische Prozesse. Sind plan-driven und orientieren sich eher an Abläufen mit Schwerpunkt auf Produkten und Dokumentation.
Beispiele:
Wasserfallmodell
V-Modell (XT)
RUP
Inkrementelle Modelle

Erklären und skizzieren Sie das Wasserfall Modell. Nennen Sie auch Vor- und Nachteile
Klassisch / Sequentiell (traditionell)
Umsetzung des Life-Cycles
Fokus auf Dokumentation
Strikt sequenzieller Projektablauf.
Vorherige Phase muss vollständig abgeschlossen und freigegeben (Validierung und Verifikation) sein. → Wenn nicht erreicht, zurückspringen.
Vorteile
- Backtracking zu früheren Entwicklungsphasen.
- Weite Verbreitung und hoher Bekanntheitsgrad.
- Risikominimierung durch „Abschluss“ einer Phase.
- Weite Verbreitung und hoher Bekanntheitsgrad.
- Strikte Trennung der einzelnen Phasen.
Nachteile
- Reaktion auf spätere Änderungen schwer.
- Software und Prototyp für Kunden steht spät zu verfügung.
- keine parallele Entwicklung, tasks müssen abgeschlossen werden
- Starke Auswirkung von Fehlern aus frühen Phasen.
- Anwendung bei guten Kenntnissen über die Anforderungsdomäne
- nur bei klar definierten und vollständigen Anforderungen.
Anwendung
Für vollständige, stabile Anforderungen, kleinen Projekten.
kleine Entwicklungsteams
Gute Kenntnis erforderlich (No-Surprise Software)
Alle Anforderungen / Erwartungen müssen von Anfang an komplett klar sein

Erklären und skizzieren Sie das V-Modell. Nennen Sie auch Vor- und Nachteile.
Für vollständige, stabile Anforderungen.
Im öffentlichen Bereich.
4 Submodelle: Systemerstellung, Qualitätssicherung, Konfigurationsmanagement, Projektmanagement
Ziel:
- Gesamtaufwand / Kostenreduktion
- Kürzere Einarbeitungszeiten für neue Mitarbeiter im Projekt
- Einfachere Kontrolle / vergleich des Projektfortschritts (auch für den Auftraggeber)
Teilt auf in Realisierungs und Test-Phase.
1. Analytische Phasen
  Immer detailiertere Spezifikation
1. Synthetische Phasen
  Immer weiter Implementiert und getestet
Sichten in analytischen und synthetischen Phasen
Anwendersicht Kundensicht, Geschäftsprozesse, Akzeptanz und Abnahmetests
Architektursicht Grundlegendes Architektur Design + Realisierug, Integrationstests
Implementierungssicht konkret spezifizierte Komponenten, oft Test-Driven-Developement
Qualitätssicherung
- Ist integriert nach jeder Phase
- Reviews, Inspektionen
Vorteile
- Fehlerbehandlung in frühen Phasen mit Reviews
  $\cdot$ Frühe Fehlererkennung in analytischen Phasen
  $\cdot$ Gute Planung
- Verschiedene Abstraktionslevels.
Nachteile
- Wie Wasserfallmodell
  Klare System-Anforderungen von Anfang an verlangt
  Alle Anforderungen / Erwartungen müssen von Anfang an komplett klar sein
- Viel Aufwand für Dokumentationen
Anwendungsbereich
für kleine Projekte zu detailliert, für große Projekte mit hohem Qualitätsanspruch geeignet (speziell Embedded Systems) an die man mehrere Jahre entwickelt
Große Projekte im öffentlichen Bereich

V Modell XT
V-Modell XT
Baut auf V-Modell und V-Modell 97 auf.
In DE im öffentlichen Bereich verpflichtend.
Modular, flexibel (kann angepasst werden durch Tailoring ).
Für unklare, sich ändernde Anforderungen auch geeignet.
Ziel: Projektrisiko minimieren, Anpassbarkeit, Anwendbarkeit, Skalierbarkeit und Änder- und Erweiterbarkeit des V-Modells.
21 verschiedene Elemente /Vorgehensbausteine
a) Kernelemente
b) Optionale Elemente
Kapseln mit Schnittstellen:
$\cdot$ Produkte
Ein Produkt kann aus vielen Subprodukten stehen die voneinander abhängig sein können (dependency).
$\cdot$ Produktergebnisse
$\cdot$ zugeordnete Aktivitäten
Für einen Produkt gibt es genau eine Aktivität (die widerum aus anderen Subaktivitäten bestehen kann)
$\cdot$ verantwortliche Rollen
Für einen Produkt gibt es genau einen Verantwortlichen.
Produkt und Aktivität können von anderen Produkte und Aktivitäten abhängig sein.
Es gibt Abhängigkeiten zwischen den Bausteinen (steht in der V-Modell XT Dokumentation).
Projektgegenstand
Inhalt des Projektes (bspws Hardware-Systeme, Software-Systeme, komplexe Systeme, eingebettete Systeme und Systemintegration im V-Modell XT)
Projekttypen
1. Systementwicklungsprojekt des Auftraggebers AG
  Auftraggeber-Sicht
1. Systementwicklungsprojekt des Auftragnehmers AN
  Auftragnehmer-Sicht
1. Systementwicklungsprojekt des AN mit AG in derstelben Organisation
  InHouse-Projekt , keine externe Kommunikation
1. Einführung und Pflege eines organisationsspezifischen Vorgehensmodells
  Warten und Verbessern
Kern und optionale Bausteine nach Projekttyp
Projekttypen vs. Projektgegenstand
Projekttypen eingeteilt nach:
1. Gegenstand: z.B. Hardwaresystem, Softwaresystem, Komplexes System
1. Rollen: z.B. Auftraggeber / Auftragnehmerprojekte
Gesamte Strategie inkl. Entscheidungspunkte (Projektdurchführung)
Projektdurchführungsstrategie: Aneinander-Reihung der Bausteine → Definiert Ablauf.
Unterschiedliche Arten an Strategien möglich (auch inkrementell und agil).
Beispiel:
Tools
Kann man an unterschiedliche Projektgegebenheiten mit Open Source tools anpassen:
- Auswahl von benötigten Vorgehensbausteinen
- passende Projektdurchführungsstrategie
- Ergebnis: maßgefertigte Vorgehensweise + Templates für die Projektdokumentation.

Erklären und skizzieren Sie den SCRUM Prozess. Nennen Sie auch Vor- und Nachteile
Bisher mangelhafte Flexibilität, unnötig hoher Dokumentationsaufwand, fehlende Nähe zum Kunden, Kunde nicht mit in Entwicklung einbezogen.
SCRUM
Art von agiler Entwicklung.
Ziel: kleine effiziente Teams bilden.
Gesamte Dauer meistens 2-4 Wochen
Sprint meistens 1 Tag → Keine Unterbrechungen, keine Änderungen zugelassen
Kurze tägliche Besprechungen vor Daily Scrums , 15 Minuten:
1. Was wurde seit dem letzten meeting erledigt
1. Welche Probleme sind aufgetreten während der Entwicklung
1. Was ist das Ziel bis zum nächsten Meeting
Reagiert auf andauernd ändernde Anforderungen im Projektablauf. Teil-Produkte stehen dem Kunden frühzeitig zur Verfügung.
Ein Team zuständig für Einheit / Produkt / Teilprodukt.
Begriffe
Temporal structure = daily Scrum Meeting + Review + Retrospective.
Backlog
alle Arbeitspakete, die in nächster Zeit umgesetzt werden müssen (sowohl klar definierte als auch vage Anforderungen): Produkt vs. Sprint Backlog.
Priorisierte Projektergebnisse (Backlog Items).
Daily-Scrum
Täglicher Arbeitsauftrag
Das Sprint-Team darf beim Arbeiten nicht gestört werden.
Scrum Team
Funktionsübergreifendes Team, zuständig für den Sprint Backlog.
Burndown Chart
Visuelle Darstellung des Projektfortschritts.
Phasen
1. Pregame
  Anforderungen → Architektur und Planung
  Alle Eigenschaften und Features gemeinsam mit Kunden → Product Backlog → Prioritisieren
  (alle zukünftigen Änderungen passieren im Product Backlog)
1. Sprint
  Kleine Menge an features aus product backlog → spring backlog (machbare Menge)
1. Postgame
  Auslieferung
Sprint
Team darf nicht gestört werden.
Wiederholung von:
1. Develop and Test Implementierung von neuer Software
1. Wrap Integration
1. Review Review des integrierten Produkts
1. Adjust Anpassung, Verbesserung
Methoden / Tools
$\cdot$ Burndown charts
$\cdot$ Test-Driven Developement
$\cdot$ Pair Programming
$\cdot$ Reviews
Vorteile:
• Wenige Regeln, leicht verständlich.
• Hohe Effektivität durch Selbstorganisation.
• Adaptiv/Tolerant gegenüber Anforderungsänderungen und neu Priorisierung.
• Hohe Transparenz durch regelmäßige Meetings und Backlogs.
• Geringer Administrations- und Dokumentationsaufwand.
Nachteile:
• Kein Gesamtüberblick über die komplette Projektstrecke.
• Hoher Kommunikations- und Abstimmungsaufwand.
• Erschwerte Koordination mehrerer Entwicklungsteam bei Großprojekten.
• Potentielle Verunsicherungen aufgrund fehlender Zuständigkeiten und Hierarchien.
• Potentielle Unvereinbarkeit mit bestehenden Unternehmensstrukturen.

Erklären Sie den Unterschied zwischen dem Produkt-Backlog und Sprint-Backlog.
Produkt-Backlog: Vom Kunden priorisierte Liste alle Features zum Produkt.
Sprint-Backlog: (Teilmenge von Produkt-Backlog) Alle Features die zu einem gewissen Sprint gehören. Features werden in kleinere Tasks aufgeteilt.

Was versteht man unter einem Burndown-Chart?
Visuelle Darstellung des Projektfortschrittes.
Immer neue Schätzungen des Abschlusses basierend auf aktueller Geschwindigkeit bei jedem daily scrum.

Was gehört zu den 12 Prinzipien des Agilen Manifests?
Entstand aus Kritik an „schwergewichtigen“ Ansätzen.
"Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan"
Englisch:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
1. Business people and developers must work together daily throughout the project.
1. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
1. Working software is the primary measure of progress.
1. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
1. Continuous attention to technical excellence and good design enhances agility.
1. Simplicity--the art of maximizing the amount of work not done--is essential.
1. The best architectures, requirements, and designs emerge from self-organizing teams.
1. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Deutsch:
1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
1. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
1. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
1. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
1. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
1. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
1. Funktionierende Software ist das wichtigste Fortschrittsmaß.
1. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
1. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
1. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
1. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
1. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Rational Unified Process, RUP
Inkrementell, iterativ, phasenorientiert.
Im kommerziellen Umfeld.
UML in jeder Phase.
Integriertes Anforderungsmanagement und Änderungsmanagement (supporting workflow).
Phasen mit Meilensteinen
Eine Phase kann mehrere Iterationen haben (Von Projektmanager festgelegt).
Aktivität + Verantwortlicher = Artifakt
Jede Phase / Aktivität von einem Verantwortlichen erzeugt ein Produkt / Artefakt → überprüft, freigegeben.
Wenn Überprüfung nicht bestanden, weitere Iteration.
1. Inception (Beginn)
  Anforderungen (Geschäftsfälle / Business Cases), Rahmenbedingungen definiert.
1. Elaboration (Entwurf + Design)
  Spezifikation aus Anforderungen.
1. Construction (Implementierung)
  Komponenten umgesetzt.
1. Transition (Auslieferung)
  Auslieferung an Kunden, Product release.
Disziplinen und Workflows
9 Disziplinen die durch alle Phasen geführt werden
6 Engineering Workflows
3 Supporting Workflows
Engineering Workflows
1. Business Modeling: Geschäftsfallmodellierung mit UML
1. Requirements: Anforderungen genau erheben, Verfeinerung der Use-Cases
1. Analysis & Design: Erstellen wichtige Dokumente / Artefakte: Architektur, Design, Test-Dokumente
1. Implementation
1. Test
1. Deployment: Fertigstellung, Auslieferung
Supporting Workflows
1. Configuration and Change Management: Dokumentenversionierung mit Version Control System
1. Project Management
1. Environment: Definiert Ressourcen, Budget und Werkzeuge für Entwickler
Vorteile
Real-world Szenarien.
Werkzeugunterstützung (Rational XDE, IBM).
Vordefinierte Liste mit erforderlichen Artefakten.
Nachteile
Komplexität, Dokumentationsaufwand
Anwendungsbereich
Grosse Projekte die einen Überblick brauchen (inkl. Deployment).

Erklären Sie die wesentlichen Konzepte des „Process Customizing“ und des „Prozess Tailoring“. Wozu und wann werden sie eingesetzt?
Modelle müssen dem Projekt angepasst werden.
Nicht alle Schritte aus dem Life-Cycle können ausgeführt werden.
$\cdot$ Schritte Zusammenlegen oder auslassen
Anpassung an
- Organisation mit eigener Domäne (= Fachgebiet)
  zb Wenn eine Organisation öfter Web Applikationen macht.
  Kann Best-Practices in der Domäne nutzen - Process Pattern
- Projekt
Reihenfolge
1. Process Customization: Organisation + Domäne
1. Process Tailoring: Projekt
Prozess Customization (Standardisierung)
Verallgemeinerte Form des „Tailorings“.
- unternehmensspezifische Standards (für eher große Unternehmen) → Domänenabhängige Anpassungen, z.B. für Produktionsautomatisierung.
- ähnliche Projekte (z.B. Webapplikationen).
Dient dann als Grundlage für Projektspezifisches Tailoring.
Prozess Tailoring (Prozess auf das jeweilige Projekt anpassen
Angepasst an konkrete Projekte (Projektgröße, Projekttyp und Anwendungsdomäne)
Braucht erfahrene Projektleiter und Toolunterstützung (z.B. V-Modell XT Projektassistent).

Auf welcher Grundannahme basiert die klassische / sequenzielle Softwareentwicklung? Zu welchen Problemen kann dies führen und wie wird damit bei der kontinuierlichen Softwareentwicklung umgegangen?
Der sequentielle Entwicklungsprozess basiert auf stabilen Anforderungen.
Anforderungen ändern sich allerdings oft, was bei sequentiellen Vorgehensmodellen in der Regel dazu führt, dass das Endprodukt nicht mehr den Anforderungen entspricht.
Beim kontinuirlichen Modell wird iterativ gearbeitet, der Funktionsumfang steigt mit jeder Iteration, gesteuert durch den Soll-Ist-Vergleich → auf Anforderungsänderungen kann besser reagiert werden.

3 Creational Patterns beschreiben.
• Singleton – Provision of a single instance only • Factory – Method in a derived class creates associates • Prototype – Factory for cloning new instances from a prototypical instance
○ Singleton
Provision of a single instance only
Issue
Only one object instance should exist:
- Database access
- Id generator
- Logger
- Communication with hardware
Solution
- Example
  public class Person { private final Logger LOG = LoggerFactory.getLogger(Person.class); Logger getLogger() { return LOG; } }
  In this case LOG is the same object even without static due to the way the LoggerFactory works.
○ Factory
Method in a derived class creates associates
Issue
Object creation & configuration is complex
Solution
- Example
  interface Product { float getPrice(); }public class Milk implements Product { final float price; public Milk(final float price) { this.price = price; } //constructor public float getPrice() { return price; } //getter }public class Sugar implements Product { final float price; public Sugar(final float price) { this.price = price; } //constructor public float getPrice () { return price; } //getter }public class Product Factory { public static Product createProduct(String what){ //When sugar is requested, we return sugar: if (what.equals("Sugar")) { return new Sugar(1.49F) ; } // When milk is needed, we return milk: else if (what.equals("Milk")) { return new Milk(0.99F); } // Otherwise return at least sugar else { return new Sugar(1.49F); } } }
○ Abstract Factory
Factory for building related objects without specifying their concrete classes
Issue
Achieving higher abstraction by grouping individual factories with a common theme
Solution
A group of individual factories that have a common theme
Two hierarchies → abstract AbstractFactory class provides interface
Client only knows abstract interface → Family may grow independently of the client

4 Structural Patterns beschreiben.
• Facade – Facade simplifies the interface for a subsystem • Adapter – Translator adapts a server interface for a client • Proxy – One object approximates another • Bridge – Abstraction for binding one of many implementations
○ Facade / Facet
Simplifies the interface for a subsystem
Issue
Need simplified access to a complex subsystem
Provides an abstracted interface of a subsystem
Solution
- Example
  public class SimpleMail { public static int sendMail(String address, String subject, String body) { int status = 0; ... //Complex mail sending operation return status; } }
○ Adapter / Translator
Adapts a server interface for a client
Issue
Need to integrate incompatible external functionality
Solution
Translates (data transformation) into a compatible interface
○ Proxy
One object approximates another
Issue
Need to integrate further actions before intended method call
Solution
Extends concept of the delegation pattern
Implements interface and acts as a representative of the „original“ implementation
Used in: security, logging, caching
○ Inversion of Control IoC
Die Verantwortung für das Erzeugen und Initialisieren von Objekten wird an eine zentrale Stelle (z.B. eine Klasse) delegiert.
Von der zentralen Stelle kann man die Abhängigkeiten zwischen den Objekten leichter überblicken und steuern.

Beschreiben Sie das Data Access Object Pattern (DAO) anhand eines UML-Diagramms und erläutern Sie dessen Funktionsweise. Wann kommt dieses Pattern typischerweise zum Einsatz?
Einsatz:
Trennung von Interface/Implementation (mehrere Implementationen möglich
Dependency Injection Systeme (Spring)
Geschäftsmethoden aus der Business Logic layer enthalten keine direkte Interaktion mit Persistenztechnologien wie zB relationalen Datenbanken.
Um Daten (Domänenobjekte) zu persistieren, definiert man Data Access Object DAO Interfaces (mit CRUD befehlen - create, reade, update, delete).
• Create (insert..()) • Read (get..(), search..()) • Update (update..(),save..()) • Delete(delete..())
Das SQLPersonDAO-Objekt ist eine mögliche Implementierung des PersonDAO-Interfaces.

Wie sieht eine moderene 3-Tier-Architektur aus? Beschreiben Sie die folgenden Fälle: a) Thin-Client b) Fat-Client. Beschreiben und skizzieren Sie die beiden Architekturvarianten.
Moderne 3-Tier-Architektur
- Präsentationsschicht
- Anwendungs-/Logikschicht
- Datenschicht
Thin-Client („Heavy Server“ vs. Server per Layer)
Fat-Client (Data-Server)

Zeichnen und erklären Sie die Motivationspyramide nach Maslow. Nennen Sie auch ein Alternativ Modell für menschliche Motivation.
Motivation
Summe der Beweggründe → beeinflussen Handlung
1. extrinsische Motivation (von außen) äußere Zwänge (Strafen)
1. intrinsische Motivation (von innen) von einer Aufgabe ausgehenden Anreize
Motivationstheorien
1. Prozesstheorien bestimmtes Verhalten gewählt zum erreichen vom Ziel
1. Inhaltstheorien Bedürfnisse, Antriebe und Ziele
  1. Monothematische Theorien (heute nicht mehr relevant)
    Einziges Motiv bestimmt das Verhalten
    Bsp.: Freud: Sexualtrieb, Adler: Minderwertigkeitskomplex
  1. Polythematische Theorien:
    Mehrere Grundmotive
    Verschiedene Triebe mit Rangordnung und Stärke basierend auf mehreren Bedürfnissen.
Wichtige polythematischen Inhaltstheorien
$\cdot$ ERG-Modell (Existence, Relatedness, Growth)
$\cdot$ Zweidimensionale Arbeitszufriedenheitstheorie von Herzbe
$\cdot$ Motivationspyramide von Maslow (alt und überholt)
Erst wenn eine Stufe in einem gewissen Ausmaß befriedigt ist, wird die darauf aufbauende verfolgt.
1. Physiologische Grund- oder Existenzbedürfnisse“lebensnotwendige” Bedürfnisse wie Schlaf, Nahrung
1. Sicherheit Absicherung der Person - Schutz des Lebens, des Eigentums, Lebensstandards, Schutz vor Arbeitslosigkeit, Unfallfolgen bis hin zur Altersvorsorge
1. Sozial Gruppenzugehörigkeit, soziale Akzeptanz, Freundschaft, Zuneigung, etc.
1. Achtungsbedürfnis Selbstachtung, Fremdachtung → Erleben der eigenen Leistung, Anerkennung, Status
1. Selbstverwirklichung Zu verwirklichen, was es potentiell ist → Einfluss auf Umwelt nehmen, sie gestalten.
  Ab dieser Stufe kommt es zu einer gewissen Eigendynamik: je stärker dieses Bedürfnis befriedigt wird, desto bestimmender wird es für das Verhalten.

Nennen Sie vier Formen und vier Richtlinien zur Team-Organisation.
Formen der Team-Organisation
1. Stab
  Hierarchische, (organisatorische) Strukturen mit strikter Trennung der Rollenverteilung → langsam.
1. Matrix
  Mischung aus "stab" und "rein" → Pro Team ein Leiter der aber dem Projektleiter unterworfen ist.
1. Rein
  Ein Mitglied aus jedem Team ist gleichzeitig Projektleiter und teil einer Leiter-Versammlung.
• die klassische hierarchische Organisation • die typische Matrix-Organisation • das “Chef-Programmierer”-Team • das offen strukturierte Team • das SWAT-Team • das XP-Team
Verantwortlichkeiten
Horizontal Zeitlich - Über Projekt-Verlauf
Vertikal Arbeitspakete - explizite Zuständigkeiten
Richtlinien zur Team-Organisation
Hohe qualität, niedrige quantität
Nicht unterfordern, nicht überfordern
Aufgaben basierend auf Interessensgebiete der Arbeiter
Wertschätzung, Vielfalt → Mitarbeiter sind mehr als nur Ressourcen
Auf die persönliche Entwicklung der Mitarbeiter achten

Nennen Sie je zwei Faktoren die Einfluss/keinen Einfluss auf die Produktivität von Menschen haben
Faktoren ohne Einfluss auf Produktivität
- Programmiersprache außer die Assembler-Programmierer
- Berufserfahrung Kein Zusammenhang zwischen Berufserfahrung vs. erbrachte Leistungen. Außer Personen, die weniger als 6 Monate Erfahrung hatten.
- Anzahl der Fehler
- Gehalt Nur sehr schwache Beziehung zwischen Gehalt und Leistung: bessere Hälfte verdiente ca. 10% mehr als die schlechtere Hälfte.
Faktoren mit Einfluss auf Produktivität
- Teampartner gleiches Umfeld, gleiche Firmenkultur = fast identische Leistungen
- Arbeitsplatz Qualität des Arbeitsplatzes (in der Arbeit) → !! sehr wichtig

Nennen und erklären Sie sechs Wege, die Teambildung verhindern
Dinge die Teambuilding verhindern
1. Defensives Management, Teammitglieder werden entmündigt keine Entscheidungsmacht
1. Sinnlose Bürokratie
1. Physikalische Trennung von Personen, die eigentlich zusammen arbeiten sollen
1. Zersplitterung der Zeit der Mitarbeiter auf mehrere Projekte
1. Qualitätsreduktion der Produkte
  Vorteil: Kostenreduktion
  Nachteil: geringere Identifikation der Mitarbeiter mit dem Projekt
1. unrealistische Termine → geringe Identifikation mit dem Projekt
1. Cliquenkontrolle, Ständige Veränderung der Teamstruktur

Warum ist Feedback wichtig? Nennen Sie fünf Arten wie man Feedback im Rahmen eines Software-Projektes einholen kann
Menschen verstehen die Umwelt durch Interaktion und Rückmeldung → Feedback ist für das Verständnis der Umwelt sehr wichtig.
Rechtzeitiges Feedback = Rechtzeitige Reaktion
Einholen:
1. Prototypen
1. Code Review, Pair Programming
1. Features sofort vom Benutzer Testen lassen (am besten durch Kunden)
1. Usability Tests

Warum ist Feedback wichtig und wie soll es aussehen?
Beim Feedback geben ist zu beachten:
- Höflich und wertschätzend
- Negatives unter vier Augen
- Feedback ist eigene Meinung – nicht die „Wahrheit“
- Über das Problem, nicht die Person sprechen: „Der Code war für mich schwer zu lesen“ vs. „Dein Code ist schwer zu lesen“.
- Alternativen anbieten
- Nicht erst bei Problemen → regelmäßig Rückmeldungen auch positive:
  Feedback institutionalisieren (Pair-Programming, Code-Reviews, 1:1 Meetings, Pull Requests)

Unterschied

Zu Reviews verwandte Tätigkeiten

Arten von Reviews

Mit Kunde

Ohne Kunde

Testarten / Test Methoden (statisch vs dynamisch)

Teststufen

Unit Testing

Module Testing

Integration Testing

Continuous Integration CI

V-Modell XT

SCRUM