Software Engineering 2 - 2 Flashcards

Question

Welchen Zweck hat die Dokumentation für den **Admin**? Und Welche Dokumente bekommt er?

Answer 1

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 2

* 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 3

_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 4

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 5

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 6

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

Answer 7

* 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 8

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

Answer 9

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

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 11

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

Answer 12

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

Answer 13

* In den 80/90ern

Answer 14

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

**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 16

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

Answer 17

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 18

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 19

Ja, als agiles Framework tut es das.

Answer 20

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 21

Weiter gehts, ich hab dich lieb!

Answer 22

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 23

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 24

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 25

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 26

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 27

**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 28

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 29

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

Answer 30

* 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 31

* 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 32

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 33

**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 34

**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 35

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

Answer 36

**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 37

* Punkte verrechnen

Answer 38

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 39

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 40

* 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 41

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 42

**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 43

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

Answer 44

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

Answer 45

* **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 46

* 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 47

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

Answer 48

* 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

Software Engineering 2 - 2 Flashcards

(84 cards)