7. Projektdokumentation Dokumentenarten Inhalte von home.edvsz.hs- · PDF...

Click here to load reader

  • date post

    17-Sep-2018
  • Category

    Documents

  • view

    212
  • download

    0

Embed Size (px)

Transcript of 7. Projektdokumentation Dokumentenarten Inhalte von home.edvsz.hs- · PDF...

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 161

    7. Projektdokumentation

    Dokumentenarten

    Inhalte von Lasten- und Pflichtenheften im OO-Umeld

    Technische Dokumentation

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 162

    Grundstzliches

    Die bentigte Dokumentation hngt stark von der Projektart ab, bei externen Kunden ist Lasten- oder Pflichtenheft oft Vertragsbestandteil Externer Kunde, groes Projekt: sehr viel

    Aufwand notwendig ffentlicher Auftraggeber: hufig detaillierte

    (nicht immer sinnvolle) Vorgaben (V-Modell) Internes Groprojekt: hnlich wie externer Kunde,

    aber flexibler im Verlauf anpassbar Mittleres / kleines Projekt: genau notwendige

    Dokumentation suchen

    Generell Bedenken: Dokumentationserstellung kann langweilig sein, in Groprojekten als Erinnerung wichtig, fr Wartung zentraler Erfolgsaspekt

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 163

    Arten von Dokumenten

    Lastenheft / Pflichtenheft: zentrale Beschreibung, was gemacht werden soll

    Technische Dokumentation, z. B.: Designmodell, Software-Architektur, Design-Entscheidungen

    QS-Handbuch: was muss wann von wem wie geprft werden, wann ist Prfung erfolgreich

    Werkzeughandbuch: wie, was nutzen, welche Einstellungen Projektdokumentation: Projektplne, Risikobehandlung,

    Projektlogbuch Programmdokumentation (typisch mit Dokumentengenerator

    aus Quellcode) Nutzungshandbuch / Installationshandbuch

    projektabhngig festlegen, was noch/nicht bentigt wird

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 164

    Lastenheft oder/und Pflichtenheft

    Lastenheft: Auftraggeber beschreibt, was er wnschtDas System soll die Frage aller Fragen suchen

    Pflichtenheft: Auftragnehmer beschreibt, was er machtDas System muss (oder wird) die Frage aller Fragen suchen

    Frage: wer entwickelt Hefte Wenn Auftraggeber und Auftragnehmer feststehen,

    kann Pflichtenheft inkrementell entwickelt werden Pflichtenheft teilweise mit UML fllbar Schwierig: Beim Auftraggeber keine Informatiker

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 165

    Lastenheft / Pflichtenheft

    Struktur [nur ein Vorschlag]0. Administrative Daten: von wem, wann genehmigt, ...1. Zielbestimmung und Zielgruppen

    In welcher Umgebung soll das System eingesetzt werden?Was soll das System lsen, welche Stakeholder betroffen?

    2. Funktionale AnforderungenProduktfunktionen (Anforderungen)Produktschnittstellen

    3. Nichtfunktionale AnforderungenQualittsanforderungenweitere technische Anforderungen

    4. Lieferumfang5. Abnahmekriterien6. Anhnge (insbesondere Glossar)

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 166

    Beispielinhalte Pflichtenheft (0/5)

    Versionshistorie: Dokumenten-ID + Bezeichnung Versionsnummer Grund der neuen Version Ersteller Zustand (z. B. in Bearbeitung, eingefroren zur

    Prfung, freigegeben, veraltet) Bei Freigaben: von wem, evtl. mit rechtverbindlicher

    Unterschrift

    Versionsmanagement: technisch + Aktenschrank

    0. Administrative Daten

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 167

    Beispielinhalte Pflichtenheft (1/5)

    Zentrale Aussage: In welcher Situation soll das neue System mit welchen Zielen entwickelt werden

    Nennung der StakeholderDefinition: Jemand der Einfluss auf die Anforderungen hat, da er vom System betroffen ist (Systembetroffener)

    Nennung der Ziele des Systems: Was soll fr welche Stakeholder erreicht werden

    Beschreibung der funktionalen Ziele durch Use Cases (Diagramm + Dokumentation)

    1. Zielbestimmung und Zielgruppen

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 168

    Beispiel: Use Case-Diagramm

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 169

    Beispielbeschreibung (1/2)

    Handbuch zur Fhrung von Projekten des KundenReferenzen

    Lisa Leitung (zentrale Ansprechpartnerin des Kunden)Fachverant-wortlicher

    Projektbro (startet Use Case durch Auswahl der Funktionalitt im zu erstellenden System)

    beteiligte Aktoren(Stakeholder)

    Mitarbeiter des Projektbros haben die Mglichkeit, Projekte mit Teilprojekten anzulegen und zu bearbeiten.

    Kurzbeschrei-bung

    1.0, 30.01.2008, ErstellungVersion

    Ali AnalytikerAutor

    -Paket

    U1Nummer

    Projektstruktur bearbeitenName des Use Case

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 170

    Beispielbeschreibung (2/2)

    sehr hoch, System macht ohne Funktionalitt keinen Sinn

    Kritikalitt

    Nutzer kann existierendes Projekt auswhlen,Nutzer kann Daten eines Teilprojekts ndern

    alternative Ablufe

    1. Nutzer whlt Funktionalitt zur Bearbeitung von Projektstrukturen2. Nutzer legt Projekt mit Projektstandarddaten an3. Nutzer ergnzt neue Teilprojekte4. Nutzer verlsst Funktionalitt

    typischer Ablauf

    Neue Projekte und Teilprojekte sowie nderungen von Projekten und Teilprojekten wurden vom System bernommen.

    Nachbedingun-gen

    Die Software ist vollstndig installiert und wurde gestartet.

    Vorbedingun-gen

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 171

    Beispielinhalte Pflichtenheft (2/5)

    Systematische Aufzhlung einzeln nachprfbarer Funktionen (jede Anforderung hat eigene ID, ist getrennt lesbar, berprfbar)

    Ansatz: Verfeinerung der Use Cases durch Aktivittsdiagramme; Przisierung der Aktivittsdiagramme durch Text

    Aktivittsdiagramme werden inkrementell entwickelt; erst typischer Ablauf, dann Alternativen ergnzen

    In der Dokumentation steht nur Ergebnis Literatur: C. Rupp, SOPHIST GROUP, Requirements-

    Engineering und Management, Hanser Fachbuchverlag, 2004

    2. Funktionale Anforderungen

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 172

    Beispiel: Aktivittsdiagramm mit typischen Ablauf

    Anmerkung: typischer Ablauf ist immer einfache Sequenz von Aktionen, Ausnahme wie hier: einfache Schleifen

    Use Case: Projektstruktur bearbeiten

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 173

    Beispiel:Aktivittsdiagramm um Alternativen ergnzt

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 174

    Rupp: Anforderungsformulierung

    muss

    soll

    wird

    das System

    -

    dieMglichkeitbieten

    fhig sein

    Typ 1

    Typ 3

    Typ 2

    Typ 1: Selbstndige Systemaktivitt, System fhrt Prozess selbstndig durch, z. B. Berechnung des bisherigen Aufwandes eines Projekts durch Abfrage aller Teilprojekte und ErgebnisanzeigeTyp 2: Benutzerinteraktion, System stellt Nutzer die Prozessfunktionalitt zur Verfgung, z: B. Verfgbarkeit eines Eingabefeldes, um den Projektdaten einzugebenTyp 3: Schnittstellenanforderung, d. h. das System fhrt einen Prozess in Abhngigkeit von einem Dritten (zum Beispiel einem Fremdsystem) aus, ist an sich passiv und wartet auf ein externesEreignis, z. B. Anfrage einer anderen Brosoftware nach einer bersicht ber die laufenden Projekte annehmen

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 175

    Beispielbersetzung

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 176

    Beispielinhalte Pflichtenheft (3/5)

    Vom System geforderte Eigenschaften, die fr Erfolg erfllt sein mssen

    Achtung! Hier kann jede Anforderung ein KO-Kriterium fr das Projekt sein (z. B. Reaktionszeit, Ergonomie)

    Achtung! Hier werden gerne Normen zitiert (z. B. wie in Anforderungen an die Dienstqualitt 8DIN EN ISO 66272) beschrieben); diese Normen sind damit vollstndig Vertragsgegenstand

    Bei Erstellung hilft wieder Vorlagennutzung (z. B. aus V-Modell XT)

    3. Nichtfunktionale Anforderungen

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 177

    Definition: Anforderungen an die Dienstqualitt

    Mit Anforderungen an die Dienstqualitt (quality of service) sind Anforderungen gemeint, die Angaben ber das Wie einer anderen, meist funktionalen Anforderung oder des gesamten Systems enthalten. Manchmal werden sie auch Dienstgte-Anforderungen oder Constraints genannt. Die DIN EN ISO 66272 unterteilt die Dienstgte in die fnf Merkmale Zuverlssigkeit. Benutzbarkeit, Effizienz, nderbarkeit und bertragbarkeit. Sie beschreibt alle mglichen Aspekte der Dienstqualitt von Systemen praxistauglich und ordnet sie berschneidungsfrei in einem hierarchischen Schema an.

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 178

    Beispiele: Anforderungen an die Dienstqualitt

    Das System muss sich im Falle des Auftretens eines Fehlers der Kategorie 1 innerhalb von 20 Stunden wieder auf vollem Leistungsniveau befinden.

    Das System muss jede Einzelanfrage an den Bestand der Zentralbibliothek innerhalb von 30 Sekunden ausfhren.

    Wenn ein Fehler der Kategorie 2 oder 3 auftritt, muss das System den Benutzer auf mgliche Ursachen hinweisen.

    Das System muss die Hupe so verwenden, dass diese ihre volle Lautstrke von 112 Dezibel innerhalb von 30 Millisekunden erreicht (Attack-Time).

  • Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 179

    Definition: Anforderungen an Benutzungsschnittstelle

    Unter Anforderungen an die Benutzungsschnittstelle ist einerseits zu verstehen, was blicherweise unter Mensch-Maschine-Schnittstelle verstanden wird. Also Form und Funktion von Ein- und Ausgabe-Gerten, die dem menschlichen Benutzer die Interaktion mit dem System ermglichen. Andererseits knnen auch angrenzende Systeme ber eine Benutzungsschnittstelle mit dem zu entwickelnden System verbunden sein, wenn der Zweck diese zu Benutzern macht. Das ist zum Beispiel bei reinen Infrastruktur- oder Middleware-Systemen der Fall, bei denen das S