SWEN2

Steht für  Software Engineering Body of Knowledge und ist ein Guide für das Entwickeln von Software des IEEE (Institute of electrical and electornics engineers)

Ziele von SWEBOK:

• to characterize the contents of the software engineering discipline;
• to promote a consistent view of software engineering worldwide;
• to clarify the place of, and set the boundary of, software engineering with respect to other disciplines;
• to provide a foundation for training materials and curriculum development; and
• to provide a basis for certification and licensing of software engineers.

Unabhängig ablaufende Elemente, welche über Nachrichten miteinander agieren.

Communication Processes und Event Systems.

Wasserfall:

• Lineares Modell welches in aufeinanderfolgende Projektphasen organisiert ist: 
  • Anforderungen
  • Entwurf
  • Implementation
  • Überprüfung
  • Wartung
• Vorteile:
  • Einfach verständlich
  • Bei soliden Anforderungen einigermasse gute Abschätzung von kosten und Umfang möglich
• Nachteile:
  • Unflexibel
  • Softwareprojekte laufen häufig nichtlinear ab
  • Anforderungen sind im voraus so gut wie nie 100% bekannt
  • Es wird häufig am User vorbeientwickelt (Nur 20% der Features werden wirklich gebraucht)

Unified Process

• Iterativ und inkremental
• Use case driven
• Risk first => d.H. kritische Use Cases zuerst entwickeln
• Vier Phasen:
  • Inception (Risiken identifizieren sowie provisrische Architektur)
  • Elaboration (Architekturprototyp und detaillierte Beschreibung von 80% der Use Cases)
  • Construction (Entwickeln und testen des Produkts)
  • Transition (Übergabe und Auslieferung der Software)
• Vorteile:
  • Skalierbarkeit auf grosse und kleine Projekte
  • Bekanntes Verfahren (d.H: es gibt Standards für Sachen wie UML)
  • Klare Struktur
• Nachteile:
  • Sehr Dokumentationslastig (mit teilweise wenig Businessvalue)
  • Schwierige Einführung von neuen Entwicklern welche das System nicht kennen

Fixer Kommunikations-Mechanismus zwischen aufrufendem Element und aufgerufenen Element

Main Program & Subroutine / Object Oriented / Layered

Brooks unterscheidet zwischen ungewollter (accidental) und notwendiger (essential) komplexität. Ungewollte komplexität sind Probleme welche gelöst werden können. Notwendige Komplexität kann nicht umgangen werden. Wenn ein User 30 Sachen von einer Software will, muss diese Software diese 30 Sachen unterstützen. Ungewollte Komplexität geht immer mehr zurück, durch bessere Programmiersprachen und Tools und Programmierer können sich auf die notwendige Komplexität fokussieren.

Brooks empfiehlt Software inkrementell und anhand von Prototypen zusammen mit dem Kunden zu entwickeln. Ausserdem sagt er, dass der Fokus bei der Bildung von Programmieren auf der Softwaredesignebene liegen sollte. "Starsoftwaredesigner" sollten zudem gleich behandelt werden wie Starmanager.,

 Erlaubt die Realisierung portabler und interpretierbarer Systeme

Interpreter und Rule-Based Systems

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

System ist eine Abfolge von Datenbezogenen Transformationen

Batch Sequential und Pipes and Filters