TU Wien:Software Engineering und Projektmanagement VO (Biffl)/Fragenkatalog: Unterschied zwischen den Versionen

Aus VoWi
Zur Navigation springen Zur Suche springen
(+intro)
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 357: Zeile 357:
 
12 agile Prinzipien:
 
12 agile Prinzipien:
  
# Unsere höchste Priorität ist es,den Kunden durch frühe und kontinuierliche Auslieferungwertvoller Software zufrieden zu stellen.
+
# Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung von Software zufrieden zu stellen.
# Heiße Anforderungsänderungen selbst spätin der Entwicklung willkommen. Agile Prozesse nutzen Veränderungenzum Wettbewerbsvorteil des Kunden.
+
# Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
# Liefere funktionierende Softwareregelmäßig innerhalb weniger Wochen oder Monate undbevorzuge dabei die kürzere Zeitspanne.
+
# Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
# Fachexperten und Entwicklermüssen während des Projektestäglich zusammenarbeiten.
+
# Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
# Errichte Projekte rund um motivierte Individuen.Gib ihnen das Umfeld und die Unterstützung, die sie benötigenund vertraue darauf, dass sie die Aufgabe erledigen.
+
# 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.
# Die effizienteste und effektivste Methode, Informationenan und innerhalb eines Entwicklungsteams zu übermitteln,ist im Gespräch von Angesicht zu Angesicht.
+
# Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch Face-to-Face.
# Funktionierende Software ist daswichtigste Fortschrittsmaß.
+
# Funktionierende Software ist das wichtigste Fortschrittsmaß.
# Agile Prozesse fördern nachhaltige Entwicklung.Die Auftraggeber, Entwickler und Benutzer sollten eingleichmäßiges Tempo auf unbegrenzte Zeit halten können.
+
# Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
# Ständiges Augenmerk auf technische Exzellenz undgutes Design fördert Agilität.
+
# Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
# Einfachheit – die Kunst, die Menge nichtgetaner Arbeit zu maximieren – ist essenziell.
+
# Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
# Die besten Architekturen, Anforderungen und Entwürfeentstehen durch selbstorganisierte Teams.
+
# Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
# In regelmäßigen Abständen reflektiert das Team,wie es effektiver werden kann und passt seinVerhalten entsprechend an.
+
# In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
  
 
Andere Prüfungen mit ähnlicher/selber Frage:
 
Andere Prüfungen mit ähnlicher/selber Frage:
Zeile 445: Zeile 445:
 
Richtlinien zur Team-Organisation:
 
Richtlinien zur Team-Organisation:
  
* Setzen Sie weniger (!) Leute
+
* Setzen Sie weniger (!) Leute ein.
 
* Stellen Sie den Teammitgliedern Aufgaben, die zu ihren Fähigkeiten passen.
 
* Stellen Sie den Teammitgliedern Aufgaben, die zu ihren Fähigkeiten passen.
 
* Stellen Sie den Teammitgliedern Aufgaben, die zu ihren Interessen passen.
 
* Stellen Sie den Teammitgliedern Aufgaben, die zu ihren Interessen passen.

Aktuelle Version vom 9. November 2019, 19:31 Uhr

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

Inhaltsverzeichnis

Einführung in Projektmanagement[Bearbeiten]

Was ist ein Projekt? Durch welche Merkmale ist es definiert?[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]

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

Was ist Projektmanagement?[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.

Nennen Sie drei Stakeholder, die Einfluss auf die Anforderungen haben. Begründen Sie Ihre Antworten. (2019-01-21)[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]

  • 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).

Einführung in Software Engineering[Bearbeiten]

Unterschied zwischen Embedded Systems und kommerzieller Software anhand von fünf Kriterien vergleichen.[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]

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

Bei zentralen SCM gibt es einen Server welcher das Repository, das ist dargestellt in Abbildung [fig:scmcentral]. 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 [fig:scmdist]. 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.)


caption Funktionsweise eines zentralen SCM


caption Funktionsweise eines verteilten SCM

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

2 Arbeitsablauf SVN (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]

Continuous Integration Werkzeuge unterstützen 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 Abbildung [fig:ci] 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).


caption Ablauf eines Continuous Integration Prozesses

Andere Prüfungen mit ähnlicher/selber Frage:

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

Beschreiben Sie Inversion of Control (IOC). (2019-03-20)[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: Unity Framework, Spring .NET, Ninject, Autofac

Software Engineering Phasen[Bearbeiten]

Beschreiben Sie Traceability. Welche Arten von Traceability gibt es? (2019-07-04)[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]

(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), Skizze in Abbildung [fig:sysintegrationbigbang].

    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 [fig:sysintegrationtopdown].

    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 [fig:sysintegrationbottomup].

    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 [fig:sysintegrationbuild].

    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.


caption Skizze der Big-Bang Systemintegration Strategie


caption Skizze der Top-Down Systemintegration Strategie


caption Skizze der Bottom-Up Systemintegration Strategie


caption Skizze der Build Systemintegration Strategie

Blackbox/Whitebox Multiple Choice (2019-07-04)[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]

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 ({\textstyle <} statt {\textstyle \leq}).

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?
  • Erwartetest 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-03-20
  • 2019-01-21

Nennen Sie drei Techniken zur Wartung. (2019-03-20)[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

Modellierung von Anwendungsprozessen[Bearbeiten]

QS in SE-Projekten[Bearbeiten]

Beschreiben und skizzieren Sie den Ablauf eines Reviews. (2019-01-21)[Bearbeiten]

Der Ablauf ist in Abbildung [fig:reviewprocess] 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.


caption Ablauf eines Reviews

Ausgewählte Software Prozesse[Bearbeiten]

Skizzieren Sie den Software Life-Cycle.[Bearbeiten]

Der Software Life-Cycle, gezeigt in Abbildung [fig:swlifecycle], beschreibt ein Basiskonzept für Software Engineering Prozesse und Vorgehensmodelle.


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

Erklären und skizzieren Sie das Wasserfall Modell. Nennen Sie auch Vor- und Nachteile.[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 Abbildung [fig:waterfall]. 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.


caption Ablauf von Projekten mit dem Wasserfall-Modell.

Erklären und skizzieren Sie das V-Modell. Nennen Sie auch Vor- und Nachteile.[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 Abbildung [fig:vmodel] 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.


caption Ablauf des V-Modell

Erklären und skizzieren Sie den SCRUM Prozess. Nennen Sie auch Vor- und Nachteile.[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 Abbildung [fig:scrum].

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.


caption Ablauf des SCRUM-Prozesses.

Was gehört zu den 12 Prinzipien des Agilen Manifests? Multiple-Choice (2019-07-04)[Bearbeiten]

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.

Andere Prüfungen mit ähnlicher/selber Frage:

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

Gastvortrag: Feedback[Bearbeiten]

Warum ist Feedback wichtig? Nennen Sie fünf Arten wie man Feedback im Rahmen eines Software-Projektes einholen kann (2019-07-04)[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]

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

Design Patterns[Bearbeiten]

Gastvortrag: Dynatrace[Bearbeiten]

PM - Teil 2[Bearbeiten]

Zeichnen und erklären Sie die Motivationspyramide nach Maslow. Nennen Sie auch ein Alternativ Modell für menschliche Motivation. (2019-07-04)[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 Abbildung [fig:maslow] 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.


caption Bedürfnispyramide nach Maslow. Von LMU Dozent Medizin (Diskussion) 04:47, 23. Sep. 2017 (CEST) - Eigenes Werk (Originaltext: selbst erstellt), CC BY-SA 3.0 de, https://commons.wikimedia.org/w/index.php?curid=62696203

Andere Prüfungen mit ähnlicher/selber Frage:

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

Nennen Sie vier Formen und vier Richtlinien zur Team-Organisation. (2019-07-04)[Bearbeiten]

Formen der Team-Organisation:

  • klassisch hierarchische Organisation
  • typische Matrix-Organisation
  • Chef-Programmierer-Team
  • offen strukturiertes Team
  • SWAT-Team (???)
  • 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