93 lines
3.5 KiB
Markdown
93 lines
3.5 KiB
Markdown
# Software Processes
|
|
In den 1950ern wurde Software an Seite der Hardware entwickelt
|
|
- Ziel dieser Prozesse war das komplette Produkt in einem einzigen Projekt zu entwerfen
|
|
|
|
## Classic Organizational Structure
|
|
- **Business or Client**
|
|
- braucht neue Software/System
|
|
- Definiert Kriterien, welche für die Vollständigkeit des Systems essenziell sind
|
|
- Definiert _[requirements specification](IntroductionOOAD.md#requirements-in-software-engineering)_, welche das benötigte System beschreibt
|
|
- **Entwicklungsteam oder Software-Firma**
|
|
- Bekommt _requirements specification_
|
|
- Designt und entwickelt das System anhand der gegebenen Spezifikationen
|
|
- Erstellt ein Handbuch
|
|
- **Operations Team**
|
|
- Bekommt Handbuch
|
|
- Nimmt Rechenschaft für das Laufen der Software auf sich
|
|
- Gibt auftretende Fehler an das Entwicklungsteam weiter
|
|
|
|
|
|
## Handling of Change: Implications
|
|
Ursprüngliches Projekt ist fertig - Kunde ist aber nicht glücklich
|
|
- Ein neues Projekt startet den SDLC neu
|
|
- 
|
|
|
|
## Waterfall Model
|
|
- Sequenzielle Ausführung der Phasen des [SDLC](IntroductionOOAD.md#software-development-lifecycle-sdlc)
|
|
- Jede Phase wird mit einer Dokumentation des Schritts beendet
|
|
- Iterationen sind nur zwischen zwei aufeinanderfolgenden Phasen möglich
|
|
- 
|
|
- [](SoftwareProcesses.md#classic-organizational-structure)
|
|
|
|
## Neue Modelle
|
|
### V-Modell
|
|
|
|
### Spiral-Modell
|
|
|
|
|
|
## Agile
|
|
### The Agile Manifesto
|
|
#### 4 Werte
|
|
- **Individuen und Interaktionen** über _Prozesse und Werkzeuge_
|
|
- **Funktionierende Software** über _verständliche Dokumentation_
|
|
- **Arbeit mit Kunden** über _Vertragsverhandlungen_
|
|
- **Anpassung an Veränderung** über _folgen des Plans_
|
|
|
|
#### 12 Prinzipien
|
|
- Funktionierende Software ist die primäre Ressource um den Fortschritt zu messen
|
|
- Die höchste Priorität ist den Kunden durch frühe und durchgehende Lieferung von wertvoller Software glücklich zu machen
|
|
- Liefere funktionierende Software regelmäßig, ~mehrere Wochen bis mehrere Monate → kürzer = besser
|
|
- Durchgehende Aufmerksamkeit auf technische Exzellenz und gutes Design verbessert die Agilität
|
|
|
|
### Strongly Iterative Development
|
|
Verstärkt durchgehende Kreation von Nutzen für Kunden
|
|
- Scope: wichtigsten Features der Iteration
|
|
- 
|
|
|
|
Durchgehende Anpassung der Anforderungen an aktuelle Nachfrage
|
|
- 
|
|
|
|
### Small and Cross-functional Teams
|
|
- Selbst organisiert, divers, T-shaped skills
|
|
- klein
|
|
- 
|
|
- Beispiel Scrum Team:
|
|
- **3-9 Developers**
|
|
- verantwortlich für alle Aspekte der Entwicklung
|
|
- **1 Product Owner**
|
|
- spielt Kunde für die Devs, kreiert und priorisiert Features
|
|
- **1 Scrum Master**
|
|
- Coach, Prozess-Authorität
|
|
|
|
Business/Client wird Teil des Teams
|
|
- Product Owner
|
|
- 
|
|
|
|
|
|
## DevOps
|
|
Erweiterung der agilen [Software-Entwicklung](SoftwareProcesses.md#agile)
|
|
- nicht nur Dev (_Entwicklung_), sondern auch Ops(_Operations_)
|
|
|
|
- Gefördert durch dynamische Cloud-Infrastuktur
|
|
- Führt zu höherer Qualität
|
|
- Devs machen stabileren Code
|
|
- fördert Automatisierung in allen Aspekten
|
|
|
|
DevOps fördert schnellere Iterationen
|
|
- Features können individuell ausgeliefert werden
|
|
- mehrere Releases am Tag sind normal
|
|
- schnellere Feedback-Cycles
|
|
- Bessere Adaption zu neuen Anforderungen
|
|
- Nutzer-Verhalten kann aufgezeichnet und für spätere Arbeit genutzt werden
|
|
|