Sie sind auf Seite 1von 2

Anforderungen sollen über Software-Entwicklungsprozess nachvollziehbar bleiben.

Welche Maßnahmen? Technisch: Requirements Management Tools (Rational Requisite


Pro), Modellier Tools (TOGETHER), Configuration Management Tools, Document
Management Tools (SVN), Markterhebungen, Mitbewerberprodukte beobachten;
Organisatorisch: Lastenheft vom Kunden, Bestehende Ablaufbeschreibungen, Milestones
(aktuellen Stand mit Anforderungen vergleichen)
Spezifikationen ändern sich während Projektlaufzeit, Gründe warum? Kunde:
Anforderungen ändern sich, Unklarheiten im Lastenheft, Zeitverzögerung; Intern:
Ressourcen fallen aus, Projekt tlw. nicht umsetzbar, zu kostenintensiv; Interne
Änderungen: zB Programmiersprache
Vorgangsweise für Spezifikationsänderungen, die Stabilität sicherstellen? Interner
Änderungsvorgang: Vereinbarungen mit Kunden treffen, Sammeln von Anforderungen
für Änderungen, Analyse der Auswirkungen auf Termine und Kosten, Abstimmung mit
Stakeholders, Kommunikation mit Projektmitarbeiter, Umsetzen im Projektplan; Externer
Änderungsvorgang: Zurückgreifen auf geklärte Fragen vom Projektbeginn, Wie werden
Änderungen gemeinsam reviewed, &Auswirkungen auf Termine und Kosten behandelt,
&verbindlich gemacht?
Nach Login möchte Bibliothekskunde die Ausleihe für ein bestimmtes Buch verlängern,
beschreiben Benutzersicht zu diesem Anwendungsfall: Buch suchen…findet es, Info dass
es selbst ausgeliehen hat+wann es wieder frei ist, Kunde muss „ab späteren Zeitpunkt
reservieren“ wählen, „abholen“ = behalten; Alternativen: Buch ist anderweitig reserviert
(abholen erst möglich wenn Buch zurückgegeben); Gesperrt: kann nichts
bestellen/verlängern aufgrund von eigenen Buchschulden
Als Projektleiter Risiken finden die das Gelingen eines Projekts gefährden können:
verschiedener Sprachgebrauch, unklare Vorstellungen beim Kunden, wichtige Stakeholder
nicht involviert, Anbieter will innovatives System statt Lösung der Kundenprobleme
URD (User Requirements Document) Inhaltsverzeichnis: Document Abstract, Document
Status Sheet, Document Change Record, Table of Contents, List of Figures, List of Tabes,
Introduction, General Description, Spezific Requirements, List of User Requirements

Iteratives Modell Vorteile: Hohe Flexibilität (nach jeder Iteration können Iterationen
umgeplant werden); geringes Risiko (Zwischenprodukte können nach jeder Iteration
validiert werden) Nachteile: Hoher Management aufwand, Hoher Aufwand für mehrfache
Integration und Testphase; Beschreibung: Die Entwicklung basiert auf groben
Spezifikationen und einem Projekt-Masterplan, das Projekt wird in definierten Iterationen
mit entsprechenden Arbeitsprodukten geplant, Phasen von Spezifikation bis Systemtest
werden in jeder Iteration durchlaufen, Stakeholder können in mehreren Phasen involviert
werden, jede Iteration liefert Produkt das validiert werden kann
Szenario SVN Befehle: Arbeitsversion aktualisieren (svn update), Änderungen in Sourcen
durchführen (svn add, svn delete, svn copy, svn move), Änderungen überprüfen (svn
status, zB $ svn status d:\work), svn diff, svn revert), Fremde Änderungen in
Arbeitsversion einbringen (svn update, svn resolved), Eigene Änderungen ins
Projektarchiv einbringen (svn commit)

Wasserfallmodell – 3 Eigenschaften (Aktivitäten werden sequentiell durchgeführt, jede


Aktivität soll ein Arbeitsergebnis erzielen, Stakeholders sind nur bei Anforderungsphase
dabei); Vorteile (einfach verständlich, geringer Managementaufwand), Nachteile (wenig
flexibel  höheres Risiko, streng, sehr an Dokumentation orientiert); Arten von Projekte:
geringes Risiko, geringer Projektumfang, kurze Entwicklungszeit, geringe
Technologie/Marktdynamik

Configuration Management (CM) Funktionen: Basis Funktionen (Source Dateien


kontrollieren, mehrere Versionen von Komponenten speichern, Komponenten aus/in
Repository aus/einchecken, konsistente Versionen bereitstellen); weitere Funktionen
(Automatisches MERGE erlaubt mehrfach checkout; Versionskontrolle, Verfolgung von
Abhängigkeiten zwischen Files, Änderungskontrolle (wer was wann und Status der
Änderung), Statusreports, Build-Management (Unterstützung von reproduzierbarem
Build), Prozess-Management (Unterstützung von Arbeitsschritten und Abläufen),
Workspace-Management (getrennte Umgebungen für mehrere Entwickler), Repository
Management (Administration und Reports der CM-Datenbank))
Entwicklungstätigkeiten die durch CM unterstützt werden: Definition und Verfolgung
von Prozessen, Dokumentation aller Vorgänge, Versionierung/Konfliktbehandlung,
Verwaltung von Voraussetzungen, Effizienzsteigerungen bei der automatisierten
Applikationserstellung, Zugriffskontrolle
Was ist für jede Phase zu definieren? Erwarteter Input+Startkritieren, Erwarteter
Output+Endkriterien, Aktivitäten, Verantwortlichkeiten
V-Modell (Erweiterung des Wasserfallmodells): integriert Systementwicklung,
Qualitätssicherung, Konfigurationsmanagement und Projektmanagement in einer
geschlossenen Modellstruktur; Verifikation und Validierung sind auf verschiedenen
Ebenen genau definiert; Vorteile (umfassend+detailliert, für große+sicherheitskritische
Produkte), Nachteile (unflexibel, restriktiv in der Entwicklungsmethodik)

Evolutionäre Modell – Iterationen dauert 1-3 Wochen und werden nach Kundennutzen
priorisiert; jedes Ergebnis ist testbar und lauffähig; nach Validierung wird nächste Version
geplant; Vorteile (erhöhte Flexibilität, jede Version bringt Kundennutzen, Kunde kann
nächste Anforderungen anpassen) Nachteile (radikale Änderungen  hohe Kosten)
SVN-Architektur – Lokales Repository (auf lokalem Filesystem), Remote Repository (kein
lokaler Account notwendig, Zugriff via http/HTTPs) Status einer SVN-Datei
(unverändert&aktuell, lokal verändert&aktuell (commit), lokal unverändert&nicht aktuell
(update), lokal verändert&nicht aktuell (merge)); Typischer Arbeitszyklus ( siehe SVN
Befehle)
Nicht beeinflussbare Katastrophen: Fehler die Software-spezifisch sind (es fehlt nicht
inkludierte Software) und die es nicht sind (z.B. Geräteausfall)
Was könnte ein Kunde verlangen (Installation beim Kunden, Katalog mit
Fehlermeldungen, Handbuch, MA-Schulung (kurze Einführung), Testabläufe beim Kunden,
SW+Lizenz, Source, unabhängige Prüfungsstelle, Vereinbarung über Support/Updates,
Fehlerstatistik, Garantie)