200 lines
9 KiB
Markdown
200 lines
9 KiB
Markdown
# 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
|