Ergebnisse

Ergebnisse der eMeasurement-Befragung

Die initiierte webbasierte Befragungsaktion soll nun adäquate Ergebnisse hinsichtlich der Realisierung eines webbasierten Portals zur funktionalen Größenmessung liefern.
Da diese Befragungsaktion noch nicht vollständig abgeschlossen ist, sollen im Folgenden erste Ergebnisse in Form eines Zwischenergebnisses präsentiert werden.
Aus diesem Zwischenergebnis können schon jetzt interessante Fakten identifiziert werden, die für die Implementierung einer ersten Version des eMeasurement-Portals hilfreich sind.

Allgemeiner Teil

Um eine Begründung für den Bedarf und die Akzeptanz eines derartigen Portals zu finden, wurde in dem Fragebogen zuerst danach gefragt, ob ein derartiges Portal überhaupt sinnvoll erscheint.
Als Ergebnis hat die überwältigende Mehrheit von über 90 Prozent der Befragten diese Frage bejaht.
 

bild1

Einschränkend muss an dieser Stelle jedoch erwähnt werden, dass die Befragungsaktion auf fakultativer Basis erfolgte und noch erfolgt und sich die Teilnehmer im Fachkreis der eMeasurement-Interessenten befinden, und so tendenziell positiv diesem Themenkomplex gegenüberstehen. Allerdings sind es ja auch gerade diese, die die Zielgruppe und damit die potentiellen Nutzer des zu realisierenden Portals sind.
Da die Befragten also offensichtlich ein derartiges Portal als sinnvoll einschätzen und dieses bejahen, stellt sich natürlich die Frage, ob es schon ein vergleichbares Angebot eines derartigen Portals von einem anderen Anbieter gibt. Dies ist deshalb wichtig, um die Marktchancen eines solchen Portals besser ausloten zu können. Nur, wenn die Konkurrenzsituation am Markt dies zulässt, ist mit einer adäquaten Nutzermenge zu rechnen. Folglich wurde deshalb gefragt, ob ein ähnlicher webbasierter eMeasurement-Dienst den Befragten bekannt ist.

bild2

Wie aus obiger Abbildung ersichtlich ist, kennen über 70 Prozent der Befragten keinen vergleichbaren Dienst. Bei der Auswertung wurde festgestellt, dass einige Teilnehmer der Befragungsaktion tatsächlich einen vergleichbaren Dienst kennen. Bei genauerer Analyse jedoch konnte festgestellt werden, dass diese Gruppe der Befragten hauptsächlich hier die ISBSG anführte.
Das zu realisierende Portal soll jedoch kein Konkurrenzangebot zur ISBSG darstellen, vielmehr soll mittels des Portals u. a. auf Daten der ISBSG zugegriffen werden.
Bei nachträglicher selbstkritischer Einschätzung hätte diese Frage etwas ausführlicher formuliert werden müssen, um so diesem Missverständnis vorzubeugen.
Zusammenfassend lässt sich daher schlussfolgernd festhalten, dass Konkurrenzangebote zu dem zu realisierenden Portal, zumindest bis zum jetzigen Stand der Ergebnisse, nahezu nicht bekannt sind. Folglich stellt das zu realisierende Portal eine Neuheit dar und sollte dementsprechend auf reges Interesse in der Fachwelt stoßen.
Für die Realisierung eines solchen Portals ist es natürlich von entscheidender Bedeutung, welche Messausprägungen vom Portal zur Verfügung gestellt werden. Dazu wurde eine Abgrenzungsanalyse durchgeführt, bei der die Befragten ausgewählte Messmethodenarten entsprechend ihrer Wichtigkeit einschätzen sollten. Die Ergebnisse sind in folgender Abbildung visuell dargestellt.
 

bild3

Wie hieraus ersichtlich ist, stufen über 90 Prozent der Befragten den Komplex der funktionalen Größenmessung (FSM) als sehr wichtig oder wichtig ein. Folglich findet hierdurch die Konzentration des Portals auf den Komplex der FSM seine Begründung.
Aber auch die anderen Methoden sind in den Augen der Befragten nicht weniger wichtig. Insbesondere der Komplex der webbasierten Kundenzufriedenheitsmessung und des webbasierten Assessments stehen offensichtlich hoch im Kurs der Befragten, so dass auch diese und andere Methoden zu einem späteren Zeitpunkt in das Portal mit integriert werden sollten, um einen ganzheitlichen Ansatzpunkt für ein webbasiertes eMeasurement zu schaffen.
Zusätzlich zu diesen in der Abgrenzungsanalyse zur Auswahl gestellten Methoden wurde den Befragten auch die Möglichkeit eröffnet, eigenes Gedankengut mit einzubringen und dies wurde auch rege genutzt. So konnten weitere Messfunktionalitäten identifiziert werden. Die folgende Tabelle beinhaltet die am häufigsten genannten Funktionalitätsanforderungen:

Was könnte man noch messen? 
 

  • Prozessreife nach CMM (Capability Maturity Modell)
  • Combinatory Metrics (QFD)
  • Service Level
  • Performance of Web Services
  • Complexity of OO-Design
  • Defects
  • Fehlervorhersagemodelle
  • Projektnachkalkulationen
  • Technologietrends
  • Methodenbewertung
  • Entwicklungsaufwand
  • Fehlerraten
  • Testumfang
  • Qualitätsmetriken
  • Performance Daten

Um die Akzeptanz dieser zusätzlichen Funktionalität festzustellen, müsste zu einem späteren Zeitpunkt eine erneute Abgrenzungsanalyse in Form einer multiattributiven Messung durchgeführt werden.

eMeasurement auf Basis von FSM

Bevor diese und weitere Messfunktionalitäten implementiert werden können, muss natürlich erst einmal ein Portal mit einer Grundfunktionalität geschaffen werden. Und da über 90 Prozent der Befragten sich hierbei für die funktionale Größenmessung ausgesprochen haben, sollte sich, zumindest im 1. Schritt, die Funktionalität auf das FSM beschränken.
Nun gibt es aber, wie schon im Kapitel 3 dieser Diplomarbeit beschrieben, eine Vielzahl von FSM-Methoden. Interessant war es daher zu wissen, welche davon für wichtig und welche für unwichtig gehalten werden.
Hierzu wurde ebenfalls eine Abgrenzungsanalyse durchgeführt, die die in der folgenden Abbildung dargestellten Ergebnisse lieferte.
 

bild4

Demnach führt die IFPUG FPA-Methode in den Augen der Befragten ganz klar. Über 80 Prozent halten diese für sehr wichtig oder wichtig. Auf Rang zwei folgt die FFP-Methode, bei der im Übrigen bei der Befragung nicht zwischen FFP 1.0 und COSMIC FFP unterschieden wurde, mit ca. 70 Prozent.
Interessant ist hier das Abschneiden der anderen beiden Methoden, die mehrheitlich ganz klar als weniger wichtig oder unwichtig eingestuft wurden. Demnach besitzt die MKII FP bei den Befragten nur noch eine Wichtigkeit von knapp 30 Prozent und die NESMA-Methode gerade etwas mehr als 20 Prozent. Folglich sollten diese beiden letztgenannten FSM-Methoden bei der Realisierung des Portals keine Berücksichtigung finden.
Das Votum der Befragten liegt also ganz eindeutig auf Seiten der IFPUG FPA- und der FFP-Methode. Demzufolge sollte sich das FSeMP auf diese Methoden beschränken, um den Bedürfnissen der potentiellen Nutzer gerecht zu werden und zusätzlich den Entwicklungsaufwand des Portals zu reduzieren.
Als nächstes war von Interesse, welche Funktionalität ein solcher Measurement-Dienst bereitstellen sollte. Auch hier wurde den Befragten eine Vorauswahl angeboten. Die Ergebnisse sind in folgender Abbildung visuell dargestellt.
 

bild5

Demnach hält die überwiegende Mehrheit der Befragten im Grunde genommen alle zur Auswahl stehenden Funktionalitäten für wichtig oder gar sehr wichtig. Es wäre daher sinnvoll, alle angebotenen Funktionalitäten schrittweise in das Portal zu integrieren. Auffällig hierbei ist jedoch, dass vor allem das Backfiring sowie das eLearning mit einer Ablehnungsquote von 30 Prozent herausstechen. Offensichtlich wirkt beim Backfiring die Tatsache, dass es sich hierbei, wie auch schon im Kapitel 3 dieser Arbeit beschrieben, um eine sehr umstrittene und in Fachkreisen viel diskutierte Methode handelt.
Beim eLearning dagegen könnte als Begründung herhalten, dass es sich bei den Befragten um Experten handelt, die in der Regel wenig eLearningfunktionalität benötigen. Trotzdem sollte aber gerade für Erstnutzer des Portals eine adäquate eLearningfunktionalität zur Verfügung stehen.
Bei der Analyse der Ergebnisse dieses Themenkomplexes stechen insbesondere 3 Funktionalitäten hervor:

  1. die Dashboards,
  2. die Schätzungen auf Grundlage von empirischen Daten und Prozessmetriken
  3. sowie die Cockpitcharts.

Folglich sollten diese Funktionalitäten als erstes in das Portal integriert werden.
Im Folgenden sollen die einzelnen Ergebnisse der Funktionalitäten näher betrachtet werden:

Vergleich von Erfahrungskurven, Upload/Download ISBSG

Auf die Frage, ob es sinnvoll erscheint, Erfahrungskurven zu schätzen, antworteten ca. 75 Prozent der Befragten mit ja und nur 3,5 Prozent mit nein.

Offensichtlich würde eine Mehrheit der Befragten diese Funktionalität nutzen wollen. Weiterhin lässt sich feststellen, dass ca. 90 Prozent der Befürworter einer Schätzung von Erfahrungskurven diese gerne mit Kurven aus Datenbanken vergleichen wollen.
Hierbei können sowohl externe Datenbanken wie beispielsweise die ISBSG-Projektdatenbank als auch die interne Datenbank des Portals herangezogen werden. Auch besteht die Bereitschaft, sich für diese Zwecke an dem Aufbau einer entsprechenden Datenbank zu beteiligen, indem die eigenen Daten anonymisiert zur Verfügung gestellt werden.
Es gibt jedoch auch einige wenige kritische Stimmen zu diesem Punkt. Offensichtlich ist das Vertrauen auf die Anonymisierung der Daten nicht bei allen Teilnehmern der Aktion gegeben, so dass von einigen Zurückhaltung in diesem Punkt geübt wird.
Für die Möglichkeit der Nutzung von externen Datenbanken der ISBSG besteht bei ca. 46 Prozent der Befragten eine Zahlungsbereitschaft für dieses kostenpflichtige Feature. Immerhin 35 Prozent sind nicht bereit, hierfür zu zahlen. Es ist daher fraglich, ob dieses wünschenswerte Feature der Nutzung der ISBSG-Daten in das Portal in vollem Umfang aufgenommen werden kann.

Cockpit-Charts

Etwa 30 Prozent der Befragten stufen Cockpitcharts als sehr wichtig und ca. 50 Prozent als wichtig ein. Demnach stellen Cockpitcharts eine wesentliche Komponente des Portals dar.
Es wurde daher gefragt, welche Ausprägungen von Cockpitcharts gewünscht werden. Als Ergebnis wurden folgende Ausprägungen am häufigsten genannt:

  • Defects,
  • Aufwand und Produktivität,
  • Kosten und Dauer.

Zusätzlich wurden von einigen Befragten folgende Ausprägungen angegeben:

  1. Effizienz
  2. Anzahl der Mitarbeiter
  3. Quality Assessment
  4. Phasenverteilung
  5. Interne Fehlerrate
  6. Testumfang
  7. Testprofil
  8. Support Effizienz

Dementsprechend sollten im 1. Schritt der Realisierung des Portals die 4 am häufigsten genannten Ausprägungen realisiert werden, die dann ggf. um weitere ergänzt werden könnten.

Backfiring

Die als sehr kritisch zu betrachtende Backfiringmethode wird, wie schon erwähnt, auch von der Mehrheit der Befragten gewünscht. Hier war das Ziel der Befragung herauszufinden, welche Programmiersprachen durch die Backfiringmethode Berücksichtigung finden sollte.
Am häufigsten wurde die objektorientierte Programmiersprache C++ in Form von C++ und Visual C++ genannt. Auf Platz 2 folgt die Sprache C und auf Platz 3 Visual Basic.
Es folgen Cobol 85, Oracle, Smaltalk und Excel.

bild7

In den zur Auswahl angebotenen Programmiersprachen war die Sprache Java nicht mit aufgeführt. Stattdessen wurde den Befragten die Möglichkeit eröffnet, die Liste um weitere Programmiersprachen zu ergänzen. Dies wurde auch rege genutzt. An dieser Stelle haben ca. 25 Prozent der Befragten den Wunsch geäußert, auch Java zu unterstützen.
Folglich sollte Java bei der Realisierung des Portals, genauso wie die C++-Varianten, im ersten Schritt Berücksichtigung finden.
Die anderen Sprachen können dann Schritt-für-Schritt zu einem späteren Zeitpunkt implementiert werden.

eLearning und Measurement Dashboard

Im Themenkomplex eLearning war interessant, welche eLarning-Funktionalitäten das Portal bereitstellen sollte. Dazu wurden der Reihenfolge entsprechend folgende Funktionalitäten genannt:

  • Methodenüberblick,
  • CASE-Studien,
  • Dokumentationen.

Weiterhin bestand für die Befragten die Möglichkeit, andere Funktionalitäten zu nennen, die Realisierung finden sollten. Hier wurden u. a. hauptsächlich weiterführende empirische Studien sowie FAQs genannt.
Die Möglichkeit der Nutzung von Videoconferencing stieß dagegen auf heftigen Widerstand. Lediglich 7 Prozent der Befragten wünschten sich dieses Feature. Ähnlich sah dies im Bereich der Dashboards aus.
Auch hier wird Videoconferencing offensichtlich nicht gewünscht. Stattdessen sollen in einem Measurementdashboard folgende Funktionalitäten bereitgestellt werden:

  • eLearning,
  • Ressourcenüberblick,
  • Businessdaten,
  • Qualitätssicherungen.

Es wird daher die Aufgabe sein, das Dashboard anhand der Nutzeranforderungen zu gestalten.

Schätzungen auf Grundlage von empirischen Daten und Prozessmetriken
Die Schätzungen auf Basis von empirischen Daten und Prozessmetriken gehören zu den am stärksten geforderten Funktionalitäten des Portals.
Auf die Frage, ob Schätzungen auf Grund von empirischen Daten vorgenommen werden sollten, antworteten ca. 78 Prozent mit ja. Zugleich hielten nahezu alle Befragten diese Schätzungen für aussagefähig.
Bei der Auswahl der Schätzgrößen überwog die Forderung nach der Schätzung der Personenmonate, der Terminwahrscheinlichkeit und der Fehleranzahl.
Dementsprechend sollten auch diese Schätzgrößen bei der Realisierung Berücksichtigung finden.

Sicherheitsaspekte

Das nächste große Teilgebiet der Befragungsaktion umfasste den Bereich der Sicherheit. Hier ist vor allem der Bereich der Personalisierung des Portals interessant.
Überraschenderweise wünscht sich die Mehrheit der Befragten einen anonymen Dienst. Die Vorteile einer Personalisierung wurden von den Befragten nicht in hinreichendem Maße wahrgenommen.
Eventuell hätte nach einer selbstkritischen Einschätzung die Fragestellung von einem umfangreicheren Erklärungstext ergänzt werden müssen, um die Vor- und Nachteile näher zu erläutern.
Auf die Frage, ob eine Verschlüsselung bei der Datenübertragung Anwendung finden sollte, konnte kein eindeutiges Ergebnis ermittelt werden. Die Befürworter und die Gegner hielten sich in etwa die Waage.
Diejenigen jedoch, die eine Verschlüsselung befürworteten, wünschten sich im Allgemeinen die Verwendung von Secure Socket Layer (SSL). Einige wenige könnten sich auch die Verwendung von PGP oder VPN-Verbindungen vorstellen.

Technische Realisierung

Im Fragekomplex der technischen Realisierung sollte ermittelt werden, wie das Portal technisch realisiert werden soll.
Dazu wurde als erstes gefragt, auf welcher Technologie das Portal basieren soll.
Als Ergebnis kann festgehalten werden, dass HTML dicht gefolgt von Java die Wunschrealisierungsformen darstellen. Es ist daher von Seiten der Befragungsaktion nicht eindeutig.
Bei der Art der Ausgabe von Messdaten werden der Monitor und der Drucker, aber auch der Datenexport via Excel-Sheet bevorzugt. Die anderen im Fragebogen genannten Ausgabeformen spielen eine untergeordnete Rolle.

Mobile Services

Ursprünglich war geplant, das Portal durch mobile Services zu ergänzen. Die Befragung ergab hierbei eindeutig, dass mobile Services von fast 60 Prozent der Befragten nicht erwünscht sind.
Die Minderheit, die die mobilen Services für sinnvoll halten, würde vor allem diesen Service für die Datenerfassung nutzen wollen. Die Präsentation der Ergebnisse auf einem mobilen Endgerät hingegen wird nicht für praktikabel gehalten.
Die Auswertung sollte stattdessen laut Meinung der Befragten auf dem Bildschirm erfolgen.
Zu diesem nicht ganz unerwarteten Ergebnis tragen sicherlich die Unzulänglichkeiten heutiger mobiler Geräte, wie zu kleine Displays oder Beeinträchtigungen durch die Tastatur, bei. So wird insbesondere die Tastatur von mobilen Endgeräten mehrheitlich als störend empfunden.
Bei der Wahl der Technologieplattform hingegen lieferten sich J2ME und Windows CE ein Kopf-an-Kopf-Rennen. Symbian war bei den Befragten weitgehend unbekannt.
Zusammenfassend kann man festhalten, dass mobile Services zumindest zum heutigen Zeitpunkt bei der Realisierung des FSeMP nicht berücksichtigt werden sollten.

Marketingaspekte

Ein weiterer wichtiger Fragekomplex waren die Marketingaspekte. Hierbei sollte festgestellt werden, ob die Bereitschaft besteht, für ein derartiges Portal monetäre Transaktionen zu leisten.
Die folgende Abbildung zeigt das Ergebnis dieser Befragung:
 

bild8

Demnach lehnt eine Mehrheit von 53 Prozent die Bezahlung eines solchen webbasierten Messdienst ab. 42 Prozent dagegen würden unter bestimmten Umständen Zahlungen leisten.
Besser sieht es aus, wenn statt einer Bezahlung die Möglichkeit einer Werbefinanzierung eröffnet wird. Hier befürworten 65 Prozent der Befragten eine derartige Finanzierung.
Hinsichtlich einer Benutzungsgebühr konnten keine eindeutigen Ergebnisse ermittelt werden. Lediglich zu einer monatlichen Nutzungsgebühr lässt sich eine Aussage treffen. Sie wird mehrheitlich abgelehnt. Auch stoßen Vertragslaufzeiten größer 3-6 Monaten auf Ablehnung.
Bei den gewünschten Bezahlungsarten führt ganz klar die Kreditkarte, gefolgt von der Bezahlung via Rechnung. Die modernen Zahlungsformen wie virtuelles Geld oder Online-Bezahlsysteme sind weitgehend unbekannt und werden demzufolge von den Befragten auch nicht gewünscht. Virtuelles Geld wird sogar als mehrheitlich unwichtig eingestuft.
Zusammenfassend lässt sich festhalten, dass sich die Finanzierung eines solchen Portals als sehr schwierig erweist. Eine direkte Zahlungsbereitschaft besteht nicht. Lediglich eine Werbefinanzierung wäre denkbar. Dazu müsste man allerdings erst einmal einen Kooperationspartner finden, der bereit wäre, auf der Portalseite Werbung zu schalten.
 

 

[Willkommen] [Wirtschaft] [Informatik] [Bücher] [Impressum]

Copyright (c) 2012 Dipl.-Wirt.-Inform. Dennis A. Winkler, Stand: 02.07.2012
Diese Website ist unter folgenden URLs zu erreichen:
http://www.dennis-winkler.de  -  http://www.winkler-boerse.de