Archäologie Informationssystem (AIS)

Aufwandsabschätzung

(nach "Applying Use Cases" von Booch, Jacobson, Rumbauch)

Home

Aufgabestellung

Use Cases & Actoren

Aufwandsabschätzung

Architektur

Prototyp

Auf dieser Seite wird eine Abschätzung des Zeitaufwands präsentiert. Diese Abschätzung soll als Grundlage dienen, um innerbetrieblich und auch mit dem Kunden folgende Fragen zu diskutieren und abzuklären.

Wieviel Geld steht wann zur Verfügung ?
Soll (kann) unter diesen finanziellen Bedingungen das ganze System auf einmal realisiert werden, oder werden gewisse Funktionalitäten in ihrer Priorität herabgestuft um den finanziellen Rahmen einhalten zu können ?
Ist es möglich in der zu Beginn vereinbaren Zeit (bis Ende Jänner) das System als Ganzes zu realisieren ?
Wie hart ist der Termin, bzw. welche Folgen resultieren aus einer Terminüberschreitung.

Ziel ist es, sich in all diesen Fragen mit dem Kunden zu einigen und einen Kompromiss bezüglich Zeit, Kosten und Systemumfang zu finden.

Bewertung von Aktoren

Diese geschieht dadurch, dass man zu jedem Aktor bestimmt, ob dieser einfach(weiters e),durchschnittlich(weiters d) oder komplex(weiters k) ist. Ein einfacher Aktor repräsentiert ein anderes System mit wohldefiniertem API. Ein durchschnittlicher Aktor ist ein anderes System, das durch z.B. TCP/IP mit unserem System kommuniziert oder eine Person, die durch einen text-based Interface mit unserem System kommuniziert. Ein komplexer Actor ist eine Person, die mit unserem System durch unsere GUI kommuniziert. Sehen wir nun nochmals die Aktoren. Neben ihren Namen steht in Klammern zu welcher Gruppe sie gehören.

Internetbesucher(k): Ist eine Person, die über das Internet ein virtuelles Museum besucht und dort Daten zu ausgestellten Artefakten, Siedlungen und Gräbern lesen (hören, ansehen) und auch nach diesen suchen kann.
Archäologiestudent(k): Ist eine Person, die die Rechte eines Internetbesuchers hat (also kann auch als Besucher auftreten). Weiters können alle Daten in der Datenbank gelesen und gesucht werden.
Erfasser(d): Ist eine Person, die Grunddaten erfasst, editiert und Beziehungen zwischen diesen hinterlegt. Weiters wählt der Erfasser Daten aus der Datenbank aus um daraus ein virtuelles Museum aufzubauen. Der Erfasser hat auch die Rechte des Internetbesuchers und des Archäologiestudenten.
Wissenschaftlicher Erfasser(k): Ist ein Achäologe (Wissenschaftler), der erweiterte Daten (Publikationen und Interpretationen) erfasst und Beziehungen zwischen allen Daten hinterlegen kann. Weiters hat er die Rechte von Internetbesucher, Archäologiestudent und Erfasser.
Administrator(k): Ist eine Person, die Benutzer des Systems anlegt oder löscht und ihnen entsprechende Rechte zuordnet. Der Administrator erstellt auch repräsentative Medien (CD-ROMs und Kataloge) und besitzt weiters die Rechte des Internetbesuchers.
SE AG-Angestellter(e): Eine Person, die für die Wartung und Pflege des ganzen Systems zuständig ist.
Datenbanksystem(e): Ist das Datenbanksystem in dem die Daten erfasst und in weiterer folge abgerufen werden können.
CD-Brenner - einfach
Drucker - durchschnitt

Es muss jetzt jede Komplexitätsgruppe gewichtet werden.

$\begin{displaymath}3 e * 1 = 3 \end{displaymath}$
$\begin{displaymath}2 d * 2 = 4 \end{displaymath}$
$\begin{displaymath}4 k * 3 = 12 \end{displaymath}$

Somit ergibt sich für die Gesamtgewichtung der Actors: 3 + 4 + 12 = 19

Bewertung von Use Cases

Hier erfolgt eine Einteilung der Use Cases in die Klassen simple, average und complex auf Grund der Anzahl der Transaktionen die die jeweiligen Use Cases enthalten.

Simple Use Case: Mit drei oder weniger Transaktionen.
Average Use Case: Mit vier bis sieben Transaktionen.
Complex Use Case: Mit mehr als sieben Transaktionen.

Einteilung der Use Cases in Klassen

Tabelle 1: Zuordnung der Use Cases zu den entsprechenden Komplexitätsklassen

Use Case	Simple	Average	Complex
NeuesObjektAnlegen	X
AttributePflegen		X
NeuenBenutzerAnlegen		X
BenutzerProfilEditieren			X
NeuesVMAnlegen			X
VMEditieren			X
SuchenInDatenbank			X
SuchenNachDaten		X
ObjektLöschen	X
BenutzerLöschen	X
VMLöschen	X
CDROMErstellen		X
KatalogErstellen		X
VMEditieren	X
ÄnderungenSpeichern	X

Berechnung der Komplexität

Die Anzahl der simple Use Cases wird mit Gewichtungsfaktor 5 multipliziert, die der average Use Cases mit Gewichtungsfaktor 10, die der complex Uses Cases mit 15. Zusammen mit obiger Tabelle ergibt sich dann folgende Berechnung. $\begin{eqnarray*}6\ simple\ Use\ Cases * 5 = 30 \\5\ average\ Use\ Cases * 10 = 50 \\4\ complex\ Use\ Cases * 15 = 60\end{eqnarray*}$ Daraus ergibt sich ein Gesamtwert von 30 + 50 + 60 = 140

Berechnung der UUCP (unadjusted use case points) Dazu werden Actor-Gesamtbewertung und Use-Case-Geamtbewertung addiert. Also,

$\begin{displaymath}UUCP = 19 + 140 = 159\end{displaymath}$

Bewertung von technischen Faktoren

In diesem Schritt erfolgt die Berechnung des TCF (Technical Complexity Factor). Fangen wir an, die technische Komplexität des Projektes auszurechnen. Um diesen Faktor ausrechnen zu können müssen wir in der folgenden Tabelle die Faktor mit Gewichtungen von 0 bis 5 bewerten. 0 heißt, dass der Faktor aus der Sicht unseres Projekts irrelevant ist, 5 heißt er ist essenziell.

Tabelle 2: Tabelle zur Berechnung des technischen Komplexitätsfaktors(TCF)

TCF Tabelle
Faktornummer	Beschreibung	Gewichtsfaktor	Gewicht
T1	Distributiertes System	5	2
T2	Webbasiert	5	1
T3	Komplex interne Prozessierung	1	1
T4	Wiederverwendbare Code	1	0
T5	Leicht zu Installieren	2	0.5
T6	Benutzerfreundlichkeit	5	0.5
T7	Portabilität	1	2
T8	Leicht zu ändern	2	1
T9	Erlaubt zugriff zur dritten Parteien	5	1
T10	Spezielle Sicherheitsvorkerhrungen	1	1
T11	Spezielle Benutzeraubildung	0	1

Zur Berechnung von TCF wir gehen durch die Tabelle und bilden die folgenden Summe:

$\begin{displaymath}T_{Faktor} = \sum_{i=1}^{10} Gewichtsfaktor_i*Gewicht_i = 29,5\end{displaymath}$

(1)

Damit ist dann TCF

$\begin{displaymath}TCF=0.6 + 0.01*T_{Faktor}= 0,895\end{displaymath}$

(2)

Bewertung der personellen Faktoren

EF (Enviromental Factors): Dieses Faktor repräsentiert u. a. die Erfahrenheit der am Projekt beteiligten. 0 bedeutet das negative Ende der Skala 5 heißt das positive Ende der Skala.

Tabelle 3: Tabelle zur Berechnung des enviromental Faktors (EF)

EF Tabelle
Faktornummer	Beschreibung	Gewichtsfaktor	Gewicht
F1	Rational Unified Prozess bekannt	1	1.5
F2	Applikationserfahrung	3	0.5
F3	Erfahrung mit OO Programmierung	3	1
F4	Führende Beraterqualitäten	3	0.5
F5	Motivation	4	1
F6	Stabile Voraussetzungen	3	2
F7	Teilzeitmitarbeiter	5	-1
F8	Komplexe Programmiersprache	4	-1

Von der Tabelle mit Hilfe der Formel:

$\begin{displaymath}EF_{Faktor} = \sum_{i=1}^8 Gewichtsfaktor_i*Gewicht_i = 8.5\end{displaymath}$

(3)

Davon EF:

$\begin{displaymath}EF=1.4 + (-0.03)*EF_{Faktor} = 1.145\end{displaymath}$

(4)

Use Case-Punkte

Aus den berechneten Werten können wir nun UCP (use case points) berechnen: $\begin{displaymath}UCP=UUCP*TCF*EF=159*0.895*1.145=162.9392 \end{displaymath}$

An diesem Punkt werden die benötigten Arbeitstunden berechnet. Um das machen zu können, bestimmen wir die Anzahl der Arbeitsstunden die einem UCP-Punkt entsprechen. In unserem Fall gibt es 1 Punkt zwischen F1-F6, dessen Faktor unter 3 liegt und 2 Punkte zwischen F7-F8, deren Faktor über 3 liegt. In diesem Fall sind jedem UCP - Punkt 28 Arbeitsstunden zuzuordnen (nach dem Buch Applying Use Cases Booch, Jacobson, Rumbauch).

$\begin{displaymath}Arbeitsstunden=UCP*28=162.939*28=4562.2983\end{displaymath}$

Also, eine Person bräuchte 4562.2983 Stunden, d.h. etwa 114 Wochen (mit 40 Stunden pro Woche). Da wir zu viert in unseren Gruppe sind, brauchen wir 28.5 Wochen (full-time) für die Implementation und zusätzlich 2-3 Wochen für Einarbeitung sowie Testen.