Add notes for the SWEN SEP
This commit is contained in:
parent
2c984834d3
commit
3bfc4d5623
1 changed files with 199 additions and 0 deletions
199
Notes/Semester 4/SWEN2 - Software Entwicklung 2/SEP.md
Normal file
199
Notes/Semester 4/SWEN2 - Software Entwicklung 2/SEP.md
Normal file
|
|
@ -0,0 +1,199 @@
|
||||||
|
# Software Engineering Prüfungsstoff
|
||||||
|
Dieses Dokument hält die verschiedenen Themen fest, welche im Rahmen der SEP unter Umständen angesprochen werden.
|
||||||
|
|
||||||
|
## Einführung Softwareentwicklung
|
||||||
|
- Sie können Vor- und Nachteile der plangetriebenen Methoden aufzählen
|
||||||
|
> Plangetriebene Projekte legen ihre Ziele und den Umfang des Projekts zu Beginn fest. Weitere Schritte passieren sequentiell.
|
||||||
|
>
|
||||||
|
> Man spricht hierbei vom Wasserfall-Modell
|
||||||
|
>
|
||||||
|
> Projekte können durch das Wasserfall-Modell nicht auf Änderungen an der Infrastruktur antworten oder die Ziele aufgrund anderer Anlässe verändern.
|
||||||
|
>
|
||||||
|
> Agile Projektmethoden leisten Abhilfe.
|
||||||
|
- Sie wissen, für welche Arten von Projekten die plangetriebenen Methoden verwendet resp. nicht verwendet werden sollten.
|
||||||
|
> Einsetzen für:
|
||||||
|
> - Projekte ohne jegliche Abhängigkeiten
|
||||||
|
> - Projekte ohne sich ändernder Umgebung
|
||||||
|
> Nicht einsetzen für:
|
||||||
|
> - Software-Projekte
|
||||||
|
> - Projekte mit dynamischen Umgebungen
|
||||||
|
- Sie können die drei Gesetze der Softwareentwicklung erklären
|
||||||
|
> - Humphrey's Law - "Menschen wissen nicht, was sie wollen, bevor sie es sehen"
|
||||||
|
> - Ziv's Law - "Softwareentwicklung ist unvorhersehbar und kann nie vollends verstanden werden"
|
||||||
|
> - Conway's Law - "Software ist ein Spiegel der Firma und der Menschen, die sie entwerfen"
|
||||||
|
|
||||||
|
## Agile Manifesto
|
||||||
|
- Sie können die "Values" des "Agile Manifesto" aufzählen und deren Bedeutung erklären
|
||||||
|
> - "Individuals and interaction over processes and tools":
|
||||||
|
> Es sollen auf Individuen und die Interaktionen mit ihnen, statt auf Prozesse und Tools geachtet werden.
|
||||||
|
> Dadurch kann u.a. sichergestellt werden, dass die Stärken der Team-Mitglieder besser eingesetzt werden.
|
||||||
|
> - "Working software over comprehensive documentation":
|
||||||
|
> Eine schnelle Fertigstellung des Codes sorgt für möglichst schnell verfügbares Feedback.
|
||||||
|
> - "Customer collaboration over contract negotiation":
|
||||||
|
> Dies soll sicher stellen, dass alle beteiligten zum selben Ziel hin arbeiten.
|
||||||
|
> - "Responding to change over following a plan":
|
||||||
|
> Auf Anregungen des Kunden, falls sich Ziele ändern sollten, soll zeitnahe eingegangen werden. Es soll nicht auf alte Ziele beharrt werden.
|
||||||
|
- Sie kennen die "12 Principles" hinter dem "Agile Manifesto" und können diese erklären.
|
||||||
|
> - Customer Satisfaction
|
||||||
|
> - Welcome Change
|
||||||
|
> - Deliver Frequently
|
||||||
|
> - Working Together
|
||||||
|
> - Motivated Team
|
||||||
|
> - Face to Face
|
||||||
|
> - Working Software
|
||||||
|
> - Constant Pace
|
||||||
|
> - Good Design
|
||||||
|
> - Simplicity
|
||||||
|
> - Self Organisation
|
||||||
|
> - Reflect and Adjust
|
||||||
|
- Sie können die Bedeutung des agilen Manifesto für Softwareentwicklung einordnen
|
||||||
|
> Hält die Prinzipien der agilen Community im Bereich Software-Entwicklung fest.
|
||||||
|
|
||||||
|
## Agile
|
||||||
|
- Sie kennen die folgenden Begriffe und können sie erklären:
|
||||||
|
- Risk:
|
||||||
|
> Event that never happened before and might limit the success of the project if it happens.
|
||||||
|
- Cost of Change
|
||||||
|
> Die Kosten (bspw. in Aufwand), die ein Feature wert ist (Story Points)
|
||||||
|
- Four Variables (Iron Triangle)
|
||||||
|
> Zeit, Ressource, Qualität, Scope (Features) - alle haben Einfluss aufeinander - nichts kann zugleich 100% ausgeprägt sein.
|
||||||
|
|
||||||
|
## eXtreme Programming
|
||||||
|
- Sie können erklären, was eXtreme Programming ist.
|
||||||
|
> eXtreme Programming ist eine Methode zum Umsetzen von Projekten in Umgebungen und mit Anforderungen, die sich ständig ändern.
|
||||||
|
- Sie können die folgenden Begriffe erklären:
|
||||||
|
- Core Values
|
||||||
|
> - Communication
|
||||||
|
> - Simplicity
|
||||||
|
> - Feedback
|
||||||
|
> - Courage
|
||||||
|
> - Respect
|
||||||
|
- Principles
|
||||||
|
> - Fundamental Principles
|
||||||
|
> - Rapid Feedback
|
||||||
|
> - Assume Simplicity
|
||||||
|
> - Incremental Change
|
||||||
|
> - Embracing Change
|
||||||
|
> - Quality Work
|
||||||
|
> - Other Principles
|
||||||
|
> - Teach Learning
|
||||||
|
> - Small Initial Investment
|
||||||
|
> - Play to Win
|
||||||
|
> - Concrete Experiments
|
||||||
|
> - Open, Honest Communication
|
||||||
|
> - Work with People's Instincts, not Against them
|
||||||
|
> - Accepted Responsibility
|
||||||
|
> - Local Adaption
|
||||||
|
> - Travel Light
|
||||||
|
> - Honest Measurement
|
||||||
|
- Cost of Change
|
||||||
|
> Story Points
|
||||||
|
- Business Value
|
||||||
|
> The amount of money an organization will make by having the corresponding feature
|
||||||
|
- Sie kennen folgende XP Practices und können sie erklären
|
||||||
|
- The Planning Game
|
||||||
|
> Ehrliche, instinktive Vergabe von Story-Points (Zeit-Poker)
|
||||||
|
- Small Releases
|
||||||
|
> Kleine Änderungen vermeiden grosse Fehler
|
||||||
|
- Metaphor
|
||||||
|
> Alle beteiligten Personen (auch Kunden) sollen sich verstehen - es wird ein gemeinsames Vokabular benötigt
|
||||||
|
- Simple Design
|
||||||
|
> Besteht alle Tests. Keine Code-Duplikation. Hat so wenig Klassen/Methoden wie möglich.
|
||||||
|
- Unit-Testing
|
||||||
|
> Alle automatisierten Prozesse des Projekts **müssen** getestet sein
|
||||||
|
- Refactoring
|
||||||
|
> Gibt es Refactorings, die das Einbauen eines Features erleichtert, soll dieses immer als erstes umgesetzt werden.
|
||||||
|
- Pair-Programming
|
||||||
|
> Code wird zu zweit geschrieben. Eine Person schreibt Code, die andere beobachtet und bewertet den Prozess/bringt Innovation.
|
||||||
|
- Collective Code Ownership
|
||||||
|
> Jede beteiligte Person hat 100%ige Verantwortlichkeit über den Code
|
||||||
|
- Continuous Integration
|
||||||
|
> Code wird min. 1x pro Tag getestet. Dies muss automatisiert sein.
|
||||||
|
- 40 Hours Week
|
||||||
|
> Auf die Work-Life Balance der Mitarbeiter muss geachtet werden. Nicht zu viel Überzeit.
|
||||||
|
- On-Site Customer
|
||||||
|
> Ein Kunde muss vor Ort beim Team sein, um Fragen zu beantworten
|
||||||
|
- Coding Standards
|
||||||
|
> Egal
|
||||||
|
- Test-Driven Development
|
||||||
|
> Tests werden gem. Erwartungen geschrieben. Erst dann wird der Code dazu implementiert.
|
||||||
|
- Slack
|
||||||
|
> Kleine Aufgaben einplanen, die eingestampft werden können, falls die Zeit knapp wird.
|
||||||
|
- Incremental Design
|
||||||
|
> Probleme in kleine Bestandteile aufteilen, um diese einzeln zu lösen.
|
||||||
|
- Self-Organized Team
|
||||||
|
> Self sprechend
|
||||||
|
|
||||||
|
## Software Craft
|
||||||
|
- Sie kennen Gründe, wieso das Manifest für Software Craft notwendig wurde.
|
||||||
|
> - Establish Principles
|
||||||
|
> - Develop School
|
||||||
|
> - Vocal Community
|
||||||
|
> - Create Visibility
|
||||||
|
> - Guidance for New Developers
|
||||||
|
- Sie kennen die Formate der Software Craft Community, wie ein Austausch geschaffen wird und deren Prinzipien
|
||||||
|
> Durch Konferenzen und Online-Portale (SC, SoCraTes, Software Crafters Zurich, Software Crafters Manila), weitere Aktivitäten
|
||||||
|
- Sie können erklären, wie man als Softwareentwickler üben kann
|
||||||
|
- Sie können Coding Dojo und Code Katas ausführlich erklären
|
||||||
|
> "A bunch of coders get together, code, learn, and have fun. It's got to be a winning formula!" – Emily Bache
|
||||||
|
|
||||||
|
## Pyramid of Agile Competence
|
||||||
|
- Sie kennen die "Pyramid of Agile Competencies" und können die drei Ebenen erklären
|
||||||
|
> - Agile Values
|
||||||
|
> - Craftsmanship, Organization Culture, Transparency & Openness
|
||||||
|
> - Collaboration Practices
|
||||||
|
> - Agile Champion, Customer & Requirements, Communication
|
||||||
|
> - Technical Practices
|
||||||
|
> - Testing, CI, Clean Code
|
||||||
|
|
||||||
|
## User Stories
|
||||||
|
- Sie beschreiben die Ziele, die Anwendung und wie das Format einer Userstory aufgebaut ist.
|
||||||
|
- Sie kennen die Zusammenhänge zwischen Epics, Themes und Stories
|
||||||
|
> - Epics sind grosse User Stories
|
||||||
|
> - Theme ist ein Verbund mehrerer User Stories
|
||||||
|
- Sie kennen die Eigenschaften einer guten Userstory
|
||||||
|
|
||||||
|
## Estimation and Planning
|
||||||
|
- Sie kennen die folgenden Begriffe und können diese erklären
|
||||||
|
- User Stories
|
||||||
|
- User Roles
|
||||||
|
- Epics
|
||||||
|
- Themes
|
||||||
|
- Story Points
|
||||||
|
- Velocity
|
||||||
|
> Das Ergebnis von $\text{Story Points} \div \text{Time}
|
||||||
|
- Planning Poker
|
||||||
|
- Conditions of Satisfactions
|
||||||
|
> Bedingungen, unter denen eine User Story als abgeschlossen gilt
|
||||||
|
- Levels of Planning
|
||||||
|
> Aufteilung von Teilaufgaben in...
|
||||||
|
> - Strategy
|
||||||
|
> - Portfolio
|
||||||
|
> - Product
|
||||||
|
> - Release
|
||||||
|
> - Iteration
|
||||||
|
> - Day
|
||||||
|
- Product Backlog
|
||||||
|
> Sammlung offener Aufgaben
|
||||||
|
- Priorisierung (der User Stories)
|
||||||
|
- Techniques for Estimating
|
||||||
|
> Planning Poker
|
||||||
|
- Sie kennen die folgenden Begriffe und können diese erklären:
|
||||||
|
- Planning for Value
|
||||||
|
> Aufgaben nach deren Wert im Projekt priorisieren
|
||||||
|
- Financial Value
|
||||||
|
> Aufgaben nach finanziellen Wert für Kunden-Firma priorisieren
|
||||||
|
- Risk
|
||||||
|
> Siehe Abschnitt "Agile"
|
||||||
|
- New Knowledge
|
||||||
|
> Der Zeitaufwand, der dazu aufgewendet werden muss, sich neues Wissen anzueignen
|
||||||
|
|
||||||
|
## Build Automation, CI, CD, DevOps
|
||||||
|
- Sie können die Arten von Software Automation, Arten von Automation und Ziele erklären
|
||||||
|
> Arten von Software Automation:
|
||||||
|
> - on-demand: Automation wird auf Verlangen ausgelöst
|
||||||
|
> - scheduled: Automation wird regelmässig ausgeführt (bspw. nächtlich, monatlich o.ä.)
|
||||||
|
> - triggered: Automation wird durch Vorkommnis ausgelöst (bspw. sobald Änderungen am Code veröffentlicht werden.)
|
||||||
|
> Arten von Automation:
|
||||||
|
> - Continuous Integration: Automatisiertes Testen
|
||||||
|
> - Continuous Deployment: Automatisiertes Veröffentlichen/Installieren/Ausliefern
|
||||||
Loading…
Reference in a new issue