Integration eines Wikis in einen Requirements Engineering Prozess

Transkript

1 Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Integration eines Wikis in einen Requirements Engineering Prozess Studienarbeit im Studiengang Mathematik mit Studienrichtung Informatik von Olesia Brill Prüfer: Prof. Dr. Kurt Schneider Betreuer: M. Sc. Eric Knauss Hannover, 24. Oktober 2007

2 i Danksagung Ich möchte mich an dieser Stelle bei all denen bedanken, die mich bei der Erstellung dieser Studienarbeit unterstützt haben. Ein besonderer Dank geht an meinen Betreuer, Herrn M.Sc. Eric Knauss, für die vorbildliche Betreuung meiner Studienarbeit.

3 INHALTSVERZEICHNIS ii Inhaltsverzeichnis 1 Einleitung Motivation Aufgabenstellung Gliederung der Arbeit Grundlagen und Vorgaben Anforderungen Use Cases Ein kritikbasiertes Anforderungswerkzeug - Der DODE Requirements Engineering Requirements Management Herausforderungen des Requirements Management Wiki Prinzipien Anforderungen an ein Wiki Herausforderungen Konzept eines Wikis für das SWP Aufbau des SWPes Gründe für den Einsatz eines Wikis im SWP Testdurchführung SEWiki-Aufbau Softwarepakete Artefakte Konzepte der Programmierung Ausgabe- und Eingabevorlagen Arbeiten mit dem SEWiki Rechtevergabe Integration des Use Case DODE Tutorial 35 5 Zusammenfassung und Ausblick 39 A Use Cases 41 B Aufgaben für den SEWiki-Test 47 C Fragebogen 48 Literatur 52

4 1 EINLEITUNG 1 1 Einleitung 1.1 Motivation Die Anforderungserhebung aber auch der Entwurf sind wichtige Bestandteile eines Software-Projektes. Diese enstehen in Gruppenarbeit und obliegen vielen Änderungen. Sowohl die Anforderungs- als auch die Entwurfsspezifikation müssen in Software-Projekten meist im Word- bzw. pdf-format abgegeben werden, so die Vorgabe. Bei der Gruppenarbeit in Word treten jedoch folgende Probleme auf: (i) Es können nicht gleichzeitig mehrere Teammitglieder an einem Dokument arbeiten, da nur Änderungen einer Person übernommen werden können, und die Arbeit der zweiten Person überschrieben und nicht berücksichtigt wird. (ii) Die Änderungen an dem Dokument werden nicht automatisch markiert, so dass die restlichen Gruppenmitglieder die Änderungen suchen müssen. (iii) Die Historie eines Dokumentes kann in Word nicht gespeichert werden. Wird also im Nachhinein festgestellt, dass bestimmte Änderungen nicht gerechtfertigt sind, so müssen diese nochmal manuell vollzogen werden. (iv) Ein wichtiger Bestandteil des Anforderungsdokuments sind die Szenarien, z.b. die Use-Case-Beschreibungen. Diese werden mit speziellen Programmen erzeugt und dann in Word eingefügt. Sollen diese geändert werden, so müssen sie jedes Mal neu geladen, gespeichert und wiederum im Word- Dokument ersetzt werden. Use-Case-Beschreibungen können auch einfach nur als eine Tabelle in Word erstellt werden, was auch umständlich ist. (v) Bei vielen Änderungen muss Kontakt mit allen Gruppenteilnehmern aufgenommen werden, um die Zustimmung dieser zu bekommen. Eine Art Kommunikationsplattform stellt Word nicht dar. Die bisherigen Werkzeuge unterstützen weder die Versionierung noch die Kommunikation zwischen den Teammitgliedern. Effizientes Arbeiten ist aus diesen Gründen kaum möglich. 1.2 Aufgabenstellung Ziel dieser Studienarbeit ist es, die vorliegenden Probleme der Software-Projekte am Beispiel der Software-Projekte der Informatikausbildung am Fachgebiet Soft-

5 1 EINLEITUNG 2 ware Engineering der Leibniz Universität Hannover, zu lösen. Hierbei soll ein experimentelles Wiki behilflich sein, welches für die Vorentwicklung einer bestimmten Firma erstellt und für diese Studienarbeit zur Verfügung gestellt wurde. Das Wiki-Konzept ist in diesem Zusammenhang ein vielversprechendes Konzept zur Lösung der oben aufgeführten Probleme. Das Wiki soll eine Gruppenarbeit an den Spezifikationen ermöglichen. Um Use-Case-Beschreibungen zu erstellen, soll der bereits existierende Use Case DODE des Fachgebiets Software Engineering der Leibniz Universität Hannover benutzt werden. Der Use Case DODE arbeitet mit Erfahrungen und hilft dadurch beim Erstellen von Use Cases. Es soll den Studenten die Möglichkeit geboten werden diese Use-Case-Beschreibungen aus dem vorgegebenen Use Case DODE im Wiki darstellen zu können und diese wiederum aus dem Wiki in den Use Case DODE übertragen zu können. Ein wichtiger Vorteil des Wikis im Hinblick auf die Use Cases ist es, dass das Wiki die Möglickeit bietet, über diese zu diskutieren. Für die Abgabe der fertiggestellten Spezifikationen, die im Wiki erstellt worden sind, aber im Word- bzw. pdf-format abgegeben werden müssen, sollte eine Lösung überlegt werden. Im Weiteren wird nur noch die Bezeichnung SWP verwendet, gemeint ist das Software-Projekt in der Informatikausbildung am Fachgebiet Software Engineering (SE) der Leibniz Universität Hannover. 1.3 Gliederung der Arbeit Die Studienarbeit wird grob in drei Abschnitte geteilt. Der erste Abschnitt nach der Einleitung beschäftigt sich mit den Grundlagen. Es wird geklärt, womit sich das Requirements Engineering beschäftigt und welche Herausforderungen es mit sich bringt. Desweiteren wird auf die Wiki-Grundlagen eingegangen, die für ein Verständnis des nächsten Abschnittes wichtig sind. Der zweite große Abschnitt beschäftigt sich mit der Integration des Wikis in einen Reqirements Engineering Prozess, am Beispiel des SWPes. Dabei wird zuerst analysiert, welches die Aktivitäten und die aus ihnen resultierenden Dokumente in einem SWP sind, um daraus dann die Struktur des Wikis zu entwickeln. Im dritten Abschnitt wird ein kleiner Einblick in die Bedienung des entwickelten Wikis gegeben. Abschliessend folgt eine Zusammenfassung mit Ausblick.

6 2 GRUNDLAGEN UND VORGABEN 3 2 Grundlagen und Vorgaben 2.1 Anforderungen Anforderungen sind die wichtigste Grundlage eines jeden Projektes. Wie wichtig es ist Anforderungen richtig und vollständig zu ermitteln, zeigen Studien, bei denen Projekte untersucht wurden, die nicht erfolgreich waren. Der Grund besteht in vielen Fällen darin, dass Anforderungen falsch ermittelt werden. In einem Projekt kommen die Fehler zu 65% aus der Analyse [11]. Software ist nicht wie jeder andere Werkstoff, sie hat kaum Einschränkungen, und deshalb sind genaue Anforderungen notwendig. Anforderungen sollen ein gemeinsames Verständniss schaffen und aufzeigen welche Ergebnisse die Stakeholder verlangen. Für deren Ermittlung spielen viele Faktoren eine Rolle, unter anderem die Kommunikation zwischen dem Team und dem Kunden. Dieses führt jedoch zu vielen Problemen, wie z.b. der Symmetrie of ignorance vgl.[5]. Der Kunde hat nicht viel Wissen darüber, welche Möglichkeiten die Informatik bietet, während das Projektteam sich meist in dem Fachbiet des Kunden nicht auskennt. Hinzu kommt noch, dass der Kunde meist sehr wenig Zeit hat. Die Hintergründe des Kundenwunsches bleiben oft unzugänglich. Notwendig ist hier eine gute Anforderungsanalyse, welche in Abschnitt 2.2 näher erläutert wird Use Cases Ein Use Case, zu Deutsch Anwendungsfall, beschreibt nach [9] eine typische Interaktion eines Anwenders mit einem Computersystem mit dem ein Ziel des Anwenders erreicht wird. Use Cases stellen dar, was passiert und werden zur Dokumentation von Anforderungen eingesetzt. Sie beschreiben das externe Systemverhalten und decken somit alle funktionalen Anforderungen ab. Dabei unterteilen sie das Themengebiet in kleinere Teilgebiete, sodass ein Überblick leichter gewonnen werden kann. Ein weiterer Vorteil ist das Aufdecken von Unklarheiten beim Diskutieren von Use Cases. Use Cases beschreiben eine Interaktion abstrakt. Da Use Cases so geschrieben sind, dass die Interaktion aus Sicht des Benutzers stattfindet, sind sie auch für den Benutzer gut verständlich. Dieser Vorteil wird genutzt, und aus ihnen werden durch Einsetzen fester Werte Abnahmetestfälle abgeleitet, die für den Kunden eine Referenz darstellen. Der Einsatz findet in den frühen Phasen der Analyse statt

7 2 GRUNDLAGEN UND VORGABEN 4 (siehe [9] und [2]). Use Cases sollten deshalb im SWP in der Anforderungsspezifikation aufgeführt und eine tabellarische Struktur mit verschiedenen Rubriken haben. Hier ist eine Vorlage von Vorteil Ein kritikbasiertes Anforderungswerkzeug - Der DODE Um brauchbare Use Cases zu erstellen wird Erfahrung vorausgesetzt. Die Beteiligten der SWPe verfügen jedoch über kaum Erfahrungen in dem Bereich. Ein kritikbasiertes Werkzeug kann da helfen. Der Use Case DODE, der an der Leibniz Universität Hannover von Crisp in einer Masterarbeit entwickelt wurde (siehe [3]), verfügt über eine Erfahrungssammlung, mit Hilfe welcher es Hilfestellungen beim Erstellen bzw. Bearbeiten von Use Cases geben kann. Die Erfahrungssammlung kann von dem Benutzer erweitert werden. 2.2 Requirements Engineering Das Requirements Engineering umfasst die ingenieursmäßige Anforderungsanalyse und das Anforderungsmanagement. Das Requirements Engineering besteht aus der Systemanalyse und dem Requirements Management, wie man Abbildung 1 entnehmen kann. Die Systemanalyse besteht aus folgenden Tätigkeiten: Beim Abbildung 1: Einbettung des Begriffs Requirements Management in das Requirements Engineering [11] Elicitation versucht man die Anforderungen aus dem Kunden zu ermitteln, beim Interpretation wird das Gehörte gedeutet, beim Negotiation versucht man Widersprüche aufzulösen und schreibt dann die Anforderungen auf (Dokumentation).

8 2 GRUNDLAGEN UND VORGABEN 5 Die einzelnen Aktivitäten der Abbildung 1 laufen parallel ab. Die ermittelten Anforderungen beeinflussen das komplette weitere Vorgehen. Der Software-Entwurf stützt sich auf die Anforderungen und wird aus diesen erstellt Requirements Management Die Technik schreitet heutzutage immer weiter voran, was auch für die Software als selbstverständlich empfunden wird. Jedoch ist Software anders. Sie ist immateriell und hat somit kaum Einschränkungen. Die meisten Menschen haben den Eindruck, dass Software alles kann [11]. Wegen der großen Vielfalt an Produkten und dem steigenden Wettbewerbsdruck wird es immer wichtiger, entweder die Kosten zu senken, oder sie dem Kunden zu rechtfertigen. Um Kosten zu senken bzw. das genau auf den Kunden abgestimmte Produkt zu entwickeln, ist eine genaue Anforderungsanalyse, die die Kundenwünsche ermittelt und verfolgt, zunehmend wichtiger. Das Ziel ist nicht dadurch erreicht, dass Anforderungen einmal ermittelt und dann das ganze Projekt über festgehalten werden, sondern unterliegen fortlaufend Änderungen. Hier setzt das Requirements Management ein. Die Aufgabe des Requirements Management besteht aus der Verwaltung von Anforderungen und zugehörigen Informationen, der Verfolgung von Änderungen, der Strukturierung, der Priorisierung und der Dokumentation von Beziehungen [9]. Dies ist aus dem Grunde wichtig, da der Kunde nicht selten Änderungswünsche äußert, teilweise auch in den späteren Phasen eines Projektes. Das heisst, die Anforderungen ändern sich fortlaufend das gesamte Projekt über, und deshalb muss das Requirements Management während des gesamten Projektes berücksichtigt werden. Das Requirements Abbildung 2: Der Requirements Management Prozess [10] che aufgeteilt. Zum Einen gibt es das Management wird in zwei Teilberei- Change Management, welches dafür

9 2 GRUNDLAGEN UND VORGABEN 6 zuständig ist, dass Anforderungen konsistent geändert und versioniert werden. Zum Anderen sorgt das Tracing dafür, zu sehen, welche Anforderungen sich wie auf die Entwicklung des Produkts ausgewirkt haben. Durch das Re-Tracing wird festgestellt, aus welchen Anforderungen bestimmte Eigenschaften entstanden sind. Die Aufgaben des Requirements Management sind in Abbildung 2 dargestellt. In dieser Studienarbeit spielt das Requirements Management als Management von Anforderungsdokumenten eine entscheidende Rolle Herausforderungen des Requirements Management Das Requirements Management schließt einige umfassende Aufgaben ein. Zu den oben beschriebenen gehört unter anderem auch die Verwaltung von Informationen, wie Zielen, Definitionen und Use Cases, als auch übergreifende Aufgaben, wie die Wiederverwendung dieser Informationen. Das bringt eine Menge an Herausforderungen mit sich. In [9] beschreibt Rupp die wichtigsten davon. Jeder dieser einzelnen Punkte muss für ein gutes Requirements Management beachtet und entsprechend gelöst werden. Sie werden im Folgenden vorgestellt. Informationsaustausch Bei der Arbeit in einem Projekt ist eine gute Kommunikation wichtig. Ein zentraler Punkt ist die Verteilung von Informationen. Jedes Projektmitglied muss dafür sorgen, dass den anderen Projektteilnehmern seine aktuellen Änderungen sofort zur Verfügung stehen. Das Arbeiten mit veralteten Informationen soll vermieden werde, um Kosten zu sparen. Räumliche und zeitliche Verfügbarkeit Die Projektteilnehmer arbeiten aus Kosten- und Zeitgründen meist nicht an einem einzelnen Ort. Die Projektinformationen, sowie alle relevanten Materialien, müssen von überall abrufbar und zugänglich sein. Transaktionsmanagement Ein wichtiger Punkt des Requirements Management ist das Transaktionsmanagement, welches aus Verfahren, Methoden und Algorithmen besteht, die die Zugriffe auf gleiche Daten und Informationen automatisch regeln. Das Transaktionsmanagement findet man in modernen Datenbankssysteme. Es erlaubt die Bearbeitung von Dokumenten gleichzeitig durch mehrere Personen, bei dem den Benutzern die Möglichkeit gegeben wird die Änderungen des Anderen nicht zu überschreiben, sondern zu übernehmen.

10 2 GRUNDLAGEN UND VORGABEN 7 Workflow-Konzept Jedes Projekt wächst mit der Zeit und kann unüberschaubar werden. Trotzdem sollte jeder Bearbeiter ohne langes Suchen die Informationen finden, die ihm zugeordnet wurden. Eine gute Steuerung der Informationen ist hier unentbehrlich. Sicherheitsproblem und Zugriffsschutz Aus Datenschutzgründen sollte die Bearbeitung der Projektdokumente nur durch autorisierte Benutzer und am Besten mit Unterschrift erfolgen. So wird sichergestellt, dass nur berechtigte Personen Zugriff haben, und es kann nachvollzogen werden, wer welchen Teil der Dokumente bearbeitet hat. 2.3 Wiki Ein Wiki ist ein Werkzeug für die Erzeugung, Verwaltung und Darstellung von Informationen. Heutzutage werden Wikis in vielerlei verschiedenen Gebieten eingesetzt. Das wohl bekannteste Beispiel ist die Wikipedia-Enzyklopädie. In den große Unternehmen nimmt die Anzahl der verwendeten Wikis zu. Im firmeneigenen Intranet werden sie häufig für interne Zwecke eingesetzt. Gründe gibt es viele, unter anderem, dass ein Wiki eine Art selbstverwaltende Informationsdatenbank darstellt. Die Informationen werden zentral gesammelt und durch die Eigenschaften eines Wikis die Zusammenarbeit und Kommunikation im Projektteam erleichtert. Das Prinzip eines Wikis ist folgendes: Jedes Wiki hat einen Webserver, auf dem Webseiten gespeichert werden. Diese Webseiten können vom Benutzer erstellt und bereits existierende Seiten gelesen oder verändert werden. Dieses geschieht einfach über einen Webbrowser. Jedes Wiki besitzt eine Wiki-Syntax, die meist eine niedrige Lernschwelle besitzt und somit leicht erlernbar ist Prinzipien Die Grundprinzipien sind in allen Wikis gleich und sollen hier nach [1] kurz vorgestellt werden. Desweiteren wird auch sofort Bezug zu dem oberen Abschnitt Herausforderungen des Requirements Management genommen, und kurz dargestellt, inwiefern ein Wiki grundsätzlich eine Unterstützung des Requirements Management wäre. One place publishing Um die Kommunikation in einem Team zu fördern, werden Informationen zentral

11 2 GRUNDLAGEN UND VORGABEN 8 abgelegt. So stehen die Informationen gleich nach dem Speichern allen anderen Benutzern des Wikis zur Verfügung. Beim Abrufen der Informationen wird immer die aktuellste Version verwendet. Alle Informationen befinden sich auf einem zentralen Platz und müssen nicht jedes Mal per verschickt werden. Dieses Prinzip löst das Problem des Informationsaustausches. Safe and simple collaboration Ein Wiki ermöglicht eine einfache und sichere Zusammenarbeit, deshalb auch safe and simple collaboration. Einfach aus dem Grunde, weil die niedrige Lernschwelle eine einfache Benutzung des Wikis erlaubt. Sicherheit bietet das Wiki bei der gleichzeitigen Bearbeitung von Seiten. Entweder ist das Bearbeiten einer Seite jeweils auf eine Person beschränkt, oder es wird anders geregelt. Desweiteren können ältere Versionen wiederhergestellt werden. Hier wird das Prinzip des Transaktionsmanagements verwendet. Description on demand Description on demand bezeichnet die Eigenschaft, dass in Wikis neue Seiten verlinkt werden können, ohne sie mit Inhalt zu füllen. Diese werden in einer anderen Farbe als die mit Inhalt gefüllten Seiten hervorgehoben. Dadurch wird dem Benutzer angedeutet, dass diese Seite von Bedeutung ist, jedoch noch keinen Inhalt hat. Emergent structures Am Anfang eines Projektes ist das Vorgehen meist relativ chaotisch. Es entsteht vorerst eine Art Sammlung von Informationen, die nicht genau zugewiesen werden können. Ein Wiki bietet dafür den perfekten Anlauf, Informationen erst zu sammeln und dann zu strukturieren. Zu Beginn erstellte Seiten können nach und nach verknüpft und so eine Struktur aufgebaut werden. Desweiteren ist eine räumliche und zeitliche Verfügbarkeit durch ein Wiki gewährleistet, wenn das Wiki direkt aus dem Internet abgerufen werden kann Anforderungen an ein Wiki Da Wikis in so vielen Bereichen eingesetzt werden, müssen sie dementsprechend verschiedene Anforderungen erfüllen. In [1] beschreiben Decker u.a. die Eigenschaften, die ein Wiki für den Einsatz im Requirements Engineering haben muss

12 2 GRUNDLAGEN UND VORGABEN 9 bzw. haben sollte. Sie sind in verschiedene Bereiche unterteilt wie Suche, Struktur, Versionierung und Zugriff und werden im Einzelnen vorgestellt. Suche Notwendig ist auf jeden Fall immer eine Volltextsuche, um einen Überblick zu bewahren. Eine Suche über eine URL, über die man Anfragen schon vordefinieren kann, wäre von Vorteil. Strukturierung Bei einer hohen Anzahl an Seiten im Wiki geht der Überblick schnell verloren. Vor allem sind die einzelnen Seiten beliebig miteinander verlinkt. Nicht zu sehen ist dann, welche Seite wo verwendet wird. Um diese Funktionalität zur Verfügung zu stellen, werden sogenannte Backlinks benutzt. Beim Aufrufen des Backlink- Befehls werden alle Seiten angezeigt, von denen aus die geöffnete Seite verlinkt ist. Wie oben beschrieben ist jedes Wiki eine Ansammlung von Daten auf mehreren Seiten. Um die Seiten zu strukturieren, werden sie in Kategorien eingeteilt. Auf diese Weise können Informationen zu bestimmten Gebieten zugeordnet und beim Aufrufen einer Kategorie aufgelistet werden. Eine einzelne Wiki-Seiten kann sich jeweils aus verschiedenen Unterabschnitten zusammensetzen, die teilweise lange Beschreibungen enthalten. Um nicht lange suchen zu müssen, hilft ein Inhaltsverzeichnis zu der passenden Textpassage zu finden. Aus dem Bereich der Strukturierung sollte ein Wiki für das Requirements Engineering mindestens eine der oben aufgeführten Eigenschaft erfüllen. Versionierung Ein wesentlicher Bestandteil eines Wiki ist die Versionierung. Jedoch würde diese Eigenschaft nicht viel bewirken, wenn man nicht die älteren Versionen wiederherstellen (rollback) könnte. Um zu wissen, welche Version gebraucht wird, ist es wichtig, zwei Versionen miteinenader zu vergleichen (diff ). Zugriffsrechte Sicherheitsaspekte spielen bei jedem Projekt eine entscheidende Rolle. Es darf nicht beliebig auf die Daten in einem Wiki zugegriffen werden, sondern jeder Benutzer muss sich mit einem Benutzernamen und Passwort authentifizieren.

13 3 KONZEPT EINES WIKIS FÜR DAS SWP 10 Desweiteren sind Zugriffsbeschränkungen von Vorteil, die einschränken, welcher Benutzer welche Funktionen ausführen darf Herausforderungen Wie oben beschrieben, haben Wikis recht viele Vorteile. Doch einige Aspekte sind bisher noch offen geblieben. Es besteht bisher nicht die Möglichkeit Seiten auf irgendeine Weise zu aggregieren, um sie dann seitenübergreifend zu versionieren oder zu exportieren. Der pdf-export selbst ist auch noch nicht integriert. Um unkontrolliertes Ausstrecken der Inhalte zu vermeiden, muss das Wiki gut strukturiert werden. Ein anderer Aspekt betrifft das Arbeiten am Wiki, wenn keine Internetverbing besteht. Dieses ist nicht möglich. Die Rechteverwaltung ist bisher sehr einfach strukturiert, indem die Rechte entweder an alle Benutzer oder Gruppenweise vergeben werden. Die Seitenzugriffsverweigerung für einzelne Seiten ist demnach für eine Person alleine nicht möglich. 3 Konzept eines Wikis für das SWP Um ein Wiki auf die Bedürfnisse der Benutzer anzupassen, müssen die Aktivitäten, für die es zur Verfügung stehen soll, untersucht werden. Das zu erstellende Wiki, welches im Folgenden einfach nur kurz SEWiki bezeichnet wird, soll als Verwaltungseinheit in SWPen eingesetzt werden. Welche Aktivitäten in einem SWP ablaufen und welche Vorgehensweise gewählt wird, soll im Weiteren betrachtet werden. Um die Aufgaben allgemein in Software-Projekten zu analysieren, bedient man sich eines Vorgehensmodells. Dieses beschreibt einen Entwicklungsprozess und dessen Ergebnisse. Die Ergebnisse entstehen als Folge von Aktivitäten, die entweder sequentiell oder inkrementell durchlaufen werden. Hier soll die sequentielle Vorgehensweise betrachtet werden. Ein bekanntes sequentielles Vorgehensmodell ist das V-Modell, welches in Abbildung 3 dargestellt ist. Der Entwicklungsprozess enthält Aktivitäten, die sowohl das Requirements Engineering, als auch den Entwurf, die Implementierung und den Test abdecken. Die einzelnen Aktivitäten werden auch als Phasen bezeichnet. Da die Implementierung grundsätzlich nicht mit Anforderungen direkt arbeitet, sondern aus dem Entwurf resultiert, soll es im Weiteren keine allzu große Rolle spielen. Das Hauptaugenmerkmal wird auf die Aktivitäten links in der Abbildung gelegt, bei dem das Requirements Engineering auch als Teilprozess eine wichtige Rolle spielt. Die Prozesse des Requirements

14 3 KONZEPT EINES WIKIS FÜR DAS SWP 11 Managament laufen nicht einzeln, sondern parallel ab. Deshalb können sie hier keiner einzelnen Phase zugeordnet werden. Abbildung 3: Das allgemeine V-Modell Die Phasen in der Abbildung 3 sind Rollen zugeordnet. Eine Rolle ist unter anderem der Kunde bzw. das Projektteam, welches den Auftrag des Kunden ausführt. Der Kunde verfasst in der Phase der Anforderungsermittlung das Lastenheft, auf dem alles Weitere aufbaut, was dem folgt. Bei der Abnahme wird vom Kunden der Abnahmetest durchgeführt, der bestätigen soll, dass die Software ihre Anforderungen erfüllt. Diese Abnahmetestfälle werden relativ früh ermittelt und meist im Pflichtenheft, welches bei der Anforderungsanalyse oder anders Anforderungsspezifikation erstellt wird, festgehalten. 3.1 Aufbau des SWPes Abbildung 4: Die Projektphasen im SWP des Institut für Software-Engineering der Leibniz Universität Hannover [7]

15 3 KONZEPT EINES WIKIS FÜR DAS SWP 12 Das SWP wird im Laufe des Informatik-Studiums abgelegt, um Praxiserfahrungen für später zu erlangen. Der Ablauf des SWPes ist relativ Nahe an das V-Modell angelehnt. Es unterteilt sich in 3 Phasen, der Anforderungs-, Entwurfs- und Implementierungsphase. Die Projektphasen, als auch die dafür zur Verfügung stehenden Zeiten, sind in Abbildung 4 dargestellt. Jede Phase schließt mit einem Quality Gate ab, welches bei Nichtbestehen in genau einer Woche wiederholt wird. Abbildung 5: Darstellung der Aktivitäten im SWP - Anforderungsphase Um den Zusammenhang zwischen den einzelnen Projektphasen und den darin entstehenden Dokumenten zu verdeutlichen, sind hier zwei Aktivitätsdiagramme dargestellt. Sie zeigen die einzelnen Aktivitäten des SWPes und die aus den Aktivitäten resultierenden Dokumente. Dieses sind jedoch nicht alle Dokumente, die entstehen. Es gibt eine Menge anderer Dokumente, die im Allgemeinen

16 3 KONZEPT EINES WIKIS FÜR DAS SWP 13 von vornherein nicht bestimmt werden können und jeder Projektgruppe selbst überlassen wird, welche weiteren Dokumente sie für notwendig erachtet. Diese Dokumente werden von den SE-Mitarbeitern nicht geprüft. Die Abbildung 5 stellt die Anforderungsphase dar und endet mit der Entwurfsspezifikation, die auf der nächsten Abbilung fortgesetzt wird. In Abbildung 6 ist Abbildung 6: Darstellung der Aktivitäten im SWP - Entwurfsphase die Entwurfsphase dargestellt. Auf die Implementierungsphase wird nicht weiter eingegangen, da sie beim Entwickeln des SEWikis keine Rolle spielt. Wie auch schon in Abbildung 4 zu sehen war, findet nach der Anforderungs- und Entwurfsphase ein Quality Gate statt. Bei Nichtbestehen muss die entsprechende Spezifikation fertiggestellt und die nächste Spezifikation trotzdem schon angefangen werden, da die Zeit beschränkt ist. Jedem Projektteam steht eine bestimmte Anzahl an Beratungs- und Kundengesprächen zur Verfügung. Diese können frei eingeteilt werden.

17 3 KONZEPT EINES WIKIS FÜR DAS SWP 14 Auf dem hier dargestellten Aufbau des SWPes baut das zu entwickelnde SEWiki auf und berücksichtigt die Aktivitäten bzw. die entstehenden Dokumente. Die Dokumente, die zum Quality Gate abgegeben werden müssen, sind die 1 Mission des Projekts Softwareprojekt - Anforderungsspezifikation 4 Qualitätsanforderungen 1.1 Erläuterungen des 4.1 Qualitätsziele des Projekts zu lösenden Problems 4.2 Qualitäts-Prioritäten 1.2 Wünsche und Prioritäten des Kunden des Kunden 4.3 Wie Qualitätsziele erreicht 1.3 Domänenbeschreibung werden sollen 1.4 Maßnahmen zur 5 Probleme und Risiken Anforderungsanalyse 2 Rahmenbedingungen 6 Optionen zur Aufwandsreduktion und Umfeld 6.1 Mögliche Abstriche 2.1 Einschränkungen und 6.2 Inkrementelle Arbeit Vorgaben 2.2 Anwender 8 Glossar 7 <Zur freien Verfügung> 2.3 Schnittstellen und an- 9 Abnahme-Testfälle grenzende Systeme 3 Funktionale Anforderungen 3.1 Use-Case-Diagramm 3.2 Use-Case-Beschreibungen 3.3 Technische Anforderungen Tabelle 1: Anforderungsspezifikation-Vorlage des SWPes Anforderungs- und die Entwurfsspezifikation. Um den Studenten vorzugeben, welche Inhalte dort in etwa enthalten sein sollen, existieren für die beiden Spezifikationen Vorlagen. Die Vorlagen sind nicht genau auf ein Projekt abgestimmt, sondern enthalten allgemeine Stichpunkte, die grundsätzlich in jedem Projekt von Bedeutung sein können. Die Vorlage für die Anforderungsspezifikation ist in Tabelle 1 zu sehen. Diese Vorlage wurde auch in dem SEWiki erzeugt, sodass die Anforderungsspezifikation dort eine einzelne Seite ist Gründe für den Einsatz eines Wikis im SWP Aus den oben dargestellten Aktivitäten und Dokumenten, die in einem SWP entstehen, wird deutlich, dass ein Verwaltungssystem verwendet werden muss,

18 3 KONZEPT EINES WIKIS FÜR DAS SWP 15 um eine gute Strukturierung der anfallenden Dokumente zu erhalten. Mit den bisherigen Werkzeugen war die Strukturierung teilweise recht eingeschränkt. Die verwendeten Anforderungsumgebungen, zur Dokumentation von Anforderungen, sind in Abbildung 7 dargestellt. Dieses sind die gleichen Werkzeuge, die man auch für die Dokumentation des Entwurfs und anderer Dokumente benutzt. Abbildung 7: Im Moment verwendete Anforderungsumgebungen, x-koordinate stellt die Anzahl der Personen dar, im Test haben 135 Personen teilgenommen (siehe [4]) Das am Meisten gebrauchte Werkzeug zum Schreiben von Dokumenten ist das Microsoft Word. Dieses bietet den Vorteil, dass die Teammitglieder sich nicht einarbeiten müssen, da es den Meisten aus dem Privatgebrauch bekannt ist. Die Verlinkung ist in Word möglich, jedoch schwierig und fehleranfällig. Desweiteren können die für ein Requiremants Management nötigen Aktivitäten in Word nur schwer erfolgen, da Word weder eine Versionierung noch ein Change Management bietet. Hierfür sind Requirements-Engineering-Werkzeuge notwendig, wie z.b. Doors, Caliber und Requisite Pro. Diese haben den Nachteil, dass die Anschaffung relativ teuer ist. Wikis bilden im Bereich des Requirements Managements einige Vorteile gegenüber anderen Werkzeugen. Die Vorteile eines jeden Wikis wurden in den Grundlagen vorgestellt. Zusätzlich sind in Tabelle 2 die Vor- und Nachteile des entstehenden Prototypen dargestellt.

19 3 KONZEPT EINES WIKIS FÜR DAS SWP 16 positiv Diskussionsseiten Versionsverwaltung Überblick über die letzten Änderungen alle Dokumente eines Projektes in einem Werkzeug Word- und pdf-dokumente können eingebunden werden räumliche und zeitliche Verfügbarkeit Verlinkung der Seiten, um Zusammenhang zu verdeutlichen Worterklärungen können im Glossar aber auch auf Extraseiten dargestellt werden Überblick über die TODOs aller Seiten bzw. Dokumente Seiten können beliebig im Wiki-Text eingebunden werden negativ gewöhnungsbedürftige Syntax eingeschränkte Rechtschreibprüfung keine Kommentarfunktion wie in Wordoder pdf-dateien eingeschränkte Formatierungsmöglichkeiten offline Arbeiten ist nicht möglich eingeschränkter Export keine Seitenübergreifende Versionsverwaltung jeder kann alles ändern kaum Beschränkungen/Constraints Änderungen sofort verfügbar einfache externe Verlinkung (z.b. in s) übersichtliche Gliederung Vorlagen vereinfachen die Arbeit Terminüberblick Zeitleiste als Übersicht über anstehende Termine Tabelle 2: Auflistung der positiven bzw. negativen Gesichtspunkte des SEWikis blau dargestellte Gesichtspunkte wurden aus dem Test ermittelt (siehe nächster Abschnitt) Testdurchführung Nachdem das SEWiki soweit fertiggestellt worden ist, wurde mit 4 Informatik- Studenten, die das SWP schon abgeschlossen hatten, ein Test durchgeführt. Die Beteiligten sollten bestimmte Aufgaben am SEWiki durchführen. Sowohl die Aufgaben, als auch die Ergebnisse, befinden sich im Anhang. Nach dem Lösen der Aufgaben und dadurch einer Einarbeitungszeit von ca. 2 Stunden wurden die Beteiligten aufgefordert einen Fragebogen auszufüllen, der Aspekte, wie Quali-

20 3 KONZEPT EINES WIKIS FÜR DAS SWP 17 tätsmerkmale und den Vergleich dieser mit den bisherigen Werkzeugen, enthielt. Desweiteren bot er die Möglichkeit, die positiven und negativen Aspekte des SEWikis zu beschreiben. Diese sind in Tabelle 2 in blau dargestellt. Abbildung 8: Fragebogen Auswertung

21 3 KONZEPT EINES WIKIS FÜR DAS SWP 18 Abbildung 9: Fragebogen Auswertung Abbildung 10: Fragebogen Auswertung Die negativen Aspekte beziehen sich überwiegend darauf, dass in Wikis generell kaum Restriktionen vorhanden sind. Dieses ist jedoch aber widerum eines der größten Vorteile eines jeden Wikis, da nur auf diese Art und Weise eine beliebige

22 3 KONZEPT EINES WIKIS FÜR DAS SWP 19 Abbildung 11: Fragebogen Auswertung Strukturierung und Anpassung erlaubt ist. Der Vergleich des SEWikis mit den bisherigen Werkzeuge ist sehr positiv ausgefallen, wie den Abbildungen 9 und 11 zu entnehmen ist. Nur ein Aspekt der Qualitätsmerkmale ist von den Beteiligten schlechter bewertet worden als bisher. Dieses betrifft die Zuverlässigkeit, welches darauf zurückzuführen ist, dass es auf Grund der kurzen Einarbeitungszeit schwierig ist das Wissen über ein Wiki zu erwerben, welches notwendig ist, um damit optimal arbeiten zu können. Ein weiterer Grund ist der, dass die Erweiterungen von MediaWiki (siehe 3.2.1) sich noch in der Entwicklung befinden. Insgesamt haben die betrachteten Aspekte gezeigt, dass der Einsatz eines auf das SWP angepassten SEWikis sich positiv auswirken sollte. Es hat mehr Vorteile als Nachteile nachzuweisen und wurde im Test im Vergleich zu den bisherigen Werkzeugen besser bewertet. Der Einsatz des SEWikis bedeutet nicht, dass auf die bisherigen Werkzeuge verzichtet werden muss. Durch das Hochladen beliebiger Arten von Dokumenten ist das parallele Arbeiten mehrerer Werkzeuge, zur Unterstützung des SEWikis, möglich und teilweise auch sehr wichtig. Auch die Benutzung externer Programme, die an das SEWiki angebunden werden könnten, beispielweise der Aufruf des Use Case DODE um Use Cases zu erzeugen, würde sich positiv auf die Arbeit mit dem SEWiki auswirken. Die Idee der Integration ist in Abschnitt beschrieben.

23 3 KONZEPT EINES WIKIS FÜR DAS SWP SEWiki-Aufbau In diesem Abschnitt soll der Aufbau des SEWikis erläutert werden. Dieser basiert auf dem in [8] beschriebenem. Vergleicht man das SEWiki mit den Anforderungen, die an ein Wiki für den Einsatz im Requirements Engineering gestellt werden, so erfüllt es so gut wie alle Anforderungen. Die Aspakte der Suche, Strukturierung aber auch der Versionierung sind vorhanden. Die Strukturierung wird teilweise in den folgenden Abschnitten erläutert, während auf den Aspekt der Zugriffsrechte in Abschnitt eingegangen wird Softwarepakete Das SEWiki setzt sich aus MediaWiki und 3 Erweiterungen zusammen. Die Erweiterungen ergänzen MediaWiki für unsere Zwecke, um Fuktionen zu ermöglichen mit denen die Arbeit mit dem SEWiki erleichtert werden soll. MediaWiki Der Hauptbestandteil des Prototypen ist MediaWiki. Dieses enthält die wichtigsten Funktionen wie Speicherung, Eingabe, Bearbeitung und die Versionsverwaltung. MediaWiki ist in PHP implemetiert und basiert auf einer MySQL- Datenbank, in der alle Einträge gespeichert werden. Es ist hauptsächlich für die Wikipedia-Projekte optimiert und ist somit recht benutzerfreundlich, dank seines einfachen Wikitext-Formates. Die Verwaltung und Steuerung wird durch Spezialseiten ermöglicht. Eine Auswahl der wichtigsten Spezialseiten ist in Abbildung 12 zu sehen. Diese sind auf der Hauptseite des Prototypen dargestellt. MediaWiki bietet eine gute Sprachunterstützung und viele Einstellungs- und Anpassungsmöglichkeiten wie z.b. die Abbildung 12: Auflistung der wichtigsten Spezialseiten auf der Hauptseite Darstellung von den letzten Änderun- Sprachauswahl und die Einstellung der des SEWikis gen. Änderungen können grundsätzlich mit einem Vermerk abgespeichert werden, sodass die anderen Wiki-Benutzer auf einen Blick sehen, was geändert wurde. Erfolgt das Ändern eines Textes durch mehrere Benutzer gleichzeitig, so erstellt

24 3 KONZEPT EINES WIKIS FÜR DAS SWP 21 MediaWiki automatisch aus beiden Änderungen eine neue Version, solange zwei verschiedene Abschnitte bearbeitet wurden. Bei Änderungen, die die gleichen Abschnitten betreffen, wird der als erstes gespeicherte Text dem zweiten Benutzer beim Speichern angezeigt. Dieser kann seine Änderungen dann in den bereits abgespeicherten Text einbauen. Die Seite, die dann angezeigt wird, ist in Abbildung 13 zu sehen. Abbildung 13: Seite nach dem gleichzeitigen Ändern MediaWiki wird ständig weiterentwickelt, und deshalb gibt es jetzt schon viele Erweiterungen, mit denen das MediaWiki an die Bedürfnisse angepasst werden kann. Diese Erweiterungen sind jedoch noch nicht so konsistent, wie man sie teilweise gerne haben würde. Semantic MediaWiki Semantic MediaWiki erweitert MediaWiki um semantische Konzepte. So kann man Wissen über Seiten und ihre Abhängigkeiten maschinenlesbar darstellen. Dies geschieht mit Hilfe einer Ontologie, mit der man Kategorien, Relationen und Attribute beschreiben kann. Relationen dienen dazu, Abhängigkeiten zwischen den einzelnen Seiten darzustellen, während Attribute Eigenschaften der jeweiligen Seite selbst erfassen. Über Kategorien kann man verschiedene Seiten einem

25 3 KONZEPT EINES WIKIS FÜR DAS SWP 22 Themengebiet zuteilen, welches eine Klasse darstellt, und somit eine Struktur in dem Wiki aufbauen. Die Seiten sind dann die Instanzen. Mit den dargestellten Eigenschaften können Seiteninhalte mit zusätzlichen Informationen versehen werden. Die Darstellung dieser Informationen auf einer Seite wird als Annotationen bezeichnet (Bsp. siehe Abbildung 19). Annotationen ermöglichen eine semantische Suche, mit der viel genauere Ergebnisse erzielt werden, durch das Suchen nach bestimmten Relationen oder Attributen. Sogenannte InlineQuerys erlauben detailierte Suchabfrage. Als Ergebnis können Listen oder Tabellen ausgegeben werden. Ein Beispiel für eine InlineQuery ist in Abbildung 14 dargestellt. Abbildung 14: Zeitleiste auf der Hauptseite des SEWikis Semantic Forms Eine Erweiterung des Semantic MediaWiki ist wiederum das Semantic Forms. Es dient zum Erstellen von Formularen. Die vom Benutzer in ein generiertes Formular eingegebenen Daten werden in eine Vorlage übertragen. Aus dieser Vorlage wird dann eine neue Seite erstellt. Das Semantic Forms macht es möglich, das Layout der Seite und die Annotationen für den Benutzer zu erfassen, ohne dass der Benutzer davon etwas bemerkt. Dieses hat den Vorteil, dass die Seiten einheitlich dargestellt werden, aber auch die Eingabeformulare immer gleich sind. Einmal erstellte Vorlagen und Formulare können jedes Mal wieder benutzt werden. Ein weiterer Vorteil von Formularen ist die automatische Vervollständigung von Feldern. Dies geschieht je nach vorheriger Eingabe der Relation und Kategorie, auf die in Abschnitt eingegangen wird. Ein Beispiel dafür ist die Abbildung 24.

26 3 KONZEPT EINES WIKIS FÜR DAS SWP 23 Parser Functions Die Erweiterung Parser Functions deckt den Teil der Vorlagenprogrammierung ab. Es können Kontrollstrukturen anhand deren Parameter definiert werden, was den sonst relativ starren Vorlagen etwas mehr Spielraum lässt. Bei Eingabe bestimmter Werte in das Eigabeformular lassen sich vordefinierte Ausgaben machen. Wenn nichts in ein Feld eingegeben werden sollte, dann können auch bestimmte Ausgaben gemacht werden. Dies ist bei dem SEWiki der Fall, bei dem bei manchen Vorlagen nicht alle Felder ausgefüllt werden müssen. Ein Beispiel dafür ist die if-abfrage in Abbildung Artefakte Als Artefakt werden alle Typen von Ergebnissen in einem Projekt bezeichnet (in [8] näher erläutert). Ergebnisse sind in SWPen wichtig, da sie alle notwendigen Informationen darstellen. Die Artefakte des Prototypen werden im Folgenden vorgestellt, wobei für jedes Artefakt ein Eingabeformular und die dafür vorgesehene Vorlage existiert. Wie oben beschrieben werden die Abhängigkeiten bzw. Eigenschaften durch die Eigabeformulare erfasst. Projekt Um das SEWiki gliedern zu können, wird es in Projekte unterteilt. Alle weiteren Artefakte, abgesehen von den Glossareinträgen, sind eindeutig einem Projekt zugeordnet. Bei dem Prototypen unterteilen sich die Artefakte eines Projektes in die Klassen Organisatorisches und Projektdokumente. Beim Erstellen eines Projektes werden Titel, Anfangs- und Enddatum und eine kurze Beschreibung semantisch erfasst. Organisatorisches Jedes Artefakt von Organisatorisches ist, durch Eingabe des Projektnamen in das dafür vorgesehene Formularfeld, eindeutig einem Projekt zugeordnet. Die Klasse Organisatorisches unteilt sich in die Unterklassen Review, Allgemeine Informationen und Planung, wie in Abbildung 15 dargestellt. Grundsätzlich sollten am Anfang eines Projektes die Artefakte der Unterklasse Planung als erstes bearbeitet werden, da sie von anderen Artefakten verwendet werden. Die Unterklasse Planung setzt sich aus Aufgaben, Mitarbeitern und Terminen zusammen. Zwischen Mitarbeitern und Aufgaben besteht eine Assoziation. Jeder Aufgabe wird der für sie zuständige Mitarbeiter zugeordnet, um zu gewährleisten,

27 3 KONZEPT EINES WIKIS FÜR DAS SWP 24 Abbildung 15: Artefakt Organisatorisches dass die Aufgabe einen Zuständigen hat. Ohne eine zuständige Person werden Aufgaben leichter vernachlässigt. Das Review ist vorwiegend für das zur Verfügung stellen von Informationen bzw. Dokumenten durch die SE-Mitarbeiter gedacht. Das Artefakt Allgemeine Informationen soll den Projektbeteiligten dabei helfen Informationen auszutauschen und das Projekt zu organisieren. Besonders am Anfang eines Projektes sollen hier Informationen hinzugefügt werden. An der Stelle sollen jedoch keine wichtigen Dokumente, aus denen Anforderungen entstehen, erstellt werden. Dafür ist die Projektmappe in der Klasse Projektdokumente vorgesehen. Projektdokumente Jedes Projektdokument wird, durch Eingabe des Projektnamens in das entsprechende Formularfeld, eindeutig einem Projekt zugeordnet. Die Unterklassen der Klasse Projektdokumente sind in Abbildung 16 dargestellt. Die Projektmappe enthält alle Dokumente, die für das Projekt relevant sind und aus denen Anforderungen ermittelt werden, abgesehen von den Spezifikationen. Es können unter anderem beliebige Diagramme, Kundengespräche etc. sein. Die Idee dafür entstand dadurch, dass sich im Laufe eines Projektes sehr viele Dokumente ansammeln, die es zu verwalten gilt. Beim Erstellen eines Projektmappe-

28 3 KONZEPT EINES WIKIS FÜR DAS SWP 25 Abbildung 16: Artefakt Projektdokumente Dokumentes werden der Titel, das Datum und die Projektphase semantisch erfasst, anhand derer das Dokument zeitlich und thematisch eingeordnet werden kann. Auf diese Art und Weise sind alle Dokumente strukturiert in einer Mappe einsortiert. Jedes Projekt enthält eine Anforderungs- und eine Entwurfsspezifikation. Dieses sind die zwei wichtigsten Artefakte, die nach der Fertigstellung beim Quality Gate vorgelegt werden. Die beiden Artefakte assoziieren mit der Unterklasse Planung der Klasse Organisatorisches. In der Anforderungsspezifikation werden die Mitarbeiter, die zum Projekt gehören, und die Aufgaben, die in der Anforderungsphase anstehen, aufgelistet. In der Entwurfsspezifikation sind alle 3 Artefakte der Unterklasse Planung vertreten. Die aufgeführten Aufgaben sind wiederum nur auf die Entwurfsphase beschränkt. Jede Anforderungsspezifikation kann beliebig viele Use Cases enthalten. Use Cases Beim Erstellen eines Use Cases ist auch hier ein Formularfeld für die Eingabe des Projektnamen vorhanden. Nur so kann gewährleistet werden, dass alle

29 3 KONZEPT EINES WIKIS FÜR DAS SWP 26 einem Projekt zugeordneten Use Cases, in der zu diesem Projekt zugeordneten Anforderungsspezifikation, mit Hilfe einer semantischen Anfrage, aufgelistet werden. Beim Bearbeiten eines Use Cases sind die in der Abbildung 17 aufgelisteten Attribute bzw. Relationen Pflichtfelder, die notwendigerweise ausgefüllt werden müssen, um den Use Case zu speichern. Abbildung 17: Artefakt Use Case Glossareinträge Zu jedem Use Case kann ein Glossareintrag gemacht werden, für den der Begriff und die Beschreibung eingetragen werden müssen. Ein Glossareintrag ist indirekt über den Use Case einem Projekt zugeordnet. Das ist bewusst so gewählt, um eine Wiederverwendbarkeit zu ermöglichen Konzepte der Programmierung Im Weiteren sollen die Konzepte für die Formalisierung der Seiten erläutert werden (basierend auf [8]). Wie schon in dem Kapitel Softwarepakete kurz erwähnt wurde, gibt es vier Konzepte, mit denen man Abhängigkeiten von Seiten und den Seiteninhalt beschreiben kann. Das sind Folgende: Kategorien, Relationen, Attribute und Typen. Diese Konzepte haben jeweils einen eigenen Namensraum, d.h. sie können z.b. mit jeweils Category:Name, Relation:Name etc. in der URL

30 3 KONZEPT EINES WIKIS FÜR DAS SWP 27 aufgerufen werden. Kategorie Mit Hilfe von Kategorien können Seiten zu Artefaktklassen zugeordnet werden. Alle zu einer Kategorie zugeordneten Seiten kann man sich anzeigen lassen. Im SEWiki findet man einige Wichtige davon auf der Navigationsleiste. Dadurch ist der schnelle Zugriff auf die wichtigsten Seiten sichergestellt. Der Ausschnitt der Navigationsleiste ist in Abbildung Abbildung 18 zu sehen. Für jede Kategorie kann man definieren, welches Eingabeformular verwendet werden soll. Im SEWiki-Text kann man Seiten zu einer Kategorie durch folgendes Tag zuordnen: [[Category:UseCase]] Relation Relationen zeigen die Beziehungen der Seiten Abbildung 18: Navigationsleiste untereinander. Zum Beispiel ist in Abbildung 19 die Relation belongs to dargestellt. Dies ist eine Assoziation zwischen dem Use Case und der Projektseite. Um eine Relation zu einer Seite hinzuzufügen, wird folgendes Tag in den SEWiki-Text eingefügt: [[belongs to::sinologie Würzburg]] Attribute Durch Attribute werden Eigenschaften einer Seite beschrieben. Mit Hilfe der Eigenschaften werden wichtige Informationen in den Annotationen dargestellt. In Abbildung 19 sind die Attribute Titel, Status und Priorität definiert, die einen Use Case identifizieren. Um z.b. das Attribut Titel im SEWiki-Text hinzuzufügen benutzt man folgendes Tag: [[Titel:=Veranstaltungsdaten bearbeiten (RE5)]] Type Attribute haben einen bestimmten Datentyp, wie z.b. Enumeration, String, In-

31 3 KONZEPT EINES WIKIS FÜR DAS SWP 28 teger etc. Die Datentypen werden im späteren Verlauf beim Erzeugen von Eingabeformularen verwendet. Enthält ein Attribut den Datentyp Enumeration, wie in der Abbildung 19 das Attribut Status, dann wird in dem Eingabeformular eine Drop-Down-Box mit den möglichen Werten angezeigt. Zuerste wird auf der Attributseite Attribute:Status folgendes Tag hinzugefügt, um anzugeben, dass das Attribut den Datentyp Enumeration hat: [[has type::type:enumeration]] Die Aufzählung der Werte geschieht dann direkt dahinter folgendermaßen: [[allows value:=offen]], [[allows value:=begonnen]], [[allows value:=fertig]] Abbildung 19: Annotation zu einem Use Case Die vorgestellten 4 Konzepte sind die Hauptmerkmale für die Formalisierung der definierten Artefakte. Wenn sie nur manuell benutzt werden bedeutet das viel Aufwand. Deshalb werden, wie schon oben beschrieben, Vorlagen und Eingabeformulare generiert. Dadurch hat der Benutzer den Vorteil, dass er nur die Eingabefelder ausfüllen muss und die Zuordnung der Relationen und Attribute für den Benutzer unbemerkt im Hintergrund passiert. Die Vorlagen und Eingabeformulare werden als nächstes vorgestellt Ausgabe- und Eingabevorlagen Im Prototypen wird sehr viel mit Vorlagen und Eingabeformularen gearbeitet, um dem Benutzer den Umgang mit dem SEWiki zu vereinfachen und eine Struktur in die Dokumente zu bekommen. Ausgabevorlagen Als Erstes müssen die Vorlagen definiert werden, die für das Ausgeben der Informationen zuständig sind. Sie befinden sich im Namensbereich Template. Es werden als erstes in der dafür vorgesehenen Vorlage die Parameter übergeben,

32 3 KONZEPT EINES WIKIS FÜR DAS SWP 29 die vom Benutzer definiert werden sollen. Am Beispiel eines Use Cases kann es in Abbildung 20 verdeutlicht werden. Abbildung 20: Use-Case-Vorlage (Template:UseCase) Abbildung 21: Aufrufen einer Use-Case-Vorlage Es werden Parameter wie Titel, Projekt, Erstellt von etc. definiert. Diese Parameter werden dann Relationen oder Attributen zugeordnet. Es werden auch die Bezeichnungen, die vor den übergebenen Parametern angezeigt werden nach dem! definiert. Nachdem die möglichen Parameter definiert wurden, kann die Ausgabevorlage aufgerufen werden. Dabei werden die Parameter mit Werten initiiert. Der Aufruf

33 3 KONZEPT EINES WIKIS FÜR DAS SWP 30 der Use-Case-Vorlage wird in Abbildung 21 demonstriert. Sind alle notwendigen Parameter übergeben worden und die Seite gespeichert, so wird die neu erstellte Wiki-Seite ausgegeben. Sie sieht für ein Use Case im Prototypen so wie in Abbildung 22 aus. Abbildung 22: Anzeige eines Use Cases Eingabevorlagen Damit der Benutzer die Augabevorlagen nicht manuell aufrufen muss, werden Eingabevorlagen definiert. Diese beschreiben die Struktur und Darstellung der Eingabeformulare, die vom Benutzer ausgefüllt werden, um eine neue Seite zu erstellen oder eine bestehende zu ändern. Eingabevorlagen definieren auch, welche Ausgabevorlagen verwendet werden sollen. Die Parameter müssen aus diesem Grunde bei beiden Arten von Vorlagen gleich sein, d.h. für die Parameter, die in den Ausgabevorlagen definiert wurden, muss nun ein passendes Eingabefeld generiert werden, um den Parameter so zu übergeben. Die Eingabevorlage für einen Use Case ist in Abbildung 23 dargestellt. In dem gezeigten Abschnitt wird nur die Use-Case-Vorlage benutzt. Es wird

34 3 KONZEPT EINES WIKIS FÜR DAS SWP 31 Abbildung 23: Use-Case-Eingabevorlagen eine Tabelle dargestellt, wobei hier mit Absicht verdeutlicht werden soll, dass die Wiki-Syntax auch HTML-Syntax akzeptiert. Die Tabelle ist in HTML dargestellt. Eine Tabelle, dargestellt durch die Wiki-Syntax, wurde bereits in Abbildung 20 verwendet. Die auf diese Weise definierte Eingabevorlage wird zum Eingabeformular generiert. Dies ist das Formular, mit dem der Benutzer neue Artefakte erstellen bzw. bereits vorhandene bearbeiten kann. Das Eingabeformular für einen Use Case ist in Abbildung 24 zu sehen.

35 3 KONZEPT EINES WIKIS FÜR DAS SWP 32 Abbildung 24: Generiertes Use-Case-Eingabeformular 3.3 Arbeiten mit dem SEWiki Rechtevergabe Um den Aspekt der Zugriffsrechte aus Abschnitt nochmal aufzugreifen, beschäftigt sich dieses Kapitel mit den Benutzerrechten. In Tabelle 3 ist die Rechtezuordnung zu den einzelnen Gruppen dargestellt. Es wird zwischen vier Gruppen unterschieden, zwischen der Gruppe der anonymen und den berechtigten Benutzern des SEWikis, den Administratoren und den Bureaukraten, die durch die Projektleiter vertreten sind. Ein - bedeutet in der Tabelle, dass der Gruppe das Recht nicht gegeben ist, während bei einem + das Recht vergeben wurde. Ein anonymer Benutzer, der nur der allgemeinen Gruppe * angehört, jedoch nicht den anderen Gruppen, soll keine Rechte erhalten. Sie hat lediglich die Möglichkeit sich die Hauptseite anzusehen, die Hilfeseite, die das Einloggen beschreibt und die Login-Seite selbst, um sich anmelden zu können. Sobald sich eine Person eingeloggt hat, gehört sie zu den restlichen 3 Gruppen. Die jeweiligen Gruppen haben die in der Tabelle 3 für ihre Gruppe aufgelisteteten Rechte.

36 3 KONZEPT EINES WIKIS FÜR DAS SWP 33 Benutzergruppen Rechte * user/ sysop/ bureaucrat/ Benutzer Admin Projektleiter block Benutzer sperren createaccount delete edit editinterface Benutzeroberfläche anpassen move Artikel verschieben patrol Artikel als geprüft markieren protect Artikel vor Bearbeitung schützen read renameuser rollback Artikel auf älteren Stand zurücksetzen upload userrights Userrechte bearbeiten edit - Hauptseite und die Verlinkungen (Projekt erstellen, neuer Projekttermin) edit - Hilfeseiten für Benutzer edit - Hilfeseiten für Administratoren edit - Template edit - Formular read - Hauptseite read - Hilfeseite Help:Anmelden read - Hilfeseite Help:Contents read - Spezialseite Special:Userlogin Tabelle 3: Überblick über die Rechte in dem SEWiki Da Administratoren für das einwandfreie Funktionieren des Prototypen zu sorgen haben, sind ihnen alle Rechte gegeben. Der Projektleiter hat eine spezielle Aufgabe, das Projekt zu organisieren und zu überwachen. Ihm sind mehr Rechte zugeteilt als den restlichen Benutzern, da bestimmte Funktionen möglichst nur einer Person zur Verfügung stehen sollen, um einen Überblick zu behalten. Der Projektleiter hat zu den Rechten der zugelassenen Benutzer zusätzlich die Möglichkeit Artikel als geprüft zu markieren und Benutzer umzubenennen. Desweiteren kann er Artikel vor Bearbeitung schützen. Da das SEWiki alle Dokumente eines Projektes beinhalten und sie jedem Projektbeteiligten beliebig zur Verfügung stehen, können die Dokumente leichter geändert werden. Eine fertige Version wird es also in dem Sinne nie

37 3 KONZEPT EINES WIKIS FÜR DAS SWP 34 geben können. Aus diesem Grunde soll der Projektleiter entscheiden, wann ein Dokument ihm als fertig erscheint und dieses dann vor Bearbeitung schützen. Weiterhin würde dann die Möglichkeit bestehen über dieses Dokument zu diskutieren. Sollte mehrheitlich entschieden werden, dass das Dokument noch nicht vollständig ist, so muss der Projektleiter dieses wieder zur Bearbeitung freigeben. Benutzer haben generell nicht die Möglichkeit für sich einen Account anzulegen. Das Anlegen eines Accounts erfolgt immer durch den Administrator. Damit ist sichergestellt, dass der Zugang nur Projektbeteiligten zur Verfügung steht. Die Rechte für das Löschen von Seiten hat auch einzig und allein ein Benutzer mit Administratorrechten. Dadurch soll sichergestellt werden, dass die Projektbeteiligten nicht beliebig Seiten löschen können. Diese sind zwar wiederherstellbar, jedoch schwer auffindbar. Eine Seite, die nicht existiert, kann meist nur auf Spezialseiten angezeigt werden Integration des Use Case DODE Das SEWiki soll den Benutzern als Verwaltung von Dokumenten dienen. Ausserhalb des SEWikis sollen möglichst wenig bis gar keine Dokumente existieren. Um dies gewährleisten zu können, müssen Dokumente, die mit externen Werkzeugen erstellt werden, entweder hochgeladen oder, und das ist die bessere Variante, die zusätzlich benutzten Werkzeuge müssen in das Wiki integriert werden. Hier soll, am Beispiel des Use Case DODE, vorgestellt werden, was dafür notwendig ist. Man kann die Einbindung der Dokumente, die mit dem Use Case DODE erstellt werden, in drei Schritte aufteilen. Abbildung 25 stellt die einfachste Möglichkeit vor. Nach dem Erstellen einer Use-Case-Beschreibung im DODE, kann diese als HTML-Dokument exportiert werden. Da das SEWiki HTML-Syntax-kompatibel ist, kann durch copy and paste die Use-Case-Beschreibung in das SEWiki manuell eingefügt und gespeichert werden. Abbildung 25: 1.Schritt copy and paste Der nächste Schritt, der zu tun wäre, ist einen Parser zu intergrieren, der die Use- Case-Beschreibung aus dem Wiki in den Use Case DODE übertragen würde. Die Grundlage dafür bietet die Socket-Programmierung. In Abbildung 26 ist das be-

38 4 TUTORIAL 35 schriebene Vorgehen abstrakt dargestellt. Der letzte Schritt wäre eine komplette Abbildung 26: 2.Schritt Erzeugen eines Parser um die UseCases aus dem Wiki zu laden Integration des Use Case DODE in das Wiki. Dabei würden aus dem DODE durch Synchronization alle Use Cases, die im Wiki enthalten sind, ausgelesen werden. Diese könnten dann im Use Case DODE bearbeitet und wieder in das Wiki geladen werden. Die Grundlage hierfür ist auch die Socket-Programmierung. Dafür werden einige Daten gebraucht, die vom Use Case DODE bzw. vom Wiki vorgegeben sein müsste, wie z.b. Datum und Uhrzeit, User-Daten etc. Abbildung 27 zeigt die Idee der Integration abstrakt. Abbildung 27: 3.Schritt Komplette Integration 4 Tutorial - Arbeiten mit der Anforderungsspezifikation Um die Benutzung des Wiki zu verdeutlichen, wird in diesem Abschnitt die Erstellung einer Anforderungsspezifikation mit den notwendigen Schritten dargestellt. Es sollen auch ein paar Zusatzfunktionen vorgestellt werden, die dem Benutzer das Arbeiten mit dem SEWiki erleichtern sollen. Projektseite Bevor eine Anforderungsspezifikation überhaupt erst erstellt werden kann, muss

39 4 TUTORIAL 36 das Projekt existieren. Die Use-Case-Beschreibung zum Erstellen eines Projektes befindet sich im Anhang. Nachdem das Projekt existiert, ist es in die bereits oben beschriebenen Artefakte unterteilt. Ein Inhaltsverzeichnis, zu sehen in Abbildung 28, soll einen Überblick über die einzelnen Artefakte bieten. Die Artefakte Termine, Aufgaben und Mitarbeiter sollten als Erstes fertiggestellt werden, aus dem Grunde, da diese nicht nur auf der Projektseite, sondern auch in der Anforderungs- und Abbildung 28: Das Inhaltsverzeichnis eines Projektes Entwurfsspezifikation aufgelistet werden. Ein Beispiel für die Auflistung dieser Artefakte ist in Abbildung 29 zu sehen. Hier sind die Aufgaben auf der Projektseite dargestellt. Um eine neue Aufgabe hinzuzufügen, benutzt man den Link Neue Aufgabe unter der Auflistung. Abbildung 29: Auflistung der Aufgaben auf der Projektseite Erstellen und Bearbeiten einer Anforderungsspezifikation Zum Erstellen einer Anforderungsspezifikation benutzt man den dafür vorgesehenen Link Anforderungsspezifikation erstellen auf der Projektseite. Es erscheint das in Abbildung 30 dargestellte Eingabeformular. Da für jedes Projekt nur eine Anforderungsspezifikation existiert, sollte man diese auch nur ein einziges Mal erstellen. Sollte die Anforderungsspezifikation erneut erstellt werden, so wird die

40 4 TUTORIAL 37 Abbildung 30: Das Formular beim Erzeugen einer Anforderungsspezifikation bereits gespeicherte Version überschrieben. Diese überschriebene Version kann wiederhergestellt werden. Nach dem Ausfüllen der Felder kann man zuerst optional eine Vorschau sehen ( Vorschau zeigen ). Wurde die Seite gespeichert, so erscheint eine Seite mit der Vorlage für die Anforderungsspezifikation, von der die Überschriften bereits in Tabelle 1 gezeigt wurden. Um effizientes Arbeiten mit der Vorlage zu ermöglichen, enthält die Anforderungsspezifikation ein Inhaltsverzeichnis. Ein wichtiger Punkt der Anforderungsspezifikation sind Use Cases. Diese können in dem dafür vorgesehenen Abschnitt erzeugt werden. In der Anforderungsspezifikation selbst werden sie mit den wichtigsten Attributen und Relationen kurz aufgelistet. Abbildung 31 stellt ein Beispiel einer solchen Auflistung dar. Die Eingabeformulare für Use Cases wurden in Abschnitt gezeigt. Abbildung 31: Auflistung der zu dem Projekt gehörenden Use Cases Hilfestellungen des SEWikis Um effizientes Arbeiten zu ermöglichen, bietet das SEWikis einige Hilfestellungen. Besonders bei der Einarbeitung in das SEWiki, werden die Hilfeseiten, ba-

41 4 TUTORIAL 38 Abbildung 32: Die Hilfeseiten des SEWikis sierend auf [6], hilfreich sein. Diese sollen von den Projektbeteiligten im weiteren Verlauf ergänzt werden, sodass man die am häufigsten benutzten Funktionen jederzeit nachschlagen kann. Eine Übersicht über die bereits enthaltenen Themen bietet Abbildung 32. Abbildung 33: TODO-Vorlage, zum Da jedes Projekt im Laufe der Zeit mehr und mehr Dokumente enthält, ist ein Überblick über die noch anstehenden Aufgaben wichtig. Diese Aufgabe soll die Vorlage TODO (Abbildung 33) übernehmen, die einfach an die zu bearbeitende Textstelle eingefügt werden soll. Mit Hilfe der Backlinks kann man Einfügen an die Stelle, die noch bearbeitet werden soll sich alle Seiten ausgeben lassen, die diese Vorlage benutzen. Auf der Hauptseite befindet sich ein Link zu dieser Seite (siehe Abbildung 12), sodass durch einen Mausklick die anstehenden Aufgaben angezeigt werden. Fertigstellen der Anforderungsspezifikation Für die Abgabe der Anforderungsspezifikation ist ein Abgabedatum vorgegeben. Die Abgabe sollte nach aller Möglichkeit in pdf- bzw. Word-Format erfolgen.