Fragebogen
3   [Seiten-ID: 1189] [L]
Motivation

Sehr geehrte Damen und Herren,

die Einführung von modernen Software-Entwicklungstechniken dauert oft mehrere Jahre. Speziell beim Transfer von Forschungsergebnissen zeigt
sich, dass auch ausgereifte Techniken oft nicht in der Praxis benutzt werden. Das Beispiel der Inspektionen zeigt, dass trotz vielfältiger Erfolgsberichte
 und empirisch gestützter Forschung die Technik in der Industrie nicht sehr weit verbreitet ist.

Am Beispiel der Inspektionen untersuchen Mitarbeiter des Fraunhofer Institutes für Experimentelles Software Engineering, anhand welcher Informationen
 Entscheider den Nutzen und die Risiken von Softwarenentwicklungstechniken und –methoden bewerten, welche der relevanten Informationen ggf. fehlen
 und welche Informationen die Forschung bereitstellen sollte, um den Transfer zu vereinfachen.

Um dieses Vorhaben zu unterstützen, wird eine Online-Umfrage durchgeführt, mit dem Ziel, einen Überblick über die Verbreitung von Inspektionen in der
Industrie zu bekommen und die Gründe für den Einsatz bzw. die Ablehnung von Inspektionen zu ermitteln.

Falls Sie mit der Softwareentwicklung in Ihrem Unternehmen vertraut sind, würden wir Sie bitten, sich an der Umfrage zu beteiligen. Vielleicht kennen Sie
 Personen, die Interesse an einer solchen Umfrage haben könnten. Wir würden Sie in diesem Fall bitten, diese Mail weiterzuleiten.

Die Teilnahme an der Online-Umfrage ist freiwillig. Alle Angaben werden selbstverständlich anonym behandelt. Die Bearbeitung wird ca. 15-20 Minuten
in Anspruch nehmen.

Wenn Sie Fragen zu der Umfrage haben, wenden Sie sich bitte an:
Andreas Jedlitschka, Tel. 0631 6800 2260, oder per e-mail an: andreas.jedlitschka@iese.fraunhofer.de


Unter allen eingehenden Antworten werden wir 3 Exemplare des Buches: "A Handbook of Software and System Engineering"
von A. Endres und D. Rombach verlosen

Wir danken Ihnen bereits jetzt für Ihre Mitarbeit.


4   [Seiten-ID: 1190] [L]
Werden Inspektionen angewandt

Zur eindeutigen Bewertung Ihrer Antworten möchten wir zunächst definieren, was wir im Folgenden unter dem Begriff "Inspektionen" verstehen:

Der Begriff Inspektion umfasst in der Umfrage jegliche Art von Review, das in den verschiedenen Phasen der Softwareentwicklung auf
Zwischenprodukten (z.B. Anforderungen, Design, Code, Testfälle) durchgeführt wird. Dabei ist das Ziel der Inspektion mögliche Fehler in
den untersuchten Produkten zu identifizieren. Daher beinhaltet eine Inspektion eine explizite Phase in der die Inspekteure nach Fehlern suchen.
Die Fehlersuche kann durch die Erfahrung der Inspekteure oder durch den Einsatz von systematischen Techniken wie etwa Checklisten unterstützt
 werden.

Wir möchten Sie bitten sogenannte Management-Reviews, die zur Überprüfung des Projektstatus dienen, nicht als Inspektion zu betrachten.

Bitte beantworten Sie alle nun folgenden Fragen unter Berücksichtigung der oben genannten Definition



Werden in Ihrer Gruppe Inspektionen angewendet?

Ja
Nein
Nicht mehr
5.1   [Seiten-ID: 1191] [L]
Einführung von Inspektionen
In welchem Umfang werden in Ihrer Gruppe Inspektionen angewendet?

für alle Projekte
für die meisten Projekte
für ausgewählte Projekte
für wenige Projekte
Wie sind Sie auf Inspektionen aufmerksam geworden
Bitte geben Sie an, durch wen oder was Sie auf Inspektionen aufmerksam geworden sind.

Berater 
Kollege (intern) 
Kollege (extern) 
Artikel in Praktiker-Zeitschrift (z.B. IEEE Software) 
Artikel in wissenschaftl. Zeitschrift (z.B. IEEE Transaction on Software Engineering) 
Firmenübergreifende Austauschrunden 
Internet 
Konferenz 
Fachbuch 
sonsitge Literatur (z.B. Standards) 
Andere:  
Der Startpunkt für die Einführung von Inspektionen ist die Entscheidung einer Person,
Inspektionen in einem Projekt oder einer Gruppe/Abteilung einzuführen.
Wer hat die Einführung angeregt?

Oberstes Managment 
Qulitätsmanagement 
Bereichsleiter 
Projektleiter 
Gruppen- oder Teammitglied 
Berater (intern/extern) 
Andere:  
Wer hat die Entscheidung getroffen?

Oberstes Managment 
Qulitätsmanagement 
Bereichsleiter 
Projektleiter 
Andere:  
5.2   [Seiten-ID: 1192] [L]
Einführung Information
Für jede Entscheidung werden Grundlagen unterschiedlicher Art herangezogen.
Welche Informationen waren in Ihrer Gruppe ausschlaggebend für die Einführung von Inspektionen?
Bitte geben Sie für jedes Kriterium an, in wie weit es für die Entscheidung nicht relevant, wenig relevant, relevant, oder sehr relevant war.

nicht relevant wenig relevant relevant sehr relevant
Einfluss auf die Entwicklungskosten
Einfluss auf die Entwicklungsdauer
Einfluss auf die Produktqualität
Erwartung positiver Kosten-Nutzen
Komplementarität mit anderen verwendeten Techniken (z.B. gute Ergänzung zum Testen)
Erwartung Return on Investment
Anwendung ist aufgrund von Standards verpflichtend
Andere:  
Welche zusätzlichen Informationen hätten Ihre Gruppe bei der Entscheidung für die Einführung von
Inspektionen unterstützt, ist aber nach Ihrer Kenntnis nicht verfügbar?
Bitte geben Sie für jede zusätzlich gewünschte Information an, in wie weit sie für die Entscheidung nicht relevant, wenig relevant, relevant,
oder sehr relevant ist.

nicht relevant wenig relevant relevant sehr relevant
Einfluss auf die Entwicklungskosten
Einfluss auf die Entwicklungsdauer
Einfluss auf die Produktqualität
Erwartung positiver Kosten-Nutzen
Komplementarität mit anderen verwendeten Techniken (z.B. gute Ergänzung zum Testen)
Return on Investment
Andere:  
In den vorherigen Fragen haben wir Sie nach Informationen gefragt, die für die Einführung von
Inspektionen ausschlaggebend sind. In dieser Frage möchten wir gerne wissen, aus welcher Quelle Ihre
Gruppe diese Informationen bezogen hat und wie stark das Vertrauen in diese Quelle ist.
Bitte geben Sie an, welche der folgenden Quellen bei der Gewinnung dieser Information für Ihre Entscheidung relevant waren.
Dabei gibt die Relevanz auch an, wie stark Sie dieser Quelle vertrauen.

nicht relevant weniger relevant relevant sehr relevant
Berater
Kollege (intern)
Kollege (extern)
Artikel in Praktiker-Zeitschrift (z.B. IEEE Software)
Artikel in wissenschaftl. Zeitschrift (z.B. IEEE Transaction on Software Engineering)
Firmenübergreifende Austauschrunden
Internet
Konferenz
Fachbuch
sonsitge Literatur
Andere:  
Wie wichtig ist es für die Entscheidung, dass die Informationen aus Ihrer Branche stammen?

nicht wichtig weniger wichtig wichtig sehr wichtig
5.3   [Seiten-ID: 1193] [L]
Zielsetzung
Die Einführung von qualitätssichernden Maßnahmen, wie etwa Inspektionen, ist mit einer Zielsetzung
verbunden. Mit welcher Zielsetzung wurden Inspektionen in Ihrer Gruppe eingeführt?
Bitte markieren Sie wie relevant Inspektionen zur Erreichung der unten genannten Ziele sind

nicht relevant wenig relevant relevant sehr relevant
(frühe) Fehlerfindung
Qualität des Endproduktes verbessern
Einhaltung von Standards (z.B. CMMI, Entwicklungsstandards, oder interne)
Reduktion von Entwicklungsaufwand
Team-building
Training von unerfahrenen Mitarbeitern
Fehlerkostenreduzierung
Identifizierung von Fehlerquellen im Entwicklungsprozess
Andere:  
5.4   [Seiten-ID: 1196] [L]
Zyklus und Eigenschaften
Inspektionen können im gesamten Entwicklungszyklus eingesetzt werden. Auf welchen Dokumenten
oder Teildokumenten werden Inspektionen in Ihrer Gruppe eingesetzt?
Mehrfachauswahl ist möglich.

Anforderungen (Lasten oder Pflichtenheft) 
Architektur 
Design oder Designteile (bestimmte Diagrammtypen) 
Code 
Testfälle 
Projektpläne 
Testpläne 
Andere:  
Inspektionen können unterschiedlich intensiv durchgeführt werden. Bitte wählen Sie aus der
untenstehenden Liste die Vorgehensweise aus, die der in Ihrer Gruppe bestehenden am ehesten
 entspricht.

Sehr formal (definierter Prozess, eingeplante Zeiten für Planung, Fehlersuche, Inspektionssitzung und
Korrektur; Inspekteure suchen individuell und intensiv nach Fehlern (vor der Sitzung); Sitzung dient zur
Fehlersammlung und Konsolidierung)
Formal (definierter Prozess; eingeplante Zeiten fürVorbereitung und Fehlersammlung (Sitzung);
Inspekteure bereiten sich auf die Sitzung vor; Fehler werden z.T. in der Sitzung z.T in der Vorbereitung
 gesucht)
Semi-Formal (definierter Prozess; eingeplante Zeiten für Inspektionssitzung; Inspekteure bereiten sich
 grob auf die Sitzung vor; Fehlersuche findet im Wesentlichen in der Sitzung statt)
informell (rudimentärer Prozess; Inspekteure investieren kaum/keine Zeit für die individuelle Fehlersuche;
 Fehler werden ausschließlich in der Sitzung (gemeinsam) gesuch)
Ad-Hoc (kein definierter Prozess; keine eingeplanten Zeiten für Fehlersuche oder Sitzung; spontane
Durchsicht eines Dokumentes durch Kollegen sofern Bedarf besteht)
Es gibt unterschiedliche Techniken, wie nach Fehlern in Dokumenten gesucht werden kann.
Welche der Techniken setzen Sie hauptsächlich zur Unterstützung der Fehlersuche in der
Inspektion ein?
Hier erläutern Sie, wie die Frage ausgefüllt werden soll (optional).

angewendet nicht angewendet
Ad-hoc (basiert rein auf Erfahrung der Inspekteure)
Checkliste (Liste mit Fragen, die zu beantworten sind)
fokussierte Checkliste (Liste mit Fragen, die auf bestimmte Aspekte fokussiert)
Szenario-basiert (Leseszenario, das dem Inspektor Arbeitsanweisungen gibt und auf bestimmte Qualitäten/Fehler fokussiert)
5.5   [Seiten-ID: 1473] [L]
Qualität
Welche der folgenden Eigenschaften des untersuchten Artefaktes werden in Ihrer Gruppe mit
Inspektionen adressiert?
Bitte legen Sie bei der Beantwortung der Frage die folgenden Definitionen zugrunde.
Konsistenz (=die Informationen innerhalb des Artefaktes widersprechen sich nicht)
Vollständigkeit (=alle Informationen aus relevanten Vorgängerartefakten sind berücksichtigt)
Korrektheit (=die im Artefakt dargestellte Information ist inhaltlich korrekt)
Minimalität (=es wird keine überflüssige Information im Dokument beschrieben)
Verständlichkeit (=die beschriebenen Informationen sind für alle Nutzer des untersuchten Dokumentes klar und verständlich)
Standard (=der Artefakt entspricht den internen Standards)

Konsistenz Vollständigkeit Korrektheit Minimalität Verständlichkeit Standard Andere
Anforderungen
Architektur
Design oder Designteile
Code
Testfälle
Projektpläne
Testpläne
Andere
Mit einer Inspektion können sowohl Eigenschaften des untersuchten Artefaktes als auch für
das Endprodukt relevanten Qualitäten adressiert werden. Welche der folgenden Qualitäten des
 Endproduktes (der Software) werden in Ihrer Gruppe mit Inspektionen adressiert?
Mehrfachauswahl ist möglich.

Funktionalität
(d.h., die Software stellt die gewünschte Funktionalität zur Verfügung) 
Effizienz und Performance
(d.h., die Software liefert akkurate Performance unter Berücksichtigung der zur Verfügung stehenden
Ressourcen. Dies beinhaltet Zeitverhalten, Ressourcenauslastung, etc.)  
Wartbarkeit
(d.h., die Software ist effizient zu ändern bzw. zu erweitern) 
Wiederverwendbarkeit
(d.h., die Software kann effizient an unterschiedliche Umgebungen angepasst werden, ohne die
Software umfangreich ändern zu müssen) 
Usability
(d.h., das Software-Produkt ist schnell zu verstehen, effizient zu erlernen und zu benutzen) 
Zuverlässigkeit
(d.h., die Software stellt die gewünschte Funktionalität mit einer adäquaten Performance unter
 gegebenen Umständen bereit. Dies beinhaltet Robustheit, Fehlertoleranz, etc.) 
Safety
(d.h., die Software kann Situationen vermeiden, in denen Gefahr für katastrophale Verluste besteht,
bspw. Verlust von Leben und Kapital). 
Security
(d.h., die Software kann Informationen und Daten vor nichtautorisiertem Zugriff schützen) 
Testability
(d.h., sinnvolle Tests und Prüfungen auf der Software können definiert und durchgeführt werden) 
Andere:  
5.6   [Seiten-ID: 1474] [L]
Vorgehen / Messen
Wenn eine Inspektion in Ihrer Gruppe durchgeführt wird, was ist dann die typische
Herangehensweise?

Das gesamte Dokument nach möglichst vielen Fehler zu untersuchen
Gezielt bestimmte Teile des Dokumentes nach allen möglichen Fehlern untersuchen
Gezielt bestimmte Qualitäten bzw. Fehlertypen im ganzen Dokument adressieren
Gezielt bestimmte Qualitäten bzw. Fehlertypen in ausgewählten Teilen des Dokumentes untersuchen
Gezielt bestimmte Qualitäten bzw. Fehlertypen in Dokumenten unterschiedlicher Entwicklungsphasen
adressieren
Etwas Anderes, und zwar:  
Während der Inspektion können Daten über Fehleranzahl, Aufwände, gefundene Fehlertypen,
Fehlerursprünge gesammelt werden. Wie werden in Ihrer Gruppe die gesammelten
Inspektionsdaten analysiert?

Wir sammeln keine Inspektionsdaten 
Effizienzanalyse (z.B., wie viele Fehler mit wie viel Aufwand gefunden wurden) 
Kosteneffektivitätsanalyse (z.B., was konnte an möglichen Folgekosten durch die Inspektion eingespart
 werden) 
Fehlerverfolgungsmodelle (d.h., in welchen Phasen bzw. Artefakten sind typischerweise viele Fehler,
wo werden Fehler aus dem Entwicklungszyklus herausgefiltert) 
Fehlertypanalysen (z.B., welche Fehler sind typisch in welchen Artefakten, und in welchen Inspektionen
 werden diese Fehlertypen gefunden) 
Andere:  
5.7   [Seiten-ID: 1195] [L]
Planungsaspekte
Ein Schritt bei der Durchführung von Inspektionen ist deren Planung.
Führen Sie in Ihrer Gruppe eine systematische Planung der Inspektionsaktivitäten durch?
Unter Planung ist die gezielte Auswahl von Inspekteuren, Dokumenten und Qualitäten (welche Qualitäten soll sichergestellt werden),
sowie die Planung der benötigten Aufwände für die Inspektion(sschritte) zu verstehen.

immer
meistens
selten
nie
5.8.1   [Seiten-ID: 1268] [L]
planung ja
Welche der folgenden Aspekte sind bei der Planung einer Inspektion in Ihrer Gruppe von Bedeutung?
Bitte geben Sie für jeden Aspekt seine typische Relevanz in der Inspektionsplanung an.

nicht relevant wenig relevant relevant sehr relevant
Größe / Umfang des zu inspizierenden Artefakts
Wichtigkeit (Kritikalität) des inspizierten Artefaktes (Inhalt ist kritisch für den Erfolg des Projektes)
Verfügbarkeit von Experten (=Personen, die sich mit der im Artefakt beschriebenen Information sehr gut auskennen) während der Inspektion
Verfügbarkeit von Entwicklerzeit (d.h., Zeitrestriktionen im Entwicklungsprozess)
Daten über vergangene Inspektionen (wie etwa Anzahl gefundener Fehler, Effizienz, benötigt Zeit, etc)
Qualitäten, die das Endprodukt erfüllen sollte (z.B. Performance, Security, Zuverlässigkeit, etc.)
Eigenschaften, die der Artefakt erfüllen sollte (z.B. Konsistenz, Vollständigkeit, etc)
Verfügbarer Aufwand für alle qualitätssichernde Maßnahmen (zur systematische Balancierung der Aufwände für Inspektionen und anderen Techniken wie z.B. Testen)
Daten bzgl. der Qualität bzw. Fehler die im Endprodukt sichergestellt bzw. vermieden werden sollen
Sonstige:  
Der für die Inspektion zur Verfügung stehende Aufwand kann auf unterschiedliche Weise eingesetzt werden.
Bitte wählen Sie die Alternative, die dem Vorgehen in Ihrer Gruppe am nächsten kommt.
Stellen Sie sich vor, Sie haben 100 Stunden für alle Inspektionsaktivitäten im Entwicklungsprozess zur Verfügung

Kein optimierter Einsatz (es wird in jeder Entwicklungsstufe so viel wie möglich inspiziert
Gleichverteilung des Aufwandes (jede Entwicklungsstufe erhält den gleichen Anteil an Inspektionsaufwand)
Phasenoptimierung (d.h., der Einsatz der Inspektion wird in Abhängigkeit der zu erreichenden Qualitätsziele innerhalb der
betrachteten Entwicklungsstufe optimiert)
Lebenszyklusweit (d.h. der Einsatz von Inspektionen wird in Abhängigkeit der zu erreichenden Qualitätsziele über alle
Entwicklungsstufen hinweg optimiert)
Andere Strategie, und zwar:  
Wenn Sie gezielt Dokumentteile bzw. Qualitäten adressieren, welche Kriterien ziehen Sie zur Auswahl heran,
d.h., wie entscheiden Sie, welche Qualität, bzw. welche Dokumentteile in der Inspektion adressiert werden sollen?

5.9   [Seiten-ID: 1197] [L]
Best Practices
Bitte schätzen Sie nach Ihrer Erfahrung ein, wie wichtig die folgenden Punkte sind, um Inspektionen erfolgreich einzuführen.

nicht relevant wenig relevant relevant sehr relevant
Unterstützung durch das Management erzeugen
Einsetzen eines Inspektionsverantwortlichen (Champion)
Training für Inspekteure
Training für Inspektionsverantwortliche
Überzeugung der Entwickler
Andere und zwar:  
Um Inspektionen erfolgreich durchzuführen, sind bestimmte Aspekte wie klare Verantwortlichkeiten, Motivation
der Entwickler, etc. von Bedeutung. Bitte nennen Sie stichpunktartig „Best Practices“, die in Ihrer Gruppe zum
Erfolg der Inspektion beigetragen haben?

Nach der Einführung von Inspektionen ist es wichtig, den Inspektions-Prozess kontinuierlich weiter anzuwenden.
Welche Informationen sind wichtig, um die Weiterführung des Prozesses zu motivieren?

Messen des Inspektionserfolges und Feedback an die Entwickler / Inspekteure: Bitte nennen Sie Informationen über den Inspektionsprozess, die Sie in Ihrer Gruppe den Inspekteuren weitergeben    
Messen des Inspektionserfolges und Feedback an das Management: Bitte nennen Sie Informationen über den Inspektionsprozess, die Sie in Ihrer Gruppe den Inspekteuren weitergeben     
Kontinuierliches Training für Beteiligte am Inspektionsprozess    
Einbindung von Experten in den Inspektionsprozess     
Klare Richtlinien zur Durchführung der Inspektion    
Andere    
6.1   [Seiten-ID: 1200] [L]
Entscheidung Abbruch
Können Sie die Entscheidung, Inspektionen nicht mehr in einem Projekt oder einer Gruppe/Abteilung zu
verwenden, einer Person/Gruppe zuordnen?

Oberstes Managment 
Qulitätsmanagement 
Bereichsleiter 
Projektleiter 
Gruppen- oder Teammitglied 
Berater (intern/extern) 
Keine bewußte Entscheidung 
Andere:  
Was sind die Gründe, Inspektionen nicht mehr einzusetzen?
Bitte geben Sie für die genannten Gründe an, in wie weit diese relevant für den Abbruch von Inspektionen in Ihrer Gruppe waren.

nicht relevant wenig relevant relevant sehr relevant
Kein Kosten-Nutzen nachweisbar
Fehlende Richtlinien zur optimalen Anpassung von Inspektionen an Entwicklungskontext
Zu zeit-aufwändig
Zu kosten-aufwändig
Kein Effekt auf die Qualität des Endproduktes feststellbar
Für das Endprodukt relevante Qualitäten nicht mit Inspektionen adressierbar
Zu große Verzögerung der Entwicklung
Fehlende Balancierung mit anderen Techniken
Inspektionen wurden durch Testen ersetzt
Andere Maßnahmen versprechen bessere Effekte.
Andere:  
Welche Informationen führten zu der Entscheidung, Inspektionen nicht weiter zu verwenden?

nicht relevant wenig relevant relevant sehr relevant
Ergbnis aus begleitendem Messprogramm
Erfahrungsberichte (intern)
Erfahrungsberichte (extern) gleiche Domäne
Erfahrungsberichte (extern) gleiche Domäne
Studie
wissenschaftl. Publikation
Andere:  
6.2   [Seiten-ID: 1199] [L]
I werden nicht mehr verwendet
In welchem Umfang wurden in Ihrer Gruppe Inspektionen angewendet?

für alle Projekte
für die meisten Projekte
für ausgewählte Projekte
für wenige Projekte
Inspektionen können im gesamten Entwicklungszyklus eingesetzt werden. Auf welchen Dokumenten oder
 Teildokumenten wurden Inspektionen in Ihrer Gruppe eingesetzt?
Mehrfachauswahl ist möglich.

Anforderungen (Lasten oder Pflichtenheft) 
Architektur 
Design oder Designteile (bestimmte Diagrammtypen) 
Code 
Testfälle 
Projektpläne 
Testpläne 
Andere:  
Inspektionen können unterschiedlich intensiv durchgeführt werden. Bitte wählen Sie aus der
untenstehenden Liste die Vorgehensweise aus, die der in Ihrer Gruppe durchgeführten am ehesten entsprach.

Sehr formal (definierter Prozess, eingeplante Zeiten für Planung, Fehlersuche, Inspektionssitzung und Korrektur;
 Inspekteure suchen individuell und intensiv nach Fehlern (vor der Sitzung); Sitzung dient zur Fehlersammlung und
 Konsolidierung)
Formal (definierter Prozess; eingeplante Zeiten fürVorbereitung und Fehlersammlung (Sitzung); Inspekteure bereiten
 sich auf die Sitzung vor; Fehler werden z.T. in der Sitzung z.T in der Vorbereitung gesucht)
Semi-Formal (definierter Prozess; eingeplante Zeiten für Inspektionssitzung; Inspekteure bereiten sich grob auf die
Sitzung vor; Fehlersuche findet im Wesentlichen in der Sitzung statt)
informell (rudimentärer Prozess; Inspekteure investieren kaum/keine Zeit für die individuelle Fehlersuche; Fehler werden
 ausschließlich in der Sitzung (gemeinsam) gesuch)
Ad-Hoc (kein definierter Prozess; keine eingeplanten Zeiten für Fehlersuche oder Sitzung; spontane Durchsicht eines
 Dokumentes durch Kollegen sofern Bedarf besteht)
Welche der folgenden Eigenschaften des untersuchten Artefaktes wurden in Ihrer Gruppe mit Inspektionen
 adressiert?
Bitte legen Sie bei der Beantwortung der Frage die folgenden Definitionen zugrunde.
Konsistenz (=die Informationen innerhalb des Artefaktes widersprechen sich nicht)
Vollständigkeit (=alle Informationen aus relevanten Vorgängerartefakten sind berücksichtigt)
Korrektheit (=die im Artefakt dargestellte Information ist inhaltlich korrekt)
Minimalität (=es wird keine überflüssige Information im Dokument beschrieben)
Verständlichkeit (=die beschriebenen Informationen sind für alle Nutzer des untersuchten Dokumentes klar und verständlich)
Standard (=der Artefakt entspricht den internen Standards)

Konsistenz Vollständigkeit Korrektheit Minimalität Verständlichkeit Standard Andere
Anforderungen
Architektur
Design oder Designteile
Code
Testfälle
Projektpläne
Testpläne
Andere
Mit einer Inspektion können sowohl Eigenschaften des untersuchten Artefaktes als auch für das
Endprodukt relevanten Qualitäten adressiert werden. Welche der folgenden Qualitäten des Endproduktes
(der Software) wurden in Ihrer Gruppe mit Inspektionen adressiert?
Mehrfachauswahl ist möglich.

Funktionalität
(d.h., die Software stellt die gewünschte Funktionalität zur Verfügung) 
Effizienz und Performance
(d.h., die Software liefert akkurate Performance unter Berücksichtigung der zur Verfügung stehenden Ressourcen.
Dies beinhaltet Zeitverhalten, Ressourcenauslastung, etc.)  
Wartbarkeit
(d.h., die Software ist effizient zu ändern bzw. zu erweitern) 
Wiederverwendbarkeit
(d.h., die Software kann effizient an unterschiedliche Umgebungen angepasst werden, ohne die Software
umfangreich ändern zu müssen) 
Usability
(d.h., das Software-Produkt ist schnell zu verstehen, effizient zu erlernen und zu benutzen) 
Zuverlässigkeit
(d.h., die Software stellt die gewünschte Funktionalität mit einer adäquaten Performance unter gegebenen
Umständen bereit. Dies beinhaltet Robustheit, Fehlertoleranz, etc.) 
Safety
(d.h., die Software kann Situationen vermeiden, in denen Gefahr für katastrophale Verluste besteht, bspw.
Verlust von Leben und Kapital). 
Security
(d.h., die Software kann Informationen und Daten vor nichtautorisiertem Zugriff schützen) 
Testability
(d.h., sinnvolle Tests und Prüfungen auf der Software können definiert und durchgeführt werden) 
Andere:  
Während der Inspektion können Daten über Fehleranzahl, Aufwände, gefundene Fehlertypen,
Fehlerursprünge gesammelt werden. Wie wurden in Ihrer Gruppe die gesammelten Inspektionsdaten
 analysiert?

Wir sammeln keine Inspektionsdaten 
Effizienzanalyse (z.B., wie viele Fehler mit wie viel Aufwand gefunden wurden) 
Kosteneffektivitätsanalyse (z.B., was konnte an möglichen Folgekosten durch die Inspektion eingespart werden) 
Fehlerverfolgungsmodelle (d.h., in welchen Phasen bzw. Artefakten sind typischerweise viele Fehler, wo
werden Fehler aus dem Entwicklungszyklus herausgefiltert) 
Fehlertypanalysen (z.B., welche Fehler sind typisch in welchen Artefakten, und in welchen Inspektionen
werden diese Fehlertypen gefunden) 
Andere:  
7.1   [Seiten-ID: 1201] [L]
Bekanntheit
Sie haben angegeben, Inspektionen nicht einzusetzen. Mit den folgenden Fragen möchten wir die Gründe
dafür näher kennen lernen.
Ist Ihnen die Technik „Inspektionen“ bekannt?

ja
nein
7.2.1   [Seiten-ID: 1202] [L]
bewusste Entscheidung gegen
Hat es eine bewusste Entscheidung gegen den Einsatz von Inspektionen gegeben?

ja
nein
7.2.2.1   [Seiten-ID: 1203] [L]
Gründe Entscheidung gegen
Können Sie die Entscheidung, Inspektionen in einem Projekt oder einer Gruppe/Abteilung nicht einzuführen, einer Person/Gruppe zuordnen?
Wer hat die Entscheidung getroffen?

Oberstes Managment 
Qulitätsmanagement 
Bereichsleiter 
Projektleiter 
Andere:  
Was sind die Gründe, Inspektionen nicht einzusetzen?
Bitte geben Sie für die Gründe an, in wie weit Sie in Ihrer Gruppe relevant sind, Inspektionen bewusst nicht einzusetzen.

nicht relevant wenig relevant relevant sehr relevant
Allgemein zu wenige Information verfügbar
Kein Kosten-Nutzen nachweisbar
Fehlende Richtlinien zur optimalen Anpassung von Inspektionen an Entwicklungskontext
Zu zeit-aufwändig
Zu kosten-aufwändig
Kein Effekt in Bezug auf die Qualität des Endproduktes feststellbar
Für das Endprodukt relevante Qualitäten nicht mit der Inspektion adressierbar
Zu große Verzögerung der Entwicklung
Fehlende Balancierung mit anderen Techniken
Inspektionen wurden durch Testen ersetzt
Andere Maßnahmen versprechen bessere Effekte
Andere:  
In der vorherigen Frage haben wir Sie nach Informationen gefragt, die für die Entscheidung gegen die Einführung
von Inspektionen ausschlaggebend waren.
In dieser Frage möchten wir gerne wissen, aus welcher Quelle Ihre Gruppe diese Informationen bezogen hat und
wie stark das Vertrauen in diese Quelle ist.
Bitte geben Sie an, durch wen oder wie Sie die Informationen erhalten haben.

nicht relevant wenig relevant relevant sehr relevant
Berater
Kollege (intern)
Kollege (extern)
Artikel in Praktiker-Zeitschrift (z.B. IEEE Software)
Artikel in wissenschaftl. Zeitschrift (z.B. IEEE Transaction on Software Engineering)
Firmenübergreifende Austauschrunden
Internet
Konferenz
Fachbuch
sonsitge Literatur
Andere:  
7.2.3.1   [Seiten-ID: 1215] [L]
Gründe unbewusste Entscheidung2
Welche Informationen würden Sie benötigen, um eine fundierte Entscheidung für oder wider Inspektionen
treffen zu können?
Bitte geben Sie für jedes Kriterium an, in wie weit es für die Entscheidung nicht relevant, wenig relevant, relevant, oder sehr relevant wäre.

nicht relevant wenig relevant relevant sehr relevant
Allgemeine Informationen zu Inspektionen
Einfluss auf die Entwicklungskosten
Einfluss auf die Entwicklungsdauer
Einfluss auf die Qualität des Endproduktes
Kosten-Nutzen Effekt
Komplementarität mit anderen verwendeten Techniken (z.B. gute Ergänzung zum Testen)
Return on Investment
Andere:  
In der vorherigen Frage haben wir Sie nach Informationen gefragt, die Sie für eine Entscheidung zur
Entscheidung für oder wider Inspektionen benötigen.
In dieser Frage möchten wir gerne wissen, aus welcher Quelle Sie diese Informationen vorzugsweise beziehen.
Bitte geben Sie an, durch wen oder wie Sie die Informationen erhalten haben.

nicht relevant wenig relevant relevant sehr relevant
Berater
Kollege (intern)
Kollege (extern)
Artikel in Praktiker-Zeitschrift (z.B. IEEE Software)
Artikel in wissenschaftl. Zeitschrift (z.B. IEEE Transaction on Software Engineering)
Firmenübergreifende Austauschrunden
Internet
Konferenz
Fachbuch
sonsitge Literatur
Andere:  
Wie wichtig ist es für die Entscheidung, dass die Informationen aus Ihrer Branche stammen?

nicht relevant wenig relevant relevant sehr relevant
7.3.1   [Seiten-ID: 1204] [L]
Gründe unbewusste Entscheidung
Wie könnte der Bekanntheitsgrad einer Software-Entwicklungs-Technik gesteigert werden?
Bitte geben Sie für jede Art der Quelle der Information an, in wie weit sie für die Verbreitung einer Technik relevant ist.

nicht relevant wenig relevant relevant sehr relevant
Berater
Kollege (intern)
Kollege (extern)
Artikel in Praktiker-Zeitschrift (z.B. IEEE Software)
Artikel in wissenschaftl. Zeitschrift (z.B. IEEE Transaction on Software Engineering)
Firmenübergreifende Austauschrunden
Internet
Konferenz
Fachbuch
sonsitge Literatur
Andere:  
Wie relevant ist es für Sie, dass die Informationen aus Ihrer Branche stammen?

nicht relevant wenig relevant relevant sehr relevant
8   [Seiten-ID: 1205] [L]
Statistik
Um Ihre Antworten besser bewerten und analysieren zu können, werden wir Ihnen im Folgenden zunächst
einige Fragen zum Kontext Ihres Unternehmens und Ihrer Rolle im Unternehmen / in Ihrer Gruppe stellen.

Was ist Ihre aktuelle Rolle in Ihrem Unternehmen
Kreuzen bitte die zutreffendste Antwortmöglichkeit an oder tragen Sie unter Andere die entsprechenden Bezeichnung ein.

Management (z.B. Bereichsleiter)
Qualitätsmanager für das Unternehmen
Qualitätsmanager für ein Projekt
Projektleiter in der Entwicklung
Software-Entwickler
Mitarbeiter der Qualitätssicherung in einem Projekt
Andere:  
Zu welchen Branchen gehört Ihr Unternehmen?
Bitte wählen Sie aus der Liste ihre Branche aus, es sind Mehrfachnennungen möglich.

Anlagenbau 
Banken und Versicherungen 
Biotechnologie 
Chemie 
Elektronik 
Energiewirtschaft 
Fahrzeuge 
Freizeit und Unterhaltung 
Gesundheitswesen 
Halbleiter 
Handel 
IT-Dienstleistung 
IT-Systemhersteller 
Luftfahrt 
Maschinenbau 
Medizintechnik 
Militärtechnik 
Software 
Telekommunikation 
Transport, Logistik und Verkehr 
Andere:  
Wieviele Mitarbeiter beschäftigt Ihr Unternehmen?
Bitte wählen Sie die zutreffenden Mitarbeiterzahlen aus.

1 bis 24
25 bis 49
50 bis 249
250 bis 999
1000 und mehr
9   [Seiten-ID: 1206] [L]
Statistik 2
Wie viele Mitarbeiter arbeiten in Ihrer Gruppe?
Wählen Sie bitte den entsprechenden Bereich aus.

1 - 9
10 - 24
25 - 49
50 und mehr
Wie würden Sie die Erfahrung der Mitarbeiter in Ihrer Gruppe einschätzen?
Geben Sie bitte eine Abschätzung der durchschnittlichen Erfahrung an.

niedrig
eher niedrig
mittel
eher hoch
hoch
Wie lange dauern typischerweise Projekte in Ihrer Gruppe?
Bitte wählen Sie den entsprechenden Bereich aus, der der durchschnittlichen Projektdauer am ehesten entspricht.

< 2 Monate
2 - 6 Monate
7 - 12 Monate
13 - 18 Monate
19 - 24 Monate
> 24 Monate
Welcher Art sind typischerweise die Projekte in Ihrer Gruppe?

Neuentwicklung
Anpassung / Integration
Erweiterung
Wartung
Andere  
10   [Seiten-ID: 1207] [L]
email
Wenn Sie eine Auswertung der Studie erhalten möchten, geben Sie bitte Ihre eMail-Adresse an. Wir garantieren die absolute Anonymität Ihrer Angaben.

11   [Seiten-ID: 1187] [L]
Endseite

Wir danken Ihnen für die Teilnahme an der Umfrage




Link zum Fraunhofer Institut Experimentelles Software Engineering:

Fraunhofer IESE

Link zur Inspektionsseite des Fraunhofer Institut Experimentelles Software Engineering:

Fraunhofer IESE Inspektions Methode