Authetizität

Authentizität ist die Echtheit und Glaubwürdigkeit eines Subjektes oder Objekts, welche durch dessen Identität (Stichwort: Identifikation) und charakteristische Merkmale eindeutig bewiesen werden kann.

Wissen

Die Authentifizierung kann zum einen durch Wissen erfolgen. Hierbei werden folgende Verfahren unterschieden.

• Passwort: Hier wird die erfolgreiche Authentifizierung von der Eingabe des korrekten Passworts abhängig gemacht.
• Callenge-Response-Prinzip: Hier authentifizieren sich zwei Computersysteme maschinell über symetrische Kryptographiemechanismen.
• Asymetrische Verschlüsselung: Diesen Verfahren funktioniert ähnlich wie das Callenge-Response-Prinzip.

Besitz

Weiterhin kann auch eine Authentifikation über den Besitz erfolgen. Diese Gegenstände können z.B. Schlüssel, Personalausweis (z.B. elektronischer Personalausweis) und Chipkarte sein. Das Verfahren ist nicht sehr sicher.

Eigenschaften

Das dritte Authentifizierungsprinzip basiert auf den persönlichen Eigenschaften des Subjekts (Benutzer). Hierunter sind biometrische Eigenschaften zu verstehen. Beispielsweise können Handvenen, Fingerabdruck, Iris durch einen passenden Scanner geprüft werden.

hybride Verfahren

Unter hybriden Verfahren bei der Authentifzierung ist eine Kombination aus mehreren der oben genannten drei Verfahren zu verstehen. Dadurch wird die Sicherheit der Authentifzierung insgesamt erheblich gesteigert und die Fehleranfälligkeit (insbes. bei den biometrischen Eigenschaften) reduziert.

Beispiel: Das Authentifizieren an einem Geldautomaten ist ein hybrides Verfahren. Die Authentifzierung mittels EC-Karte ist besitzbasiert. Die Eingebe der korrekten PIN ist wissenbasiert, da diese ein Passwort darstellt.

1. die Schaumstoff Spitzhacke

Eine sehr schöne Spitzhacke, für Minecraft im Real-Life. Sie ist aus Schaumstoff und macht sich bestimmt auf jeder Party super! Eine super Geschenkidee für Nerds!

Eine Tolles Schwert, mit dem man nicht nur bei Minecraft, sondern auch als Ritter des Cyberspace eine gute Figur macht. Die ist bei Conventions und im Fasching der Gag schlechthin.

Creeper T-Shirts gibt es viele, doch diese ist besonders gut gelungen. Es zeigt die Anatomie eines Creepers.

Mit dieser Minecraft Creeper-Kaffeetasse wird man ganz besonders schnell morgen wach… Sie ist auch für Tee geeignet. Das hat nicht jeder!

Die bewährte Spitzhacke ist auch manchmal für anderes außer den Abbau von Rohstoffen gut. Auch Flaschen kann man damit öffnen. Probiert es einfach mal aus! Gerade an Vatertag ein tolles Geschenk für Dad!

sicher

Die verschlüsselte Informationen sind sicher, wenn es nur möglich ist, dass diese mit dem dazugehörigen Schlüssel hergeleitet werden können.

kryptographisch sicher

Die kryptographische Sicherheit ist dann gewährleistet, wenn es praktisch unmöglich ist, dass die Information ohne den dazugehörigen Schlüssel hergeleitet werden kann. Weiterhin darf, bei Benutzung einer asymetrischen Verschlüsselung, aus dem Chiffrierschlüssel (öffentlicher Schlüssel) nicht der Dechiffrierschlüssel (privater Schlüssel) berechnet werden können.

wahrscheinlich sicher

Eine verschlüsselte Information ist dann wahrscheinlich sicher, wenn sie weniger Wert besitzt als für deren Entschlüsselung an Geld aufgebracht werden muss (Kosten-Nutzen-Verhältnis). Außerdem ist sie auch dann wahrscheinlich sicher, wenn die Zeit, in der sie sicher sein muss, geringer ist als die für die Entschlüsselung benötigte Zeit.

Die Unterscheidung von Würmer, Viren und Trojanern

Malware kann nach Programmart, Codeausführung, Verbreitung und Verbreitungsmechanismus unterschieden werden:

 Wie schütze ich mich gegen Würmer, Viren und Trojaner

Um sich gegen Trojaner zu schützen, sollte man Passwörter nicht auf der Festplatte oder wenn dann nur mit sicherer Verschlüsselung abspeichern. Man sollte weiterhin nur Software verwenden, deren digitalen Fingerabdruck (Hash-Wert, z.B. MD5, SHA-1) man erfolgreich mit der Signatur des Herstellers verglichen hat. Zudem sollte man die Rechte auf Dateien, Programme und Dienste beschränken (Prinzip der minimalen Rechte).

Bei Würmern hilft es, das System technisch über Updates auf dem neuesten Stand zu halten. Weiterhin muss der Zugriff auf Programme, Daten und Dienste beschränken (Prinzip der minimalen Rechte). Insbesondere ist es sehr effektiv, wenn man im E-Mail-Client den Zugriff auf bestimmte Dateitypen (insbes. EXE- oder VBS-Dateien) unterbindet.

Bei Viren gibt es eine Vielzahl von Gegenmaßnahmen:

• digitaler Fingerabdruck der Originaldatei prüfen
• Dateien und Programme impfen
• Dateien und Programme verschlüsseln
• nicht veränderbare Medien verwenden
• Prinzip der minimalen Rechte
• Ausführung von Makros verbieten

Als wirksamste Gegenmaßnahme bei allen sollte jedoch der Umstieg auf Linux genannt werden. Dieser verhindert aufgrund seiner Systemarchitektur und dem Rechte- und Rollenkonzept die Gefahr der Infektion mit Malware erheblich.

 
Die Kostenplanung basiert auf der Größen- und Aufwandsschätzung, wenn ausschließlich Personalkosten im Projekt anfallen. Dieser Fall wird aus Vereinfachungsgründen angenommen. Anderenfalls würden noch die Kosten für Lizenzen (Entwicklungsumgebung, GoogleDocs, Webspace, URL) und die Infrastruktur (Server und Datenbank) wurden dazukommen. Die Kosten der jeweiligen Aufgabenpakete wurden mit

“Personalkosten = Arbeitspaketkosten = Aufwand in Stunden * Stundensatz * Produktivitätsanteil”

berechnet. Der “Aufwand in Stunden” kann der Größen- und Aufwandsschätzung entnommen werden. Um einen wahrscheinlichen Aufwand zu verwenden wurde die PERT-Methode genutzt. Der Aufwand für jedes beteiligte Teammitglied, wurde aufsummiert. Somit entfällt bei der weiteren Berechnung die Multiplikation mit der Anzahl an Mitarbeiter. Dieses Vorgehen ist möglich, weil ein durchschnittlicher Stundensatz für alle Teammitglieder ermittelt und verwendet wird (s.u.).

“Aufwand=  (minimaler Aufwand + maximaler Aufwand + realistischer Aufwand * 4) / 6”

Der Stundensatz wurde einer im August 2012 durchgeführten Studie von GULP entnommen. Veröffentlicht wurde diese Studie auf www.gulp.de und www.heise.de. Um der rollenungebundenen Aufgabenerledigung, insbesondere bei Planungsaufgaben im Rahmen der Teilleistungen, Rechnung zu tragen, wurde ein einheitlicher Stundensatz für alle Teammitglieder ermittelt. Dieser wurde wie folgt ermittelt:

“[Projektleitung (78 €) + Software-Entwickler (66 €) * 2 + Qualitätssicherungsexperte (66 €) * 2 + Analytiker (66 € analog zu Entwicklern) ] / 6 = Stundensatz (68 €)”

Der Produktivanteil wurde für einen Arbeitstag á 8,5 Bruttoarbeitsstunden berechnet.  Als Nettoarbeitsstunden wurden ~6,67 Stunden (=8,5 Std * 60 – 30min – 10min * 8 Std) geschätzt. Dabei wurden 30 Minuten Mittagspause, sowie 10 Minuten “Kreativpause” pro Stunde einbezogen. Die “Kreativpausen” wurden in Anlehnung an die Bildschirmarbeitsverordnung geschätzt, nach der ein Mitarbeiter nach 50 Minuten ununterbrochener Tätigkeit am Bildschirm 10 Minuten Pause machen muss.

“(8,5 Std * 60 – 30 min – 10 min * 8 Std) / 8,5 Std * 60 = Produktivanteil (78%)”

Für ein beliebiges Aufgabenpaket wurden nach PERT ein Aufwand von 10 Stunden geschätzt. Die Personalkosten würden sich wie folgt berechnen

“10 Stunden * 68 €/Stunde * 78% = 530,40 €”

 
Zur Überwachung der Risiken sind die erfassten Indikatoren maßgebend. Wie bereits erwähnt ist für eine aktive Risikoüberwachung der Risikomanager verantwortlich. Um seiner Tätigkeit einen Rahmen zu geben, werden regelmäßige Meetings dafür verwendet. Hier ist es seine Aufgabe, entsprechende Informationen über den Projektverlauf, Verzögerungen oder Probleme einzuholen. Auf Basis dieser Informationen sind potentielle Risikoindikatoren zu erkennen (z.B. Verzögerungen bei der Fertigstellung von Aufgabenpaketen). Daraus wird wöchentlich eine aktuelle Risikomatrix mit Tendenzen erstellt. So treten einige Risiken nur in bestimmten Projektphasen auf oder verschärfen sich im Projektverlauf (z.B. steigende Anzahl an Dokumenten lässt die Gefahr der Unübersichtlichkeit steigen). Eine beispielhafte Darstellung ist folgendem Bild zu entnehmen:

Überwachung von Risiken mit der Risikomatrix

Ergreifen und Validieren von Maßnahmen

Wird ein Risiko erkannt – egal ob vom Risikomanager oder von einem Teammitglied-, wird dies sofort kommuniziert. Dann müssen entsprechende Gegenmaßnahmen, soweit diese bekannt sind, angewendet werden. Solch ein Risiko befindet sich ab diesem Zeitpunkt im besonderen Fokus des Teams, die Wirksamkeit der Maßnahmen wird zeitnah validiert und der aktuelle Bearbeitungsstand wird kommuniziert.

Überwachung des Risikofeldes

Neben der Fokussierung der initial erfassten Risiken soll von jedem Teammitglied das Auftreten neuer Risiken sofort angesprochen werden. Erster Ansprechpartner ist hierfür der Risikomanager, da er den Überblick über alle dokumentierten und gemeldeten Risiken hat. Ein neues Risiko kann dann entsprechend klassifiziert und analysiert werden, um im weiteren Projektverlauf damit umgehen zu können. Die aktuelle Risikoliste und -matrix wird allen Teammitgliedern kommuniziert.

Quelle: Projekt des Autors mit Stefan Kleih, Michael Ruhnau, Matthias Köhler, Kim Jansen

 
Um mit den bisher erkannten Risiken umgehen zu können legte das Projektteam im nächsten Schritt eine Risikostrategie fest. Diese Strategie orientiert sich an den bisher identifizierten Gefahren und deren Einordnung in Bezug auf die drei genannten Eigenschaften. Hierfür wurde zur Visualisierung eine Risikomatrix erstellt, welche diese Einordnung transparent darstellen soll. Ziel ist es, die Gefahren des Projektes auf einen Blick einschätzen und auf dieser Basis eine Strategieentscheidung treffen zu können. Also ob es sich beispielsweise um ein Hochrisiko-Projekt handelt oder eher um ein Projekt, welches mit wenigen Risiken verbunden ist.
Zur Abbildung werden die Größen der Eintrittswahrscheinlichkeit auf der Y-Achse und die Schadenshöhe auf der X-Achse dargestellt. Die einzelnen Risiken werden mit ihrer Nummer als Kreise in die Risikomatrix eingetragen. Die Entdeckungswahrscheinlichkeit wird dabei durch die Größe des jeweiligen Kreises gekennzeichnet.

Legende für Risikomatrix

Risikostrategie

Die Risikomatrix wird in die nachfolgenden drei Bereiche gegliedert. Für jeden Bereich sind entsprechende Handlungsanweisungen definiert.

unkritische Risiken (grün)

Risiken in diesem Bereich sind relativ unkritisch und gefährden das Projekt nicht. Für diese Risiken werden Indikatoren und Gegenmaßnahmen erfasst. Ein Eingreifen erfolgt jedoch erst bei Auftreten des Problems.

kritische Risiken (gelb)

Für solche Risiken müssen geeignete Indikatoren und Gegenmaßnahmen erfasst werden. Abhängig von der Entdeckungswahrscheinlichkeit sind entsprechende Gegenmaßnahmen frühzeitig zu ergreifen. Denn eine Gefahr die zur Projektdurchführung kaum zu entdecken ist, sich aber in diesem Bereich befindet, gefährdet den Projekterfolg. Dieser Bereich wird zur Projektlaufzeit kontinuierlich beobachtet und durch entsprechende Kommunikation und Nachfragen durch den Risikomanager fokussiert.

hochkritische Risiken (rot)

Risiken im hochkritischen Bereich müssen unbedingt vermieden werden. Hierfür wird vom Projektteam eine weitere detaillierte Analyse durchgeführt um Indikatoren und Gegenmaßnahmen zu identifizieren. Kann ein Risiko gesenkt werden, sind entsprechende Maßnahmen möglichst sofort zu ergreifen. Da bei Eintreten einer solchen Gefahr das Projekt ohne schnelle und wirksame Gegenmaßnahmen kaum erfolgreich beendet werden kann.
Aus den bisher geschilderten Risikoeigenschaften, der Risikoliste und der Differenzierung der Risikoprioritäten, lässt sich folgende Risikomatrix ableiten:

Beispiel Risikomatrix

Diese Matrix stellt die Einschätzung aller Teammitglieder im Planungszeitraum des Projektes dar. Daraus geht hervor, dass es sich um ein Projekt mit wenigen hochkritischen Risiken handelt. Aber doch einige kritische Gefahren vorhanden sind. Der Großteil dieser liegt in der Abstimmung, Koordination und Kommunikation des Teams und kann durch geeignete Maßnahmen (regelmäßiges Jour fixe, Dokument-Repository) reduziert werden.

Gegenmaßnahmen und Indikatoren

Bereits bei der Erfassung und Analyse wurden potentielle Gegenmaßnahmen erfasst. Ziel der Risikosteuerung ist die Anwendung dieser Maßnahmen. Um das Auftreten von verschiedenen Risiken erkennen zu können, wurden jedem Risiko entsprechende Risikoindikatoren zugeordnet. An dieser Stelle ist zu definieren, wer für die Überwachung der Risiken verantwortlich ist und wie dies organisatorisch erfolgen soll. In einem kleinen Projekt bietet es sich an, dass die Rolle des Risikomanagers vom Projektleiter übernommen wird. Da dieser den Gesamtüberblick über die einzelnen Aufgabenpakete und den Bearbeitungsstand hat (Entwicklung, Anforderungsmanagement und Test) und auch für eine strukturierte Kommunikation zuständig ist.

Neben dem Risikomanager ist jedes Teammitglied dazu aufgerufen, das Erkennen von Risikoindikatoren dem Risikomanager und dem Team zu kommunizieren (z.B. eigene Unklarheit über die nächsten Aufgaben, technische Schwierigkeiten bei der Implementierung). Nur so können frühzeitig Gegenmaßnahmen eingeleitet werden. Das Bewusstsein für die erkannten Projektrisiken wurde bereits durch den gemeinsamen Erfassungsprozess der Risikoliste geschaffen.

Quelle: Projekt des Autors mit Stefan Kleih, Michael Ruhnau, Matthias Köhler, Kim Jansen

Quelle: Projekt des Autors mit Stefan Kleih, Michael Ruhnau, Matthias Köhler, Kim Jansen

 
Es wird das Verfahren der semiquantitative Analyse verwendet, mit dessen Hilfe eine formale Klassifizierung der Schadenshöhe und Eintrittswahrscheinlichkeit definiert werden soll. Dies hat zum Ziel, dass Projektrisiken vergleichbar sind und eine Priorisierung erfolgen kann. Hierzu wurden zunächst Skalierungen für die Eigenschaften der Schadenshöhe, der Eintrittswahrscheinlichkeit sowie der Wahrscheinlichkeit der Entdeckung des Problems definiert. Dabei wurde für alle drei Kategorien eine Skala von 1 – 4 gewählt.

Eintrittswahrscheinlichkeit

Tabelle 1 – Eintrittswahrscheinlichkeiten

Wahrscheinlichkeit, dass das Risiko unentdeckt bleibt

Tabelle 2 – Entdeckungswahrscheinlichkeiten

Schadenshöhe

Für die Definition der Schadenshöhe wurde eine Differenzierung zwischen technischen Schäden und Problemen im Projektverlauf durchgeführt. Für Schäden in Bezug auf die Anwendung dienen die Kernfunktionen des Systems als Grundlage für die Bestimmung der Schadenshöhe, die als Use-Cases definiert wurden.

Abhängig von der Ausführbarkeit dieser Funktionen wird der Schaden in Bezug auf die Anwendung klassifiziert.
Für andere Probleme im Projektverlauf (z.B. Abstimmungsschwierigkeiten) wurde die Komponente Zeit als zu betrachtender Faktor gewählt. Da das fiktive Projekt einen engen zeitlichen Rahmen hat, bei dem eine weitere Bearbeitung des Themas nicht stattfinden wird, wurden entsprechend geringe Abweichungen (zum Beispiel bis 5% Abweichung bei Überschreitung der Projektdauer = Schadensstufe 2) gewählt.

Tabelle 3 – Bestimmung der Schadenshöhe

Risikoprioritätszahl

Auf Grundlage dieser drei Faktoren wird die Risikoprioritätszahl (RPZ) berechnet.

RPZ = Schadenshöhe x Eintrittswahrscheinlichkeit x Entdeckungswahrscheinlichkeit

Eine Risikoprioritätszahl welche größer als 10 ist wird durch die zuvor definierten Skalen als besonders kritisch betrachtet. Für Risiken mit einer entsprechenden Prioritätszahl müssen geeignete Gegenmaßnahmen definiert werden und eine ständige Überwachung und Kontrolle erfolgen. Auf diesen Aspekt wird im Bereich der Risikosteuerung und -überwachung näher eingegangen.

Auf Grundlage der erfassten Risiken aus dem Schritt Identifizierung konnte eine detaillierte Erweiterung der Risikoliste um die genannten Eigenschaften erfolgen. Dieser Prozess erfolgte wieder in zwei Phasen. Zuerst schätzte jedes Teammitglied die Schadenshöhe, Eintritts- und Entdeckungswahrscheinlichkeit unabhängig. Außerdem werden an dieser Stelle schon potentielle Gegenmaßnahmen sowie Indikatoren für die Erkennung des Risikos erfasst. In einer anschließenden Sitzung wird über die Risiken diskutiert, bei denen sehr große Abweichungen der Einschätzungen bestanden.

Ergebnis dieses Prozesses ist eine  detaillierte Risikoliste.

Wie bereits beschrieben, erfolgte die Erfassung der Risiken sowie deren Eigenschaftsbestimmung in einem mehrstufigen Verfahren. An dieser Stelle sollen nun beispielhaft einige Risiken genannt und die Begründung für deren Eigenschaftsdefinition erfolgen. Generell lässt sich jedoch festhalten, dass alle Schätzwerte auf den Erfahrungen der Teammitglieder beruhen, die diese durch Ihre jeweilige berufliche Erfahrung bereits unter Beweis gestellt haben.

Nr. 1  - “Liste der möglichen Risiken für das Projekt ist unvollständig”:

Als eines der ersten Risiken wurde die Gefahr der Unvollständigkeit der Risikoliste identifiziert. Das Projektteam war sich dessen schnell bewusst, da nichts den Erfolg eines Projektes so gefährden kann, wie ein plötzlich auftauchendes Risiko, für das im Vorfeld keine Gegenmaßnahmen definiert wurden.

Vor diesem Hintergrund wurde diese Gefahr mit einem relativ hohen Schadenswert (Wert = 3) bewertet. Denn sollte solch eine Gefahr auftauchen werden Kapazitäten für deren Analyse und die Einleitung von Gegenmaßnahmen gebunden sein. Dies kann den Zeitplan verschieben und im schlimmsten Fall ein Projekt scheitern lassen.
Das solch ein Fall eintritt, ist nach Erfahrungen des Projektteams nicht ganz unwahrscheinlich. Da es sich bei diesem Projekt aber um eine relativ abgeschlossene und überschaubare Aufgabe handelt, wird davon ausgegangen, dass dieser Fall eher nicht eintreten wird (Wert = 2).

Ähnlich verhält es sich mit der Entdeckungswahrscheinlichkeit. Sollten Risiken im Umfeld der Anwendung (z.B. Serverabschaltung durch Wartung etc.) auftreten, wird dies relativ schnell auffallen. Anders verhält es sich mit Risiken auf organisatorischer Ebene (zeitliche Verzögerungen, unklare Anforderungen). Diese Probleme sollten aber durch regelmäßige Telefonkonferenzen eher auffallen. Zusammenfassend wurde deshalb ein ähnlich geringer Wert für die Entdeckungswahrscheinlichkeit vergeben (Wert = 2)

Quelle: Projekt des Autors mit Stefan Kleih, Michael Ruhnau, Matthias Köhler, Kim Jansen

sponsored by smartwebapps.de
 

1. Gründe für Zertifizierung

Im Folgenden benenne ich die Gründe, warum es sich lohnt, eine Zertifizierung zum Softwaretester nach ISTQB-Standard (ISTQB Certified Tester) zu machen:

1. standardisierte Qualifikation zum professionellen Softwaretester
2. international anerkannte Zertifizierung im Bereich Softwaretest
3. Qualitätsmerkmal für ein Softwareunternehmen, um sich von der Konkurrenz abzugrenzen
4. umfangreiches Wissen zu Testplanung, Testmanagement, Testentwurfsverfahren und Testwerkzeugen
5. Einführung eines einheitlichen Vokabulars, um sich effizient und schnell mit anderen ISTQB Certified Testern zu verständigen
6. Einführung einer einheitlichen Testmethodik im Unternehmen
7. neue Konzepte beim Softwaretest im Unternehmen für eine kontinuierliche Verbesserung (Stichwort: PDCA)

2. Prüfungstraining

Je nach Lerntypus gibt es zwei verschiedene Arten, wie man sich auf die 60 Minuten dauernde schriftliche Multiple-Choice-Prüfung vorbereiten kann.

2.1 Teilnahme an Vorbereitungskursen

Hier gibt es einige Prüfungsanbieter, die ihren Vorbereitungskurs nach ISTQB zertifizieren haben lassen. Sie dauern ca. 4 Tage, wobei der letzte halbe Tag für das Ablegen der Prüfung reserviert ist.

2.2 Selbststudium

Beim Selbststudium kommen verschiedene Methoden zur Anwendung, um das Wissen auch immer wieder zu prüfen.

Studium entsprechender Literatur

siehe Kapitel “benötigte Literatur”

Training mit Multiple-Choice-Fragen

Hier gibt es zum einen eine Musterprüfung vom German Testing-Board:

• zur Musterprüfung
• zur Lösung

Weiterhin existiert noch eine Lernplattform mit Fragen rund um die ISTQB-Thematik unter http://www.smartwebapps.de/, auf der man interaktiv mit Multiple-Choice-Fragen trainieren kann.

3. benötigte Literatur

Ich habe bereits in einem Blogeintrag gute Bücher zur Vorbereitung auf die verschiedenen ISTQB-Prüfungen erstellt: http://blog.milsystems.de/2012/07/wichtige-lektuere-zum-thema-istqb/

4. Prüfungstermine

4.1 Papierverfahren

Die Prüfung kann unter Prüfungsaufsicht unter Verwendung eines schriftlichen Prüfungsbogens zum Ankreuzen abgelegt werden.

 4.2 E-Exams

Alternativ zum Papierverfahren ist auch ein computergestützter Test an ausgewählten Prüfungsorten unter Aufsicht möglich.

Bei Rückfragen einfach einen Kommentar hinterlassen!

Einführung

Das Risikomanagement für das Projekt wird anhand des folgenden Schemas durchgeführt.

Kreislauf des Risikomanagements, Risikoidentifikation, Risikoanalyse, Risikosteuerung, Risikoüberwachung

Ziel ist es, durch einen kontinuierlichen Prozess der Risikoidentifikation, -analyse, -steuerung und -überwachung, die Gefahren für das Projekt zu verringern und damit zum Projekterfolgt beizutragen.

Risikoidentifikation

Zur Klassifikation von Risiken wurden vom Projektteam vor der eigentlichen Erfassung folgende Risikoklassifikationen definiert:

Tabelle 1 – Risikokategorisierung

Auf Basis dieser Klassifikationen erfolgt die initiale Identifikation von Risiken durch das Erstellen einer Risikoliste. Diese wird durch individuelles Brainstorming (Kreativitätstechniken) aller Teammitglieder erstellt. Durch diesen unabhängigen Prozess soll sichergestellt werden, dass möglichst alle Risiken erkannt werden und keine gegenseitige Beeinflussung stattfindet. Jedes Mitglied erfasst die aus seiner Sicht potentiellen Risiken, unabhängig vom eigenen Aufgabenbereich.  Diese Technik basiert auf den individuellen Erfahrungen und dem Wissen der Teammitglieder (Expertenbefragung). Sie soll es ermöglichen mit geringem Zeitaufwand ein gutes Ergebnis zu erzielen. Des Weiteren werden Risikolisten (Checklisten) aus ähnlichen Webprojekten zur Identifikation weiterer Gefahren herangezogen. Das Ergebnis dieses Prozesses dient als Grundlage für den nächsten Arbeitsschritt – der Risikoanalyse.

Quelle: Projekt des Autors mit Stefan Kleih, Michael Ruhnau, Matthias Köhler, Kim Jansen

 
Unter Berücksichtigung der in der Quellenangabe genannten Studien zu Trends im Bereich Maleware und der für die Monate November bis Januar erstellten Berichte zu Sicherheitsvorfällen haben sich für mich bei der Beurteilung der Sicherheitslage seit Kursbeginn folgende Themenbereiche herauskristallisiert: Zunahme von Mobiler Malware, Ransomware und militärisch bzw. politisch motivierte Cyberangriffe. Daneben werden auch andere Trends in den Studien genannt, auf die ich wegen fehlender von mir festgestellter Sicherheitsvorfälle nicht weiter eingehen werde.

Zum einen wird in den Studien von McAfee und F-Secure eine Zunahme von Mobiler Malware prognostiziert. Hierzu habe ich auch verschiedene Sicherheitsvorfälle in meinen Berichten festgestellt. Zum einen habe ich eine Trojaner-App für ein Mobiles Device beschrieben, mit der Geld erbeutet werden konnte. Weiterhin habe ich einen Fall aufgenommen, bei dem mit einem Online-Banking-Trojaner Schaden angerichtet worden ist. Hier ist die Infektion über eine JavaScript-Lücke im Webbrowser erfolgt, was zeigt, dass neben Apps auch vermehrt mobile Browser als Angriffsziel genutzt werden. Auch der Webservice von Google Docs wurde als Kommunikationskanal für einen Trojaner missbraucht. Jüngst wurde eine Lücke bei Facebook entdeckt, über die unbemerkte Webcam-Aufnahmen möglich waren, und welche so mittels entsprechender Malware das Mobile Devices zur Wanze umfunktionieren könnte. Auch auf Passwörter, die im Browser gespeichert sind, hat es Malware abgesehen (vgl. Trojaner klaut Passwortspeicher von Firefox und Co). Geschuldet ist diese Zunahme der steigenden Verbreitung von Smartphones und Tablet-PCs. Dabei ist gerade die hohe Verbreitung des Android-Betriebssystems interessant für die Ersteller von Maleware, da hier mit relativ wenig Aufwand eine große Zahl an Zielen angegriffen werden kann.

Eine Besonderheit an mobilen Geräten ist, dass hier der User fast seine ganzen Daten verwaltet (SMS, Telefonnummern, Bilder und andere Multimediainhalte, diverse Login-Daten). Auf dem PC oder Laptop gab es diese Konzentration von persönlichen Informationen bei der Vielzahl der Nutzer noch nicht. Diese Informationen sind aufgrund ihrer Wichtigkeit für den Nutzer interessant für Angreifer. Daher wurde in der Studie von McAfee eine Zunahme von sog. Ransomware im Bereich Mobiler Devices prognostiziert (diese Art Malware hat sich in der letzten Zeit allgemein verdreifacht). Bei dieser Art von Malware müssen die Nutzer Geld bezahlen, um ggf. wieder Zugriff auf die von der Malware verschlüsselten Daten zu erhalten. Diese Malware verursacht somit von der Schadenfunktion zunächst einmal einen permanenten Schaden, der ggf. bei Zahlung wieder entfällt.

Weiterhin spricht McAfee auch von Trojaner-Apps, die über einen Wurm verbreitet werden und ohne Zutun des Nutzers kostenpflichtige Apps kaufen und so den Kriminellen Geld einbringen. Auch die NFC-Technologie, mit der über das Mobile Device gezahlt werden kann (Stichwort „digitaler Geldbeutel“), soll in Zukunft genutzt werden, um Würmer auf eine neue Art zu übertragen (neue Kopplung von Systemen) bzw. um über diese Schnittstelle an Geld zu gelangen.

Weiterhin hat die Verbreitung der oben beschriebenen Ransomware zugenommen. Daran sieht man, dass es für die Ersteller von Malware im Vordergrund steht, dass diese selbst oder etwaige „Kunden“ damit Geld verdienen können. Das bloße Zerstören ist nicht mehr interessant.

Die mit Stuxnet und Flame begonnen militärisch und politisch motivierten Cyberangriffe haben im beobachteten Zeitraum weiter zugenommen. Es wurde der Trojaner miniFlame und ein Wurm, der SQL-Datenbanken im Iran angegriffen hat, in Monatsberichten beschrieben. Man sieht hier gut, dass bestimmte Staaten sich mit vielen finanziellen und personellen Ressourcen für einen Cyberkrieg rüsten und die dafür erforderlichen Waffen auch austesten. Durch das Themenfeld Cyberangriffe sind somit Staaten mit ihren Sicherheitsapparaten neben dem organisierten Verbrechen als neue Player im Bereich IT-Sicherheit aufgetreten.

Quelle:

• https://www.info-point-security.com/security-themen/malware-viren-spam-phishing/item/7586-f-secure-prognostiziert-malware-trends-2013.html, 05.01.2013
• http://www.mcafee.com/us/resources/reports/rp-threat-predictions-2013.pdf, 05.01.2013

Agile Softwareentwicklung

Agile Softwareentwicklung im Allgemeinen ist für unser Vorgehensmodell im Projekt nicht sinnvoll. Die Gründe dafür sind Folgende: Bedingt durch die abzuliefernden Teilleistungen steht in unserem Projekt die Dokumentation in der Wichtigkeit höher als die funktionierende Software. Dies bedeutet zwar nicht, dass die Software nicht funktionieren sollte, jedoch würde eine funktionierende Software ohne Abgabe der hier von der Priorität nicht so hoch eingestuften Planungsdokumente (PSP, PAP, Aufwandsschätzung, Kostenplanung, Risikoliste) mit dem geforderten Detaillierungsgrad zu einer schlechten Bewertung führen. Weiterhin ist zwar eine Rückkopplung mit der Auftraggeberin zwar ausdrücklich in unserem Projekt angestrebt, jedoch ist nicht zu erwarten, dass hier Änderungswünsche “on the fly” umgesetzt werden müssen. Zu guter Letzt streben wir an, zum Beginn der Softwareentwicklung ein stabiles Fachkonzept zu haben. Somit ist es nicht erforderlich, dass wir schnell auf Veränderungen reagieren müssen.

Extreme Programming

Um im Speziellen Extreme Programming auszuschließen wird angeführt, dass wir nicht anstreben viele Releases zu produzieren. Es ist somit kein „Planing-Game“ mit Zuordnung des „User-Stories“ zu einem Release erforderlich.

Scrum

Aufgrund der Projekttätigkeit neben der normalen Arbeit und der dadurch relativ kurzen Projektdauer, ist es nicht praktikabel alle 30 Tage (oder in einem kürzeren Rhytmus) Sprints durchzuführen. Auch ist es aufgrund der virtuellen Teams und der persönlichen Zeiteinteilung der Entwickler nicht möglich, tägliche Stand-Up-Meetings durchzuführen, daher kommt Scrum nicht in Frage.

V-Modell XT

Aufgrund unserer geringen Projektgröße mit sechs Personen ist das V-Modell XT nicht praktikabel. Es wäre hier erforderlich, dass eine Person gleichzeitig mehrere Rollen übernehmen müsste. Weiterhin ist es aufgrund der Projektgröße schwer von der Kapazität zu bewältigen, wenn wir alle im V-Modell XT zu erstellenden Dokumente (dokumentenorientierter Ansatz) erstellen müssen. Es wäre zu befürchten, dass aufgrund des Overheads am Ende keine lauffähige Software, die von der Auftraggeberin gefordert wird, herauskommt. Zudem haben bisher in unserem Team noch nicht alle Personen mit dem V-Modell XT gearbeitet. Dies würde also für einige eine tiefere Einarbeitung bedeuten, damit alle Prozesse richtig umgesetzt werden können.

Rational Unified Process

Beim Rational Unified Process spricht zum einen gegen den Einsatz, dass unser Team in diesem Vorgehensmodell nicht flächendeckend geschult ist. Unser Projekt ist jedoch auch nicht in der Zielgruppe des Vorgehensmodells, da es für eine industrielle Softwareentwicklung entwickelt wurde, welche in diesem Projekt jedoch nicht angestrebt wird.

Spiralmodell / Prototype

Das Spiralmodell ist iterativ und inkrementell, wobei mehrere Prototypen erstellt werden. In unserem Projekt wird es jedoch aufgrund des vollständigen Lastenhefts und des überschaubaren Projektumfangs keine Iterationen geben. Wir haben lediglich am Anfang einen Prototyp erstellt, der im Rahmen des Softwareentwicklungsprozesses zur fertigen Anwendung weiterentwickelt wird.

Entscheidung zwischen Wasserfallmodell und V-Modell

Wir haben nun alle Vorgehensmodelle bis auf zwei verbleibende ausgeschlossen, das Wasserfallmodell und das V-Modell. Um uns zwischen diesen zu entscheiden, haben wir die Argumente für das eine oder andere erörtert.

Argumente für das Wasserfallmodell

Für das Wasserfallmodell spricht, dass wir eine kurze Projektdauer haben und ein kleines Projektteam. Weiterhin sind vor Beginn des Entwicklungsprozesses alle Anforderungen bekannt und es ist nicht mit Änderungen im Fachkonzept zu rechnen. Auch die Risiken können wir sehr gut von Anfang an überblicken. Die Termine (Meilensteine) stehen wie die für die Teilleistungen zu erstellenden Dokumente von Anfang an fest. Wegen unserer nebenberuflichen Projektarbeit ist es für uns wichtig ein Einfaches uns überschaubares Vorgehensmodell zu haben, welches für unser kleines Team gut handhabbar ist.

Argumente für das V-Modell

Auf der anderen Seite spricht jedoch für das V-Modell, dass in Erweiterung zum Wasserfallmodell in diesem die Qualitätssicherung durch Verifikation und Validierung fest einbezogen wird. Gerade der Part Qualitätssicherung wird in unserem Projekt durch zwei Personen begleitet, womit dieser bei unserer kleinen Projektgröße ein relativ großes Gewicht hat. Wir werden mit Ausnahme der Entwicklung der Komponente “Karteikartenrückseite anzeigen” im Bereich Realisierung mehr das Web-CMS Drupal und die dort verwendeten PHP-Module konfigurieren. Somit sind keine umfangreichen Komponententests durchzuführen. Der geplante Komponententest der Komponente “Karteikartenrückseite anzeigen” verdeutlich jedoch unser Bestreben durch Validierung innerhalb des V die Qualitätssicherung zu berücksichtigen. Es ist auch ein kleiner Integrationstest der Komponente in das PHP-Template angedacht. Weiterhin macht die Realisierung einen ersten Systemtest, um eine abnahmefähige Software sicherzustellen. Der Abnahmetest wird dann durch das ganze Team in Verantwortung der zwei für Qualitätssicherung zuständigen Personen durchgeführt. Man sieht jedoch hier, dass durch die Betonung der Qualitätssicherung eher das V-Modell geeignet ist.
Auch bei der Dekomposition des Lastenhefts in einen fachlichen und technischen Systementwurf bzw. eine Komponentenspezifikation ist bei uns im Projekt geplant. Es ist vorgesehen im Projektverlauf aus dem Fachkonzept eine funktionalen Systementwurf und eine Komponentenspezifikation für die jQuery-Komponente zu erstellen. Da im Bereich des CMS vorhandener Code konfiguriert wird, wird auf das technische Design von Drupal verwiesen. Dieses Vorgehen würde auch für eine Anwendung des V-Modells sprechen. Weiterhin haben wir im Projekt ein Risikomanagement initiiert. Dies ist auch mit dem V-Modell möglich.

Unter Betrachtung aller Argumente für das Wasserfallmodell und das V-Modell haben wir uns im Team für das V-Modell entschieden.

siehe auch: http://www.elektronikpraxis.vogel.de

Beginn der Datenbank

Seit Januar 2012 ist die Datenbank mit kostenlosen Testsimulationen und Wissen zur Thematik rund um das Thema ISTQB nun unter der URL http://smartwebapps.de zu erreichen. Dieses bietet neben dem Studium entsprechender Lektüre zum ISTQB-Standard praktische Prüfungserfahrung. Am Anfang wurde das Projekt zur freien Verbreitung des Wissens zum ISTQB-Standard (Softwaretest) durch einen Schulungsanbieter torpediert. Daraufhin wurden alle Logos und Nennungen des Begriffs ISTQB entfernt. Seitdem ist ein reibungsloser Betrieb der Lernplattform möglich gewesen.

Zahlen und Statistik

• registrierte Nutzer: 2.084 (Stand 26. Januar 2013)
• Besucher im vergangenen Jahr 2012: 8.463 Stück
• Anstieg der Besucherzahl ab September 2012 auf ca. 1.000 im Monatsdurchschnitt
• Anzahl Fragen: 152 Stück
• Anzahl der durchgeführten Prüfungssimulationen: 5.405 Stück

Ausblick

Entwicklertätigkeit

Da ich das ISTQB-Projekt dauerhaft kostenlos betreiben will (das Webhosting ist auch nicht umsonst…) und ich die komplette Software in meiner Freizeit entwickle, schaut die Seite noch ein bisschen spartanisch aus. Das Projekt finanziert sich nur aus der Provision, die die per Amazon verkauften Bücher bringen, und diese decken gerade einmal die Kosten für diesen Weblog und die Lernplattform! Die Lernplattform ist jedoch voll funktionsfähig. Ich werde sobald es mein Terminkalender hergibt, ein komplettes und fertiges Design der Seite erstellen.

neue Fragen durch Nutzer erwünscht

Das Wachstum der Seite und der Fragen, hängt jedoch von den Nutzern ab, die neue Fragen erstellen und einreichen. Hier haben Sie bereits einige Nutzer als sehr aktiv gezeigt, denen ich ausdrücklich meinen Dank aussprechen möchte! Ohne euch wäre dieses Projekt nicht zu stemmen gewesen!

• ThomasG ( 43 Fragen)
• Stefan ( 23 Fragen)
• tlcopy ( 22 Fragen)
• testexperte ( 7 Fragen)
• n.graf ( 3 Fragen)
• karinqueste ( 3 Fragen)
• tommy1 ( 1 Fragen)
• showtime ( 1 Fragen)

Auf ein weiteres Jahr!

Grüße,

euer Stefan

 
Ich erstellte diesen Artikel aufgrund des Wunschs eines Besuchers dieses Weblogs: http://blog.milsystems.de/about/#comment-361

Grundlegende Informationen

Was ist ownCloud?

ownCloud ist eine Cloud-Computing Software-Suite, die einen ortsunabhängigen Speicherbereich für Daten zur Verfügung stellt. Sie basiert auf PHP und wahlweise SQLite, MySQL oder PostgreSQL-Datenbank. Damit lässt sich die Software wie bei einer Webanwendung üblich über einen Browser mit weltweitem Zugriff bedienen. Sie stellt damit eine freie und nicht-kommerzielle Alternative zu Dropbox und Google Drive dar, bei dem man immer Herr über seine Daten ist, sofern man den dazugehörigen Webserver betreibt bzw. einen seriöusen Webhostinganbieter wie all-inkl.com hat.

Weitere Infos zum Thema:

• Wikipedia: http://de.wikipedia.org/wiki/OwnCloud
• Dokumentation: http://doc.owncloud.org/
• https://www.dropbox.com/
• https://drive.google.com

Hilfe bei der Installation auf der Projektseite

http://doc.owncloud.org/server/4.5/admin_manual/installation.html#manual-installation

Doch hier sind die Feinheiten bei der Installtion beim Hosting Anbieter all-inkl.com nicht beschrieben.

Schritt-für-Schritt-Anleitung zur Installation von ownCloud

1. Schritt: Laden Sie die Software von http://owncloud.org/ herunter und prüfen Sie mit md5sum den Hash des Programmpakets auf Ihrem Rechner. Weitere Infos zum Prüfungen des md5-Hashes finden Sie bei Windows unter http://www.winmd5.com/ und bei Linux unter https://help.ubuntu.com/community/HowToMD5SUM.

2. Schritt: Laden Sie die Programmdatei mit WebFTP mit automatischem Entpacken auf Ihren Account bei all-inkl.com (weitere Infos in meinem Tutorial zu WebFTP)

3. Schritt: Richten Sie eine Domain oder Subdomain ein, die auf das Verzeichnis Ihres ownCloud-Verzeichnisses zeigt, das Sie zuvor hochgeladen haben (siehe hier mein Tutorial zum Erstellen von Domains und Subdomains)

4. Schritt: Bearbeiten Sie die .htaccess-Datei im obersten Verzeichnis und fügen Sie ihr folgende Zeile hinzu

#start all-inkl.com php 5.3 einschalten
AddHandler php53-cgi .php
#end all-inkl.com php 5.3 einschalten

5. Schritt: Geben Sie Verzeichnissen “config”, “lib” und “apps” und deren Inhalt die Rechte 755

6. Schritt: wenn Sie nicht SQLite benutzen wollen sondern eine mySQL-Datenbank, so legen Sie diese im KAS an (siehe hierzu mein Tutorial zu mySQL-Datenbanken bei all-inkl.com). Ich präferiere eine mySQL-Datenbank, da man die gut mit dem Tool mysqldumper sichern kann.

7. Schritt: Installieren Sie ownCloud mit dem Wizzard, indem Sie die unter Schritt 3 angelegte Domain oder Subdomain im Webbrowser starten. Dies wird in Folgendem Video gut erklärt.

In diesem Artikel beschreibe ich die drei Schätzschritte, die in Softwareentwicklungsprojekten gemacht werden sollten. Insbesondere auf die Größenschätzung wird oftmals verzichtet, was in der Folge Probleme mit sich bringt.

 

Größenschätzung

Insbesondere bei den Softwarekomponenten darf auf keinen Fall auf eine Größenschätzung verzichtet werden, da hieraus die zu erstellenden Dokumente und die Anzahl der Testfälle abgeleitet werden können. Grundlage für diese Schätzung sind folgende Parameter:

• LoC (Lines of Code)
• Anzahl der Masken, Module, Eingabefelder
• weitere Parameter wie Schwierigkeit der Programmierung, Komplexität und Risiko

Aufwandsschätzung

Auf Basis der Größenschätzung kann in einem weiteren Schritt der Aufwand geschätzt werden. Hier wird unter Zuhilfenahme einer der folgenden Schätzmethoden für jedes Arbeitspaket aus dem Projektstrukturplan (PSP) die Anzahl der Stunden oder Personentage geschätzt:

1. Analogieschätzung
   • Multiplikationsmethode
   • Prozentsatzmethode
2. Expertenschätzung
   • Delphi-Methode
   • informelle Schätzung
   • Drei-Punkt-Schätzung (PERT-Methode mit pessimistisch, real und optimistisch)
3. Parametrische Schätzverfahren
   • COCOMO
   • Function Point Methode

Kostenschätzung

Bei der Kostenschätzung müssen folgende Kosten berücksichtigt werden:

• Personalkosten = Personalstundensatz * Aufwand in Stunden * Produktivanteil
• Lizenzkosten
• Systemresourcen

1. Schritt

Laden Sie sich die 2 Debian Paketarchive herunter über die Seite http://de.software.canon-europe.com/ herunter:

• für Scanner: MX710 series ScanGear MP Ver. 1.90 for Linux (debian Packagearchive)
• für Drucker: MX710 series IJ Printer Driver Ver. 3.70 for Linux (debian Packagearchive)

2. Schritt

a) Installieren Sie den Druckertreiber für den Canon PIXMA MX715.

In der Kommandozeile des Linux Betriebssystems werden folgende Befehle eingegeben:

Treiber entpacken (man steht im Verzeichnis in dem die heruntergeladene Datei liegt):

tar zxvf cnijfilter-mx710series-3.70-1-deb.tar.gz

cd cnijfilter-mx710series-3.70-1-deb/packages

Common-Package installieren:

sudo dpkg -iG cnijfilter-common_3.70-1_i386.deb

Modellspezifisches Paket installieren:

sudo dpkg -iG cnijfilter-mx710series_3.70-1_i386.deb

b) Drucker einrichten

In der Kommandozeile wird folgender Befehl eingegeben:

sudo service cups restart

Im folgenden wird nur der Drucker entsprechend der unten stehenden Bilder in Linux Ubuntu eingerichtet (Bilder der Reihenfolge nach durchgehen).

3. Schritt

a) Installieren Sie den Treiber für den Scanner von Canon PIXMA MX715 (weitere Infos).

Treiber entpacken (man steht im Verzeichnis in dem die heruntergeladene Datei liegt):

tar zxvf scangearmp-mx710series-1.90-1-deb.tar.gz

cd scangearmp-mx710series-1.90-1-deb/packages

Common-Package installieren:

sudo dpkg -iG scangearmp-common_1.90-1_i386.deb

Modellspezifisches Paket installieren:

sudo dpkg -iG scangearmp-mx710series_1.90-1_i386.deb

b) Scanner starten

scangearmp

4. Schritt

Zu guter letzt wird noch Startmenüeintrag  im Linux Betriebssystems für den Scanner erstellt, um nicht immer das Scannprogramm über die Kommandozeile starten zu müssen.

Ich habe dazu den Editor für das Unity-Startmenü für Linux Ubuntu verwendet. Das weitere Vorgehen habe ich mit den unten stehenden Screenshots dokumentiert.

Bei Fragen einfach einen Kommentar hinterlassen!

Beschreibung: Es wurde ein Trojaner namensBackdoor.Makadocs durch die Firma Symantec entdeckt, welcher über entsprechend präparierte Word- und RTF-Dokumente verbreitet wird. Das Besondere an diesem ist, dass die Kommunikation mit dem Kontrollserver über Google Docs läuft, genauer gesagt über den Viewer von Google Docs, welcher Inhalte über URLs anzeigt und lädt. Die Kommunikationsverbindung wird über https verschlüsselt, wodurch das blockieren auf dem infizierten Rechner lokal nicht möglich ist, sondern nur durch Google erfolgen kann.

Einordnung: Es handelt sich hier um Malware in Form eines Trojaners, der das Schutzziel Vertraulichkeit beeinträchtigt.

Quelle:http://www.heise.de/security/meldung/Trojaner-benutzt-Google-Docs-als-Kommunikationskanal-1752075.html, 20.11.2012

Beschreibung: Es wurde ein Rootkit entdeckt, dass Webserver befällt, die auf dem Linux-Betriebssystem laufen. Dieses fügt allen Webseiten, die der Server ausliefert ein iFrame hinzu, welches eine speziell präparierte Webseite einbindet (Integrität). Über diese wird der Nutzer mittels eines eines Exploit-Kits angegriffen.

Einordnung: Das Rootkit ist kein Wurm, Virus oder Trojaner, sondern ist eine eigenständige Malware, die zur Tarnung von anderer Malware benutzt wird. Das Exploit-Kit enthält verschiedene Malware, die nicht genauer im Artikel erläutert wird (ggf. Wurm, Virus bzw. Trojaner).

Quelle:http://www.heise.de/security/meldung/Rootkit-befaellt-Linux-Webserver-1753721.html, 20.11.2012

Beschreibung: Bei ImageShack wurden alle als privat eingestuften Bilder gehackt (Vertraulichkeit). Zudem wurde der Kernel von VMwares ESX-Server eine Lücke in ZPanel (Open-Source-Hosting) und E-Mail-Adressen von Symantec-Mitarbeitern veröffentlicht.

Einordnung: Es handelt sich hierbei nicht um Malware, sondern um menschliche Handlungen mit schädigender Absicht mit Angriff auf die Vertraulichkeit und den Softwareschutz.

Quelle:http://www.heise.de/security/meldung/Anonymous-am-Werk-Symantec-ImageShack-und-VMWare-gehackt-1742980.html, 20.11.2012

Beschreibung: Cyber-Kriminelle nutzen die Einführung der SEPA-Überweisung durch entsprechend entwickelten Trojaner, der auf dem infizierten Rechner wartet, dass sich das Opfer zum Online-Banking anmeldet. Der Angriff erfolgt im Browser durch eingeschleustes JavaScript (Web-Injects), welches je abhängig vom Kontostand eine bestimmte Summe ins Ausland transferiert (Authentizität). Der Trojaner wird nur vereinzelt bei finanziell gut gestellten Opfern eingesetzt, was das Risiko des Entdeckt-werdens verringert.

Einordnung: Es handelt sich hierbei um einen Trojaner.

Quelle:http://www.heise.de/security/meldung/Profi-Banking-Trojaner-unterstuetzt-SEPA-Ueberweisungen-1754048.html, 20.11.2012

Ist-Zustand

Vor Einführung der qualifizierten Fehlanzeige erhält der Produktverantwortliche, der einen Review startet, im Regelfall von einem Prüfer nur dann eine Rückmeldung, wenn dieser Anmerkungen zum Produkt hat. Es ist nicht klar erkennbar, was der Grund dafür ist, wenn Prüfer bei einem Review keine E-Mail an den Produktverantwortlichen zurückschicken.

Folgende Gründe sind denkbar:

• Prüfer ist mit dem Produkt zufrieden und hat keine Anmerkungen
• Prüfer hat keine Zeit, da er seine Ressourcen für andere Aktivitäten benötigt
• Prüfer ist krank / im Urlaub und kann daher keine Anmerkungen abgeben
• Prüfer hat den Abgabetermin für das Review vergessen

Vorschlag einer qualifizierten Fehlanzeige

Gerade bei Produkten, die einen großen spezialisierten Teilnehmerkreis betreffen ist es wichtig, dass alle Betroffenen das Dokument (bzw. den sie betreffenden Teil) unter ihrem Blickwinkel geprüft haben. An einigen Produkten hängen weitreichende Projektentscheidungen. Es könnten aufwändige Änderungen verursacht werden, wenn Probleme erst im Nachhinein bekannt werden.

Um eine qualifizierte Aussage über die Qualität eines Produkts und damit über die Qualität im Projekt treffen zu können, ist es wichtig bei einem Audit zu prüfen, wie viele Prüfer ein Dokument tatsächlich geprüft haben.

Vorteile einer qualifizierten Fehlanzeige

• Produktverantwortliche sieht, wie viel Prozent des Prüferkreises sein Dokument tatsächlich prüfen konnte
• Produktverantwortliche kann bei wichtigen Prüfern ggf. nachfragen und das Review verlängern
• Personen, die ein Dokument freigeben bzw. mit diesem weiterarbeiten, können sich beim Produktverantwortlichen über dessen Belastbarkeit erkundigen
• Stabstelle QS kann bei einem Audit stichprobenweise Reviews prüfen und Anhaltspunkte für die Qualität im Projekt gewinnen
• Projektbeteiligte sind für die Bedeutung des Reviews von Produkten sensibilisiert

Nachteile, die entkräftet werden können

• Leistungskontrolle: die Qualifizierten Fehlanzeigen werden vom Produktverantwortlichen wie alle anderen E-Mails mit Anmerkungen dezentral gesammelt; eine Auswertung zur Leistungsüberwachung ist damit nicht möglich; es sollen nur stichprobenweise in einem QS-Audit ausgewählte Reviews geprüft werden
• Mehraufwand: die Archivierung einer E-Mail ist nicht aufwändig und sollte sowieso schon bei den E-Mails mit Anmerkungen zum Produkt erfolgen

Ausführung

Haben einzelne Prüfer keine Anmerkungen, ist eine begründete Fehlanzeige mittels E-Mail erforderlich. Die Gründe, aus denen eine Fehlanzeige erfolgt, können sein:

(1)   Geprüft, keine Beanstandungen

(2)   Prüfung innerhalb des vorgegebenen Zeitraums nicht möglich

(3)   Sonstiger Grund (z.B. abweisend, nicht verfügbar)

Bei allen genannten Gründen ausgenommen „Geprüft” ist darzulegen, welche Einschätzungen oder Umstände zu der Fehlanzeige geführt haben. Auf Basis dieser Informationen kann der Prozess der Dokumentenprüfung im Rahmen des Projekts optimiert werden.

Alle im Rahmen des Reviews erhaltenen E-Mails (mit Anmerkungen bzw. qualifizierte Fehlanzeige) werden durch den Produktverantwortlichen gesammelt und für etwaige Prüfungen dezentral vorgehalten.

Deckblatt

Das Dokument im V-Modell XT sollte ein Deckblatt haben, welches die folgenden Mindestangaben enthält:

• Projekt
• Teilprojekt
• Thema
• Version (aktuell)
• Status (aktuell)
• Seitenzahlen (aktuell)
• erstellt am
• erstellt von
• geprüft am (sofern eine Prüfung stattgefunden hat)
• geprüft von (sofern eine Prüfung stattgefunden hat)
• freigegeben am (sofern eine Freigabe stattgefunden hat)
• freigegeben von (sofern eine Freigabe stattgefunden hat)
• Ablageort (in welchem Repository liegt das Dokument)

Zweck des Dokuments

Dieser Teil enthält eine Kurzzusammenfassung, die einem Leser schnell einen Überblick über den Inhalt des Dokuments und seinen Zweck gibt (Management-Summary).

Versionsübersicht

Hier sollen keine Änderungen im Dokument dokumentiert werden. Diese gehören in das Änderungsverzeichnis. Aus Gründen der Praktikabilität kann auf diesen Bestandteil verzichtet werden.

Versionierung

Die Versionsführung für Dokumente erfolgt in Anlehnung an das Produktzustandsmodell. Versionsführung und -nummerierung folgen den nachstehend aufgeführten Regeln:

• Die Versionsnummer besteht aus mindestens zwei Stellen, die durch einen Punkt getrennt sind.

• Dokumente erhalten bei Ersterstellung mit Vorlage zur eigenständigen QS oder, wenn diese nicht erforderlich ist, mit dem Wechsel in den Produktzustand „fertig gestellt“ die Version 1.0

• Die Versionsnummer ändert sich, wenn ein Dokument in Bearbeitung genom¬men wird (der Produktzustand wechselt nach „in Bearbeitung“)

• Ist beim Wechsel in den Produktzustand „in Bearbeitung“ der vorherige Zustand „fertig gestellt“, dann wird die Vorpunktstelle der Versionsnummer fortlaufend erhöht (z.B. 2.0), die Nachpunktstelle wird auf Null gesetzt, weitere Stellen fallen weg.

• Ist beim Wechsel in den Produktzustand „in Bearbeitung“ der vorherige Zustand „vorgelegt“, dann wird die Nachpunktstelle der Versionsnummer fortlaufend erhöht (z.B. 1.2), die nachfolgenden Stellen fallen weg.

Prüfverzeichnis

Um die Prüfungen des Dokuments in verschiedenen Versionen nachvollziehbar zu machen, ist es wichtig, im Dokument auch ein Prüfverzeichnis gewissenhaft zu pflegen. Dies bedeutet, für jede Prüfung, ist ein entsprechender Eintrag anzulegen – gleichgültig ob es sich um eine Eigenprüfung oder um eine Prüfung durch eine eigenständige Qualitätssicherung handelt. In die Spalte „Anmerkungen“ sollte die verwendete Prüfmethode eingetragen werden. In der Spalte „Zustand“ ist der Produktzustand, der sich nach der Prüfung ergibt, einzutragen.

Verteiler

Hier sind zwingend alle Personen einzutragen, die das Dokument prüfen sollen. Der Personenkreis ist bei Bedarf zu erweitern.

Änderungsverzeichnis

Um die Erstellung des Dokuments nachvollziehbar zu machen, ist es wichtig, im Dokument ein Änderungsverzeichnis gewissenhaft zu pflegen.

Inhaltsverzeichnis

Jedes Dokument sollte zur besseren Übersicht ein Inhaltsverzeichnis haben, welches die aktuellen Seitenzahlen der Kapitel anzeigt.