====== Software Engineering - Requirements ======

===== Allgemeines =====

  * Homepage: http://www.st.informatik.tu-darmstadt.de/static/pages/lectures/se/ws05-06/re/index.jsp
  * Letzte Vorlesung: 8.12.
  * Klausur: 12.12.

===== Hilfreiches =====

  * Definition Pflichtenheft: http://www.sts.tu-harburg.de/~r.f.moeller/lectures/se-ss-05/04-Definition.pdf
  * http://www.informatik.uni-mannheim.de/pi4/lectures/ss2001/pm/dokumente/vorlagen/pflichtenheft.html
  * http://www.fachkonzept.de/downld.htm
  * [[http://www.checkliste.de/informationstechnik/anforderungsprofile-pflichtenhefte-lastenhefte/|Anforderungsprofile Pflichten/Lastenhefte]]

===== 27.10.2005 =====

  * Pascal aus Algol, nachdem Algol68 nicht wirklich zu gebrauchen
  * Spezialentwicklung fuer damals aufkommende Mikrocomputer
  * Prozess-Periode: kleine Programme, Korrektheit noch durch Verstaendnis pruefbar
  * Formale Periode: Korrektheit durch Berechnung
  * Leitidee Dijkstra: Man muss zuerst wissen, was das Programm tun soll
  * Strukturierte Programmierung ab 1982
  * saubere Programmierung bei manchen Programmiersprachen schlichtweg unmoeglich (z.B. nur eine Answeisung bei if => daraus resultierende goto-Schlachten)
  * "GOTO considered harmful" -> grundsaetzliche Konstruktion der Sprache = Bloecke mit Ein- und Ausgang
  * frueher Abbildung auf vorgegebene Datenstrukturen
  * dann Objektorientierung: Definition der **Funktion**
  * Beherrschung der Komponenten: AUfgabe ist Verdrahtung vorhandener Komponenten
  * Programme frueher selten korrekt, Zeit/Kostenabschaetzungen falsch
  * Anforderungsanalyse: Fehlertraechtig, richtig verstanden? Realisation korrekt?
  * Dahl/Nygaard: 1967 OOP erfunden, aber kein Durchbruch
  * Dijkstra/Hoare/Wirth: OOP (unabhaengig von und spaeter als Dahl/Nygaard, Durchbruch)
  * Parnas: Geheimnisprinzip (definierte Schnittstellen, wurscht was innen ablaeuft)
  * Ritchie/Thompson: C
  * Kay: UI
  * Booch: Spezifikation und Umschreibung von OOP => **UML**
  * Jacobson: skandinavisches Modell, Nutzer muss mitbestimmen, iterative Releases, Rational Unified Process
  * Gamma et al: Design Patterns
  * Pflichtenheft definiert auch Qualitaetsmerkmale der Software
  * Fehlerursache <-> Fehlerwirkung zu diskrepant bei selbstmodifizierendem Quellcode, darum Pfui
  * Wissenschaft: Menge von Methoden um ein Ziel so zu erreichen, wie es auch geplant war (Ingenieurswissenschaft)
  * nicht praezise
  * keine partielle Ordnung zw. Loesungen, kein "richtig"
  * Kunde mit Test zufrieden -> Kunde mit Programm zufrieden: geht nicht, da zuviele Tests
  * Chancen in Sekundaerbranche hoeher als in Primaerbranche
  * Outsourcing grosses Problem (Stellenabbau)

===== 3.11.2005 =====

  * Pflichtenheft: Merkmale, Indikatoren, Prozess
  * jeder testet sein eigenes Modul -> aber auch "globale" Systemtests
  * wichtig -> welche Usecases sieht der Auftraggeber als Erfolgsdefinition an?
  * Daten vom Auftraggeber nötig für Systemtestprogrammierung
  * Meilenstein: Bestimmter Grad von Funktionalität/Korrektheit zu einem bestimmten Zeitpunkt attestiert
  * interne Meilensteine zeitlich etwas vor den offiziellen ansetzen
  * im Pflichtenheft: Anforderungen an Meilensteinen an einzelne Teilnehmer (Coder, Auftraggeber, ...), z.B. Bereitstellung von Daten, Software, Funktionalität
  * "Welche Meilensteine garantieren Sie zu welcher Zeit?"
  * bei Changerequests muss immer ein Kompromiss zwischen Verwertung und Zeit getroffen werden
  * Durchführung nur nach Abwägung und Einigung bzgl. Durchführbarkeit vs. Aufwand vs. Zeit
  * Architektur nicht Ziel von XP, sie entsteht einfach

===== 7.11.2005 =====

  * Pflichtenheft:
    * Leitthema: Projekt planen
    * Planung wird je Iteration besser
    * Zeitplanung und Zeiterhebung
    * Schätzmethode: Function Points 
    * 1. Meilenstein: 1-2 seitiges Paper "Was bringt das Produkt, was gibt es schon?" -> Etwa bis Ende November
    * 2. Meilenstein: 2-3 Seiten Featureliste
    * 3. Meilenstein: Gespräch eingeflossen, 2. Version
  * Divide and conquer
  * heute: Kunde redet mit, inkrementelle Entwicklung
  * Funktionsumfang als einzige wirkliche Variable -> nächste Version
  * Dreiteilung: essentielle, gewünschte, "Kür"-Features
  * Planung: Am Anfang nur schätzen
  * Eichkurven 
  * Zwischenprodukte mit 2-3 Tagen Entwicklungszeiten

===== 10.11.2005 =====

  * "Unterstützung der Zeitplanung und Kontrolle"
    * Zeiterfassung: 
      * Benutzerfreundliche Zeiterfassung
      * Ausgerichtet am Unified Process
      * Adaptierbar bzgl. der Iterationen
    * Zeitplanung:
      * Überprüfung von inTime (z.B. Berechnung von "Leistungsverbesserung" pro Function Point, ...)
      * Verknüpfung mit der Zeiterfassung
  * 1. Geschäftsmodell, 2. Einzelne Schritte
  * ISO-Norm: Ablauf, Qualitätssicherung offen
  * Meilenstein: Wann, was, wer, Wann und wie erfüllt?
  * Projektstrukturplan: Verfeinerung des Produktplanes mit internen Zwishcenprodukten und den zugehörigen Arbeitsprozessen
    * Vorbedingung, Ist-Zustand
    * Anwenderwünsche ermitteln, Doku der gewünschten Funktionen
    * Ergebnis: Liste der geplanten Funktionen (Namen, Kurzbeschreibungen, Status)
  * Function Point, Delphi Methode, Erfahrungsdatenbank

===== 14.11.2005 =====

==== XP in SE ====

  * Refactoring
  * Simple Design: Mach das einfachste was irgendwie funktioniert 
  * Pair Programming: Zwei Leute, ein PC, Vier Augen
  * Coding Standards: Layout, Namenskonventionen
  * Collective Ownership: Jeder darf am ganzen Code Änderungen vornehmen
  * 40h-Week
  * On-site Customer: Sitzt mit im Team, kann immer Entscheidungen treffen -> geht aber praktisch nicht, dass Auftraggeber eigenen Mann während der Durchführung des Projekts fürs Rumsitzen und Fragenbeantworten bezahlt
  * Metaphor: Abstrahierung, Modellbildung
  * Beispiel:
    * Kosten: 5M (8M)
    * Zeit: 31.3.06 (31.12.06)
    * Features: MUMBA (MIMBA)
    * Qualität: 100% (90%)
  * => Darum: Kunde kann nur drei Variablen festlegen, d.h. eigentlich nur zwei, denn Qualität ist nicht verhandelbar
  * schwierig: Erstauftrag
  * Pläne sind im Grunde nutzlos, das Planen ist aber dennoch wichtig (schon allein, um später aus Fehler lernen zu können)
  * Release early, release often
  * Releases = Ausliefern, Iterationen intern
  * user stories: Kleine Funktionalitätseinheiten, nach Möglichkeit unabhängig voneinander, testbar
  * Release Neuplanung => zuviele Tasks, keine Tasks, Gruppenänderungen
  * Grundlagen Schätzungen immer vergangene Ergebnisse
  * Aufschreiben, wie lange für einen Task braucht
  * (Fehl-)Schätzungen = Erfahrung
  * Konstantes Timetracking während der Iteration
  * auch dann releasen, wenn noch nicht alles fertig
  * Testwerkzeug: schnelle Ausführung, umfassend
  * Fortlaufende Integration: Jeden Abend nach erfolgreichem (!) Test => Checkin, wenn broken -> reparieren, dann checkin, IMMER checkin
  * Erst Test, dann richtig coden
  * Test = Doku, definiert Komponente
  * großer Wert auf Kommunikation
  * Mut: z.B. auch mal Rückschritte in Kauf nehmen, um am Ende besser vorwärts zukommen (bsp. Rewrite)
  * Pflichtenheft: Ist, Soll, Stories, Rechtekapitel (Urheber, Vervielfältigung)
  * geplante Releases bzw Milestones
  * Schalenmodell: Core, nette Features, theoretische Konzepte

===== 17.11.2005 =====

==== Abschätzungsverfahren Function Point ====

  * Gliederung:
    - Beschreibung
    - Voraussetzungen und Annahmen
    - Funktionskriterien
    - Einflussfaktoren
    - Beispiel 
    - Fazit
  * erdacht von Allan Albrecht, IBM
  * schnelle effiziente Abschätzung des Projektaufwands
  * vorher: LOC-Verfahren
  * beruht auf Schwierigkeit/Umfang
  * Analyse des Projekts in seiner Gesamtheit -> Pflichtenheft!
  * Funktionen des Projektes klassifiziert in leicht, mittel, komplex
  * Summe der Funtion Points -> abstrakte Zahl, nach Erfahrung Aussage über AUfwand in Mitarbeitermonaten (MM)
  * Erfahrung fürht zu besserer Klassifikation
  * -> Functionpointkurve erstellen, iterativ warten
  * Projektanfang -> Klassifizierung -> Analyse von __Aufwand__
  * Voraussetzungen:
    * Lastenheft, genaue Anforderungen!
    * aus Sichtweise des Auftraggebers
    * Bewertung durch erfahrene Mitarbeiter
    * Auswertende (Punktevergeber) -> kein Detailwissen über Verfahren, sonst Beeinflussung des Ergebnisses
  * Kriterien: Eingaben, Ausgaben, Anwenderdateien, Referenzdateien, Abfragen
  * Eingaben:
    * Transaktionen, Abfragen mit vielen Zwischenschritten
    * Bildschirmeingaben, CD-ROM, sequentielle Datenbestände, Belegleser, ...
    * Klassifikation -> Tabelle
  * Ausgaben
    * bereitgestellte Daten
    * Bildschirmausgaben, Fehlermeldungen, Abfragen mit vielen Verarbeitungsschritten
  * Anwenderdateien
    * Datenbanken, Tabellen, Textfiles, ...
  * Referenzdateien
    * externe Informationsträger, unveränderbar
    * Server, Festplatten, ...
    * Anfragen -> Daten
    * Kundendatenbank, Textdateien
  * Abfragen
    * Suchen nach Informationen
    * viele Zwischenschritte -> Ein/Ausgabe!
    * Ermittlung von Kundendaten, Austausch von Daten mit anderen Anwendungen, ...
  * Schlüsselwörter => Folien
  * unterschiedliche Gewichtung je Kriterium
  * Grad des Einflusses -> Skala 0-5
  * Einflussfaktoren
    * Verflechtung mit anderen Systemen
    * dezentrale Verwaltung/Verarbeitung
    * hohe Transaktionsrate
    * komplexe Rechenoperationen, umfangreiche Kontrollverfahren, viele Ausnahmeregelungen, komplexe Logik
    * Wiederverwertbarkeit -> je mehr desto schwerer
    * Datenbestandskonvertierungen -> Maßnahmen bei Entwurf, Programmierung und Systemtests
    * Vereinfachung des Wechsels bei Änderungen -> variable Logik u.ä. => Erweiterungsfähigkeit
  * FP = E1 * (E2/100 + 0.65) (E1 = Summe FP der Kriterien, E2 = Summe FP der Einflussfaktoren
  * Auswertungstabelle FP/MM
  * Nachteil des Verfahrens: Nicht strukturierbar, also keine Gewichtung von Entwicklungsphasen

~~DISCUSSION~~