Difference between revisions of "TU Wien:Software Engineering und Projektmanagement VO (Biffl)/Fragenkatalog"

From VoWi
Jump to navigation Jump to search
(verschiebe Themen an den Anfang von Überschriften um ein rasches Scannen zu ermöglichen)
 
Line 257: Line 257:
  
 
=== Ablauf eines Reviews beschreiben und skizzieren (2019-01-21) ===
 
=== Ablauf eines Reviews beschreiben und skizzieren (2019-01-21) ===
 +
 +
[[File:{{FILEPREFIX}}review_process.png|frame|Ablauf eines Reviews]]
  
 
Der Ablauf ist in folgender Abbildung skizziert und ist wie folgt:
 
Der Ablauf ist in folgender Abbildung skizziert und ist wie folgt:
Line 266: Line 268:
 
# '''Nachbearbeitung:''' Die dokumentierten Mängel korrigieren.
 
# '''Nachbearbeitung:''' Die dokumentierten Mängel korrigieren.
 
# '''Bewertung:''' Die Korrekturen überprüfen.
 
# '''Bewertung:''' Die Korrekturen überprüfen.
 
 
[[File:{{FILEPREFIX}}review_process.png|frame|none|Ablauf eines Reviews]]
 
  
 
== Ausgewählte Software Prozesse ==
 
== Ausgewählte Software Prozesse ==

Latest revision as of 19:18, 28 June 2020

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

Contents

Einführung in Projektmanagement[edit]

Was ist ein Projekt? Durch welche Merkmale ist es definiert?[edit]

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

Welche drei Kennzeichen hat ein Projekt?[edit]

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

Was ist Projektmanagement?[edit]

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)[edit]
  • 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)[edit]

  • 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[edit]

Embedded Systems und kommerzieller Software anhand von fünf Kriterien vergleichen[edit]

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[edit]

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

Funktionsweise eines zentralen SCM
Funktionsweise eines verteilten SCM

Bei zentralen SCM gibt es einen Server welcher das Repository, 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:

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)[edit]

Ablauf eines Continuous Integration Prozesses

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 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)[edit]

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[edit]

Traceability beschreiben. Welche Arten von Traceability gibt es? (2019-07-04)[edit]

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)[edit]

(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.
TU Wien-Software Engineering und Projektmanagement VO (Biffl)-Fragenkatalog - sysintegration bigbang.png
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).
TU Wien-Software Engineering und Projektmanagement VO (Biffl)-Fragenkatalog - sysintegration topdown.png
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.
TU Wien-Software Engineering und Projektmanagement VO (Biffl)-Fragenkatalog - sysintegration bottomup.png
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.
TU Wien-Software Engineering und Projektmanagement VO (Biffl)-Fragenkatalog - sysintegration build.png

Blackbox/Whitebox Multiple Choice (2019-07-04)[edit]

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)[edit]

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

Drei Techniken zur Wartung nennen (2019-03-20)[edit]

  • 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[edit]

QS in SE-Projekten[edit]

Ablauf eines Reviews beschreiben und skizzieren (2019-01-21)[edit]

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.

Ausgewählte Software Prozesse[edit]

Software Life-Cycle skizzieren[edit]

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.[edit]

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.[edit]

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.[edit]

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)[edit]

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.

Andere Prüfungen mit ähnlicher/selber Frage:

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

Gastvortrag: Feedback[edit]

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

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)[edit]

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[edit]

Gastvortrag: Dynatrace[edit]

PM - Teil 2[edit]

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

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)[edit]

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