1 - Requirement Management Systeme. Suche und Bewertung geeigneter Tools in der Software-Entwicklung [Seite 1]
1.1 - Inhaltsverzeichnis [Seite 3]
1.2 - Abbildungsverzeichnis [Seite 5]
1.3 - Tabellenverzeichnis [Seite 7]
1.4 - Abkürzungsverzeichnis [Seite 8]
1.5 - Vorwort [Seite 9]
1.6 - Abstract [Seite 10]
1.7 - Danksagung [Seite 11]
1.8 - 1. Einleitung [Seite 13]
1.8.1 - 1.1 Motivation [Seite 14]
1.8.2 - 1.2 Zielsetzung und Konzeption dieser Arbeit [Seite 15]
1.9 - 2. Requirement, Requirements Management und Requirements Engineering [Seite 17]
1.9.1 - 2.1 Requirements Management [Seite 18]
1.9.2 - 2.2 Requirements Engineering [Seite 18]
1.9.3 - 2.3 Requirements [Seite 19]
1.10 - 3 Application Lifecycle Management [Seite 25]
1.10.1 - 3.1 Was ist ALM ? [Seite 25]
1.10.2 - 3.2 Nutzen von Application Lifecycle Management [Seite 29]
1.10.3 - 3.3 ALM Lösungswerkzeuge [Seite 31]
1.10.4 - 3.4 Vorgehen der Evaluation [Seite 31]
1.11 - 4 Die ALM Lösungswerkzeuge im Detail [Seite 34]
1.11.1 - 4.1 CaliberRM von Borland [Seite 34]
1.11.2 - 4.2 Polarion Requirements 1.0.1 von Polarion [Seite 61]
1.11.3 - 4.3 Visual Studio Team System von Microsoft [Seite 91]
1.12 - 5 Zusammenfassung und Ausblick [Seite 92]
1.13 - Anhang [Seite 101]
1.14 - Glossar [Seite 113]
1.15 - Literaturverzeichnis [Seite 115]
Textprobe:
Kapitel 4.1.5, Multiuserfähigkeit des CaliberRM:
In dem CaliberRM ist ein Rollenkonzept integriert, das bedeutet, dass vom Administrator beliebig viele Rollen vergeben werden können. Welche das sein können sind zum Beispiel in Abbildung 12: Benutzeransicht im CaliberRM Administrator und in Abbildung 13: Gruppenansicht im CaliberRM Administrator dargestellt. Der CaliberRM Administrator kann deswegen neue Benutzer und neue Gruppen erstellen. Jede von den Rollen hat ein eigenes Passwort, welches in regelmässigen Abständen geändert werden muss. Die Zugriffsrechte werden in CaliberRM auf Rollenebene vergeben und werden automatisch vererbt. Das bedeutet, das der Benutzer einer Rolle auch sämtliche Zugriffsrechte dieser Rolle erbt.
Bevor der Benutzer mit der eigentlichen Eingabe und Bearbeitung von Requirements überhaupt beginnen kann, muss man als erstes im CaliberRM Administrator das Projekt definieren, beziehungsweise neu erstellen. In unserem Fall wird das in Kapitel 3.4 beschriebene Praxisbeispiel Adressbuch angewendet. Im Administrator werden Angaben wie, wer am Projekt beteiligt ist und welche Gruppen mitwirken dürfen, festgelegt. Hierzu stehen die folgenden Views zur Verfügung:
Es gibt vier Ansichten, die in dem Menüfeld unter View oder Iconleiste hin- und herschaltbar sind:
- Projektansicht.
- Benutzeransicht.
- Gruppenansicht.
- Ansicht zum Überwachen von Benutzerverbindungen (Monitor).
In der Projektansicht werden alle Projekte aufgeführt und die für ein ausgewähltes Projekt spezifischen Informationen angezeigt, beispielsweise allgemeine Projektinformationen (Project Info), die dem Projekt zugewiesenen Benutzer und Gruppen (Group Assignment), Projekt-Baselines und Projektintegrationen (External Traceability).
4.2.2, Die Software-Entwicklungsphasen im Polarion Requirements:
Das Polarion Requirements unterstützt den Softwareentwicklungsprozess nicht in allen Phasen. Hauptaugenmerk liegt hier in der Analysephase die ganz abgedeckt ist.
Planungsphase:
Diese Phase wird von Polarion Requirements nicht unterstützt.
Analysephase:
Requirement Findung (Elicitation) ist Kernbestandteil des Requirements Management und deswegen von sehr hoher Bedeutung. Im Polarion Requirements werden Requirements definiert, festgehalten und gesammelt. Über Diskussionsforen können auch Feedback über Requirements abgegeben werden.
Designphase:
Diese Phase wird von Polarion Requirements nicht unterstützt.
Implementierungsphase
Die Codierung beziehungsweise die Implementierung der Software wird im Polarion Requirements nicht unterstützt.
Testphase:
Validierungskriterien können an den Anforderungen hinterlegt werden. Diese Kriterien können in Polarion Requirements zu Testspezifikationsanforderungen zusammengefasst werden. Die eigentliche Testspezifikation sowie Durchführung der Tests erfolgt jedoch nicht mehr im Polarion Requirements.
Releasephase:
Diese Phase wird im Polarion Requirements durch das Baselining unterstüzt, mit der Planung der Baselines sowie mit der Baseline Wartung ist die Zuordnung von Anforderungsversionen zu Baseline und die Zuordnung von Anforderungensversionen zu entsprechenden Releases in der Entwicklung möglich.
