Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

SE AI > Project Management > Flashcards

Project Management Flashcards

1
Q

Unterschied von Projektprogress in ML vs SE

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Was sind Ursachen dafür, dass 87% der ML Projekte scheitern, bzw. 53% der ML Prototypen nicht die Produktion erreichen?

5

A
  • Unklares Projektziel
  • ML Ziel =!= Business Ziel
  • Unkoordinierte Arbeite von DS vs SE
  • Explodierende Kosten für Expertise und Hardware
  • Komplexität des Projektes benötigt versch. Skills (SE, DevOps, Data Science, Data Engineer, …)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Was ist Hoftstadter’s Law?

A

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Nenne Gründe gegen AI Software

3

A
  • Errors Costs > Improvement Costs
  • Entscheidungen müssen erklärbar sein
  • Entwicklung muss schnell gehen -> Starte mit Heuristiken
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

4 Gründe für Automatisierung

A
  • Mehr Effizienz
  • Mehr Sicherheit für Menschen
  • Weniger langweilige Tasks
  • Ermögliche Funktionalität, die Menschen ohne Automatisierung nicht beherrschen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

4 Gründe für Augmentation (Zunahme)

A
  • Höhere Kundezufriedenheit bei Aufgabe
  • Mehr User Control
  • Mehr Kundenverantwortung
  • Mehr Kreativität
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Definiere den Lebenszyklus eines ML-Projekts

(4)

A

Scoping & Planning < Data < Model < Deployment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Was gehört zu Scoping & Planning hinzu? (ML LC)

3

A
  • Define Projekt Goals
  • Specify Requirements
  • Allocate Ressources

Model metric does not align with project goal; performance unsatisfiable/disappointing; requirements revisiting

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Was gehört zu Data hinzu? (ML LC)

4

A
  • Define and collect Data
  • Preprocessing
  • Label
  • Organize Data

Data mismatch (different distribution in production); rare cases required; bias found

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Was gehört zu Model hinzu? (ML LC)

5

A
  • Model Selection
  • Training
  • Experimantation
  • Error Analysis
  • Debugging

*Production performance != training performance; non-functional properties not met; *

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Was gehört zu Deployment hinzu? (ML LC)

3

A
  • Deploy model
  • monitor and maintain system
  • feedback loop
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Wie geht man an AI-Projekte heran?
Ziel: Budgetierung

4 + Budgetierung

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Was sind Probleme an der folgenden Metrik für AI System “Credit Card Fraud”:

“Success the more unauthorized withdrawals we block”

2

A
  • Bestes Outcome wird erreicht, wenn das System alle Transaktionen blockt
  • Je mehr Transaktionen geblockt werden, desto mehr wird sich das herumsprechen, desto weniger Leute werden es bei der Orga versuchen -> Es wird angeblich schlechter über Zeit (bei Design)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Beschrifte die Achsen

A

Impact & Feasibility

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Feasibility Pyramid for Cost Drivers + je 3 Beispielfragestellung

A

DMD

Difficulty
Availlability of Similar Solutions, Education, Ressource for Training, Deployment

Model Accuracy
Cost of wrong predictions, mininmum accuracy, retrain frequency

Data Availlability
Data aquiration, labeling and amount

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Was sollte man bei der Datenverfügbarkeit und der Modellkomplexität beachten, wenn man über die Machbarkeitsanalyse nachdenkt?

Daten(2), Model(1)

A
  • Wie schnelllebig sind die Daten?
  • Zu welchen benötigten Informationen habe ich keinen Zugriff?
  • Wie viel kostet ein Inferenzschritt?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Techniken für die Verbesserung der Machbarkeit

4

A
  • keine 100% Accuracy Produktdesigns!
  • Keine Abhängigkeit von einem einzigen Modell
  • Sicherheitsmechanismen für KI-Nutzung (Anzeige bei guter Pseudo-Wahrscheinlichkeiten)
  • Alpha-Test (Experimental)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Manage and Mitigate Risk
1. -> 2. -> 3.

A

1.Identify -> 2. Mitigate -> 3. Monitor

  1. Identifizierung
  2. Mildern / Reduzieren
  3. Beobachten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Was ist eine von Amazon erfunden gängige Methode für Riskmanagement?

A

Scoreboards in verschiedenen Kontexten:

z. B. :
- Project
- Finance
- Project Processes
- Data Quality
- Summary

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Nenne die 3 Meilensteine um den Progress und Fokus für Entwicklungsstresspunkte im Auge zu behalten

A
  1. Domain Expertise
  2. Reproduziere Arbeit von anderen mit ähnlichen Zielen
  3. Automatisiere das Training und Inferenz Pipeline abgeleitet von 2.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Nenne den 1. Meilenstein während der Projektmanagement Phase ganz am Anfang und beschreibe, was ihn ausmacht.

3 + 3

A

Domain Expertise

**Starte einfach **
- kein ML / nur Heuristiken
- Wie lösen Menschen das Problem derzeit?
- Wie würdest du mit den aktuellen Daten es manuell lösen?

Schau dir die Daten zuerst an
- Exploratory Data Analysis (EDA)
- Manuelle Validierung der Annahmen
- Manuelles Labeln für Heuristiken zum Lösen des Problems

22
Q

Nenne den 2. Meilenstein in AI-Software Engineering und beschreibe, was ihn ausmacht.

Idee + 2

A

Reproduziere ähnliche Arbeit

Idee: Was sind die technologischen Einschränkungen

  • Ähnliche open source Repos finden
  • Ähnliche ML / DL Modelle finden
23
Q

Nenne den 3. Meilenstein in PM und beschreibe, was ihn ausmacht.

A

Simple Pipelining

Baue eine minimalistische einfache Pipeline
a) Training Pipeline
b) Inference / Production Pipeline

24
Q

Nenne mögliche Datenquellen für Training

6

A
  • Web-Archive
  • reddit/r/datasets
  • Kaggle
  • UCI ML Repo
  • Crawling
  • Simple Google Search
25
Q

Nenne mögliche ML-Modell Hubs

A
  • Paperswithcode
  • Huggingface
26
Q

Nenne Steps in der Training Pipeline

7

A
27
Q

Nenne Steps in der Production / Inference Pipeline

7

A
28
Q

Nenne die Project Archetypes für AI-Software Projekte

3

A
  • Improve existing process
  • augment manuel process
  • automate manuel process
29
Q

Definiere den Archytype “Improve existing process” und nenne Beispiele

A

Automatisiere, beschelunige, reduziere Fehler oder verbessere Antworten von existierenden Prozessen

Beispiel: Code Completion, Customized Recommender Systems

30
Q

Definiere den Archytype “augment manuel process” und nenne Beispiele

A

Unterstütze manuelle Aufgaben mit Empfehlungen, Korrekturen und Alternativen

Beispiele:
- Slide Designer
- Transcription Engine
- Rechtschreib und Grammatikhilfe

31
Q

Definiere den Archytype “automate manuel process” und nenne Beispiele

A

Ersetze manuelle Prozesse durch automatische KI-Prozesse

Beispiele:
- Selbstfahrende Autos
- Chatbots
- Customer Support
- Website Designs

32
Q

Nenne verschiedene Projekterwartungen / Ziele

A

Wirtschaftlich: Mehr Profit, Weniger Kosten
Sozial: Nutzerfreundlichkeit, Mehr Nutzerzufriedenheit
Technologisch: Nutzung neuer Technologie im Unternehmen (zukunftssicherheit)

33
Q

Erkläre anhand des Beispieles (Organisatorisch vs Futuristisch) warum verschiedene Ziele von verschiedenen Projekterwartungen abstammen.

A

Organisatorisch: Profit, Umwelt, Sozial
- > Schwer den Bezug zu KI zu finden
- > Wird durch mehr als das KI Projekt beeinflusst
- > Effekte sind nicht direkt messbar

Futuristisch: Kundenzufriedenheit, -engagement
- > Könnte Organisatorische Ziele positiv beeinflussen
- > Effekte durch kleine Änderungen schwer messbar

34
Q

Nenne drei Erfolgskriterien für KI-Projekte

A

(1) Definiere das gewünschte Ziel
(2) Defniere einen Plan, der beschreibt wie du das Ziel erreichen kannst
(3) Definiere Metriken, die deinen direkten Erfolg messen

35
Q

Under the bottom line: Was ist das ultimative ML Ziel ?

(1) (1)

A

Business: Increase Profit
Non-Profit: Improve Society

36
Q

Wie kann man die Business value messen?

A

Meistens nicht durch die model performance!

  • Logging der Software
  • Nutze nur zielführende Metriken
  • Guardrail Metriken (Gegenmetriken im A/B Test)
37
Q

Was sind Guardrail Metriken?
Beschreibe das Beispiel von Airbnb

A

Guardrail Metriken sind Gegenmetriken in A/B Tests, die gewisse Folgeeffekte messen sollen.

Wenn zum Beispiel eine Änderung einen positiven Effekt auf die Registrierungen des Dienst hat, aber die Käufe zurückgehen, sind die Anzahl der Käufe ein Guardrail-Metrik.

Airbnb hat bei der Prozessänderung “Anzeigen der Hausregeln bei der Buchung” gesehen, dass die Buchungen zugenommen haben, aber die Guardrail Metrik “Bewertung” verschlechterte sich. Stakeholder wurden informiert und der Test wurde eventuell abgebrochen.

38
Q

Nenne 5 Verantwortlichkeiten eines AI Teamleiters und mögliche Hindernisse

A

Responsibilities
- Hire the right people
- Manage and develop people
- Managing teams’ output and align goals
- Good long-term decisions and technical debt
reduction
- Manage expectations from leadership

Obstacles
- Education, composition, scarcity of people and
limited budget
- Diverse roles, technology-hyped, CV-driven
- Timelines and uncertainty
- Technical debt (pipeline erosion), unclear
technological trend
- Management level often have a limited or false
understanding of „artificial intelligence“

39
Q

Nenne 2 * 3 Organisatorische Anti-Patterns im Gebiet “Organizational Silos” und deren Gründe

Organizational Anti-Patterns

A

Model to Production Integration

Anti-Patterns
1. long discussion over details due lack of abstractions, documentation and processes
2. complaints driven by lack of understanding
3. blocked data scientists due their responsibility to productionize the model

Gründe
1. Verschiedene kulturelle Hintergründe zwischen DS und SE
2. DS hat keinerlei Kenntnisse in SE Prinzipien
3. SE hat keinerlei Grundkenntnisse in ML Basics

Data Producer vs Data Consumer

Anti-Patterns
1. Requesting Data is hard
2. Zwei Teams (Producer & Consumer) sind sehr eng miteinander verbunden in der SW und Data Store, aber arbeiten in Silos -> unbemerkte Fehler beim Kunden
3. unvollständige Daten im Producer Team können zu schlechter Performance in Production führen

Gründe
1. Fehlendes Bewusstsein
2. Fehlende gemeinsame Ziele
3. Fehlende Dokumentation
4. Unklare Verantwortlichkeiten

40
Q

Nenne 4 + 2 Recommendations im Gebiet “Organizational Silos” gegen Organizational Anti-Patterns

Organizational Anti-Patterns

A

Model to Production Integration
1. Model Registry & Feature Store
Sorgt für ein sauberes Interface und Übersicht für mehrere Teams
2. Cross-Functional Teams
Schließt die Lücke zwischen DS und SE; verhindert Knowledge Silos
3. Paare DS mit SE (Code Reviews)
4. Übersetzungsarbeit zwsichen verschiedenen Rollen und gemeinsame Ziele von DS + SE

Data Producer vs Data Consumer
1. Baue Bewusstsein auf für Data Producers, dass Daten benötigt werden
2. Stelle eine zentrale Plattform bereit zwischen Data Producers und Data Consumers, welche die Daten zum Entdecken verfügbar macht und Standards, Metriken und Dokumentationen enthält

41
Q

Nenne 3 + 2 Organisatorische Anti-Patterns im Gebiet “Kommunikation” und deren Gründe

Organisatorische Anti-Patterns

A

Redundante Entwicklung

Anti-Patterns
1. Features sind nicht erkundbar, zugreifbar oder wiederverwendbar
2. Jede Model Entwicklung benötigt deren eigene Rohdaten und Preprocessing -> Redundante ML Infrastructure und Tools
3. Shadow IT -> Teams nutzen lieber self-hosted IT Solutions mit schlechter Security als verfügbare dedizierte zentrale Infrastruktur Provider

Gründe
1. Fehlende Schnittpunkte zwsichen Teams, Dokumentation, kein Vertrauen

Management vs Data Science

Anti-Patterns
1. Data Scientists haben Probleme ihre Rolle zu erfüllen -> Burn-out (unproduktiv, keine nützlichen Resultate für das Unternehmen, endlose Iteration ohne Progress)
2. Gereizte Stimmung zwischen DS und Management (*DS sind oft direkt aus akad. Laufbahn -> Wenig Erfahrung mit ROI, Business Value, … *)

Gründe:
1. Fehlende DS Prozesse (Research orientierte Entwicklung ist zu unsicher -> es benötigt SCRUM o.ä.)
2. Kommunikationsprobleme in komplexen Themen zwischen Fachleuten und Nicht-Fachleuten
3.

42
Q

Nenne 2 + 2 Recommendations im Gebiet “Kommunikation” gegen Organizational Anti-Patterns

Organisatorische Anti-Patterns

A

Redundante Entwicklung
1. Vereinigung und Erkundung durch Zentralisierung (Feature Stores, etc ermöglichen viele Teams zur Zusammenarbeit und Kommunikation
2. Verbessere die Verständnis zwischen Teams durch Showcase Meetings

DS vs Management
1. Neue eindeutige Entwicklungsprozesse müssen implementiert werden -> Experimentiell getrieben
2. Dokumentation und Bericht erstattung ermöglichen bessere Kommunikation mit nicht-technischen Personen

43
Q

Nenne 2 + 1 + 3 Organisatorische Anti-Patterns im Gebiet “Vacuum” und deren Gründe

Organisatorische Anti-Patterns

A

Headless Chicken Hiring
1. Personal mit unzureichenden Fähigkeiten
2. Eingestellte DS mit Inselwissen in einem Spezialaufgabe werden obsolet nachdem die Aufgabe erfüllt wurde

Gründe
1. Unklare Rollen und Titel
2. Unqualifizierter einstellender Manager
3. Zu wenig suchende Arbeitnehmer mit notwendigen Fähigkeiten

Résumé-driven Development
1. Ausgesuchte Tools, Libraries, Frameworks passen nicht zum Produkt oder Team

Gründe
1. DS identifizieren sich nicht mit dem Business Value (Fokussieren sich nur auf technischen Erfolg)
2. Fehlender Entscheidungsträger im Team

Hype-Driven Development
1. Viele PoC’s, keine Produkte
2. Keine Analyse über die tatsächlichen Teile in der Anwendung, welche von ML profitieren könnte (Einstellung: alles profitiert von ML)
3. Produkt ist nicht machbar, wegen fehlender Daten oder Expertise

Gründe
1. Fehlende unternehmerische Strategie, Regelungen und Strukturen (e.g. unmanaged Data Collection Processes)
2. Management hat keine ML Kenntnisse
3. Schlechte Übersetzung der Business Goals in die technologischen Ziele
4. Fehlende Product-Metrics, da DS nicht in der Lage ist für das Produkt relevante Metriken aufzustellen

44
Q

Nenne 1 + 1 + 3 Recommendations im Gebiet “Vacuum” gegen Organizational Anti-Patterns

Organizational Anti-Patterns

A

Headless Chicken Hiring
1. Stelle Fähigkeiten und Potentiale ein anstelle von Jobtitel

Résumé-Driven Development
1. Nutze existierende Technolgien aus anderen Abteilungen als Fallback Alternative, falls es keine Authorität gibt, welche diese genehmigen muss

Hype-Driven Development
1. Nutze Prozesse, welche machbare Use-Cases identifizieren und Produkt Roadmaps erstellen (Awareness Raising, Proposals für Machbarkeitsschätzungen, Datenverfügbarkeit, …)
2. DS sollten mit Kunden kommunizieren
3. Education um Datenverfügbarkeit aufzuzeigen

45
Q

Zähle organisatorische Best-Practice Empfehlungen auf

Organisatorische Best Practice

A
  1. Cross-Functional Teams (in gemeinsamen Büro)
  2. Das Besitzen des kompletten Prozesses von Datenextraktion bis Deployment für ein Team sorgt für einen Full-Stack View
  3. Zentralisierte Infrastruktur mit separaten Infrastruktur-Team vereinheitlicht Porzesse und Tools für mehrere ML Teams innerhalb einer Orga
  4. Startups stellen Allrounder ein, je größer das Produkt desto spezialisierte die neuen Angestellten
  5. Separierung des DS Prozesses mit T-Shaped Knowledge Base sorgt für spezialisierte Teilgebiete mit guten Überblick (Data Prepro T Feature Engineering T Learning & Validation)
  6. Dokumentation Artifakte, Code und Prozesse um Kommunikationsprobleme zu lösen -> Notwendige Voraussetzung für Unterscheidung zwischen Produkt & Dev Team
  7. Nutze Agiles Projektmanagement
  8. Um den Wert einer ML Lösung herauszufinden, können Kosten von Alternativlösungen ohne interner ML Lösung berechnet werden
  9. Nutze dedizierte Lösungen wie Model Registry und Feature Store, um klare Qualitäts Spezifikationen aufzustellen und umzusetzen
  10. Favorisiere Proaktive Kommunikation: Identifiziere Stakeholder, setze Meetings an um mit Techs Entscheidungen zu kommunizieren; Kommuniziere, was Teams leisten bzw. delivern müssen; Die wenigsten werden mir proaktiv die Informationen liefern, die ich benötige
  11. Führe diversifizierte Teams ein

AAC DDD FPS VZ

46
Q

Nenne und beschreibe kurz 5 verschiedene unternehmerische Archetypes (ML Unternehmen)

Organisatorische Best Practice

A
  1. **Novel or Ad-hoc ML **
    No or limited ML Knowledge in-house; selten umsetzbare Modelle; wenig Risiko
  2. ML in R&D
    Unternehmen macht R&D Abteilung auf; schwierig an Daten zu kommen; ML Modelle selten produktiv
  3. ML eingebaut im Business / Produkt
    Produkt Teams haben ML Kenntnisse; ML ist in Entscheidungen beachtet; -> schwierig Talente zu bekommen, ML Projektzyklus oft nicht im Einklang mit SW
  4. Independent ML Team
    Separater ML Teammanager; unterschiedliche ML Rollen; Budget für Investitionen eingeplant; EInfacher an qualifiziertes Personal zu kommen
  5. ML First
    CEO geht ALL-IN ML; ML Divisionen; Große ML Expertise in allen Bereichen; Datenverfügbarkeit überall; Einfache Deployments, Schwierig ML First zu werden; Teuer; ….
47
Q

Nenne 5 organisatorische Entscheidungen, welche vorher getroffen werden sollten.

Organisatorische Best Practice

A
  1. Haben wir unterschiedliche Teams für ML Research und Product Development / Deployment
  2. Wie viel SE Knowledge ist benötigt, brauchen wir ML Pipelines?
  3. Wer ist verantwortlich für Daten (Sammeln, Labeln und Preprocessing)
  4. Wer macht die Qualitätskontrolle
  5. Ist das ML Team verantwortlich ihre Models in der Produktion zu warten?
48
Q

Nenne 5 Best Practice Richtlinien in Teams

Organisatorische Best Practice

A
  1. Interdisziplinäre Teams für bessere Bildung, Verständnis und Knowledge Silos
  2. Collaboration Points: Klare Verantwortlichkeiten und Team-Schnittpunkte (Meetings, Tools, …)
  3. Key Task ist Productionizing of a Product
  4. Prozess und Planen: Investiere in klare Prozesse und plane voraus anstatt ad-hoc (e.g. OKR)
  5. Limitiere die durch Komplexität und Tools eingeführte kognitive Belastung des Teams -> sonst werden Teams unproduktiv
49
Q

Wie genau kann man bestehende kognitive Überlastung in Teams senken. Gehe auf die drei Haupttypen ein.

Organisatorische Best Practice

A

Haupttypen:
1. Skills (intrinsic) -> Regression, Python
2. Mechanismen (extraneous) -> How to Deploy
3. Domain Knowledge (germane) -> Which Products?

Minimiere äußerlich & maximiere relevant

50
Q

Was ist Ensemble Programming?

Organisatorische Best Practice

A

Mehrere Entwickler gleichzeitig an einem einzigen Computer

Dieses kollaborative Vorgehen fördert den Wissensaustausch, reduziert Fehler und ermöglicht es, verschiedene Perspektiven und Lösungsansätze zu kombinieren.

51
Q

Was ist Domain Driven Design und wie beeinflusst es die kognitive Belastung in SE Teams

Organisatorische Best Practice

A

Domain-Driven Design (DDD) ist eine Softwareentwicklungsmethode, die darauf abzielt, komplexe Softwareanwendungen zu entwerfen, indem sie eng an die Domäne (das Geschäftsfeld) und dessen Begriffe angepasst wird. Der Fokus liegt auf einer klaren Kommunikation zwischen Entwicklern und Fachexperten und darauf, das Domänenwissen im Code zu verankern.

  • Reduzierte Komplexität:
    Durch die klare Trennung von Domänen in Bounded Contexts wird die Komplexität des Systems in kleinere, besser verständliche Teile aufgeteilt.
    Gemeinsame Sprache: DDD fördert eine Ubiquitous Language, die von Entwicklern und Fachexperten verwendet wird, um Missverständnisse zu minimieren und die kognitive Last zu verringern.
52
Q

Gehe auf das Team Topologies Konzept ein. Welche vier Haupt-Topologien für das Entwickeln von modularisierter Software gibt es?

Wie helfen diese die kognitiven Belastung zu reduzieren?

Organisatorische Best-Practice

A
  • Streamlined Team: End-2-End Entwicklung von Features bis Deployment
  • Enabling Team: Baut unterstützende Services
  • Komplizierte Subsysteme: Teams, welche sich nur darauf konzentrieren (KI, Encryption)
  • Plattform Teams: Biete fundamentelle Technologien an (zB Infrastruktur)

Enabling, Subsystems und Plattform Teams helfen den Stream-Line Teams durch reduzierte kognitive Belastung. Das Stream-Line Team schafft die Main-value des Unternehmens

SE AI (11 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions