TU Wien:Software Engineering und Projektmanagement VO (Biffl)/Fragenkatalog

Aus VoWi
Zur Navigation springen Zur Suche springen

Ausarbeitung ausgewählter Prüfungsfragen (hauptsächlich 2019) und ergänzender Themen. Ausarbeitung basierend auf den SEPM Folien von SS 18. Einige Fragen aus 2022 ergänzt.

🧀Die Fragen welche bei den letzten 5 identischen Tests verwendet wurden *Stand 24.08.2023 sind mit 🤯(explodierender Kopf Emoji) markiert.

Einführung in Projektmanagement[Bearbeiten | Quelltext bearbeiten]

Was ist ein Projekt? Durch welche Merkmale ist es definiert?[Bearbeiten | Quelltext bearbeiten]

Ein Projekt ist ein einmaliges Vorhaben mit einem definierten Anfang, einem definiertem Ende und mehreren beteiligten Personen.

Welche drei Kennzeichen hat ein Projekt?[Bearbeiten | Quelltext bearbeiten]

  • Ihre Abgrenzbarkeit bezüglich: Aufgabe, Ergebnis, Ressourceneinsatz und Zeitrahmen
  • Komplexität der Aufgabe
  • Einmaligkeit der Aufgabe

Was ist Projektmanagement?[Bearbeiten | Quelltext bearbeiten]

Projektmanagement ist eine Gesamtheit von Methoden und Verhaltensweisen zur effizienteren Steuerung der Abwicklung von besonderen Aufgabenstellungen (Projekten).

Im engeren Sinn ist das Projektmanagement die Projektleitung, d.h. die für die Führung/Steuerung eines Projekts verantwortliche Person/Stelle.

Drei Stakeholder nennen, die Einfluss auf die Anforderungen haben. Begründen Sie Ihre Antworten. (2019-01-21)[Bearbeiten | Quelltext bearbeiten]

  • Kunde: Der Kunde hat eine Idee oder ein Bedürfnis welches durch das zu entwickelnde Produkt abgedeckt werden soll.
  • Entwickler: Entwickler nehmen Einfluss auf die Anforderungen indem Sie Wissen über technische (Un-)Möglichkeiten einfließen lassen. Sie müssen die Vorstellung des Kunden technisch Bewerten, Beschreiben und Verwirklichen.
  • Betreiber: Die Abteilung welche die Betriebs und Wartungsphase des Projekts übernimmt beeinflusst die Anforderung um einen reibungslosen Betrieb und einfache Wartung sicherzustellen.
  • Management: Das Management beeinflusst die Anforderungen durch Ressourcenvergabe und Zeitplan.
  • Konkurrent: Der Konkurrent beeinflusst die Anforderungen, da der Kunde sich vermutlich von der Konkurrenz abheben will, um am Markt zu bestehen.

Drei typische Gründe warum ein Projekt den Zeit-/Kostenrahmen überschreitet (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

  • Mangelhafte Anforderungen

    Die Anforderungen decken sich nicht mit den Erfordernissen oder sind unklar/mehrdeutig formuliert.

  • Mangelhafte Umsetzung der Anforderungen

    Die Anforderungen wurden nicht verstanden und deshalb falsch umgesetzt, es gibt technische Mängel (Implementierung) oder Termin-Not und Ressourcenmangel.

  • Mängel im Projektmanagement

    Mangelhafte Kommunikation, unrealistische Termin- und Kostenrahmen oder Ressourcenmangel (Verfügbarkeit, Qualifikation, Erfahrung).

🤯Auf welchen Annahmen basiert sequentielle Softwareentwicklung & Probleme. Wie geht kontinuierliche SE damit um?[Bearbeiten | Quelltext bearbeiten]

Annahme: vollständige unveränderliche Anforderungen.

z.B.: Wasserfall-Modell, die vorherige aktuelle Phase muss abgeschlossen sein, damit in die nächste Phase übergangen werden kann, zusätzlich basiert jede Phase auf den Vorgänger Phase.

Problem:

  • je innovativer eine Lösung ist, desto weniger sind die erforderlichen Eigenschaften zu Beginn bekannt.
  • dynamische Geschäftszweige ändern sich rasch -> Anforderungen ändern sich,
  • sequentieller Entwicklungsprozess ist eine systemimmanente (in den Rahmen eines Systems gehörend) Bruchstelle.

Lösung:

Kontinuierliche SE löst die aufgezeigten Probleme, in dem rasch ein auslieferbares Teilprodukt verfügbar ist, und der Entwicklungsprozess sich über mehrere Iterationen erstreckt, wobei bei jeder Iteration da Produkt um zusätzliche Features erweitert wird, dadurch können Anforderungsänderungen schnell umgesetzt werden. z.B.: SCRUM.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2022-06-30
  • 2023-06-28
  • 2023-08-24
  • 2023-09-27

Einführung in Software Engineering[Bearbeiten | Quelltext bearbeiten]

Embedded Systems und kommerzielle Software anhand von fünf Kriterien vergleichen[Bearbeiten | Quelltext bearbeiten]

Der unterschied in sieben Kriterien ist in folgender Tabelle zu sehen.

Vergleich zwischen Embedded Systems und kommerzieller Software.
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

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-03-20

Technik und Werkzeuge[Bearbeiten | Quelltext bearbeiten]

Was sind die Unterschiede zwischen zentralen/verteilten SCM? Nennen Sie jeweils Vor- und Nachteile (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Funktionsweise eines zentralen SCM
Funktionsweise eines verteilten SCM

Bei zentralen SCM (source code management) gibt es einen Server welcher das Repository ist, das ist dargestellt in Abbildung 1. Alle SCM-Operationen müssen über das Netzwerk an den Server geschickt werden. Daraus ergeben sich auch die Nachteile von zentralen SCM: Der Server ist ein Single Point of Failure und ein Flaschenhals, dadurch können einzelne SCM Operationen sehr lange dauern (hohe Auslastung, Netzwerkverkehr). Dafür benötigen die Clients nicht alle Dateien und Versionen und kommen mit weniger Speicherplatz aus.

Bei verteilten SCM wird das Repository geklont und lokal auf jedem Client gespeichert wodurch alle SCM Operationen lokal ausgeführt werden können (Vorteil), das ist dargestellt in Abbildung 2. Der Nachteil hierbei ist das ein große Menge an Daten beim klonen übertragen werden und auf dem Client gespeichert werden muss. Meist gibt es auch in verteilten SCM einen Server mit einem Main-Repository mit welchem sich die Clients regelmäßig synchronisieren (pull, push, fetch, pull-request, etc.)

Große Unterschiede gibt es auch beim Umgang mit Konflikten:

Arbeitsablauf SVN (Apache Subversion) (zentral)

  1. Update
  2. Lokale Änderungen
  3. Update
    • Änderungen remote und lokal
    • Merge
  4. Commit

Arbeitsablauf Git (verteilt)

  1. Kopie des Haupt-Repository (klonen)
  2. Lokale Änderungen
  3. Lokale Commits
  4. Merge
    • Push
    • Pull Request

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-03-20

Continuous Integration (CI) beschreiben und skizzieren (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Ablauf eines Continuous Integration Prozesses

Continuous Integration Werkzeuge unterstüzen Server-basierte Integration und Ausführung von Tests. Diese Automatisierung beinhaltet:

  1. Ereignis oder Zeitgesteuerter Abruf
  2. Verwendung von Build Werkzeugen
  3. Ausführung von Tests
  4. Erstellen von Berichten
  5. Verschicken von Mitteilungen

Der CI Arbeitsablauf ist in folgender Abbildung skizziert und startet wenn ein Entwickler oder eine Entwicklerin eine neue Version im SCM erstellen (Commit, Pull-Request oder ähnliches, Skizze 1). Das CI Werkzeug reagiert auf dieses Ereignis und lädt die entsprechende Version (Skizze 2). Anschließend wird das Build Tool gestartet und das Kompilat mit einem Test-System automatisiert getestet (Skizze 3). Im letzten Schritt werden die Entwickler und Entwicklerinnen verständigt und ein Bericht und das ausführbare Software-Artefakt verteilt (Skizze 4).

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-03-20
  • 2019-01-21

Inversion of Control (IOC) beschreiben (2019-03-20)[Bearbeiten | Quelltext bearbeiten]

Abhängigkeiten werden von einem Container verwaltet, die Komponenten wissen nichts darüber (IOC ist transparent). Die Abhängigkeiten werden injiziert (siehe auch Dependency Injection DI). Vorteile von IOC sind:

  • Hohe Wiederverwendbarkeit
  • Einfaches Austauschen einer Implementierung
  • Verwalten von verschiedenen Konfigurationen (dev vs. prod)
  • Automatisiertes verdrahten, weniger Boilerplate-Code benötigt.
  • Verteilung von Aufgaben

Beispiele für Implementierungen/Libraries:

  • Java: Spring-Framework, Google Guice, Pico-Container, Apache Aries Blueprint
  • .NET: ASP.NET Core, Unity Framework, Spring .NET, Ninject, Autofac

🤯Aufgaben eines SCM und Konflikt-Ablauf für verteilte SCM beschreiben:[Bearbeiten | Quelltext bearbeiten]

Source Code Management

Parallel auf mehreren Zweigen arbeiten, Mehrere Versionen Verwalten, Transparente Änderungen, Nachvollziehbarkeit, Historie

Konfliktablauf: Locking, Merging

Arbeitsablauf: lokal klonen des verteilten SCM, lokale Änderungen durchführen, lokale Commits, Merge, Pull/Push

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2022-06-30
  • 2023-06-28
  • 2023-08-24
  • 2023-09-27

Software Engineering Phasen[Bearbeiten | Quelltext bearbeiten]

Traceability beschreiben. Welche Arten von Traceability gibt es? (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Traceability ist die Nach- oder Rückverfolgbarkeit einer Information durch den gesamten Entwicklungszyklus und wird z.B. bei sicherheitskritischen Anwendungen gefordert. Sie umfasst auch die Änderungsverfolgung welche den Lebenszyklus einer Anforderung vom Ursprung über die verschiedenen Verfeinerungs- und Spezifikationsschritte bis zur Berücksichtigung in Entwicklungsartefakten nachvollziehbar macht.

Mithilfe von Traceability können folgende typische Fragestellungen beantwortet werden:

  • 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?

Es gibt drei Arten von Traceability:

  • Vertikale Traceability: Beziehungen innerhalb einer Phase und eines Artefakt-Typs, z.B. System – Subsystsem – Komponente.
  • Zeitliche Traceability: Zeitliche Nachvollziehbarkeit unterschiedlicher Releases, z.B. durch Konfigurationsmanagement.
  • Horizontale Traceability: Beziehungen zwischen unterschiedlichen Entwicklungsartefakten, z.B. Anforderungen – Implementierung – Testfälle.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-03-20
  • 2019-01-21

🤯Was ist System Integration und welche Modelle gibt es? Erstellen Sie jeweils eine Skizze und nennen Vor- und Nachteile (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

(Komplexe) Software-Projekte sind aus Gründen der Lesbarkeit, Verständlichkeit und Wartbarkeit meist in (viele) Module/Komponenten aufgeteilt. Der Vorgang diese Module in größere (Sub-)Systeme zu integrieren ist die Systemintegration. Für die Systemintegration gibt es mehrere Strategien/Modelle:

Big-Bang
Alle Module werden gleichzeitig integriert (=Big-Bang)
  • Vorteile: Keine Test-Stubs/Driver notwendig da alle Module bereits verfügbar sind.
  • Nachteile: Fehler sind sehr schwer zu lokalisieren, hohes Risiko bei der Integration.
  • Anwendung für kleine und überschaubare Projekte.
Top-Down
Schrittweise Integration ausgehend von den Business Cases skizziert in Abbildung 2.
  • Vorteile: Ausführbares Produkt-Framework früh verfügbar, Prototypen für Demos, Framework für Testfälle.
  • Nachteile: Zusätzlicher (hoher) Aufwand für Test-Stubs, Integration von Hardware erfolgt erst spät (zusätzliches Risiko).
Bottom-Up
Schrittweise Integration ausgehend von der Hardware (Low-Level), skizziert in Abbildung 3].
  • Vorteile: Stabiles System (basierend auf HW Interfaces), Schrittweise Integration in Richtung Business Cases.
  • Nachteile: Ausführbares Gesamtsystem spät verfügbar, zusätzlicher Aufwand für Prototypen, zusätzlicher Aufwand für Test-Drivers.
Build
Schrittweise Integration entsprechend den Business Cases über alle Layer hinweg. Phasen-orientierte Integration skizziert in Abbildung 4.
  • Vorteile: Frühe Verfügbarkeit von funktionalen Anforderungen, Prototyp und Demo, Berücksichtigung priorisierter Anforderungen möglich.
  • Nachteile: Wiederverwendung von Komponenten kann schwierig sein, Regressionstests erforderlich.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2023-09-27

🤯Systemintegration und Strategien beschreiben[Bearbeiten | Quelltext bearbeiten]

Big Bang

Gleichzeitige Integration aller Komponenten.

Vorteil: Keine zusätzlichen Aufwände für Test-Stubs

Nachteile: Fehler schwerer lokalisierbar, Hohes Risiko bei Integration

Anwendung: Kleine, überschaubare Produkte

Top Down

Schrittweise Integration ausgehend von Business Cases.

Vorteile: Ausführbares Produkt Framework früh vorhanden, Demo-Prototypen, Framework für Testfälle

Nachteile: Hoher Aufwand für Test-Stubs, späte Integration von Hardware

Bottom Up

Schrittweise Integration ausgehend von der Hardware.

Vorteile: Stabiles System, schrittweise Integration Richtung Businesscases (Layers)

Nachteile: Ausführbares Gesamtsystem erst spät verfügbar, zusätzlicher Aufwand für Prototypen & Test-Drivers

Build

Schrittweise Integration entsprechend der Business Cases über alle Layer hinweg -> Phasen-orientierte Integration

Vorteile: Frühe Verfügbarkeit von funktionalen Anforderungen, Prototypen & Demo, Berücksichtigung priorisierter Anforderungen möglich

Nachteile: Wiederverwendung von Kompontenten möglicherweise schwierig, Regression-Tests

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2022-06-30
  • 2023-06-28
  • 2023-08-24

🤯Blackbox/Whitebox Multiple Choice (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Black Box Tests

  • Anforderungen/Spezifikation als Grundlage
  • Unabhängig von der Realisierung der Module.
  • Data-drive (Input/Output).
  • Anforderungsüberdeckung.
  • Äquivalenzklassenbildung.
  • Keine genaue Fehlerortung möglich.

White Box Tests

  • Sourcecode als Grundlage.
  • Wissen über internen Aufbau notwendig.
  • Logic-driven.
  • Kontrollflussüberdeckung.
  • Äquivalenzklassen von internen Verzweigungen und Schleifen.
  • Ermöglicht Fehlererkennung und –lokalisierung.

🤯Beschreiben Sie den Prozess des Testfallbestimmens. Was muss dokumentiert werden? (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Eine Möglichkeit Testfälle zu bestimmen ist die Äquivalenzklassenzerlegung. 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. Die Äquivalenzklassenzerlegung kann durch eine Grenzwertanalyse erweitert werden, bei welcher man die Repräsentanten um die Klassen-Grenzen wählt, da hier besonders leicht Fehler auftreten ( statt ).

Die Testfälle (und Ergebnisse) müssen ausführlich dokumentiert werden als Information für Entwickler, für die Wiederholbarkeit und Berichterstattung und um sie als Kommunikationswerkzeug einsetzen zu können. Die Dokumentation sollte mindestens folgende Informationen enthalten:

  • Typ: Normal-, Spezial- oder Fehlerfall?
  • Vorbedingung: Eingabedaten, Zustand des System vor Testausführung.
  • Beschreibung: Was soll der Test zeigen?
  • Äquivalenzklasse: Falls eine Äquivalenzklassenzerlegung vorgenommen wurde: Auf welcher Klasse basiert der Testfall?
  • Erwartetes Ergebnis: Welches Ergebnis/Systemzustand wird nach der Ausführung des Tests erwartet. Der Test ist erfolgreich wenn der tatsächliche Zustand mit dem Erwarteten übereinstimmt.
  • Tatsächliches Ergebnis: Ergebnis/Systemzustand nach dem Test.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-01-21
  • 2019-03-20
  • 2023-09-27

Drei Techniken zur Wartung nennen (2019-03-20)[Bearbeiten | Quelltext bearbeiten]

  • Herstellen des Produktverständnisses: Das Verständnis fremder Codestücke kann – speziell bei mangelnden Aufzeichnungen – sehr zeitaufwendig sein. Key-Tools sind Code-Browsers und essentiell ist eine klare und präzise Dokumentation.
  • Reengineering: Überprüfung und Überarbeitung des Software Codes. Stellt eine gravierende und teure Form der Änderung/Wartung dar.
  • Reverse Engineering: Analyse der Software im Hinblick auf Komponenten und deren Zusammenhänge. Dabei hilft es, auf Basis des Software Codes, Modelle auf einem höheren Abstraktionsniveau zu erstellen z.B. UML-Modelle aus Code zu generieren.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-01-21

🤯Was sind funktionale und nicht-funktionale Anforderungen? (3 Beispiele jeweils)[Bearbeiten | Quelltext bearbeiten]

Funktionale Anforderungen: Was soll das System leisten? Welche Dienste soll es bieten?

Eingaben, Verarbeitungen, Ausgaben, Verhalten in definierten Situtationen, Datenformate

Nicht funktionale Anforderungen:

Wartbarkeit, Performance, Sicherheit

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2022-06-30
  • 2023-06-28
  • 2023-08-24
  • 2023-09-27

Modellierung von Anwendungsprozessen[Bearbeiten | Quelltext bearbeiten]

noch keine Fragen vorhanden (pls add 😊)[Bearbeiten | Quelltext bearbeiten]

QS in SE-Projekten[Bearbeiten | Quelltext bearbeiten]

Ablauf eines Reviews beschreiben und skizzieren (2019-01-21)[Bearbeiten | Quelltext bearbeiten]

Ablauf eines Reviews

Der Ablauf ist in folgender Abbildung skizziert und ist wie folgt:

  1. Planung: Objekt, Prüfziele, Auslösekriterien (Einstiegskritierien), Teilnehmer, Ort und Zeit festlegen.
  2. Vorbesprechung: Vorstellung des Prüfobjekts bei komplexen/neuen Produkten.
  3. Individuelle Vorbereitung: Intensive Einzeldurcharbeitung.
  4. Review-Sitzung: Eigentliche Durchführung des Reviews. Gemeinsames Lesen, Aufzeichnung von Mängeln (entdecken, nicht korrigieren!).
  5. Nachbearbeitung: Die dokumentierten Mängel korrigieren.
  6. Bewertung: Die Korrekturen überprüfen.

🤯Die 2 Teststrategien beschreiben?[Bearbeiten | Quelltext bearbeiten]

Blackbox

Input/Output, datadriven

Unabhängig von der Realisierung der Module, Anforderungsüberdeckung, Äquivalenzklassenbildung, Keine genaue Fehlerortung möglich

Whitebox

Software Code als Grundlage, logicdriven

Fundiertes Verständnis des internen Aufbaus, Datenflussabdeckung, Äquivalenzklassen für Bedingungen und Verschachtelungen, Ermöglicht Fehlererkennung und Lokalisierung

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2022-06-30
  • 2023-06-28
  • 2023-08-24
  • 2023-09-27

🤯Prozess für Testfallbestimmung beschreiben und was dokumentiert wird[Bearbeiten | Quelltext bearbeiten]

Äquivalenzklassezerlegung:

Eingabedaten werden in Klassen mit äquivalentem Verhalten eingeteilt und anschließend wird ein Repräsentant jeder Klasse für einen Testfall gewählt.

Kann durch eine Grenzwertanalyse erweitert werden -> Repräsentanten um Klassen-Grenzen wählen

Dokumentation:

  • Normal Fall / Spezialfall / Fehlerfall
  • Vorbedingungen (Eingaben,..)
  • evtl. Äquivalenzklasse
  • Erwartest Ergebnis
  • Tatsächliche Ergebnis

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2022-06-30
  • 2023-06-28
  • 2023-08-24
  • 2023-09-27

🤯Was ist der Deming cycle? Skizzieren Sie diesen.[Bearbeiten | Quelltext bearbeiten]

Der Deming oder PDCA-Cycle ist ein 4 stufiger Prozess zur konitnuierlichen Verbesserung.

Die vier Phasen:

P..Plan: Planung der Umsetzung und erkennen von Verbesserungspotenzialen

D..Do: Ausprobieren/Testen des Konzepts (Prototyp)

C..Check: Prüfen des Prototypen.

A..Act: Umsetzung des Plans auf großer Front.


Note: Da in den Folien nur das Diagramm abegebildet ist, ist die beschreibung von Wikipedia zusammengefasst.

Was ist der Demming Zyklus und erkläre wie er mit Softwaremetriken zusammenhängt. (Gastvortrag)[Bearbeiten | Quelltext bearbeiten]

Der Deming- oder PDCA-Cycle ist ein 4 stufiger Prozess zur kontinuierlichen Verbesserung.

Die vier Phasen:

  • Plan: Planung der Umsetzung und erkennen von Verbesserungspotenzial
  • Do: Ausprobieren/Testen des Konzepts (Prototyp)
  • Check: Prüfen des Prototypen
  • Act: Umsetzen des Plans auf großer Front

Zusammenhang zu Softwaremetriken:

  • Plan: Metriken und KPIs (Key Performance Indicators) erstellen/definieren
  • Do: Software erstellen
  • Check: Metriken messen
  • Act: Korrekturen vornehmen -> Softwarequalität verbessern

    Andere Prüfungen mit ähnlicher/selber Frage:

  • 2023-08-24
  • 2023-09-27

Ausgewählte Software Prozesse[Bearbeiten | Quelltext bearbeiten]

Software Life-Cycle skizzieren[Bearbeiten | Quelltext bearbeiten]

Der Software Life-Cycle, gezeigt in folgender Abbildung, beschreibt ein Basiskonzept für Software Engineering Prozesse und Vorgehensmodelle.

Der typische Life-Cycle eins Software-Projekts als Basis für Prozesse und Vorgehensmodelle.

Wasserfall Modell erklären und skizzieren. Nennen Sie auch Vor- und Nachteile.[Bearbeiten | Quelltext bearbeiten]

Das Wasserfall-Modell ist eine Umsetzung des Life-Cycles aus den 80er Jahren das einfach Anzuwenden ist und eine Schwerpunkt auf Dokumentation legt. Der Ablauf ist skizziert in folgender Abbildung. Zu den Vorteilen zählt:

  • Backtracking zu früheren Entwicklungsphasen.
  • Risikominimierung durch Abschluss einer Phase.
  • Weite Verbreitung und hoher Bekanntheitsgrad.
  • Strikte Trennung der einzelnen Phasen.
  • Unterstützung von kleinen Entwicklungsteams.

Nachteile:

  • Alle Tasks einer Phase müssen abgeschlossen werden (keine parallele Entwicklung möglich).
  • Starke Auswirkung von Fehlern in früheren Phasen auf das Entwicklungsprojekt.

Anwendung bei guten Kenntnissen über die Anforderungsdomäne und nur bei klar definierten und vollständigen Anforderungen.


Ablauf von Projekten mit dem Wasserfall-Modell.

V-Modell erklären und skizzieren. Nennen Sie auch Vor- und Nachteile.[Bearbeiten | Quelltext bearbeiten]

Das V-Modell ist ein Vorgehensmodell welches dem Wasserfallmodell ähnlich ist, aber zusätzliche Phasen für die Qualitätssicherung einführt, welche den Entwicklungsphasen gegenüberstehen. Der Ablauf ist in folgender Abbildung dargestellt.

Vorteile:

  • Spezifikationsphase vs. Realisierung und Testen.
  • Kontext von Produkten und Tests.
  • Verschiedene Abstraktionslevels (User, Architektur, Implementierung).
  • Fehlerbehandlung in frühen Phasen (Reviews).
  • Basiskonzept für VM 97 und VM XT.

Nachteile:

  • Klare Beschreibung der Systemanforderungen ist wichtig.
  • Hoher Dokumentationsaufwand.
  • Kritisch bei unklaren/veränderlichen Anforderungen.

Anwendung bei großen Projekten im öffentlichen Bereich mit klar definierten Anforderungen.


Ablauf des V-Modell

SCRUM Prozess erklären und skizzieren. Nennen Sie auch Vor- und Nachteile.[Bearbeiten | Quelltext bearbeiten]

SCRUM ist ein agiler Software Prozess für kleine aber hoch-effiziente Teams (bei großen Projekten sind auch mehrere Teams möglich). Das flexible Prozessmodell erlaubt es auf sich ändernde Anforderungen im Projektablauf zu reagieren. Entsprechend dem Agilen Manifest stehen (Teil-)Produkte frühzeitig zur Verfügung (frühe und kontinuierliche Auslieferung). Generell erfüllt SCRUM einen hohen Anteil der agilen Prinzipien.

Der SCRUM-Prozess ist dargestellt in folgender Abbildung.

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.


Ablauf des SCRUM-Prozesses.

12 Prinzipien des Agilen Manifests (Multiple-Choice) (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Multiple-Choice (was gehört dazu).

12 agile Prinzipien:

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung von Software zufrieden zu stellen.
  2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
  3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
  4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
  5. 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.
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch Face-to-Face.
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
  9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
  10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

international version:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-03-20
  • 2019-01-21

Was ist Prozess Tailoring?[Bearbeiten | Quelltext bearbeiten]

Generische Entwicklungsprozesse die angepasst werden müssen an die individuelle Projektgegebenheiten.

Ersetzen einzelner Prozess-Schritte (oder Vorgehensbausteine) durch passende alternative Lösungen.

Individuelle Projektplan Anpassung.

Einzelne Prozessschritte durch Alternativen ersetzen.

Erfordert: Erfahrene Projektleiter da ein fundiertes Verständnis des Modellaufbaus erforderlich ist. Die Berücksichtigung von definierten Tailoring-Kriterien.

Process Tailoring wird eingesetzt, da standatisierte Software-Prozesse, aufgrund einer Vielzahl von zu berücksichtigenden Projektattributen, in der Praxis eher schwer einsetzbar sind.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2022-06-30

Design Patterns[Bearbeiten | Quelltext bearbeiten]

Vorteile von Design Patterns sowie Beispiele[Bearbeiten | Quelltext bearbeiten]

Elemente:

  • Benutzerfreundlichkeit
  • Support
  • Prägnanz
  • Vollständigkeit
  • Formalismus
  • Ausdruckskraft

Vorteile:

  • Gleicher Wortschatz spart Diskussionen
  • Hilft komplexe Systeme zu verwalten
  • Vereinfacht nicht-funktionale Anforderungen
  • Minimiert Entwicklungszeit und -kosten
  • Verbessert die Dokumentation

Beispiele:

  • Singleton
  • Factory
  • Proxy
  • Decorator

Welche Design Pattern gibt es?[Bearbeiten | Quelltext bearbeiten]

Fundamental Pattern - deal with essential concepts of software architecture

  • Interface: Separate Interface description and concrete implementation, defines the signature operations of an entity
  • Delegation: extention of functionality without inheritance
  • Immutable: provides unchangable object after initialization

Creational Patterns - deal with initailizing and configuring classes and objects

  • Singleton – Provision of a single instance only
  • Factory – Method in a derived class creates associates
  • Abstract Factory – higher abstraction by grouping individual factiories with a common theme

Structural Patterns - deal with decoupling interface and implementaion of classes and objects

  • Facade – Facade simplifies the interface for a subsystem
  • Adapter – Translator adapts a server interface for a client
  • Proxy – One object approximates another

Behavioral Patterns - deal with dynamic intactions among objects

  • Observer – Dependents update automatically when a subject changes
  • Decorator – Decorator extends an object transparently
  • State – Object whose behavior depends on its state
  • Strategy – Vary algorithms independently
  • Chain of Responsibility – Request delegated to the responsible service provider
🔴 Ab hier ab 2022 nicht mehr relevant. (außer Kreativaufgaben)

Gastvortrag: Feedback[Bearbeiten | Quelltext bearbeiten]

Warum ist Feedback wichtig? Nennen Sie fünf Arten wie man Feedback im Rahmen eines Software-Projektes einholen kann (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Menschen verstehen die Umwelt durch Interaktion und Rückmeldung, d.h. Feedback ist für das Verständnis der Umwelt sehr wichtig. Zusätzlich kann durch rechtzeitiges Feedback die Zeit in sinnlosen Projekten minimiert und Fehler früh erkannt werden. In Software-Projekten kann Feedback auf viele Arten eingeholt werden:

  • Prototypen
  • Code Review, Pair Programming
  • Neue Features sofort Testen (am besten durch Kunden)
  • Usability Tests
  • Architektur top-down aus dem Elfenbeinturm (???)

Warum ist Feedback wichtig und wie soll es aussehen? (2019-03-20)[Bearbeiten | Quelltext bearbeiten]

Menschen verstehen die Umwelt durch Interaktion und Rückmeldung, d.h. Feedback ist für das Verständnis der Umwelt sehr wichtig. Zusätzlich kann durch rechtzeitiges Feedback die Zeit in sinnlosen Projekten minimiert und Fehler früh erkannt werden.

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, d.h. regelmäßig positive Rückmeldungen, Feedback institutionalisieren (Pair-Programming, Code-Reviews, 1:1 Meetings, Pull Requests)

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-01-21

PM - Teil 2[Bearbeiten | Quelltext bearbeiten]

Motivationspyramide nach Maslow zeichnen und erklären. Nennen Sie auch ein Alternativ Modell für menschliche Motivation. (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Die Motivationspyramide nach Maslow ist eine polythematische Theorie zur Erklärung menschlichen Verhaltens welche von fünf hierarchischen Kategorien menschlicher Bedürfnisse ausgeht. Erst wenn die unteren Stufen in einem gewissen Ausmaß befriedigt sind wird die darauf Aufbauende verfolgt. Die Pyramide ist in folgender Abbildung dargestellt und umfasst folgende Kategorien:

  1. Grund- oder Existenzbedürfnisse (Physiologische): Lebensnotwendige Bedürfnisse wie z.B. Nahrung und Schlaf.

  2. Sicherheit: Absicherung bezüglich Schutz des Lebens, des Eigentums, Lebensstandard, Schutz vor Arbeitslosigkeit, Unfallfolgen bis hin zur Altersvorsorge.

  3. Sozialbedürfnis: Gruppenzugehörigkeit, soziale Akzeptanz, Freundschaft, Zuneigung, etc.

  4. Anerkennung und Wertschätzung (Achtung): Unterscheidung zwischen Selbst- und Fremdachtung. Wird gesteuert durch das Erleben der eigenen Leistung und der resultierenden Anerkennung. Umfasst auch Kompetenz, Status, Respekt.

  5. Selbstverwirklichung: Das Verlangen des Individuums, zu verwirklichen, was es potentiell ist, d.h. seine potentiellen Fähigkeiten zu entfalten. Menschen in dieser Stufe werden weitgehend durch die Freude motiviert und versuchen einen starken Einfluss auf ihre Umwelt auszuüben. Sie sind kreativ aktiv, leistungsorientiert und versuchen ihre Fähigkeiten weiterzuentwickeln.

    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.

Alternative monothematische Theorien sind z.B. der Sexualtrieb (Freud) oder Minderwertigkeitskomplex (Adler). Andere polythematische Theorien sind z.B. das ERG-Modell (Existence, Relatedness, Growth) nach Adlerfer oder die zweidimensionale Arbeitszufriedenheitstheorie von Herzberg.

Bedürfnispyramide nach Maslow.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-03-20
  • 2019-01-21

Team-Organisation: vier Formen und vier Richtlinien nennen (2019-07-04)[Bearbeiten | Quelltext bearbeiten]

Formen der Team-Organisation:

  • klassisch hierarchische Organisation
  • typische Matrix-Organisation
  • Chef-Programmierer-Team
  • offen strukturiertes Team
  • SWAT-Team (Erklärung)
  • XP-Team (Extreme Programming)

Richtlinien zur Team-Organisation:

  • Setzen Sie weniger (!) Leute ein.
  • Stellen Sie den Teammitgliedern Aufgaben, die zu ihren Fähigkeiten passen.
  • Stellen Sie den Teammitgliedern Aufgaben, die zu ihren Interessen passen.
  • Achten Sie mittelfristig auf die persönliche Entwicklung der Mitarbeiter.
  • Achten Sie auf eine balancierte und harmonische Mischung.
  • Lösen Sie sich von Leuten, die nicht zum Team passen.

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2019-03-20
  • 2019-01-21


Beispiele für Kreativaufgaben[Bearbeiten | Quelltext bearbeiten]

🤯Kreativaufgabe Hotelkette[Bearbeiten | Quelltext bearbeiten]

Angabe Hotelkette

Team aufstellen

  • 4 köpfiges Team
  • Projektleiter und. technischer Architekt
  • Frontend Dev
  • Backend Dev
  • Tester

Prozess auswählen

  • Agiler SE Prozess:
  • Wenige Entwickler, mittelgroßes Projekt mit einigen unklaren Anforderungen, z.b Kunden sperren , muss noch abgeklärt werden
  • Vermutlich Erweiterung in Zukunft möglich deswegen Scrum
  • SCRUM: kleine hocheffiziente Teams, Sprint im Vordergrund, Anforderungsänderungen schnell umsetzbar, hocheffizient

Meilensteine aufstellen

  1. Kick Off Meeting
  2. Projektfreigabe
  3. Anforderungsreview
  4. Entwurf-Design Review
  5. Sprint 1- n Design Review
  6. Produktabnahme

Nicht funktionale Anforderungen bestimmen: Sicherheit, Geschwindigkeit, Usability

Burndown Chart analysieren (agile Verstoße nennen)

Andere Prüfungen mit ähnlicher/selber Frage:

  • 2023-08-24
  • 2023-09-27

Multiple Choice Fragen[Bearbeiten | Quelltext bearbeiten]

🤯Falls sich wer erinnern kann bitte die ergänzen.[Bearbeiten | Quelltext bearbeiten]

Block 1:

...

Block 2:

...🥳