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