Einführung in Software Engineering

Einführung in Software Engineering
1) Kap. 1 Einführung
a) Probleme beim Software Engineering
• Kommunikationsprobleme mit dem Anwender
• Software immateriell und nicht durch physikalische Gesetze begrenzt
Modellbildung schwierig
• einfache Modifizierung
(1) Anforderungsänderung während Entwicklungszeit
• Software Verschleißt nicht, altert aber
(1) Wartungsproblem
• verschiedene Plattformen
(1) Portabilitätsprobleme
• Variantenvielfalt
• Akzeptanzprobleme
(1) „Das machen wir schon seit 30 Jahren auf dem Papier“
• Mängel an Standards, Methoden und Werkzeuge
b) Definition Software
• Gesamtheit oder Teil der Programme, welche für Rechnersysteme entwickelt wurden
• ermöglichen zusammen mit Rechensystemeigenschaften:
(1) Betrieb der Rechensysteme
(2) Nutzung zur Lösung gestellter Aufgaben
(3) zusätzliche Betriebs‐ und Anwendungsarten der Rechensysteme
(4) zugehörige Dokumentation ist Software‐Bestandteil
c) Hauptprobleme Softwareentwicklung
• kontinuierlich steigende Kosten für Software
• kontinuierlich steigende durchschnittliche Projektgröße (bei konstanter Projektdauer)
• geringe Produktivität der Softwareentwickler
(1) mangelnde berufliche Qualifikation
(2) unzulängliche Arbeitsumgebungen
• große Fehlerhäufigkeit
• hoher Wartungsaufwand
d) Merke:
• für Entwicklung großer Softwareprodukte mit vielen LOC braucht man andere
Vorgehensweisen als zum Lösen kleiner Übungsaufgaben
• Softwaretechnik (Software Engineering) verhält sich zur Informatik (Computer Science)
wie die Elektrotechnik zur Physik
2) Kap. 2 Qualitätsmerkmale
a) Softwarequalitätsmerkmale
• Ziel ist effiziente Entwicklung messbar qualitativ hochwertiger Software die:
(1) korrekt und zuverlässig arbeitet
(2) robust auf Fehleingaben, Hardwareausfall usw. reagiert
(3) effizient (ökonomisch) mit Hardwareressourcen umgeht
(4) benutzerfreundliche Oberfläche besitzt
(5) wartbar und wiederverwendbar ist
• Unterscheidung zwischen interner‐ und externer Qualitätsfaktoren
• Achtung: Unterschied Qualität Softwareentwicklungsprozess
b) Korrektheit
• Software ist funktional korrekt, wenn sie sich genauso verhält, wie in
Anforderungsdefinition festgelegt relativ
c) Zuverlässigkeit

• Maß für Wahrscheinlichkeit das sich Softwaresystem in bestimmtem Zeitraum wie
erwartet verhält.
• Metriken zur Zuverlässigkeitsbewertung
(1) „rate of failure occurence“ (ROFOC) : Häufigkeit von nicht erwartetem Verhalten
(2) „mean time to failure/ between failures“ (MTTF/MTBF): mittlerer Zeitabstand
zwischen zwei Fehlern
(3) „availability“ (AVAIL): mittlere Verfügbarkeit der Software
d) Verfügbarkeit
• quantifizierbarer Teilaspekt der Zuverlässigkeit
e) Robustheit
• Software ist robust wenn sie auch unter unvorhergesehenen Umständen funktioniert
f) Wartbarkeit
• Änderungen an Software aufgrund von Fehlern oder geänderter Anforderungen
• Wartbarkeit bedeutet:
(1) Lokalisierbarkeit und Behebbarkeit von Fehlern
(2) Anpassbarkeit
(3) Portabilität
• jede Wartung reduziert die Wartbarkeit bis Software nicht mehr änderbar ist.
g) Portierbarkeit
• System ist portierbar wenn es ohne großen Aufwand auf verschiedenen Umgebungen
läuft.
• Erreichbar durch:
(1) Trennung (kleiner) umgebungsabhängiger Teile vom Rest des Systems
(2) Verwendung standardisierter (Programmier‐) Sprachen
(3) Verwendung standardisierter (verbreiteter) Betriebssysteme
(4) Verwendung standardisierter Fenstersysteme
h) Kompatibilität
• SW kann leicht mit anderer SW kooperieren
• Wichtig hierbei:
(1) Standards für Schnittstellen und Austauschformate
(2) offene Systeme mit austauschbaren Komponenten
i) Benutzerfreundlichkeit
• Software Ergonomie
(1) Problemangemessenheit
(2) Selbsterklärungsfähigkeit
(3) Konfektionierbarkeit
(4) Erwartungskonformität
(5) Steuerbarkeit
j) Dokumentation
• Benutzerdokumentation
•
•
technische Dokumentation
Entwicklungsdokumentation
Systemdokumentation
k) Effizienz
• Ökonomische Nutzung der Hardware Ressourcen (Rechenzeit, Speicher)
• Effizienzermittlung
(1) theoretische Komplexitätsanalyse (O‐von‐Rechnungen)
(2) Simulationsmodelle
(3) Messungen am realen System (Profiling,..)
l) Effizienz des Softwareherstellungsprozesses
• produktive Softwareherstellung

• möglichst wenig Mitarbeiter, möglichst kurze Zeit, möglichst gute Software
• Produktionszeit Softwarequalität
• Lösung:
(1) Wiederverwendung von Softwarekomponenten
(2) Vorgehensweisen
(3) Einsatz hoher Programmiersprachen
(4) Codegenertoren
• Verbesserung der Prozessqualität
(1) Softwareentwicklungsprozesse sind selbst Produkte deren Qualität überwacht und
verbessert werden muss
(2) bei Softwareentwicklung sind Standards einzuhalten (dokumentiert, nachvollziehbar)
(3) kontinuierliche Anstrengungen um Schwächen zu identifizieren und zu eliminieren
(4) „Gute Prozesse führen zu guter Software“
• Qualitätssicherung mit ISO 9000
(1) prozessorientierter Aufbau
(2) Anwendung auf Produktion und Dienstleistungen
(a) Prüfung des QM‐Handbuchs auf Einhaltung der in Norm geforderten
Anforderungen
(b) Prüfung auf Einhaltung und Umsetzung des eigenen QM‐Handbuchs
(c) „bestanden“ oder „nicht bestanden“
(3) vorgeschriebene Dokumente
(a) Vertrag Auftraggeber – Lieferant
(b) Spezifikation
(c) Entwicklungsplan
(d) Qualitätssicherungsplan
(e) Testplan
(f) Wartungsplan
(g) Konfigurationsmanagement
(4) vorgeschriebene Tätigkeiten
(a) Konfigurationsmanagement
(b) Dokumentmanagement
(c) Qualitätsaufzeichnungen
(d) Festlegung
(e) Schulung
(5) Bei Einhaltung aller Kriterien folgt Zertifizierung durch unabhängige
Zertifizierungsstelle
(6) Bewertung
(a) Pro
(i) lenke Aufmerksamkeit des Management auf Qualitätssicherung
(ii) ist gutes Marketing Instrument
(iii) reduziert Produkthaftungsrisiko
(b) Contra
(i) Nachvollziehbarkeit und Dokumentation nicht ausreichend
(ii) keine Aussage über Qualität von Prozessen und Produkten
(iii) teurer bürokratischer Aufwand
(iv) Qualifikation der Zertifizierungsstellen umstritten
(v) große Abweichung zwischen zertifiziertem und realem Prozess
• Capability Maturity Model – CMM
• Referenzmodell zur Beurteilung von Softwarelieferanten
• Softwareentwicklungsprozesse in 5 Reifegrade unterteilt
• Reifegrad entspricht Qualitätsstufe
(1) Stufe 1 – chaotischer ad‐hoc Prozess

(a) Charakteristik
(i) unvorhersehbare Entwicklungskosten, ‐zeit und –qualität
(ii) kein Projektmanagement, nur Künstler am Werk
(b) Verbesserungen
(i) Planung von Kosten und Zeit
(ii) Änderungs‐ Qualitätssicherungsmanagement
(2) Stufe 2 – wiederholbarer intuitiver Prozess
(a) Charakteristik
(i) Kosten und Qualität schwanken, gute Terminkontrolle
(ii) Know‐How einzelner Personen entscheidend
(b) Verbesserungen
(i) Prozessstandards entwickeln
(ii) Methoden für Analyse, Entwurf, Tests … entwickeln
(3) Stufe 3 – definierter qualitativer Prozess
(a) Charakteristik
(i) zuverlässige Kosten‐ und Terminkontrolle, schwankende Qualität
(ii) institutionalisierter Prozess, unabhängig von Individuen
(b) Verbesserungen
(i) Prozesse vermessen und analysieren
(ii) quantitative Qualitätssicherung
(4) Stufe 4 – gesteuerter quantitativer Prozess
(a) Charakteristik
(i) gute statische Kontrolle über Produktqualität
(ii) Prozesse durch Metriken gesteuert
(b) Verbesserungen
(i) instrumentierte Prozessumgebung (mit Überwachung)
(ii) ökonomisch gerechtfertigte Investitionen in neue Technologien
(5) Stufe 5 – optimierender rückgekoppelter Prozess
(a) Charakteristik
(i) quantitative Basis für Kapitalinvestitionen in Prozessautomatisierung und
Prozessverbesserung
(b) Verbesserungen
(i) kontinuierlicher Schwerpunkt auf Prozessvermessung und
Prozessverbesserung (zur Fehlervermeidung)
m) Vergleich ISO 9000 und CMM
• Schwerpunkt in ISO Zertifizierung im Nachweis eines Qualitätsmanagementsystems im
Sinne der Norm
(1) allgemein für Produktionsabläufe geeignet
• CMM konzentriert sich auf Qualitäts‐ und Produktivitätssteigerung der gesamten
Softwareentwicklungsprozesse
(1) auf Softwareentwicklung zugeschnitten
• ISO‐Norm SPICE
(1) Integration und Vereinheitlichung von CCM und ISO
• CMMI als Weiterentwicklung von CMM und Spice
• Spice und CMMI liefern dem Kunden Kennzahlen, mit welcher Qualität er bei seiner
Software rechnen kann weiterhin liefern sie dem Hersteller Informationen über
Schwächen in seinen Prozessen und Verbesserungspotential
n) SPICE – Software Process Improvement and Capability dEtermination
• entspricht ISO/EC 15504
• Vereinhetlicht Assessmentmodelle und –Verfahren
• Prozessmodell
(1) definiert, welche Prozessaktivitäten erforderlich sind für ein bestimmtes Level

(2) Ist Checkliste für Verbesserungen
• Assessmentmethode
(1) Prüft die angewandten Prozesse
(2) Liefert Stärken, Schwächen und Verbesserungsvorschläge
(3) Bestimmt Level für jeden Prozess
Incomplete Performed Managed Established Predictable Optimising
3) Kapitel 3 Vorgehensmodelle
a) Entwicklungsprozess – Vom Konzept zum Vorgehensmodell
• Beispiele Konzepte/ Paradigmen
(1) imperativ
(2) objektorientiert
• Beispiele für Sprachen in Softwaretechnik
(1) natürliche (deutsch, englisch)
(2) formalisierte (UML)
(3) formale (Java)
• Syntax, Semantik und Prakmatik
(1) Syntax – Aufbau / Struktur der Sätze in einer Sprache
(2) Semantik – Bedeutung von Sätzen in Sprache
(3) Pragmatik – Regeln für Umgang mit einer Sprache
• Methoden in der Softwaretechnik
(1) Richtlinien zum Umgang mit einzelnen Sprachen und ggf. Richtlinien zum Umgang
mit einzelnen Werkzeugen für jeweilige Phasen des Vorgehensmodells
(2) Eignung einer bestimmten Methode wird bestimmt durch
(a) Problemangemessenheit
(b) ihre Integrationsfähigkeit
(c) Grad der Vertrautheit der Softwareentwickler mit der Methode bzw. ihre
Erlernbarkeit
(d) Existenz von die Methode unterstützenden Softwareentwicklungswerkzeugen
• Werkzeuge
(1) erzwingen nach Möglichkeit die Anwendung der gewählten Methoden
(2) Arten von Softwareentwicklungswerkzeugen bzw. CASE (Computer Aided Software
Engineering)
(a) Editoren
(b) Prototypingwerkzeuge
(c) Ausführungswerkzeuge
(d) Testwerkzeuge
(e) Programmanalysewerkzeuge
(f) Dokumentationswerkzeuge
(g) Konfigurationsverwaltungswerkzeuge
• Vorgehensmodelle
(1) Darstellung, die den Softwareentwicklungsprozess in idealisierter Form detailliert mit
Regeln zum koordiniertem Einsatz von Werkzeugen, Methoden und Sprachen
beschreibt und auch Analysen des Prozesses gestattet
(2) Prinzipiell muss es dazu die einzelnen Prozessschritte und die dabei verwendeten
und entwickelten Resultate beschreiben
(3) Im Vorgehensmodell sind definiert
(a) Prozessschritte / Aktivitäten
(b) Rollen
(c) Resultate / Dokumente

(4) Vorgehensmodelle bzw. Prozessmodelle strukturieren den Vorgang der Software‐
Erstellung
(a) Definieren Aktivitäten
(b) Legen deren Ergebnisse fest
(c) geben Empfehlungen für Abarbeitung der Aktivitäten
b) Code and Fix Zyklus
• Typisch für 1‐Personen Projekt
(1) Code schreiben und überetzen
(2) Code testen
(3) Code verbessern
(4) GOTO( 2)
• Probleme:
(1) Wartbarkeit und Zuverlässigkeit nehmen kontinuierlich ab
(2) Wenn Programmierer kündigt ist alles vorbei
(3) wenn Entwickler und Anwender nicht identisch gibt es oft
Meinungsverschiedenheiten über erwarteten/realisierten Funktionsumfang
c) klassisches Wasserfallmodell
• Phasen:
(1) Machbarkeitsstudie
(2) Anforderungsanalyse
(3) Systementwurf
(4) Codieren und Modultest
(5) Integration und Systemtest
(6) Auslieferung und Installation
(7) Wartung
(1) Machbarkeitsstudie
(a) Kosten und Ertragsabschätzung
(b) grobe Problemanalyse mit Lösungsvorschlägen
(c) Aufgaben:
(i) Problem beschreiben, Lösungen erarbeiten, Kosten abschätzen, Angebot
erstellen
(d) Ergebnisse
(i) Lastenheft
(ii) grobes Pflichtenheft
(iii) Projektplan
(iv) Angebot an Auftraggeber
(e) Probleme:
(i) zu Projektbeginn nur ungenaue Kosten‐ und Ressourcenabschätzung möglich
(2) Anforderungsanalyse
(a) WAS soll Software leisten
(b) Aufgaben:
(i) Festlegung Systemeigenschaften, Funktionalität, Leistung,
Benutzerschnittstelle, Portierbarkeit … im Pflichtenheft
(ii) Bestimmen von Testfällen
(iii) Festlegung von Dokumentationsdokumenten
(c) Ergebnisse
(i) Pflichtenheft
(ii) Akzeptanzplan
(iii) Benutzerhandbuch (1.0)
(d) Probleme:
(i) bei unklaren Anforderung Erstellung vollständiges Pflichtenheft unmöglich

(ii) Anforderungen früh eingefroren, Wandel nicht ein geplant
(iii) Einbindung des Auftraggebers nur in dieser und der Testphase – Potentielle
Quelle von Missverständnissen / Meinungsverschiedenheiten
(3) Systementwurf
(a) wie werden Softwarefunktionen realisiert? – Softwarebauplan
(b) Aufgaben:
(i) Programmieren im Großen = Bauplan
(ii) Grobentwurf der System in Module zerlegt
(iii) Auswahl von Softwarebibliotheken, Rahmenwerken…
(iv) Entwurf von Modulschnittstellen und Algorithmen
(c) Ergebnisse:
(i) Entwurfsdokument mit Softwarebauplan
(ii) detaillierte Testpläne
(4) Codieren und Modultest
(a) Implementierungs‐ und Testphase
(b) Aufgaben:
(i) Implementierung einzelner Module
(ii) Einhaltung von Programmierrichtlinien
(iii) Code‐Inspektion kritischer Modulteile
(iv) Test erstellter Module
(c) Ergebnisse:
(i) Menge realisierter Module
(ii) Implementierungsberichte (Abweichung vom Entwurf, Zeitplan …)
(iii) technische Dokumentation einzelner Module
(iv) Testprotokolle
(5) Integration und Systemtest
(a) Zusammenbau der einzelnen Module(kann mit (4) verschmelzen)
(b) Aufgabe:
(i) Systemintegration
(ii) Gesamtsystemtest (Alpha‐Test)
(iii) Fertigstellung der Dokumentation
(c) Ergebnisse:
(i) fertiges System
(ii) Benutzerhandbuch
(iii) technische Dokumentation
(iv) Testprotokolle
(d) Probleme:
(i) erste Lauffähige Version der Software erst am Ende der Testphase – späte
Erkennung von Fehlern / Missverständnissen
(ii) Gefahr Projektablaufverzögerungen in Testphaseneinsparungen wieder
aufzuholen
(6) Auslieferung und Installation
(a) Inbetriebnahme beim Kunden
(b) Aufgabe:
(i) Auslieferung an ausgewählte Benutzer (Beta‐Test)
(ii) Auslieferung an alle Benutzer
(iii) Schulung der Benutzer
(c) Ergebnisse:
(i) fertiges System

(ii) Akzeptanzdokument
(d) Probleme:
(i) Pflichtenheft kann nie Umgang mit fertigem System ersetzen –
Risikomaximierung
(ii) Späte Erkennung unerwünschter Funktionen
(7) Wartung
(a) Aufgaben:
(i) ca. 20% Fehler Beheben
(ii) 20% Anpassungen durchführen
(iii) 50% Verbesserungen vornehmen
(b) verschlingt 60% der Softwarekosten
(c) Ergebnisse:
(i) Software Problemberichte
(ii) Software Änderungsvorschläge
(iii) neue Softwareversionen
(d) Probleme:
(i) Wartung mit ca. 60% des Gesamtaufwandes ist eine Phase
(ii) Rückgriffe in andere Phasen notwendig
(8) allgemeine Probleme beim Wasserfallmodell
(a) Phasenmodell als solches gib es nicht – Uneinigkeit bezüglich Phasenanzahl und
Ausgestaltung
(b) Anfang und Ende der Phasen sind zumindest stark idealisiert
d) iterierendes Phasenmodell
• Abwandlung vorheriges Phasenmodell
• ermöglicht Rücksprung in vorherige Phase bei entdecktem Fehler
e) V‐Modell
• im Bundeswehrbereich entwickelt
• regelt Entwicklung, Pflege und Änderungen von Systemen
• Bewertung:
(1) Pro
(a) erfasst auch Systemkomponenten die nicht in Software realisiert werden
(b) Standarddefinition außerordentlich umfangreich mit vielen Teilaktivitäten
(c) Unterstützung von Qualitätssicherung und Konfigurationsmanagement
(d) korrespondierende Phasen des Wasserfallmodells einander zugeordnet
(e) allumfassende Wartungsphase entfällt (zu recht)
(2) Contra
(a) Schwäche der strikten Phaseneinteilung bleibt weiter erhalten

(b) Anwender beklagen zu starke Reglementieung und Papierflut
f) rapid Prototyping
• Entwicklung von Prototypen
• Demonstration/Analysw ausgewählter Merkmale des fertigen Produktes
• Unterteilung in „Wegwerfprototypen“ oder „evolutionäre Prototypenentwicklung“
• Mit Generatoren, ausführbaren Spezifikationssprachen, Skriptsprachen etc. wird:
(1) Benutzerschnittstelle realisiert und dem Kunden demonstriert
(2) anschließend weggeworfen
• Vor‐/Nachteile
(1) Pros
(a) schnelle Klärung der Funktionalität – Risikominimierung
(b) früher Test der Benutzerschnittstelle
(2) Cons
(a) Gefahr der Weiterentwicklung eines Prototypen ‐ ungeplantes evolutionäres
Modell
(b) ggf. erheblicher Mehraufwand
• Bewertung des evolutionären Modells:
(1) Pros:
(a) früh evaluierbarer Prototyp
(b) Kosten‐ und Leistungsumpfang des gesammten Softwaresystems müssen zu
Beginn des Projekts nicht vollständig festgelegt werden
(c) Projektplanung durch überschaubare Teilprojekte vereinfacht
(d) Systemarchitektur muss von vornherein auf Erweiterbarkeit angelegt werden
(2) Cons
(a) Systemarchitektur des ersten Prototypen ist schwer auf später notwendige
Erweiterungen auszulegen
(b) Prototypenerstellungsprozess nicht festgelegt
(c) evolutionäre Entwicklung birgt Gefahr das bereits realisierte Funktionen hinfällig
werden
(d) Endresultat sieht ggf. wie Software nach 10 Jahren Wartung aus
g) Spiralmodell
• gliedert Softwareentwicklungsprozess in nicht festgelegte Anzahl von Zyklen
• jeder Zyklus setzt sich aus vier Schritten zusammen:
(1) Ziele (z.B: erweiterung der Funktionalität)
(2) Alternativen (z.B. unterschiedliche Softwarearchitekturen)
(3) Rahmenbedingungen (z.B. Budget, Termine)
• Realisierung der gewählten Alternative und Überprüfung des Ergebnisses (z.B. duch
Tests)
• Bewertung der Alternativen mit Hinblick auf Ziele und Rahmenbedingungen
• Risikominimierung ‐ z.B. Wegwerfprototyp unter Kostenberücksichtigung
• inhaltliche und organisatorische Planung des folgenden sowie evtl. weiterer Zyklen
• bewertung des Projektfortschritts nach Abschluss eines Zyklus
(1) Entscheidung daraus: Projekt wird
(a) abgeschlossen
(b) abgebrochen
(c) mit nächstem Zyklus fortgesetzt
• Einbettung
(1) in Spiralmodell lassen sich prinzipiell alle bisherigen Vorgehensmodelle einbetten
(2) Vorteil: Verbindung von Flexibilität der evolutionären Prototypenentwicklung mit
guter Beherrschbarkeit des Phasenorientierten Projekts
h) V‐Modell XT
• Weiterentwicklung V‐Modell

• Ergänzugn um
(1) Tailoring (auf konkrete Projekte)
(2) Iteratives Vorgehen
• Grundkonzept
(1) Vorgehensbausteine
(a) Produkte
(b) (verantwortliche) Rollen
(c) Aktivitäten
(2) Produktdurchführungsstrategie, definierte Reihenfolge und Entscheidungspunkte
i) RUP – Rational Unified Process
• Nutzbarmachung erprobter Ansätze zur Softwareentwicklung (best practice)
(1) Develop software iteratively
(2) Manage requirements
(3) Use componented‐based architectures
(4) visually model software
(5) verify software quality
(6) control changes to software
• Definition von Workflows, die parallel und in Phasen ablaufen können
• Iterationen und inkrementelle Verbesserungen sind in jeder Phase möglich
• Grundkonzept bei Definition der Workflows:
(1) Workers führen Aktivitäten durch deren Ergebniss ein Artefakt ist
(2) Zur Gestaltung der Artefakte werden Guidelines und Templates zur Verfügung
gestellt
• RUP kennt 4 Phasen
(1) Konzeptionalisierung: Planungs‐ Entscheidungsgrundlagen schaffen
(2) Entwurf: Erfassung der Anforderungen
(3) Konstruktion und Realisierung – Stabiles Produkt zur Auslieferung
(4) Einführung und Betrieb
j) leichtgewichtige Prozessmodelle – light‐weight processes
• herkömliche Standards werden verworfen weil:
(1) sehr starr
(2) produzieren unmengen an Papier
(3) binden nutzlose Arbeitskräfte
• sollen sinnlosen bürokratischen Overhead vermeiden
• Extreme Programming (XP) – best practices der Programmierung
• Agile Prozessmodelle:
(1) herkömmliche Prozessmodelle auf das unbedingt notwendige zurückschneiden
(2) situationsbedingt, flexibel und schnell voranschreiten
• Agiles Manifest
(1) Einzelpersonen und Interaktionen wichtiger als Prozesse und Werkzeuge
(2) Laufende Systeme wichtiger als umfangreiche Dokumentation
(3) Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlungen
(4) Fähigkeit auf Änderungen zu reagieren wichtiger als Verfolgen eines Plans
• Guidelines von XP
(1) Verzicht auf Phasen
(2) keine eigenständige Analyse‐ oder Designaktivitäten vor der Codierung
(3) keine Erstellung getrennter Dokumentationsdokumente, Modelle etc.
(4) großes Gewicht auf Testplanung
(5) Test werden vor oder zusammen mit Code geschrieben
(6) durchlaufen aller Tests nach jeder Änderung
(7) unbedingtes Einhalten der 40‐Stunden Woche
(8) Auftraggeber soll permanent neue Anforderungen aufstellen und priorisieren

(9) Kunde wird Teammitglied
(10) nur Aufgaben höchster Priorität werden angegangen
(11) sehr kurze Iterationszyklen – häufige Realeases
(12) „Pair Programming“ Teams
• SUBSETS DÜRFEN NICHT XP GENANNT WERDEN
• Randbedingungen
(1) max. 5‐10 Programmierer an einem Projekt
(2) Beschränkung auf rel. kleine Projekte
(3) intensive Kommunikation zwischen Kunde und Programmierern
(4) keine räumlich verteilten Teams
(5) Kunde verzichtet auf separate Software‐Dokumentation
(6) zugunsten ausführlicher Tests die, die Rapid‐Prototyping‐Vorgehensweise
unterstützen
(7) Programmierer versuchen bei Realisierung künftige Realeases nicht zu
berücksichtigen
(8) Programmierer zum ständigen Umbau (Redesign) der bereits erstellten Software
bereit
(9) Prinzip des Refaktorings von Software.
• Bewertung von XP
(1) Pros
(a) Kompromiss zwischen Wirklichkeit der Programmentwicklung und aufwändiger
Vorgehensmodellen
(b) Betonung der Menschlichen Komponente
(c) systematisches evolutionäres Rapid Prototyping
(d) unwesentlich Ansteigende Kosten bei späterer Anfoderungsänderung
(2) Cons
(a) keine Dokumentation
(b) Entwicklung des Gesamtsystems nicht unbedingt sehr Zielgerichtet
(c) Grundannahmen nicht hinreichend empirisch belegt
(d) nur für kleine Projekte, nicht in sicherheitskritischen Anwendungsbereichen
k) Scrum
• egl. Bezeichnung für „angeordnetes Gedränge“ im Rugby
• Bei Projektmanagementprozess steht Team im Mittelpunkt
• Team organisiert sich selbst und bespricht vor nächstem Scrum den geplanten Spielzug
• Wichtige Konzepte/Begriffe
(1) Burndown Chart
(a) graphischer Projektfortschritt eines Produktes, Sprint oder Releases
(b) gibt den übrigen Arbeitsaufwand an
(2) Chicken
(a) am Projekt interessierten aber nicht an Umsetzung und Projektrisiko beteiligte
Person
(3) Pig
(a) direkt am Projekt beteiligte Person welche auch Risiko trägt
(4) (Produkt‐) Backlog
(a) Priorisierte Liste mit zeitlichen Schätzwerten für Fertigstellung (in
Personentagen)
(5) Produc Ower
(a) für Pflege des Backlogs verantwortliche Person
(6) Sprint
(a) Zeitspanne, in der das Team versucht alle Ziele aus der Sprint‐Planungssitzung
umzusetzen
(b) in der Zeit keine Anforderungsänderungen von außen

(7) Sprint Backlog
(a) Aufgabenliste für einen Sprint
(b) täglich vom Team präzise geführt
(8) Sprint Rewiev Meeting
(a) Sitzung am Ende eines Sprints
(b) Vorstellung fertiger Funktionalitäten – keine Dummies oder Grafiken
(9) Scrum‐Master
(a) Für Scrum‐Prozess verantwortliche Person
(b) sorgt für korrekte Implementierung und maximalen Nutzen des Prozesses
(c) sollte keine Doppelfunktion als Teammitglied haben
(d) sollte kein Vorgesetzter sein
(e) kein Projektleiter im herkömmlichen Sinne – eher Vermittler, Unterstützer
l) V‐Modell XT
• Weiterentwicklung des V‐Modells
• Erlaubt „Agile Projektdurchführungsstrategie“
4) Kap 4. Requirements Engineering
a) Durchführungsprüfung von Software Projekten
• ökonomische, fachliche, personelle Durchführung prüfen
• Unterscheidung zwischen Softwareprojekten:
(1) für konkreten Auftraggeber
(a) Was genau will dieser?
(2) anonymer Markt
(a) Bedarf und Rentabilität klären
• Ökonomische Durchführbarkeit (Machbarkeitsstudie)
(1) ROI‐Return on Investment Softwareentwicklung muss sich lohnen
(2) Trifft nicht zu bei:
(a) Änderungen aufgrund neuer gesetzlicher Bestimmungen
(b) Ablösung veralteter Technologie
(3) Problem bei Kostenabschätzung
(a) Was soll man alles berücksichtigen – Schulungen, Krankheit …
(4) Problem bei Nutzenabschätzung
(a) Was bringt es wenn Mitarbeiter besser auf Informationen zugreifen können
(5) Bestandteile einer Machbarkeitsstudie
(a) Lastenheft: grobe Auflistung fachlicher Anforderungen des Auftraggebers
(b) Projektkalkulation: geschätzte Kosten für Softwareprodukt
(c) Projektplan: Zeitplan für Projektdurchführung, mit Phasen, Phasenergebnissen
und Verantwortlichen
(d) Große Probleme:
(i) wie ist Umfang/Größe eines Softwareprodukts definiert?
(ii) wie lässt sich Produktumfang ohne Betrachtung der Realisierung schätzen?
(iii) in welchem Verhältnis stehen Produktumfang, Entwicklungszeit und –
kosten?
• Ermittlung von Anforderungen (Anforderungsanalyse)
(1) Needs – Problembeschreibung/ Warum die Software
(2) Features – Lastenheft mit Hauptfunktionen
(3) Software Requirements = Pflichtenheft – detaillierte Beschreibung der
Softwarefunktionen
(4) Fast ein Drittel bis zur Auslieferung nicht entdeckter Fehler sind Analysefehler,
dessen Beseitigung sehr teuer ist.
(5) Arten von Anforderungen
(a) funktionale Anforderungen: primäre Funktionen und Ein‐ Ausgabeverhalten
(b) nichtfunktionale Anforderungen:

(i) Produktanforderungen: BENUTZARKEI; Effizienz, Zuverlässigkeit,
Portierbarkeit
(ii) Unternehmensanforderungen: Lieferung, Umsetzung, Vorgehen
(iii) Externe Anforderungen: Kompatibilität, Datenschutz, Recht, Ethik
• Techniken zur Anforderungsanalyse
(i) Bestimmung Interessengruppen – Durchführung von Interviews
(ii) Anforderungen aus verschiedenen Sichten – Viewpoints
(iii) Workshops mit Brainstorming oder Storyboard mit allen Interessengruppen
(iv) Anforderungsfälle (typ. Funktionsabläufe) ermitteln und ggf. Roleplay
(1) Stakeholders eines Softwareprodukts
(i) meist verschiedenen Personengruppen mit unterschiedlichen (evtl.
widersprüchlichen ) Interessen betroffen
(ii) Erhebung der Anforderung aller Stakeholders
(iii) schlichten von Konflikten als Aufgabe des Softwareentwicklers
(2) Interviews mit Interessengruppen
(a) Domain‐Analyse der Umgebung
(b) Antworten auf folgende Fragen erwünscht:
(i) Profil des Kunden (Aufgaben, Produkte, Erfolgsmaße)
(ii) Probleme des Kunden (welche Abläufe sind ineffizient, fehlerträchtig etc.)
(iii) Umgebung des Kunden ( Benutzer, Hardware, Plattform)
(iv) erwartete Softwareeigenschaften (Funktionen, Zuverlässigkeit, Support)
(3) Viewpoint‐getriebene Anforderungsanalyse
(a) durch Interessengruppen definierte Sichten auf System sind effektives Hilfsmittel
Anforderungsanalyse zu organisieren
(b) andere Sichten sind:
(i) Orientierung an Funktionsgruppen
(ii) Orientierung an Phasen oder Notationen der Softwareentwicklung
(c) Phasenorientierte Sichten
(i) Customer View
(ii) Application View
(iii) Functional View
(iv) Conceptual View
(v) Realization View
(4) Branstorming Workshop
(a) Alle vom Softwareprodukt betroffenen Personengruppen nehmen an zwei
Tägigem Workshop teil
(b) Phasen des Workshops
(i) verschicken von vorab Material zur Vorbereitung/Einstimmung
(ii) Ideen sammeln
1. Darstellung am White Board
2. Kritik und Ergänzungen erwünscht
(iii) Ideen gruppieren und daraus Funktionen der Software bestimmen
(iv) sortieren der Funktionen nach Priorität
(5) weitere Methoden
(a) folgende Techniken versuchen die wichtigsten Funktionsabläufe der Software
durchzuspielen
(i) Anwendungsfälle (Use Case& Misuse Case)
(ii) Storyboarding ‐ spielen mit GUI
(iii) Rollenspiele – Person = Rolle
• Aufbau und Funktion eines Lastenheftes
(1) Zielbestimmung
(2) Produkteinsatz
(3) Produktfunktionen

(4) Produktdaten (gespeicherte Hauptdaten)
(5) Produktleistungen (besondere Anforderungen an Hauptfunktion oder Hauptdaten)
(6) Qualitätsanforderungen
(7) Ergänzungen
(8) Glossar
• sonstige Eigenschaften des Lastenheftes
(1) Adressaten
(2) Form
(3) Inhalt
(4) Erstellungszeitpunkt
(5) Umfang
(6) Kategorisierung der Funktionen Daten und Leistungen
(a) absolut notwendig (primary)
(b) ziemlich wichtig (secondary)
(c) Schnickschnack (optional)
• Weitere übliche Attribute für Anforderungen
(1) Status
(2) Nutzen
(3) Aufwand
(4) Risiko: Wsh unerwartete/ unerwünschte Probleme
(5) Stabilität: Wahrscheinlichkeit von Anforderungsänderungen
(6) Release: Welches Release muss welche Funktion haben
(7) Grund: Konkreter Nutzen der Realisierung
• Probleme mit Kundenbeschreibung
(1) keine Aussage warum Geschäftsprozess durch Software unterstützen will
(2) enthält mehrdeutige Begriffe
(3) irrelevante Aussagen
(4) unvollständig
(5) keine Festlegung der Systemgrenzen
(6) enthält nur Aussagen über funktionalen Ablauf (Datenmengen, Antwortzeiten etc.
fehlt)
• Konsequenz für Erhebung von Anforderungen
(1) aus natürlich sprachlichen Anforderungsdefinition alle wichtigen Wörter
heraussuchen
(2) für wichtige und/oder unklare Begriffe Glossar anlegen
(3) Unterstützung durch UML
b) Aufwands und Kostenabschätzung
• Kosten und Entwicklungsauer werden wesentlich durch personellen Aufwand bestimmt
(1) Indikatoren hierfür sind Umfang und Qualität
(2) Übliches Maß für Personalaufwand
(a) Mitarbeitermonate MM
(b) Mitarbeitermonate MJ (10MM = 1MJ)
(3) Übliches Maß an Produktumfang
(a) „Lines of Code“ (LOC)– schlecht
(b) „Function Points“ (FP)
• Schätzverfahren im Überblick
(1) Analogiemethode: Vergleich mit älteren Projekten
(2) Prozentsatzmethode: Verteilung des Aufwands auf Phasen anhand alter Projekte
(3) Parkinsons Gesetz: Die Arbeit ist beendet wenn alle Vorräte erschöpft sind.
(a) praxisnah, realistisch, wenig hilfreich
(4) Gewichtungsmethode: Bestimmung vieler Faktoren und Verknüpfung durch
mathematische Formel (Erfahrung der Mitarbeiter, verwendete Sprachen)

c) Projektpläne und Projektorganisation
• Am Ende der Machbarkeitsstudie steht die Erstellung eines Projektplans mit:
(1) Identifizierung einzelner Arbeitspakete
(2) Terminplanung
(3) Ressourcenplanung
• Machbarkeitsstudie ohne grobes Softwaredesign nicht möglich da:
(1) Arbeitspakete ergeben sich aus Softwarestruktur
(2) Abhängigkeiten und Umfang der Pakete ebenso
(3) Realisierungsart der Pakete bestimmt über Ressourcen
• Konsequenz: Projektplanung und ‐organisation ist fortlaufender Prozess. Zu
Projektbeginn ist dies nur grober Plan.
• Abschließende Checkliste
(1) Machbarkeitsstudie soll nur wenige Tage dauern
(2) ggf. Vorprojekt zur Risikoabschätzung
(3) folgende Punkte sind zu klären:
(a) Angaben im Lastenheft mit Kunden abgestimmt?
(b) mit geplanten Ressourcen technisch realisierbar?
(c) vertrauenswürdige Kostenschätzung?
(d) Produktentwicklung wirtschaftlich interessant?
(e) realistischer Zeitplan?
(f) Phasenverantwortliche?
(g) Risikoabschätzung durchgeführt?
d) Hilfsmittel bei Anforderungsanalyse – Modelle/Diagramme
• Eingesetzte klassische Modellierungssprachen
(1) funktionale Aspekte – Verhalten
(a) Datenflussdiagramme
(b) Funktionsbäume
(2) Datenstrukturen
(a) Data Dictionary = Typdefinitionen
(b) Entity‐Relationship‐Diagramme (Klassendiagramm ohne Operationen)
(3) Kontrollstrukturen
(a) Struktogramme (Nassi‐Shneiderman‐Diagramme)
(b) Pseudocode
(4) zustandsbehaftete nebenläufige Systeme
(a) Zustandsübergangsdiagramme (endliche Automaten)
(b) Petrinetze
• Kritik an aufgezählten Modellen
(1) starke Trennung zwischen Daten‐ und Verhaltensaspekten
(a) folgend Konsistenshaltungsprobleme
(2) verschiedene Konzepte und Sprachen in einzelnen Entwicklungssprachen
(a) Konsistenz?
(b) gewünschte Trennung zwischen Analyse und Entwurf wird erzwungen
• Voraussetzung für erfolgreiche Softwaremodellierung
(1) Sprachen mit wohldefinierter Syntax und Semantik
(2) präzise sprachübergreifende Konsistenz‐ und Abbildungsregeln
e) Objektorientierte Modellierungssprachen
• Vielzahl von OO‐Modellierungsdialekten wird durch Standard‐Sprache ersetzt um so
(Idee von Booch)
(1) Vorteile verschiedener Modellierungsansätze zu vereinen
(2) potentiellen Anwendern die Qual der Wahl abzunehmen
(3) Voraussetzungen für Datenaustausch zwischen OO‐Werkzeugen zu schaffen
(4) enge Integration von OO‐Werkzeugen

(5) Abhängigkeit der Anwender von Herstellern reduzieren
(6) Werkzeugherstellern von der Unterstützung verschiedener Ansätze befreien
f) UML Unified Modeling Language
• Pros
(1) Metamodell in Form von Klassendiagrammen legt rel. präzise die Syntax der
unterstützten Diagrammarten fest
• Pro/Con
(1) Semantik der Diagrammarten wird (noch) weitgehend in Prosa erläutert, einige
Konsistenzregeln werden in OCL (Object Constrained Language) definiert
• Cons
(1) es gibt 10 Diagrammarten die teilweise gegeneinander Konkurieren
(2) das Metamodell ist nahezu beliebig erweiterbar, was uns in Zukunft eine Fülle von
UML‐Dialekten mit entsprechenden Werkzeugen bescheren wird
g) Einsatz von UML in der Analysephase
• Ausgangspunkt sind Produktanforderungen des Kunden (entweder als Fließtext oder als
strukturiertes Lastenheft
• Ergebnis ist ein (erweitertes) Plichtenheft mit semiformalen Definitionen der
Produktfunktion und ‐daten als UML‐Diagramme
• Umfang des UML‐Einsatzes umstritten
(1) UML‐Protagonisten
(a) UML als visuelle/graphische Programmiersprache
(b) erstelltes Analysemodell ist (als Prototyp) ausführbar (ausführbares
Pflichtenheft)
(2) UML‐Antagonisten
(a) Pflichtenheft nur in strukturiertem Englisch/Deutsch geschrieben
(b) graphische Sprachen wie UML erst in Designphase einsetzen
h) Produktfunktionen und Anwendungsfälle
• konkrete Beschreibung der Funktionen anhand von Fallbeispielen sog. Szenarien
• Zusammenfassung ähnlicher Szenarien zu sog. Anwendungsfällen
• Vorgehensweise:
(1) Skizze konkreter Benutzungsszenarien mit Akteuren
(2) Identifikation der Grenze zwischen Software und Reality
(3) Skizze der zugehörigen Benutzeroberfläche
(4) bilden von Anwendungsfällen – Use Cases
(5) Überblick über Use‐Cases durch Use‐Case‐Diagramm
• Bestimmung geeigneter Szenarien/ Anwendungsfälle
(1) unterstreichen relevanter Verben im Lastenheft Szenario
Anwendungsfalldiagramm 1.0
(2) kenntlichmachen der Softwareaufgaben – Abgrenzung
(3) Akteure zuordnen – „benutzt“ Beziehung
(a) wenn zwischen Akteur und Use Case unidirektional Daten ausgetauscht werden
erhält die Verbindungslinie eine Pfeilspitze
(b) interagieren mehrere Akteure mit einem Anwendungsfall, ist nicht festgelegt
was das bedeutet (meist: jeder Akteur darf ausführen aber auch: alle Akteure
zusammen dürfen nur die Systemfunktion nutzen)
(c) viele Beziehungen machen Diagramm unübersichtlich
i) Weiter UML‐Verbindungsbeziehungen
• Vererbung (Owner erbt Rechte von Clerk) {Pfeil mit leerer Pfeilspitze}
• extend
(1) beschreibung von Sonderfällen eines Anwenungsfalls separat
(2) hinzufügen von Funktionalitäten zu Anwendungsfällen
• include (use)

(1) bei gleichen Teilabläufen mehrerer Anwendungsfälle Separierung Dieser
(2) Auslagerung von Funktionalität
• Vererbungen nur sparsam einsetzen
j) Ranking von Anwendungsfällen
•