1. Einführung in Projektmanagement
1.1. 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 sequenzielle Entwicklungsprozess basiert auf stabilen Anforderungen. Anforderungen ändern sich allerdings oft, was bei sequenziellen Vorgehensmodellen in der Regel dazu führt, dass das Endprodukt nicht mehr den Anforderungen entspricht.
Beim kontinuierlichen Modell wird iterativ gearbeitet, der Funktionsumfang steigt mit jeder Iteration, gesteuert durch den Soll-Ist-Vergleich → auf Anforderungsänderungen kann besser reagiert werden
1.2. Was ist ein Projekt? Durch welche Merkmale ist es definiert?
Ein Projekt ist ein einmaliges Vorhaben mit einem definierten Anfang, einem definierten Ende und mehreren beteiligten Personen.
1.3. Welche 3 Kennzeichen hat ein Projekt?
• Ihre Abgrenzbarkeit bezüglich: Aufgabe, Ergebnis, Ressourceneinsatz und Zeitrahmen
• Komplexität der Aufgabe
• Einmaligkeit der Aufgabe
1.4. Was ist Projektmanagement?
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
1.5. Nenne 3 Stakeholder, die Einfluss auf die Anforderungen haben und begründe dies.
• Kunde: Der Kunde hat eine Idee oder ein Bedürfnis, welches durch das zu entwickelnde Produkt abgedeckt werden soll
• Entwickler: Entwickler nimmt Einfluss auf die Anforderungen, indem er Wissen über technische Möglichkeiten einfließen lässt. Bewertet Vorstellungen des Kunden technisch, beschreibt und verwirklicht diese.
• 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.
1.6. Nennen und beschreiben Sie 4 Arten von Anforderungen. Wie wirken sich die unterschiedlichen Anforderungen auf die unterschiedlichen Stakeholder aus?
Hauptziel: ein System zu entwickeln, dass die Anforderungen möglichst aller Stakeholder berücksichtigt
• Funktionale Anforderungen: Was soll umgesetzt werden? Wie soll sich das System verhalten?
• Nicht-funktionale Anforderungen: zielen nicht direkt auf die Funktionalität ab z.B. Leistung, Sicherheit, Usability, Wartbarkeit
• Designbedingungen: Worauf soll beim technischen Entwurf geachtet werden z.B. Schnittstellen, Entwicklungsumgebung
•
1.7. Nenne 3 typische Gründe warum ein Projekt Zeit-/Kostenrahmen überschreitet?
• Mangelnde Anforderungen: Die Anforderungen decken sich nicht mit den Erfordernissen oder sind unklar/mehrdeutig formuliert.
• Mangelnde 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).
2. Einführung in Software-Engineering
2.1. Wie unterscheiden sich kommerzielle Software von eingebetteten Systemen?
Nutzen Sie hierfür die nachfolgende Tabelle für Ihren Vergleich. Nennen Sie zusätzlich jeweils zwei Beispiele für die jeweiligen Arten.
Eingebettete Systeme Kommerzielle Software Steuerung Ereignisgesteuert, oft auch
vollständig automatisiert
Benutzergesteuert Kosten Teuer, wegen Neuentwicklung oder
Anpassung
Kaufen billiger als selbst entwickeln Zuverlässigkeit Sehr wichtig Oft nicht entscheidend
Wartung Schwierig, z.T. Hardware-technisch unmöglich
Meist professioneller Support Sicherheit Müssen sicher sein Unterschiedliche Wichtigkeit: Online-
Banking, Datenbank Systeme vs.
Fotobearbeitung Usability Benutzerinterface rudimentär oder
nicht vorhanden
Oft entscheidend, vor allem bei großer Konkurrenz
Beispiele Handysteuerung, Lift-Steuerung, ABS, Ampel
Datenbanksystem, Web-Applikation, Texteditor
3. Technik und Werkzeuge
3.1. Was sind die Aufgaben eines Sourcecode Management Systems (SCM)?
Beschreiben Sie den Arbeitsablauf, wie bei verteilten SCM Systemen mit Konflikten umgegangen wird!
Aufgaben eines SCM:
• Parallele Projektentwicklung auf mehreren Zweigen
• Transparente Änderungen
• Nachvollziehbare Entwicklungsgeschichte
• Zugriff auf ältere Versionen
Arbeitsablauf eines verteilten SCM System bei Konflikten: z.B.: GIT 1. Kopie des Haupt-Repository (clone)
2. Lokale Änderungen 3. Lokale Commits 4. Merge
a. Push b. Pull Request
Arbeitsablauf eines zentralen SCM System bei Konflikten: z.B.: SVN 1. Update
2. Lokale Änderungen 3. Update
a. Änderungen remote und lokal b. Merge
4. Commit
3.2. Was sind die Unterschiede zwischen zentralen/verteilten SCM? Nennen Sie jeweils Vor- und Nachteile.
Bei zentralen SCM gibt es einen Server, welcher das Repository ist.
Alle SCM-Operationen müssen über das Netzwerk an den Server geschickt werden.
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).
Vorteile von zentralen SCM:
• Die Clients benötigen nicht alle Dateien und Versionen und kommen mit weniger Speicherplatz aus.
Bei verteilten SCM wird das Repository geklont und lokal auf jedem Client gespeichert. Meist gibt es auch einen Server mit Main-
Repository mit welchem sich die Clients regelmäßig synchronisieren.
Vorteil von verteilten SCM:
• Alle SCM Operationen können lokal ausgeführt werden.
Nachteil von verteilten SCM:
• Große Menge an Daten werden beim Klonen übertragen und beim Client gespeichert.
3.3. Beschreibe und skizziere CI (Continuous Integration)
CI-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/e Entwickler/in eine neue Version im SCM erstellen (Commit, Pull-Request o.ä.).
Das CI Werkzeug reagiert auf dieses Ereignis und lädt die entsprechende Version. Anschließend wird das Build Tool gestartet und das Kompilat mit einem Test-System automatisiert getestet. Im letzten Schritt werden die Entwickler/innen verständigt und ein Bericht und das ausführbare Software-Artefakt verteilt.
3.4. Beschreibe IOC (Inversion of Control)
Abhängigkeiten werden von einem Container verwaltet, die Komponenten wissen nichts darüber. Die Abhängigkeiten werden injiziert. Vorteile von IOC:
• 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
• .NET: Unity Framework, Spring .NET
3.5. 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.
Herausforderungen:
• Große geographische Distanzen → kein Face-2-Face, Austauschen von Handzeichnungen erschwert
• Verschiedene Arbeitszeiten
• Verschiedene Zeitzonen
Verwendete Kommunikation: asynchrone Kommunikation Beispiele:
• Wiki, CMS
• Mailingliste / Forum
• Issue-Tracker
4. Software Engineering Phasen
4.1. Beschreibe Traceability. Welche Arten von Traceability gibt es?
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.
Mit Hilfe 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?
3 Arten von Traceability:
• Vertikale Traceability: Beziehungen innerhalb einer Phase und eines Artefakt-Typs, z.B.: System – Subsystem – Komponente
• Zeitliche Traceability: Zeitliche Nachvollziehbarkeit unterschiedlicher Releases, z.B.: durch Konfigurationsmanagement
• Horizontale Traceability: Beziehungen zwischen unterschiedlichen Entwicklungsartefakten, z.B.:
Anforderungen - Implementierung - Testfälle
4.2. Was ist System Integration und welche Modelle gibt es? Erstellen Sie je eine Skizze und nennen Sie Vor- und Nachteile.
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 System Integration. Für die Systemintegration gibt es mehrere Modelle:
• Big-Bang: Alle Modelle werden gleichzeitig integriert
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 Vorteile: Ausführendes 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-Top: Schrittweise Integration ausgehend von der Hardware Vorteile: Stabiles System (basierend auf HW Interfaces), Schrittweise Integration in Richtung Business Cases
Nachteil: 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, Phasenweise Integration
Vorteile: Frühe Verfügbarkeit von funktionalen Anforderungen, Prototyp und Demo, Berücksichtigung priorisiertes Anforderungen möglich Nachteile: Wiederverwendung von Komponenten kann schwierig sein, Regressionstests erforderlich
4.3. Blackbox /Whitebox Multiple Choice
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
4.4. Beschreiben Sie den Prozess des Testfallbestimmens. Was muss dokumentiert werden?
Eine Möglichkeit Testfälle zu bestimmen ist die Äquivalenzklassenzerlegung. Hierbei werden die Eingabedaten in Klassen mit demselben (ä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 Systems vor Testausführung
• Ä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
4.5. Nenne 3 Techniken zur Wartung
• Herstellen des Produktverständnisses: Das Verständnis fremder Codestücke kann – speziell bei mangelnden Aufzeichnungen – sehr zeitaufwendig sein. Key-Tools sind Code-Browser und essenziell 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 u generieren.
5. Modellierung von Anwendungsprozessen
5.1. Was versteht man unter "Prozess Tailoring"? Warum ist dieses oftmals notwendig?
Standardisierte Software-Prozesse sind in der Praxis direkt eher schwer einsetzbar, da eine Vielzahl an Projektattributen berücksichtigt werden müssen. Beispiele: Projektgröße, Projekttyp,
Anwendungsdomäne.
• Anpassbarkeit eines generischen Entwicklungsprozesses an spezifische Projektgegebenheiten durch Prozess-Tailoring
• Ersetzen einzelner Prozess-Schritte durch passende alternative Lösungen
• Wiederverwendung von Best-Practices
• Individuelle Anpassung des Projektplans
• Achtung: Erfordert erfahrene Projektleiter, da ein fundiertes Verständnis des Modellaufbaus erforderlich ist
• Achtung: Berücksichtigung von definierten Tailoring-Kriterien und Produktabhängigkeiten
5.2. Was versteht man unter Prozess "Customization"?
• Verallgemeinerte Form des Tailoring
• Anpassung des Vorgehensmodells an unternehmensspezifische Gegebenheiten
• Effizienzsteigerung von Tailoring für ähnliche Aufgaben durch Customization
• Achtung: Kompatibilität zum zugrunde liegenden Prozess muss sichergestellt werden
6. QS in SE-Projekten
6.1. Beschreiben Sie die drei unterschiedlichen Teststufen. Geben Sie jeweils ein konkretes Beispiel für einen Test der jeweiligen Stufe an.
• Unit Test: Dokumentation von Klassen, Fokus auf Komponenten und Prüfung auf
Übereinstimmung zwischen Umsetzung der Komponente und der technischen Spezifikation Beispiel: Black-Box-Tests
• Integration Test: Test der Interaktion zwischen Modulen innerhalb eines (Sub-)Systems Beispiel: White-Box-Tests
• System Test: Fokus auf Übereinstimmung zwischen funktionalen und technischen Bedingungen des Gesamtsystems
Beispiel: White-Box-Tests
6.2. Beschreibe und skizziere den Ablauf eines Reviews
1. Planung: Objekt, Prüfziele, Auslösekriterien, 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.
7. Ausgewählte Software-Prozesse
7.1. Software Life-Cycle erklären und skizzieren.
Der Software Life-Cycle beschreibt eine
Basiskonzept für Software Engineering-Prozesse und Vorgehensmodelle.
• Anforderungen: Wünsche des Kunden an das Produkt
• Spezifikation: beschreibt das System aus technischer Sicht
• Planung: erstellen von Projektplan für Zeit, Dauer, Kosten
• Entwurf & Design: technische Lösung der Systemanforderungen
• Implementierung & Testen: Erzeugen des Software-Produkts
• Integration & Testen: Zusammenfügen und Test der einzelnen Komponenten
• Betrieb & Wartung: Fehlerbehebung, Unterstützung, Erweiterungen während des laufenden Betriebes
• Außerbetriebnahme: Nach der Einsatzphase muss das Software-Produkt kontrolliert aus dem Betrieb genommen werden.
7.2. Wasserfall Modell erklären und skizzieren
Ist einfach anzuwenden und ein Schwerpunkt ist die Dokumentation.
Vorteile:
• Backtracking zu früheren Entwicklungsphasen
• Risikominimierung durch Abschluss einer Phase
• Weite Verbreitung und hoher Bekanntheitsgrad
• Strikte Trennung der Einzelphasen
• 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
Anforderungsdomäne und nur bei klar definierten und vollständigen Anforderungen.
7.3. V-Modell erklären und skizzieren
ähnelt dem Wasserfallmodell, aber hat zusätzliche Phasen für die Qualitätssicherung, welche den Entwicklungsphasen gegenüberstehen.
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.
7.4. SCRUM Prozess erklären und skizzieren
Agiler Softwareprozess 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.
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 Entwicklungsteams bei Großprojekten
• Potenzielle Verunsicherungen aufgrund fehlender Zuständigkeiten und Hierarchien
• Potenzielle Unvereinbarkeit mit bestehenden Unternehmensstrukturen
8. Andere Fragen
8.1. Maslow-Pyramide zeichnen, erklären, Alternativmodell nennen
Die Maslow-Pyramide ist eine polythematische Theorie zur Erklärung des menschlichen Verhaltens, welches von 5 hierarchischen
Kategorien menschlicher Bedürfnisse ausgeht. Erst wenn die unteren Stufen befriedigt sind, wird die darauf Aufbauende verfolgt.
• Grund-/Existenzbedürfnisse: Lebensnotwendig z.B.: Schlaf, Nahrung
• Sicherheit: Absicherung bezüglich Schutz des Lebens, Eigentums, Lebensstandard, Schutz vor Arbeitslosigkeit
• Sozialbedürfnis: Gruppenzugehörigkeit, soziale Akzeptanz, Freundschaft, Zuneigung
• Anerkennung und Wertschätzung: Unterscheidung zwischen Selbst- und Fremdachtung, wird gesteuert durch das Erleben der eigenen Leistung und der resultierenden Anerkennung
• Selbstverwirklichung: Das Verlangen des Individuums zu verwirklichen, was es potenziell ist, d.h. seine Fähigkeiten zu entfalten,
Alternative monothematische Theorien:
• Sexualtrieb (Freud)
• Minderwertigkeitskomplex (Adler) Andere polythematische Theorien:
• ERG-Modell (Adlerfer)
•
8.2. Nenne und erkläre 6 Wege, die zur Verhinderung von Teambildung führen
• Defensives Management: jede Entscheidung wird vom Management getroffen, Teammitglieder werden entmündigt
• Bürokratie: das sinnlose Produzieren von Projektdokumenten, das von der eigentlichen Arbeit abhält
• Physikalische Trennung: räumliche Trennung von Personen, die zusammenarbeiten sollten
• Zersplitterung der Zeit der Mitarbeiter: Aufteilung der Mitarbeiter auf mehrere Projekte
• Qualitätsreduktion der Produkte: unter dem Argument der Kostenreduktion → Effekt ist eine geringere Identifikation der Mitarbeiter mit dem Projekt
• Scheintermine: unrealistische Termine bewirken, dass sich MA nicht ernst genommen fühlen
→ geringe Identifikation der MA mit dem Projekt
• Cliquenkontrolle: Veränderung der Teamstruktur während des Projekts bzw. Zerschlagung von Teams nach Projektende
8.3. Was ist Feedback? Warum ist Feedback wichtig? Wie soll es aussehen?
5 Arten wie man Feedback im Rahmen eines Software-Projekts einholen kann
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 sonnlosen Projekten minimiert und Fehler frühzeitig erkennt werden.
Beim Feedback beachten:
• Höflich und wertschätzend
• Negatives unter vier Augen
• Feedback ist eigene Meinung – nicht die „Wahrheit“
• Über das Problem, nicht über die Person sprechen Arten, wie man Feedback einholen kann:
• Prototypen
• Code Review, Pair Programming
• Neue Features sofort Testen (best case: durch Kunden)
• Usability Tests
• Architektur top-down aus dem Elfenbeinturm
8.4. Team-Organisation: Nenne 4 Formen und 4 Richtlinien?
Formen der Team-Organisation:
• Klassische hierarchische Organisation
• Typische Matrix-Organisation
• Chef-Programmierer-Team
• Offen strukturiertes Team
• SWAT-Team
• XP-Team (externe Programmierung) 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
8.5. Nennen und beschreiben Sie jeweils zwei Faktoren, die die Produktivität von Menschen beeinflussen bzw. nicht beeinflussen.
Beeinflussen:
• Teampartner: Hohe Korrelation zwischen den Leistungen der beiden Teampartner
• Arbeitsplatz: Qualität des Arbeitsplatzes hat starken Einfluss auf die Leistung Nicht beeinflussen:
• Programmiersprache: innerhalb einzelner Sprachgruppen gibt es die gleiche Leistungsverteilung wie über alle Sprachen hinweg, Ausnahme: Assembler
• Berufserfahrung: kein sichtbarer Zusammenhang zwischen Jahren an Berufserfahrung und den erbrachten Leistungen
• Anzahl an Fehlern: Auch wenn Aufgaben mit null Fehlern bewältigt werden, ist man nicht schneller als mit Fehlern
• Gehalt: es gibt nur eine schwache Beziehung zwischen Gehalt und Leistung
8.6. Nennen und beschreiben Sie vier Wege zur Auswahl von Mitarbeitern.
• Portfolio: Bewerber bringen eine Auswahl von Produkten ihrer bisherigen Tätigkeiten
• Eignungstest: Achtung: Eignungstests prüfen nur Fähigkeiten, die unmittelbar nach der Einstellung gefordert werden
• Anhörungen: Bewerber präsentieren Aspekte ihrer bisherigen Tätigkeit, hier hören auch Teampartner und nicht nur die Projektleitung zu
• Interview: mehrere Interview-Runden mit Bewerbern und einer kleinen Anzahl an Interviewern
8.7. Nennen Sie die Elemente von Design-Patterns! Warum ist es von Vorteil Design Patterns zu verwenden (4 Gründe)?
Elemente:
• Benutzerfreundlichkeit
• Support
• Prägnant
• Vollständigkeit
• Formalismus
• Ausdruckskraft Vorteile von Design Patterns:
• Gleicher Wortschatz spart Diskussionen
• Hilft komplexe Systeme zu verwalten
• vereinfacht nicht-funktionale Anforderungen
• minimiert Entwicklungszeit und -kosten
• verbessert die Dokumentation
9. PRAXIS-Teil
9.1. Hotelbeispiel
Sie sind der leitende Projektmanager eines kleinen Software-Unternehmens und sollen folgenden Auftrag einer mittelgroßen europäischen Hotelkette gemeinsam mit Ihrem Projektteam umsetzen. Die aus acht Häusern bestehende Hotelkette möchte das Reservierungs- und
Mitarbeiterverwaltungssystem zentralisieren. Dazu soll ein webbasiertes Softwaresystem entworfen werden, das die folgende, durch den Kunden formulierte, Funktionalität abbildet:
• Ein Haus stellt eine Filiale der Hotelkette dar. Jedes Haus ist mit Namen und Adresse erfasst.
Zu jedem Haus werden die Mitarbeiter erfasst.
• Mitarbeiter können als Manager, Rezeptionisten oder als allgemeines Personal geführt werden. Manager und Rezeptionisten können in mehreren Häusern arbeiten. Das allgemeine Personal ist einem einzigen Haus zugeordnet.
• Weiters werden zu jedem Haus die Zimmer erfasst. Jedes, Zimmer gehört einer
Zimmerkategorie (Standard, Superior, Deluxe, Standard Suite, Junior Suite, Superior Suite) an.
Weiters wird zu jedem Zimmer die Zimmernummer, das Stockwerk und die Anzahl der Betten erfasst. Sollte ein Zimmer nicht buchbar sein (z.B. wegen einer defekten sanitären Anlage), dann ist dieses Zimmer aus dem Buchungsprozess auszuschließen (sperren). Es soll auch zu einem späteren Zeitpunkt immer nachverfolgbar sein, wann ein Zimmer gesperrt war und aus welchem Grund.
• Kunden werden mit ihren individuellen Daten erfasst. Eine eindeutige Identifikation geschieht über eine Kundennummer. Unter Umständen wird es später notwendig, einzelne Kunden zu sperren (z.B.: falls der Kunde in der Vergangenheit schon Zimmer gebucht hat, diese aber dann nicht bezahlt hat). Der Auftraggeber klärt hier die rechtlichen Gegebenheiten noch ab.
• Jeder Kunde kann als Stammkunde ausgezeichnet werden. Wann welcher Kunde als Stammkunde geführt wird, obliegt dem jeweiligen Hotelpersonal, allerdings soll ersichtlich sein, welcher Mitarbeiter den Kunden zu einem Stammkunden gemacht hat. Zu jedem Stammkunden können individuelle Wünsche notiert werden, welche hausspezifisch sind (z.B.:
Kunde XY bevorzugt hofseitiges Zimmer in den höheren Etagen; Kunde Z möchte keine Bananen im Obstkorb; ...).
• Eine Buchung kann ein oder mehrere Zimmer umfassen. Sämtliche Buchungen werden dem durchführenden Manager oder Rezeptionisten zugeordnet Zu jeder Buchung ist ein
buchender Kunde zu erfassen, sowie eventuell weitere mitreisende Personen die ebenfalls Kunden sind. Jede Buchung enthält die notwenigen Informationen (wie zB. Anreisedatum, Abreisedatum, Gesamtpreis pro Nacht). Wurde eine Buchung bezahlt, so sind zu dieser Buchung die Daten der Zahlung zu speichern. Die Zahlung kann als Barzahlung,
Kreditkartenzahlung oder in kombinierter Form durchgeführt werden. Jede Zahlung enthält den bezahlten Beitrag und das Bezahldatum. Wird eine Zahlung nicht von dem buchenden Kunden durchgeführt, so muss dies ebenfalls erfasst werden können. Eine Zahlung ist sowohl bar als auch mit Kreditkarte möglich.
1. Analysieren Sie die Angaben des Kunden. Das Projekt soll nach 6 Monaten abgeschlossen sein.
Stellen Sie ein Projektteam zusammen. Wie groß muss Ihr Projektteam sein und welche
projektspezifischen Expertisen sollen im Team vorhanden sein (gehen Sie hierbei speziell auf das beschriebene Projekt ein und begründen Sie Ihre Antwort)? (10 P)
1.1. 1 Projektleiter – immer notwendig
1.2. 3 Technischer Architekt – technische Umsetzung des Projekts 1.3. 2 Web Developer - Kommunikation zwischen den Häusern
1.4. 1 UI Entwickler – UI nur für geschultes Personal – muss nicht selbsterklärend sein 1.5. 1 Tester – um die einzelnen Meilensteine und das Gesamtsystem zu testen
2. Welchen Softwareentwicklungsprozess würden Sie aufgrund der Kundeninformation wählen und warum? Beschreiben Sie diesen kurz. (10 P)
SCRUM – es ist bei Änderungen sehr flexibel, da noch nicht alle Anforderungen klar definiert sind, praktisch, außerdem können einzelne Teile gut in verschiedene Sprints aufgeteilt werden:
SCRUM ist ein agiler Entwicklungsprozess, welcher für kleine Projektteams sehr gut geeignet ist.
Außerdem sehr flexibel bei ändernden Anforderungen. Es besteht aus einem Pregame (Vorbereitung, Planung der Sprints), beliebig vielen Sprints (Entwicklungsphase mit Tests und Anpassungen) und einem Postgame (Abschluss)
3. Sie haben sich für einen Softwareentwicklungsprozess entschieden. Definieren Sie sinnvolle Meilensteine, um dieses Projekt zu einem gelungenen Abschluss zu führen. (5 P)
Mitarbeiter und Zimmer eines Hotels speichern, Kunden speichern, Buchungen durchführen, Stammkunden speichern, mehrere Hotels integrieren, verschiedene Zahlungsarten, Zimmer sperren, Historie von gesperrten Zimmern
4. Definieren Sie 5 essenzielle nichtfunktionale Anforderungen des Projektes. (5 P) 4.1. Leistung und Performance
4.2. Usability und menschliche Faktoren 4.3. Sicherheit
4.4. Wartbarkeit 4.5. Erweiterbarkeit
5. Es wurde bereits versucht das Projekt mit einem anderen Projektteam zu realisieren. Das Team ist dabei nach SCRUM vorgegangen und konnte das Endprodukt nicht in einer zufriedenstellenden Qualität liefern. Ihnen liegt das Burndown-Chart des letzten Sprints vor. Beschreiben Sie anhand des Burndown-Charts drei mögliche Ursachen, welche zum Scheitern des Projektes geführt haben könnten. Markieren Sie die Stellen zusätzlich im Burndown-Chart. Welcher fundamentale
Grundsatz von SCRUM wurde von diesem Team verletzt? (10 P) Ursachen:
• Der Sprint war zu lange: durch das späte Review sind sehr spät sehr viele Änderungen/Anpassungen
notwendig geworden
• es wurden keine neuen Schätzungen gemacht
• es sollten täglich/wöchentlich Fortschritte passieren ->
Fehler im Projektmanagement / beim SCRUM Master
