Skip to content

y0urself/Software_Engineering

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
readme.md
readme.md
 
 

Repository files navigation

Software Engineering

Schnittstelle Aufgabe
Software-Entwicklungsumgebung Bereitstellen
Qualitätssicherung Anforderungen, Prüfen
Software-Entwicklung Entwickeln, (Wartung, Evolution)
Projektmanagement Planen und Kontrollieren
Software-/Konfigurationsmanagement Projektstruktur planen, Rechte und Produkte verwalten

Phasen der Entwicklung

  1. Anforderungsphase: Analyse des Kundenwunschs
  2. Spezifikationsphase: Kontrakt,
  3. Planungsphase: Entwurf von Projektdurchführung, Aufwand-, Zeitabschätzung
  4. Entwurfsphase: Hard-/Softwareentwurf, Detailentwurf
  5. Implementierungsphase: Impl. von Programmkomponenten, Test d. Systems
  6. Integrationsphase: Auslieferung an Kunden
  7. Wartungsphase: Betrieb b. Kunde, Verbesserung, Erweiterung
  8. Rückzugsphase: Einstellung, Datensicherung

nach oben

Modularisierung

  • Exportschnittstelle: auf welche Konstrukte (Funktionen oder Variablen) kann von außen zugegriffen werden (auch außen sichtbare Informationen über Typen)

  • Importschnittstelle: welche Konstrukte werden von außen benutzt (in Sprachen teils nur implizit unterstützt)

  • Tiefe/Breite der Modulstruktur sollte vernünftig sein

  • Modulgröße und Modulzahl sind zueinander gegenläufige Größen

Lieber kleine Module, die genau eine Sache machen und keine Entscheidungen haben.

Bindung

  • reflexive Beziehung: Beziehung einer Klasse zu sich selbst
  • Zusammenhang innerhalb des Modules
  • möglichst eng, aber nicht zu eng -> z.B. Kommunikatorisch

Arten:

zufällig logisch temporal prozedual Kommunikations- sequenziell funktionale Bindung
niedrig (zerstreut) hoch (eng)

prozedural: Prozeduren in der Aufrufreihenfolge voneinander abhängig, muss nicht sein, dass alle und alles starr ausgeführt wird Beispiel: Stack

sequenziel: Sequenz muss vollständig ausgeführt werden, alle Methoden in einer festen Reihenfolge Beispiel: Schalter: erst an, dann aus (anders geht nicht)

nach oben

Kopplung

  • Abhängigkeit zwischen den Modulen
  • möglichst kleine Kopplung -> Stempel- oder Datenkopplung
  • am Besten NIE Steuerkopplung

Arten:

keine direkte Daten- Stempel- Steuer- Externe/ Common- Inhaltskopplung
niedrig hoch

Design by Contract:

Invariants (C4J):

  • Client (Aufrufer des Modules) must ensure precondition and may assume postcondition
  • Method (Modul) may assume precondition and must ensure postcondition -> Invariante gilt immer, außer wenn Prozeduren, Methoden, Funktionen ausgeführt werden

@Java: java -ea (enable assertions) -javaagent:$(lib_path)/$(lib_name)

@ in comment: Java-Annotationen z.B. @goal ...

Observer beobachtet Observable, wird benachrichtig, wenn irgendwas sich ändert

  • notifyAll(), notifyObservers()

nach oben

Projektmanagement

Grundlagen:

  • Magisches Dreieck aus Zeit, Qualität und Ressourcen (z.B. Mitarbeitertage)

    • Leistungen (z.B. Anzahl der SW Elemente)
    • Produktivität = (Leistungen * Qualität) / Ressourcen

  • Ressource

  • Planung

  • Meilenstein

  • kritischer Pfad

  • Projektrisiko

  • Projekterfolg

  • Projekttyp

  • Motivationsmodell: Was Entwickler kann, muss, will und was honoriert wird ...

Organisationsformen:

  • starke bis schwache Hierarchie
Organisationsformen Beschreibung
Funktionale Organisation Abteilungen bzw. Gruppen mit Spezialisten für einzelne Aufgaben
Reine Projektorganisation Temporäre Struktur(Sekundär)
Matrixorganisation jeder Mitarbeiter hat einen festen Platz in der Primärunternehmensorganisation und gleichzeitig seine Rolle(n) in Projekten

Teamorganisation

  • kleine Teams und "Einzelkämpfer"
  • anarchische Teams
  • demokratische Teams
  • hierarchische Teams
  • Chief-programmer Teams

nach oben

Vorgangsliste

ID Aufgabe Vorraussetzung  Zeit
A Aufgabentext lesen 30 Minuten
B Arbeitspakete identifizieren A 10 Minuten
C Projektstrukturplan B 20 Minuten
D Vorgangsliste erstellen C 10 Minuten
E Netzplan zeichnen D 40 Minuten
F Gantt-Diagramm D 30 Minuten
G Organisationsformen A 10 Minuten
H Fragen der Tutoren vorbereiten 30 Minuten

nach oben

Projektstrukturplan

Gliederungsarten:

  • Funktionsorientiert
  • Objektorientiert
  • Phasenorientiert
  • andere Kriterien
  • Mischformen

Netzplan

  • Vorgangsname und ID
  • Dauer des Vorgangs
  • Start und Endzeit vorwärts (VA und VE)
  • Start und Endzeit rückwärts (RA und RE)
  • Puffer zwischen RA und VA, kann nicht negativ sein!

Anordnungsbeziehungen

Anordnungsbeziehung Beschreibung 
Normalfolge (Ende-Anfang) Y muss beendet sein bevor X anfangen kann
Endfolge(Ende-Ende) Y muss beendet sein bevor X beendet werden kann
Sprungfolge (Anfang-Ende) Y muss angefangen haben bevor X enden kann
Anfangsfolge (Anfang-Anfang) Y muss angefangen haben bevor X anfangen kann
  • Vorwärts- und Rückwärtsrechnung
  • kritischen Pfad bestimmen

nach oben

Gantt-Diagramm

10    20    30    40    50    60    70    80    90
A ##############
B               ######
C                     ############
D                     ######
E                           ########################
F                           ##############################
G               ######
H ##############
  • Meilensteine eintragbar

nach oben

Meilenstein-Trendanalyse

  • Verzögerungen sind schlecht
  • Schätzzeitpunkt - was denke ich zu Schaffen?
  • Berichtzeitpunkt - was ist zum angegebenen Zeitpunkt fertig?
  • Diagonale ist optimal ...

Brook'sches Gesetz

  • Mitarbeiter vs. Kommunikationsaufwand
Variable Beschreibung Formel
k Kommunikationsaufwand k = c_k * (n^2/2)
a Entwicklungsdauer a = t * (1/n)
n Anzahl Mitarbeiter
c_k Konst. für durchschnittl. individ. Kommunikationsaufwand
t Entwicklungsdauer des Projektes

(z.B) Angegebene Parameter:

Ein Mitarbeiter arbeitet 40 Stunden die Woche. 3 Mitarbeiter benötigen 5 Wochen. c_k = 2

... t = 40 * 3 * 5 = 600
... a = 600 * (1/3) = 200
... k = 2 * (3^2/2) = 2 * (9/2) = 9
-> Suche nun min. Gesamtzeitaufwand pro Mitarbeiter ...

nach oben

COCOMO

(Constructive Cost Model)

Faktor Varibale Beispiel
Lines of Code LoC
Vorgangsdauer VD VD = a * kLoC^b
Personentage PM
Umrechnungsfaktor a a = LoC/PM 400 LoC/PM <=> 1/0.4 PM/kLoC <=> 2.5 PM/kLoC
Gewichtungsfaktor b (exponenziell ...)
Einflussfaktoren EF
Schwere a b
einfaches Softwareproblem 2,4 1.05
mittelschweres Softwareproblem 3,0 1,12
schweres Softwareproblem 3,6 1,2
  • Intermediate COCOMO ( COCOMO * EF )
  • EF = (Summe aller) Einflussfaktor(en)
  • Schlecht: kLoC muss man schätzen!

nach oben

Function Points

Beispiel:

Anforderungen -> zuordnen + klassifizieren

Anforderung  Typ Schwere
Anmeldung im System Abfrage niedrig
Pizza bestellen Eingabe mittel
Speiseplan verändern Datenbestände hoch
  • Summe der Einflussfaktoren: 15

Rechnung:

  • FPu ungewichtete Functionpoints
  • FP gewichtete Functionpoints
  • EF Einflussfaktor(en)
sum(uFP) = 3 + 4 + 15
FP       = sum(FPu) * ((0.01 * sum(EF)) + 0.65)
FP       = 22       * ((0.01 * 15)      + 0.65) = 17.6
  • empirische Daten sammeln und über Erfahrungen mitteln
  • 14 Einflussfaktoren (Wert 0-5), Summe kann zwischen 0.0 und 0.7 liegen
    • Dadurch sind die gewichteten FP immer zwischen 0.65 * uFP <= FP <= 1.35 * uFP
Element niedrig mittel hoch
Eingabe (external Input) 3 4 6
Ausgabe (external Output) 4 5 7
Datenbestände (internal Logical File) 7 10 15
Abfrage (external Inquery) 3 4 6
Referenzdaten (external Interface File) 5 7 10

Klausur:

Erkläre Funktion Points:

  • 5 Kategorien, 3 Katogerisierungen leicht mittel schwer, 14 Einflussfaktoren
  • Tabelle unwichtig
  • 14 Einflussdinger (Gewichtung bis 5), 35%, Rückkopplungsprozess, ...
  • Immer genauer werden, Daten sammeln, ...

Beispiel

... dann halt machen

nach oben

Konfigurationsmanagement

Konfigurationselemente

  • Quelltext

  • Schnittstellenverträge

  • Anforderungsdokumente (z.B. Use Cases)

  • Architektur- und Designdokumente

  • Konfigurationsmanagement-Handbuch

  • Testspezifikationen und Testdaten

  • Build-Skripte

  • Meta- und Konfigurationsdaten

  • Benutzerdokumentation

  • Installationsanleitung, Release-Notes

  • Werkzeuge (z.B.Compiler, Entwicklungsumgebungen)

  • Bibliotheken

  • Generierte Artefakte (z.B. HTML-Dokumente, kompilierte Quelltexte)

  • Protokolle von Meetings

  • Binäre Auslieferungsdateien

  • Projektpläne

  • Protokolle von Meetings

  • Liste offener Punkte, Risikolisten, etc.

  • = alle Elemente in einem Repository, die unter die Versionskontrolle fallen, (Quelldateien (Dateien, die sich schnell, häufig verändern))

  • != Konstanten, Binäre Daten, ...

Konfiguationsmanagement-Plan

Einleitung -> Management -> Aktivitäten -> Zeitplan -> Ressourcen -> Pflege

nach oben

Versionskontrolle

Delta-Mechanismus

  • Reduktion von Speicherbedarf

  • Vorwärtsdelta:

    • erste Version als komplette Datei, anschließend Deltas

  • Rückwärsdelta:

    • letzte Version als kompette Datei, davor Deltas

  • lock-modify-unlock

    • keine parallele Veränderung (daher lock!)

  • copy-modify-merge

    • Arbeiten auf der Kopie, Konflikte mergen

Release-Management

  • Hauptrelease
  • Wartungsrelease
  • Patch
  • Releaseplan (?)

SVN

  • Repository, Revisionen

  • Transaktion = Schreiben in Repository

    • erhält Revisionsnummer

  • Revision ist immer das Gesamtabbild des Systems

    • keine Versionsnummern für einzelne Dateien oder Verzeichnisse

  • keine "echten" Tags und Branches

    • Branch als "Kopie"

    Kommandos für Konsole:

    • svn <command> [<option[s]>][<target>]

nach oben

GIT

  • "Speicherung von Versionen in Snapshots, nicht in Deltas" - Pulvermüller 2017
  • benötigt keinen zentralen Server

nach oben

Commands

Beschreibung git SVN
Anlegen eines neuen, leeren Quell-Repositories git init --bare svnadmin create dir, svn checkout} file://path/dir
Kopieren in ein neues Arbeitsverzeichnis git clone dir.git svn checkout dir
Aktualisierung eines bestehenden Arbeitsverzeichnisses git pull svn update
Hinzufügen von Dateien und git add file*regex*dir svn add file*regex*dir
Verzeichnissen in die Versionskontrolle git commit -m 'meh' svn commit -m 'meh', git push
Rückgängig machen von lokalen Änderungen 'git reset --soft HEAD\^, git reset HEAD\^ *regex {svn revert} file*regex
Übertragen von Änderungen in das Quell-Repository git push svn commit -m 'meh'
Verschieben, Löschen und git rm option file* svn delete *regex
Umbenennen von Dateien und Verzeichnissen git mv option file* svn move *regex, svn delete
Erzeugen von Branches git checkout -b branch svn copy /branches/new
Erzeugen von Tags git tag -a 'v1' -m 'meh' svn copy ...
Zusammenführen eines Branches mit dem Hauptentwicklungspfad mit unterschiedlichen Änderungen in derselben Datei git checkout master, git merge branch svn merge /trunk -r3:HEAD

  • Tags

    • einfache Tags, Referenz auf Commit
    • kommentierte Tags, "Zwitter zwischen Commit & Branch"

    nach oben

Buildmanagement:

  • automatisierung des Build-Prozesses

  • Dokumentation

  • clear, ...

  • Make und Ant sind imperativ

  • Maven ist deklarativ

  • Ant und Maven sind XML, plattformunabhängig

  • Make irgendwie Script, plattformabhängig

Make:

  • Regeln mit dependencies(Abhängigkeiten) und targets(Ziele)
  • baut aus den Abhängigkeiten die Ziele zusammen
# bauen wir uns ein Makefile
# einrücken :D

# variablen, aufrufen mit $()
RM = rm -rf

# file-lists
FILE = test.txt

# target
$(FILE):
touch $(FILE)

# pseudo target
all:

#  $^
#  $+ alle Abhängigkeiten, wo noch Abhängigkeiten

# intermediate target, wenn aus %.text: %.txt aufgerufen
# wildcard
# touch target "$@"
%.txt:
touch $@

# wildcard
# name der ersten abhängigkeit: &< und name des targets: &@
%.text: %.txt
cp $< $@

# target: dependencies(target)
test.text: test.txt
cp test.txt test.text

# pseudo target
# wird immer ausgeführt
clean:
$(RM) $(FILE)
rm -rf jar.jar

nach oben

Maven:

  • mvn archetype:generate -DgroupId=de.uos.swe -DartifactId=uebung-maven
    • archetype: was soll passieren?
    • groupID: Paketname (erste 3 ...),
    • artifactID: wie soll die jar-Datei heißen?
      • fragt Dinge ab, welcher build, ...
    • pom.xml ist analog zum Makefile, build.xml
      • <dependencies> wenn neue <dependency>,
      • schaut ob maven local installiert`ist
      • sonst schaut er global, ob es auf maven liegt und läd es runter, wenn er es findet
Befehl Aufgabe
mvn compile kompiliert den Kram
mvn validate
mvn package mache ein Package daraus
mvn test ablaufen der Tests mit JUnit
mvn integration test teste ob es integriert funktioniert
mvn varify ist das erstelle korrekt? Prüfsumme, ...
mvn install frimelt es aus dem Maven Repository raus
mvn site Erstellt eine Internetseite documentation
mvn clean

Beispiel Maven Plugin

package de.uos.swe;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;

/**
* @goal message
*/
public class MyMojo extends AbstractMojo {
  /**
  * @parameter property="message"
  */
  private String message="Hello!";

  public void execute() throws MojoExecutionException {
    getLog().info(message);
  }
}

Beispiel pom.xml

<build>
  <plugins>
    <plugin>
      <groupId>de.uos.swe</groupId>
      <artifactId>simple-maven-plugin</artifactId>
      <version>1.0-SNAPSHOT</version>
      <executions>
      <execution>
      <phase>compile</phase>
      <goals>
        <goal>message</goal>
      </goals>
      <configuration>
        <message>I am alive!</message>
      </configuration>
      </execution>
      </executions>
    </plugin>
  </plugins>
</build>

nach oben

MAVEN Mojo:

  • mojo: Maven plain Old Java Object
  • in maven eigenes Plugin einbauen
  • getLog().info(message); -> gib mir aktuellen Mavenlog und poste was als Info Message
    • in Javadoc: @parameter property="message"
  • plugin einbauen

Ant:

  • von Apache
  • moderner als make
  • XML
    • <tag> mehr Inhalt </tag>
    • <tag atribute = bla> </tag>
    • <tag/>
      • ((()())()) -> "well formed"
    • nur ein Wurzelelement
    • XML-Schemadefinition:
      • wie ist die Struktur? (wird vorher festgelegt)
    • ant kann automatisch Strings einbauen
    • see build.xml

Klausur:

(wohl eher) Make TAB := ->|

nach oben

Software-Modelle

Vielfalt der Modellierungskonzepte

Modellierungsart Beispiel
Algorithmenorientierte Modellierung Kontrollstrukturen z. B. Programmablaufplan, Struktogramm, Pseudocode
Regelbasierte Modellierung Wenn-Dann-Beziehungen z. B. Entscheidungstabelle, Regel
Zustandsorientierte Modellierung Zustand, Nebenläufigkeit z. B. Zustandsübergangsdiagramm, Petri-Netz
Funktionsorientierte Modellierung Funktionshierarchie z. B. Funktionsbaum
Datenflussorientierte Modellierung z. B. SA (Structured Analysis) vonDeMarco (1978/79)
Datenstrukturorientierte Modellierung z. B. ERM (Entity Relationship Model) von Chen (1976), Syntaxdiagramm
Szenariobasierte Modellierung Interaktionsstrukturen z. B. Interaktionsdiagramme
Objektorientierte Modellierung Klassenstrukturen z. B. Klassendiagramm mit UML (Unified Modeling Language) von Booch, Rumbaugh, Jacobson (1996)
Geschäftsprozessorientierte Modellierung z. B. ARIS (Architektur integrierter Informationssysteme) von Scheer (1988) oder Workflow-Modelle wie BPEL
Formale Modellierung z. B. Automaten, Petri-Netze, Algebraische Spezifikation, Z, Temporale Logik, Prozessalgebra
Spezielle Modellierungssprachen z. B. für spezielle Aufgaben wie Echzeitsysteme (z. B. Realtime-UML) oder unternehmensspezifisch

Gründe und Probleme wohl offensichtlich

Programmablaufplan

= FlowChart = Flussdiagramm

  • "wie" statt "was"

  • ungeeignet für große Systeme

  • endlicher gerichteter knotenmarkierter Graph

  • Startknoten und Endknoten nicht vergessen (rund)

  • Condition (caro)

  • Ausgabe/Eingabe (Parallelogramm)

Struktogramm

= Nassi-Shneidermann-Diagramme

  • Struktogramm: Structorizer.app

  • programmiersprachenunabhängige Logikdarstellung

  • bedingte Anweisung und Fallunterscheidung in einem v

  • Schleifen (Ein oder Austrittsprüfung)

  • infinity-Loop

  • verschachtelbar

  • lineare Kontrollstrukturen

  • aufwendig zu Zeichnen

nach oben

Strukturierte Analyse

Datenflussdiagramm (DFD)

  • Menge von DFDs, Dateilexikon, Minispezifikationen
    • genau ein Übersicht DFD (kein Datenspeicher, ein Prozess)
    • ein- oder mehrere Verfeinerungs-DFDs (1 pro Prozess, keine Terminatoren)
      • Verfeinerungs-DFD sind konsistent zum Übersichts-DFD
    • Terminatoren (eckig) und Datenspeicher (parallelen) nur über Prozesse (rund) verbinden
Datenlexikon
  • endliche Menge Datendefinitionen
Art Symbol
Datenausdruck, der sich durch die Operationen definiert durch =
Produkt (Sequenzbildung, „und“) +
Iteration (Wiederholung) { . . . }
Wiederholung von M bis N M{ . . . }N
Selektion (Auswahl, „entweder...oder...“) [ . . .
Option ( ... )
Kommentar * . . . *

Beispiel

  • Aufgabenblatt = {Aufgabe}
  • Aufgabe = Text + Musterlösung + Bewertungskriterien (für Tutoren)
  • Adresse = [ Straße + Haus-Nr. | Postfachnummer ] + ( Länderkennzeichen ) + PLZ + Ort + ( Telefon ) + ( Fax )
Minispezifikation
  • z.B. Pseudocode, PAP
    • formlos

nach oben

EBNF und Syntaxdiagramm

  • zwei wichtige Beschreibungsformalismen für Datenstrukturen

Erweiterte Backus-Naur-Form (EBNF)

(Informatik D)

x→y|y′|y′′

  • wie in BNF drei Regeln x→y und x→y′ und x→y′′.

x→y[z]y′

  • zist optional, d.h. zwei Regeln x→yy′ und x→yzy′.

x→y{z}y′

  • zkommt beliebig oft (auch 0-mal) vor x → y[Z]y′ und Z → z[Z].

nach oben

Syntaxdiagramme

nach oben

Entity-Relationship-Diagramm

(Datenbanksysteme)

  • 1:1, 1:n, m:n - Beziehungen
  • Entities haben Attribute
  • Relationships zwischen Entities,
    • schwache Relationship bei 1:1 oder 1:n möglich
    • mehrwertige Relationen

Schlüssel

  • Schlüsselkandidat (Attribut(e) als Schlüssel)
  • Primärschlüssel (künstlicher Schlüssel, ID)
  • min-max-Notation
  • Generalisierung ("is-a")
  • Konsolidierung -> Anwendersichten konsolidieren -> Widerspruchsfrei, redundanzfrei, keine Synonyme, Homonyme

Funktionsbaum

  • systematische Gliederung einer Vielzahl von Funktionen
  • sehr oberflächlich

nach oben

UML

Diagrammtyp Beschreibung
Strukturdiagramme
Klassendiagramm Modellierung der Einzelklasse mit Attributen und Parametern, sowie Beziehungen untereinander
Objektdiagramm Ausschnitt zu gewissem Zeitpunkt von Objekt(instanzen) im System und ihre Beziehungen zueinander
Paketdiagramm Strukturierung des Systems nach ihren Paketen
Komponentendiagramm Komponenten mit gekapselter Funktionalität nach außen abgrenzen
Kompositionsstrukturdiagramm Komponenten tw. durchlässig von innen nach außen ...
Verteilungsdiagramm Es zeigt eine bestimmte Sicht auf die Struktur des modellierten Systems
Verhaltensdiagramme
Anwendungsfalldiagramm UseCase: Beschreibung aus User-Sicht, was das System leistet
Aktivitätsdiagramm ausdrucksmächtige Möglichkeit Abläufe oder Prozesse mit Flüssen zu beschreiben
Zustandsdiagramm Zustände und Übergänge von Objekten innerhalb eines Systems
Kommunikationsdiagramme wenig Interaktion zwischen einer (größeren) Menge von Objekten explizit dargestellt
Sequenzdiagramm viel Interaktion zwischen einer (kleinen) Menge von Objekten mit festgelegter Zeitachse
Zeitdiagramm Mischung aus Zustands- und Kommunikationsdiagramm mit echter Zeitachse (Intervall t)
Interaktionsübersichtsdiagramm Zusammensetzung zwischen Sequenz- und Aktivitätsdiagramm

Kommunikationsdiagramm, Zeitdiagramm sowie Sequenzdiagramm sind komplementär

nach oben

Strukturdiagramme

(Definition Skript)

Klassendiagramm

(class diagrams): beschreiben den strukturellen Aufbau eines Systems aus Klassen.

Objektdiagramme

(object diagrams): beschreiben zu einem bestimmten Zeitpunkt die Menge der existierenden Objekte samt Attributwerten und ihrer Beziehungen (Snapshot).

Paketdiagramme

(package diagrams): stellen die Strukturierung der Klassen eines Systems durch Pakete dar (Gruppierung, Subsystembildung).

Komponentendiagramme und Kompositionsstrukturdiagramme

(component diagrams) und (composite structure diagram): beschreiben den strukturellen Aufbau auf höherer Abstraktion (Architektur).

Verteilungsdiagramme

(deployment diagram): zeigen die Verteilung eines Systems auf Hardware-Einheiten.

nach oben

Verhaltensdiagramme

(Definition Skript)

Anwendungsfalldiagramme

(use case diagrams): beschreiben aus Benutzersicht, was ein System leisten soll

Zustandsdiagramme

(state machine diagrams): beschreiben das zustandsabhängige Verhalten von Objekten

Aktivitätsdiagramme

(activity diagrams): dienen zur Beschreibung von Abläufen im System

Interaktionsdiagramme

(interaction diagrams): beschreiben die dynamischen Interaktionen und Abhängigkeiten der Systemelemente im Ablauf

Sequenzdiagramme

(sequence diagrams): zeigen exemplarisch die Interaktion einer Menge von Objekten.

Zeitdiagramme

(timing diagrams): mischen Zustands - und Sequenzdiagramme, um den Objektzustand über eine Zeitspanne hinweg darzustellen (mit den zustandsverändernden Nachrichten).

Interaktionsübersichtsdiagramme

(interaction overview diagrams): sind Aktivitätsdiagramme, in dem Teilabläufe durch referenzierte oder eingebettete Sequenzdiagramme repräsentiert sind (Verknüpfung von Sequenzdiagrammen mit Hilfe eines umgebenden Aktivitätsdiagramms; in der Praxis eher selten).

Kommunikationsdiagramme

(communication diagrams): zeigen Kommunikations-/Kollaborationsbeziehungen zwischen Objekten zur Laufzeit.

Sequenzdiagramm

  • if/else, nur if (optional)
  • asynchron, synchrone Antwort

Kommunikationsdiagramm

  • (Instanzname):FieldController
  • Nummerierung: 
    • sequenzielle Nummerierung   1, 2, 3 ..

    • iterative Nummerierung      1 * , 1.1 * , 1.2 *

    • geschachtelte Nummerierung  1.1, 1.1.1

    • parallele Nummerierung      1a, 1b

Objektdiagramm

  • Variable dessen Zustand ungewiss ist, werden mit ihrem Typ dargestellt
    • ansonsten ihren Wert eintragen

Zustandsdiagramm

  • Terminationszustand

  • use-case-Point Methode

nach oben

Vorgehensmodelle

  • allgemeine Art des Vorgehens für ein Projekt

Code & Fix:

  • Phase I: Erstellt eine Version

  • Phase II: Änderungsphase - so lange bis fertig

  • Phase III: Wartung nach Auslieferung

  • Phase IV: Außerbetriebsetzung

  • Schlecht: Kunde ist quasi der Tester (Zyklus Phase II & III)

nach oben

Wasserfallmodell:

  • Phase I: System Requirements

  • Phase II: Software Requirements

  • Phase ..: Design

  • ...

  • Phase ...: Implementation

  • Jede Phase bedingt die nächste Phase!

  • Wasserfallmodelle werden allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen.

  • kann maximal eine Phase zurück springen, um zu fixen

nach oben

V-Modell

(Erst was, dann wie)

Anforderungsdefinition (Was?)                    <->                    Abnahmetest (durch Kunden)
    Funktionaler Systementwurf                   <->               Systemtest (Funkt. ganze System?)
        Technische Systementwurf (Wie?)          <->          Integrationstest (Zusammenschieben)
            Komponentenspezifikation (Module)    <->     Komponententest (Test einzelner Klassen)
                                            Implementation

auf Konsistenz achten!

  • betont die Tests

nach oben

Rapid-Prototyping

  • Explorativ (rausfinden, was die Anforderungen sind - Erkundung durch Implementation)
  • Evolutionär (Baue Prototypen und verbessere immer weiter, bis fertig)
  • Experimentell
    • Vertikal (Immer Schrittweise neue Funktionalitäten hinzufügen)
      • -> Horizontaler Prototyp: Eine Schicht formuliert man aus, (GUI fertig), aber da steht nichts hinter
    • Horizontal (Erstmal alle Funktionalitäten andeuten)
      • -> Vertikaler Prototyp: Ein Feature komplett durchbauen, von GUI bis zur Datenbank

nach oben

Spiralmodel

(inkrementell) [Berry Böhm]

  • Risikoanalyse -> als erstes das Problem mit dem größten Risiko lösen! :)
  • Sektoren
  • Kosten und Zustimmung durch Überprüfung (an den Achsen)
  • Anforderungen -> Testen (jede Phase)
    • Starte in der Mitte

Objektorientierte Modelle

  • Makroprozess (Konzept -> Designphase -> Analyse (nach Sinn) -> Evolution (Implementation) -> Wartung (Maintaining)
    • Mikroprozess [pro Makroprozess beliebig viele Mikroprozesse] (...ces -> Identifizierung -> Semantik -> Relationship -> Implementation, Interfaces -> Ident...)
  • das kleine "b"
    • [Grady Botch]
    • Unify Process (Objektmodell)

nach oben

Prozessmodelle

(erlaubt jedes Vorgehensmodell)

Conway's Law

„Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“

  • zusätzlich angepasst auf das Produkt, welches Vorgehen sich anbietet und welche Organisationsmodell sich anbietet, um das Vorgehen umzusetzen

  • rational Unify Process

evolutionäre Modelle

  • Grundsystem - dann neues System mit Änderungen - wieder neues System mit nächsten Änderungen (Immer neu)

inkrementelle Modelle (gut geplant!)

  • Kernsystem - weitere Ausbaustufen hinzufügen

iterative Modelle

  • arbeiten im selben System - nicht wie in evolutionär immer neu implementiert

Agile Modelle

  • Menschen, Kunden, Kommunikation, laufende Software und Reaktion auf Änderungen sind zentrale Faktoren
  • iterative Arbeitsabläufe
  • inkrementelle Auslieferung von funktionierender Software
  • kurze Iterationen, parallele Arbeitsschritte

Agiles Manifest

Individuals and interactions over processes and tools

  • Menschen und die Zusammenarbeit mit/zwischen diesen sind wichtiger als das starre Festhalten an Prozessen oder Werkzeugen

Working software over comprehensive documentation

  • Schnell eine lauffähige Software zu entwicklen ist wichtiger, als zu viel Zeit für umfangreiche (z.T. überflüssige) Dokumentation aufzuwenden

Customer collaboration over contract negotiation

  • eine enge Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen, die vorab alles festklopfen

Responding to change over following a plan

  • eine enge Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen, die vorab alles festklopfen

nach oben

Best Practices

  • Entwickle iterativ
  • Modelliere graphisch
  • Überwache Erfüllung der Anforderungen
  • Verfolge Änderungen
  • Schließe jeden Schritt mit Qualitätsprüfung ab
  • Verwende eine komponentenbasierte Version
  • Entwickle nur was zur Lösung notwendig
  • Konzentriere Dich auf die wesentlichen Ergebnisse und weniger darauf, wie sie erzielt werden
  • Vermeide unnötige Dokumente
  • Passe Dich an den Entwicklungsstand an
  • Lerne von Fehlern
  • Überprüfe regelmäßig die Risiken des Projektes
  • Entwickle objektivierbare Kriterien zur Messung des Projektfortschrittes
  • Versuche Routinearbeit zu automatisieren
  • Arbeite nach Plan

nach oben

extreme Programming (xP)

  • erstes agiles Modell?
  • tailoring?
  • kleinere Projekte 5 - 15 Personen
  • setzt agiles Manifest um

Kernwerte:

  • Einfachheit (simplicity)
  • Mut (courage)
  • Kommunikation (communication)
  • Kundenrückmeldung (feedback)

Prinzipien:

  • Unmittelbares Feedback (Rapid Feedback)
  • Einfachheit anstreben (Assume Simplicty)
  • Inkrementelle Veränderung (Incremental Change)
  • Veränderung wollen (Embracing Change)
  • Qualitätsarbeit (Quality Work)
  • Lernen lehren (Teach Learning)
  • Die weiteren XP Prinzipien:
  • Geringe Anfangsinvestition (Small Initial Investment)
  • Auf Sieg spielen (Play to win)
  • Gezielte Experimente (concrete Experiments)
  • Offene, aufrichtige Kommunikation (Open, honest Communication)
  • Die Instinkte des Teams nutzen, nicht dagegen arbeiten (Work with people ́s instincts, not against them)
  • Verantwortung übernehmen (Accept Responsibility)
  • An örtliche Gegebenheiten anpassen (Local Adaptations) Mit leichtem Gepäck reisen (Travel light)
  • Ehrliches Messen (Honest Measurements)

Praktikten

  • Pairprogramming
  • Stories
  • ...

nach oben

Scrum

  • Product-Owner: Weiß, was er haben will
    • Product Backlog:
      • Schreibt Userstories rein
      • Tasks, die das System beschreiben
    • Sprint Backlog:
      • in jedem Sprint-Zyklus werden so und so viele Tasks aus dem Product Backlog genommen und verarbeitet
      • keine neuen Story-Points während eines Sprints (in Sprint-Backlock)
    • Sprint 1-4 Wochen
      • in einem Sprint arbeiten die Mitarbeiter ungestört an dem Sprint Backlog
    • Daily Scrum:
      • Besprechung was getan wurde, was getan wird, gab es Probleme
      • das was ich gestern gesagt hab und was ich am nächsten Tag geschafft habe, sollten optimalerweise zusammenliegen
    • Scrum-Master: Hat die Scrum-Skillz, hält Probleme vom Team fern
    • Sprint-Retrospektive:
      • was hat gut, was nicht so gut geklappt?
    • Sprint-Review:
      • präsentiere Sprint dem Product-Owner
      • neue Features, oder eilige Sachen können nun hinzugefügt werden
    • Burndown-Chart:
      • x: Zeit, y: Story-Points
    • Definition of Done:
      • wenn der Entwickler sagt: es ist fertig

nach oben

Kanban

(nicht wirklich Agil?)

Design Implementation Test
X
  • Pol-Prinzip (nur einer kann an einem Ticket arbeiten)
    • Man holt sich das Ticket, es wird einem nicht gegeben
  • Kaisen (Ständiger wille zur Optimierung)
    • z.B. 2 statt einem Implementationsstrang ... (besser aufteilen ...)
    • z.B. Tester überfordert - 2. Tester dazunehmen
  • Cost-of-Delay (also die Tickets priorisieren, die bei delay am teuersten sind)
    • gleichgroße Happen machen (damit man sie besser gleichzeitig abarbeiten kann)

nach oben

Microsoft-Modell

  • bla

nach oben

About

Zusammenfassung Skript

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

 
 
 

Contributors