Auswertung einer Umfrage zu konkreten Nutzungsszenarien beim Einsatz von Requirementstraceability in der Praxis

Transkript

1 TU Ilmenau, Fakultät für Informatik und Automatisierung, Fachgebiet Softwaresysteme/Prozessinformatik Auswertung einer Umfrage zu konkreten Nutzungsszenarien beim Einsatz von Requirementstraceability in der Praxis Die Studie ist im Rahmen eines Forschungsprojektes der DFG PH49/8-1 entstanden. Veröffentlichung nur in Absprache mit den Autorinnen. Elke Bouillon, Ilka Philippow,

2 Inhalt 1 Aufbau der Studie Festlegung der Zielsetzung Sammlung möglicher Nutzungsszenarien Gestaltung der Online-Umfrage Teilnehmer Gewinnung von Teilnehmern Rollen der Teilnehmer im Softwareentwicklungsprojekt Art der Projekte Ergebnisse Gründe für den Einsatz von Traceability Auswertung der Nutzungsszenarien Anforderungsmanagement Planung und Organisation Traceability als Nachweis der anforderungsgerechten Implementierung Traceability in der Entwicklung Test und Fehlersuche Wartung und Weiterentwicklung Weitere Nutzungsszenarien Einsatz von Traceability Anzahl der genutzten Szenarien Bewertung des Einsatzes von Traceability Statements Einsatz von Werkzeugen Verbale Aussagen Diskussion Validierung der Ergebnisse Zusammenfassung References

3 1 Aufbau der Studie Im Folgenden soll eine Studie vorgestellt werden, die Aufschluss über die tatsächlichen Nutzungsszenarien gibt. Im Vergleich mit anderen Untersuchungsmethoden ist die Durchführung einer Umfrage mittels Fragebogen kostengünstig und zeiteffektiv umzusetzen. Dies betrifft vor allem die Probanden, die oft nur 5 bis 10 min für die Befragung investieren müssen. So lässt sich eine relativ hohe Anzahl an Personen in die Untersuchung einbeziehen. Damit ist sie die geeignete Methode um Trends beispielsweise in der Nutzung von Technologien festzustellen [12]. Als Untersuchungsmethode wurde daher die direkte Befragung einer größeren Anzahl von Teilnehmern mittels eines Online-Fragebogens gewählt. 1.1 Festlegung der Zielsetzung Das Ziel der Befragung war es, ein aktuelles Bild davon zu erhalten, für welche Nutzungsszenarien Traceability in der Praxis eingesetzt wird. Es sollte eine quantitative Aussage darüber getroffen werden, welche der Szenarien wie häufig eingesetzt werden. Darüber hinaus war es Ziel, durch offene Fragen weitere Nutzungsszenarien zu identifizieren. Durch die Gestaltung der Umfrage und die offene Ansprache wurden bewusst Teilnehmer angesprochen, die bereits ein Interesse für Traceability mitbringen. Die Umfrage lässt damit keinen Schluss auf die generelle Häufigkeit der Nutzung von Traceability in der Praxis zu. 1.2 Sammlung möglicher Nutzungsszenarien In Vorbereitung der Befragung wurden mögliche Nutzungsszenarien für den Einsatz von Traceability in der Praxis zusammengetragen. Dazu wurden zahlreichen Literaturstellen ausgewertet. [14] [13] [15], [11], [8], [9]. Zudem wurden Internetseiten und Eintragungen in Foren ausgewertet, Gespräche geführt und ausgewählte Tools untersucht [5], [4], [1], [2], [3]. Es konnten 29 Aktivitäten, die durch den Einsatz der Traceability jeweils unterstützt bzw. ermöglicht werden, identifiziert werden. Diese wurden in einem iterativen Prozess aus einer größeren Zahl durch Streichen von Redundanzen konsolidiert. Die Aktivitäten wurden zunächst in 6 Gruppen sortiert: Anforderungsmanagement, Planung und Organisation, Arbeit des Entwicklungsteams, Organisation der Zusammenarbeit, Test und Fehlersuche, Änderungen und Wartung. Letztlich ist die Zuordnung nicht immer eindeutig, zur besseren Übersicht war es jedoch notwendig, eine schlüssige Sortierung als Grundlage für die Befragung anzulegen. Im Ergebnis war es sinnvoll, die Nutzungsbereiche nochmal neu zusammenzustellen. 1.3 Gestaltung der Online-Umfrage Der Fragebogen sollte an Teilnehmer mit einem unterschiedlichen Fokus auf das Thema Traceability gerichtet werden. Vom Projektmanager über Requirements Engineers und Entwickler bis zum Testmanager sollten sich potentielle Probanden angesprochen fühlen. Bei der sprachlichen Gestaltung wurde daher auf eine klare, allgemein verständliche Sprache geachtet. Die Teilnehmer wurden gebeten, sich auf ein konkretes Projekt zu beziehen, an dem sie selbst beteiligt waren oder sind. Grundsätzlich ist es nicht einfach, den Einsatz von Traceability in seiner Häufigkeit zu bewerten. Einige Szenarien werden täglich durchgeführt, andere nur in größeren zeitlichen Abständen. Die Befragten wurden daher gebeten, die Häufigkeit folgendermaßen einzuschätzen: gar nicht bedeutet, Traceability wird dafür nicht eingesetzt ; gelegentlich dafür wird Traceability ab und an eingesetzt, aber diese Nutzung ist im Projekt nicht Standard; regelmäßig heißt, dass diese Nutzung Standard ist und üblicherweise verwendet wird. Die tatsächliche Häufigkeit kann dabei durchaus variieren. Je nach Nutzungsszenario ist es der tägliche Einsatz oder auch nur einige Male im Projekt. Zudem war es für 2

4 die Datenauswertung erforderlich, noch weitere Daten zu erfassen wie die nach der Projektgröße und dem praktischen Hintergrund des Probanden. Diese Fragen wurden auf ein Mindestmaß beschränkt, um den Fragebogen in einem vertretbaren Umfang zu halten. Der Fragebogen wurde noch ergänzt um die Fragen nach dem Grund des Einsatzes (gefordert und/oder erwartete Vorteile), dem Tooleinsatz und einigen grundsätzlichen Statements zu Traceability. Zudem wurden an vielen Stellen die Möglichkeiten einer Freitexteingabe eingebaut, um darüber hinaus noch weiteres Feedback zu ermöglichen. Für die Umsetzung des Fragebogens wurde mit ESF Survey von Unipark ein kommerzielles Tool ausgewählt. Damit war eine flexible Auswahl unterschiedlicher Fragetypen ohne großen Aufwand möglich. Zudem unterstützen Tools dieser Art die Auswertung der Umfragedaten. 2 Teilnehmer 2.1 Gewinnung von Teilnehmern Für die Gewinnung von Teilnehmern wurde sehr stark auf persönliche Ansprache der Kontakte gesetzt. Das Projekt wurde auf Fachtagungen vorgestellt. Im Internet wurden über Foren Interessengruppen angesprochen, die sich mit Requirements Engineering und Qualitätssicherung in Softwareprojekten beschäftigen. Weiterhin wurden persönliche Kontakte: ehemalige Diplomanden und Kollegen sowie Kontakte von Messen und Netzwerkveranstaltungen genutzt. Darüber hinaus wurden soziale Netzwerke genutzt und Multiplikatoren angesprochen. 2.2 Rollen der Teilnehmer im Softwareentwicklungsprojekt Die Umfrage wurde in einem Zeitraum von 6 Wochen ca. 300-mal aufgerufen. 106 Teilnehmer haben die Umfrage tatsächlich begonnen, 71 Teilnehmer davon haben bis zur letzten inhaltlichen Frage Antworten gegeben. Damit ist ein relativ hoher Prozentsatz der Befragten bis zum Schluss dabei geblieben. Die Beantwortungszeit lag im Mittel tatsächlich bei den erwarteten maximalen 10 min. Projektmanager 36% Requirements Engineer Qualitätsmanager 29,6% 29% Softwareentwickler/ Programmierer Software-Architekt / Designer 20% 19,5% Testmanager/ Tester 12% Geschäftsführer 8,5% Abbildung 1: Rollen der Teilnehmer im Softwareentwicklungsprozess Mehrfachnennungen waren möglich Die Teilnehmer wurden nach ihrer persönlichen Rolle im Softwareentwicklungsprozess befragt. Dazu war eine Auswahl gegeben. Zudem hatten die Teilnehmer die Möglichkeit, eine verbale Angabe zu 3

5 machen. Da insbesondere in kleinen Firmen bzw. Projekten Personen oft mehrere Rollen im Softwareentwicklungsprozess begleiten, waren hier Mehrfachnennungen möglich. Die Auswertung hat ergeben, dass alle im Fragebogen vorgegebenen Rollen durch eine relevante Anzahl der Befragten ausgewählt wurden. Die nähere Analyse zeigt, dass vor allem im Bereich des Projektmanagements viele Überschneidungen mit anderen Tätigkeiten vorliegen. Beispielsweise gaben 50% der Probanden, die im Projektmanagement tätig sind, an, auch die Rolle des Requirementsengineers zu begleiten. Zudem wurden in der Beantwortung der offenen Frage als weitere Rollen noch genannt: Support, Buildmanagement Coach/ Berater Die breite Streuung der Teilnehmer zeigt, dass die wesentlichen Bereiche im Softwareentwicklungsprozess abgedeckt sind. Dies ließ erwarten, eine Vielzahl unterschiedlicher Positionen und Meinungen zu erhalten. 2.3 Art der Projekte Die Probanden wurden nach der Art der Projekte befragt, auf die sie sich in Ihrer Antwort beziehen. Tabelle 1 zeigt, dass es hier eine breite Streuung zwischen kleinen/ mittleren und großen Projekten gibt. Auch die Projektdauer ist sehr unterschiedlich. Ein Projekt wurde einer verbalen Eingabe zur Folge seit 20 Jahren ständig weiter entwickelt. Kleine Projekte 1-6 Personen Mittlere Projekte 7-50 Personen Große Projekte Über 51 Personen Einige Monate (unter einem Jahr) Tabelle 1: Übersicht über die Projekte der Teilnehmer Projektdauer 1-3 Jahre Über 3 Jahre 14,8% 4,9% 3,2% 6,5% 27,9% 11,5% 1,6% 14,8% 14,8% Tabelle 2 zeigt, dass die beschriebenen Projekte auch sehr stark divergieren zwischen Projekten die nur an einem Standort, an mehreren Standorten bzw. international verteilt entwickelt werden. Da auch hier eine breite Abdeckung unterschiedlicher Projekte gegeben ist, kann von einer breiten Einsicht und unterschiedlichen Erfahrungshintergründen der Probanden ausgegangen werden. Kleine Projekte 1-6 Personen Mittlere Projekte 7-50 Personen Große Projekte Über 51 Personen einem Standort Tabelle 2: Übersicht über die Projekte der Teilnehmer Projektentwicklung an mehreren Standorten in einem Land international verteilten Standorten 18,5% 3,4% 0 20,3% 15,3% 11,9% 6,8% 8,5% 15,3% 4

6 3 Ergebnisse 3.1 Gründe für den Einsatz von Traceability Die erste Frage im Fragebogen bezog sich auf die Gründe für den Einsatz von Traceability. Hier waren ganz bewusst Mehrfachnennungen möglich, da mehrere Gründe vorliegen können. 60% der Befragten gaben an, sich vom Einsatz der Traceability Vorteile für das Softwareentwicklungsprojekt zu erwarten. Da nahezu alle Teilnehmer der Studie angaben, Traceability einzusetzen, kann festgestellt werden, dass 40% Traceability nur einsetzen, weil es aus unterschiedlichen Gründen Zertifizierung, Forderung des Kunden, Methodeneinsatz - vorgegeben ist. Um die Motivation noch einmal näher zu betrachten, wurden die Ergebnisse auf eine Mehrfachnennung bei gleichzeitiger Angabe der erwarteten Vorteile hin untersucht: - 69% der Befragten, die Traceability einsetzen weil dies gesetzlich oder wegen einer Zertifizierung gefordert ist, - 67% der Probanden, in deren Projekten Traceability vom Kunden vorgegeben ist - 74% derjenigen, in deren Projekten Traceability als technische Notwendigkeit angegeben wird. erwarten sich gleichzeitig Vorteile. weil Vorteile erwartet werden (z.b. für Fehlersuche, Änderungen, Planung) 60% weil der Einsatz gefordert ist (gesetzlich, für eine Zertifizierung) 29,10% Der Einsatz wurde vorgegeben durch die Projektleitung oder den Kunden Es gibt technische Notwendigkeiten (z.b. Vorbedingung für Methodeneinsatz) 17,30% 22,70% Gründe sind nicht bekannt 1,70% Abbildung 2: Gründe für den Einsatz von Traceability in den Projekten Mehrfachnennungen waren möglich Die Motivationsstruktur unterschieden nach der Projektgröße zeigt hier Unterschiede: In kleinen Projekten mit 1-6 Mitarbeitern werden zu 86% Vorteile erwartet, (Einsatz gefordert 21%, Einsatz vorgegeben 14%, Methodeneinsatz 14%) In mittleren Projekten mit 7 bis 50 Mitarbeitern werden zu 68% Vorteile erwartet (Einsatz gefordert 46%, Einsatz vorgegeben 29%, Methodeneinsatz 18%) In großen Projekten mit über 51 Mitarbeitern werden zu 84% Vorteile erwartet (Einsatz gefordert 52%, Einsatz vorgegeben 37%, Methodeneinsatz 42%) 5

7 3.2 Auswertung der Nutzungsszenarien Anforderungsmanagement Abbildung 3 zeigt die Häufigkeit mit der Traceability im Anforderungsmanagement eingesetzt wird. Alle Nutzungsszenarien in diesem Bereich werden von mehr als drei Viertel aller Teilnehmer eingesetzt. Dabei ist die standartmäßige Nutzung in Frage 1a) zum Nachvollziehen der einzelnen Anforderungen am höchsten (58%). Die standardmäßige Nutzung für die Analyse welche Stakeholder von einer Änderung noch betroffen sind 1f) liegt mit 31% relativ niedrig. Wofür setzen Sie Traceability im Bereich des Anforderungsmanagement ein? 1a) zum Nachvollziehen, wie einzelne Anforderungen entstanden sind (z.b. Regelwerke, Stakeholder) 1b) zum Verfeinern von Anforderungen 1c) zur Dokumentation der Historie der Anforderungen 1d) zur Identifikation von Ansprechpartnern für die weitere Entwicklung der Anforderungen 1e) zur Analyse der Widerspruchsfreiheit einzelner Anforderungen 1f) zur Analyse, welche Stakeholder von der Änderung (noch) betroffen ist? 0% 20% 40% 60% 80% 100% regelmäßig gelegentlich gar nicht Abbildung 3: Praxiseinsatz von Traceability im Bereich der Anforderungsanalyse Eine nähere Analyse der Ergebnisse zeigt, dass insbesondere bei großen Projekten Traceability im gesamten Bereich der Anforderungen eine große Rolle spielt. Erstaunlicherweise stellt sich heraus, dass das größte Defizit in der Anwendung von Traceability in den mittleren Projekten zu erkennen ist. Dies betrifft alle angegebenen Nutzungsszenarien. Besonders deutlich wird dies am Beispiel der Frage 1b) - Verfeinern von Anforderungen. In Abbildung 4 zeigt sich klar das größte Defizit bei den mittleren Projekten. 1b) Wird Traceability für das Verfeinern der Anforderungen eingesetzt? großes Projekt (über 50 Mitarbeiter) mittleres Projekt (7-50 Mitarbeiter) kleines Projekt (-5 Mitarbeiter) 0% 20% 40% 60% 80% 100% regelmäßig gelegentlich gar nicht Abbildung 4: Praxiseinsatz der Traceability zum Verfeinern der Anforderungen aufgeschlüsselt nach Projektgröße Betrachtet man die Projektdauer, so ergibt sich eine leichte Tendenz. Je länger das Projekt dauert umso häufiger wird Traceability hier eingesetzt. 6

8 Ein signifikanter Einfluss der Standorte lässt sich nur in zwei Fällen sehen. In international verteilten Projekten kommt Traceability in den Fällen 1a) und 1c) immer zum Einsatz (in beiden Fällen 71% als Standard, 29% gelegentlich). Des Weiteren wurde noch untersucht, ob diejenigen die Traceability in diesem Bereich einsetzen, häufiger RE-Werkzeuge einsetzen. Hier ist in den Szenarien 1a), 1b) und 1c) ein Zusammenhang erkennbar. Der Unterschied beträgt ca. 20%. Beispiel: 71% derjenigen die ein RE-Werkzeug einsetzen, tun dies standardmäßig für das nachvollziehen der Anforderungen 1a). Jedoch 52% derjenigen die kein spezielles Tool dafür anwenden, tun dies ebenso Planung und Organisation In der Planung und Organisation wird Traceability häufig eingesetzt (siehe Abbildung 5). Besonders auffallend ist hier, dass in Fall 2a, Zustandsverfolgung von Anforderungen in 74% aller Fälle die Nutzung bereits Standard ist. Demgegenüber verwundert, dass für das Feststellen der erreichten Ziele, 2d), nur in 48% Traceability regelmäßig zum Einsatz kommt. Die Planung von Releases, 2b), wird in 83% aller Fälle von Traceability unterstützt (60% Standard), eine Anpassung der Release-Planung, z.b. wenn Zeitdruck im Projekt entsteht, immerhin noch zu 78% (40% Standard). In einer näheren Analyse der Ergebnisse wurde differenziert betrachtet, ob diese Nutzungsszenarien verstärkt von Personen angegeben wurden, die im Projektmanagement tätig sind, da hier eine überdurchschnittlich hohe Anzahl an Probanden beteiligt war. Dies wurde nicht bestätigt. Die Tendenz einer starken Nutzung von Traceability in der Planung und Organisation zieht sich durch kleinere ebenso wie durch mittlere bzw. große Projekte. Ein ähnlicher Effekt wie beim Anforderungsmanagement kann hier in den Fragen 2a) und 2b) festgestellt werden. Auch hier gibt es ein Defizit in dem mittleren Unternehmen. Bei der Länge der Projekte kann eine ganz leichte Tendenz ausgemacht werden, dass die häufigste Nutzung im Bereich der Projekte zwischen 1 und 3 Jahren liegt. Die Standortfrage zeigte hier keine signifikanten Auswirkungen. Ein Einfluss der verwendeten Werkzeuge konnte nicht festgestellt werden. Wofür setzen Sie Traceability im Bereich Planung und Organisation ein? 2a) zur Zustandsverfolgung von Anforderungen bzw. Aufträgen 2b) zur Planung von Releases 2c) für die Freigabe einzelner Anforderungen für die Umsetzung 2d) zur Feststellung erreichter Ziele (z.b. n% der Requirements umgesetzt) 2e) zur Anpassung der Releaseplanung (z.b. bei Zeitdruck) 2f) um Mitarbeiter über Änderungen zu informieren (z.b. in den Anforderungen, Implementierung, etc.) 0% 20% 40% 60% 80% 100% regelmäßig gelegentlich gar nicht Abbildung 5: Praxiseinsatz der Traceability im Bereich Planung und Organisation 7

9 3.2.3 Traceability als Nachweis der anforderungsgerechten Implementierung Wie häufig in der Literatur angemerkt, kann mit Hilfe von Traceability der Nachweis geführt werden, dass alle Anforderungen erfüllt sind (Frage 3a). 68% der Befragten gaben an, Traceability für diesen Nachweis regelmäßig zu nutzen. Eine nähere Analyse ergab 42% davon taten dies in Projekten, für die Traceability vorgeschrieben ist. Eine deutliche Korrelation ergab sich hier mit Frage 2a) Zustandsverfolgung der Anforderungen: 84% der Befragten die 3a) einsetzen, nutzen gleichzeitig regelmäßig 2a) 5a) Entwickeln der Testfälle direkt aus den Anforderungen, hier sind es 71% 1c) Dokumentation der Historie, ebenfalls 71% 1b) Verfeinern von Anforderungen, 70% Auffallend ist, dass dieses Nutzungsszenario sehr stark in kleinen Projekten eingesetzt wird - 83% aller kleinen Projekte. Gefolgt von den großen Projekten (68%) und den mittleren Projekten (59%). Der Umkehrschluss, dass kein zusätzlicher Code entstanden ist (Frage 3c) ist nur für 31% aller Befragten Standard. Der Prozentsatz derjenigen, die dies in Projekten tun, in denen Traceability vorgeschrieben ist, ist hier deutlich höher: 63%. Es können auch mehr Korrelationen beobachtet werden. Von den Teilnehmern die Traceability für den Nachweis, dass kein zusätzlicher Code entstanden ist, nutzen, tun diese gleichzeitig regelmäßig für: 3a) Nachweis, dass alle Anforderungen umgesetzt sind 89% 1b) Verfeinern von Anforderungen 89% 3b) Dokumentation der Traceability 89% 5a) Entwickeln von Testfällen direkt aus den Anforderungen 83% 2c) Freigabe einzelner Anforderungen für die Umsetzung 75% 1a) Nachvollziehen, wie einzelne Anforderungen entstanden sind 74% (dies entspricht jedoch dem Durchschnitt) 5b) Fehlersuche nach Tests 74% 5c) Aufdecken von Komponenten, die nicht durch Tests abgedeckt sind 71% 1c) Dokumentation der Historie 69% Dieses Nutzungsszenario wird mit steigender Projektgröße häufiger angewendet. Die Dokumentation der Traceability selbst, z.b. für sicherheitsrelevante Anwendungen wird hauptsächlich in zertifizierten Projekten eingesetzt. Ein Schwerpunkt kann darüber hinaus in großen Projekten identifiziert werden. Standorte und Länge des Projektes haben im gesamten Bereich kaum Einfluss. Verwenden Sie Traceability für den Nachweis einer anforderungsgerechten Implementierung? 3a) für den Nachweis, dass alle beschriebenen Anforderungen umgesetzt sind 3b) für die Dokumentation der Traceability (z.b. für sicherheitsrelevante Software) 3c) für den Nachweis, dass nur Code basierend auf Anforderungen entstanden ist 0% 20% 40% 60% 80% 100% regelmäßig gelegentlich gar nicht Abbildung 6: Praxiseinsatz von Traceability für Nachweise einer anforderungsgerechten Implementierung 8

10 3.2.4 Traceability in der Entwicklung Innerhalb der Entwicklung wird Traceability noch relativ selten als Standard eingesetzt. Nur für 45% der Befragten ist die Navigation zwischen einzelnen Dokumenten (Frage 4a) Standard. Für eine Navigation zwischen einzelnen Artefakten wie z.b. Codekomponenten - 4b) sind es nur noch 29%. Wofür setzen Sie Traceability im Bereich der Entwicklung ein? 4a) zur Navigation zwischen Dokumenten (z.b. Designentscheidung - Umsetzung, Anforderung - Testfall) 4b) zur Navigation zwischen Softwareartefakten (z.b. Modellelemente, Codekomponenten) 4c) für die Einarbeitung neuer Mitarbeiter im Entwicklungsteam 4d) für die Erleichterung von Wiederverwendung durch die Identifizierung einzelner Komponenten 4e) zur Qualitätsanalyse über Abhängigkeiten (deckt eine Komponente zu viele Anforderungen ab - Aufteilung) 0% 20% 40% 60% 80% 100% regelmäßig gelegentlich gar nicht Abbildung 7: Praxiseinsatz von Traceability im Bereich der Entwicklung Eine nähere Analyse zeigt ein interessantes Bild. Während das Szenario 4a) noch relativ gleichmäßig in großen, mittleren und kleinen Projekten eingesetzt wird, zeigt sich in allen anderen Szenarien eine deutliche Zunahme der Nutzung mit zunehmender Projektgröße. Dies sei am Beispiel der Anwendung der Traceability für die Navigation zwischen Softwareartefakten verdeutlicht (siehe Abbildung 8). 4a) Wird Traceability für die Navigation zwischen Softwareartefakten eingesetzt? 0% 20% 40% 60% 80% 100% kleines Projekt (-5 Mitarbeiter) mittleres Projekt (7-50 Mitarbeiter) großes Projekt (über 50 Mitarbeiter) regelmäßig gelegentlich gar nicht Abbildung 8 Praxiseinsatz von Traceability für die Navigation zwischen Softwareartefakten aufgeschlüsselt nach Projektgröße Bei der Analyse der Projektdauer konnte wiederum eine leichte Tendenz zur häufigsten Nutzung bei einer mittleren Projektdauer von 1-3 Jahre beobachten werden. Die Einarbeitung von neuen Mitarbeitern ins Entwicklungsteam spielt bei kurzen Projekten eine sehr geringe Rolle (73% nutzen Traceability hier gar nicht). In Projekten in denen ein Entwicklungswerkzeug zur Traceability verwendet wird, ist die Nutzung der Szenarien 4b- 4e häufiger. Die Navigation zwischen Softwareartefakten 4b) zeigt dies sehr deutlich: Werkzeugnutzer setzen dieses nur zu 22% gar nicht ein, bei den Nicht-Werkzeugnutzern sind es 55%. Letztlich wurden noch mögliche Korrelationen mit anderen Nutzungsszenarien untersucht. 9

11 Szenario 4a) korreliert deutlich mit: 5a) Entwickeln von Testfällen (direkt aus den Anforderungen). In 88% der Projekte, die 4a regelmäßig nutzen, setzen regelmäßig 5a) ein. 4a) Nachweis, dass alle beschriebenen Anforderungen umgesetzt sind (81%) 1b) Verfeinern von Anforderungen (74%) Szenario 4b) korreliert besonders deutlich mit den Szenarien: 2b) Planung von Releases. In 76% der Projekte, die 4b regelmäßig nutzen, setzen regelmäßig 2b) ein. mit dem Bereich Test und Fehlersuche (5a), 5b) und 5c) sind für die regelmäßigen Nutzer auch hier jeweils mit 71% Standard. Ein ähnliches Bild ergibt sich für die Szenarien 4d) und 4c). Im Szenario 4e) konnten zudem noch zwei sehr starke Korrelationen mit anderen Szenarien entdeckt werden. Alle Teilnehmer, die angaben, standardmäßig eine Qualitätsanalyse über Abhängigkeiten durchzuführen, gaben auch an: 1e) Analyse der Widerspruchsfreiheit einzelner Anforderungen 3a) Nachweis, dass alle beschriebenen Anforderungen umgesetzt sind regelmäßig einzusetzen Test und Fehlersuche In der Literatur wird der Bereich Test und Fehlersuche als ein wesentlicher Bereich für Traceability genannt. Die Ergebnisse in Abbildung 9 zeigen, dass Traceability in der Praxis hierfür ebenfalls häufig zum Einsatz kommt. Wofür setzen Sie Traceability im Bereich Test und Fehlersuche ein? 5a) zum Entwickeln von Testfällen (direkt aus den Anforderungen) 5b) für die Fehlersuche nach Tests 5c) zum Aufdecken von Komponenten, die nicht durch Tests abgedeckt sind 5d) für das Gezieltes Testen nach Änderungen (Aussparen unnötiger Tests) 5e) Identifizierung von Ansprechpartnern bei der Fehlersuche 0% 20% 40% 60% 80% 100% regelmäßig gelegentlich gar nicht Abbildung 9: Praxiseinsatz von Traceability im Bereich Test und Fehlersuche Die Entwicklung von Testfällen direkt aus den Anforderungen (Frage 5a) wird dabei am häufigsten eingesetzt (in 64% aller Projekte ist dies bereits Standard). Dieses Nutzungsszenario korreliert besonders deutlich mit: 1a) - Nachvollziehen, wie einzelne Anforderungen entstanden sind und 2a) - Zustandsverfolgung von Anforderungen bzw. Aufträgen (jeweils 84% nutzen auch dieses als Standard). Dokumentation der Traceability (74%) 10

12 Auch zur direkten Fehlersuche (Frage 5b) wird Traceability noch in mehr als der Hälfte aller Projekte regelmäßig angewendet (54%). Wer Traceability hier einsetzt tut dies in der Regel auch in den anderen Anwendungsfällen im Bereich Test und Fehlersuche. Als zusätzliche Korrelation sind hier die Aufwandsschätzungen für Änderungswünsche deutlich (66% nutzen dies ebenso regelmäßig). Ein ähnliches Bild ergab sich für die anderen Nutzungsszenarien 5c-5e in diesem Bereich. Eine nähere Analyse der Ergebnisse zeigte zudem, dass mit zunehmender Projektgröße in allen Nutzungsszenarien ein häufigerer Einsatz zu verzeichnen ist. Dies kann auch für die Projektlänge beobachtet werden Wartung und Weiterentwicklung Durch die Dokumentation von Abhängigkeiten ist Traceability besonders auch für die Wartung und Weiterentwicklung von Software geeignet. Auch hier liegt zumindest die gelegentliche Nutzung (fast) aller Szenarien bei ca. 80% (siehe Abbildung 10). Die standardmäßige Nutzung bleibt jedoch deutlich hinter der Planung und Organisation sowie dem Anforderungsmanagement zurück. Zum Einsatz kommt Traceability vor allem bei der Aufwandsschätzung für Änderungswünsche (Frage 6a). Die Analyse der Auswirkungen von Änderungswünschen (Frage 6b) direkt damit verbunden, steht damit auch an zweiter Stelle. Obwohl immer noch fast drei Viertel aller Befragen angaben, zumindest gelegentlich bei der Umsetzung von Änderung durch angelegte Traces unterstützt zu werden (Frage 6c), geben doch nur wenige Beteiligte an, dass Traceability direkt für die Einarbeitung des Wartungsteams genutzt wird (Frage 6d). Bei der näheren Analyse werden folgende Korrelationen deutlich. Nutzer die Traceability für die Aufwandsschätzung bei Änderungen 6a) einsetzen tun dies häufig auch: 5a) Entwickeln von Testfällen (direkt aus den Anforderungen) (88%) 1a) Nachvollziehen, wie einzelne Anforderungen entstanden sind (83%) 2a) Zustandsverfolgung von Anforderungen bzw. Aufträgen (83%) 2b) Planung von Releases (77%) 5b) Fehlersuche nach Tests (77%) 1b) Verfeinern von Anforderungen (75%) Für die Analyse der Auswirkungen von Änderungswünschen: 6a) Aufwandsschätzungen für Änderungswünsche (87%) 5a) Entwickeln von Testfällen (direkt aus den Anforderungen) (85%) 1a) Nachvollziehen, wie einzelne Anforderungen entstanden sind (83%) 2a) Zustandsverfolgung von Anforderungen bzw. Aufträgen (83%) 1c) Dokumentation der Historie (79%) 2b) Planung von Releases (79%) 1e) Analyse der Widerspruchsfreiheit einzelner Anforderungen (78%) 6c) Direkte Hilfe bei der Umsetzung von Änderungen (73%) Zudem kann beobachtet werden, dass Nutzer dieses Szenarios häufiger als der Durchschnitt die Nutzungsszenarien im Bereich der Entwicklung anwenden. Als direkte Hilfe bei der Umsetzung von Änderungswünschen 2b) Planung von Releases (87%) 6a) Aufwandsschätzungen für Änderungswünsche (87%) 5a) Entwickeln von Testfällen (direkt aus den Anforderungen) (84%) 1a) Nachvollziehen, wie einzelne Anforderungen entstanden sind (83%) 3a) Nachweis, dass alle beschriebenen Anforderungen umgesetzt sind (82%) 5d) Gezieltes Testen nach Änderungen (76%) Auch hier kann ein Zusammenhang mit den Szenarien der Entwicklung beobachtet werden. 11

13 Am häufigsten werden alle diese Nutzungsszenarien in großen Projekten eingesetzt. Bei mittleren und kleinen Projekten lässt sich kein Trend feststellen. Wofür setzen Sie Traceability im Bereich der Wartung und Weiterentwicklung ein? 6a) zur Aufwandsschätzungen für Änderungswünsche 6b) für die Analyse der Auswirkungen von Änderungswünschen 6c) als direkte Hilfe bei der Umsetzung von Änderungen (z.b. 6d) für die Einarbeitung des Wartungsteams in die Software 0% 20% 40% 60% 80% 100% regelmäßig gelegentlich gar nicht Abbildung 10 Praxiseinsatz von Traceability im Bereich Wartung und Entwicklung Weitere Nutzungsszenarien Die Teilnehmer an der Umfrage hatten an mehreren Stellen die Möglichkeit in offenen Fragen weitere Nutzungsszenarien zu nennen, die im Laufe des Projektes mit Traceability erreicht werden. Hinzu kommen noch: 7a) Für die Entlastung der Projektleitung gegen projektpolitische Angriffe. 7b) Zum Nachweis, dass bestimmte Methoden eingehalten worden sind. 7c) Um bestimmte Codeänderungen zu begründen. 7d) Zur Analyse von Fehlerauswirkungen. Wo wirken sich entdeckte Fehler z.b. in einer Bibliothek noch aus? 7e) Die Release-Verwaltung (mehrfach genannt) als Nutzungsszenario und gleichzeitig Abprodukt für den Einsatz von Traceability. 7f) Die Konzeptevaluierung durch die Abbildung der fachlichen Anforderungen auf die technischen Lösungen. 7g) Der Aufbau einer Wissensdatenbank, durch die Auswertung der Traces durch Metriken Einsatz von Traceability Anzahl der genutzten Szenarien Es wurde analysiert, wie stark einzelne Nutzer Traceability einsetzen. 13% der Befragten nutzen Traceability sehr umfangreich (mehr als 20 Nutzungsszenarien regelmäßig, weitere gelegentlich). 39% der Befragten setzen mehr als 12 und weniger als 20 Nutzungsszenarien regelmäßig ein. In dieser Nutzergruppe zeigt sich jedoch, dass 63% von diesen Nutzern viele andere Nutzungsszenarien gelegentlich nutzen. Sie kamen in der Summe auf mehr als 20 Nutzungsszenarien. Bei 36% von ihnen war eine stärkere Fokussierung zu beobachten. 36% sind in ihrer Nutzung deutlich fokussiert. Sie setzen 7-12 Nutzungsszenarien regelmäßig ein. Hier ist die gelegentliche Nutzung anderer Szenarien auch deutlich geringer. 12% setzen Traceability sehr gezielt ein. 1-6 Nutzungsszenarien werden regelmäßig genutzt, nur wenige Szenarien zusätzlich gelegentlich. 12

14 3.3 Bewertung des Einsatzes von Traceability Statements Abschließend wurden die Teilnehmer noch um die Bewertung einiger Statements gebeten. Wie sehen Sie die folgenden Aussagen über den Einsatz von Traceability a) Traceability ist eine wichtige Grundlage für den gesamten Entwicklungsprozess. b) Traceability bietet große Potentiale und sollte meiner Meinung nach noch stärker eingesetzt werden. c) Die erreichten Vorteile überwiegen den Aufwand für Traceability. d) In unserem Projekt sind die Mitarbeiter alle in den Prozess der Traceability mit einbezogen. *) e) Traceability hat nicht den erwarteten Nutzen gebracht. 0% 20% 40% 60% 80% 100% trifft völlig zu trifft zum Teil zu trifft gar nicht zu Abbildung 11 Bewertung des Praxiseinsatz von Traceability durch die Teilnehmer *) Sie kennen die Ziele und ihre Rolle Hier zeigt sich, dass die überwiegende Mehrheit der Teilnehmer Traceability für eine wichtige Grundlage im Entwicklungsprozess sehen (trifft völlig zu 63%; trifft zum Teil zu 35%)- Statement a). Der Aufwand wird in der Regel durch die Vorteile gerechtfertigt (Statement c). 55% der Befragten meinen sogar, dass Traceability stärker eingesetzt werden sollte (Statement b). Eine sehr skeptische Meinung haben nur 7% der Befragten. Sie stimmen dem Statement e Traceability hat nicht den erwarteten Nutzen gebracht völlig zu. Das Einbeziehen und die Information der Mitarbeiter (Statement d) wird wie folgt eingeschätzt: Hier können nur 33% vollständig zustimmen, dass alle Mitarbeiter in den Prozess mit einbezogen sind und dass alle die Ziele der Traceability sowie ihre eigene Rolle darin kennen. 49% bestätigen das nur zum Teil. 18% können dieser Aussage nicht zustimmen. Diejenigen, die sich vom Einsatz der Traceability Vorteile erwartet haben, antworteten wie folgt (jeweils im Verhältnis zu denen die sich keine Vorteile erwartet hatten): Betrachteten das Aufwand Nutzenverhältnis ähnlich, wie diejenigen, die keine Erwartungen hatten. c) Auch die Potentiale wurden ähnlich eingeschätzt b) Sahen Traceability etwas häufiger als eine wichtige Grundlage für den gesamten Entwicklungsprozess an. a) Sahen sich deutlich seltener enttäuscht vom Nutzen. e) Auffallend war hier, dass die Mitarbeiter deutlich besser in den Prozess eingebunden waren. d) In Projekten, in denen Traceability aus Gründen eines Methodeneinsatzes eingesetzt wird, (Schnittmenge mit erwarteten Vorteilen 74%) fällt die Umfrage noch deutlicher aus: Die Teilnehmer betrachteten das Aufwand Nutzenverhältnis deutlich besser. Auch die Potentiale wurden etwas positiver eingeschätzt. b) 100% sahen Traceability als eine wichtige Grundlage für den gesamten Entwicklungsprozess an. a) 13

15 Jeweils nur ein Teilnehmer bewertete die Aussage, dass Traceability nicht den erwarteten Nutzen gebracht hatte mit trifft zu bzw. trifft zum Teil zu. e) Nur ein Proband gab an dass die Mitarbeiter nicht in den Prozess einbezogen sind. d) Untersuchungen nach weiteren Gründen z.b. ein Einsatz von Traceability wegen einer Zertifizierung ergeben hier kein klares Bild, da Mehrfachnennungen möglich waren Einsatz von Werkzeugen Für den Einsatz der Traceability in der Praxis kommen unterschiedliche Werkzeuge zum Einsatz. Einfache Office-Werkzeuge wie Tabellenkalkulationsprogramme oder Wikis kommen dabei fast ebenso häufig zum Einsatz wie RE-Tools, Entwicklungs- und Versionierungssysteme. Versionierungswerkzeuge Officewerwzeuge (z.b. Tabellenkalkulation, Wiki) Entwicklungswerkzeuge Werkzeuge für das Reqiirements- Engineering 54% 52,17% 50,72% 51% Planungswerkzeuge 20% Abbildung 12 Einsatz von Werkzeugen für Traceability Mehrfachnennungen waren möglich Darüber hinaus gaben 33% aller Befragten an, für Traceability angepasste Lösungen über mehrere Tools hinweg einzusetzen. Hier handelt es sich um Werkzeugketten bzw. Eigenentwicklungen. Interessant ist, dass die Häufigkeit des Einsatzes von Traceability nur geringfügig vom Einsatz bestimmter Tools bestimmt wird. Allerdings fällt die Bewertung des Aufwandes für den Einsatz von Traceability wie erwartet positiver aus, wenn ein durchgehendes Werkzeug zum Einsatz kommt Verbale Aussagen Die Befragten hatten in der Umfrage die Möglichkeit, auch eine persönliche Einschätzung abzugeben. 25% der Befragten, machten von dieser Möglichkeit Gebrauch. Nahezu alle Bemerkungen beziehen sich (u.a.) auf die Fragen der Balance zwischen Aufwand und Nutzen. Der Aufwand wird immer noch als (zu) hoch eingeschätzt. Dies ist nach wie vor ein häufiger Grund, Traceability nicht oder nur eingeschränkt einzusetzen. In einigen Beiträgen wird formuliert, dass Traceability geschickt eingesetzt auch Kosten und Zeit einsparen kann. Als Voraussetzung für einen erfolgreichen Einsatz der Traceability werden genannt: - zielorientierter Einsatz mit einer abgestimmten Granularität (Risk-based Traceability) - gute, angepasste Toolauswahl - gute Information und Motivation der Mitarbeiter, insbesondere in der Entwicklung - ständige Nachführung (Wartung) der Traces Als wichtiges positives Ergebnis des Einsatzes von Traceability wird von den Teilnehmern häufig eine deutliche Qualitätszunahme genannt. Dies rechtfertige bzw. erfordere den Einsatz, so die Aussagen, insbesondere bei sicherheitskritischen Systemen. 14

16 4 Diskussion Zunächst kann festgestellt werden, dass fast alle Befragten den Grund kannten, warum Traceability im Projekt zum Einsatz kommt. Mit 60% erwartet deutlich mehr als die Hälfte der Befragten Vorteile für die weitere Softwareentwicklung bzw. die Qualität und Planung. Die Studie zeigt, dass Traceability in der Praxis für unterschiedliche Nutzungsszenarien zum Einsatz kommt. Zudem kann festgestellt werden, dass mit 13% nur in wenigen Projekten versucht wird, die ganze Bandbreite an Nutzungsszenarien abzudecken. In etwa der Hälfte aller Projekte wurde deutlich auf bestimmte Anwendungsszenarien fokussiert. Inwieweit hier eine bewusste Auswahl getroffen wurde, kann nicht gesagt werden. Traceability wird in kleinen, mittleren und großen Projekten eingesetzt. In der Regel steigt mit zunehmender Projektgröße der Einsatz der Traceability. Hier bestehen jedoch deutliche Ausnahmen. Im Bereich der Anforderungsanalyse und teilweise auch in der Planung und Organisation kommt in kleinen Projekten Traceability häufiger zum Einsatz als in mittleren Projekten. Diese Zahlen weichen zwar nicht dramatisch von den Zahlen in Großprojekten oder kleinen Projekten ab, sind aber deutlich erkennbar. Ein möglicher Zusammenhang besteht hier zu der Motivationsstruktur. Zudem kann vermutet werden, dass in kleinen Projekten größeres Augenmerk auf die Kommunikation mit dem Kunden gelegt wird. In mittleren Projekten nimmt hier einerseits die Komplexität zu zum anderen verschieben sich die Prioritäten der Traceability. Nähere Ursachen dafür bedürfen einer weiteren Untersuchung. Als häufigste Nutzungsszenarien wurden identifiziert: 2a) Zustandsverfolgung von Anforderungen bzw. Aufträgen Standard 74,24%; gelegentlich 16,67% ; nicht verwendet 9,09% 3a) Nachweis, dass alle beschriebenen Anforderungen umgesetzt sind Standard 68,18%; gelegentlich 24,24%; nicht verwendet 7,58% 5a) Entwickeln von Testfällen (direkt aus den Anforderungen) Standard 63,79%; gelegentlich 22,41%; nicht verwendet 13,79% 1a) Nachvollziehen, wie einzelne Anforderungen entstanden sind (z.b. Regelwerke, Stakeholder) Standard 57,8%; gelegentlich 32,4%; nicht verwendet 9,9% 2b) Planung von Releases Standard 59,70%; gelegentlich 23,88%; nicht verwendet 16,42% 1b) Verfeinern von Anforderungen Standard 56,72%; gelegentlich 26,87%; nicht verwendet 16,42% 5b) Fehlersuche nach Tests Standard 54,24% (in großen Projekten 68,4); gelegentlich 23,73%, nicht verwendet 22,03% 6a) Aufwandsschätzungen für Änderungswünsche Standard 51,72% (in großen Projekten 64,7); gelegentlich 27,59%; nicht verwendet 20,69% Zusammenfassend kann festgestellt werden, ein Schwerpunkt des Einsatzes von Traceability wird im Bereich des Managements von Softwareprojekten deutlich, gefolgt von Anforderungsanalyse sowie im Test bzw. der Fehlersuche Mit der Aufwandsschätzung von Änderungswünschen 6b), liegt auch ein Szenario auf der Wartung und Weiterentwicklung im Bereich der häufigsten 8 Nutzungsszenarien. Ein Blick auf die häufigsten Szenarien nach der Größe des Projektes zeigt deutliche Unterschiede: Kleines Projekt 2a) Zustandsverfolgung von Anforderungen bzw. Aufträgen (92% Standard) 3a) Nachweis, dass alle beschriebenen Anforderungen umgesetzt sind (83%) 15

17 2b) Planung von Releases (69%) 1a) Nachvollziehen, wie einzelne Anforderungen entstanden sind (66%) 1c) Dokumentation der Historie (62%) Mittleres Projekt 2a) Zustandsverfolgung von Anforderungen bzw. Aufträgen (68%) 5a) Entwickeln von Testfällen (direkt aus den Anforderungen) (64%) 2b) Planung von Releases (61%) 3a) Nachweis, dass alle beschriebenen Anforderungen umgesetzt sind (59%) 5b) Fehlersuche nach Tests (54%) Großes Projekt 2a) Zustandsverfolgung von Anforderungen bzw. Aufträgen (84%) 1a) Nachvollziehen, wie einzelne Anforderungen entstanden sind (79%) 1b) Verfeinern von Anforderungen (72%) 3b) Dokumentation der Traceability (71%) 5b)/2b) Fehlersuche nach Tests /Planung von Releases (68%) Die stärksten Defizite bestehen im Bereich der Entwicklung. Hier existieren auch die größten Unterschiede zwischen kleinen Projekten, wo Traceability nur gelegentlich zum Einsatz kommt und großen Projekten, wo die Nutzung relativ häufig bereits Standard ist. In der Entwicklung ist für die Erstellung und die Pflege von Links ein relativ hoher Aufwand notwendig. Insbesondere in den Entwicklungsteams sind zusätzliche Aufwendungen nur schwer zu vermitteln. Ein möglicher Grund für den besonders starken Einsatz der Traceability in großen Projekten liegt möglicherweise darin begründet, dass in komplexeren Projekten ein höherer Leidensdruck für den Einsatz gegeben ist. Der Nutzen lässt sich damit besser begründen. Zudem werden in größeren Projekten auf Grund der hohen Komplexität leistungsfähigere Werkzeuge eingesetzt, die die Softwareentwickler entlasten. Interessant ist das Nutzungsszenario der Qualitätsanalyse über die Analyse von Anhängigkeiten (4c). Deckt eine Komponente zu viele Anforderungen ab, so ist über eine Umstrukturierung nachzudenken. Auch wenn dieses Nutzungsszenario in vielen Projekten nur gelegentlich genutzt wird, so scheint dieser von den Teilnehmern als recht wichtig eingeschätzt zu werden. Das hat die verbale Auswertung ergeben. Die Auswertung der verbalen Eingaben hat zumindest bestätigt, dass Traceability auch als eine wichtige Voraussetzung für die Weiterentwicklung gesehen wird. Dies wird in den angegebenen Zahlen des Fragenkomplexes 6 nicht allzu deutlich. Ein Grund für diesen scheinbaren Widerspruch kann hier sein, dass relativ häufig die Weiterentwicklung direkt vom Entwicklungsteam durchgeführt wird. Es wurde ergänzend angegeben, dass Traceability allgemein für die Dokumentation verwendet wird. Da das Ziel der Dokumentation nicht angegeben wurde, kann vermutet werden, dass diese Dokumentation als eine Voraussetzung für die Weiterentwicklung angesehen wird. Durch offene Fragestellungen konnten durch die Umfrage weitere Nutzungsszenarien identifiziert werden. Diese müssen noch näher spezifiziert werden. So ist der Einsatz der Traceability für die Entlastung der Projektleitung gegen projektpolitische Angriffe (7a) wahrscheinlich damit zu begründen, dass mittels Traceability gut nachgewiesen werden kann, warum eine Entwicklung sich verzögert hat. Über den quantitativen Einsatz dieser Nutzungsszenarien lassen sich noch keine Aussagen treffen. Die Aussagen dazu, inwieweit die Mitarbeiter in den Prozess der Traceability einbezogen sind, die Ziele und ihre Rolle kennen (Statement d), zeigt deutlich, dass in der Information und Motivation der Mitarbeiter noch ein hohes Potential liegt. Die meisten Teilnehmer äußerten sich sehr positiv über den Einsatz von Traceability. Als wichtigster Effekt wird die steigende Qualität der entstehenden Produkte genannt. Für diese Aussage, werden von uns die Ursachen über verschiedene Nutzungsszenarien hinweg vermutet. So geht eine Qualitätssicherung über den reinen Einsatz der Traceability zu Test und Fehlersuche hinaus. Durch 16

18 einen guten Einsatz von Traceability wird vielmehr der Softwareentwicklungsprozess als Ganzes qualitativ verbessert. In den verbalen Einschätzungen wurde auf die Notwendigkeit hingewiesen ein gutes Verhältnis zwischen Aufwand und Nutzen herzustellen. 5 Validierung der Ergebnisse Konstruktvalidität Durch den Einsatz eines Fragebogens ist eine Beeinflussung der Teilnehmer durch den Fragenden weitgehend ausgeschlossen. Es wurde versucht, durch eine klare allgemeinverständliche Sprache und mit einem zweistufigen Pretest der Umfrage unklare Fragestellungen zu vermeiden. Die positiven Kommentare zur Fragebogengestaltung lassen darauf schließen, dass dies weitgehend gelungen ist. Trotzdem können grade durch den unterschiedlichen Background der Probanden Missverstände nicht ausgeschlossen werden. Interne Validität Eine Herausforderung für alle Befragungen ist die Auswahl einer repräsentativen Beteiligungsgruppe. Die Arbeit mit einem anonymen Online-Fragebogen bietet die Möglichkeit eine Umfrage auch über Interessensgruppen, z.b. Newsgroups in sozialen Netzwerken oder öffentlichen Foren zu verbreiten. Dadurch ist es möglich gleichzeitig eine höhere Anzahl von Personen anzusprechen. Bei diesem Vorgehen muss man sich jedoch bewusst sein, dass die Rücklaufquote von vorn herein einer Auswahl unterliegt. Über Newsgruppen werden in der Regel Menschen erreicht, die sich aktiv mit bestimmten Themen beschäftigen und damit bereits eine gewisse Vorauswahl bilden. Dies muss bei der Auswertung der Umfrage Beachtung finden [10] [6]. Es wird daher einschränkend festgestellt, dass die Studie mehrheitlich Personen angesprochen hat, die Traceability zumindest interessiert gegenüber gestanden haben. Sie lässt damit keinen Schluss auf die generelle Häufigkeit der Nutzung von Traceability in der Praxis zu. Es sind lediglich Schlüsse zulässig, wofür Traceability in Projekten eingesetzt wird, in denen Traceability ein Thema ist. Externe Validität Die Anzahl der Befragten ist mit 71 vollständig ausgefüllten Fragebögen statistisch relevant. Abschnitte 2.2 und 2.3 zeigen, dass sich die Probanden sowohl mit sehr unterschiedlichen Rollen als auch aus unterschiedlichen Projekten beteiligt haben. Es ist daher davon auszugehen, ein recht umfassendes Bild über die Nutzungsszenarien erhalten zu haben. Um eine hohe Antwortrate zu generieren, ist ein Kompromiss zu finden zwischen der Anzahl der möglichen Fragen (und der daraus abzulesenden Ergebnissen) und der Kürze des Fragebogens (und der damit verbundenen Motivation der Teilnehmer) [7]. Es wurde daher auf Fragen nach der Branchenzugehörigkeit der Projekte verzichtet, ebenso auf Fragen zum konkreten Vorgehen im Softwareentwicklungsprozess. Die breite Streuung der Antworten lässt jedoch den Schluss zu, dass sehr unterschiedliche Branchen beteiligt waren. Bezüglich der Vorgehensmodelle unter besonderer Einbeziehung agiler Vorgehen ist eine weitere Studie geplant. Interpretation der Ergebnisse Zur Auswertung der Ergebnisse standen verschiedene Zahlen zur Verfügung. So kann ein Nutzungsszenario häufig eingesetzt werden, wenn viele Probanden angaben, dieses regelmäßig zu nutzen bzw. wenn wenige Probanden angaben, das Szenario selten einzusetzen. Bei der Auswertung wurde auf beide Zahlen geachtet. Standen diese im Widerspruch, wurde das Nutzungsszenario nicht gewertet. Das gleich gilt für die Bewertung der Statements trifft zu, trifft zum Teil zu, trifft gar nicht zu. 17

19 6 Zusammenfassung Es wurde eine Umfrage vorgestellt, die einen Überblick über den Praxiseinsatz von Traceability unter dem Fokus einzelner Nutzungsszenarien gibt. Es muss einschränkend festgestellt werden, dass die Studie mehrheitlich Personen angesprochen hat, die Traceability zumindest interessiert gegenüber gestanden haben. Sie lässt damit keinen Schluss auf die generelle Häufigkeit der Nutzung von Traceability in der Praxis zu. Die Studie hat gezeigt, dass mit 60% deutlich mehr als die Hälfte der Befragten vom Einsatz der Traceability Vorteile für die weitere Softwareentwicklung bzw. die Qualität und Planung erwarten. Traceability wird in unterschiedlichen Nutzungsszenarien eingesetzt. Ein Schwerpunkt wird im Bereich des Managements von Softwareprojekten deutlich. Die wichtigsten Szenarien wurden identifiziert. Sie liegen im Bereich der Planung gefolgt von Anforderungsanalyse und Test/Fehlersuche. Die stärksten Defizite bestehen im Bereich der Entwicklung. Es konnten darüber hinaus noch weitere Nutzungsszenarien gefunden werden. Traceability wird in kleinen, mittleren und großen Projekten eingesetzt. Es gibt hier jedoch deutliche Unterschiede in den eingesetzten Nutzungsszenarien. Es wurde festgestellt, dass nur in wenigen Projekten versucht wird, die ganze Bandbreite an Nutzungsszenarien abzudecken. In vielen Projekten gibt es hingegen Schwerpunkte in der Nutzung von Traceability. Inwieweit hier eine bewusste Auswahl getroffen wurde kann nicht gesagt werden. Die meisten Teilnehmer äußerten sich sehr positiv über den Einsatz von Traceability. Als wichtigster Effekt wird die steigende Qualität der entstehenden Produkte herausgestellt. Die wichtigste Herausforderung für einen erfolgreichen Einsatz von Traceability ist eine gute Balance zwischen Aufwand und Nutzen zu finden. 18

20 7 References [1] Xing-Forum der Gruppe: CMMI (Capability Maturity Model Integration) - Best Practices. [2] Xing-Forum der Gruppe: Qualitätsmanagement für Software-Projekte. [3] Xing-Forum der Gruppe: Requirements Engineering. [4] Brad Appelton. Blog: Brad appleton s acme blog; categorie traceability. last vitit 01/2012. [5] Brad Appleton. Website: The trouble with tracing: Traceability dissected last visite [6] J. Daly, J. Miller, A. Brooks, M. Roper, and M. Wood. Issues on the object-oriented paradigm: A questionnaire survey, [7] Barbara A. Kitchenham and Shari L. Pfleeger. Personal opinion surveys. In Guide to Advanced Empirical Software Engineering, pages Springer London, / _3. [8] L. Klimpke and T. Hildenbrand. Towards end-to-end traceability: Insights and implications from five case studies. In Software Engineering Advances, ICSEA 09. Fourth International Conference on, pages , sept [9] Patrick Mäder, Orlena Gotel, and Ilka Philippow. Motivation matters in the traceability trenches. In Proceedings of 17th International Requirements Engineering Conference (REâ 09), [10] T. Punter, M. Ciolkowski, B. Freimut, and I. John. Conducting on-line surveys in software engineering. In International Symposium on Empirical Software Engineering, ISESE Proceedings., pages 80 88, sept.-1 oct [11] Balasubramaniam Ramesh and Matthias Jarke. Toward reference models for requirements traceability. IEEE Trans. Softw. Eng., 27(1):58 93, [12] Janice Singer, Susan E. Sim, and Timothy C. Lethbridge. Software engineering data collection for field studies. In Forrest Shull, Janice Singer, and Dag I. K. Sjàberg, editors, Guide to Advanced Empirical Software Engineering, pages Springer London, / _1. [13] George Spanoudakis and Andrea Zisman. Software traceability: A roadmap. In Chang S. K., editor, Handbook of Software Engineering and Knowledge Engineering, volume III, pages World Scientific Publishing Co., River Edge, NJ, [14] Anja von Knethen and Barbara Paech. A survey on tracing approaches in practice and research. IESE-Report /E, Fraunhofer Institut Experimentelle Software Engineering, Kaiserslautern, Germany, [15] Stefan Winkler and Jens von Pilgrim. A survey of traceability in requirements engineering and model-driven development. Software and Systems Modeling, 9(4): ,