Software Engineering 2 - Klausur HANNA NUR DIESES LERNEN BITTE Flashcards

Question

Wie kann eine BuildPipeline bei Continuous Integration aufgebaut sein?

Answer 1

**(Stage 1)** - Inspection (Runs Tools, Complexity, Static code) - Commit Build (Unit Test Cases, other basic tests) **(Stage 2)** - SecondaryBuild1 (Component Tests, System Test, Functional Tests) - SecondaryBuild2 **(Stage 3)** - Non-Functional Build1 (Long running Perfomance Tests, Non Functional Tests) - Non-Functional Build2

Answer 2

- Der Integrationsaufwand wird kontrollierbar - Probleme werden sofort sichtbar und können sofort behoben werden - Erfordert neben viel Technik auf viel Disziplin - Auch Deployments/Installations und Aufbau ganzer Testumgebungen automatisiertbar (Continuous Deployment)

Answer 3

- Entwicklungsflüsse optimieren - Flaschenhälse im Prozess erkennen und verringern

Answer 4

- Workflow visualisieren (Auch in Scrum) - Pull-Prinzip (Aufgaben werden durch Bearbeiter geholt nicht zugeordnet) - Work in Progress (WIP Limit) beschränkt Anzahl der Dinge im Zustand und lässt Flaschenhälse erkennen - Cycle time (einer Durchlaufzeit) messen und maximieren, Prozess optimieren, so dass die Durchlaufzeit niedrig und vorhersagbar ist - Unnötige Lagerzeit in einem Zustand minimieren - Funktioniert gut bei ähnlich dimensionierten Aufgaben und eingespielten Team

Answer 5

- Durch Normen - Durch Best-Practices

Answer 6

- Liegt im eigenen Ermessen - Ansprüche ändern sich (persönlich und unternehmerisch) - Das gemeinsame Verständnis über Qualität legt fest was man erreichen möchte

Answer 7

**In Analyse(5€)**: Bei Adressverwaltung fehlt Adresszusatz Kosten in Analyse einfügen, beschreiben, neue Version **In Entwurf (50€):** Komponenten, Klassen, Methoden, Persistenz, Prozessschrite Kosten in Implementierung **In Implementierung(500€):** Getestete Module ändern, neu testen, Testspezifikation erweitern, Designidee überdenken, Dokumentation Kosten **In Betrieb(5000€):** Daten neu importien, System entwickeln und parallel weiter betreiben, Temporäre Ersatzlösung(Excel?), Migration

Answer 8

**Direkte Kosten:** -Diskussion über Mängel) **Verstecke Kosten:** - Schwer zu erkennen - Fehlende Nachvollziehbarkeit - Fehlende Dokumentation - Schlechte Dateinamen - Können fast nie einem Verursacher zugeordnet werden, machen aber den Großteil der Gesamtkosten aus

Answer 9

**Stress:** - Keine Zeit - Überstunden **Unzufriedenheit:** - unrentable Projekte - unzufriedene Kunden - Kein Spaß **Unbrauchbarkeit:** - Programm kann etwas nicht - Messer schneidet nicht Qualität ist ein tiefes menschliches Bedürfnis

Answer 10

-Qualität kann nicht verordnet werden, sie muss gelebt werden

Answer 11

-Softwarequalität ist DIE GESAMTHEIT DER MERKMALE eines Softwareproduktes, die sich auf dessen Eignung beziehen, festgelegte und vorausgesetzte Erfordernisse zu erfüllen

Answer 12

**Nach Boehm:** _Produktqualität_ - Wartbarkeit (Prüfbarkeit, Änderbarkeit, Portabilität) - Brauchbarkeit (Zuverlässigkeit, Nützlichkeit, Bedienbarkeit) _Prozessqualität_ - außere Prozessqualität - Planungssicherheit (Termin Einhaltung, Aufwand Einhaltung) - innere Prozessqualität (Baustein Gewinn, Know-How Gewinn) **Nach ISO/IEC 25010:** - Brauchbarkeit - Kompatibilität - Performance - Zuverlässigkeit - Sicherheit - Wartbarkeit - Portabilität

Answer 13

-Durch Qualitäts-Metriken

Answer 14

- Anzahl der Parameter - Zyklomatische Komplexität - Kohäsion und Kopplung - GUI-Styleguide - Testabdeckung(Coverage)

Answer 15

- Nein, sehr schwierig - Merkmale: _1. **Korrektheit** messen:_ - Ist die Korrektheit entscheidbar? - Formal beweisbar? - Tests nur Stichproben, vollständige Testabdeckung nicht möglich _2. **Ausfallsicherheit** messen:_ - Hardware Mean Time Between Failures - Software bei systematischen Fehlern oft eine Katastrophe und kaum Absehbar

Answer 16

- Die Metrik ist eine Funktion, um Elemente der Software - Entwicklung in eine (geordnete) Basismenge abbildet - Es gibt hunderte verschiedene Metriken für verschiedene Aspekte

Answer 17

**Was ist der Nutzen?** - Bewerten Qualität von Produkten und Prozessen - Prognosen zu Kosten, Termin, Qualität machen **Was ist der Schaden?** -Gefahr der Fehlinterpretation/falsche Aussagen * *Daher?** - Wenige, aber wichtige Metriken nutzen und abwägen

Answer 18

-Die **konsequente** Erhebung und Anwendung

Answer 19

- Liefern keine Ja/Nein Antwort - Sondern Informationen - Entwicklung und Auswahl von Metriken soll Entwicklung möglichst einfach helfen

Answer 20

- Liefert ein exaktes Bild eines Systems, Projektes, Prozesses - reduziert auf die wichtigen Aspekte

Answer 21

- Größen (Line of Code) - Komplexität (McCape-Metrik, Halstead-Metrik, Kopplung der Klasse, beispielsweise Anzahl der verbundenen Klassen oder Anzahl der Operationen) - Stil (Länge von Bezeichnern, Anteil Kommentar oder Leerzeilen, Jumps)

Answer 22

- Story Points - Function Points - Use-Case-Points

Answer 23

**Objektive Metrik (Einfache Metrik)** - Wie?: Durch das Messen und Zählen - Pro: exakt, automatisierbar - Con: Nicht sicher, keine Interpretation - Beispiel: Körpergröße, Luftdruck, Lines of Code **subjektive Metrik (Qualitätsbewertung)** - Wie?: Beurteilen durch Gutachten - Pro: Für komplexe Merkmale, plausible Ergebnisse - Con: Aufwändig, Qualität liegt am Gutachter - Beispiel: Gesundheitszustand, Wetterlage, Benutzerfreundlichkeit **Pseudometrik (Prognosen, Kostenschätzung)** - Wie?: Berechnen durch Messungen/Beurteilung - Pro: Aussage über nicht sichtbare Merkmale - Con: schwer nachvollziehbar -Beispiel: BMI, Produktivität

Answer 24

- Die **Komplexität** der Wartbarkeit eines Programmes sollte gering sein - Komplexität ist gering wenn es leicht verständlich und prüfbar ist (Wenige If-Else Verzweigungen) - Aus dem Kontrollflussgraphen eines Moduls ableitbar

Answer 25

**v(G) = e - n + p** für einen Kontrollflussgraphen G mit n Knoten und e Kanten; p ist die Anzahl der Außenverbindungen Beispiel: Programm mit einem Ein-Ausgang-\>p=2 Komplexität ist dann minimal v(G)= 0-1+2 **=1** - Lineare Verkettung (Sequenz) hat Komplexität 1 - Jede Verzweigung oder Schleife erhöht die Komplexität um 1

Answer 26

Wie oft beim Code-Review WTF gesagt wird ;)

Answer 27

-Beinhaltetet Tätigkeiten, um Vertrauen zu schaffen, dass eine Dienstleistung/Produkt die Qualität erfüllt

Answer 28

-Gesamtführende Aufgabe, welche die Qualitätspolitik, Ziele und Verantwortlichkeiten festlegen

Answer 29

Konstruktiv (Grade, CI, GIT) Organisatorisch (Software-Projekt-Management) Analytisch (Software Prüfung) - nicht mechanisch (Inspektion, Review) - mechanisch (Prüfung mit Rechner) - ausführen (dynamische Prüfung) - analysieren (Statische Prüfung) - Regeln prüfen - Konsistenzprüfung - quantitative Untersuchung

Answer 30

- Verfahren zur Anforderungsanalyse/Dokumentation/Freigabe - Dokumentenstandard (Lasten- und Pflichtenheft, Architekturbeschreibung, Testfallspezifikation, Protokolle) - Entwurfsmuster für die Softwarearchitektur - Codierungsrichtlinien - Continous Integration - Vorgehensmodelle - Schulungen - Meistensteine und Freigabewesen - Festlegen von Verantwortlichkeiten

Answer 31

- Coding Style (Einrückung) - Dumme Fehler (If Logik falsch) - Antipatterns nutzen (equals nicht auf null checken) - Schlechte Fehlerbehandlung (Stream nicht schließen) - Metriken (McCabe) - Technische Schulden (Leichen im Keller, Legacy, Notlösungen)

Answer 32

-Aufwand für Änderungen an Code/Erweiterungen die schlecht geschrieben sind

Answer 33

-CheckStyle ist ein Programm das für Java Style prüft und auch MacCabe-Metrik

Answer 34

**Findbugs** -kann Bugs finden **SonarQube** - Mächtiges Tool für Analysen - Kann verschiedene Metriken berechnen und Analysen durchführen und Ergebnisse darstellen - Auch für Gradle als Plugin und viele Sprachen

Answer 35

-Mockito zum Testen mit Mockup Objekten

Answer 36

- Einfaches Programm, welches drei ganzzahlige Parameter bekommt besitzt 2^48 Kombinationen - Testen würde an die 100 Jahre dauern **-\>Daher wenig Testfälle, die unterschiedliche Fälle abdecken**

Answer 37

- Einfaches Programm, welches aus vier Verzweigungen einer einer umfassenden Schleife besteht. - 100 Billionen unterschiedliche Abläufe **-\>Daher möglichst wenig Testfällle, die viel abdecken**

Answer 38

- Testen ist ein wichtiges Werkzeug der Qualitätssicherung QS (Andere Ansätze der QS: Reviews, Statische Analysen, Formale Verifikation) - Vollständige Testabdeckung ist nicht möglich wg. State Space Explosion Problem (Ziel mit wenig Tests viel abdecken) - Systematik beim Testen ist wichtig (Prozess, Heuristik, Methodik, Erfahrung)

Answer 39

- Testen zeigt die ANWESENHEIT von Fehlern (Keine Abwesenheit!) - Vollständige Tests sind nicht möglich -Mit dem Testen früh beginnen (Spät ist teuer) - Häufung von Fehlern (Oft nicht gleichmäßig verteilt) - Zunehmende Testresistenz (Testfälle prüfen, erweitern, modifizieren) - Testen ist abhängig vom Umfeld (Tests an Einsatzumgebung anpassen und Randbedingungen) - Kein Fehler weist nicht auf ein brauchbares System hin

Answer 40

**Als Certified Tester spricht man von:** **Statischen Tests(Testobjekt wird nicht ausgeführt)** - Untersuchung von Dokumenten - Code Ausdruck analysieren **Dynamischen Tests (Testobjekt wird ausgeführt)** - Fehler-orientiert (Ziel sie zu finden) - Komformitäts-orientiert (Testgegenstand verhält sich konform zu seiner Spezifikation; Abnahmetest) - Auch von Hand

Answer 41

**Vorteile** - Testen ist ein natürliches Prüfverfahren - Tests sind reproduzierbar - Investierter Aufwand mehrfach nutzbar - Zielumgebung wird mitgeprüft - Systemverhalten wird sichtbar **Nachteile:** - Ergebnisse werden überschätzt (Tests sind Stichproben!) - Nicht alle Eigenschaften testbar - Nicht alle Anwendungssituationen nachbildbar - Test zeigt die Fehlerursache nicht

Answer 42

-Ein Test muss systematisch sein!

Answer 43

- Randbedingungen sind präzise definiert(Programm, Übersetzer, Betriebssystem,Wer,Geräte) - Eingaben systematisch gewählt (Tastatur, Dateien, DB, Zustände) - Ergebnisse werden dokumentiert und nach vorher definierten Kriterien beurteilt

Answer 44

- Komponententest/Unit Tests (Testen einer Komponente/Moduls z.B. Klasse) - Integrationstest (Testen des Zusammenspiels mehrerer Komponenten) - Systemtest (Testen des Gesamtsystems ohne reale Nachbarsysteme) - Verbundtest (Testen der Software im Zusammenspiel mit den Nachbarsystemen) - Abnahmetest (Testen in der realen Einsatzumgebung beim Kunden mit dem Ziel das Projekt abzuschließen)

Answer 45

- Guide Development (Fehler vor und während Codens verhindern) - Qritique the Product (Fehler und Fehlende Features schnell finden) - Business Facing (Für die Anwender) - Technology Facing (Mehr Team-intern) TODO ?????

Answer 46

**Black-Box-Test(Funktionstest)** - Betrachtung des Systems ohne Interna zu kennen - Testfälle auf Basis der Spezifikation der geforderten Eigenschaften **Glass-Box-Test(Strukturtest)** - Betrachtung des Systems mit Wissen über Interna Unterscheidungen - Anweisungsüberdeckung (Alle Anweisungen wurden ausgeführt) - Zweigüberdeckung (Alle Vezweigungen wurden durchlaufen) - Termüberdeckung (Alle Terme die eine Verzweigung steuern wurden (z.B. true/false) ausgeführt

Answer 47

- Auswahl der Testfälle richtet sich nach Eingaben, Ausgaben und funktionellen Verknüpfung - Kein Wissen über intere Struktur des Testobjektes - Ziel: Bringt Eingabe X das erwartete Ergebnis Y? **Kriterien für die Auswahl von Testfällen** - Anweisungsüberdeckung(Alle Anweisungen wurden ausgeführt) - Zweigüberdeckung (Alle Vezweigungen wurden durchlaufen) - Termüberdeckung (Alle Terme die eine Verzweigung steuern wurden (z.B. true/false) ausgeführt

Answer 48

- Festlegung von Äquivalenzklassen (Teilbereiche des Wertebereiches die sich bei Fehlern gleich verhalten) - Auswahl eines Repräsentanten einer Klasse - Überprüfung auf Vollständigkeit Beispiel: Ganzzahliger Bereich a\<= W \<= n Enumeration {A,B,C} Wort W: 1. Zeichen = Buchstabe? **Gültiger Wert:** Ganzzahliger Bereich a\<= W \<= n W in {A,B,C} W.1 = Buchstabe **Ungültiger Wert:** W\< a W \> n W nicht in {A,B,C} W.1 ist kein Buchstabe

Answer 49

-Schritte: **1.** Ermittel für jede Eingabevariable den zulässigen Wertebereich **2.** Verfeinere die Äquivalenzklassen auf Basis der Spezifikation (Gültige Äquivalenzklasse, Ungültige, Vorbedingungen der Funktion) **3.** Auswahl von Repräsentanten der Äquivalenzklasse **4.** Testfälle definieren für Äquivalenzklassen **5.** Bei mehreren Parametern: Kombination aus Äquivalenzklassen

Answer 50

- \>Idee: In Verzweigungs/Schleifenbedingungen gibt es oft Grenzbereiche ab wann eine Bedingung noch zu trifft oder nicht mehr - \>Kombination mit Äquivalenzklassenbildung - Grenzen der Äquivalenzklassen testen - Jeder Rand einer Äquivalenzklasse muss in Testdaten vorkommen **Was sind Grenzwerte?** - Werte auf den Grenzen - Werte links und rechts neben den Grenzen - Kleinste und größte un/gültige Anzahl

Answer 51

- \>Testdaten identifizieren - Testdaten direkt auf oder neben den Äquivalenzklassen - Wertebereich: - Kleinste und größte un/gültige Werte und die daneben Beispiele: Natürliche Zahlen 1..255 -\> 0,1,255,266 Reelle Zahlen -1.0 .. 1.0 (3 Stellen) -\> -1.001, -1000, 1000, 1.001 Zeichenkette mit Länge \< 10 -\> Ketten der Länge 0, 1, 10, 11 Liste mit max. 100 Elementen -\> Listen der Länge 0, 1, 100, 101

Answer 52

**Fehler** ist die Nichterfüllung einer festgelegten Anforderung - Abweichung zwischen Ist/Soll Verhalten - Vorraussetzungen Soll muss in einer Art Spezifikation beschrieben sein **Mangel** liegt vor, wenn eine Anforderung nicht angemessen erfüllt wurde -Programm funktioniert, aber Dialog oder Speicher dauern zu lange, GUI unvollständig

Answer 53

**Fehler oder Mangel** wird erst bei der Ausführung bzw. beim Test der Software bemerkt **Error: Fehlbehandlung** -Handlung die zu einem Fehlerzustand/Verhalten führt wie Programmierfehler oder fehlerhafte Eingabe **Fault(bug):** Fehlerzustand -Fehlerhafte Zeile, die eine Fehlfunktion auslöst **Failure: Fehlerwirkung** -Ausfall einer Software, Dienste funktionieren nicht mehr

Answer 54

**Validation** - Haben wir das RICHTIGE SYSTEM gebaut? - Prüfung ob die Ergebnisse den Anforderungen einer Nutzung des Systemes entsprechen **Verifikation** - Haben wir das SYSTEM RICHTIG gebaut? - Prüfung ob die Ergebnisse einer Entwicklungsphase den Vorgaben der Dokumente entspricht

Answer 55

Grobe Anforderung: **-\>Beispiel fehlerhafte Anforderung** Anforderungsanalyse: Spezifikationsfehler(Fehler aus Anforderung) Entwurf: Entwurfsfehler Codierung: Fehler aus Codierung Test und Integration: unbekannter Fehler

Answer 56

- \>Frage sollte am Beginn des Projektes durch Teststrategie geklärt sein - \>Die Zeit ist nie um! - \>Metriken helfen, aber gezielt wählen! - Requirements-Coverage und Requirements -Tracking (Wieviele Anforderungen werden durch die Tests abgedeckt?) **Code-Coverage** - Statement-Coverage (Anteil der Anweisungen die ausgeführt werden) - Banch-Coverage (Anteil der Verweigungen die durchlaufen werden)

Answer 57

- Möglichst umfassende Prüfung der spezifizierten Funktionalität auf Basis der Anforderung erfassen - Nur relevante Testfälle testen - Die Soll-Ergebnisse der Spezifikation sollen gefunden werden

Answer 58

- Funktionsüberdeckung (Jede spezifierte Funktion mindestens einmal ausgeführt) - Eingabeüberdeckung (Jedes Eingabedatum in mindestens einem Testfall verwendet) - Ausgabeüberdeckung (Jede Ausgabesituation mindestens einmal erzeugt (Masken, Fehlermeldungen)

Answer 59

**Äquivalenzklassenbildung (Äk, Ä-Klassen)** - Repräsentative Menge von Eingabedaten - Eingaben in Äquivalenzklassen eingeteilt - Aus jeder Äquiklasse mind. ein Repräsentant getestet **Grenzwertüberprüfung** - Fehler an Grenzen zulässiger Datenbereiche - Testfälle für Grenzfälle definieren

Answer 60

**Alle Werte einer Äqzuivalenzklasse zeigen identisches Verhalten** - Alle Funktionen können getestet werden - Anzahl der Testfälle reduziert sich **Aber Äquivalenz ist hypothetisch** -Klassen werden nach Erfahrung und Intuition gebildet **Zerlegung mit Hilfe von:** - spezifierten Gültigkeitsbereichen - spezifizierten Sonderbehandlungen

Answer 61

**1. Schritt: Aufstellung von Eingabebedingungen** -Analysieren der Eingabebendingungen anhand Spezifikation mit Vor/Nachbedingung **2. Schritt: Bildung von Äquivalenzklassen** - Zu jeder Eingabebedingung - Gültige Äquivalenzklassen (Normalfälle) - ungültige Äquivalenzklassen (Sonderfälle) **2. Schritt weiter: Wertebereich, linear** - Spezifiziert eine Eingabebedingung einen Wertebereich(Bsp: 1 gültige ÄK -- 2 ungültige ÄK) - Bereich 1\<= Wert \<= 49 gültige ÄK: 1\<= Wert \<= 49 ungültige ÄK: Wert \<1, Wert \>49 - Hilfsmittel: Zahlenstrahl - Schrittweises Vorgehen: Äquivalenzklassen zu einer Bedingung Die Klassen mit jeder weiteren Bedingung weiter zerlegen **2. Schritt weiter: Datenstruktur (Mengengerüst)** - Wenn untere und obere Schranken angegeben (Bsp: 1 gültige ÄK -- 2 ungültige ÄK) - Beispiel: Eine Liste enthält 1 bis 155 Elemente gültige ÄK: 1 bis 155 Elemente ungültige ÄK 0, \> 155 Elemente 2. Schritt weiter: Aufzählung **Werte der Aufzählung gleich behandelt (Bsp: 1 gültige ÄK -- 2 ungültige ÄK)** -Beispiel: Aufzählung (rot, gelb, grün) gültige ÄK: (rot, gelb, grün) ungültige ÄK: Wert nicht in {rot, gelb, grün} **Werte der Aufzählung nicht gleich behandelt (Bsp: 1 gültige ÄK -- 2 ungültige ÄK)** -Beispiel: Aufzählung (rot, gelb, grün) gültige ÄK: Wert = rot, Wert = gelb, Wert = grün ungültige ÄK: Wert nicht in {rot, gelb, grün} -Man sollte die Äquivalenzklasse weite runterteilen bei nicht gleich behandelt

Answer 62

- Äquivalenzklassen bei mehreren Parametern int f (int x, int y) - wenn x \< 0 und y \< 0 dann f(x,y) = y - wenn x = 0 und y \> 10 dann f(x,y) = 42 - wenn 0 \< x \< 10 und y \> 100 dann f(x,y) = y \* y - Äquivalenzklassen bei Vorbedingung int f (int x, int y) Vorbedingung: x und y sollen positiv sein - wenn 0 \< x \< 10 und y \< 100 dann f(x,y) = y \* y - wenn x \>= 10 dann f(x,y) = 1

Answer 63

**3. Schritt: Repräsentanten wählen** -Einen Wert aus jeder gültigen und jeder ungültigen Äquivalenzklasse auswählen (Bei mehreren das Kreuzprodukt) **4. Schritt: Testfälle definieren** -Für jede Äquivalenzklasse besteht ein Testfall aus einem Repräsentanten und dem zugehörigen Sollwert nach Spezifikation

Answer 64

- \>Testfälle aus allen Repräsentanten kombinieren und nach Häufigkeit sortieren - Testfälle Reihenfolge nach Häufigkeiten priorisieren - Benutzungsrelevante Testfälle testen - Testfälle mit Grenzwerte oder Grenzwertkombination bevorzugen - \>Paarweise Kombination von Äquivalenzklasse-Repräsentation statt vollständiger Kombination - \>Minimalkriterium: Mindestens ein Repräsentant jeder Äquivalenzklasse in mindestens einem Testfall - \>Repräsentanten ungültiger Äquivalenzklassen nicht mit Repräsentanten anderer ungültiger Äquivalenzklassen kombinieren

Answer 65

- Test-Ende-Kriterium abhängig von durchgeführten Test der Repräsentanten der jeweiligen Äquivalenzklasse und Gesamtzahl aller Äquivalenzklassen - Äquivalenzklassen-Überdeckung = (Anzahl getestete Äquivalenzklasse / Gesamtzahl Äquivalenzklassen) \* 100% Beispiel: 18 ÄK davon 15 getestet; ÄK-Überdeckung = (15 / 18) \* 100% = 83,33% - Güte der Testfälle abhängig von der Aussagekraft der Spezifikation - Definition der Testfälle hängt nicht nur von den Eingabebedingungen ab, sondern auch Werte einer Äquivalenzklasse und Kombination ein Eingabebedingungen

Answer 66

**Idee:** In Verweigungs-/Schleifenbedingung gibt es Grenzbereiche für die eine Bedingung gerade noch zutrifft oder nicht mehr - \>Kombination mit Äquivalenzklassenbildung - Grenzen der Äquivalenzklasse testen - Jeder rand einer Äquivalenzklasse muss in Testdatenkombination vorkommen **Grenzwerte** - Werte auf den Grenzen - Werte rechts und links neben den Grenzen - Mengenwertige Bereiche (Datenstrukturen) - Kleinste und größte un/gültige Zahl -Zweitkleinse und Zweitgrößte gültige Zahl

Answer 67

**1. Schritt: Repräsentanten identifizieren** - Testendaten direkt auf oder neben den Grenzen der Äquivalenzklasse - Wertebereich: - gültige Testwerte: gültiger kleinster und größter Wert - ungültige Testwerte: direkt neben und außerhalb - Bsp: Natürliche Zahlen 1..255 (0,1,255,256) - Bsp: Listen maximal 100 Elemente (0,1,100,101) **2. Schritt: Sollwerte identifizieren** -Analog zu Äquivalenzklassentests

Answer 68

- \>Test-Ende-Kriterium - Grenzwert-Überdeckung = (Anzahl getestete Grenzwerte / Gesamzahl Grenzwerte) \* 100% - Ist bei richtiger Anwendung mit am effektivsten - Findet am häufig Fehler - Kreativität bei Erstellung der Testdaten nötig

Answer 69

Logischer Testfall 1 2 3 4 5 Firmenzugehörigkeit x 0\<=x\<=3 38 x\<0 Gratifikation in % 0 50 75 100 Gültige Grenzwerte 3 4,5 6,8 9 -1 Ungültige Grenzwerte 4 3,6 5,9 8

Answer 70

**Grenzen des Eingabebereiches** - Bereich [-1.0; +1.0] (Testdaten -1.001; -1.0; +1.0; +1.001) - Bereich }-1.0;+1.0[ (Testdaten -1.0; -0.999; +0.999; +1.0) **Grenzen der erlaubten Anzahl von Eingabewerten** -Eingabedatei mit 1 bis 365 Sätzen (Testfälle 0,1,365,366) **Grenzen des Ausgabebereiches** -Programm errechnet Beitrag der zwischen 0.00 und 600 EUR liegt (Testdaten 0, 600, \<0, \>600) **Grenzen der erlaubten Anzahl von Ausgabewerten** -Ausgabe von 1 bis 4 Daten (Testdaten 0, 1, 4, 5) **Geordnete Mengen -Lineare Liste, Tabelle** (Testdaten Erstes und letztes Element) **Komplexe Datenstrukturen** -Leere Liste, Null-Matrix (Testdaten leere Menge) **Bei numerischen Berechnungen** -Testdaten eng zusammen und weit auseinander liegende Werte

Answer 71

- \>Erstellen der Sequenzen für die zu durchlaufenden Pfade durch Breitensuche im Automaten (**Konformanztest**) - \>Unerlaubte Pfade durch Erweitern jeder Sequenz um jeden zu empfangenden Event (Keine Rückweisung ist unerlaubter Pfad - **Robustheitstests** Ziel jeder Zustand mindestens einmal - jeder Übergang mindestens einmal - Attribute einer Klasse spannen ebenfalls einen Zustandsraum auf. Testen auf un/erlaubte Übergänge - Alle Aktionen in einem Automaten mind. einmal ausführen

Answer 72

- \>Zustandsübergangsbaum erstellen: - Wurzelknoten ist Anfangszustand - Berechne Knoten als Folgezustände - Kanten markieren mit Übergangsfunktion/event - Zweig terminiert wenn Knoten auf dem Weg von der Wurzel schon vorhanden oder zugehöriger Zustand ist Endzustand - Fehlerzustände sind auch Endzustände

Answer 73

- Überführen eines Automaten in einen Übergangsbaum; - Alle Zustände müssen erreicht werden und alle Transitionen müssen berücksichtigt werden - Jeder zusätzliche Zustand lässt die Anzahl der Tests überproportional wachsen

Answer 74

- Ein Testfall ist definiert durch Anfangszustand, Eingabefolge, erwartete Ausgaben, Endzustand - Für jeden Zustandsübergang: Vorzustand, auslösendes Ereignis, Reaktion, Folgezustand (Zustandsbestimmung nicht immer offensichtlich!) - Bei Spezifikation schon Testbarkeit prüfen: -Hohe Anzahl von Zuständen ist problematisch

Answer 75

- Nicht alles ist Ein/Ausgabe oder Zustandsautomat - Geschäftsprozesse basieren auf Bedingung und Aktion - Beim Testen alle Kombination von Bedingungen und Aktionen austesten (jede true/false Bedingung einmal) **Entscheidungstabelle** **TF1 TF2 TF3 TF4 TF5** **Bedingungen** Bankkarte gültig? Nein Ja Ja Ja Ja PIN korrekt? -- Nein Nein Ja Ja Dritte PIN-Eingabe? -- Nein Ja -- -- Geld verfügbar? -- -- -- Nein Ja **Aktionen** Karte abweisen Ja Nein Nein Nein Nein PIN erneut anfordern Nein Ja Nein Nein Nein Karte einbehalten Nein Nein Ja Nein Nein Geldbetrag erneut anfordern Nein Nein Nein Ja Nein Geld auszahlen Nein Nein Nein Nein Ja

Answer 76

**Ziel** - Möglichst umfassende Prüfung der vorhanden Strukturen - Nur relevante Testfälle **Strukturen als Ausgangssituation** - Strukturen und Abdeckung zur Definition von Testende - Soll-Ergebnisse in der Spezifikation aber evtl nicht direkt ableitbar

Answer 77

- \>Testfälle so wählen, dass alle oder eine festgelegte Quote der Anweisung mindestens einmal ausgeführt werden (C0-Maß) - \>Basiert auf Kontrollflussgraph - Darstellung der Kontrollstruktur einer Komponente als Graph - gerichtete Kanten als Beschreibung der Reihenfolge - Knoten sind Anweisungen -Elemente: Sequenz, Verzweigung, Schleifen, Zuweisung - Testdurchlauf beinhaltet: Nachweis über ausgeführte Anweisungen - Manchmal reicht ein Testfall - Test-Ende-Kriterium: Quote 100% empfohlen

Answer 78

Ist eher ein schwaches Kriterium muss nicht alle Fälle abdecken - identifiziert potentiell unerreichbaren Code - erkennt leere If-Zweige nicht

Answer 79

- Testfälle so wählen, dass alle Zweige mindestens einmal ausgeführt werden (C1 - Maß) - Basiert auf Kontrollflussgraphen (s.o): Zweig entspricht Kante - Bei Bedingungen die Auswertung zu false/true - alle Case-Fälle - Schleifen ohne Durchlauf, Durchlauf und Wiederholung - Unzureichend für Objektorientierung - Nachweis welche Bedingungen und Anweisungen ausgeführt wurden - Berücksichtigung von leeren If-Zweigen - Test-Ende-Kritierium über Quote; empfohlen 100%

Answer 80

- Testfälle so wählen, dass alle Pfade inkl. Schleifen/Wiederholungen ausgeführt werden - Beinhaltet die Kombination aller Pfade durch jeweilige Basisblöcke des Programms (Abhängigkeiten zwischen Pfaden berücksichtigen)

Answer 81

- Testfälle so wählen, dass alle Pfade inkl. Schleifen/Wiederholungen ausgeführt werden - Beinhaltet die Kombination aller Pfade durch jeweilige Basisblöcke des Programms (Abhängigkeiten zwischen Pfaden berücksichtigen)

Answer 82

- \>Frage: Wenn man weiß welche Zweige, Pfade man abdecken will woher kommen die Testfälle? - Wie legt man Eingabedaten fest? - Wie legt man Sollverhalten fest? - \>Auswahl von Eingabedaten - Repräsentation und ihre Kombinationen - Analog zu Äquivalenzklassen - Basierend auf Bedingungen und ihren Abhängigkeiten - \>Solltewerte - Abgeleitet aus übergeordneter Spezifikation - Auf Basis von Standardanforderungen

Answer 83

- Grundprinzip: Basis ist der Programmtext (Komplexität bestimmt Aufwand) Vorteile: - Geeignet für untere Testebenen (Komponententest) - Guter Support durch Werkzeuge für Testfallgenerierung und Testreporting Nachteile: - Nicht umgesetzte Anteile der Spezifikation werden nicht erkannt - Instrumentierter Code (um Überdeckung zu messen) verhält sich anders als Code alleine (Zeitmessung) - \>Empfehlung: Minimum Zweigüberdeckung!

Answer 84

**Blackbox:** - Anwendungsfallbasiertes Testen - Syntaxtesten -Zufalltesten **Whitebox:** - Bedingungsüberdeckung (If/While konkret analysieren) - Datenflussbasierte Verfahren Intuitives und erfahrungsbasiertes Testen: - Error-Guessing

Answer 85

a) Saldo 5001; SparRate 101; Bonus 51 (Jedes If ueber 1 Tests) (1 Testfall!) b) Saldo 500; SparRate 50; Bonus 9 (If 1) Saldo 4000; SparRate 150; Bonus 20

Answer 86

- Architektur spezifiziert die Komponententests - Komponententest wird durch den Entwickler der Komponente durchgeführt (Done nur bei Erfolg) - Integrationstest bei Abnahme durch Entwickler/Test-Team

Answer 87

- Werden genutzt beim isolierten Testen von Systemteilen (Klassen, Komponenten) - Abhängige Teile sind oft noch nicht entwickelt - Erspart parallele Entwicklung - Trotzdem kann sichergestellt werden, dass ein Teil funktioniert, da man Test Doubles nutzt

Answer 88

- **Dummys:** (Werden nie benutzt, füllen nur Parameterlisten) - **Fake Objects**: (Läuffähige implementierung, sehr schlicht gehalten, nie für Produktion) - **Stubs**: (Liefern vorgefertigte Ergebnisse für Testaufrufe. Können Infos über Aufruf speichern - **Mocks**: (Vorkonfigurierte Objekte mit Spezifikation der erwarteten Aufrufe und deren Ergebnisse

Answer 89

-Nein, da sie stark gekoppelt ist

Answer 90

-Durch die Test-Suite Eclemma, als Tool für Testüberdeckungen

Answer 91

- Gut sind 80-90% - Unrealistisch 100%

Answer 92

-Eine selektive Wiederholung bestehender Tests, um zu prüfen, dass Code-Modifikationen keine Effekte auf das System hatte.

Answer 93

**Strukturierte Beschreibung von Testfällen** (Hier Abnahmetest aus SpezifikationsDokument) **Name** TF-31: Änderung der Telefonnummer eines Kunden **Beschreibung** Die Telefonnummer eines bestehenden Kunden soll geändert werden. **Voraussetzungen** Die Stammdaten für den Kunden „testuser“ existieren. Die bisherige Telefonnummer lautet „0000-0000“. **Eingabe** Der Benutzer ändert im Dialog „Profildaten ändern“ die Telefonnummer auf den neuen Wert „1234-5678“. **Ausgabe** Das System meldet, dass die Änderung erfolgreich war. **Verifizierung** Nach der Änderung werden die Kundendaten erneut ausgelesen und die gelesene Telefonnummer mit dem erwarteten Wert verglichen.

Answer 94

- Unten als breite Basis automatisierte Unit-Tests - Darüber automatisierte Komponenten, Integrationstests - Darüber automatisierte GUI Tests - An der Spitze der Pyramide wenige Tests per Hand (Viele Dinge sind aber nicht automatisiertbar testbar, wie Benutzerfreundlichkeit oder Funktionen mit Nachbarsystemen)

Answer 95

- Eine Darstellung über das Vorgehen im Testing, in der erst viel per Hand getestet wird und danach automatisiert getestet wird - Dieses Verfahren ist ineffektiv und schlecht

Answer 96

**Review** - Prüfung eines Dokuments, Zeichnung, Programmes durch Gutachter unter Vorgaben - Ziel Fehler und Schwächen zeigen - Positive Merkmale hervorheben **Inspektion** -Systematisches Review Punkt für Punkt auf Stärken und Schwächen **Walktrough** -Ein Review bei dem ein Autor Schritt für Schritt die Funktionsweise beschreibt und Zuhörer nur bei Mängeln einhaken

Answer 97

**Prüfling** ist ein in sich abgeschlossener für Menschen lesbarer Teil von Software (Dokument, Code, Datenmodul) **Referenzunterlagen** (Subjektivität herausnehmen) -Spezifikation, Richtlinien, Fragenkataloge

Answer 98

**Manager/PL** = (Nimmt nicht am Review teil) ist verantwortlich für Prüfung und Freigabe **Autor** = (passive Rolle für Rückfragen) Urheber des Prüflings **Moderator** = Leiter des Reviews **Gutachter** = Kann Prüfling beurteilen **Protokollant** = Protokolliert -Review-Team = Alle Teilnehmer

Answer 99

- Planung - 2 Wochen Vorbereitung (Initiierung) - 2 Stunden Sitzung (Keine Diskussion nur Aufnahme der Mängel) - 1 Stunde "Dritte Stunde" - 2 Wochen Nacharbeitung (Danach Freigabe) - Analyse

Answer 100

- Festlegung des Review - Teams - Einplanung entsprechender Zeit für Reviews

Answer 101

- Moderator versorgt Gutachter mit erforderlichen Informationen (Schriftliche Einladung/Einführungssitzung) - Wichtig (Unabhängige Beurteilung, Jeder Gutachter kann mehr als ein Aspekt haben, jeder Aspekt muss von mind. zwei Gutachtern bearbeitet werden)

Answer 102

- Moderator versorgt Gutachter mit erforderlichen Informationen (Schriftliche Einladung/Einführungssitzung) - Wichtig (Unabhängige Beurteilung, Jeder Gutachter kann mehr als ein Aspekt haben, jeder Aspekt muss von mind. zwei Gutachtern bearbeitet werden)

Answer 103

-Gutachter betrachten den Prüfling um Mängelliste zu erstellen(anhandFragenkatalog/Checkliste)

Answer 104

- Gutachter betrachten den Prüfling um Mängelliste zu erstellen(anhandFragenkatalog/Checkliste) - Moderator muss sicherstellen, dass Gutachter alle Rahmenbedingungen (Zeit, Unterlagen) hat um Aufgabe zu erledigen - Fragenkataloge (Ja/Nein Fragen auf Grundlage von Erfahrung mit präziser Fragenstellung) - Verschiedene Typen von Fragenkatalogen für Dokumente/Code (Projekt- und Dokumentenspezifischer Fragenkatalog)

Answer 105

"Sind alle wesentlichen Begriffe in den Anforderungen klar definiert?" "Kann man für jede Anforderungen zweifelsfrei festellen ob sie im fertigen System erfüllt ist oder nicht?"

Answer 106

- Nach Regeln geleitet durch Moderator - Abschnittsweise behandeln des Prüflings durch jeden Gutachter, die über Mängel präzise berichten - Protokollant protokolliert Befunde - Autor hat passive Rolle (soll sich nicht verteidigen müssen) - Moderator will Konsens erreichen

Answer 107

- Nach Regeln geleitet durch Moderator - Abschnittsweise behandeln des Prüflings durch jeden Gutachter, die über Mängel präzise berichten - Protokollant protokolliert Befunde - Autor hat passive Rolle (soll sich nicht verteidigen müssen) - Moderator will Konsens erreichen

Answer 108

- Optionale Sitzung mit Kaffee und Kuchen - Man kann noch über Lösungen diskutieren - Nacharbeit für Moderator -\> Entscheidungen anhand Review-Bericht treffen - Autor muss evt. Prüfling bearbeiten - Überarbeiteter Prüfling muss geprüft werden bei kleinen Mängel Kontrolle durch Moderator, ansonsten erneutes Review

Answer 109

- Kurzfristiger Nutzen durch Schulung der Mitglieder des Teams - Langfristiger Nutzen durch systematische Auswertung der Resultate - Welchen Einfluss haben Parameter? - Einfluss von früher erkannten Problemen? - Analyse der Wirksamkeit von Änderungen

Answer 110

Stärken: -Können früh im Entwicklungsprozess durchgeführt werden - Alle Entwicklungsprozesse prüfbar (Mehr als Code!) - Selbsteinschätzung der Entwickler nähert sich Realität an - Hohe Wirksamkeit Schwächen: -Gekaufte Software nur teilweise für Reviews zugänglich - Der Autor darf nie zum Angeklagten werden!!! - Es können Streitigkeiten entstehen -Sind nicht billig (15% des Arbeitsaufwands)

Answer 111

- Das Zeile für Zeile Durcharbeiten eines Einzelergebnisses - Hat informellen Charakter (Nicht moderiert) - Oft für Begutachtung von Code genutzt und fertigen Ergebnissen genutzt

Answer 112

- Ein Walkthrough spielt durch Beispiele und Testfälle die Funktionalität durch - Eignen sich sehr zur Ausbildung von Mitarbeitern und Kommunikation wg. Diskussionen - Oft für Begutachtung von technischen Konzepten und Spezifikation genutzt

Answer 113

- Großer Einfluss auf Produktivität und Qualität der Produkte - Keine Garantie für gute Entwicklung - Entwicklungsprozess sollte einheitlich organisiert und durchgeführt sein - Sprachen, Methoden, Werkzeuge müssen Tätigkeit unterstützen - Mitarbeiter müssen entsprechend des Prozesses/Werkzeug ausgebildet sein - CMMI - SPICE - ISO-9000 (Nicht Software only)

Answer 114

- Steht für Capability Maturity Model Integrated (1997) - Zur Durchführung von Prozessbewertung

Answer 115

- Das Sichtbarmachen der Schwächen des Prozesses durch Checklisten - Bewertung neutral ggü. der Technik(Objektorientierung) - Besteht auf Stufen, die untere jeweils vorraussetzt - Hohe Prozessreife -Prozesse besser beschrieben/geplant/gesteuert, - Kennzahlen vorhanden - Termine/Kosten/Qualität kann prognostiziert werden) - CMMI definiert 22 Prozessbereiche mit Zielen der Strukturierung - Requirements Management (REQM) - Project Planing (PP) - Organizational Training (OT) - Causal Analysis and Resolution (CAR)

Answer 116

**Stufe 1: initial** - Prozess nicht bewusst gestaltet sondern zufällig - Überschreitung Kosten, Termine -Erfolg nicht planbar, Mitarbeiterabhängig **Stufe 2: managed** - Vorgaben für Bereiche (Anforderung QS, PM) - Kein definierter Software - Prozess - Jedes Projekt folgt einem eigenen Prozess **Stufe 3: defined** - Alle Projekte einer Organisation folgen einem einheitlichen Schema - Definition Standardprozess - Freiheiten für Projekte **Stufe 4: quanitatevly managed** -Einführung von Metriken zur Erkennung von Problemen **Stufe 5: optimizing** - Stetige technische und organisatorische Verbesserung der Prozesse - Anpassung Randbedingungen - Systematische Analyse von Fehlern und Problemen

Answer 117

- Dokument für nächstes Meeting erstellen (Wer nimmt wo wann teil?) - Beginn mit kurzer Absprache wer was gemacht hat - Prüfung welche Issues noch offen/beendet sind - Ausarbeitung Agendapunkte und protokollierung - Abschließene Klärung wer wird was machen - Nächsten Termin festlegen; Protokoll veröffentlichen

Answer 118

- Sind unverzichtbar im Projekt - Ergebnisse erarbeiten - Können nicht durch Remote(Video,Skype) ersetzt werden - Meetings Kostenfalle - Nutzen aus Meetings ziehen!

Answer 119

- Richtige Leute einladen (nur benötigte) - Agenda erstellen und mind. einen Tag vorher verteilen (Vorbereitung für Teilnehmer, Einladungsannahme/Ablehnung) - Meeting muss pünktlich beginnen (Telefone aus, Keine Unterbrechung) - Sitzung ohne Protokoll hat nicht stattgefunden

Answer 120

- Protokolle beleben objektiv die Ergebnisse eines Meetings - Keine Last, sondern Werkzeug und Ergebnis - Müssen sofort erledigt werden - Immer transparent erwähnen was ins Protokoll aufgenommen wird (Spart Konflikte) - Evtl. Action-Item-Protokoll benutzen

Answer 121

-Es sollen echte Ergebnisse produziert werden, also Aufforderungen, Beschlüssel, Empfehlungen und Feststellungen **Vorteile:** - Tatsächliche Ergebnisse festhalten - Unterstützt Moderator produktiv zu sein - Ermöglicht einfache Kontrolle von vorherigen Ergebnissen

Answer 122

**Aufforderung (Action):** - Umfang begrenzt für Einzelnen - Zustimmung des Einzelnen -Dauer und Kosten abschätzbar - Endtermin klar **Beschluss:** - Für alle verbindlich - Einigung der Beteiligten vorrausgesetzt **Empfehlung:** - Wenn einzelner nicht anwesend oder keine Einigung - Einseitig aussprechbar - nicht verpflichtend **Feststellung:** - Sachverhalt und persönliche Sichtweise - Einseitig aussprechbar auch ohne Einigung - nicht verpflichtend

Answer 123

- Alle Ergebnisse sofort und öffentlich festhalten - Alle Ergebnisse werden immer fortlaufend nummeriert - Zu jedem Ergebnis ein Konsens (Kategorie, Wer?, realistisch?)

Answer 124

-HIER BILD EINFÜGEN

Answer 125

- Teilnehmer und Abwesende - Kontakt des PL - Fortlaufende Nummerierung der Inhalte - Beschreibungen in Stichworten und Test - Terminierung bis wann etwas zu erledigen ist - Aktion, Beschluss, Empfehlung, Feststellung - Wen es betrifft - Festlegung nächster Termin

Answer 126

- Zuhören und ausreden lassen - Einen Beitrag straffen - Beim Thema bleiben - Nur sachdienliche Beiträge bringen und dulden - Bei Gegensätzen die Form wahren

Answer 127

-Kenntnis und Anwendung professioneller Technicken, um Risiken zu entdecken, analysieren und beseitigen/beherrschen

Answer 128

- Risiko ist ein unsicheres Ereignis mit negativer Auswirkung - Auch eine Chance, da ohne Risiko kein Geschäftserfolg und kein Projekt -Früher um Klippe fahren ein Risiko -\> Fracht auf viele Schiffe verteilen Oft nicht greifbar aber ahnbar -Eintrittswarscheinlichkeit x Auswirkung

Answer 129

- Ein Problem erschwert/verhindert Durchführung - Ein Risiko erschafft mit einer Wahrscheinlichkeit ein Problem (Potentielles Problem)

Answer 130

- Ziel ein potenzielles Problem zu finden bevor es auftritt - Kontinuierlich im Projekt auszuführen - Ziel Risiken zu kontrollieren, nicht zu vermeiden - Zusätzlicher Aufwand der geplant sein muss

Answer 131

- Verbessert Qualität und Vorhersehbarkeit - Entkriminalisiert Risiken - Proaktives Handeln

Answer 132

- Identifizieren - Bewerten - Abschächen - Verfolgen .. -VON VORNE

Answer 133

- Risiken müssen systematisch identifiziert werden - Risiken in Risikoarten einteilen - Über Risiken sprechen - Oft wiederholen sich gleiche Risiken, daher auf die wichtigsten konzentrieren (Standardrisiken)

Answer 134

- Technische Risiken (Neue Technik, Externe, Patente) - Implementierungsrisiken (schlechter Entwurf, Anforderung unerfüllbar) - Wirschaftliche Risiken (Ressourcen nicht verfügbar, Cash-Flow zu gering) -industrielle Risiken (Lieferantenausfall, Preisänderung) - Geschäftsrisiken (bessere Wettbewerber, schlechte Marktforschung) - Operative Risiken (Kurzfristige! Unsicherheit, Zeitrahmen,Kosten) - Strategische Risiken (Langfristige! Auswirkungen die eine Gefahr werden)

Answer 135

- Brainstorming (Nie alleine) -Bedrohungsszenario ("Was wäre wenn?") - SWOT-Analyse (Strenghts, Weaknesses, Oppurtunities, Threats) Wurde das richtige Produkt entwickelt? - Frühere Probleme/Erfahrungen - Interviews - Checklisten

Answer 136

- Falsche Funktionen werden entwickelt (Klar Ziele, Verschiedene Interessen, Anforderung in Benutzersprache) - Falsche Benutzerschnittstelle (Bedürfnisse erkannt?, Nutzbarkeit?, Sprachen?) - Over-Engineering (Unnötige Funktionen, Wirtschaftlichkeit?, Nutzen?) - Ständige Änderung an Anforderungen - Unzureichende Qualität externer Komponenten (Werden Komponenten abgenommen? Versionierung?) - Lieferantenverzug (Alle Lieferanten bekannt?) - Unzureichende Performance (Wie modelliert?, Zeitvorageben? Test?, Backups?) - Unzureichende Ressourcen (Fähigkeiten, Zahl, Verfügbarkeit Mitarbeiter, Störungen) - Unrealistische Zeit/Budgetplanung (Termine ohne Prüfung/Analyse, Budget für Wartung)

Answer 137

-Tabellarisch durch Risikoliste Inhalt Beschreibung Beispiel **Identifikation** Name KiKa\_2009\_Risk\_1 **Beschreibung** Wie passiert? Tests nicht verfügbar **Folgen** Was passiert? Verzögerung Projekt Eintrittswahrscheinlichkeit %? hoch **Auswirkungen** Kosten, Verzögerung? hoch **Priorität %** und Auswirkung 1..9 **Maßnahmen** Abschwächen Backup ab 2000 **Status** Statusklasse offen **Verfolgung** Zeitplan gefunden am 07.07 durch Max

Answer 138

- Risikoliste laufend aktualisieren! - Verantwortlichen benennen (PL, QS-Manager) - Risiken sind von allen Beteiligten zu erfassen

Answer 139

-Risiken in Klassifikationen aufteilen **Wert = Eintrittswahrscheinlichkeit x Auswirkungen** **1 (gering)** **Es ist wenig wahrscheinlich, dass das Risiko eintritt. Der Schaden wird kaum merklich sein:** * Geringe Einschränkung der Leistungen * Geringe Zeitverzögerung * Geringe Überschreitung der Kosten **2 (mittel)** **Es wäre nicht überraschend, wenn das Risiko eintritt. Der Schaden ist beträchtlich:** * Merkliche Einschränkung der Leistung * Merkliche Zeitverzögerung * Merkliche Überschreitung der Kosten **3 (hoch)** **Es ist damit zu rechnen, dass das Risiko eintritt. Der Schade ist groß:** * Zentrale Funktionen sind betroffen * Lange Zeitverzögerung * Starke Überschreitung der Kosten

Answer 140

- Risiken abschwächen durch: - Vermeidung - Reduktion/Optimierung (Wahrscheinlichkeit oder Auswirkung minimieren) -Abwälzen auf Dritte - Ignorieren

Answer 141

**Zu Wenig gute Leute** -\> Gute Leute einstellen, Arbeitsklima verbessern **Schlechte Kosten/Zeitpläne** -\> Aufwandsschätzung, Anforderung reduzieren **Falsche Funktionalität** -\> Spezifikation, Prototypen, Kunden beteiligen

Answer 142

- Nur aktiv und regelmäßig verfolgte Risiken verlieren an Gefahr - Wirkt die Abschwächung? - Risiken noch relevant? - Schon Problem geworden oder neue entstanden? - Top-Ten Liste der höchsten Risiken erstellen - Ziel ist es mit den Risiken umzugehen!

Answer 143

- Umgang mit geänderten Anforderungen - Unterkategorie von Konfigurationsverwaltung

Answer 144

- Ermöglicht die geordnete Zusammenarbeit im Team - Technische und organisatorische Vorkehrung - Oft unterschätzt

Answer 145

- Versionsmanagement (Wer hat wann was geändert?) - Changemanagement (Warum geändert?) - Buildmanagement (Wie verarbeiten Abhängigkeiten?) - Relesemanagement (Was wird ausgeliefert, was produziert?)

Answer 146

- Projektmanager (PM) - Entwickler - Buildmanager (BM) - Releasemanager (RM) - Changerequestmanger (CM)

Answer 147

- Systematische Verwaltung von Änderungen - Software korrigieren, neue Anforderungen, Fehler einordnen - Administrativ und finanziell bedeutend! - Fehler sind zu beheben -\> Kosten sind Fehlerkosten - Neue Anforderungen -\> Änderungskosten die berechnet werden - Software neuorganisieren, neu dokumentieren, wartbarkeit erhalten -\> Rücklagekosten

Answer 148

- Jede Änderung beginnt mit Problemmeldung - Änderungsantrag CR ist Sonderfall für Änderungs/Erweiterungswunsch - Vorlagen zur Erfassung von Problemen/Änderungen nötig - Change-Management ist bei Wasserfall besonders nötig

Answer 149

- Problemklärung (Worum geht es?) - Klassifikation (Irrtum, Fehlermeldung, Änderung)

Answer 150

- Irrtum (System falsch bedient, falsches erwartet) - Fehler (Wann und ob Fehler beheben?) - Änderung (Vorteile, Kosten, Risiken!)

Answer 151

- SPR (sehr schwergängig, aber wenig alternativen) Es entspricht ungefähr einem CR - CCB (Change Control Board)

Answer 152

- Analyse der gemeldeten Fehler - Rückmeldung für den Anwender - Klassifikation der Fehler (1-3 sind Bugs) - 1 Mangel an Dokumentation - 2 leichte Fehler - 3 schwere Fehler - 4 Fehler mit Zerstörung des Nutzens der Software - Klasse 1-3 Fehler einplanen; Klasse 4 sofort bearbeiten

Answer 153

- Code & Fix - Wasserfallmodell - Prototyping - V-Modell - Rational Unified Process - Agile(Scrum, XP)

Answer 154

**Vorteile:** - Schnell vorankommen/Produkt - Tätigkeiten (Code/Test) einfach gehalten **Nachteile:** - Projekt nicht planbar, keine Qualitätsentscheidung - Fehlerbehebung führt zu Umstrukturierung - Benutzer kann Software ablehnen, da nicht zusammen abgesprochen - Fehler schwer zu finden **-\> Code & Fix sabotiert Qualität**

Answer 155

**Besteht aus:** - Lastenheft, Pflichtenheft - Systemenwurf - Code **Vorteile:** - Geht sehr schnell an die Entwicklung - Bei abschätzbaren komplett klaren Entwicklungen effektiv **Nachteile:** - Kein weiterer Kundenkontakt - Sehr schlecht für komplexe Systeme - Terminverzögerungen - Bigbang-Programmeinführung

Answer 156

- Frühe Kosten sind die schlimmsten, da sie noch weiter steigen werden - Hoher Aufwand diese zu beseitigen

Answer 157

- Nach Boehm - Ziel ist es das Wasserfallmodell und Qualitätssicherung zu integrieren anhand von Entwicklung und Verifikation

Answer 158

**Horizontaler Prototyp** -Realisiert Funktion einer Systemebene vollständig **Vertikaler Prototyp** - Realisiert ausgewählte Teile des Systems durch alle Ebenen Ebenen - Gui, Anwendungskern/Logik, Persistenz

Answer 159

**Vorteile:** - Reduktion Entwicklungsrisiko - Benutzer - Auftragsgeber Kommunikation - Schnell, da Qualität nicht wichtig **Nachteile:** - Zusätzlicher Aufwand - Beschränkung und Grenzen unbekannt - Protyp darf nicht für Vorversion des endgültigen Produktes gehalten werden

Answer 160

- Generisches Modell einer Projektfortschrittes, welches in einer Spirale auftritt 1. Ziele, Alternativen 2. Risikoanalyse 3. Entwickeln, Prüfen 4. Planung der nächsten Phase

Answer 161

**Vorteile:** - Flexibel, Modell nicht für ganze Entwicklung festgelegt - Fehler und schlechte Alternativen werden durch Risikoanalyse beseitigt **Nachteile:** - Keine genaue Planung, sondern Etappenweise

Answer 162

- Gibt Rollen/Aufgaben/Artefakte für Entwicklung vor - Angepasst für Objektorientierte Software - RUP ist konkrete Ausprägung von UP - Bietet Tools an, enthält Templates für Dokumente

Answer 163

- Besteht auf 4 Phasen mit jeweils einem Milestone - Entwicklung ist iterativ und inkrementell - Eine Phase kann aus Iterationen bestehen - Jede Iteration ein MiniWasserfall - Jede Iteration ausführbar - Bietet Flexibilität gegenüber Änderungen und reduziert Risiken - Anwendungsfallbasiert (Beschreiben Anforderung) - Architekturzentriert (Basis für Entwicklung)

Answer 164

- Iterativer Ansatz - Anfangs viel gegen Ende weniger - Start,Architektur,Coaching,Zum Kunde

Answer 165

**Inception** -Projektfokus finden MS: Wie soll das Projekt durchgeführt werden? **Elaboration** - Anforderungen finden - Architektur, Prototyp MS: Lebenszyklus-Architektur **Construction** - Implementation auf Basis Architektur - Integration/Test - Dokumentation MS: Beta Version; Stabil genug? **Transition** - Alle Dokumente/Systeme verbessern durch Rückmeldungen - Deployment/Datenbank MS: Product Release; Ist der Nutzer zufrieden?

Answer 166

Vorraussetzung - Kenntisse Objektorientiere Programmierung - Mangement-Fhigkeiten (Iterationen planen etc) Vorteile - Gute Darstellung in HTML - Gute Details Nachteile - Schwierige Anpassung an Ereignisse - Softwareentwicklung ist von Projekt zu Projekt unterschiedlich; Algorithmische Lösungen gibt es nicht

Answer 167

- Fortschritte beobachten - Maßnahmen ergreifen, wenn es in die falsche Richtung geht - Festhalten der Vorgaben und Erwartungen (Soll) - Erfassen und Bewerten was im Projekt erreicht wird (Ist) - Vergleich der Erwartungen und Bewertung (Soll-Ist-Vergleich) - Konsequenzen ziehen

Answer 168

**Auftraggeber (Externes Controlling)** -Beim Erreichen von Milestones -Qualität, Risiken, Ziele **Projekteigentümer (Internes Controlling)** - Monatlich Controlling - Kosten, Risiken, Ziele **Projektleiter (Steuerung innerhalb Projekt)** - Wöchentlich Controlling - Stand, Qualität, Probleme, Restaufwand **Projektteam**

Answer 169

- Erfassen des Ist-Zustandes durch den PL der sich Restaufwände (RA) wöchentlich holt - Restaufwand wird eingetragen in den Projektplan und ändert diesen - Entscheidung über Änderung von Soll/Ist - In SCRUM - Daily Standup

Answer 170

- Arbeitspakete stehen im MIttelpunkt - Mitarbeitern ordnen Arbeitsstunden in Arbeitspakete - Abweichung entsteht sobald Schätzung falsch, Arbeit ineffizient, Aufgabe abgewichen - Freies Berichten ist zu vermeiden, da das 90% Syndrom auftreten kann. (Am Anfang leicht und viel berichten, bei schwerem kein Durchblick nichts berichten) - Den Grad wie weit etwas fertiggestellt ist kann man schwer messen, falls noch schwerere Aufgaben übrig sind

Answer 171

- Nicht über IstAufwand / Geschätzer Aufwand - Sondern über IstAufwand / IstAufwand + Restaufwand - Hier wird die aktuelle Aufwandsschätzung genutzt - Abweichungen sind Aufforderungen zum Handeln - Ist sehr gängig so zu schätzen!

Answer 172

- Anzahl abgeschlossener Arbeitspakete / Anzahl Arbeitspakete - naiv - Pakete mit 0,5 auch berücksichtigen! (gerade bei wenig Paketen)

Answer 173

- In strukturierter Form (Excel) - Durch Absprache mit Mitarbeiter wie seine Zahlen entstanden sind

Answer 174

- Jeder Posten der Stückliste (Arbeitspaket) ist ein Budgetkonto (Komponente entwerfen, Reisekosten) - Mitarbeiter buchen während der Arbeit am Projekt auf diesen Konten - Getrennte Konten für getrennte Tätigkeiten des PSP (Fachliches Datenmodell ist anders als Review) - Nicht zu viele Konten; QS-Konto für alle Teilreviews (Gute Einteilung) - Gebuchte Zeiten ermöglichen Controlling - Darstellung im Zeitplan

Answer 175

- Projekterfahrung charakterisiert Stand des Projektes - Informationen müssen veranschaulicht werden (Schwächen erkennen) - Oft Timedrift-Diagramme oder MTA -Idee: Zeitachsen real vs geplant um Änderungen zu zeigen

Answer 176

**Unmittelbare Maßnahmen**: Schadenseindämmung und Anpassung Bei Terminüberschreitung -\>Weniger liefern, Lieferung verzögern Bei Kostenüberschreitung -\> Nachverhandeln, Verrechnen mit anderen Leistungen **Mittelbare Maßnahmen**: Lokalisierung und Behebung der Ursachen Schlechte Leistung, Technische Probleme, Schlechte Planung **Schlechte Maßnahmen**: - Vergrößerung des Projekteams (Brooks Law: More Manpower to a late project makes it even later) - Hoffen auf ein Wunder - Vertuschen des Problems

Answer 177

- Ohne Planung kein Controlling - Berichterstattung muss bindend sein - Berichterstattung braucht Kontrollmechanismen (Bewertung von Reviews und Test) - Verwendette Begriffe müssen von allen Beteiligten gleich interpretiert werden - Bei Planabweichung müssen Maßnahmen durchgeführt und überwacht werden - Der Projekteigentümer bekommt nur die Informationen die er haben will -Der Übereigner einer Nachricht darf nicht für diese bestraft werden

Answer 178

- Regelmäßige wöchtenliche Besprechung des Projektteams - Berichte über Arbeitsfortschritte und Probleme - Beschließen Maßnahmen - Protokoll mit ToDo-Liste anfertigen -SCRUM: Daily Standup

Answer 179

- Teilnehmer: Beide Projektleiter, Mitarbeiter des Auftraggebers, evtl einige Mitarbeiter des Auftragnehmers (Kunde mit dabei!) - Ähnlich wie Teammeeting - Auftragnehmer berichtet über Fortwschritte und Probleme, sowie Vorschläge und Anpassungen des Projektplans - Auftragnehmer stellt sicher, dass Auftraggeber Verpflichtungen einhält (Lizenzenkauf, Unterlagenkauf)

Answer 180

-Oft fehlt ein Abschluss - Keine Dokumentation über Miss/Erfolge - Keine subjektive Wahrnehmung fertig zu sein Nötige Abschlussarbeiten - Archivierung der Resultate/Unterlagen - Auflösung der Projektorganisation/Neuzuweisung - Kennzahlen festhalten für weitere Projekte(Kosten/Termine) - Dokumentation vervollständigen - Success Story festhalten -Für die Zukunft daraus lernen (Was war gut, was weniger, was beachten?) Es sollte ein Gegensatz zum Kick Off geben, als Abschlussritual, damit es jedem bewusstgemacht wird

Answer 181

- Man kann nicht auf alle Ziele gleich priorisiert eingehen - **Zeit** begrenzt, **Kosten** begrenzt, **Qualität** nicht umsetzbar -

Answer 182

-Projekte sollen ERFOLGREICH durchgeführt und abgeschlossen werden, daher definierte Resultate in Qualität, Zeit, Kosten mit gewissen Ressourcen einhalten Weitere Ziele: -Besserer Ruf/Branding - Kentnisse aneignein - Wiederverwendbarkeit von Komponenten -Arbeitsklima attraktiv halten

Answer 183

- Planen (Planung ist essentiell, Planung ist wertlos) (Kommt eh anders) - Bewertung und Kontrollierung ob man im Plan ist -Kommunizieren zwischen Mangement, Kunden, Marketing und Mitarbeitern Ansprechpartner sein: Für Management zuständig für Projekt, Für Kunde Herstellerfirma, für Marketing die Technikumsetzung, für Mitarbeiter die Leitung (Für alle zuhören und weitergeben!) - Das Projekt vor Störungen schützen wie schlechten Kunden, unklare Ziele, Sparmaßnahmen, Mitarbeiterstehlen etc. - Mitarbeiter führen und motivieren(Ordnung, Bestätigung) - Schwierigkeiten früh erkennen und bekämpfen

Answer 184

- Soft Skills: Soziale Kompetenz - Kommunikation: Engagiert, Ergebnissorientiert, Stellt fragen - Kooperation: Enge Kundenbeziehung, Beratung - Teamfähigkeit: Anpassung, Respekt - Motiviation: Unterstützt Kollegen, Setzt Ziele - Konfliktfähigkeit: Konstruktiv, Erkennt Störungen

Answer 185

- An einem Projekt gibt es mehrere Personen unterschiedlicher Rollen - Der Projektmanager muss das Projektteam organisieren - Unteteilung des Teams in kleinere Teams von 5-7 Personen _Formen_ -Kleine Teams und Einzelkämpfer: (Ausfall?, Einarbeitung Nachfolger?, Mehraufwand in Kauf nehmen zur Integration in Gruppe) -Anarchische Teams: (Entwickler arbeiten im Wesentlichen autonom, Hierarchie wird ignoriert, keine Normen/Standard) -\> Resultat ist Glückssache Demokratische Teams: (Gemeinsame Ziele, Disziplin, Konsensprobleme eine gewählte Person trifft Entscheidung) Fähigkeiten gut eingesetzt, aber viel Kommunikationsaufwand ``` Hierarchische Teams (traditionell): -Projektleiter kontrolliert und entscheidet ``` - Große Teams mit Unterabteilungen - Fest Zuständigkeiten und Pflichten/Übersicht - Hierachie erschwert Kommunikation, Infos zu spät, Projektleiter trägt Verantwortung Chief Programmar Teams(bei großen Projekten unmöglich): - Form von Hierarchischen Teams - Projektleiter führt technisch konstruktiv, entwirft, implemtiert, testet - Chief ist hier "Vorarbeiter" - Ist effizient, aber hat sehr hohe Ansprüche an den Chief

Answer 186

- Akquisition (Kundensuche, Teamsuche) - Angebot (Aufforderung, Preis, Features) - Initialisierung - Durchführung - Abschluss (Abnahme)

Answer 187

- Abstimmung der Zielsetzung des Lastenhefts (Anforderungen, Ausgrenzung, Annahme) /Zentrale User Stories - Kostenschätzung - Erstellung eines Angebotes - Unterteilung in Start, Workshop, Konsolidierung, Ende - Angebotspräsentation, Fragen, Verhandlung

Answer 188

-Zusammenstellung des Teams -Planung der Pakete/Ressourcen/Berichtswesen/Budget -Unterbeauftragten planen Kick-Off planen -Risikomanagement einrichten

Answer 189

- Analyse, Entwurf, Implementierung, QS/Test, Dokumentation (agil, nicht agil) - Planung und Kontrolle - Meetings mit Kunden und Team

Answer 190

- Finale Lieferung - Abnahmetest durch Kunden - Touch-Down Workshop(Kick-Off) - Ergebnisse intern festhalten

Answer 191

- BT = Bearbeitungstage - BM = Bearbeitungsmonate - BzI = Bereit zur Integration _Projektanfang:_ AG Ist doch alles klar AN Aufgabe viel zu ungenau _Projektende:_ AG Alles ist fertig AN Hätte anders sein müssen war auch besprochen - Solche Risiken können durch eine präzise Angebotsformulierung vermieden werden. - Ein offen und ehrliches Angebot, welches das Verständnis zeigt ist ideal.

Answer 192

- Termingerechte Erstellung des Angebots - Steuerung des Angebotsteams(Aufwandsschätzung, Angebotstext) - Wirtschaftlichkeitsrechnung - Juristische Prüfung - Projektplan im groben (Demonstration von Verständis über Aufgabe, Ressourcen des Arbeitgebers, Meilensteine)

Answer 193

1. Projektziel nicht genau definiert 2. Aufwandsschätzung ungenau 3. Aufgaben oder Zusatzkosten werden vergessen 4. Zu gering geschätzter Aufwand 5. Lieferbenstandteile nicht genau definiert 6. Ansprechpartner nicht klar 7. Verantwortlichkeiten zwischen AG und AN unklar 8. Abnahme unreguliert 9. Sich runterhandeln lassen, man muss zum Preis stehen 10. Es wird schon irgendwie klassen ohne sicher zu sein

Answer 194

- Sobald die Auftragerteilung erfolgt ist - Nun wird das Team zusammengestellt - Projektplan wird im Detail besprochen - Unterbeauftrage planen - Vorbereitung auf Kick-Off Veranstaltung mit dem Projektleiter des Auftraggebers

Answer 195

_Teilnehmer am Kick-Off:_ Projektleiter des Arbeitgeber und Arbeitnehmers Projektmitarbeiter der Arbeitgeberseite und wichtigsten Mitarbeiter der Arbeitnehmerseite - Gemeinsame Vision - Kennenlernen - Einvernehmen über Ziele (quantifizierbar, Grundlage für Abnahme) - Organisatorisches: Jour Fixe/Meetings, Projektverzeichnis, Wiki, Werkzeuge, Vorlagen - Erzeugen von Aufbruchsstimmung - Dauer des Kick-Offs Stunden bis 1 Tag

Answer 196

- In der Angebotsphase (Kostenschätzung) - In der Initialisierungsphase (Planung der Aufgaben, Ressourcen, Berichtswesen, Termine/Budgets) - In der Durchführungsphase (Planung und Kontrolle)

Answer 197

-Ein Plan ist die geistige Vorwegnahme des zukünftigen Handelns, aber auch nutzlos, da es eh anders kommt!

Answer 198

-Planung heißt mit wie vielen Mitteln das Projekt auf Basis des Wissensstands durchzuführen ist Aspekte: Aufgabenplanung (Ergebnis Arbeitspaket) Terminplanung (Meilensteine, Releases, Endtermin) Ressourcenplanung (Aufwand Mitarbeiter in Personentagen, Kosten für Hard/Software) -Kann in einem Gantt Chart erfasst werden

Answer 199

-Wichtigste Frage vor Projektbeginn: **Wie hoch wird der Aufwand?** Daraus ableitend: **Wie Lange wird die Entwicklung dauern? Und wieviele Leute benötigt man?** Die Ergebnisse der Aufwandsschätzung werden: - Kalkulation der Angebotserstellung (grobe Planung) - Personalplanung - Vorbereitung der Entscheidung "Entwickeln oder Einkaufen?" - Nachkalkulation =\> Neue Projekte kann man nie komplett abschätzen - Je früher man schätzt, desto unsicherer ist man - Später kann man durch abgeschlossene Arbeitspakete besser schätzen

Answer 200

-Lastenheft bzw. ersten Backlog (Anforderungen müssen gute Qualität haben) -Frühe Anforderungsqualität kann mit Workshops geschehen -Bei einem Wasserfallprojekt ist die Bekanntheit ALLER Anforderungen nötig (unmöglich), daher auf frühes Lastenheft und Formulierungen achten oder Projekttyp agil abändern

Answer 201

_Komplettes Projekt:_ - Analyse, Design, Implementierung, Test - Hohes Risiko für Auftragnehmer (Spezifikation steht noch nicht fest) _Teile des Projektes:_ - Angebot für Spezifikation, Entscheidung des Kunden durch wen Umsetzung geschehen soll - Angebot für Entwurf, Implementierung, Test, Abnehmetest _Bei Agil:_ - Kernfunktionalität - Ausbaustufe 1

Answer 202

- Geschätzte Stunden \* Stundensatz - Stundensatz definiert sich auf Skill-Level (PL mehr als Entwickler) - Stundensatz enhält Kosten für Fremdleistung \* Faktor x - Weite Kosten wie Reisekosten einberechnen -Die Schätzung sollte durch jemanden des Teams geschehen, der Technik Know-How hat (PL, Product Owner)

Answer 203

- Analogieschätzung: Auf Basis vorhandener Projekte - Expertenschätzung: Durch Fachleute - Algorithmische Schätzung: Kosten aus Größen berechnen die bekannt sind und genauer als der Aufwand geschätzt werden - Auch eine Kombination der Schätzung ist möglich

Answer 204

- Idealerweise aus Datenbank - Verteilung der Kosten auf Analyse, Spezifikation, Architektur, Implementierung, Test auf neues Projekt hochrechnen - Auf Phasenschätzung den Rest hochrechnen

Answer 205

- Experten: PL, fachlicher Experte, technischer Experte - Vorsicht vor zu leicht getroffenen Prognosen - Dokumentation wichtig: Voraussetzungen, Zeitpunkt, Personen, Vorbehalte - Schätzworkshop mit höchsten 3-4 Teilnehmern - Schätzung des Aufwands der Stückliste in Bearbeiterstunden oder Tagen - Entweder alle Posten schätzen oder einige Phasen schätzen und hochrechnen

Answer 206

-Ist eine Schätzungmethode ohne Diskussion _Beinhaltet:_ - Projektbeschreibung mit Teilprodukten - Ziele des Gesamtprojektes vorstellen - Jeder Experte schätzt im Arbeitsformular die Arbeitspakete alleine - Unterschiede werden dargestellt und Experten bekommen diese zurück - Solange bis alle Schätzungen im Toleranzabweichbereich liegen - Mittelwert ist der finale Wert -Die Breitband-Delphimethode ist mit Diskussionen

Answer 207

- Constructive Cost Model (CoCoMo I+2) - Function Point

Answer 208

-Berechnung des Aufwands und Entwicklungsdauer aus geschätzten Lines of Code - Man muss also trotzdem schätzen! - Beinhaltet spezielle Umstände (Sicherheitsanforderungen, Projektteamerfahrung)

Answer 209

- Aufwand hängt von Schwierigkeitsgrad und Umfang ab - Es werden die wesentlichen Geschäftsvorfälle gesammelt und in leicht/mittel/komplex klassifiziert -Tatsächlicher Aufwand ist oft ähnlich den Function Points -

Answer 210

- Eingaben (Unterschiedliche Logik/Format, Anzahl Datenelemente, Eingabeprüfung) - Ausgaben (Bildschirm, Interface, gedruckte Berichte, Komplexität des Berichtes in Zeilen, Spalten, Elementen) - Abfragen (Nur fest implementierende Online-Abfragen, keine Endbenutzerabfragen) - Anwenderdateien (Jeder gepfegte Bestand auf Basis DB-Design, Klassifikation nach Komplexität, Änderungsnotwendigkeit der DB) - Referenzdateien (Informationen, read-only) _Einflussfaktoren:_ - Bewertung mit Polaritätsprofil 0..5 - Liste der Einflussfaktoren - Function Points zu Mann-Monate umrechnen _Bewertung:_ - Prognosen und Einflussgrößen abhängig von Entwicklungsmethodik - Statistische Arugmentation benötigt Datenbasis (kein wirrer Haufen) - Schätzung ist firmenspezifisch - Ziel der Weiterentwicklung zu einer firmen-spezifischen Kostendatenbank - Tools gibt es dafür am Markt -Wird selten verwendet in der Wirtschaft

Answer 211

Einteilung des Projekts in Phasen Die zeitliche Anordnung der Arbeitspakete Meilensteine (also zentrale Projektergebnisse)

Answer 212

* **Phase:** zusammenhängender Zeitraum, in dem bestimmte Arbeiten durchgeführt werden. * **Ende einer Phase:** wird durch Meilenstein markiert. * **Phase erfolgreich beendet:** wenn Kriterien des Meilensteins erfüllt werden.

Answer 213

**Phasen erleichtern Kontrolle** * Für separate Finanzierungen (Spezifikation, dann Umsetzung) * Einteilung des Projekts in Iterationen * An Prüfungen (Meilensteinen) ist der Kunde beteiligt

Answer 214

**Was mach es?**: * Darstellung der Aufgaben und Termine in graphischer Form _Vorteile_ * weit verbreitet * übersichtlich * einfach * zeigt Parallelität auf _Nachteile_ * Änderungsaufwand groß * Übersichtlichkeit nur bei grober Granularitärt **_Erweiterungmöglichkeiten:_** * Zuordnung zu Ressourcen * Graphische Darstellung des jeweiligen Bearbeitungszustandes * Aktionen ohne Dauer (Ereignisse: Meilensteine)

Answer 215

* Netzplan

Answer 216

**_Kritischer Pfad?_** * = Folge von Aktivitäten, zwischen denen kein zeitlicher Puffer existiert _Was passiert, wenn sich eine Aktivität auf einem **kritischen Pfad verzögert?**_ * Hat Auswirkungen auf Gesamtdauer des Projekts * Kritischer Pfad braucht daher besondere Aufmerksamkeit

Answer 217

**_Externe Meilensteine_** * Ergebnisse die aus Auftraggebersicht bedeutend sind * (Z.B. Vorliegen, Spezifikation, Implementierung, Tests,... ,Fertigstellung einer Iteration in Agilen Projekten) **_Interne Meilensteine_** * Zwischenkontrollpunkte ohne Kundenbeteiligung * Und ohne Wissen des Kunden

Answer 218

**_Kriterien:_** * Kein Raum für Subjektivität und Willkür! **Definition eines Meilensteins:** 1. Definition der _Ergebnisse_, die vorliegen müssen 2. Die geforderten _Qualitätseigenschaften_ dieser Ergebnisse 3. Die _Instanz_, die entscheidet, ob ein MS erreicht ist 4. Der Vorgegebene _Zeitpunkt_ für das Erreichen **MS festgelegt durch Prozessmodelle (*Bsp. siehe Bild*)**

Answer 219

**Was ist noch bei der Planung zu berücksichtigen?** * Logische _Abhängigkeiten_ zwischen Arbeitspaketen * Arten von Anhängigkeiten * Ende-Anfang-Beziehung * Anfang-Anfang-Beziehung * Ende-Ende-Beziehung

Answer 220

**_Was ist noch bei der Planung zu berücksichtigen?:_** * Aufwand für die Arbeitspakete * Automatisiert durch * "Tool" oder * "von Hand"

Answer 221

Granularität ist kritisch denn: _Entwerder zu kurz:_ * Kunde andauernd in Anspruch genommen, keine ruhige Entwicklung möglich _Oder zu lang:_ * Verzögerungen die erst am Phasenende auffallen _Was muss eingeplant werden?_ Es müssen Verzögerungen durch **Puffer** eingeplant werden

Answer 222

**_Bei der Terminplanung:_** * _Auslastung_ und _Verfügbarkeit_ von Mitarbeitern und Betriebsmitteln

Answer 223

**Was ist noch bei der Planung zu berücksichtigen?:** * _Einflüsse_ von Außen * Lieferung von Software und Hardware * Bereitstellung von Daten, Algorithmen, usw. * Bestätigung der Abnahme von Zwischenresultaten

Answer 224

**_Was ist bei der Planung zu berücksichtigen?:_** * _Logische Abhängigkeiten_ zwischen Arbeitspaketen * _Aufwand_ für die Arbeitspakete * _Einflüsse_ von Außen

Answer 225

**_Nenne Zwei eigenschaften Von Ressourcen:_** * Knappheit * Kosten Geld **_Warum sollten Ressourcen bei der Planung berücksichtigt werden?_** * Zur Einhaltung der Termine * Aus kostengründen (Keine Unnötigen mehrkosten)

Answer 226

**_Wie geht der Projektleiter bei der Planung vor?:_** * PSP * Schätzmethoden * Termin- und Recourcenplanung

Answer 227

Software-Entwickeln **ist** Dokumentation.

Answer 228

* Dokumentation gilt als ewiges **Sorgenkind** und ist eine **Daueraufgabe** * Nachträgliche Dokumentation ist eine **unzureichende Notlösung** (Denn Info ist vergessen)

Answer 229

* _Integrierte Dokumenttion_ (enthaltene Komentare, Bezeichner des Layouts) * _Separate Dokumentation_ (Teil der Software, die nicht im Programm enthalten sind)

Answer 230

Nein, nur stabilität ist geforgert! (Es gibt keine Dokumentation im Kopf)

Answer 231

* Ist leichter zu bearbeiten und kann eher nachgeführt werden * Reicht in keinem Falle aus!

Answer 232

* Glossar * Spezifikation (Wireframes, Use Cases, Datenmodell,...) * Architektur-Entwurf

Answer 233

* Sie können nicht in Code-Komponenten abgelegt werden (Die Projektdokumentation ganz zu schweigen)

Answer 234

* Ist grundsätzlich gefährtdet und kann nur unter gewissen Bedingungen funktionieren?

Answer 235

1. Anforderung an Dokumente müssen klar sein 2. Verantwortlichkeiten klären * (Wer erstellt, prüft, gibt frei) 3. Dokumentaion soll hoch bewertet und anerkannt sein 4. Inhaltsverzeichnis (Struktur) muss von Anfang an klar sein 5. Werkzeugunterstützung muss verfügbar sein 6. Prüfung der Dokumente nach Ändereung/Fertigstellung 7. Dokumente werden effektiver Konfigurationsverwaltung unterstellt

Answer 236

- Wissenstransfer und Kommunikation zwischen Auftraggeber- und Nehmer - Dokumentation bewahrt das Wissen über Programm, Entwicklung, Wartung - Dokumentation erlaubt systematische Prüfung (Review) und belegt diese (revisionsfest) - Dokumentation spiegelt Projektfortschritt wider (Liegt Test vor?-\> nachgucken)

Answer 237

- Nutzen ist verteilt und fern - Kosten treten sofort sichtbar auf - Oft wird daher an der Doku gespart

Answer 238

* Vermeiden (,rasches finden) von Fehlern * Software kann einfacher erweitert & wiederverwendet werden

Answer 239

* Produktivität im Ø --\> 4 Seiten pro Tag * Diese Arbeit ist 1000 € Wert * 40 Seiten Starkes Dokument 40.000€ * (Produktivität hier eher hoch geschätzt)

Answer 240

1. Systemdokumentation 2. Projektdokumentation 3. Qualitätsdokumentation 4. Prozessdokumentation *(Möglicher Wiki-Aufbau)*

Answer 241

Dokumente die für die Konstruktion/ Betrieb/ Wartung der Software benötigt werden. (unterscheidung techn./fachl.)

Answer 242

* Alle Dokumente die benötigt werden, um das Entwicklungsprojekt zu planen/zu leiten/abzuschließen.

Answer 243

Alle Dokumente in denen die Maßnahmen zur analytischen Qualitätssicherung dokumentiert sind.

Answer 244

* Beschreibt den Entwicklungsprozess und seine konkrete Umsetzung im Projekt.

Answer 245

* Dokumentiert wie sie installiert, betrieben und bedient wird. (Notwending, damit Software eingesetzt werden kann)

Answer 246

1. Benutzungshandbuch 2. Tutorial 3. Installationshandbuch 4. Kontextsensitive Hilfe 5. Onlineinformationen

Answer 247

1. Unklare Zielvorstellungen/Anforderungen des Kunden 2. Häufige Änderungen Während des Projekts (Change Requests) 3. Arbeitsprozesse außerhalb des kurzfristigen Planungshorizontes bergen zu viele Unsicherheiten 4. Zu viele abgegrenzte Aktivitäten/Teams ("Teilprodukte über die Mauer werfen") 5. Tests des Produktes am Ende ist viel zu spät

Answer 248

* Geisteshaltung durch agiles Manifest populär geworden * Umgesetz durch "agile Methoden"

Answer 249

1. Wartungsingenieure arbeiten als Archäologen 2. Grundlagen für die Handbücher fehlen 3. Retrospektive Analysen sind nicht möglich (Keine Möglichkeit für Organisation aus Projekt zu lernen)

Answer 250

* Software-Entwickler haben dies nicht gelernt (Weder in Ausbildung noch in Praxis) * Priorität 1, 2 und 3 ist einhaltung des Liefertermins * **FOLGE**: --\> Zeit für Doku fehlt

Answer 251

_Eher nicht denn:_ * Keine Abstraktion * Stellt Code direkt dar * Lieber anders herum * Keine Gedanken vorher gemacht (Wenn man automatisch generierte Dokumentation nutzt dann vielleicht über **arc42.de**)

Answer 252

1. Personalprobleme (mangelnde Qualifikation durch Neueinstellung, Umschichtung, mangelhafte Fortbildung) 2. Unrealistische Pläne/Budgets (Z.B durch Unterprisangebote wegen hohem Wettbewerbsdruck) 3. Entwickeln der falschen Funktionen & Eigenschaften (Bsp.: Onlineshop gemacht mit schlechter Kundenanalyse) 4. Entwickeln der falschen Benutzungsschnittstelle (z.B. komplizierte Oberfläche) 5. "Goldverzierungen" (z.B graphisch verzierte Oberfläche--\> Schnickschnack) 6. Ständiger Wechsel der Anforderungen (Z.B. durch unzureichend ausgearbeitetes Lastenheft,...) 7. Versagen externer Komponenten (Z.B. Fehler einer zugelieferten Komponente) 8. Versagen externer Aufträge (Z.B. erxterner Lieferant für Datenbanklösung geht in Konkurs) 9. Zu geringe Leistungen (Z.B. Überlastung von Servern) 10. Fehleinschätzung des Standes der Technik (Z.B. Performance neu entwickelter Datenbanktechnik wird überschätzt)

Answer 253

* Prozessmodelle wie (Wasserfallmodell, V-Modell (später), Unternehmenseigene Modelle) * Anforderungen erheben * Architektur erstellen * Dokumente verfassen * Planung, Verträge

Answer 254

* Software-Bürokratie * Kunde zu spät eingebunden * Vertrags- statt Kundenorientierung * Kein Spaß * Träge und teuer (Begründung dieser Kritik nicht wissenschaftlich sondern begründet durch Beobachtung, "gesunder Menschenverstand")

Answer 255

- Individuals and Interactions (over processes and tools) - Working Software (over comprehensive documentation) - Customer collaboration (over contact negotiation) - Responding to change (over following a plan)

Answer 256

Kunden zufriedenstellen und Software ausliefern Auf änderungswünsche des Kunden zu jeder Zeit eingehen Software regelmäßig abfliefern Leute aus Buiseness und Entwicklung müssen zusammenarbeiten Gutes Arbeitsklima schaffen und Unterstützung geben Face to Face conversation zum Infoweitergeben Funktionierende Software definiert Entwicklungsfortschritt Agile Prozesse --\> Gut für Entwicklung, sollen in einer konstanten Geschwindigkeit geschehen Wertlegen auf technische Perfektion Einfachheit Selbst-organisierte teams erzielen die Besten Ergebnisse Wiederholende Selbstreflektion des Teams

Answer 257

* **XP** - Extreme Programming → Fokus auf teaminterne Engeneering-Praktiken ("Von Programierern für Programierer) * **SCRUM** - Framework mit Fokus auf Struktur und Kommunikation ("Management")

Answer 258

**Iterationen** → Boehms' Spiralmodell **Story Points** → Function Points **Continious Integration** → "Daily Build" bei Microsoft (1995) **Retrospective** → Aus CCMI, KAIZEN (Kontinuierliche Verbesserung)

Answer 259

Weiter gehts, ich hab dich lieb!

Answer 260

* In den 80/90ern

Answer 261

- Verantwortlich arbeiten können nur hochqualifizierte Teams - Kleine Teams (bis 10 Pers) (Sonst zu viel Kommunikation) - Gemeinsamer Raum für alle Teammitglieder! - Wir brauchen _keine_: Star-Architekten, Gurus, Alleinarbeiter - Management-Akzeptanz bei Auftragnehmer und -geber

Answer 262

**Kurze Zyklen bis zur Auslieferung** * Nach ca. 1 Monat ausliefern * Realease abnehmen/bewerten lassen von Kunden **Evolutionäre Entwicklung** * Keine große Architektur sondern mit klein & angemessen beginnen und dann refactoring **Testgetriebene Entwicklung** * Automatisierte Tests vor dem Code schreiben * Testen aller features (User-Stories statt tradit. Anforderungen) **Teamarbeit** * Pair Programming, Collective Code Ownership **Dokumentation verliert an Wichtigkeit** * Nicht "keine Dokumentation"! * Kommunikation ersetzt Dokumentation **Kunde als Teil des Teams** * ****Spart Zeit * Kunde bestimmt Umfang des Wertesnach seinen Prioritäten **Vertrauen** * Kunde hat vertrauen in Team/Vorgehen * Statt Festpreis variabler Preis (oder variabler Umfang) **Änderungen Willkommen** * Kein Change-Request-Verfahren, sonder Änderungen für neues Release immer möglich

Answer 263

Ist Iteration in SRCRUM Hat fixe Längen (2 Wochen, 4 Wochen) Ergebnis von Sprint soll lauffähige Software sein Wird Kunden am Sprintende zur Evaluation präsentiert Während eines Sprints ist _keine_ Kundeninteraktion (Product Owner) erlaubt * Konsequenz: Features/Anforderungen währen Sprint fixiert * Keine Störung von "außen"

Answer 264

Enthält (technischen) Aufgaben die notwendig sind um das Sprint Ziels zu erfüllen Charakterisierung: "Aufgabe" * eine nicht länger als 16 Std dauern * längere in Teilaufgaben zerlegen * bei Planung Arbeitsgeschwindigkeit (Team) bdenken * Teams aktualisieren Aufwände während Sprint * Jedes Teammitglied kann Pakete: * ergänzen, ändern, löschen

Answer 265

**Representiert Endkundenbedürfnisse** * (traditionell machte dies der Prokejt manager) **Für erreichung der wirtschaftl. Ziele verantwortlich** * Steuert diese durch priorisierte Produckt Backlog und den Release Plan **Erstellt Produktkonzept und das Product Backlog** * Dies wird kontinuierlich bearbeitet * Neue Anforderungen kommen hinzu, werden neu priorisiert * hochpriorisierte Anforderungen werden in neue verfeinert * enge Kommunikation mit Kunden **Erstellt/Aktualisiert Releaseplan** **_⇒ Wichtige Projektmanagementaufgaben führt er also selbst durch!_**

Answer 266

Das Team führt die Arbeiten zur Produkterweiterung aus Team entscheidet selbst, wie viele Anforderungen es im nächsten Sprint in Producktinkrekremente umwandeln kann. * 5-9 Mitarbeiter * Team entscheidet über Arbeitschritte/Organisation * (Entgegen trationellen Management)

Answer 267

Ist **Coach** → hilft Team Scrum richtig einzusetzen Überwacht einhaltung der Scrum Regeln Moderiert Meetings Sollte versuchen sich schnell überflüssig zu machen

Answer 268

* Aufwand ist relativ zu anderen Aufwenden abschätzbar * Beginn mit klarer u. kleiner Anforderung * Anhand kleiner Anforderungen große abschätzen * Gleichgroße Anforderungen gruppieren * Product Backlog bei Disskursion benutzen * Schätzungen möglichst realistisch * genau - ist unmöglich

Answer 269

* Scrum = "*Gedränge*" (Aus dem Rugby) Annahme * Entwicklungsprozesse sind so komplex, dass sie sich kaum vorausplanen lassen

Answer 270

**Berichterstattung in Scrum schafft Transparenz** * Verzögerungen/Fortschritt schnell einsehbar **Burndown-Bericht** * beschreibt aktuellen Projektfortschritt * führt Summe aller Aufwände im Spring-Backlog auf * Zeigt Änderungen der Aufwände an * Führt Summe aller Aufwände im Product Backlog am Ende jedes Sprints auf (zeigt Änderungen über Sprint-Grenzen hinweg auf) Burndownchart * Verfolgung der Restaufwände für Gesamtprojekt Aufwandsschätzung (Product Backlog) in Jira * Mittels Comulative Flow Diagramm

Answer 271

Es gibt groben Ramen vor * Darin organiesiert Team sich selbst, Produktivität soll dadurch steigen Team übernimmt gemeinsam Verantwortung für Tätigkeiten Keine Kontrolle von "Oben" Keine konkreten Use-Cases und Entwürfe werden vorgegeben

Answer 272

Ist ein agiles Managementframework zur Entwicklung von Software mit wenigen klar definierten Regeln _Anwndung von 3 Rollen_ * Product owner * Team * Scrum Master Das **Product Backlog** enthält priorisierte Anforderungen Erstellung von Produktinkrementen innerhalb kurzer Arbeitszyklen, genannt **Sprint** * Jedes Produktinkrement ist getestet und dokumentiert * Jeder Sprint beinhaltet Analyse, Design, Implementierung, Test, Bugfixing, Dokumentation

Answer 273

Ja, als agiles Framework tut es das.

Answer 274

* Punkte verrechnen

Answer 275

Statusmeeting des Teams (max. 15 min im Stehen) Dient Informationsaustausch der Teammitglieder _Jedes Teammitglied beantwortet:_ * Welche Arbeitspakete hab ich seit letztem Meetig fertiggestellt * Welche Arbeitspakete wirst du bis zum nächsten Meetig bearbeiten * Gibt es behindernde Probleme bei deinen Aufgaben Hindernisse nimmt der Scrum Master ins Impediment Backlog auf und beseitigt sie

Answer 276

Sprint Ergebnis wird einem Review unterzogen * Durch Team und Kunden * Z.B. Präsentation der laufenden Software Was wird gemacht?: * Kunde prüft ob seine Anforderung erfüllt sind * Eventuelle Änderungen werden im Product Backlog dokumentiert

Answer 277

* Betrachtung der zurückliegenden Sprintphase * "Was war gut"/ "was hat Verbesserungspotential"? * Eventuelle Anpassung des Impediment Backlogs * Eventuelle Anpassung des Product Backlogs * 15-30 Min

Answer 278

Scrum fördert die enge zusammenarbeit ist aber kein Wundermittel! Das erfolgreiche Anwenden ist ein Lernprozess (dieser braucht Zeit und Geduld) * Oft sind die ersten Sprints (Iterationen) schwierig

Answer 279

Anmerkung: Immer auch die anderen "alten" Tests durchführen

Answer 280

Enthält Features/Anforderungen des zu entwickelnden Produktes * Grundlage (erster Fassung) bilden Lastenheft, User-Stories, Interviews, Workshops * Umfasst alle Funktionen die Kunde wünscht * Vor jedem Sprint neu bewertet/priorisiert * Aber auch Bugs, technische Zwischenaufgaben,..

Answer 281

* Ablehnung traditioneller Projektleitungsaufgaben * Geht für meisten Teams nicht * Niemand will "Hilfs- Projektleiter sein" * Ablehnung von Hilfs-/Zwischenprodukten/ nicht auslieferbaren Produktteilen * Ablehnunf von Softwarearchitekturen * Ablehnung von Wiederverwendbarkeit als Entwicklungsziel * Kunde im Team * (In Praxis Kunde schwierig) (Product-Owner gut)

Answer 282

hoch prioris. * stehen am Anfang * werden im Aufwand geschätzt (von ENtwicklern) * in Sprint Backlog übernommen und in Unteraufgaben zerlegt niedrig prioris. * nicht detailiert beschrieben * Zeit wird für wesentlichen Elemente verwendet

Answer 283

Vertrautheit mit der fachlichen Domäne? Homogene bearbeitung der Geschäftsprozesse/Anwendungsfälle von vers. Benutzern? Fachliche Varianten, Ausnahmen zu berücksichtigen? Ist Ablauf neu/verändert? Wie viele vers. personen als Anforderungsgeber sind zu beachten? Gibt es Risiko durch zu wenig Requirements-Engeneering in verzögerung, mehrkosten zu kommen? Folgen bei vergessen von fachlichen Varianten/Details

Answer 284

* Teilnehmer, Team, Product Owner & Srcum Master * Geht 2 Std lang * Soll alle Einträge des Product Backlog abschätzen * Ist bei Veränderungen während des Sprints nötig * Team schätzt gemeinsam ab (durch Diskursionen)

Answer 285

Sprint Planungstreffen Teil 1 * Product Owner erklärt Team die Anforderungen an Backlog Einträge * Einigung über "Sprint-Ziel" (Basis für Abnahme) Sprint Planungstreffen Teil 2 * Eigenverantwortliche Planung durch Team * Zerlegung der Backlog-Einträge in Arbeitspakete (AP) * Verteilung der Aufgaben an Teammitglieder * Erstellung des Sprint Backlog (+Schätzung der AP in std) * Schätzung im BacklogProduct ergänzen/anpassen

Answer 286

**Velocity** = *Entwicklungsgeschwindigkeit* (in Scrum) Für bessere Planung Einschätzung der Velocity Velocity = **Summe aller Aufwände** der von Sprintende vom Product Owner abgenommenen Arbeitsergebnisse * Unfertige Ergebnisse (99,9% fertig) werden im Scrum **_nie_** abgenommen --\> Es gibt daher keine "Anteilspunkte" für teilhafte Ergebnisse

Answer 287

* Erfahrungen aus vorhergehenden/ähnlichen Projekten * 2-3 Sprints durchführen und den erzielten Mittelwert nehmen

Answer 288

**DoD = Definition of Done** * Ist das Fertigstellungskriterium eines Product Backlog Eintrags * Variiert von Scrum zu Scrum Team * Sollte innerhalb eines Scrum Teams konsequent sein

Answer 289

Westlicher Begriff für das TPS ("Toyota Production System") "Lean" stammt aus Produktion "Agile" stammt aus Softwareentwicklung _Lean Software Developement Prinzipien_ * Müll beseitigen * Besser werden * Enscheiden so spät wie möglich * Liefern so schnell wie möglich * Das Team stärken * Qualität einbauen * Alles optimieren

Answer 290

**Agile**: _Fokus auf Produkt_ * "Agile" stammt aus Softwareentwicklung * Wollen auf veränderte Anforderungen reagieren können, daher bei ihnen sehr flexible Vorhergehensweise **Lean**: _Fokus auf Prozess_ * "Lean" stammt aus Produktion * Kombination aus Fokussierung auf beteiligte Menschen & Anspruch der stetigen Verbesserung * Wollen Prozesse standardisieren & vereinfachen * So lange bis nur noch die Elemente da sind, die wesentlich für Wertschöpfung sind

Answer 291

* Bertrant Meyer * Bewertung agile Entwicklungsmethodik aus entspannter wissenschaftlicher Sichtweise * Er deffiniert agile Methoden * Unterscheidet in * The "Good" * The "Bad" * The "Ugly"

Answer 292

* **Pair Programming** * = 2 gleich kompetente Programmierer arbeiten gleichzeitig (Dies ist manchmal sinnvoll) * Ein "Open-space"-Büro * Selbstorganisierende Teams * Bedenke (Fast kein Orchester kann ohne Dirigent arbeiten) * Verträgliche Arbeitszeiten einhalten (:/ Deadlines) * Erstellung von minimaler Funktionalität * Planning game, planning poker (Aufwände schätzen) * Jeder im Team kann alles (Anmerkung: unrealistisch)

Answer 293

Reaktion auf Plattitüden --\> Anmerkung _Anmerkung_ * kritisch mit neuen Vorhergehensweisen umgehen

Answer 294

* Entwickeln sie Software systematisch und verbessern sie stetig * Benutzen sie projektspezifische, gut angepasste Methoden (Manchmal Agil, manchmal nicht * Kommunizieren sie * Softwareentwicklung ist nicht rein technisch * Bleiben sie am Ball den SE und Informatik entwickeln sich stetig * Keine unnötige Laberei * Kein certified Geldverfdiener-Master * Keine Religion statt Wissenschaft _Anmerkung_ * Zertifikate heißen nicht dass du gut bist * Sind aber gut für den Lebenslauf

Brainscape's Knowledge GenomeTM

Software Engineering 2 - Klausur HANNA NUR DIESES LERNEN BITTE Flashcards

Brainscape's Knowledge Genome^TM