Software Engineering 1 - Klausur Flashcards Preview

test > Software Engineering 1 - Klausur > Flashcards

Flashcards in Software Engineering 1 - Klausur Deck (252)
Loading flashcards...
1
Q

Nenne die 3-Schichten-Architektur von oben nach unten!

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
GUI/Benutzeroberfläche
               |
Applikationslogik
               |
Persistenzschicht
2
Q

Nenne die Aufgabe der GUI/Benutzeroberfläche innerhalb der 3-Schichten-Architektur.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

Die GUI/Benutzeroberfläche ist der Teil auf dem der Anwender agiert. Jener kapselt sich vom Anwendungskern ab.

3
Q

Nenne die Aufgabe der Applikationslogik innerhalb der 3-Schichten-Architektur.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

In der Applikationslogik liegt die gesamte fachliche Logik des Systems.

4
Q

Nenne die Aufgabe der Persistenzschicht innerhalb der 3-Schichten-Architektur.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

In der Persistenzschicht liegt der technische Teil des Systems, z.B. die Datenbank.

5
Q

In welcher Schicht der 3-Schichten-Architektur liegen die fachlichen Komponenten.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

Die fachlichen Komponenten liegen in der Applikationslogik, also der 2. Schicht von oben.

6
Q

Was sind die Vorteile der Architektur in ein 3-Schichten-Modell?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Die flexible Austauschbarkeit: Es ist somit z.B. möglich, dass die GUI einfach ausgetauscht wird, da diese unabhängig von der Applikationslogik oder der Pesistenzschicht ist.

7
Q

Was testet ein Integrationstest?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

Ein Integrationstest testet das Zusammenspiel von verschiedenen Komponenten.

8
Q

Welche typischen Phasen/Aktivitäten gibt es in einem Softwareprojekt? Erläutern Sie die Phasen und die Tätigkeit kurz.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Analyse/Spezifikation -> Planung, Ist-Analyse, Soll-Analyse, Verhandlung mit dem Kunden, Lastenheft, Pflichtenheft
  • Entwurf -> (Wie soll die Architektur/Lösung konzipiert werden?)
  • Implementation -> Implementation/Programmierung des Projektes
  • Test/Debugg -> Test aller Arten, Fehlerbehebung
  • Installation -> Installation/Einführung des Systems beim Kunden
  • Wartung -> Wartung des Systems
9
Q

Nennen Sie drei Möglichkeiten, wie in der Analysephase eines Projektes Kundenanforderungen durch einen Analysten herausgefunden werden können.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • gezieltes Nachfragen nach Wünschen des Kunden
  • Workshops mit dem Kunden(Stakeholdern)
  • Ist-Analyse
10
Q

Beschreiben Sie typische Aufgaben einer Fassade in der Quasar-Standardarchitektur.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

??????????????

11
Q

Warum entstehen gerade in der Softwareentwicklung so schnell Bugs/Fehler?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Software kann man nicht direkt wahrnehmen
  • Komplexitäten sind schwer einzuschätzen
  • Kopien und Originale sind völlig gleich (Konsistenzprobleme)
  • Es gibt keine natürliche Lokalität (Fehlereingrenzung/Lokalisierung schwer)
  • Die Herstellung braucht keine Rohstoffe oder physikalische Werkzeuge und die Werkstoffe (Sprachen) implizieren keine sinvollen Strukturen
12
Q

Was ist das Whiscy-Syndrom?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Steht für Why Isn’t Sam coding yet und verkörpert eine negative Erwartungshaltung in der Softwareentwicklung, welche dazu führt, dass Entwickler immer Coden sollten, immer alles im Kopf haben sollten und Prototypen zu fertigen Produkten umstrukturiert werden.

13
Q

Nennen Sie 10 klassiche Projektfehler!

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  1. Komplexität und Kosten wurden unterschätzt
  2. Fehlende Kontrolle über Anforderungen oder Umfang!!!!
  3. Fehlende Kommunikation!!!
  4. Kunden/Stakeholder nicht ausreichend eingebunden!!!
  5. Kulturelle Probleme nicht adressiert
  6. Schlechte Projektmanagement
  7. Schlechte Ausführungsqualität!!!
  8. Fehlendes Risikomanagement
  9. Nichtfunktionale Anforderungen nicht adressiert
  10. Schlecht geplante Einführung
14
Q

Was ist ein Stakeholder?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Interessensgruppen

15
Q

Nennen Sie die Aktivitätsphasen und Tätigkeiten während eines Projektes!

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  1. Analyse/Spezifikation(Requiremens) (Was soll gemacht werden?)
  2. Entwurf/Design (Wie? Konzeption der Lösung/Architektur)
  3. Implementation (Übertragung des Entwurfes in ablauffähigen Codes)
  4. Integration/Tests (Zusammenbau der Komponenten und Gesamttests)
  5. Installation/Wartung (Schulung/Fehlerbehebung/Weiterentwicklung)
16
Q

Erklären Sie den Wasserfallansatz entgegen den iterativen Ansatz in der Projektentwicklung.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

…..

17
Q

Beschreiben Sie den Verlauf/Schritte der Wasserfallmethode.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  1. Initiales Konzept
  2. Die Aufgaben herausarbeiten
  3. Requirements schreiben
  4. Vollständiges Requirement-Dokument
  5. Code entwickeln
  6. Fertiges Produkt
18
Q

Beschreiben Sie den Verlauf/Schritte der iterativen Entiwicklung.

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

1.Initiales Konzept
2.Vorläufige Geschäftsanalyse
3. Absprache mit dem Produkt Owner
4.User Stories schreiben
5.Partielles Produkt/Feature entwickeln
6. Feedback einholen
7. User Stories schreiben
….
8. Fertiges Produkt

19
Q

Was ist das Problem an Wasserfallprojekten?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Alle Entscheidungen werden am Anfang getroffen.
  • Komplexitäten und Kosten schwer abschätzbar.
  • Oft entstehen am Ende die Probleme und teuren Änderungen
  • Anforderungen an das Produkt ergeben sich erst im Verlauf
  • Eventuell sind manche Dinge nicht umsetzbar, was erst spät erkannt wird.
20
Q

Was ist der Vorteil an iterativen Projekten?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Durch Zwischenstände/Features können neue Ideen enstehen

- Durch Zwischenstände/Featues können Meinungen und Ideen geändert werden.

21
Q

Was ist das Problem an iterativen Projekten?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Für manche Projekte ist das Verfahren ungünstig und nicht zu empfehlen.

22
Q

Was ist der Vorteil an Wasserfallprojekten?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Projekte die sehr klar und linear abschätzbar sind können damit schneller entstehen. Z.b. konstante mathematische Berechnungen brauchen kaum Zwischenstops.
  • Wenn man das Produkt schon im vornherein sehr gut kennt ist es einfacher.
23
Q

Was für ein Problem existiert dabei die Anforderungen an ein Produkt zu erfassen?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Ein Kommunikationsproblem, da aus Business und Technischer Sicht die Dinge oft sehr verschieden betrachtet werden. Es kommt leicht dazu, dass man aneinander vorbei redet.

24
Q

Was ist über Requirements/Anforderungen zu wissen?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Sie müssen nicht unbedingt ausgeschrieben werden, aber sie müssen den Projektteilnehmern bekannt sein.
  • Der Kunde gibt oft nicht die richtige Antwort.
  • Requirements entstehen nicht durch Zufall, sondern aus Prozessen, der die Entwicklung bedingt.
  • Unsere Aufgabe ist es die Art, wie der Benutzer über Probleme denkt zu ändern.
25
Q

Wozu nutzt man Personas?

“Analyse-Themen”

A
  • Personas repräsentieren Nutzer des Systems
  • Sie sind fiktionale Charaktere mit Namen, Bild, Charakteristiken, Einstellungen und Zielen
  • Proto-Personas sind ein Best-Guess wer einmal unser Produkt nutzen möchte und warum
26
Q

Welche Details sollte eine Proto-Persona beinhalten?

“Analyse-Themen”

A
  • Personendaten
  • Beruf
  • Hobby
  • Charakter
  • Lebensziele
27
Q

Wozu benutzt man das Value Proposition Canvas?

“Analyse-Themen”

A
  • Um das richtige Produkt für den Kunden zu finden
  • Um die Probleme und Bedürfnisse einer Zielgruppe zu finden
  • Um den Wert und Nutzen für Kunden zu schöpfen
  • Analyse der Zielgruppen
28
Q

Wie benutzt man das Value Proposition Canvas? (Bestandteile)

“Analyse-Themen”

A

(Grüner Kasten)

  • Product & Services
  • Gain Creators
  • Pain Relievers

(Roter Kreis)

  • Gains
  • Pains
  • Customer Jobs
29
Q

Welche Fragen sind beim Value Proposition Canvas bei den Customer Jobs (roter Kreis) entscheidend?

“Analyse-Themen”

A
  • Welche funktionalen Jobs will der Kunde erledigen?(Probleme lösen)
  • Welche sozialen Jobs will der Kunde erledigen? (Macht, Status,Nachhaltigkeit)
  • Welche emotionalen Jobs will der Kunde erledigen? (Sicherheit, Wohlgefühl)
30
Q

Welche Fragen sind beim Value Proposition Canvas bei den Pains (roter Kreis) entscheidend?

“Analyse-Themen”

A
  • Was kostet zu viel/dauert zu lange?
  • Was sind die Hauptprobleme?
  • Wo gibt es fehlende Funktionen?
  • Welche Risiken fürchtet der Kunde?
31
Q

Welche Fragen sind beim Value Proposition Canvas bei den Gains (roter Kreis) entscheidend?

“Analyse-Themen”

A
  • Wo möchte der Kunde Vorteile? (Zeit,Geld, Aufwand)
  • Wie kann das Produkt ein Kundenproblem lösen?
  • Wonach suchen die Kunden?
  • Welche bestehenden Lösungen gibt es und mag er?
32
Q

Welche Fragen sind beim Value Proposition Canvas bei den Product&Services (grüner Kasten) entscheidend?

“Analyse-Themen”

A
  • Welche Produkte biete ich an, die Aufgaben des Kunden lösen?
  • Welche Produkte biete ich an, die Bedürfnisse des Kunden befriedigen?
  • Welche Produkte helfen dem Kunden als Käufer?
33
Q

Welche Fragen sind beim Value Proposition Canvas bei den Pain Relievers (grüner Kasten) entscheidend?

“Analyse-Themen”

A
  • Wie setze ich den Schwierigkeiten ein Ende?
  • Wie sind meine Lösung besser als bestehende?
  • Wie vermeide ich negative Konsequenzen?
34
Q

Welche Fragen sind beim Value Proposition Canvas bei den Gain Creators (grüner Kasten) entscheidend?

“Analyse-Themen”

A
  • Wie erleichtere ich das Leben des Kunden?
  • Womit erfülle ich Kundenbedürfnisse?
  • Wie kann ich das bieten was der Kunde will?
35
Q

Warum ist es wichtig alle Zielgruppen zu kennen?

“Analyse-Themen”

A

-Weil man sonst keine gute Software entwickeln kann
-Um das Produkt wirklich den Anforderungen der verschiedenen Nutzer anpassen zu können
(-Dazu können User Roles genutzt werden)

36
Q

Was ist eine User Role?

“Analyse-Themen”

A

-Eine Nutzerrolle/User Role ist eine Menge von Attributen, die eine Population von Nutzern und ihre Beabsichtigten Interaktionen mit dem System beschreibt.

37
Q

Was sind die Schritte wie User Roles gebildet werden?

“Analyse-Themen”

A
  1. Brainstorming für initiale Menge von User Roles
  2. Rollen organisieren/ordnen(Gruppieren)
  3. Rollen konsolidieren(Unterordnen/Einreihen)
  4. Rollen verfeinern(Rollenverhalten und Eigenschaften mit Text beschreiben)
38
Q

Wie können von den Nutzerrollen/User Roles nun Anforderungen abgeleitet werden?

“Analyse-Themen”

A

-Durch die Verwendung von User Stories

39
Q

Was ist eine User Story?

“Analyse-Themen”

A

-Eine User Story stellt eine Anforderung dar.

40
Q

Nennen Sie ein Beispiel für eine User Story.

“Analyse-Themen”

A

-“Als Benutzer kann ich meine Bilder in meinem Profil hochladen”

41
Q

Worauf muss beim Erstellen einer User Story vorhanden sein?

“Analyse-Themen”

A
  • Die Rolle muss vorhanden sein
  • Und das Ziel/Wunsch muss vorhanden sein
  • Keine Technischen/Fachlichen Beschreibungen(In Java geschrieben)
42
Q

Was sollen User Stories für den Kunden bringen?

“Analyse-Themen”

A

-Eine User Story soll einen Wert für den Nutzer besitzen.

43
Q

Nennen Sie 3 gute User Stories!

“Analyse-Themen”

A
  • Als Gruppenmoderator kann ich die Kanalbeschreibung verwalten.
  • Als Nutzer kann ich meinen Verlauf löschen.
  • Als Nutzer kann ich neue Angebote inserieren.
44
Q

Fehlen bei den User Stories nicht die Details damit ein Developer damit arbeiten kann? Was macht man mit offenen Fragen?

“Analyse-Themen”

A

-Nein, denn durch Story-Splitting können weitere Epics abgeleitet werden und neue User Stories geschrieben werden.

45
Q

Wie nennt man eine “Große” User Story?

“Analyse-Themen”

A

-Epic (Was möchte der Nutzer grob machen?)

46
Q

Nennen Sie ein Beispiel für ein Epic und dessen Aufteilung in User Stories.

“Analyse-Themen”

A
  • Epic: Als Benutzer kann ich nach Inseraten suchen.
  • User Story: Als Benutzer kann ich nach dem Preis von Inseraten sortieren.
  • User Story: Als Benutzer kann ich die Bewertungen jedes Händlers sehen, der Angebote inseriert hat.
47
Q

Worauf ist bei Epics zu achten?

“Analyse-Themen”

A

-Das sie nicht zu fein granuliert erstellt werden.
Beispiel:
Epic: Als Benutzer kann ich nach Inseraten suchen.
-User Story: Als Benutzer kann ich den Titel des Inserats sehen
-User Story: Als Benutzer kann ich die Beschreibung des Inserats sehen
-User Story: Als Benutzer kann ich den Preis des Inserats sehen

48
Q

Warum sollte man User Stories verwenden?

“Analyse-Themen”

A
  • User Stories sind für die Kommunikation und nicht zum schriftlichen Festhalten
  • User Stories sind für Benutzer und Entwickler verständlich
  • User Stories haben richtige Planungsgrößen
  • User Stories sind gut für iterative Entwicklung
  • User Stories leiten dazu Details bis zu einem Punkt zu schieben bei dem klar ist, dass man es wirklich benötigt.
49
Q

Was sind traditionelle Anforderungserfassungen?

“Analyse-Themen”

A

-Der IEEE-Standard 830-1998

50
Q

Wie teilen sich Anforderungen in der traditionellen Anforderungserfassungen auf?

“Analyse-Themen”

A

-Funktionale Anforderungen
(Das System soll eine Liste von Profilen anzeigen können)
-Nichtfunktionale Anforderungen/Qualitäsanforderungen
(Das System soll die Suchergebnisse innerhalb von 2 Sekunden anzeigen)

51
Q

Anhand welcher Schritte findet man Anforderungen/Requirements?

“Analyse-Themen”

A
  1. User Roles und Personas
  2. Epics ableiten(Ziele der Personas/Rollen ansehen)
  3. Epics in feingranulare User Stories splitten
52
Q

Wie lauten die Schritte eines Projektes im Wassserfallkonzept?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  1. Analyse
  2. Entwurf
  3. Implementierung
  4. Test in strenger Sequenz
53
Q

Wie lauten die Schritte eines Projektes im Agilen/iterartiven Konzept?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Es herrscht ein stetiger Lernprozess während des Projektverlaufes.
    1. Analyse
    2. Entwurf
    3. Implementierung
    4. Test stetig wiederholt (mit unterschiedlicher Intensität)
54
Q

Wie läuft ein agiles Projekt ab?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  1. User Roles werden definiert
  2. Benutzer schreiben die User Stories
  3. Initiale Stories in einem Workshop
  4. Stetige Verfeinerung, Priorisierung und Schätzung der Stories
55
Q

Wie werden User Stories im iterativen Verfahren eingeteilt, priorisiert und geschätzt?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Durch die Zuordnung in verschiedene Releases

- Durch die weitere Zuordnung in einzelne Iterationen innerhalb eines Releases

56
Q

Was ist das Kanban-Board?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
57
Q

Woraus besteht ein Kanban-Board?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Aus dem Zustand Backlog
  • Aus dem Zustand In Development
  • Aus dem Zustand Analyse/Spezifikation
  • Aus dem Zustand Done
  • Ggf, aus mehr Zuständen zwischen Backlog und Done.
58
Q

Wie funktioniert ein Kanban-Board?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Zuerst einmal kommen alle User Stories in das Backlog hinein
  • Dabei werden die User Stories nach Priorität geordnet
  • Durch einen Pull-Vorgang können Zustandsübergänge geschehen
59
Q

Inwiefern ergänzt eine User Story Map das Kanban-Board?

“Analyse-Themen”

A
  • Im Kanban-Board sind die Zusammenhänge der User-Stories nicht klar
  • User Story Maps fügen eine zweite Dimension hinzu
60
Q

Wie ist eine User-Story Map aufgebaut?

“Analyse-Themen”

A
  • Oben ist sie in rote Kärtchen mit User Acitivities gegliedert
  • Darunter befinden sich jeweils die zugehörigen blauen Epics
  • Unter jedem Epic befinden sich die gesplitteten User Stories
  • Die User Stories sind nach Releases untereinander geordnet und können Stück für Stück in Iterationen abgearbeitet werden
61
Q

Vorteile von User Story Maps

“Analyse-Themen”

A
  • Man sieht das große Ganze des Backlogs aus Kanban
  • Es hilft beim Priorisieren und Verfeinern von User Stories
  • Es hilft beim iterativen Entwickeln und regt Diskussionen an
62
Q

Was ist eine Stakeholdermatrix?

“Analyse-Themen”

A

-Ein Werkzeug um im Auge zu halten inwieweit man bestimmte Nutzergruppen versorgen muss

63
Q

Was sind die verschiedenen Gruppen bei der Stakeholdermatrix und wie sind diese zu behandeln?

“Analyse-Themen”

A
  • Wenig Power, Wenig Interesse (Nur im Blick behalten)
  • Viel Power, Wenig Interesse (Bedürfnisse erfüllen, da sie kein Interesse an unserem Produkt haben)
  • Wenig Power, Viel Interesse (Die Verteidiger des Produktes informiert halten reicht)
  • Viel Power, Viel Interesse(Die Promoter sollten direkt und bevorzugt behandelt werden, weil sie das Produkt vorrantreiben können -> Zusammenarbeit)
64
Q

Was sind die INVEST-Kriterien?

“Analyse-Themen”

A
  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable
65
Q

Wofür steht das I in den Invest-Kriterien und was bedeutet es? (Mit Beispiel!)

“Analyse-Themen”

A

-Independent
(Man sollte Abhängigkeiten oder Interaktionen zwischen User Stories möglichst vermeiden)
-Bsp: User Story 1: Als Benutzer mit Mastercard zahlen
-Bsp: User Story 2: Als Benutzer mit Visa zahlen

-Verhinderbar durch das Kombinieren der Karten oder die Stories anders aufsplitten

66
Q

Wofür steht das N in den Invest-Kriterien und was bedeutet es?

“Analyse-Themen”

A

-Negotiable

User Stories sind verhandelbar und werden kommunikativ besprochen. Stories sind eine Erinnerung keine Spezifikation

67
Q

Wofür steht das V in den Invest-Kriterien und was bedeutet es?

“Analyse-Themen”

A

-Valuable
(User Stories sollen für alle Stakeholder einen Wert bieten nicht nur für Entwickler oder die Rolle wird genau angegeben)
-Negativbeispiel: Gespeichert wird in Plaintext
-Positivbeispiel: Vom Benutzer eingegebene Werte werden gespeichert

68
Q

Wofür steht das E in den Invest-Kriterien und was bedeutet es?

“Analyse-Themen”

A

-Estimable

User Stories sollten abschätzbar sein

69
Q

Wofür steht das S in den Invest-Kriterien und was bedeutet es?

“Analyse-Themen”

A

-Small
(Zu kleine User Stories kann man schlecht planen. Man kann zu kleine Stories in eine Mergen)
(-Epics sind zusammengesetzte Stories und Komplexe Stories)

70
Q

Wofür steht das T in den Invest-Kriterien und was bedeutet es? (Mit Beispiel!)

“Analyse-Themen”

A

-Testable
(Tests zeigen, dass eine User Story erfolgreich entwickelt ist. Bei Nichtfunktionalen Anforderungen vorsicht!)
-Möglichst viel sollte Testbar sein
-Negativbeispiel: Die Software soll einfach zu benutzen sein
-Positivbeispiel: Ein Benutzer kann eine Bestellung ohne Training selber vornehmen

71
Q

Was sind Akzeptanztests bei User Stories?

“Analyse-Themen”

A

-Erwartungen der Benutzer, welche auf der Rückseite notiert werden.

72
Q

Nenne Beispiele für Akzeptanztests in User Stories?

“Analyse-Themen”

A
  • Vorderseite: Als Benutzer kann ich einen Artikel inserieren
  • Rückseite: Leere Beschreibung?, Kein Preis?, Gigantischer Preis?, Artikelanzahl 0 möglich?
73
Q

Wann sollten Akzeptanztests in einer Iteration bei User Stories geschrieben werden?

“Analyse-Themen”

A

-Möglichst früh, damit wirklich jeder Grenzfall bedacht ist und keine Bugs entstehen.

74
Q

Was besagt Brian Maricks Testing Quadrant?

“Implementierungs-Themen”

A

-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 ?????

75
Q

Wie findet man generell Anforderungen im Projekt?

“Analyse-Themen”

A

-Durch Elicitation Techniques (Schleppnetz-Methode)

76
Q

Was beinhalten Elicitaion Techniques bei der Suche nach Anforderungen?

“Analyse-Themen”

A
  • Getreu der Schleppnetz-Methode sollte man erst ein grobes Netz zum Suchen benutzen und dann immer kleiner und detailierter nach Anforderungen suchen
  • Anforderungen können mit der Zeit wachsen und wichtiger werden oder plötzlich unwichtig sein
  • Man kann nicht alle Anforderungen perfekt fangen und hat auch mal Mist dabei, nur Profis wissen wo/wie man perfekt fängt.
77
Q

Was ist zu bemängeln an der Art wie man traditionell im Wasserfallverfahren die Anforderungen sammelt?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Es ist unmöglich alle Anforderungen am Anfang des Projektes zu finden
  • Anforderungen können ihre wichtiger werden oder komplett unwichtig, das wird nicht berücksichtigt
  • Viele Anforderungen tauchen erst später im Projektverlauf auf
78
Q

Wie versucht man die Anforderungen im agilen Vorgang zu sammeln?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Man versucht trotzdem am Anfang möglichst alle findbaren User Stories zu finden (oft grobe zuerst)
  • Und im weiteren Verlauf entstehen oft neue
79
Q

Was sind Techniken zum Sammeln von Anforderungen?

“Analyse-Themen”

A
  • Interviews(offene W Fragen!)
  • Fragebögen
  • Beobachtungen
  • Workshops/Story Writing Workshops
80
Q

Was ist die Funktion/das Ziel von offenen Fragen bei einem Interview?

“Analyse-Themen”

A
  • Viele Antworten ermöglichen

- Viel zu erfragen

81
Q

Was ist die Funktion/das Ziel von geschlossenen Fragen bei einem Interview?

“Analyse-Themen”

A
  • Schnell auf den Punkt kommen

- Vermutungen bestätigen lassen

82
Q

Welche Techniken/Phasen in einem Interview gibt es? Nennen Sie zugehörige Fragen.

“Analyse-Themen”

A
  • Sammeln(Was alles?, Und Außerdem?)
  • Fokussieren(Was genau?, Wer?, Womit?, Bis wann?)
  • Bestätigen(Habe ich richtig verstanden dass..?, Sie meinen also..?)
83
Q

Wer nimmt an einem Story-Writing Workshop teil?

“Analyse-Themen”

A

-Ein Workshop, an dem Entwickler, Benutzer, Kunden und andere Stakeholder teilnehmen

84
Q

Was sind die Ziele bei einem Story-Writing Workshop?

“Analyse-Themen”

A
  • Möglichst viele User Stories schreiben(Quantität im Fokus)

- Keine Priorisierung

85
Q

Wann sollte ein Story-Writing Workshop geschehen?

“Analyse-Themen”

A

-Mindestens einen Workshop vor dem Start jedem Realeases

86
Q

Was sind Techniken für ein Story Writing Workshop?

“Analyse-Themen”

A
  • Brainstorming

- Konzeptionelle Abläufe nachverfolgen

87
Q

Was ist beim Detaillieren von User Stories zu beachten?

“Analyse-Themen”

A
  • Eine fertige User Story ist klein, detailliert und kann implementiert werden
  • Sie sollten verständlich, testbar, realisierbar sein
  • Das ist zu erreichen durch das Splitten von Epics, Akzeptanzkriterien, Details ausarbeiten(Mockups)
88
Q

Nenne und erkläre die Pattern beim User Story Splitting.

“Analyse-Themen”

A
  • Workflow Steps (Posten als Editor, Posten als Admin)
  • Business Rule Variations (Keine schwammigen Angaben)
  • Major Effort (Nach dem größten Aufwand splitten)
  • Operations (CRUD)
  • Spike (Forschungs User Stories)
89
Q

Was ist eine Spezifikation?

“Analyse-Themen”

A
  • Eine Spezifikation ist eine formalisierte Beschreibung eines Produktes/Systems/Dienstleistung
  • Sie soll für den Entwickler die Freiheiten minimieren und diese dokumentieren
90
Q

Was beinhaltet der Spezifikationsbaukasten?

“Analyse-Themen”

A
  • Wireframes/Gui-Mockups
  • Fachliches Datenmodell/Fachliche Datentypen
  • Geschäftsprozesse
  • Use Cases/Anwendungsfälle
  • Druckausgaben/E-Mails
  • Batch-Jobs
  • Schnittstellen zu Nachbarsystemen
91
Q

Was ist ein Wireframe/Mockup?

“Analyse-Themen”

A
  • Ein konzeptioneller Entwurf und oft Wegwerfprototyp der Benutzerschnittstellen
  • Sollten nie fertig aussehen, um gar nicht in Versuchung zu kommen sie zu übernehmen
  • Außerdem erschafft es einem Entwickler auch mehr Zeit, als wenn der Kunde denkt es wäre fast fertig
92
Q

Was ist ein Anwendungsfall/Use Case?

“Analyse-Themen”

A

-Anwendungsfälle/Use Cases sind Arbeitsschritte aus Geschäftsprozessen, die systemseitig unterstützt werden sollen

93
Q

Was beschreiben Anwendungsfälle/Use Cases?

“Analyse-Themen”

A
  • Anwendungsfälle/Use Cases beschreiben das sichtbare Verhalten und die Interaktion eines Systems auf Nutzerrollenanfragen
  • Jeder Anwenungsfall hat einen direkten Nutzen
94
Q

Woraus enstehen Anwendungsfälle/Use Cases?

“Analyse-Themen”

A

-Aus Geschäftsprozessen und Anforderungen/User Stories

95
Q

Wie sehen Anwendungsfälle/Use Cases aus?

“Analyse-Themen”

A
  • Textbeschreibung
  • Durchnummerierung
  • Evtl. UML Usa Case Diagramm
96
Q

Beschreibe die Basisstruktur von Anwendungsfällen/Use Cases?

“Analyse-Themen”

A
  • Titel:
  • Akteur:
  • Ziel:
  • Auslöser:
  • Vorbedingung:
  • Nachbedingung:
  • Erfolgsfall: (Ohne Technik)(Ablauf des Users durch das System)
97
Q

Womit lassen sich Anwendungsfälle/Use Cases gut ergänzen?

“Analyse-Themen”

A

-Mit Mockups/Wireframes, da diese genau den Erfolgsprozess visualisieren können

98
Q

Wie können Anwendungsfälle/Use Cases auch visualisiert werden?

“Analyse-Themen”

A

-Durch Anwendungsfalldiagramme

99
Q

Was macht ein Anwendungsfalldiagramm?

“Analyse-Themen”

A

-Es stellt den Anwendungsfall/Use Case mit den Akteuren! grafisch dar.

100
Q

Wofür macht ein Anwendungsfalldiagramm sinn?

“Analyse-Themen”

A
  • Am Beginn der Spezifikation

- Zur Kommunikation mit Kunden

101
Q

Wie wird ein System in dem Anwendungsfalldiagramm notiert?

“Analyse-Themen”

A

-Durch systemgrenzen Kästen, welche alles umschließen was zum System gehört(Anwendungsfälle/Use Cases)

102
Q

Wie wird ein Akteur in dem Anwendungsfalldiagramm notiert?

“Analyse-Themen”

A
  • Außerhalb des Systems, meist links oder rechts(Wie andere Systeme)
  • Keine Beziehung zum System
103
Q

Wie wird ein Anwendungsfall in dem Anwendungsfalldiagramm notiert?

“Analyse-Themen”

A
  • Alle innerhalb des Systems
  • Namen: Objekt + Verb im infinitiv
  • Bsp: “Verkauf durchführen”
104
Q

Wie wird eine Assoziation in dem Anwendungsfalldiagramm notiert?

“Analyse-Themen”

A
  • Zwischen Akeuren und Anwendungsfällen/Use Cases ein Pfeil (wenn gerichtet)
  • Bsp: “Gerichtete Assoziation: Benutzereingabe für Anwendungsfall”
105
Q

Wie wird ein “<> in dem Anwendungsfalldiagramm notiert?

“Analyse-Themen”

A
  • Ein Pfeil zwischen Anwendungsfällen/Use Cases
  • Anwendungsfall A beinhaltet immer Anwendungsfall B
  • B Wird während der Bearbeitung von A ausgeführt
106
Q

Wie wird ein “<> in dem Anwendungsfalldiagramm notiert?

“Analyse-Themen”

A
  • Ein Pfeil zwischen Anwendungsfällen/Use Cases
  • Anwendungsfal B ist optionaler Bestandteil von Anwendungsfall A
  • Extension Point immer notwendig(????)
107
Q

Was sind typische Fehler im Anwendungsfalldiagramm?

“Analyse-Themen”

A
  • Zu feingranulare Anwendungsfälle/Use Cases
  • Keine begleitenden Texte
  • Zu viele Use-Cases/Beziehungen
  • <> ohne Erweiterungspunkt
  • Assoziation zwischen Use-Cases
  • Assoziation zwischen Akteuren
  • Use Case außerhalb eines Systems
108
Q

Wann ist ein Use Case die bessere Wahl und wann eine User Storie?

“Analyse-Themen”

A
  • Alle Anwendungsfälle/Use Cases zu spezifizieren kostet zu viel Aufwand
  • Daher kritische Hauptfunktionen sollten Anwendungsfälle/Use Cases sein
  • Nebenfunktionen können User Stories bleiben
109
Q

Warum modelliert man überhaupt?

“Analyse-Themen”

A

-Nicht um Daten anzupassen, sondern um die Fragen danach zu verbessern

110
Q

Was beschreibt ein fachliche Datenmodell? (UML)

“Analyse-Themen”

A
  • Fachliche Sicht auf Daten

- Keine Softwareelemente

111
Q

Was ist der Nutzen eines fachlichen Datenmodells?

“Analyse-Themen”

A
  • Es ist eine Art visuelles Wörterbuch

- Es ist ein Entwurfsmodell

112
Q

Womit kann ein fachliches Datenmodell erstellt werden?

“Analyse-Themen”

A

-UML(Unified Modeling Language)

113
Q

Auf welche Arten können UML Klassendiagramme genutzt werden?

“Analyse-Themen”

A

-Sichtweise Fachlich
(Modellierung von Konzeption in der Spezifikation)
-Sichtweise Entwurf
(Schnittstellen zwischen Softwarekomponenten egal welche Sprache)
-Sichtweise Implementierung
(Softwareklassen mit Code)

114
Q

Woraus bestehen UML-Klassendiagramme?

“Analyse-Themen”

A
  • Assoziationen (Pfeil ge/ungerichtet)
  • Kardinalitäten(1 *, 1 1 etc)
  • Klassen(Kasten mit Name)
  • Attributen(Im Klassenkasten)
  • Datentyp (hinter dem Attribut)
  • Aggregation (???)
115
Q

Sind in UML-Diagrammen/Fachlichen Datenmodellen die Sichtbarkeiten von Entitäten relevant?

“Analyse-Themen”

A

-Nein, nur die Beziehungen zwischen Entitäten

116
Q

Was ist eine Aggregation in UML/Fachlichen Datenmodelle?

“Analyse-Themen”

A
  • Teil-Ganze Beziehung (“besteht aus” oder enthält)
  • Teil kann auch alleine existieren oder zu mehreren Ganzen gehören
  • Notation durch weiße Raute auf “Geber” seite
117
Q

Was ist eine Komposition in UML/Fachlichen Datenmodelle?

“Analyse-Themen”

A
  • Ein Teil darf hierbei nur zu einem Ganzen gehören

- Notation durch schwarze Raute auf “Geber”seite

118
Q

Was ist eine Assoziationsklasse in UML/Fachlichen Datenmodelle?

“Analyse-Themen”

A
  • Eine Zwischenklasse zwischen zwei Entitäten
  • Stellt weitere Informationen über die Beziehung dar
  • Kompliziert das UML-Diagramm jedoch durch zusätzliche Assoziation wenn falsch gemacht
119
Q

Wie sollten Assoziationsklasse in UML/Fachlichen Datenmodellen notiert werden?

“Analyse-Themen”

A
  • Kann an jeweils nur eine Assoziation als beschreibendes Element mit gestrichelter Linie herangehängt werden
  • Keine neue Assoziation entstehen lassen
120
Q

Was erweitert das Fachliche Datenmodell(UML) und erklärt dessen Begriffe? (Entitäten, Konzepte)

“Analyse-Themen”

A

-Das Glossar

121
Q

Was ist ein fachlicher Datentyp?

“Analyse-Themen”

A
  • Ein fachlicher Datentyp beschreibt Wertebereiche

- Bsp: EmailType, IbanType

122
Q

Was ist ein technischer Datentyp?

“Analyse-Themen”

A
  • int
  • bool
  • float[10]
123
Q

Wie werden fachlichen Datentypen im fachlichen Datenmodell dargestellt?

“Analyse-Themen”

A
  • Bsp: Nummerisch(10)

- Bsp: Ja/Nein

124
Q

Wo sollten spezielle Datentypen beschrieben werden?

“Analyse-Themen”

A

-Im Datentypenverzeichnis

125
Q

Was wird im Datentypenverzeichnis dargestellt?

“Analyse-Themen”

A
  • Datentyp
  • Beschreibung
  • Wertebereich
  • GUI-Darstellung
126
Q

Oftmals sind Entitäten mit Fachlichen Datentypen zu verwechseln. Erklären Sie was eine Entität ausmacht.

“Analyse-Themen”

A
  • Haben Identität
  • Haben einen Lebenszyklus (CRUD)
  • Werden durch Attribute beschrieben
127
Q

Oftmals sind Entitäten mit Fachlichen Datentypen zu verwechseln. Erklären Sie was einen fachlichen Datentyp ausmacht.

“Analyse-Themen”

A
  • Modellieren nur Werte(Name, Datum, Anzahl)

- Sind verzichtbar, aber für Verständlichkeit

128
Q

Wofür wird Gradle genutzt?

“Entwurfs-Themen”

A

-Für Projekt-Automation

129
Q

Was ist in einem Projekt schwerfällig/zu tun ohne Projekt-Automation?

“Entwurfs-Themen”

A
  • Manuell Builden und Delivern, was langsam ist und mehr Fehler bringt
  • Manuelles Coding, Refactoring und Testen
  • Oft geht es nur an einem Rechner
  • Manuelle Kopieren zum Testen
  • Deploymentprobleme
130
Q

Was sind die Vorteile mit Projekt-Automation?

“Entwurfs-Themen”

A
  • Jeder automatisierbare Schritt sollte automatisiert werden
  • Wiederholbarkeit (Compile, Test, Assemble, Deploy)
  • Portierbarkeit (Keine Abhängigkeit an IDE oder Rechner)
131
Q

Was machen Build-Tools (wie Gradle)?

“Entwurfs-Themen”

A

-Automatisieren einzelner Schritte durch Tasks

132
Q

Was enthält ein BuildFile/BuildScript?

“Entwurfs-Themen”

A
  • Build-Konfiguration
  • Abhängigkeiten zu externen Libraries
  • Befehle, um ein bestimmtes Ziel zu erreichen mit Tasks etc
133
Q

Wie funktionieren Builds?

“Entwurfs-Themen”

A

-Sie erhalten ein Build-Input und geben ein entsprechendes Biild-Output

134
Q

Was sind gängige Build-Tools?

“Entwurfs-Themen”

A
  • Apachte Ant
  • Apache Maven
  • Gradle
  • MSBuild
  • Gulp
135
Q

Warum ist Gradle als Build-Tool anderen zu bevorzugen?

“Entwurfs-Themen”

A

-Weil es die besten Features anderer Build Tools vereint

Convention over Configuration, Plugins etc

136
Q

Was sind die Aspekte eines Entwurfes?

“Entwurfs-Themen”

A
  • Input (Alles aus AnalyseThemen/Spezifikation)
  • Architektur
  • Prinzipien
  • Muster
  • Erfahrung/Kreativität
  • Werkzeuge
137
Q

Was ist eine Softwarearchitektur?

“Entwurfs-Themen”

A
  • Eine Softwarearchitektur ist die Struktur eines Software-Produktes.
  • Externe Elemente
  • Beziehungen zwischen Elementen
138
Q

Was ist ein Architekturstil?

“Entwurfs-Themen”

A

-Ein Architekturstil bezeichnet abstrakt gleiche Regeln, Muster oder Einschränkungen verschiedener Architekturen

139
Q

Was ist der gängige Architekturstil für Informationssysteme?

“Entwurfs-Themen”

A

-Die drei Schichten-Architektur(Gui->Geschäftslogik->Persistenzschicht(->DB))

140
Q

Was ist eine Referenzarchitektur?

“Entwurfs-Themen”

A
  • Eine Schablone für Softwarearchitekturen

- Hat oft ein eigenes Vokabular zum Beschreiben

141
Q

Wie sieht die Referenzarchitektur für SE1 aus?

“Entwurfs-Themen”

A

-Dialoge -Nachbarsysteme
schnittstelle schnittstelle
————Fassade—————— –|
schnittstelle schnittstelle |
——–Anwendungskern——— |
schnittstelle schnittstelle |
Nachbarsystem DB

142
Q

Wo liegen die Komponenten innerhalb der Referenzarchitektur aus SE1?

“Entwurfs-Themen”

A

-Im Anwendungskern

143
Q

Was steckt genau im Systemkern nach der Referenzarchitektur von SE1 und was interagiert mit was?

“Entwurfs-Themen”

A
  • Aufrufe von der GUI treffen auf den UseCase bzw. die UseCase Implementation
  • Der UseCase/Impl steht in Beziehung zum Datentyp, der Repository und den Entitäten
  • Das Repository greift auf die DB zu und auch auf die Entitäten
144
Q

Was für ein Typ von Datenbank wurde in unserem SE1 Projekt genutzt?

“Entwurfs-Themen”

A

-Durch Spring Data JPA mit Hibernate wurde eine relationale Datenbank im Memory emuliert

145
Q

Was ist das OO-Problem: Impedance Mismatch?

“Entwurfs-Themen”

A
  • Das tritt auf, wenn die Daten der Datenbank nicht mehr mit denen der Objektorientierung übereinstimmen
  • Hibernate sollte die Verbindung herstellen
146
Q

Beschreiben Sie das RepositoryPattern/DAO-Pattern.

“Entwurfs-Themen”

A

-Repositories stellen CRUD Operationen bereit

147
Q

Welche Annotationen werden im Repository-Pattern genutzt?

“Entwurfs-Themen”

A
  • @Entity (Entität)
  • @ID @GeneratedValue (PK ID)
  • @OneToMany (Kardinalität)
  • @Repository (Repository)
  • @Query (SQL Befehl)
148
Q

Was wird innerhalb der UseCaseKlassenImplementierung implementiert?

“Entwurfs-Themen”

A

-Geschäftsoperationen
(Entitätsübergreifende Funktionalitäten)
(Bsp: buche(vonKonto, nachKonto, betrag))
-

149
Q

Was nutzen UseCaseKlassen um an ihre Entitätsinstanzen zu gelangen und diese zu berarbeiten?

“Entwurfs-Themen”

A

-Repositories

150
Q

Was sind die Ausgangspunkte für die Funktionalitäten unseres Systems?

“Entwurfs-Themen”

A

-Die Anwendungsfälle/Use Cases

151
Q

Zu was werden die systemunterstützenden Teile der Anwendungsfälle/Use Cases unseres Systems?

“Entwurfs-Themen”

A

-Systemoperationen

152
Q

Wie bildet man Systemoperationen?

“Entwurfs-Themen”

A

-Aus manchen Punkten von UseCases/Anwendungsfällen/Use Cases im Erfolgsfall lassen sich Systemoperationen ableiten.

153
Q

Wodurch werden systemübergreifende Abläufe abgebildet?

“Analyse-Themen”

A

-Durch Geschäftsprozesse

154
Q

Was ist ein Geschäftsprozess?

A

-Ein Geschäftsprozess ist eine inhaltlich abgeschlossene, zeitliche und sachlogische Folge von Aktivitäten die ein gewisses Ergebnise(Produkt/Dienstleistung) erzeugt.

155
Q

Wie sieht die Kundensicht bei Geschäftsprozessen aus?

“Analyse-Themen”

A

-Geschäftsprozesse haben externe und interne Kunden die Input liefern oder Ergebnisse erwarten

156
Q

Was beschreibt ein Geschäftsmodell? (GPM)

“Analyse-Themen”

A
  • Systemübergreifende Abläufe des Geschäftes
  • Arbeitsschritte die von Mensch und Maschine ausgeführt werden
  • Anstoß über Ereignisse
157
Q

Wie kann eine Geschäftsprozessmodellierung(GPM) dargestellt werden?

“Analyse-Themen”

A
  • Text(immer!)
  • UML
  • BPMN(Business Process Model and Notation)
  • EPK(Ereignisgesteuerte Prozessketten)
158
Q

Was sind die Ziele bei der Nutzung von Geschäftsprozessmodellierung(GPM)?

“Analyse-Themen”

A
  • Dokumentation, Effizienz, Controlling

- Speziell für Geschäftsprozesse entwickelt und Ausdrucksstärker

159
Q

Was für Ereignisse gibt es bei der Geschäftsprozessmodellierung(GPM)?

“Analyse-Themen”

A
  • Externe Ereignisse(Ein Benutzer tut/merkt etwas)
  • Zeitereignisse
  • Interne Ereignisse
160
Q

Welche verschiedenen Ansichten gibt es bei der Geschäftsprozessmodellierung? (GPM)

“Analyse-Themen”

A
  • Prozesssicht: (Welches sind die Abläufe/Vorgänge/Inputs/Outputs)
  • Datensicht: (Welche Daten sind wichtig? (Assoziationen zwischen Entitäten)
  • Organisationssicht: (Organigramm)
161
Q

Wie lauten die Notationsmöglichkeiten von Geschäftsprozessen?

“Analyse-Themen”

A
  • UML 2.x Aktivitätsdiagramme
  • BPMN 2.0
  • (eEPK Ereignisgesteuerte Prozesskette)
162
Q

Was ist das BPMN 2.0?

“Analyse-Themen”

A

-Das Business Process Model and Notation v2.0

163
Q

Wofür wird das BPMN 2.0 genutzt?

“Analyse-Themen”

A
  • Diagramm für Geschäftsprozesse
  • Es beschreibt Organisationsstrukturen, Funktionen, Datenflüsse und Ressourcen
  • Metamodell und XML Tauschformat
164
Q

Was beinhalten Prozessdiagramme (BPMN 2.0)?

“Analyse-Themen”

A

-Modellieren Abläufe von Aktivitäten, Ereignissen, Gateways, Datenobjekten und Artefakte

165
Q

Was ist das Ziel von BPMN 2.0?

“Analyse-Themen”

A

-Prozesse so präzise beschreiben, dass eine Workflow-Engine sie ausführen kann

166
Q

Wann spricht man bei einem Prozessdiagramm von einem ausführbarem Prozess?

“Analyse-Themen”

A

-Wenn alle Details des Modells vorhanden sind

167
Q

Welche Notationen beinhalten Prozessdiagramme (BPMN 2.0)?

“Analyse-Themen”

A
  • Ereignisse(Kreis)
  • Aktivitäten(Kasten)
  • Gateways(Raute)
168
Q

Was sind die Vorteile von eEpk(Ereignisgesteuerte Prozessketten)?

“Analyse-Themen”

A
  • Modellierung ist intuitiv

- Es gibt Werkzeuge dafür

169
Q

Was sind die Nachteile von eEpk(Ereignisgesteuerte Prozessketten)?

“Analyse-Themen”

A
  • Keine Standard Semantik weltweit

- Diagramme oft komplex, da zwischen Ereignis und Funktion gewechselt wird

170
Q

Wie ist der Geschäftsprozess/Ablauf eines klassischen Softwareprojektes?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Projektleiter und Kunde sprechen über die Zusammenarbeit
  • Kunde sendet ein Lastenheft zum Projektleiter
  • Das Projektteam erstellt eine Kosten und Aufwandsschätzung
  • Der Projektleiter sendet ein Angebot mit Konditionen zum Kunden
  • Es wird verhandelt
  • Auftrag wird angenommen und Vertragspflicht entsteht
171
Q

Was ist Aufgabe der Analyse in der klassischen Softwareentwicklung?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Detaillierung, Erhebung von Anforderungen

172
Q

Was ist Aufgabe der Spezifikation in der klassischen Softwareentwicklung?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Beschreibung der Außensicht des System (Für den Kunden spürbar)

173
Q

Wie wird die Spezifikation in der klassischen Softwareentwicklung auch genannt?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A

-Pflichtenheft

174
Q

Was ist der Nutzen der Spezifikation in der klassischen Softwareentwicklung?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Funktionsweisen der Software mit dem Kunden abstimmen
  • Abstimmen mit den Entwicklern
  • Nutzung zur Aufwands/kostenschätzung
  • Abnahme
  • Dokumentation
175
Q

Was passiert wenn die Spezifikation in der klassischen Softwareentwicklung fehlt?

“Klassische“ und „weitere“ Softwareentwicklungsthemen”

A
  • Anforderungen ungeklärt
  • Entwickler müssen interpretieren -> Fehlkommunikation
  • Keine systematischen Tests
  • Korrektheit des System unüberprüfbar
176
Q

Was ist die Bedeutung eines Entwurfes?

“Entwurfs-Themen”

A
  • Ein komplexes System sollte in überschaubar gegliedert sein
  • Die Struktur ist sehr wichtig für die Wartbarkeit
  • Menschen können nur begrenzt viele Dinge erfassen
  • Daher Komponentenbildung hilfreich
177
Q

-Was sind Komponenten?

“Entwurfs-Themen”

A

-Gegliederte Teile eines größeren Ganzen, welche zusammen einen Zweck erfüllen

178
Q

Was sind Merkmale einer Komponente?

“Entwurfs-Themen”

A
  • Voneinander einzeln unabhängig
  • Beliebig Koppelbar
  • Gewähren Schnittstellen
  • Jede Komponente ist durch einfache Schnittstellen leicht austauschbar
  • Kapsel Funktionalitäten nach dem Geheimnisprinzip ein
  • Jemand von außen muss nur wissen wie er etwas anspricht und nicht wie es im inneren funktioniert
  • Neben Schnittstelle die wesentliche Einheit
179
Q

Wie teilt man in Komponenten auf?

“Entwurfs-Themen”

A
  • Durch Erfahrung
  • Nicht jede Klasse als Komponente designen (zu granular)
  • Nicht nur eine der 3-Schichten als Komponente (zu grob)
180
Q

Was ist die erste Frage eines Entwurfes?

“Entwurfs-Themen”

A

-Aus welchen Komponenten besteht es?

181
Q

Ohne was kann ein großes Softwaresysten nicht gut werden?

“Entwurfs-Themen”

A

-Ohne gute Komponentenstruktur

182
Q

Was ist die Außenansicht einer Komponente?

“Entwurfs-Themen”

A

-Die Schnittstellen

183
Q

Was ist die Innenansicht einer Komponente?

“Entwurfs-Themen”

A
  • Interner Aufbau
  • Anwendungsfälle/Use Cases
  • Entitäten
  • Funktionalitäten
184
Q

Was besagt der Entwurfsprinzip “Separation of Concerns”(SoC) ?

“Entwurfs-Themen”

A
  • Trennung von Zuständigkeiten

- Jede Komponente erfüllt nur einen bestimmten Zweck

185
Q

Was sind die Vorteile bei der Nutzung vom Entwurfsprinzip “Separation of Concerns” (SoC)?

“Entwurfs-Themen”

A
  • Mehr Verständniss
  • Bessere Wiederverwendung
  • Wartbarkeit
  • Austauschbarkeit
186
Q

Was sind Beispiel für die Nutzung vom Entwurfsprinzip “Separation of Concerns” (SoC)?

“Entwurfs-Themen”

A
  • Trennung von Funktion und Interaktion

- Trennung von Fachlichkeit und Technologie

187
Q

Wnn wird das Entwurfsprinzip “Separation of Concerns” (SoC) verletzt?

“Entwurfs-Themen”

A

-Wenn eine Funktion und eine Interaktion der GUI kohäsiv zusammenliegt

188
Q

Wo haben wir das Entwurfsprinzip “Separation of Concerns” (SoC) angewendet in SE1?

“Entwurfs-Themen”

A
  • 3-Schichten Architektur (GUI Angular 2) -> (Spring Logik) -> (Persistenz Datenbank)
  • DAO/Repository Pattern
  • Fassade
  • Entitäten
189
Q

Was besagt das Entwurfsprinzip der hohen Kohäsion?

“Entwurfs-Themen”

A
  • Kohäsion = Zusammenhalt
  • Sollte sehr hoch sein
  • Jede Komponente erfüllt einen Job und den ganz
190
Q

Was sind Bestandteile der UML 2.0 Komponentendiagramm Notation?

“Entwurfs-Themen”

A
  • Kästen für Komponenten(kleines Zeichen oben rechts)
  • Angebotene Schnittstellen als Ball an der Assoziation
  • Verwendete Schnittstellen als Halbkreis an der Assoziation
  • Abhängigkeiten durch gerichtete Pfeile zwischen Ball und Halbkreis
  • Namen sollten klar als Komponente erkennbar sein
191
Q

Was verbindet Komponenten miteinander?

“Entwurfs-Themen”

A
  • Konfigurationen

- Frameworks(Spring)

192
Q

Wie wird durch die Konfiguration eine Anwendung zu Starten gebracht?

“Entwurfs-Themen”

A

-Erst wird sie konstruiert und arbeitet dann(main/BuildComponents()->Run())

193
Q

Was ist eine Dependency Injection?

“Entwurfs-Themen”

A
  • Ein Entwurfsmuster für Konfigurationen

- Die Abhängigkeit wird von Außen in die Komponente gebracht

194
Q

Welche Arten von Dependency Injection gibt es?

“Entwurfs-Themen”

A
-Konfiguration für den Konstruktor 
( new KompA(Komp b, Komp c, Komp d)
-Konfiguration über Setter
(a = new KomA 
a.bindIB(b);
-Dependency Injection mit Spring (Spring Container erzeugt Objekte und verknüpft diese durch Wireing, konfiguriert und verwaltet sie bis zu Löschung)
195
Q

Was wird in Spring ein “Bean” genannt?

“Entwurfs-Themen”

A

-Die Objekte die mit Dependency Injection zu konfigurieren sind

196
Q

Wie funktioniert bei Spring Boot die Dependency Injection?

“Entwurfs-Themen”

A

-Automatisch durch entsprechende Annotation @Autowired

197
Q

Was ist der Service Locator?

“Entwurfs-Themen”

A

-Ein Entwurfsmuster zur Reduzierung der Kopplung

198
Q

Was ist das Prinzip hinter dem Service Locator Pattern?

“Entwurfs-Themen”

A
  • Eine Art Telefonbuch/Verzeichnis für alle benutzbaren Objekte
  • Komponenten suchen sich Verbindungen durch den Service Locator
199
Q

Was ist der Vorteil des Service Locator Patterns?

“Entwurfs-Themen”

A

-Geringere Kopplung zwischen Objekten

200
Q

Was ist der Nachteil des Service Locator Patterns?

“Entwurfs-Themen”

A
  • Es entsteht eine Abhängigkeit von Service Locator

- Er selbst ist schwer konfigurierbar

201
Q

Wo wird in unserer Refernzarchitektur die Restschnittstelle angeboten?

“Entwurfs-Themen”

A

-Überhalb der Fassade, als Schnittstelle zwischen GUI und Fassade.

202
Q

Wie funktioniert die Schnittstellenverbindung zwischen GUI bis zum Use-Case/Implementation?

“Entwurfs-Themen”

A
  • GUI greift auf die REST API des Controllers zu.
  • Der Controller besitzt das Facade Pattern
  • Der Controller ruft die Schnittstelle der UseCase/Komponentenklassen auf.
203
Q

Wofür steht eine REST API?

“Entwurfs-Themen”

A

-REpresentational State Transfer

204
Q

Was ist REST?

“Entwurfs-Themen”

A

-Ein Architekturstil

205
Q

Was benutzt REST?

A
  • Das HTTP-Protokoll samt
  • GET(Daten vom Server erhalten)
  • POST(Daten auf dem Server ablegen)
  • (PUT/DELETE)
206
Q

Was sind die Vorteile von REST?

A
  • Einfachheit
  • Verständlichkeit
  • Debugging einfach
207
Q

Wie kann REST dargestellt werden?

“Entwurfs-Themen”

A
  • Über mehrere Wege
  • Über JSON
  • Über XML
208
Q

Was sind die Vorteile bei der JSON Nutzung?

“Entwurfs-Themen”

A
  • JSON hat wenige Datentypen
  • JSON ist sehr lesbar und schlank
  • JSON lässt leicht Java Script Objekte erstellen(Text)
  • JSON ist plattformübergreifend/universell
209
Q

Was sind die Vorteile bei der XML Nutzung?

“Entwurfs-Themen”

A
  • XML arbeitet mit Tags

- XML hat mehr Möglichkeiten als JSON

210
Q

Was sind die Nachteile bei der JSON Nutzung?

“Entwurfs-Themen”

A

-Eventuell nicht komplex genug für gewisse Anforderungen

211
Q

Was sind die Nachteile bei der XML Nutzung?

“Entwurfs-Themen”

A
  • Lange und redundante Syntax

- Code wird aufgeblasen und verkompliziert zum lesen

212
Q

Was für HTTP-Response Codes gibt es?

“Entwurfs-Themen”

A
  • 50x: Server Fehler
  • 40x Client Fehler
  • 30x Umleitung
  • 20x Hat geklappt
213
Q

Was sind bekannte HTTP-Response Codes?

A
  • 404 Not Found
  • 403 Forbidden
  • 201 Created
214
Q

Wie kann man die REST-API manuell Triggern?

“Entwurfs-Themen”

A

-Durch Programme wie POSTMAN oder curl

215
Q

Was tut ein Designmuster?

“Entwurfs-Themen”

A
  • Beschreibt ein Problem, welches häufiger auftritt

- Beschreibt abstrakt eine Lösung für das Problem

216
Q

Welche Arten von Designmustern gibt es?

“Entwurfs-Themen”

A
  • Analysemuster (Zum Analysieren von Problemen)
  • Architekturmuster (Z.B. 3-Schichten-Architektur)
  • ENTWURFSMUSTER (Helfen bei Realisierung von Komponenten/Klassenbstrukturen)
  • Programmiertechniken (Hinweise für Lösungen in bestimmten Programmiersprachen)
  • Organisationsmuster (Daily-Scrum-Meeting)
  • Anti-Patterns (Typische Fehler wie Redundanzen oder alles Hohe Kopplung)
217
Q

Wsa sind die Vorteile bei der Nutzung von Entwurfsmuster?

“Entwurfs-Themen”

A
  • Man besitzt ein gemeinsames Vokabular
  • Bessere Kommunikation im Team
  • Bringen Konzepte in konkrete Form
  • Dokumentieren Entwürfe
  • Keine Neuerfindung des Rades
  • Guter Code entsteht
218
Q

Wie ist ein Entwurfsmuster aufgebaut?

“Entwurfs-Themen”

A
  • Name, Problembeschreibung, Lösung, Konsequenzen
  • Klassifikation, Synonyme, Anwendbarkeit
  • Implementierung, Beispielcode, Referenzen, benachbarte Designmuster
219
Q

Wann kann das Abstract Factory Pattern genutzt werden?

“Entwurfs-Themen”

A
  • Ein System muss mit unterschiedlichen Sets von Objekten konfiguriert werden
  • Die Objekte hängen zusammen
  • Das System ist von der Erstellung der Objekte losgelöst
220
Q

Was sind die Vorteile des Abstract Factory Pattern?

“Entwurfs-Themen”

A
  • Allmeingültiger schlanker ClientCode
  • Einfache Erweiterung der Produktfamilien
  • Wiederverwendung von konkreten Produkten
221
Q

Was sind die Nachteile des Abstract Factory Pattern?

“Entwurfs-Themen”

A
  • Keine Flexibilität neuer Produkte, weil Factories erweitert werden müssten
  • Änderung der Schnittstelle
222
Q

Wie werden Entwurfsmuster klassifiziert?

“Entwurfs-Themen”

A
  • Erzeugungsmuster(Abstraktion der Instanziierung, machen System unabhängig von Objekterstellung)
  • Strukturelle Muster(Zusammensetzung von Objekten zu größeren Strukturen für neue Funktionen)
  • Verhaltensmuster(Zusammenarbeit und Verantwortlichkeit zwischen Objekte)
223
Q

Was ist das Adapter Pattern und wann wird es genutzt?

“Entwurfs-Themen”

A
  • Erlaubt zwei inkompatible Interfaces zusammen zu arbeiten
  • Kann z.B. genutzt werden wenn ein bestimmtes Ziel Interfaces genutzt werden soll
  • Jede Klasse kann zusammenarbeiten, solange der Adapter dafür sorgt, dass alle Klassen alle Methoden des geteilten Interfaces implementieren
224
Q

Erklären Sie den Aufbau des Adapter Pattern an einem Beispiel!

“Entwurfs-Themen”

A
  • Bsp: Client möchte einen Angreifer haben
  • Wir haben nur eine Roboterklasse
  • Mit einem entsprechenden Adapterinterface implementieren wir das Angreiferinterface so, dass dementsprechend mit jeder Methode eine Funktion des Roboters aufgerufen wird
  • > Der Roboter kann nun als Angreifer genutzt werden
225
Q

Wann wird das Observer Pattern genutzt?

“Entwurfs-Themen”

A
  • Wenn man viele andere Objekte updaten muss, sobald ein Objekt sich verändert
  • Z.B. bei einer Auktion, wo viele Bietende über eine Preisveränderung informiert werden müssen
226
Q

Was sind die Vorteile/Nachteile des Observer Pattern?

“Entwurfs-Themen”

A
  • Eine losere Kopplung ensteht
  • Das sich ändernde Objekt muss nicht über die Beobachter wissen

-Es könnte zu Updates kommen, die die Beobachter nicht interessiert(Spam)

227
Q

Erklären Sie den Aufbau des Observer Pattern an einem Beispiel!

“Entwurfs-Themen”

A
  • Das Verändernde Objekt hat eine Funktion zum Registrieren, Löschen und Benachrichtigen bei Updates
  • Es gibt ein Observer Interface, welches eine update Funktion besitzt
  • Und dann gibt es Observer, welche das ObserverInterface implementieren
228
Q

Was ist das Facade Pattern und wann wird es genutzt?

“Entwurfs-Themen”

A

-Wenn man ein vereinfachtes Interface entwickelt, was viele Funktionen bereitstellen soll die im internen geschehen und auf verschiedene Klassen/Schnittstellen zugreifen

229
Q

Was sind die Vor/Nachteile des Facade Pattern?

“Entwurfs-Themen”

A
  • Vereinfachte Schnittstelle in einem komplexen System
  • Lose Kopplung

-Kann Unübersichtlichkeit schaffen, da eine weitere Aufrufsverzweigung geschieht

230
Q

Was ist das State Pattern und wann wird es genutzt?

“Entwurfs-Themen”

A
231
Q

Erklären Sie den Aufbau des Observer Pattern an einem Beispiel!

“Entwurfs-Themen”

A
  • Es gibt ein Interfaces, welches Alle Funktionen als Methoden definiert
  • Dann gibt es verschiedene StateKlassen, welche die Funktionen unterschiedlich implementieren
  • Durch eine Klasse im Objekt kann ein Zustandswechsel geschehen und das Verhalten(Methode) der jeweiligen Stateklassen wird ausgeführt
232
Q

Was ist das Strategy Pattern und wann wird es genutzt?

“Entwurfs-Themen”

A
  • Wenn man eine Klasse definieren möchte, die ein Verhalten haben soll, dass anderen Verhalten ähnelt
  • Sie kann sich quasi ihre Strategie auswählen
  • Wird verwendet, wenn man ein Verhalten dynamisch nutzen möchte
233
Q

Was sind die Vor/Nachteile des Strategy Pattern?

“Entwurfs-Themen”

A
  • Redundanter Code wird verhindert
  • Lässt keine lange Liste an Zuständen entstehen
  • Negativ: Oftmals entstehen nun mehr Objekte/Klassen
234
Q

Erklären Sie den Aufbau des Strategy Pattern an einem Beispiel!

“Entwurfs-Themen”

A
  • Es gibt eine Oberklasse Z.b: Tier
  • Klassen wie Hunde/Vögeln extenden die Klasse
  • Die Oberklasse Tier hat eine Instanzvariable eines Interfaces z.b. Fliegen
  • Das Interfaces Fliegen hat verschiedene StrategieKlassen die das Fliegen unterschiedlich implementieren
  • Hunde und Katzen können nun dynamisch die Strategie austauschen
235
Q

Sollten Nicht-Funktionale Anforderungen wage oder exakt sein?

“Analyse-Themen”

A

-Exakt, z.B. Die Rückmeldung soll innerhalb 2 Sekunden geschehen.

236
Q

Wie sollte man anfangen eine User-Story Map anzulegen?

“Analyse-Themen”

A
  • Zuerst die Epics strukturieren
  • Danach nach oben zu den User Actitivies
  • Danach die User Stories entwickeln (“Als Benutzer soll ich Auktionen inserieren können”)
237
Q

Was ist Software Engineering?

A
  • Größere Projekte organisieren (Viele Mitarbeiter managen, Wartbarkeit der Software wahren)
  • Architektur (Entwurfsmuster, Architekturstile)
  • Modellierung(Klassendiagramme/UML)
  • Arbeitsweisen(Agile)
  • Spezifikation(Was möchte der Kunde, was möchte ich?)
  • Projektmanagement
238
Q

Warum lohnt sich Software Engineering?

A

-Katastrophen zu verhindern durch Softwarefehler, wie Bugs

239
Q

Was sind große und Bekannte Bugs?

A
  • Arianne 5 Jungfernflug (Selbstzerstörung durch Stackoverflow der Software alter Rakete)
  • Hamburger Stellwerk (Stackoverflow)
  • Denver Koffer Debakel (Architekturfehler)
240
Q

Warum ist es unmöglich fehlerfreie Software zu erstellen?

A
  • Hardware ändert sich stetig
  • Zeitdruck
  • Komplexität
241
Q

Warum ist es gut Frontend und Backend voneinander zu trennen?

A

-Da Frontend sehr kurzlebig ist und vermutlich zeitnah ausgetauscht oder erweitert wird

242
Q

Wie unterscheidet sich die Spezifikation in einem agilen und einen traditionellen Projekt?

A
  • Traditionell: Es wird ein Spezifikationsblatt erstellt um alles aus dem Spezifikationsbaukasten abzuhaken, danach beginnt das Programmieren
  • Agil: Es ist noch nicht alles festzuschreiben
243
Q

Was ist der Unterschied zwischen Anwendungsfall/UseCase und Geschäftsprozess?

A
  • Ein Anwendungsfall/UseCase ist etwas kleines

- Ein Geschäftsprozess ist etwas großes

244
Q

Was sind Geschäftsregeln?

A

-Wenn z.B. eine Stornierung geschieht legt eine Geschäftsregel fest bis wann der Storno erfolgt

245
Q

Wann wird Gechäftsmodellmodellierung oft angewendet?

A

-Zur Optimierung von bestehenden Systemen/Firmen

246
Q

Woran erkennt man was in einem Komponente gehört?

A
  • Ergibt sich aus dem fachlichen Datenmodell, was dort stark zusammenhängt ist eine Komponente
  • Auch über die Anwendungsfälle/UseCases können thematische Zusammenhänge eine Komponente werden
247
Q

Erklären Sie Kopplung knapp

A
  • Kopplung sollte stets möglichst gering sein, da wenn man etwas verändert es sich sonst auf alles andere auswirkt
  • Wird durch Komponenten reduziert
248
Q

Was tun Entitätsklassen?

A

-Modellieren Objekte aus der Realität(als Klassen)

249
Q

Was tun Repositoryklassen?

A
  • Definieren die Schnittstelle zur Datenbank

- Werden von UseCaseKlassen benutzt um an Entitätsinstanzen zu gelangen und damit zu arbeiten

250
Q

Was tun UseCaseKlassen?

A

-Implementieren einen UseCase/Anwendungsfall, also eine Aktion die ein Nutzer anstößt

251
Q

Was ist der Nutzen von Spring Boot und Spring Data JPA?

A
  • Spring automatisiert die Nutzung(weniger selbst coden)

- DAO Pattern für die Datenbank

252
Q

Was ist der Nutzen von Gradle und Buildsystemen?

A
  • Unabhängigkeit vom lokalen Rechner/IDE/Testumgebung

- Etwas soll allgemeingültig funktionieren