Software Engineering - Requirements

Allgemeines

Hilfreiches

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:
    1. Beschreibung
    2. Voraussetzungen und Annahmen
    3. Funktionskriterien
    4. Einflussfaktoren
    5. Beispiel
    6. 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

Enter your comment (wiki syntax is allowed):
PAMOF
uni/mitschriften/sereq.txt · Last modified: 2008/03/26 12:35 (external edit)