Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Modul Projektplanung Literatur:

Ähnliche Präsentationen


Präsentation zum Thema: "Modul Projektplanung Literatur:"—  Präsentation transkript:

1 Modul Projektplanung Literatur:
Informationen finden sich in allen Büchern über Projektmanagement, Hier wurden insbesondere die folgenden Quellen benutzt: Walter Gruber, Arbeitsbuch Projektmanagement, WEKA 2003) Gerda Süß, Die wichtigsten Methoden im Projektmanagement, WEKA 2002 Capers Jones, „Software Quality - Analysis and Guidelines for Success“, International Thomson Computer Press 1997 Seminar Testmanagement, Dr. Klaus Röber

2 Motivation für Projektplanung

3 Projektplanung Die Projektplanung hat folgenden Zweck: - Systematische Informationsgewinnung über den zukünftigen Ablauf des Projekts - Schaffung einer Basis für realistische Sollvorgaben - Schaffung einer Basis für die Kontrolle des Projektfortschritts - Schaffung einer Basis für die Steuerung des Projekts Sie verläuft phasenorientiert iterativ und wird für jedes der ggf. im Projektauftrag definierten Teilprojekte separat durchgeführt Projektplan Phase 1 Phase 2 Phase n Phasenplan 1 Phasenplan 2 Phasenplan n Projektplan überarbeitet

4 Kernprozesse der Projektplanung
Projektstrukturierung Was ist alles zu tun? Meilensteinplanung Welches sind wichtige Ereignisse im Projektverlauf? Einsatzmittelbedarfsplanung Wie viel Arbeitsaufwand und welche sachlichen Einsatzmittel sind zur Erbringung von Arbeitsergebnissen notwendig? Terminplanung In welcher Reihenfolge und zu welchen Terminen müssen die Arbeitspakete abgearbeitet werden? Kostenplanung Wie viel Kosten verursachen die einzelnen Arbeitspakete? Planoptimierung Stimmt der bis dahin geplante Projektverlauf mit den Wünschen des Auftraggebers überein? Risikomanagementplanung Sind die Aktivitäten des Risikomanagements für das Projekt definiert? Integrationsmanagement Ergibt sich bei der Zusammenführung der Ergebnisse aller Planungsprozesse ein aufeinander abgestimmtes, schlüssiges Dokument?

5 Unterstützungsprozesse der Projektplanung
Risikoanalyse Was könnte mein Projekt gefährden und welche Maßnahmen kann ich dagegen treffen? Qualitätsplanung Sind die Qualitätsstandards definiert und ist geplant, wie sie eingehalten werden können? Kommunikationsplanung Ist festgelegt, wer welche Informationen wann und wie erhält? Die Kernprozesse sind in einer zeitlichen Abfolge zu sehen, die allerdings durch Schleifen infolge neuer Erkenntnisse, Anforderungen des Kunden u. Ä. zumeist mehrmals durchlaufen werden (denken Sie an das Teufelsquadrat!). Die Unterstützungsprozesse können dagegen nicht einzelnen Kernprozessen zugeordnet werden, sie sind prozessübergreifend.

6 Ergebnis der Planung: Der Projektplan
ist das zentrale Planungs- und Steuerungsinstrument des Projektmanagements für die konkrete Projektdurchführung. besteht aus einer Reihe von Einzelergebnissen, die nur in ihrer Gesamtheit alle Planungsaspekte eines Projektes widerspiegeln, z. B.: Aktivitäten/Arbeitspakete (Aufwand, Ressourcenzuordnung, Termine) Projekt-Meilensteine Ressourcenplan Teamorganisation Der Projektplan wird während des Projektverlaufs ( jeweils nach Genehmigung durch den Auftraggeber / Sponsor ) fortgeschrieben.

7 Zeit Einige Begriffe - Aufwand - Spanne - Punkt = Ressourcen-
verbrauch = Dauer = Termin Z.B. 2 MT (Menschtage) Z.B. 2 Arbeitstage Z.B 14.00 Uhr

8 Bestätigung der Projekt-Baselines
Eine Projekt-Baseline ist ein Element ( Eckwert ) der Planung, welches anschließend auch gemessen wird. Dazu gehören z.B. Umfang, Termine, Aufwand, Kosten, Ressourcen. Zwischen der Verabschiedung des Projektauftrags und dem Start der Detailplanung kann u.U. ein längerer Zeitraum liegen. Deshalb müssen diese, im Projektauftrag definierten, Baselines in dieser Aktivität überprüft werden, um sie gegenüber dem Management zu bestätigen oder sie bei gravierenden Veränderungen ggf. neu vom Management genehmigen zu lassen Arbeitsschritte: Überprüfen, ob die aktuelle Planung mit den gemeinsam vereinbarten Baselines übereinstimmt Eskalation gegenüber dem Auftraggeber/Sponsor (wenn erforderlich)

9 Phasenmodelle als Grundlage der Projektplanung
Phasenmodelle dienen der Zerlegung eines Projekts in seine einzelnen Lebensphasen Sie grenzen inhaltliche Abschnitte voneinander ab und setzen sie in einen zeitlichen Bezug zueinander Entscheidungen über den weiteren Projektverlauf werden häufig am Ende einer Phase getroffen Die Phaseneinteilung dient als Grundlage für Projektstruktur-, Ressourcen- und Kostenplanung Phasenmodelle werden meist aus Gründen der Anschaulichkeit graphisch dargestellt Allgemeine Phasenmodelle können an spezifische Projekterfordernisse angepasst werden Vgl. dazu Modul Vorgehensmodelle

10 Projektstruktur-Planung
Voraussetzung: - Lastenheft oder Pflichtenheft Zweck: - Projekt überschaubar machen - Teilprojekte bilden - Projekt abgrenzen - Vollständigkeit sicher stellen - Ressourcen und Ergebnisse planbar machen - Durchführung kontrollierbar machen Verfahren: - empirisch-induktiv (wenn Projekt schwer überschaubar) - systematisch-deduktiv (wenn Projektüberblick gegeben)

11 Empirisch-induktive Planung („Bottom-up“)
Den Bottom-up Ansatz wählt man dann, wenn kein Vorgehensmodell für das Projekt existiert und man sich über die Vorgehensweise noch im Unklaren ist. Im ersten Schritt werden alle Aktivitäten und/oder Teilziele ohne jegliche Ordnung aufgeschrieben. Hierbei handelt es sich um einen Kreativitätsprozess, bei dem auch Kreativitätstechniken wie z. B. Mind-Mapping oder Brainstorming sinnvoll eingesetzt werden können. Als Nächstes werden die so gefundenen Aktivitäten und/oder Teilziele nach Oberbegriffen geordnet, diese evtl noch einmal in einer übergeordneten Ebene zusammengefasst usw. So entsteht nach und nach eine Struktur, die im letzten Schritt nochmals von oben nach unten auf Vollständigkeit hin überprüft werden muss.

12 Systematisch-deduktive Planung
Diesen Ansatz wählt man, wenn man das Projekt gut überschaut und ein Vorgehensmodell vorhanden ist Auswahl eines Prozessmodells (Vorgehensmodells = Modell des Entwicklungsprozesses, z. B. das bekannte V-Modell) Editieren des Prozessmodells Zerlegung der Aufgaben des Prozessmodells in Vorgänge bzw. Teilaufgaben Gruppieren der Teilaufgaben in Arbeitspakete

13 Projektstruktur-Plan
Strukturelemente Aufgabe - Aufgaben - Teilaufgaben - Arbeitspakete (AP) Teil- - kann geschlossen an eine Aufgabe Org.-Einheit delegiert werden - beinhaltet ein als Zielgröße definiertes Ergebnis - Reihe der Arbeitspakete ergibt den Projektablaufplan Arbeits- - Summe der Arbeitspakete zeigt den paket Leistungsumfang eines Projekts

14 Merkmale eines Projektstruktur-Plans
Möglichkeiten der Strukturierung - objekt-, aufbau-, erzeugnisorientiert - funktionsorientiert - gemischt Möglichkeiten der Standardisierung - hierarchisch: Entwicklung Schubladenplan/Standardstrukturplan Maschine Aufgabe-Teilaufgabe-Arbeitspaket - zeitlich: Schalt- Gehäuse Steuerung Standard-Projektplan technik Arbeitspaket-Vorgänge Hard- Soft- ware ware Beispiel: objektorientierte Strukturierung

15 Beispiel: Projektstrukturplan (www.hms-hopf-management.de)

16 Beispiel: Projektstrukturplan (www.webagency.de)

17 Beispiel: Projektstrukturplan (www.albbw.de)

18 Beispiel: Formular zur Arbeitspaketbeschreibung
Quelle: Gruber

19 Übung zur Projektstrukturierung (1)
Ihre Aufgabe ist es, ein Projektmanagement-Tool einzuführen. Da dies kein Standardprojekt ist, für das es ein Vorgehensmodell gibt, wählen Sie die empirisch-induktive Methode. Arbeit im Team (3 – 5 Personen) Zeit 30 Minuten Präsentieren Sie anschließend das Ergebnis im Plenum

20 Musterlösung Quelle: Gruber

21 Übung zur Projektstrukturierung (2)
Situation in der Fallstudie: Sie befinden sich mit ihrem Projektteam in der Startsitzung zu Beginn der Teilphase „Spezifikation Sollkonzept“ für das Teilprojekt 1 „Entwicklung Auftragsabwicklung“ Machen Sie gemeinsam für diese Phase eine Aktivitätenplanung Vorschlag für die Vorgehensweise: Nehmen Sie die Liste der Endprodukte des Sollkonzepts und entscheiden Sie, ob Sie die „kann“ – Endprodukte brauchen oder nicht Überlegen Sie, welche Aktivitäten Sie durchführen müssen, um Endprodukt zu erstellen Zeit: 30 Minuten Präsentieren Sie anschließend das Ergebnis

22 Meilensteinplanung Meilensteine sind wichtige Ereignisse im Projektverlauf. Sie markieren den Abschluss oder Beginn von wichtigen Projektschritten. Sie ergeben sich aus der Projektstruktur, d. h. Zergliederung des Projektziels in Teilziele (s. Projektstrukturplan) Meilensteine sind Punkte, an denen eine Entscheidung über den weiteren Projektfortgang gefällt werden kann. In der Regel sollte beim Erreichen des Meilensteins eine Reviewsitzung (s. Qualitätsplanung) durchgeführt werden, in der die zum Meilenstein erreichten Arbeitsergebnisse überprüft und freigegeben werden. Meilensteine können so sog. Meilensteinplänen zusammen gefasst werden Diese geben einen schnellen Überblick über die wesentlichen Eckpunkte der Projektplanung und sind deshalb auch zur Information des Managements geeignet. Außerdem sind richtig definierte Meilensteine die Basis für ein effektives Controlling-Instrument, der Meilenstein-Trendanalyse (s. Steuerungsprozesse).

23 Wie werden Meilensteine definiert?
Zur Definition eines Meilensteins gehören: MS-Name MS-Verantwortlicher Termin für die Erbringung der MS-Ergebnisse festgelegte MS-Ergebnisse (z. B. Dokumente, Prototypen, Modelle, Programme) Quelle: Süß

24 Meilenstein-Plan: Beispiel

25 Einsatzmittelbedarfsplanung
In der Einsatzmittelbedarfsplanung wird ermittelt, welche physischen Einsatzmittel (die drei M: Mensch, Maschine, Material) in welcher Menge zur Abarbeitung der einzelnen Arbeitspakete benötigt werden. Dabei ist es hilfreich, sich zugleich die Frage nach den benötigten Qualifikationen und Sachmitteln zu stellen,: Sind sie vorhanden oder müssen sie beschafft werden? (z. B. Computer, Drucker, Büromöbel). Die Ermittlung des Einsatzmittelbedarfs ist die Grundlage für eine Kostenschätzung und –planung. Wichtigster und schwierigster Unterpunkt bei der Einsatzmittelbedarfsplanung ist die Aufwandsermittlung, da einer bestimmten Menge menschlicher Arbeit nicht immer ein eindeutiges Ergebnis zugeordnet werden kann. Methoden zur Aufwandschätzung haben wir im Modul „Aufwandschätzung“ betrachtet. Für die Detailplanung eignen sich insbesondere die Bottom-Up Methode bzw. die Expertenschätzung (s. Delphi Methode).

26 Erinnerung: Aufwandsschätzung
Als Aufwand bezeichnet man die mit einer Tätigkeit verbundene Arbeitsmenge Jede Schätzung basiert auf Erfahrungen Ziel des Einsatzes von Aufwandsschätzverfahren ist gemachte Erfahrungen zu sichern den Zugriff auf gesicherte Erfahrungen personenunabhängig zu ermöglichen Um eine realitätsnahe Schätzung zu erreichen, sollte man sich einer methodischen Unterstützung bedienen Methoden der Aufwandsschätzung als Mittel zur Projektkalkulation gewinnen immer mehr an Bedeutung, da hierauf alle Plandaten aufbauen Basis für die Aufwandsschätzung ist das zuvor entwickelte Ergebnis der Strukturierung Die Schätzung ist als Prozess zu begreifen. Es muss möglich sein, in Abhängigkeit vom Zeitfortschritt mehrere Schätzungen abzugeben

27 So geht man vor Basis für die Aufwandschätzung sind die Arbeitspakete aus dem Projektstrukturplan. Jedes Arbeitspaket wird für sich allein betrachtet: 1. Abschätzen der Arbeitsmenge (= Aufwand, Einheit z. B. Personentage [PT] oder –stunden [Ph]), die voraussichtlich notwendig sein wird, um das Ziel des Arbeitspakets zu erreichen. Da jede Schätzung einzig und allein auf Erfahrungen basiert, ist es zur Verbesserung der Aufwandschätzung notwendig, Erfahrungssicherung zu betreiben. Beim Schätzen des Aufwands für ein Arbeitspaket sollte unbedingt der zuständige Mitarbeiter mit eingebunden sein – der Projektleiter allein wird dies in der Regel nicht leisten können. Der geschätzte Aufwand sollte möglichst nach den einzelnen Ressourcen getrennt sein. Schätzen der Intensität, mit der eine Ressource diesen Aufwand erbringen kann (Personaleinsatz, Einheit entweder in % oder z. B. in [Ph/Tag]). Urlaube, Schulungen oder sonstige geplante Abwesenheiten von Ressourcen werden in diesem Stadium noch nicht berücksichtigt. Dies erfolgt im Rahmen der Planoptimierung. Aus den beiden Größen Aufwand und Personaleinsatz lässt sich ableiten, welcher Zeitbedarf (= Dauer, Einheit in Tagen [t], Wochen [w] oder Stunden [h]) für die Durchführung eines Arbeitspakets notwendig ist. Dauer = Aufwand/Personaleinsatz Hat man im ersten Schritt bereits die Aufwände für die einzelnen Ressourcen getrennt, ergibt sich je Ressource eine individuelle Arbeitsdauer. Die längste Bearbeitungsdauer ist die Gesamtdauer des Arbeitspakets.

28 Ein einfaches praktikables Verfahren
„Expertenschätzung in Konferenz“ Methode Jedes Mitglied schätzt zunächst für sich den Aufwand für jede der einzelnen Aktivitäten Dann werden die Schätzergebnisse miteinander verglichen und die Gruppe einigt sich auf einen gemeinsamen Wert. Es wird dabei empfohlen, die Diskussion mit den zentralen und wichtigen Aufgaben zu beginnen. Zum Schluss überprüft die Gruppe noch einmal, ob die gefundenen Schätzwerte für die einzelnen Aufgaben auch in Relation zueinander sinnvoll sind und gleicht sie gegen die Planvorgaben aus dem Projektauftrag ab.. Dieses Verfahren eignet sich sowohl für die Planung in sehr frühen Phasen als auch für die Detailplanung und auch für ungewöhnliche Projekte, wo wenig Vergleichszahlen vorliegen Es nutzt das Wissen aller Projektmitarbeiter, nicht nur das des Projektleiters. Und vor allem: alle Teammitglieder wissen durch die gemeinsame Diskussion, was mit der Aufgabenstellung gemeint ist und unter welchen Vorannahmen die Schätzung zustande gekommen ist. Deswegen wird auch die Gefahr von Missverständnissen deutlich verringert und die Mitarbeiter melden sich früher beim Projektleiter, wenn sie während der Arbeit merken, dass der Aufwand höher ausfällt aufgrund bisher nicht bekannter Umstände...

29 Beispiel zur Aufwandschätzung (Quelle: Süß)
AP-Nr. AP-Bezeichnung Bearbeiter Aufwand [PT] PE [%] Dauer [Tage] 1.1 Detailplanung Programminhalte Müller 5 50 11,5 Schmitt Meier 10 100 Huber 1.2 Erstellung Texte 5,75 15 17,25 1.3 Programmierung 20 23 Personentag ist ja bekanntlich nicht gleich Tag. Dies kann man mit einem Aufschlag von x% auf den Aufwand berücksichtigen: Dauer = (1 + x)*Aufwand/Personaleinsatz. Beispiels- Weise rechnet man oft mit 15% Aufschlag.

30 Übung: Aufwands- und Zeitbedarfsschätzung
Machen Sie jetzt für die eben erstellte Aktivitätenplanung (s. Übung 1 zur Projektstrukturierung) eine Aufwandsschätzung. Verwenden Sie dabei die Methode „Expertenschätzung in Konferenz“. Gehen Sie dabei von folgenden Verfügbarkeiten aus: Hr. Huber 50%, Hr. Klaus 80%, Fr. Schubert 100%, Fr. Seibert 100%, Hr. Stern 50%, Fr. Ansorge 100%. Als sog. „Verteilzeiten“, d. h. Zeiten, in denen der Mitarbeiter nicht für das Projekt arbeitet, sondern anderen Beschäftigungen nachgeht (Administration, Abteilungsbesprechungen, private Kommunikation etc.) setzen Sie 15% an. Bei der Berechnung wird auf halbe Tage gerundet. Zeit 30 Minuten

31 Aufwandschätzung Musterlösung
AP-Nr. Bezeichnung Mitarbeiter Aufwand [PT] PE [%] Dauer [Tage] Konzeption erstellen 1.1 Fachkonzept erstellen Hr. Huber 6 50 14 1.2 Berichte erstellen Hr. Klaus 10 80 14,5 1.3 Technikkonzept erstellen Fr. Schubert 12 100 Umsetzung und Test durchführen 2.1 Änderungen im Tool vornehmen 2.2 Anschließen an die Datenbank 11,5 2.3 Test durchführen Fr. Seibert 5 Pilotprojekte durchführen 3.1 Einführung in das Tool Hr. Stern 2 4,5 3.2 Support der Pilotprojekte 20 46 3.3 Abschlussbericht erstellen Inbetriebnahme durchführen 4.1 Änderungen lt. Pilotprojekt umsetzen 4.2 Anwenderschulung durchführen Fr. Ansorge 23 4.3 Installation 1 1,5

32 Die häufigsten Fehler bei der Aufwandschätzung
Erfahrungsgemäß fallen Aufwandschätzungen zu neuen Themen oder von Mitarbeitern, die nur selten bewusst Aufwände schätzen, eher zu niedrig als zu hoch aus. Viele Mitarbeiter trennen Aufwand und Dauer nicht scharf. Der Aufwand hängt jedoch vom zu erbringenden Arbeitsinhalt ab, die Dauer kann dagegen durch mehr oder weniger intensives Arbeiten an einem Arbeitspaket beeinflusst werden. Eine bewusste und systematische Erfahrungssicherung, Grundvoraussetzung für eine fundierte Aufwandschätzung, wird häufig aus Zeitmangel oder anderen Gründen nicht gemacht. Viele Angaben zum voraussichtlichen Aufwand werden unter dem Druck knapper Ressourcen und enger Terminpläne gemach – und sind deswegen von vornherein unrealistisch. Auch Projektmanagement und Qualitätsmanagement verursachen Aufwand. Dieser wird jedoch häufig nicht in die Planung einbezogen.

33 Initiieren von Beschaffungen
Diese Aktivität ist dann durchzuführen, wenn aufgrund des aktuellen Ressourcenbedarfs für das Projekt Beschaffungen von Sachmitteln oder Dienstleistungen erforderlich sind. In diese Aktivität ist der Sponsor eingebunden. Arbeitsschritte: Präzisieren Ressourcenbedarf Formulieren Beschaffungsanforderung (entspr. Unternehmensregeln) Initiieren Beschaffung ( über Einkauf ) Ergebnis: Beschaffungsanforderung (entsprechend Firmen-Standard)

34 Terminplanung Ziel der Terminplanung ist Vorgehen
Die logisch-zeitliche Abfolge der im Rahmen der Auftragsabwicklung von den internen und externen Stellen abzuarbeitenden Vorgänge festzulegen sowie die auftragsfremden Vorbedingungen einzubeziehen, die zwar nicht zum Auftragsumfang gehören, die aber Voraussetzungen für die Erbringung der eigenen Leistungen sind Vorgehen Um die logisch und sachlich erforderlichen Abhängigkeiten zu ermitteln, werden die zu erledigenden Arbeiten erfasst und ihre Beziehung zu vorhergehenden und nachfolgenden Aufgaben analysiert: - Welche Arbeitspakete können unabhängig voneinander durchgeführt werden? - Welche Arbeitspakete sind unmittelbare Voraussetzungen? - Welche Arbeitspakete können unmittelbar folgen? Die Abhängigkeiten können in einem Netzplan dargestellt werden oder, wenn die Verhältnisse einfach sind, in einem Balkendiagramm. Das Balkendiagramm eignet sich auch für die übersichtliche Darstellung der Termine.

35 Ablauf- und Terminplanung: Grafische Darstellung
Modul Netzplantechnik und Balkendiagramme

36 Planoptimierung Die bisher erstellte Planung berücksichtigt noch nicht das Umfeld des Projekts. So wurden bis jetzt weder die evtl. mit dem Auftraggeber vereinbarten Meilensteintermine eingearbeitet noch die Verfügbarkeit der Ressourcen berücksichtigt. In der Planoptimierung wird dies ganz systematisch nachgeholt. Die für eine Planoptimierung relevanten Größen können sich auf eine oder mehrere der drei wichtigsten Planungselemente beziehen: Ressourcen – z. B. durch die begrenzte Verfügbarkeit, Urlaub oder anderweitig geplante Abwesenheiten Termine – z. B. in Form von bereits mit dem Auftraggeber vereinbarten Meilenstein-Terminen, die in die Planung einzuarbeiten sind. Kosten – z. B. durch eine Liquiditätsplanung bei großen kapitalintensiven Projekten.

37 Planoptimierung nach Ressourcen – das Belastungsdiagramm
Hauptinteresse bei der Optimierung eines Projektplans wird i.d.R. die Auslastung der Ressourcen sein. Um diese mit in den Projektplan einzubinden, wird das sog. Belastungsdiagramm (auch Ressourcenhistogramm oder Ressourcengrafik genannt) angewendet. Es besteht aus zwei Grundelementen: der Ressourcenverfügbarkeit (in der Grafik auf der nächsten Folie gestrichelte Linie) und dem Ressourcenbedarf (in der Grafik farbige Flächen) Die Ressourcenverfügbarkeit bildet die voraussichtliche Kapazität ab, mit der die Ressource (also z. B. ein Mitarbeiter) für das Projekt zur Verfügung steht. Ist der MA im Urlaub, sinkt die Linie auf Null. Der Ressourcenbedarf ergibt sich aus der bisherigen Planung. Die Größe der farbigen Flächen spiegelt den geschätzten Aufwand wider, die zeitliche Lage ergibt sich aus der Netzplanrechnung. Die Gegenüberstellung von Verfügbarkeit und Bedarf gibt Auskunft darüber, ob die geplanten Aufwände in der dafür vorgesehenen Zeit erbracht werden können. Übersteigt der Bedarf die Verfügbarkeit (wie in der Grafik zu sehen), ist die Planung so nicht realisierbar. Sie muss nochmals überarbeitet werden. Prinzipiell gibt es dafür zwei Möglichkeiten: Termintreue Planung und Kapazitätstreue Planung

38 Belastungsdigramm Ressourcenverfügbarkeit Überlastung
Noch freie Kapazität 100% AP 3.2 AP 1.2 AP 2.1 AP 4.2 AP 3.1 AP 1.1 Zeit

39 Termintreue Planung: Ressourcenerhöhung
120% Noch freie Kapazität 100% AP 3.2 AP 1.2 AP 2.1 AP 4.2 AP 3.1 AP 1.1 Zeit

40 Ressourcenerhöhung Da die Termine als fest angesehen werden (eine Verschiebung darf nur innerhalb der errechneten Pufferzeiten durchgeführt werden), müssen die Ressourcen – zumindest zeitweise – erhöht werden. Dies kann z. B. geschehen durch: Umschichtung von Ressourcen innerhalb des Betriebes Inanspruchnahme von Fremdleistungen Neueinstellungen, Einkauf Vergabe an Fremdfirmen Mehrschichtbetrieb Überstunden

41 Kapazitätstreue Planung: Terminänderung
Ressourcenverfügbarkeit Noch freie Kapazität 100% AP 3.2 AP 1.2 AP 2.1 AP 4.2 AP 3.1 AP 1.1 Zeit

42 Und wenn beides nicht klappt?
Führen beide Planungsansätze nicht zum Ziele, nämlich das geforderte Ergebnis in der geforderten Zeit zu bringen, kann nur noch die Höhe des Aufwands, also das Arbeitsvolumen reduziert werden, z. B. durch Verminderung des Auftragsumfangs oder der Qualität. Beider kapazitätstreuen Planung bieten viele PM-Tools Algorithmen zur Optimierung der Ressourcenauslastung an, die auch projektübergreifend im sog. Multiprojekt-Modus (also für mehrere Projekte gleichzeitig) funktionieren. Je nach Programm sind die Ergebnisse dieser Optimierungsalgorithmen mehr oder weniger brauchbar. Achtung - Vorsicht ist geboten: Sichern Sie auf jeden Fall Ihren Planungsstand, bevor Sie auf den Button „optimieren“ drücken. Die Optimierungsrechnung hat immer nur Vorschlagscharakter – Sie müssen entscheiden, ob sie brauchbar ist oder nicht. Wenn Sie Ihre Daten nicht gesichert haben, können Sie nicht mehr zurück und verlieren unter Umständen viel Arbeit.

43 Planoptimierung nach Terminen
Ziel ist es, die bereits vereinbarten Termine in die Planung mit einzubeziehen, insbesondere Meilensteine, für die bereits ein Termin vereinbart wurde (z. B. Pilotversion ist fertig gestellt bis 15.7.). Prinzipiell bedeutet das manuelle Festlegen von Terminen immer ein Eingreifen in die Netzplanlogik – was eigentlich vermieden werden sollte, um dem Netzplanalgorithmus maximale Freiheit zu geben. Beispiel: Ein Meilenstein kann laut Netzplanrechnung frühestens am abgeschlossen sein. Laut Vereinbarung mit dem Auftraggeber muss der Meilenstein spätestens am erreicht sein. Fügt man diese Bedingung in den Netzplan ein (spätestes Ende des Meilensteins am 1.9.), erhalten alle Vorgänge, die im Pfad vor dem Meilenstein liegen, zwei Wochen Puffer. Sind diese zwei Wochen Puffer aufgebraucht (z. B. durch unvorhergesehene Verzögerungen), werden die Vorgänge kritisch.

44 Planoptimierung nach Kosten
Eine Optimierung des Plans nach Kostenanfall kommt meist nur in Spezialfällen bei sehr großen Projekten vor. Hier kann es durchaus von Bedeutung sein, bestimmte kostenintensive Arbeitspakete so spät wie möglich zu beginnen – schließlich sind evtl. hohe Finanzierungskosten zu übernehmen. Basis ist auch hier der Netzplan. Ähnlich wie bei der Optimierung der Ressourcen können die nicht kritischen Arbeitspakete nach hinten geschoben werden, um einen besseren Zahlungsverlauf zu erhalten. Zur Visualisierung wird z. B. eine Gegenüberstellung von geplanten Projektkosten und Zahlungseingang verwendet.

45 Integrierte Aufwands-, Termin- und Ressourcenplanung

46 Projektkostenplanung
In der Regel ist mit der offiziellen Erteilung eines Projektauftrags auch die Freigabe eines bestimmten Projektbudgets verbunden, z. B. dem Budget, das in der Projektvorstudie geschätzt und im Projektantrag beantragt wurde. Der Projektleiter ist dafür verantwortlich, im Rahmen dieses Projektbudgets die vereinbarten Projektziele zu erreichen. Um die Höhe des Projektbudgets zu verifizieren, ist eine Abschätzung der voraussichtlichen Projektkosten notwendig. Erst danach ist eine fundierte Aussage möglich, wie viel die Realisierung der Projektziele voraussichtlich kosten wird. Liegen die voraussichtlichen Projektkosten über dem Projektbudget, muss der Projektleiter dies sofort mit dem Auftraggeber abstimmen. Wird eine entsprechende Budgetkorrektur abgelehnt, sollte dies auch von Auftraggeberseite sachlich zu begründen sein. Stimmen Kostenplanung und Budget überein, so ist die Kostenplanung die Basis für eine kostenorientierte Projektsteuerung.

47 Wie plane ich die Projektkosten?
Basis für die Projektkostenplanung ist der Projektstrukturplan, der eine vollständige Aufstellung aller für die Erreichung des Projektziels notwendigen Arbeitspakete beinhaltet. Die Gesamtkosten des Projekts sind dann die Summe der Kosten aller Arbeitspakete. U. U. ist diesen Kosten noch ein Anteil hinzu zu rechnen, der bei der Planoptimierung durch Termin- oder Kapazitätsprobleme auftritt, wenn Ressourcen länger als geplant benötigt werden oder wenn zeitweilig Leerlauf eintritt. Zur Planung der Arbeitspaketkosten wird in erster Linie die Kostenartenrechnung angewandt. Dazu kann auf die Kostenarten des betrieblichen Rechnungswesens zurück gegriffen werden. Falls dies zu detailliert oder aus anderen Gründen ungeeignet ist, empfehlen sich folgende Kostenarten: Personalkosten (Aufwand der Ressourcen mal Kostensatz) Materialkosten (Verbrauchsmaterialien, die besorgt werden müssen, damit ein Arbeitspaket abgearbeitet werden kann) Gerätekosten (da Geräte meist über das Projektende hinaus Verwendung finden, sollte nur ein Anteil angerechnet werden) Sonstige Kosten (z. B. Reisekosten, Aufwendungen für Geschenke)

48 Beispiel: Formular Kostenplanung
Quelle: G. Süß, Die wichtigsten Methoden im Projektmanagement, WEKA Verlag 2002

49 Risikomanagementplanung
Die Planung des Risikomanagementprozesses soll sicher stellen, dass dieser dem Risiko und der strategischen Bedeutung des Projekts für as Unternehmen angemessen ist (vgl. Module Risikomanagement) . Der Risikomanagementplan beschreibt, wie die Identifikation, qualitative und quantitative Analyse, Maßnahmenplanung, Verfolgung und Kontrolle von Risiken strukturiert und über den gesamten Lebenszyklus des Projekts durchgeführt werden soll (PMBOK).

50 Risikomanagementplan
Der Risikomanagementplan kann Folgendes beinhalten: Methoden: Festlegung, welche Methoden, Werkzeuge und Datenquellen im konkreten Projekt zur Anwendung kommen. In unterschiedlichen Projektphasen können durchaus verschiedene Methoden angemessen sein. Rollen und Verantwortlichkeiten: Definition und Besetzung der Rollen für die Aktionen gemäß Risikomanagementplan Budget: Für das Risikomanagement muss ein Budgetrahmen genehmigt werden. Zeitplan: Legt fest, wie oft im Projektlebenszyklus der Risikomanagementprozess durchgeführt wird. Diese Festlegung sollte periodisch überprüft werden. Berechnung und Interpretation: Definition der Berechnungs- und Interpretationsmethoden, die bei den verschiedenen Typen von qualitativen und quantitativen Risiken zur Anwendung kommen. Die Vorab-Festlegung sichert die Konsistenz des Risikomanagements. Schwellenwerte: Festlegung akzeptabler Schwellenwerte, da diese i.d.R. bei verschiedenen Stakeholdern unterschiedlich sind. Berichtsformate: Beschreiben Inhalt und Format des Risikomaßnahmenplans. Wie werden die Ergebnisse des Risikomanagementprozesses dokumentiert, analysiert und an die Stakeholder kommuniziert.

51 Integrationsmanagement
Integrationsmanagement ist die Koordinierung der unterschiedlichen Elemente des Projekts. In der Projektplanungsphase wird durch das Integrationsmanagement der Projektplan generiert, der die Ergebnisse der verschiedenen Planungsprozesse zu einem schlüssigen und zusammenhängenden Dokument integriert, das die Projektausführung und –steuerung lenkt. Der Projektplan kann sowohl ein Dokument als auch eine aufeinander abgestimmte Dokumentensammlung sein. Der Projektplan dient: der Steuerung der Projektausführung der Dokumentation der Projektplanungsannahmen der Dokumentation der Planungsentscheidungen und der Alternativen der Erleichterung der Kommunikation der Festlegung von Inhalt, Umfang und Terminierung der Schlüsselreviews des Managements als Basisplan für die Messung der Projektleistung und der Projektsteuerung.

52 Inhalt des Projektplans
Die sinnvolle Strukturierung des Projektplans hängt u. a, von der Art und dem Umfang des konkreten Projekts ab. Üblicherweise beinhaltet er folgende Punkte: Projektauftrag Beschreibung des Projektmanagementansatzes oder der –strategie (meist im Unternehmen generell geregelt) Beschreibung des Inhalts und Umfangs des Projekts einschließlich der Projektliefergegenstände und der Projektziele Projektstrukturplan bis zur Ebene, au der die Steuerung stattfindet Kostenschätzung, geplante Anfangstermine und Verantwortungszuweisungen der Arbeitspakete Basispläne zur Fortschrittsmessung von Terminen und Kosten Meilensteine mit Terminen Schlüsselpersonal oder erforderliche Mitarbeiter Hauptrisiken mit Einschränkungen und Annahmen sowie die geplanten Maßnahmen Offene Punkte

53 Gliederung des Dokumentes Projektplan : Beispiel (Krafft Foods)

54 Risikoanalyse, -bewertung und Maßnahmenfestlegung
Aufgabe der Risikoanalyse ist es, Faktoren, die eine Gefahr für den Projekterfolg (die im Projektauftrag definierte Leistung in geplanter Zeit mit den geplanten Ressourcen im Rahmen des vorgegebenen Budgets zu erbringen) zu identifizieren, zu beschreiben, zu bewerten und entsprechende Gegenmaßnahmen vorzubereiten bzw. einzuleiten (vgl. Module über Risikomanagement). Zu unterscheiden sind: projektimmanente Risiken (Projektrisiken) – Risiken, die sich aus der Projektabwicklung, also aus dem Prozess heraus ergeben und produktimmanente Risiken (Produktrisiken) – Risiken, die sich aus dem zu erstellenden Produkt, also dem neuen Anwendungssystem oder der neuen Organisationsform ergeben. Zum Risikomanagement der Produktrisiken existieren je nach Produktart (technische Produkte, Software, Anlagenbau etc.) meist firmenspezifische Konzepte (z. B. FMEA, Testverfahren), die i.d.R. Bestandteil des Qualitätsmanagements sind.

55 Top Ten Risikoelemente - typische Maßnahmen (1)
Quelle: Helmut Balzert, Lehrbuch der Software-Technik, Bd. 1, Spektrum 1998

56 Top 10 Risikoelemente - typische Maßnahmen (2)
Quelle: Helmut Balzert, Lehrbuch der Software-Technik, Bd. 1, Spektrum 1998

57 Projektrisiken: Ergebnis-Beispiel
Dieses Ergebnis definiert die Risiken und alternative Maßnahmen zur Reduzierung der Auswirkungen der Risiken auf das Projekt oder auf einzelne Funktionen. Es wird während der Detailplanung oder bei kritischen Projekten bereits in der Vorbereitungsphase eines Projektes erstellt und bei Bedarf während des Projektverlaufs fortgeschrieben. Kategorie Beschreibung des Risikos Auswirkung Alternative Maßnahmen Empfehlung Termin Auftragserfassung kann nicht zeitgerecht ausgeliefert werden. Hoch Warten bis die Auftragserfassung implementiert werden kann 2 Funktionalität der reduzieren 3 Erstellen eines Bridge- Programms zum existierenden Auftrags- Erfassungssystem 1 Bedienung Das vorgesehene Personal kann nicht eingesetzt werden Mittel Beschaffen von qualifiziertem Personal Intensives Training für das unerfahrene Personal

58 Qualitätsmanagement im Projekt planen: Wirtschaftlichkeit

59 Prozess Qualitätsmanagement (nach dem V-Modell)

60 Produkte des Qualitätsmanagements
Der Qualitäts-Plan beinhaltet die übergeordnete QS- Planung für das gesamte Projekt Pro Phase eines Projektes und für jeden unterstützenden Prozess (PM, KM, QM ) gibt es jeweils einen Prüfplan. Jedem Prüfgegenstand ist eine Prüfspezifikation (Checkliste ) als Input zugeordnet. Als Ergebnis der Prüfung ist jedem Prüfgegenstand ein Prüfprotokoll zugeordnet (s. Projektcontrolling) Die Anzahl der Prüfspezifikationen und Prüfprotokolle ist von der Anzahl der Prüfgegenstände abhängig.

61 Qualitätsmanagement: Rollen und Verantwortungen

62 Qualitätsziele (Erinnerung)
Mit gutem Ziel gewinnt man viel. Quelle: Chaos - ein Teutsches durcheinander von unterschiedlichen Sachen, D. Andr. Sutor, Augsburg 1716

63 Ziele und Nicht-Ziele Ziele: liegen in der Zukunft
sind vorstellbar und realistisch das Erreichen kann gedanklich vorweggenommen werden das Erreichen ist nur durch aktives Handeln möglich werden bewusst angestrebt das Erreichen ist gewünscht die Entscheidung ist bewusst getroffen worden im Interesse des Erreichens werden Einschränkungen und Anstrengungen in Kauf genommen sie sind idealerweise messbar Nicht-Ziele was sowieso in der Zukunft eintreten wird was ohne Aktivität „erwartet“ werden kann Ereignisse, die zufällig eintreten können Ereignisse, die nicht gewünscht sind

64 Zielfestlegung – 2 Fragen
Habe ich das richtige Ziel definiert? (Frage nach der Richtigkeit und dem Nutzen der Erreichung des Ziels) Habe ich das Ziel richtig definiert? (Frage nach der Erreichbarkeit des Ziels)

65 Was ist Qualität? Der transzendente Ansatz
Garvins fünf Ansätze: Der transzendente Ansatz kompromisslose Standards und extrem hohe Anforderungen Der produktbezogene Ansatz Differenzen von Eigenschaften Der kundenbezogene Ansatz Jurans „fitness for use“ Der fertigungsbezogene Ansatz Crosby‘s conformance to requirements Der wertbezogene Ansatz „Value for money“ Quelle: D. A. Garvin: What does product quality really mean?, Sloan Management Review 1984

66 Was ist Qualität – Definition der ISO (Norm 8402)

67 Anwendung der ISO Norm auf Software-Qualität
Softwarequalität ist die Gesamtheit aller Merkmale und Eigenschaften, die ein Softwareprodukt haben muss, um sicherzu- stellen, dass es (beweisbar und messbar!) die vorgegebenen oder vorausgesetzten Anforderungen des Anwenders/Auftraggebers erfüllt die Anwender es so verwenden können, dass der von ihnen erwartete Nutzen auch realisiert wird keine nicht erwünschten Operationen ausführt.

68 Qualitätsmerkmale eines Softwareprodukts - Beispiel
In Anlehnung an ISO/IEC Es gibt diverse andere Ansätze, dies ist nur ein Beispiel. Benutzungsfreundlichkeit Dokumentation Funktionalität Integration Effizienz Portabilität Sicherheit Wartbarkeit Zuverlässigkeit

69 Eigenschaften von Qualitätssoftware
Qualität konzentriert sich auf folgende 6 Schlüsselfaktoren: geringe Fehlerrate im Einsatz, idealerweise nahezu 0 hohe Zuverlässigkeit, d. h. ohne Zusammenbrüche oder seltsame Ergebnisse zu laufen bei Untersuchungen der Anwenderzufriedenheit ist die Mehrzahl der Anwender sehr zufrieden eine Struktur, die die Auswirkungen von „bad fixes“ oder das Einbringen neuer Fehler bei der Reparatur minimiert effektive Anwenderunterstützung, wenn Probleme auftreten schnelle Reparatur bei Auftreten von Fehlern, insbesondere, wenn diese schwerwiegend sind Quelle: Capers Jones, Software Quality - Analysis and Guidelines For Success, Int. Thomson Computer Press, 1997,

70 Rahmenbedingungen: Das Teufelsquadrat
Qualität Funktions- umfang + + Teamleistung - - Zeit Kosten

71 Qualitätsplanung und -sicherung
„Qualität ist kein Ereignis; Qualität ist eine Gewohnheit“ – das wusste schon Aristoteles. Qualität lässt sich nicht hinterher in ein Produkt hinein prüfen, sondern sie muss von Anfang an eingebaut sein. Alles andere wird i.d.R. sehr teuer. Am besten ist es deshalb, wenn die Projektarbeit von vornherein im Rahmen eines Qualitätsmanagementsystems (QMS) stattfindet, das beispielsweise auf der internationalen Qualitätsnorm ISO 9000: 2000 aufgebaut ist. Wenn so gearbeitet wird, sind die Chancen größer, dass der Prüfer bei einem Qualitätsreview feststellt, dass alle Qualitätsanforderungen erfüllt sind und dass keine Beanstandungen vorliegen.

72 Die Qualität eines Produkts (wie z. B. eines Tongefäßes) hängt ab von:
Quellen der Qualität Die Qualität eines Produkts (wie z. B. eines Tongefäßes) hängt ab von: Der Qualität des Materials (dem Ton), Der Qualität der Werkzeuge (der Töpferscheibe), Der Qualität des Bearbeiters (des Töpfers) Der Qualität der Struktur (der Form des Gefäßes) und von Der Qualität des Zwecks (beabsichtigte Verwendung des Gefäßes) Für die Entwicklung eines Anwendungssystems bedeutet das: Die verwendete Hardware entspricht dem Ton. Das Vorgehensmodell und die Entwicklungswerkzeuge entsprechen der Töpferscheibe. Der Entwickler ent- spricht dem Töpfer. Aber Qualität verlangt auch eine gute Struktur und einen guten Zweck. Diese werden durch das QMS und die Qualitätsziele des Auftraggebers bereit gestellt.

73 Notwendigkeit qualitätssichernder Maßnahmen
Nicht einmal ein übernatürlich guter Mitarbeiter kann systematisch perfekte Qualität liefern, wenn die anderen Komponenten nicht stimmen. Der Einfluss eines Mitarbeiters auf die Qualität im Projekt ist immer begrenzt. Einflussnahme des Managements, unklare Projektziele, nicht optimales Projektmanagement, eine qualitätsunfreundliche Unternehmenskultur, nicht ausreichende Ressourcen oder nicht ausreichende Fachbereichsbeteiligung können zur Folge haben, dass ein Projekt trotz bester Absichten des Teams seine Qualitätsziele nicht erreichen kann. Deshalb sind qualitätssichernde Maßnahmen grundsätzlich erforderlich um dem Auftraggeber gegenüber den Nachweis erbringen zu können, dass die Qualitätsziele erreicht wurden um den Mitarbeitern zu helfen, ihre Arbeit auch in einer schwierigen Umgebung mit Erfolg durchführen zu können.

74 Qualitätssichernde Maßnahmen
Es gibt drei Arten von QS-Maßnahmen: Planerische und administrative Maßnahmen (vorbeugende Maßnahmen) z. B. Vorgaben von Kriterien und Rahmenbedingungen Konstruktive Maßnahmen (vorbeugende Maßnahmen) z. B. Gliederung des Entwicklungsprozesses durch Anwendung eines Entwicklungsstandards (Vorgehensmodell) Auswahl von Methoden und Werkzeugen zur Unterstützung des Entwicklungsprozesses Festlegung von Projektstandards und –richtlinien Training der Mitarbeiter in bestimmten für das Projekt relevanten Fähigkeiten Durchführung einer Risikoanalyse für das Projekt und Ableitung entsprechender Maßnahmen Analytische Maßnahmen (prüfende Maßnahmen) Reviews, Audits, Testen

75 Qualitätsplan – Inhalt (Beispiel Airbus)
1. Allgemeines zum Qualitätsplan Zielsetzung Reichweite Ergänzende Dokumente Das Projekt XYZ Projektziele Kritikalität Genereller Qualitätsanspruch an das Projekt Projektrisiken Qualitätsziele Konstruktive QS-Maßnahmen Analytische QS-Maßnahmen

76 Qualität bei Standardsoftware
Bei einer Standardlösung hat das Implementierungsteam nur einen begrenzten Einfluss auf die Qualität. Beispiel: Qualitätsziel: Keine Eingabemaske zeigt mehr als 10 Informationen an, damit die Übersichtlichkeit nicht leidet. Entweder sieht die Software dies bereits vor, dann ist das Ziel erreicht oder es gibt Eingabemasken , die mehr Informationen anzeigen. Da Eingriffe in Stan- dardsoftware meist mit erheblichen Kosten verbunden sind, ist ein solches Qualitätsziel nicht vernünftig, da es sich nicht auf wirtschaftliche Art und Weise erreichen läßt.

77 Qualitätsmerkmale: Benutzerfreundlichkeit (Beispiel aus einem Projekt)
„ Eignung des Systems bzw. seiner Teile zum Erlernen seiner Funk- tionen, zu seiner Bedienung und Handhabung sowie zur Interpretation seiner Meldungen und Ergebnisse durch den vorgesehenen Benutzer.“ Das Merkmal Benutzungsfreundlichkeit kann in folgende Teilmerkmale zerlegt werden: Antwortzeitverhalten, Bedienbarkeit, Erlernbarkeit, Verständlichkeit. Beispiel: Antwortzeitverhalten: Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß Für die Anwender muss ein zügiges Arbeiten mit dem System mög- lich sein Antwortzeiten im On-Line Betrieb in 95% aller Fälle unter 1 sek. Zeit Zeitmessung

78 Qualitätsmerkmale: Dokumentation (Beispiel aus einem Projekt)
„ Beschaffenheit der Dokumente, die während der Projektabwicklung zur Erstellung und Einführung eines IV-Produkts erzeugt werden.“ Das Merkmal Dokumentation kann in folgende Teilmerkmale zerlegt werden: Aktualität, Identifizierbarkeit, Konformität zu bestehenden Standards, Vollständigkeit, Verständlichkeit, Widerspruchsfreiheit. Beispiel: Identifizierbarkeit Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß Für Dokumente, die Er- gebnischarakter haben und die im Zeitverlauf veränderbar sind, gibt es eine Versionsführung. Versionsführung in den Dokumenten: Versionsnummer vorhanden Versionsnummer fehlt 100 % dieser Dokumente haben eine Versions- führung Review der Dokumente

79 Qualitätsmerkmale: Funktionalität (Beispiel aus einem Projekt)
„ Eignung des Systems bzw. seiner Teile, die im Pflichtenheft spezi- fizierten Funktionen ausführen zu können.“ Das Merkmal Funktionalität kann in folgende Teilmerkmale zerlegt werden: Ordnungsmäßigkeit, Richtigkeit, Vollständigkeit. Beispiel: Richtigkeit Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß 100 % der Eingabe- und Bedienungsfehler werden bei den als kritisch einge- stuften Testfällen erkannt, sonst 90%. Eingabe- und Bedie- nungsfehler werden vom System erkannt Prozentsatz der identifi- zierten Eingabe- und Bedienungsfehler Testen am System auf Basis definierter Testfälle (Falscheingaben)

80 Qualitätsmerkmale: Integration (Beispiel aus einem Projekt)
„ Integration ist das Ausmaß, in dem das System in sein IV-technisches und organisatorisches Umfeld eingebunden ist.“ Das Merkmal Integration kann in folgende Teilmerkmale zerlegt werden: Interoperabilität (Schnittstellen), Prozeßintegration. Beispiel: Ausgabe-Schnittstellen Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß Ausgabe-Schnittstellen werden korrekt bedient Prozentsatz der korrekt übergebenen Datenfelder Testen am empfangen- den System 100 % der Felder werden korrekt übergeben

81 Qualitätsmerkmale: Effizienz (Beispiel aus einem Projekt)
„ Die Effizienz ist das Ausmaß der Inanspruchnahme von Betriebs- mitteln (Hardware) durch das Software Produkt bei gegebenen Funktionsumfang“ Das Merkmal Effizienz kann in folgende Teilmerkmale zerlegt werden: Laufzeitverhalten, Speicherungsbedarf, Zugriffsoptimierung. Beispiel: Laufzeitverhalten Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß Gehaltsabrechung ist in x Stunden fertig Zeit Zeitmessung Zeit <= x Stunden

82 Qualitätsmerkmale: Portabilität (Beispiel aus einem Projekt)
„ Portabilität ist ein Maß für den Anpassungsaufwand des Systems an eine andere Hard- oder Softwareumgebung bei identischer Funktionalität aller Komponenten“ Das Merkmal Portabilität kann in folgende Teilmerkmale zerlegt werden: Implementierungsfreundlichkeit, Kompatibilität, Übertragbarkeit, Wiederverwendbarkeit. Beispiel (Standardsoftware): Nicht erforderlich; da es sich um Standardsoftware handelt, besteht kaum eine Einflussmöglichkeit des Teams.

83 Qualitätsmerkmale: Sicherheit (Beispiel aus einem Projekt)
„ Eignung des Systems bzw. seiner Teile, sich vor Beeinträchtigungen von außen zu schützen“ Das Merkmal Sicherheit kann in folgende Teilmerkmale zerlegt werden: Datenschutz, Datenintegrität, Zugriffsschutz. Beispiel: Zugriffsschutz Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß Aller unerlaubte Zugriff auf Personaldaten muss ausgeschlossen sein Wahrscheinlichkeit, dass eine Schutzfunktion versagt Testen durch ein Mitglied des Chaos-Computer- clubs Unerlaubter Zugang wurde nicht geschafft

84 Qualitätsmerkmale: Wartbarkeit (Beispiel aus einem Projekt)
„ Wartbarkeit ist ein Maß für den Aufwand zur Weiterentwicklung bzw. Fehlerbeseitigung eines bereits existierenden Programms.“ Das Merkmal Wartbarkeit kann in folgende Teilmerkmale zerlegt werden: Anpassbarkeit, Analysierbarkeit, Änderbarkeit, Erweiterbarkeit, Testbarkeit, Verständlichkeit. Beispiel (Standardsoftware): Nicht erforderlich; da es sich um Standardsoftware handelt und die vorhandenen Info- bzw. RASA Programme möglichst weiter benutzt werden sollen, besteht kaum eine Einflussmöglichkeit des Teams.

85 Qualitätsmerkmale: Zuverlässigkeit (Beispiel aus einem Projekt)
„ Eignung des Systems bzw. seiner Teile, während einer vorgegebenen Anwendungsdauer fehlerfrei zu funktionieren.“ Das Merkmal Zuverlässigkeit kann in folgende Teilmerkmale zerlegt werden: Reproduzierbarkeit, Robustheit, Stabilität, Verfügbarkeit, Wiederherstellbarkeit. Beispiel: Stabilität Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß Das System ist stabil, soweit dies in der Ver- antwortung des Entwick- lungsteams liegt Max. Anzahl der System- ausfälle < 1,5*Anzahl der Tage der Beobachtungs- phase Anzahl der System- ausfälle in der Beobachtungszeit Zählen

86 Qualitätssicherung: „Testen“
Wir benutzen hier eine allgemeine Definition: Jede Maßnahme der analytischen Qualitäts- sicherung, d. h. jede prüfende Maßnahe , kann man unter „testen“ subsumieren. „Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden“ „Testen nennt man jede Aktivität, die zum Ziel hat, eine Eigenschaft oder Fähigkeit eines Programms oder Systems zu überprüfen, um festzustellen, ob die Anforderungen erfüllt sind“ Quelle: Myers, G. J., “Methodisches Testen von Programmen” Oldenbourg (Erstausgabe 1979) Die Definition von Hetzel erweitert die ursprüngliche Definition von Myers. Hetzel ist der Auffassung, daß es viele Wege gibt, ein System auszuwerten (bzw. zu testen), ohne es auszuführen. Beispielsweise könnte man die Anforderungsspezifikation oder das Designdokument testen, indem man Testfälle definiert, die auf diesen Anforderungen oder Dokumenten basieren. Macht man dies, werden die Tester bereits frühzeitig in den Entwicklungsprozess eingebunden und können dabei helfen, Anforderungs- und Design-probleme bereits frühzeitig zu erkennen und zu beseitigen, bevor sie codiert werden und so zu steigenden Kosten bei der Korrektur führen. Eine weitere Beobachtung, die Hetzel macht, ist die, daß unser intuitives Verständnis des Testens sich eher um die Begriffe “messen” und “auswerten” herum rankt und sich nicht darauf bezieht, Fehler zu finden. Wenn wir beispielsweise Studenten testen, dann tun wir das nicht, um herauszufinden, was sie nicht wissen, sondern um zu demonstrieren, daß sie in der Lage sind, ein Thema auf akzeptable Weise zu verstehen und zu beschreiben. Beide Sichtweisen des Testens (jegliche Auswertungstätigkeit sowie die Ausführung von Programmen, um Fehler zu finden) sind wichtig. Myers ist mehr an der Programmierung orientiert, Hetzels Definition entspricht dem Ansatz des modernen Qualitätsmanagements. Man könnte danach Testen so definieren: Testen bedeutet, auf Projektebene analytische Qualitätssicherungs-maßnahmen auszuführen. Dies würde aber zur Verwirrung beitragen. Deswegen verwenden wir den Begriff Testen nur dann, wenn wir über Programme und Systeme sprechen, so wie es mehrheitlich in der Literatur getan wird. Quelle: Hetzel, Bill, “A Complete Guide to Software Testing, QED Information Sciences Inc. 1988 Hinweis: Die Folien enthalten erläuternde Notizen (Ansicht-Notizenseite von Powerpoint)

87 Strategien zur Elimination von Softwarefehlern
1. Effektive Fehlerverhütung 2. Hohe Effizienz bei der Fehlerreparatur 3. Genaue Vorhersage von Fehlern bevor die Realisierung im Projekt beginnt 4. Exakte Fehlerverfolgung während der Entwicklung 5. Nützliche Qualitätsmessungen 6. Sicherstellen hoher Anwenderzufriedenheit Quelle: Jones Die erfolgreichste und kostengünstigste Methode besteht sicher darin, Fehler zu verhüten. Dazu dienen insbesondere die konstruktiven Qualitäts-sicherungsmaßnahmen. Weiter fallen in diese Kategorie Reviews, Walk-Throughs und Inspections, die zum Ziel haben, Fehler möglichst schon in der Analyse oder im Design abzufangen. Die Effizienz der Fehlerreparatur wird folgendermaßen gemessen: Wenn das Team während der Entwicklung 90 Fehler fand und der Anwender während des ersten Jahres der Nutzung 10, ist die Effizienz 90%. Industriedurchschnitt ist z. Z. 85%. Spitzenunternehmen kommen auf 95% oder sogar 99%. Fehlervorhersage bezieht sich auf die Vorhersage der wahrscheinlichen Fehleranzahl in der Software. Dies ist ein schwieriges Thema, für das es aber seit Anfang der 90iger Jahre unterstützende Software gibt. Fehlerverfolgung war früher eine Domäne großer hoch entwickelter Unternehmen. Inzwischen gibt es Software zur Erleichterung dieses Prozesses. Ein effektives Qualitätsmeßprogramm ist vielleicht das wesentliche Merkmal, das eine reife professionelle IV-Organisation am meisten von anderen unterscheidet. Das gilt allgemein für alle Unternehmensfunktionen: Die Leistungen von Unternehmen, die die Qualität messen, sind gewöhnlich besser als die der, die es nicht tun. Anwenderzufriedenheit ist ein spezielles Thema im Rahmen der Softwarequalität. Es gibt verschiedene effektive Methoden, um dies zu erreichen: Einsatz von Psychologen, periodische Umfragen, spezielle Reviews und Tests, um die Anwenderfreundlichkeit der Software zu bewerten. So gibt es z. B. bei einigen führenden Softwareherstellern Anwenderlabors, wo mit Video Kameras typische Anwendungsprofile der Software beobachtet werden. Quelle: Capers Jones, „Software Quality - Analysis and Guidelines for Success“, International Thomson Computer Press 1997

88 Wo soll man ansetzen? Die Frage, die sich stellt, wenn man die Qualität verbessern will, ist: Wo im Entwicklungsprozeß soll man ansetzen? Hier ist die Antwort eindeutig: So früh wie möglich! Die Beseitigung eines Fehlers, der früh erkannt wird, kostet wesentlich weniger als die Beseitigung eines Fehlers, der erst beim Testen der fertig gestellten Module erkannt wird. Deshalb setzen alle modernen Qualitätsmanagementansätze und Entwicklungsmethoden bereits bei der Fehlerverhütung an. Das heißt, nicht das Testen der Programme steht im Vordergrund sondern die Fehlerverhütung in der Anforderungsanalyse und im Design. Beim Testen der Programme lassen sich Fehler nur noch feststellen und beseitigen; in den früheren Phasen hingegen kann man Fehler vermeiden.

89 Fehlerverhütung: Wer macht die Fehler?
Untersuchungen über Fehlerursachen zeigen, daß der Mensch die meisten Fehler macht. Hier muß also angesetzt werden, wenn man die Fehler reduzieren möchte. Wenn es gelänge, einen Prozeß zu entwickeln, der sicherstellt, daß gar keine Fehler gemacht werden, könnte man auf das Testen ganz verzichten. So etwas gibt es natürlich nicht! Aber es gibt eine Entwicklungsmethode, die in diese Richtung zielt: das sogenannte Clean Room Development (basiert auf den Arbeiten von Dr. Harlan Mills und Rick Linger vom IBM Labor Gaithersburg) Haupt-Ziel des Clean Room Development besteht darin, Fehler zu vermeiden und damit den Aufwand zum Testen und zur Fehlerbereinigung zu reduzieren. Der Beifall für diese Methode ist allerdings verhalten. Gut zu funktionieren scheint sie bei stabilen Anforderungen und nicht zu großen Projekten (bis 1000 Function Points).

90 Fehlerverhütung: Ursachen für menschlich bedingte Fehler
Es gibt viele Gründe, warum der Mensch Fehler macht. Nur einen gibt es in der Regel nicht: Der Mensch will bewußt Fehler machen und macht deshalb welche. Natürlich gibt es Saboteure, aber die sind im normalen Unternehmensalltag Gott sei Dank selten. Viele der obigen Punkte kann man durch Maßnahmen in den Griff bekommen. Insbesondere das Management ist hier gefordert: Jede Mark, und jede Arbeitsstunde, die in die Verbesserung der Situation gesteckt wird, zahlt sich vielfach aus in Form von reduziertem Test- und Fehlerbereiningsaufwand sowie erhöhter Anwenderzufriedenheit. Man darf sich als Manager das Leben nicht zu leicht machen, insbesondere, da die Gründe mangelnder Leistungsbereitschaft der Mitarbeiter oft beim Management liegen. Sprenger behauptet z. B. in seinem Buch: „Mythos Motivation“, Campus 1993: „Zum anderen ist es aber von Unternehmen geradezu fahrlässig, einen weiteren wichtigen Zusammenhang zu ignorieren: Unter Perspektive der Motivierung ist jede Führungskraft als Motivator potentiell auch ein Demotivator. Wenn es Führungskräften gelingt, durch ihr Handeln oder durch die von ihnen inszenierten Anreize zusätzliche Leistung beim Mitarbeiter zu erzeugen, heißt das im Umkehrschluß, daß das Fehlen dieser Anreize oder sogar eine als negativ empfundene Einflußnahme demotivierend wirkt. Aus dieser Form der Abhängigkeit ergibt sich für das Unternehmen aber ein eminentes Steuerungsproblem: Wenn es motivierbare Mitarbeiter will, dann sind diese auch demotivierbar. - Diesen Zusammenhang zu ignorieren ist bei der grassierenden Führungsmisere von geradezu tragischer Komik.“ Der erste Schritt zur Vermeidung von Fehlern liegt also beim Management: Achten Sie darauf, Ihre Mitarbeiter nicht zu demotivieren. Motiviert sind sie meist von Natur aus, da jeder lieber gute Arbeit leistet als Fehler zu machen.

91 Fehlerverhütung: Ursachen für sachlich bedingte Fehler
Sehr viel einfacher als bei den menschlich bedingten Fehlern haben wir es bei den sachlich bedingten. Wenn wir uns die verschiedenen Ursachen genauer ansehen, lassen sich eigentlich alle relativ leicht beseitigen. Es kostet nur Geld. Deshalb muß sich auch ein hart gesottener Kapitalist folgendes überlegen. Was ist teurer, wenn meine Belegschaft ständig Fehler macht, weil miserable Arbeitsbedingungen herrschen oder wenn ich diese Arbeitsbedingungen verbessere? Kurzfristig gesehen mag das Verbessern teurer sein, aber mittelfristig gesehen lohnt es sich alle mal.

92 Psychologie des Testens (analytische QS): Wer soll testen?
Ziel des Testens ist, Fehler zu finden (nach Myers) Ein Test ist dann erfolgreich, wenn er Fehler findet Menschen sind gegenüber eigenen Fehlern toleranter als gegenüber fremden und übersehen sie deshalb leicht Wenn etwas missverstanden wurde, ist es unmöglich, selbst den Fehler zu entdecken der Autor (z. B. der Programmierer) ist in der Regel die ungeeignetste Person zum Testen! (Extrakt aus Myers: Methodisches Testen von Programmen, Oldenburg 1995)“ „.. Aber die Erfahrung hat einen wirksamen Einfluß auf den Testerfolg festgestellt. Da die Menschen eine höchst zielorientierte Tendenz zeigen, hat die Vorgabe eines Ziels einen bedeutenden psychologischen Effekt. Wenn es unsere Aufgabe ist zu zeigen, daß ein Programm keine Fehler hat, so sind wir unbewußt auf dieses Ziel ausgerichtet, d. h. wir neigen dazu, Testdaten auszuwählen, die mit geringster Wahrscheinlichkeit einen Programmfehler entdecken. Ist es andererseits unsere Aufgabe, Fehler in einem Programm aufzudecken, so haben unsere Testdaten eine größere Wahrscheinlichkeit, Fehler zu finden. Diese Definition des Testens hat Folgerungen: Es impliziert, daß Testen ein destruktiver, ja geradezu ein sadistischer Prozeß ist. Das erklärt auch, warum es die meisten Leute für schwierig halten. Denn der größte Teil unserer Gesellschaft hat eine konstruktive Einstellung zum Leben und keine destruktive. Die meisten Leute erschaffen lieber etwas als es zu zerstören. Diese Definition hat Einfluß auf die Definition der Testfälle (Testdaten) und darauf, wer ein gegebenes Programm testen sollte und wer nicht.“ Obwohl Myers hier nur von Programmen spricht, gilt das Gesagte wörtlich auch für Dokumente und andere Arbeitsergebnisse des Projekts. Wenn man Myers folgt, ergibt sich hier ein erster Hinweis darauf, wie Testen organisiert sein sollte: 1. Nicht der Autor selbst soll testen, d.h. ein anderer - möglicherweise ein Kollege oder ein Externer - muß diese Arbeit übernehmen. 2. Ein guter Tester (oder allgemein Qualitätsprüfer) benötigt eine „destruktive Mentalität“, also ist der Kollege meist ungeeignet. Es bietet sich deshalb eine spezielle Testgruppe an oder das Testen wird ganz aus dem Haus gegeben.

93 Ökonomie des Testens White Box Test: Black Box Test:
Bei diesen Testverfahren ist die innere Struktur der Programme bekannt. Der Tester definiert die Testfälle mit Kenntnis der Programmlogik (und oft unglücklicherweise) unter Vernachlässigung der Spezifikation Alle Fehler finden: Weder möglich durch Testen aller Statements noch durch erschöpfendes Pfadtesten, da beispielsweise Pfade fehlen können oder das Programm einfach das Falsche tut, weil es Missverständnisse gab. Außerdem ist die Anzahl möglicher Pfade meist sehr groß. Black Box Test: Der Tester betrachtet das Programm als Black Box, d.h. er ist nicht an der inneren Struktur interessiert, sondern daran, Umstände zu entdecken, bei denen sich das Programm nicht gemäß den Spezifikationen verhält. Alle Fehler finden: Wenn man mit diesem Verfahren alle Fehler finden will, so ist der vollständige Eingabetest, d.h. Kombination aller möglichen Eingabebedingungen, Voraussetzung dafür. Diese Zahl ist aber meist sehr groß. Extrakt aus Myers: Methodisches Testen von Programmen, Oldenburg 1995) „Der nächste notwendige Schritt nach dieser Definition des Programmtestens muß zu der Frage führen, ob es möglich ist, im Test alle Fehler des Programms zu finden. Die Antwort ist leider negativ, selbst für triviale Programme. Im allgemeinen ist es nicht machbar, oft unmöglich, alle Fehler eines Programms zu finden. Das wiederum hat einen Einfluß auf die Ökonomie des Testens, auf die Annahmen, die ein Tester über das Programm machen muß, und auf die Art, wie Testfälle entworfen werden.“ „Man betrachte den Versuch, an einem Cobol Compiler einen erschöpfenden Black-Box Test durchzuführen. Man hätte nicht nur Testfälle für alle zulässigen Cobolprogramme zu definieren (unendlich viele!), sondern auch Testfälle für alle ungültigen Cobolprogramme (unendlich viele!), um sicher zu stellen, daß der Compiler sie als unzulässig erkennt. Das Problem wird noch schwieriger bei Programmen mit Gedächtnis (z. B. Betriebssysteme, Datenbanksysteme, Flugreservationssysteme). In solchen Systemen ist die Durchführung einer Transaktion abhängig von dem, was früher passiert. Man muß also nicht nur alle zulässigen und unzulässigen Transaktionen durchprobieren, sondern auch alle möglichen Sequenzen von Transaktionen. Entsprechende Aussagen gelten für White Box Tests. Daraus ergeben sich zwei Folgerungen: 1. Man kann ein Programm i. A. nicht so testen, daß seine Fehlerfreiheit garantiert werden kann 2. Ein fundamentaler Gesichtspunkt beim Programmtest ist die Wirtschaftlichkeit.“

94 Management und Messbarkeit
Ausführen des Akzeptanztests Spezifizieren der Anforderungen Ausführen des Systemtests Review der Anforderungen Spezifizieren des System- und Akzeptanztests Review des System- und Akzeptanztests Spezifizieren des Design Ausführen des Integrations- und Funktionstests Review des Designs Review/Audit des Integrations- und Funktionsteststests Spezifizieren des Integrations- und Funktionstests Codieren der Programme Ausführen des Modultests Testen basiert jetzt auf dem erweiterten V-Modell. Es ist ein meßbarer und quantifizierbarer Prozeß. Reviews in allen Phasen des Entwicklungsprozesses werden jetzt als Test- bzw. qualitätssichernde Tätigkeiten anerkannt. Softwareprodukte werden in Bezug auf Qualitätsmerkmale wie z. B. Zuverlässigkeit, Nutzbarkeit und Wartbarkeit getestet. Testfälle aller Projekte werden gesammelt und in einer Datenbank gespeichert, um sie wieder verwendbar zu machen und Regressionstests zu erlauben. Fehler werden dokumentiert und nach Schwere klassifiziert. Noch vorhandene Schwächen im Testprozeß rühren jetzt oft daher, daß noch nicht die Philosophie der Vorbeugung befolgt wird und daß die automatisierte Unterstützung des Sammelns, Analysierens und Veröffentlichens von testbezogenen Metriken noch unvollkommen integriert ist. Spezifizierende Tätigkeiten Review des Codes Review/Audit des Modultests Ausführende Tätigkeiten Quelle: Daich, G. et al., “Software Test Technologies Report” STSC, Hill Air Force Base 1994 Überprüfende Tätigkeiten Spezifizieren des Modultests

95 Einsatz analytischer Testmethoden
Ergebnis Anforderungen Systemkonzept Design Programm System Dokumente Maßnahmen Inspektionen *** *** ** *** Analyse ** ** *** * ** ( ) Test * * *** *** * Die letzte Spalte wurde ergänzt. Die mannigfaltigen analytischen Maßnahmen (Prüfungen) müssen parallel zum Entwicklungsprozeß stattfinden. Sie lassen sich in die Gruppen: Inspektionen, Analysen, Test und Verifikation, Validierung einteilen. Unter Inspektionen versteht man informale oder formale manuelle Prüfungen und Untersuchungen von Dokumenten, Spezifikationen und Programmen, die sich in Reviews, Audits, Walk Throughs, Inspections und Peer Reviews gliedern lassen. Analysen lassen sich in vielfältiger Art durchführen, z. B. „statische Analysen“ wie Anforderungsanalyse, Anforderungsverfolgung, Algorithmus Analyse, Rundungsfehleranalyse, Strukturanalyse, Datenflußanalyse etc. sowie „dynamische Analysen, z. B. Software Leistungsanalyse, „sicherheitsnalysen“, z. B. Fehlerbaumanalyse, Ereignisablaufanalyse, Ausfalleffektanalyse, Ursache-Wirkungsanalyse, Echtzeit-Logik-Analyse. Ausführlich behandelt werden diese Techniken in Trauboth, Software Qualitätssicherung. Hier werden wir nicht näher darauf eingehen. Test wurde bereits definiert. Die Verifikation stellt die Übereinstimmung zwischen den wahren Qualitätsmerkmalen des Produkts und den spezifizierten Merkmalen fest. Dies gilt auch für Zwischenprodukte während des Entwicklungsprozesses. Validation stellt die Tauglichkeit des Produkts für seine vorgesehene betriebliche Aufgabe fest. Verifikation Validierung * ** *** ** Quelle: im wesentlichen nach Trauboth, „Software Qualitätssicherung“, Oldenbourg, 1996 *** ** * häufiger weniger häufig selten

96 Formale und weniger formale Überprüfungsmethoden
Reviews überprüfen am Ende jeder Entwicklungsphase Umfang und Qualität der Zwischenprodukte. Projektpersonal, Auftragnehmer-management und Auftraggeber entscheiden gemeinsam, ob die nächste Phase angegangen werden kann Audits sind offizielle Reviews zur Verifikation besonders kritischer Teile durch das QS-Personal Ziel eines Walk-Throughs ist, Problembereiche zu entdecken, sie aber erst nach Abschluß des Walk-Throughs und nach Zustimmung des Erstellers zu beheben Peer Review entspricht dem Walk Through. Es geht dabei um eine methodische Examinierung der Ergebnisse durch sachkundige Kollegen (Peers). Ziel ist, Fehler zu finden und Bereiche, in denen Änderungen erforderlich sind Inspection ist eine sehr formale Gruppensitzung, in der die zu inspizierende Unterlage vom Autor vorgelesen und sequentiell Wort für Wort durchgearbeitet wird Quelle: Jones Inspektionen gehören in die Gruppe der sog. Pretest Removal Techniken (vgl. Jones). Es ist eine interessante Tatsache, dass formale Design- und Codeinspektionen, die derzeit zu den effektivsten Fehlerbereinigungstechniken gehören, auch eine ganz wichtige Rolle bei der Fehlerverhütung spielen. Entwickler, die an Reviews und Inspections teilgenommen haben, tendieren dazu, Fehler, die während der Inspektionen aufgedeckt wurden, in Zukunft zu vermeiden.

97 Ursachen für Softwarefehler
Fehlerursache End-User Systeme Outsource Systeme Kommerz. Systeme Systems- software Militär Systeme Durch- schnitt MIS 0,00 % 15,00 % 55,00 % 10,00 % 20,00 % 100,00 % 15,00 % 30,00 % 35,00 % 10,00 % 100,00 % 20,00 % 25,00 % 35,00 % 10,00 % 100,00 % 10,00 % 30,00 % 20,00 % 100,00 % 10,00 % 25,00 % 40,00 % 15,00 % 100,00 % 20,00 % 35,00 % 15,00 % 10,00 % 100,00 % 12,50 % 24,17 % 38,33 % 13,33 % 11,67 % 100,00 % Anforderungen Design Quellcode Handbücher und Trainingsmaterial Sekundärfehler (fehlerhafte Wartung) Quelle: Jones Alle sechs Fehlerursachen werden von führenden Unternehmen der Welt seit über 30 Jahren gemessen. IBM beispielsweise entwickelte bereits in den 60iger Jahren ein automatisiertes Softwarefehler Reporting System, in dem Daten folgender Kategorien gesammelt wurden: Anzahl der gefundenen Fehler Schwere der gefundenen Fehler Wie wurden die Fehler gefunden(Reviews, Inspections, Tests, Kunden) Woher kamen die Fehler? (Anforderungen, Design, Code, Handbücher oder Sekundäreffekte) Daraus wurden im Laufe der Jahre u. a. folgende Schlüsse gezogen: Fehler bei den Anwenderschnittstellen und beim Design überwiegen die Programmierfehler Programmierfehler in großen Systemen konzentrieren sich in bestimmten Modulen Formale Inspektionen sind effizienter als Testen, um Fehler zu finden Sekundärfehler durch fehlerhafte Wartung können viel Ärger bereiten Testfälle und Testdatenbanken enthalten oft selbst viele Fehler Hohe Qualität steht in Verbindung mit kurzen Entwicklungszeiten und niedrigen Entwicklungskosten Function Point Metriken eignen sich am besten für Qualitätsuntersuchungen Ähnliche Ergebnisse berichten auch AT&T, HP, ITT, Motorola, Raytheon. Total

98 Fehlerursprung und Fehlerbereinigungseffizienz
Anforderungs- fehler Design- fehler Code- fehler Dokumenten- fehler Performanz- fehler Inspektions- methoden zufrieden- stellend zufrieden- stellend ausgezeichnet ausgezeichnet gut zufrieden- stellend Zufrieden- stellend nicht anwendbar Proto- typing gut gut zufrieden- stellend schwach schwach gut ausgezeichnet Testen Korrektheits- beweise zufrieden- stellend schwach schwach gut schwach Eine signifikante Schwäche aller Fehlerbereinigungstechniken besteht darin, daß es z. Z. keine Methoden gibt, die bei der Bereinigung von Fehlern aus der Anforderungsspezifikation besser als „gut“ abschneiden. Es ist deshalb wohl offensichtlich, daß man, um die Effekte von Anforderungsfehlern möglichst zu reduzieren, Fehlerverhütungsmethoden als Teil der Strategie einsetzen muß. Die geringe Fehlerbereinigungseffizienz im Bereich der Anforderungsfehler (77 %) sowie auch im Design (85 %) führt dazu, daß zum Zeitpunkt der Systemeinführung die verbleibenden Fehler wesentlich stärker ins Gewicht fallen, als Programmierfehler (0,23 bzw. 0,19 pro Function Point im Vergleich zu 0,09 pro Function Point für Programmierfehler). Quelle: Capers Jones, „Software Quality - Analysis and Guidelines for Success“, International Thomson Computer Press 1997

99 Fehlerursprung und Entdeckung
Anforderungen Design Codierung Dokumentation Test Wartung Fehler- ursprung Fehler- entdeckung Anforderungen Design Codierung Dokumentation Test Wartung Chaos-Phase Ohne Einsatz formaler Inspektionsmethoden Anforderungen Design Codierung Dokumentation Test Wartung Fehler- ursprung Quelle: Jones, Software Quality - Analysis and Guidelines for Success, Thomson Computer Press 1997 Eine der effektivsten Arten, um den Nutzen formaler Inspektionen zu illustrieren, ist, graphische Darstellungen zu machen, wo der Zeitpunkt des Fehlerursprungs mit dem Zeitpunkt des Fehleraufdeckens verbunden wird. Immer dann, wenn wir bei der Verbindungslinie einen spitzen Winkel vorliegen haben, haben wir ein ernstes Problem mit der Qualitätskontrolle, denn die Lücke zwischen dem Machen und dem Entdecken des Fehlers kann viele Monate betragen. Das Ziel ist, den Winkel so nahe wie möglich an 90o heran zubringen. Obwohl das Erreichen von 90o unwahrscheinlich ist, schaffen formale Inspektionen es jedenfalls, den Winkel von 30o auf über 6oo zu bringen. Wiw man sieht, treten Softwareentwicklungsprojekte, die die Technik der Inspektion nicht nutzen, gegen Ende des Testzyklus in eine Chaoszone ein. Das liegt daran, daß plötzlich Probleme aus der Anforderungs- und Spezifikationsphase auftauchen, die erheblichen Reparaturaufwand und Überarbeitung erfordern. Inzwischen gibt es in den USA genügend Anwender von Inspektionen, so daß sie eine gemeinnützige Geselschaft gebildet haben: SIRO (Software Inspection and Review Organization) in Sunnyvale, Californienmit der URL Es ist allerdings zu bezweifeln, daß diese Organisation sehr aktiv ist, denn der letzte Eintrag auf der Home Page war von 1996. Fehler- entdeckung Anforderungen Design Codierung Dokumentation Test Wartung Mit Einsatz formaler Inspektionsmethoden

100 Wie erreicht man eine hohe „Fehlerbereinigungseffizienz“?
Jede einzelne Maßnahme hat einen Wirkungsgrad von ca 30% (d. h. findet 30% der verbleibenden Fehler). Um eine hohe Fehlerbereinigungseffizienz (% der Fehler, die Während des Projekts gefunden werden) zu erreichen, müssen mehrere Maßnahmen hintereinander ausgeführt werden. Fehlerverhütung Formale Anforderungsanalyse (z. B. Joint Application Design) Formale Risikoanalyse frühzeitig in der Entwicklung Prototyping Strukturierte oder formale Spezifikationsmethoden Strukturierte Programmiermethoden Zertifizierte wiederverwendbare Design- und Codekomponenten Fehlerbereinigung vor dem Test Inspektion der Anforderungen Inspektion des Designs Inspektion des Codes Reviews des Testplans Inspektion der Testfälle Editieren oder reviewen der Anwenderdokumentation Testen Modultest durch die Programmierer Testen neuer Funktionalität Regressionstest Performanztest Integrationstest Systemtest Feldtest (externer Beta Test) Quelle: Jones Von den in diversen Teilbereichen der Wirtschaft und Verwaltung gemessenen Werten ist offensichtlich, daß eine hohe Fehlerbereinigungseffizienz nur durch eine Kombination verschiedener Methoden in einem mehrphasigen Vorgehen erreichbar ist. Obige Abfolge von Tätigkeiten ist die Minimalanforderung, wenn man gut oder exzellent werden will. Exzellent, d.h. über 99 %. Durchschnittliche Werte in den USA für einige Branchen sind die folgenden: Militär 99,33 %, Systemsoftwarehersteller 99,58 %, Unternehmen, die kommerzielle Software entwickeln 99,32 %. Der Grund, warum es so viele unterschiedlicher Schritte der Fehlerbereinigung bedarf, liegt darin, daß die Effizienz jeder Aktiviät ungefähr nur 30 % ist. Um daraus eine kumulative Effektivität von mehr als 95 % aufzubauen, bedarf es schon einer Reihe von Aktivitäten.

101 Einbettung der Methode Test Rx TM in den Entwicklungszyklus
phase Prozessschritte Beteiligte 1. Testteam benennen Analyse Projekt-/Testmanager Analyse 2. Risikoanalyse durchführen Projekt-/Testmanager 3.Testziele festlegen Analyse Testmanager/Tester 4.Testpläne aufstellen Analyse/Design Testmanager/Tester 5.Testfälle entwickeln Analyse/Design Tester 6.Modul-/Integrationstest ausführen Konstruktion Entwickler/Tester Test 7.Systemtest durchführen Tester Viele Firmen haben heute ein Vorgehensmodell zur Systementwicklung bzw. Einführung von Standard Software im Einsatz. Sicher wird dort auch etwas über das Testen ausgesagt, nur vielleicht nicht genug. Die Methode wurde so entwickelt, daß sie sich in einen generischen Entwicklungszyklus einpassen läßt und daß die derzeit am Markt befindlichen Testwerkzeuge eingesetzt werden können. Quellen der Methode sind: „The Handbook of MIS Application Software Testing Methods, Techniques, and Tools for Assuring Qaulity Through Testing“, Daniel J. Mosley, Prentice Hall 1993 „Client-Server Software Testing on the DeskTop and on the WebTop“, Daniel J. Mosley, Prentice Hall 1998 „A standard for Testing Application Software“, William Perry ANSI/IEEE Std , Software Test Documentation ANSI/IEEE Std Software Unit Testing“ 8.Analysieren der Testergebnisse Test Testmanager/Tester 9.Regressionstest durchführen Wartung Tester 10. Analysieren der Testergebnisse Wartung Tester

102 Unterstützende Basistechniken
Konfigurationsmanagement (KM) Fehlerverfolgung und Problem-Dokumentation (FP) Testautomation (TA) Peer Reviews (PR) Testmetriken (TM) Konfigurationsmanagement: Das Ziel des Konfigurationsmanagements besteht darin, sicherzustellen, daß ein Produkt bezüglich seiner funktionellen wie auch äußeren Merkmale - wie z. B. bei Dokumenten - jederzeit eindeutig identifizierbar ist. Diese Identifikation dient der systematischen Kontrolle von Änderungen und zur Sicherstellung der Integrität, auch während der Nutzung. Das KM überwacht die Konfigurationen, so daß die Zusammenhänge und Unterschiede zwischen früheren Konfigurationen und den aktuellen Konfigurationen jederzeit erkennbar sind. (Handbuch K. des V-Modells, Entwicklungsstandard für IT-Systeme des Bundes) Fehlerverfolgung und Problemdokumentation: Die Verwaltungsaufgaben beim Testen sind beträchtlich. Das ist insbesondere in den späteren Testphasen so. Es ist deshalb wichtig, genau zu überlegen, wie dies durchgeführt werden soll. Idealerweise bedient man sich auch eines Werkzeugs, das die Arbeit unterstützt. Testautomation: Automatisiertes Testen reduziert die Testfehler und die Testkosten. Automatisiertes Testen reduziert ebenfalls die Effekte individueller Unterschiede. Peer Reviews: Diese Methode wird vom Capability Maturity Modell als besonders wichtig dargestellt. Der Peer Review Prozeß ist ein teilformalisierter (Walk Through) oder auch formalisierter (Inspection) Reviewprozeß, bei dem ein sog. ‚Autor‘ seine Arbeitsergebnisse einem Team von Kollegen (Peers, d.h. Gleichrangigen) vorstellt. Testmetriken: Das Messen ist schon von jeher Bestandteil aller wissenschaftlichen Methoden gewesen. Erst durch das Messen verstehen wir die uns umgebenden Phänomene. Das gilt auch für die Systementwicklung und das Testen.

103 Der Testprozess und die unterstützenden Techniken
Prozessschritte KM FP TA PR TM - o x - x - o x x - x 1. Testteam benennen 2. Risikoanalyse durchführen 3.Testziele festlegen 4.Testpläne aufstellen 5.Testfälle entwickeln 6.Modul-/Integrationstest ausführen 7.Systemtest durchführen Im Kurs werden zwar keine Detailtechniken behandelt, z. B. einzelne Techniken zur Bestimmung von Testfällen, spezielle Review- und Audittechniken Diese grundlegenden Techniken hingegen werden wir noch etwas näher beleuchten. Der Testautomation wurde sogar ein eigenes Kapitel gewidmet. Doch zunächst einmal werden wir jetzt die Methode näher betrachten. 8.Analysieren der Testergebnisse 9.Regressionstest durchführen 10. Analysieren der Testergebnisse - = nicht erforderlich, o = optional, x = erforderlich

104 Wie verbessert die Definition von Testzielen die Testplanung?
Testziele bringen Disziplin in den Testprozeß Testziele sagen dem Tester, was er erreichen soll Testziele garantieren, daß der Test vollständig ausgeführt wird Die Operationalisierung der Testziele in Form einer Qualitätscheckliste macht die Überprüfung einfach Testziele bringen Disziplin in den Testprozeß: Sie können als Maßstab dienen, um den Testprozeß und den Testfortschritt zu leiten. Sie sichern Vollständigkeit der Durchführung der Testaktivitäten und sie verbessern die Kommunikation zwischen den Teammitgliedern. Klar definierte Testziele helfen bei der Formulierung von Testfällen, bei der Festlegung des Testprozesses, sowie bei Testanalyse und Berichterstattung. Ziele sagen dem Tester, was erreicht werden soll. Sie können als Basis für die Definition von Meilensteinen verwendet werden, die den Testfortschritt beschreiben. Wenn bewiesen werden kann, daß die Ziele erreicht wurden (entweder quantitativ oder qualitativ), dann hat der Testprozeß erreicht, was er sollte. Testziele können dazu verwendet werden, die Konditionen zu bestimmen, die getestet werden und damit die Testfälle. Testfälle, die entwickelt wurden, um die Testziele zu erreichen, sind sozusagen „intelligente Testfälle“. Die Wahrscheinlichkeit, daß sie sowohl vorhergesehene als auch unvorhergesehene Fehler entdecken, ist höher. Dies vermeidet die Unvollständigkeit, die zufällig entwickelten Testfällen inne wohnt. Ziele geben den einzelnen Testaktivitäten eine Richtung, der der Tester leicht folgen kann. Darüber hinaus machen sie den Testprozeß wiederholbar, denn sie erzeugen Konsistenz zwischen den einzelnen Testern. Die Folgen persönlicher Unterschiede, Ausbildung und Erfahrung werden substantiell reduziert. Die Implementierung der Testziele, d.h. die Umsetzung in operationale Qualitätschecklisten erleichtert den Testprozeß. Dabei ist die Überprüfbarkeit wichtig. D. h. Jedes Element der Checkliste muß sich auf genau ein oder mehrere Testziele rückverfolgen lassen. Die Spezifikation von Testzielen und Checklisteneinträgen ist in der Regel ein iterativer Prozeß.

105 Beispiel: Testziele und Checkliste für den Modultest (‚korrektes Datum‘)
Sicherstellen, dass Schaltjahre die Verarbeitung nicht aufhalten Sicherstellen, dass Monate 00 und 13 die Verarbeitung nicht aufhalten Sicherstellen, dass Tage 00 und 32 die Verarbeitung nicht aufhalten Sicherstellen, dass Februar die Verarbeitung nicht aufhalten Sicherstellen, dass der 30. Februar als Fehler ausgewiesen wird Sicherstellen, dass ein Jahrhundertwechsel die Verarbeitung nicht aufhält Sicherstellen, dass Daten außerhalb des Zyklus die Verarbeitung nicht aufhalten Sicherstellen, dass Daten außerhalb des Zyklus als Fehler ausgewiesen werden Checkliste: Einbeziehen von Schaltjahren Einbeziehen der Monate 00 und 13 Einbeziehen der Tage 00 und 32 Einbeziehen des Februars Einbeziehen von Daten, die verschiedene Jahrhunderte abdecken Einbeziehen von Daten, die außerhalb des Zyklus (z. B. des Buchungszyklus) liegen Die obigen Beispiele illustrieren die Art von Zielen, die für einen Modultest (d.h. Programmtest) festgelegt werden können. Man beachte dabei, daß Ziele positiv und negativ definiert werden können. Statt: „Sicherstellen, daß Schaltjahre die Verarbeitung nicht aufhalten“ hätten wir auch sagen können „ Sicherstellen, daß Schaltjahre richtig verarbeitet werden“. Was ist der Unterschied? Nun, er ist psychologischer und funktioneller Natur. Positiv formulierte Ziele zeigen, daß das Programm tut, was es soll. Negativ formulierte Ziele zeigen, daß ein Programm nicht tut, was es nicht soll. Beide Ansätze sind notwendig, um die Vollständigkeit des Testens zu garantieren. Die Beispiele oben gelten nicht für ein bestimmtes Programm sondern generell für eine Klasse von Programmen. Im konkreten Falle haben wir es oft mit einzigartigen Situationen zu tun, auf die speziell eingegangen werden muß.

106 Integration der Testplanung in den Entwicklungszyklus
Zu erstellender Testplan Auszuführender Testplan Entwicklungszyklusphase Analyse Systemtestplan Regressionstestplan Analyse Integrationstestplan System Design Detailliertes Design Modultestplan Konstruktion Modultestplan Konstruktion Integrationstestplan Die Testplanung beginnt eigentlich schon, bevor das Projekt richtig angefangen hat. Die Arbeit kann beginnen, sobald die Anforderungen definiert sind. Aber bevor der Testplan ausformuliert werden kann, müssen die Teststandards festgelegt worden sein. Teststandards sollten unabhängig von einem spezifischen Projekt definiert werden. Aber sie sollten so flexibel sein, daß man sie für ein konkretes Projekt an individuelle Anforderungen anpassen kann. Test Systemtestplan Produktion/Wartung Regressionstestplan

107 Inhalt eines Testplans (1)
Ein umfassender Testplan leistet folgendes: Er definiert die globalen messbaren Testziele im Test-Rahmenplan und definiert spezielle messbare Ziele für Teiltestpläne. Er enthält eine vollständige Beschreibung der Funktionalität und der Struktur des zu testenden Systems Er adressiert Testen vom Standpunkt eines Testzyklus aus, der parallel zum traditionellen Entwicklungszyklus verläuft und sichert so, dass Testen frühzeitig in der Entwicklung beginnt und über den gesamten Prozess hinweg fortgesetzt wird sowie dass bestimmte Review-Meilensteine gesetzt werden Er legt spezielle Aufgaben fest, die während jeder Phase des Tests auszuführen sind inklusive der Kosten und Ressourcenschätzungen für diese Aufgaben Er identifiziert Startkriterien und Abschlußkriterien für jede Testaktivität Er identifiziert alle Personen, die in den Testprozess involviert sind, weist ihnen Aufgaben zu und stellt Arbeitspläne auf Der erste Schritt bei der Entwicklung eines formalen Testplans besteht darin, ein grobes Konzept zu erstellen, das auf den etablierten Teststandards beruht. Wenn Ihre Organisation solche Standards nicht hat, gibt es eine Reihe von guten Quellen dafür, z. B.: A Standard For Testing Application Software, Willian Perry, Auerbach 1992 Federal Information Processing Standards (FIPS) Nr. 39 Structure Software Testing, Eldon Li, Center for Business and Economic Research, California Polytechnic State University. Warum sollte man das Rad immer neu erfinden wollen? Eine Art wie Menschen lernen besteht darin, daß sie andere nachmachen. Wenn es möglich ist, einen Mustertestplan zu erhalten, den jemand anders erstellt hat, dann sollte man ihn als Ausgangspunkt benutzen. Danach kann man ihn dann an die spezifischen Bedürfnisse der eigenen Organisation anpassen. Aber achten Sie darauf, daß Ihr Modelltestplan auch wirklich auf praktischen Erfahrungen aufbaut.

108 Inhalt eines Testplans (2)
Fortsetzung: Er identifiziert die erforderlichen Ressourcen für das Design, die Dokumentation und Ausführung der Testfälle bzw. Testszenarios sowie für die Aufzeichnung, Analyse und Berichterstattung der Testergebnisse Er identifiziert erwartete Ergebnisse für alle Tests Er legt Notfallmaßnahmen fest, die im Falle eines katastrophalen Fehlers des neuen Systems bzw. der neuen Version zum Tragen kommen er definiert manuelle und automatische Testtechniken und Werkzeuge sowie wann und wie sie verwendet werden sollen er definiert Prozeduren zur Lokalisierung, Entfernung und Verfolgung von Fehlern (debugging) Er legt das erforderliche Training für die Testmitarbeiter fest Er enthält einen Index, in dem Informationsquellen über die implementierten Testmethoden und Prozeduren zu finden sind

109 Black Box Methoden (Auswahl)
Aufgabenorientierte Testfallbestimmung Funktionsorientierte Testfallbestimmung Bildung von Äquivalenzklassen Grenzwertanalyse Ursache-Wirkung-Analyse Statistische Testdatenauswahl Bei der aufgabenorientierten Testfallbestimmung werden Testfälle auf der Grundlage der Problembeschreibung, der Anforderungen und des fach-lichen Konzepts festgelegt unabhängig von der Realisierung der Software. Im Gegensatz dazu sind bei der funktionsorientierten Testfallbestimmung der Entwurf, die Schnittstellen und Programmspezifikationen incl. Datenstrukturen die treibenden Aspekte. Es sollen Testfälle bestimmt werden, die die Funktionen zur Ausführung bringen. Durch Bildung von Äquivalenzklassen (d. h. Klassen von Testfällen, bei denen einer als repräsentativ für die ganze Klasse gelten kann) erreicht man, daß die Anzahl der Testfälle auf ein Minimum reduziert wird. Bei der Grenzwertanalyse werden die Eingabe- und Ausgabe-Äquivalenz-klassen auf ihre Grenzen und Ränder untersucht. Jeder Rand einer Äquiva-lenzklasse (Eingabe und Ausgabe) muß in einem Testfall auftreten. Auch alle Ausgabe-Äquivalenzklassen müssen durch entsprechende repräsentative Eingabewerte berücksichtigt werden. Anhand der Anforderungsspezifikationen für die Eingangsbedingungen und ihrer Kombinationen werden die Ursache-Wirkungsbeziehungen vom Eingang zum Ausgang des Testobjekts (ohne Berücksichtigung der inneren Struktur) graphisch aufgestellt. Aus dem Netz der logischen Graphen werden dann Testfälle abgeleitet. Der Wert statistischer Tests ist umstritten. Das hängt u. a. damit zusammen, daß die Kosten statistischer Tests relativ hoch sind. Statistische Tests ergeben Wahrscheinlichkeitsaussagen z. B. über erwartete Restfehlerraten Zuverlässigkeit und Risiko. Quelle: H. Trauboth, „Software-Qualitätssicherung“, Oldenbourg 1996

110 White Box Methoden - Auswahl
Überdeckungsorientierte Testfallbestimmung Datenflussorientierte Testfallbestimmung Bereichsorientierte Testfallbestimmung Vgl. Trauboth: Während beim Funktionstest (Black Box) die innere Struktur des Testobjekts und die Realisierung der Funktionen keine Rolle spielen, wird beim Strukturtest die Implementation der Funktionen, d.h. vorwiegend ein Programm, betrachtet. Zwei Arten von Maßen können definiert werden: Überdeckungsgrad, der die Zahl der Struktureinheiten angibt, die durch die Testfälle ausgeführt werden Komplexitätsgrad, der die Tests im Verhältnis zur Komplexität der Software bestimmt. Überdeckungsorientierte Testfallbestimmung: Die meisten Überdeckungs-maße basieren auf der Zahl der Anweisungen, Bedingungen, Zweige und Pfade in einem Programm, die durch die Eingabedaten ausgeführt (aktiviert, durchlaufen) werden. Es wird davon ausgegangen, daß das zu testende Programm als Graph dargestellt werden kann, an dem die Testfälle definiert werden können. Datenflußorientierte Testfallbestimmung: Die Datenflußanalyse, zeigt auf, wie Variable an Werte gebunden sind und wie diese Variablen benutzt werden. Die Kriterien zur Testdatenauswahl über eine Datenflußanalyse ergeben sich aus der Verfolgung der Eingangs-variablen durch ein Programm über die Verarbeitung hin, bis sie schließlich Ausgabewerte erzeugen. Bereichsorientierte Testfallbestimmung: Ein Gültigkeitsbereichsfehler (domain error) tritt auf, wenn eine bestimmte Eingabe von Daten den Ablauf eines falschen Pfades aufgrund eines Fehlers im Steuerfluß eines Programms verursacht. Auch dies kann als Basis für die Definition von Testfällen benutzt werden. (vgl. White, L., Cohen, E. : A Domain Strategy for Computer Program Testing, IEEE Trans. On Software Eng., 1980.

111 Fehlererwartung (Error Guessing)
„Manche Menschen besitzen eine natürliche Begabung zum Programmtesten. Ohne Verwendung einer speziellen Methode scheinen sie über eine Spürnase zum Entdecken von Fehlern zu verfügen.“ G. J. Myers, Methodisches Testen von Programmen, Oldenbourg 1995 Menschen mit dieser natürlichen Spürnase praktizieren - meist unbewußt -die Technik des Testfallentwurfs, die man Fehlererwartung nennt. Sie vermuten auf Grund ihrer Erfahrung und Intuition, bestimmte wahrscheinliche Fehlerarten in einem Programm und entwerfen dann Testfälle, um diese Fehler aufzuzeigen. Typische mögliche Fehlersituationen sind z. B. die folgenden: Das Auftreten einer 0 in einer Ein- oder Ausgabeliste Bei variabler Anzahl der Ein- oder Ausgabefälle die Fälle „kein“ oder „ein“ Vergessene Punkte in der Spezifikation (z. B. weil der Designer sie für offensichtlich hielt) Generell alle Spezialfälle

112 Strategie des Testfallentwurfs
Beginnen mit dem Ursache-Wirkungsgraphen (Wenn die Spezifikation Kombinationen von Eingabebedingungen enthält) Grenzwertanalyse anwenden Äquivalenzklassen für Ein- und Ausgabe festlegen und Testfälle ergänzen, wenn nötig Fehlererwartungstechnik anwenden, um weitere Testfälle hinzuzufügen Programmlogik untersuchen, wie weit deren Test erfüllt ist. Ggf. Testfälle zur Überdeckung hinzufügen Vgl. Myers Die auf den vorangehenden Folien kurz angesprochenen Methoden zum Testfallentwurf kann man zu einer gemeinsamen Strategie kombinieren. Jede Methode trägt einige nützliche Testfälle bei, aber keine kann allein eine Menge vollkommener Testfälle liefern. Aber auch die Anwendung dieser Strategie liefert keine Garantie dafür, daß alle Fehler entdeckt werden, aber sie stellt einen vernünftigen Kompromiß dar. Ihre Anwendung stellt außerdem ein beträchtliches Stück Arbeit dar, aber niemand hat behauptet, daß Testen leicht sei.

113 Modultest: Inkrementelles vs. nicht-inkrementelles Testen
Testen: Big Bang Inkrementelles Testen 1. 4. 2. 1. 3. 4. 5. 5. 2. 6. Vgl. Myers: „Bei der Durchführung des Modultests (analoge Aussagen gelten für den Integrationstest) gibt es zwei entscheidende Gesichtspunkte: den Entwurf einer Menge von effizienten Testfällen und die Art, wie die Module zusammengesetzt werden, um ein funktionierendes Programm zu erhalten. Der zweite Punkt ist wichtig, weil er die folgenden Themen beeinflußt: die Definition der Modultestfälle, die verwendeten Testwerkzeuge, die Reihenfolge, in der die Module kodiert und getestet werden, die Kosten für die Erstellung von Testfällen und die Kosten für die Fehlerbehebung.“ Nicht-inkrementelles Testen: Zunächst wird jedes Modul einzeln getestet. Dazu müssen spezielle Treibermodule sowie sog. STUB-Module („Stumpf“) erstellt werden, die Funktionen der nicht vorhandenen Module simulieren. Nach dem vollständigen Test aller Module werden diese zum Programm zusammengebunden. Inkrementelles Testen: Die Module werden nicht separat getestet, sondern man kombiniert das nächste, noch nicht getestete Modul mit dem anderen, bereits getesteten Modul. Generelle Aussagen: Inkrementelles Testen erfordert weniger Arbeit (weniger Treiber und Stubs) Schnittstellenfehler werden durch inkrementelles Testen früher entdeckt Die Fehlerbehebung ist beim inkrementellen Testen leichter Inkrementelles Testen ist strenger, da bereits getestet Programme die Rolle von Treibern und Stubs übernehmen Inkrementelles Testen verbraucht mehr Maschinenzeit Nicht-inkrementelles Testen erlaubt mehr Parallelarbeit Fazit: Inkrementelles Testen ist i. a. vorzuziehen. 7. 6. 3.

114 Inkrementelles Testen: Top Down vs. Bottom Up
Zwischenschritt beim Top Down Test Zwischenschritt beim Bottom Up Test Treiber 1 STUB 1 Vgl. Myers: Die Top Down Strategie beginnt mit dem Modul an der Spitze oder der Hauptroutine des Programms. Danach werden schrittweise weitere Module integriert. Simulierte Ein-/Ausgen und Testfälle müssen von den STUBS bereit gestellt werden. Die Bottom Up Methode beginnt mit den Modulen der untersten Kategorie, d.h. die keine anderen mehr aufrufen. Danach werden schrittweise übergeordnete Module hinzu gefügt. Generelle Regel: alle untergeordneten Module müssen schon getestet sein, bevor das darüber liegende (rufende) Modul getestet werden kann.Ein-/Ausgaben sowie Testfälle werden von Treibermodulen zur Verfügung gestellt. Vergleich: Man kann nicht generell sagen, welche Methode die bessere ist, da beide Vor- und Nachteile haben, z. B.: Z. B. aus Sicht des Bottom Up Tests: Vorteile: Vorteilhaft, wenn größere Mängel bei den untergeordneten Modulen auftreten Testbedingungen sind leichter zu erzeugen Überprüfen der Testergebnisse ist leichter Nachteile: Treibermodule müssen erzeugt werden Das Programm als Ganzes existiert nicht, bevor nicht das letzte Modul dazugebunden wurde STUB 2

115 Integrations-/Funktionstest
Vgl. Myers: „Man kann sagen, daß nach dem Modultest eines Programms der Testprozeß gerade erst beginnt, besonders, wenn das Programm als Produkt verkauft werden soll oder sehr umfangreich ist. Ein Grund dafür ist die folgende Definition eines Softwarefehlers: Ein Softwarefehler ist vorhanden, wenn das Programm nicht das tut, was der Benutzer vernünftigerweise von ihm erwartet. Auch wenn offensichtlich ein perfekter Modultest durchgeführt werden könnte, gäbe das in keiner Weise eine Garantie dafür, daß man alle Softwarefehler gemäß dieser Definition gefunden hätte. Es ergibt sich daher die Notwendigkeit für eine weitere Testart.“ Myers nennt die folgenden Test „Higher Order Testing“ Die ersten beiden dieser Tests sind der sog Integrations- und Funktionstest. Da Integrationstest im Prinzip dasselbe ist wie Modultest (nur auf einer höhe-ren) Ebene, gelten die entsprechenden Aussagen über Inkrementelles vs. Nicht-Inkrementelles Testen sowie über Top Down und Bottom Up Strategien. Im Funktionstest versucht man, Unstimmigkeiten zwischen den Programmen und ihrer externen Spezifikation aufzudecken. Funktionstests sind gewöhnlich black-box orientiert. Im Gegensatz zum Modultest, der oft vom Entwickler selbst und eher informell durchgeführt wird, sind Integrations- und Funktionstest Aufgabe des Testteams, d.h. von professionellen Testen. Sie müssen systematisch und formal durchgeführt werden. Basis stellen spezielle Testfälle dar, die vorhersagbare Ergebnisse erzeugen sollen. Tests werden systematisch geplant (ggf. werden Testscripts erstellt bei Benutzung eines Werkzeugs, s. dazu später) und genaue Aufzeichnungen (Testlogs) werden geführt.

116 System-/Akzeptanztest
Leistungsbeschreibung der Programme System-/Akzeptanz test Benutzer- dokumentation Vgl. Mosley: Der System-/Akzeptanztest dient dazu, zu beweisen, daß das fertige System die Zioele bzw. Anforderungen in einer simulierten bzw. echten Produktionsumgebung erfüllt. Mosley unterscheidet drei Arten von „Systems Test“: Systemverikationstest, Anwenderverifikationstest und Anwendervalidierungstest. Die ersten beiden Tests dienen dazu, zu beweisen, daß das System die Designziele erfüllt. Sie sind ihrer Natur nach destruktiv und versuchen, Bereiche zu finden, wo das System nicht das tut, was es soll, damit diese korrigiert werden können. Der dritte Test hat das Ziel, das System zu validieren und is t seiner Natur nach ein positiver (vertrauensbildender) Test, mit Hilfe dessen demonstriert werden soll, wie das System die Anforderungen erfüllt. Die Schlüsselworte hier sind „verifizieren“ und „validieren“. Testen ist ein Verifikationsprozeß, wenn er in einer Nicht-Produktionsumgebung mit nicht echten Daten stattfindet. Das ist genau das, was wir üblicherweise unter Systemtest verstehen. Dies kann einmal durch die EDV geschehen und dann durch den Anwender wiederholt werden. Validierung bedeutet, das etwas tatsächlich so arbeitet wie es soll. Wenn das so ist, erfüllt das getestete Produkt die Anforderungen. Der Zweck des Anwender-Akzeptanztests ist zu zeigen, daß das System funktioniert. Der einzige Weg, um zu zeigen, daß ein Produkt funktioniert, besteht darin, es in der Realität mit echten Daten auszuprobieren. Programme E/A Spezifikation

117 Sollte man Tests automatisieren? - Ja!
Automatisiertes Testen reduziert Testfehler Automatisiertes Testen reduziert den Einfluss individueller Unterschiede Automatisiertes Testen konserviert Wissen, das sonst nur im Gehirn des Testers vorhanden ist Automatisiertes Testen reduziert die Zufälligkeit der Testfälle Automatisiertes Testen reduziert die Personalkosten Automatisiertes Testen reduziert die „Bottleneck“ Funktion des Testens Quelle: Test Rx TM, Daniel J. Mosley Testfehler: Menschen machen Fehler. Testen ist eine komplexe Aufgabe. Je komplexer die Aufgabe ist, desto leichter machen wir Fehler. Automatisiertes Testen beseitigt die menschliche Komponente. Außerdem können die Tests im Laufe der Zeit immer weiter perfektioniert werden. Individuelle Unterschiede: Jeder Tester ist eine einzigartige Persönlichkeit und führt deshalb seine Tests in einer bestimmten Art und Weise aus. Das kann gut oder schlecht sein. Wissen konservieren: Tester sind ebenso mobil wie Entwickler und arbeiten in der Regel während ihres Berufslebens für mehrere Firmen. Das bedeutet, sie nehmen ihr Wissen mit, wenn es nicht in einer Testdatenbank gespeichert ist. Zufälligkeit der Testfälle: Manuelle Testfälle werden oft eher zufällig entwickelt und ausgeführt - selbst dann, wenn das Testen sorgfältig geplant wurde. Automatisierende Testwerkzeuge zwingen zu Systematik. Personalkosten: Automatisches Erzeugen, Ausführen und Analysieren von Testfällen kann ganz erheblich die Personalkosten reduzieren. Obwohl anfangs ein höherer Aufwand bei Einsatz des Werkzeugs auftritt, kann der Gesamtaufwand während der Lebenszeit des Systems um 50% reduziert werden. Bottleneck: Testen ist ein großes Bottleneck in vielen Projekten. Automatisiertes Testen reduziert das Bottleneck, denn es erlaubt das Testen sowie der Code geschrieben ist. Es reduziert auch die Tendenz des Entwicklers, auf Qualität zugunsten der Produktivität zu verzichten.

118 Sollte man Tests automatisieren? Vielleicht! - ein Szenario
Automatisierungswerkzeuge sind vorhanden Tests können voll-, teil- oder gar nicht automatisiert werden Sowohl automatisiertes wie manuelles Testen sind grundsätzlich möglich Das Unternehmen verlangt nicht unbedingt die Automatisierung Der Test wird zunächst designed und dann die Entscheidung gefällt Man hat nur eine bestimmte Zeit zum Testen Quelle: Brian Marick: „When should a Test be automated“?, 1998 Testing Foundations Um die Argumente nicht zu sehr zu verallgemeinern und damit zu verwässern, wurde ein bestimmtes Szenario angenommen, in dem über jeden Testfall entschieden ´werden soll. Wenn keine Werkzeuge vorhanden sind, brauchen wir nicht weiter zu überlegen. Es ist wichtig, die Faktoren zu verstehen, die einen Test in die eine oder andere Richtung lenken. Für einen Lasttest mit einigen hundert Anwendern ist ein manueller Test z. B. nicht vernünftig. Wenn das Unternehmen Automatisierung verlangt, brauchen wir nicht weiter zu diskutieren. Die Anforderungen der Automatisierung beeinflussen die Testdesign oft. Hier muß man aufpassen, das man keine faulen Kompromisse macht, nur, um zu automatisieren. Begrenzt ist die Zeit immer. Man muß sie auf bestmögliche Art nutzen. Das kann bedeuten,m auf das Automatisieren zu verzichten.

119 Sollte man Tests automatisieren? - drei entscheidende Fragen
Automatisieren und einmalige Ausführung eines Tests wird i. d. R. mehr kosten als ihn manuell durchzuführen. Wieviel mehr? Ein automatisierter Test hat eine begrenzte Lebenszeit, in der er seine Kosten wieder einspielen muss. Wird dieser Test früher oder später sterben? Welche Ereignisse werden seinen Tod wahrscheinlich beeinflussen? Wie wahrscheinlich ist es, dass dieser Test während seines Lebens neue Fehler findet? Wie verhält sich dieser unsichere Nutzen gegenüber den Automatisierungskosten? Einen automatisierten Test zu entwickeln dauert normalerweise länger und kostet deshalb mehr. Die Zusatzkosten können sehr unterschiedlich sein. Wenn man z. B. Testscipts (einfache Programme zur Testautomatisierung) manuell schreibt, kann es wesentlich teurer werden. Wenn man ein Capture-Replay Werkzeug benutzt, können die Kosten nur marginal größer sein. Doch auch nur 10% höhere Kosten bedeuten, daß man bei 10 automatisierten Testfällen eine manuellen nicht durchführen kann. Welche Fehler hätte dieser gefunden? Wie schwerwiegend währen sie gewesen? Je nachdem wie stark der Code während der Wartungsphase verändert wird, wird die Lebenszeit eines automatisierten Tests kürzer oder länger sein. Anpassen eines Tests kostet meist ebenso viel wie ihn neu zu schreiben. Automatisierte Test beweisen ihren Wert in der Regel erst dann, wenn der Code verändert wurde (Ausnahme sind z. B. Lasttests). Sonst wird er genau dieselben Fehler noch einmal finden, was niemandem etwas bringt. Fehler werden also oft erst im nächsten Release gefunden, was den Nutzen hinausschiebt.

120 Anforderungen an eine ideale Test Umgebung
Eine ideale Testumgebung sollte (nach Mosley): sowohl Mainframe als auch Client/Server Entwicklungsumgebungen unterstützen das Testen von Desk Top und Web Top Client/Server Anwendungen unterstützen von einem Anbieter kommen, der groß genug ist, um im Markt zu bleiben erweiterbar sein, wenn neue Testanforderungen auftreten automatisches Testmanagement, automatische Testausführung, automatisches Aufzeichnen der Ergebnisse, automatische Verfolgung von Fehlern und Berichterstattung über Probleme sowie automatische Erstellung von Ergebnisberichten können sollte Tests von Schnittstellen von Mainframe, Client/Server Desk Top und Client/Server Web Top erlauben sollte Funktionstests in diesen Umgebungen unterstützen sollte Anwenderakzeptanztests in diesen Umgebungen unterstützen sollte Regressionstests in diesen Umgebungen unterstützen sollte es erlauben, dass Tests auf dem PC designed werden, aber auch dem Mainframe, dem Client/Server Desk Top oder dem Client/Server Web Top ausgeführt werden Preisfrage: Gibt es eine solche Testumgebung??? Nein, noch nicht. Deswegen muß sich jeder potentielle Käufer überlegen, auf welche Eigenschaften er am ehesten verzichten kann und welche für ihn absolut notwendig sind. Diese Überlegungen müssen grundsätzlich vor einer intensiven Beschäftigung mit Testwerkzeugen angestellt werden, damit sie nicht durch das geschulte Verkaufspersonal der Testwerkzeuganbieter und durch die Fähigkeiten angebotener Werkzeuge verwässert werden. In vielen Fällen wird es auch erforderlich sein, mehrere Testumgebungen einzuführen, um ausreichend viele Kriterien abdecken zu können. Das hat dann natürlich höhere Kosten, höheren Schulungsaufwand und mehr Personal zur Folge, da man Mitarbeitern nicht zumuten kann, überall Spezialisten zu sein.

121 Einführung neuer Technologien
Institutionalisierung Einführung Probelauf Engagement des Unternehmens Auswertung Verständnis Generell folgt die Auswahl und Einführung neuer Praktiken, Prozesse oder Technologien einem bestimmten Schema. Zwischen dem Erstkontakt und dem Zeitpunkt des Routineeinsatzes sind eine Reihe von Aktivitäten auszuführen, wie es hier durch die Kurve von Conner und Patterson wird. Abkürzungen sind leider nicht möglich, da hierunter die Akzeptanz ganz erheblich leiden würde. Nach dem Erstkontakt mit einem neuen Prozeß bzw. einer neuen Technologie beschäftigen sich potentielle Anwender damit und erhöhen so ihr Bewußtsein hinsichtlich der Verwendbarkeit, des Reifegrades und der Anwendungsgebiete. Wenn der Prozeß bzw. die Technologie vielversprechend zu sein scheinen, versuchen die Anwender die Stärken und Schwächen sowie die Kosten und Anwendungsbereiche besser zu verstehen. Diese ersten Aktivitäten können eine ganze Zeit dauern. Vielversprechende Prozesse bzw. Technologien werden dann im Detail ausgewertet und mit anderen verglichen. Um das Risiko zu minimieren, wird dann üblicherweise der neue Prozeß bzw. die neue Technolgie versuchsweise in einem oder mehreren Pilotprojekten eingesetzt. Bei erfolgreichem Ausgang folgt dann die Einführung. Mit steigender Erfahrung wird er bzw. sie dann verfeinert und wird ein essentieller Teil im täglichen Arbeitsprozess der Organisation Bewußtsein Erstkontakt Zeit Quelle: Conner, Daryl R. et al., “Building Commitment to Organizational Change” Training and Development Journal, Vol 36 No 4, April 1982

122 Empfehlungen für den Auswahlprozess
Anforderungen an Testwerkzeuge in maximal 5 Tagen definieren Funktionalität von Testwerkzeugen untersuchen und Prioritäten für die gewünschten Charakteristiken festlegen in maximal 10 Tagen durchführen Nicht mehr als 5 Tage für Demonstrationen von Werkzeugen verwenden Nicht mehr als 30 Tage für eine Probeinstallation verwenden Eine Langfristige Vision für den Einsatz von automatisierenden Werkzeugen entwickeln. Die Vision sollte folgendes enthalten: Die Software-Entwicklungsmethode, die implementiert ist bzw. implementiert werden sollte Den Software-Testprozess, der implementiert ist bzw. werden implementiert soll Die zukünftige Computerumgebung des Unternehmens (% Mainframe vs. Client/Server , % Desk Top vs. Web Top) Die Automatisierung möglichst aller Aktivitäten von Test Rx TM Die Automatisierung des Testprozesses sollte Teil einer Initiative sein, den gesamten Entwicklungsprozess zu automatisieren Was Mosley hier fordert, ist sicherlich richtig und niemand wird dem wohl widersprechen. Die Durchführung verlangt allerdings einen strategischen Ansatz, der in den Problemen des Alltagsgeschäfts nur allzu oft unter die Räder kommt. Deshalb die Empfehlungen, die Auswahl kurz und knackig durchzuführen, damit man sich nicht in endlosen Debatten und Richtungskömpfen über einzelne Werkzeuge ergeht sondern zu Lösungen kommt. Eine besondere Wichtigkeit kommt hierbei m. E. den letzten beiden Punkten zu. Die Ausgestaltung des Entwickklungs- und Qualitätssicherungsprozesses im Ganzen hat einen wesentlichen Einfluß auf Art und Umfang der durchzuführenden Tests und damit auf die unterstützenden Werkzeuge (s. folgende Folien).

123 Gefundene Fehler und Automatisierungsgrad
1.00 0.75 Niedriger Automationsgrad Hoher Automationsgrad 0.50 Anzahl der Fehler 0.25 Quelle: Systematisches Software-Testen, T. Henkes, Synspace Die Graphik sagt folgendes aus: 1. Je höher der Automatisierungsgrad des Testens ist, desto schneller findet man Fehler 2. Je höher der Automatisierungsgrad des Testens ist, desto mehr Fehler findet man 3. Leider findet man nicht alle Fehler - jedenfalls nicht während der Testphase Es ist also sinnvoll, möglichst den ganzen Testprozeß automatisieren zu wollen, wenn man sich schon einmal dafür entschieden hat. 0.00 0.0 0.5 1.0 1.5 2.0 Zeit (Beliebige Einheit)

124 Gefundene Fehler und Qualität des Entwicklungsprozesses
1,00 Mittlere Qualität 0,75 Gute Qualität Schlechte Qualität Anzahl der Fehler (Normiert) 0,50 0,25 Quelle: Systematisches Software Testen T. Henkes, Synspace AG Die Graphik sagt folgendes aus: 1. Je höher die Qualität des Software-Entwicklungsprozesses ist (Messung über Bootstrap, CMM, SPICE etc.), desto schneller findet man Fehler 2. Je höher die Qualität des Software-Entwicklungsprozesses ist, desto mehr Fehler findet man in einer bestimmten Zeiteinheit 3. Leider findet man nicht alle Fehler - zumindest nicht während des Testprozesses Automatisierung des Testens steht also nicht allein sondern hängt ab von der Qualität und Reife des Entwicklungsprozesses. 0,00 0,0 0,5 1,0 1,5 2,0 Zeit (Beliebige Einheit)

125 Testwerkzeuge: Anforderungs-spezifikation und Design
Analysewerkzeuge für Pläne, Anforderungen und Designs Systemsimulatoren und Prototype Werkzeuge Anforderungsverfolgungswerkzeuge Anforderungsbasierte Testdaten-Generatoren Testplanungswerkzeuge Quelle STSC: Es ist inzwischen weitgehend anerkannt, daß Testen bereits in den Phasen ‚Spezifikation der Anforderungen‘ und ‚Design‘ durchgeführt werden sollte. Anforderungs- und Designinformationen sind eine erstrangige Quelle, um die Anforderungen an den Test des Systems festzulegen und Testpläne aufzustellen. Das STSC definiert das so: Testen ist keine Phase im Lebenszyklus, Testen ist die Endaktivität jeder Phase. Deshalb werden im Rahmen des Begriffs Testwerkzeuge auch solche betrachtet, die üblicherweise anders genannt werden. Anforderungsanalyse und Design sind die Domäne der sog. Upper Case Tools, um die es hier vorwiegend geht. Analysewerkzeuge evaluieren die Spezifikationen für Konsistenz, Vollständigkeit und Einhaltung von Standards. Derartige Werkzeuge wurden vom STSC im Requirements Engineering and Design Technology Report, Grotzky, John et. Al. untersucht. Systemsimulatoren und Prototype Werkzeuge verbinden Anforderungs-spezikation, Design und Testen. Die Anforderungen werden definiert und laufend verbessert durch unmittelbares Feadback über Analyse und Designentscheidungen. Anforderungsverfolgungswerkzeuge können die Arbeit, die Anforderungen über Design, Codieren und Testfälle hinweg zu verfolgen, in großen Projekten erheblich vereinfachen und automatisieren. Derartige Werkzeuge wurden vom STSC 1995 untersucht - s.o. Anforderungsbasierte Testdaten-Generatoren erstellen automatisch Testfälle zur Überprüfung der Anforderungen (diese müssen allerdings in einer formalen Sprache geschrieben sein). Testplanungswerkzeuge helfen den Entwicklern bei Definition und Planung von Tests.

126 Testwerkzeuge: Implementierung und Wartung
Compiler Statische Quellcode Analysatoren Audit Werkzeuge Komplexitätsgrad-Messwerkzeuge Cross Reference Werkzeuge Größenmewerkzeuge Werkzeuge zur Strukturüberprüfung Syntax und Semantik Analysatoren £ 20 Compiler werden üblicherweise nicht zu den Testwerkzeugen gerechnet, obwohl der Test von Quellcode eine ihrer wesentlichen Aufgaben ist. Statische Quellcode Analysatoren analysieren den Quellcode, ohne ihn auszuführen: Audit Werkzeuge analysieren Einhaltung von Regeln und Standards (z. B. Einhaltung der strukturierten Programmierung) Komplexitätsgrad-Meßwerkzeuge berechnen Metriken, die etwas über die Komplexität (und damit Anfälligkeit für Fehler) von Programmen aussagen. Cross Reference Werkzeuge liefern Beziehungen zwischen verschiedenen Objekten (z. B. Anweisungsnummer, Datenname, Unterprogrammaufrufe). Größenmeßwerkzeuge zählen die Anzahl Anweisungen oder Function Points und geben Auskunft über die historische Entwicklung des Programms. Werkzeuge zur Strukturüberprüfung analysieren Anomalien der Struktur und stellen diese durch Text oder Graphik dar (z. B. gerichtete Graphen, Strukturdiagramme, Datenflußdiagramme, Aufrufbäume) Syntax und Semantik Analysatoren ergänzen den Compiler. Sie sind nicht für alle Programmiersprachen erforderlich. Ada z. B. kommt ohne aus. Fortran benötigt sie, um Typenkonflikte in Aufrufargumenten separat geschriebener Unterprogramme zu analysieren.

127 Testwerkzeuge: Implementierung und Wartung - Fortsetzung
Werkzeuge zur Testvorbereitung Datenextraktoren Anwendungsbasierte Testdatengeneratoren Testdatengeneratoren Testplanungswerkzeuge Quelle SCST: Datenextraktoren bauen Testdaten aus bestehenden Datenbanken oder Testfällen auf Anforderungsbasierte Testdaten-Generatoren erstellen automatisch Testfälle zur Überprüfung der Anforderungen (diese müssen allerdings in einer formalen Sprache geschrieben sein). Testdatengeneratoren bauen Testfälle auf, die passend für die Systemeingaben formatiert sind. Einige Generatoren bauen Zufalls-Testdaten auf. Testplanungswerkzeuge helfen den Entwicklern bei Definition und Planung von Tests.

128 Testwerkzeuge: Implementierung und Wartung - Fortsetzung
Testausführungswerkzeuge Capture-Replay Werkzeuge Deckungsgrad Analysatoren Debugger Emulatoren Netzanalyse Werkzeuge Performanzanalyse/Lasttest Werkzeuge Run-Time Fehlerprüfungswerkzeuge Simulatoren Testausführungsmanagement Werkzeuge Validierungswerkzeuge Capture-Replay Werkzeuge dokumentieren automatisch Testeingaben (Scripts) und spielen diese bei Folgetests (nach Veränderungen) wieder ab. Einige Werkzeuge können den Regressionstest voll automatisieren. Sie erhöhen die Produktivität erheblich. Deckungsgrad Analysatoren analysieren den Abdeckungsgrad von Anweisungen, Verzeigungen, Pfaden oder Modulen bei der Testausführung. Debugger dienen zur Lokalisierung von beim Testen gefundenen Fehlern. Zum Teil haben sie weitergehende Fähigkeiten wie z. B. Analyse des Abdeckungsgrads. Emulatoren können anstelle von nicht vorhandenen oder nicht verfügbaren Systremkomponenten eingesetzt werden (z. B. Terminalemulation). Netzanalyse Werkzeuge analysieren den Datenverkehr im Netz. Performanzanalyse/Lasttest Werkzeuge analysieren die Leistungsfähigkeit einer Software (Reaktionszeiten, Lasttest). Run-Time Fehlerprüfungswerkzeuge überprüfen z. B. den Speicherzugriff während der Programmausführung (z. B. Verwendung von Speicherplatz, der außerhalb des Programmbereichs liegt). Simulatoren ersetzen fehlende oder nicht verfügbare Systemkomponenten. Testausführungsmanagement Werkzeuge ist eine generelle Bezeichung für Testwerkzeuge, die verschiedene Funktionen beim Test automatisieren (z. B. Capture Replay, Dokumentation der Testergebnisse) Validierungswerkzeuge vergleichen Software gegen Standards (z. B. Ada Codierungsstandard ANSI/MIL-STD-1815A von 1983). Sie werden oft im Zusammenhang mit Compilern und Operatingsystemen benutzt.

129 Testwerkzeuge: Implementierung und Wartung - Fortsetzung
Werkzeuge zur Testauswertung Vergleichswerkzeuge Werkzeuge zur Datenreduktion und -analyse Werkzeuge zur Verfolgung von Fehlern/Veränderungen Vergleichswerkzeuge vergleichen Objekte miteinander nach einem Softwaretest und notieren die Unterschiede. Capture-Replay Werkzeuge enthalten oft eine dynamische Vergleichsmöglichkeit, die Objekte während des Tests der Software vergleicht. Werkzeuge zur Datenreduktion und -analyse setzen Daten in eine leichter zu interpretierende Form um. Meist lassen sich auch diverse statistische Analysen durchführen. Werkzeuge zur Verfolgung von Fehlern/Veränderungen dokumentieren Fehler und erstellen Fehlerreports. Sie sind oft in Konfiguationsmanagement werkzeuge integriert oder in Systementwicklungsumgebungen.

130 Konstruktive QS-Maßnahmen (Beispiel Airbus)
Vorgehensmodell Da es sich um die Einführung von Standardsoftware handelt, ist das Vorgehensmodell für Eigenentwicklung nicht geeignet. Deshalb wurde das Vorgehensmodell von Peoplesoft gewählt. Um möglichst sicher zu gehen, wurde dieses gegen das Vorgehensmodell von SAP abgeglichen. Eingesetzte Methoden und Werkzeuge Entwicklungssprache: INFO Testen: Mercury Testsuite Ablaufdokumentation: ARIS Textverarbeitung: MS Word Spreadsheet: MS Excel Projektmanagementsoftware: MS Project Graphik: MS-Powerpoint Ordnung halten im Projekt (Konfigurationsmanagement): Die Grundidee des Konfigurationsmanagements besteht darin, durch Disziplin und Systematik Ordnung zu halten. Regeln, wie dies für die Arbeitsergebnisse des Projekts zu geschehen hat, wurden im Document „Projektcontrolling und Qualitätssicherung im IV-Projekt – Überblick“ festgelegt. Regeln für die Versionsführung der einzelnen System-Komponenten werden von Teilprojekt „Basis“ erarbeitet. Projekt-Office: Zur Unterstützung der Projekt- bzw. Teilprojektleitung wurde ein Projekt-Office eingerichtet. Seine Aufgaben sind: Definition/Auswahl des Vorgehensmodells Unterstützung bei der Projektplanung und -controlling Qualitätsplanung und Qualitätssicherung Dokumentation des Projektablaufs in MS Projekt/Führung der Projektakte Erstellung von Präsentationsmaterial für externe Präsentationen Schulungsmaßnahmen: Überblick über die Peoplesoft-Software für die Mitglieder des Projekt-Office Schulung in „Structured Walk-Through“ für die Teammitglieder Schulung in „Inspektion“ für ausgewählte Teammitglieder Risikoanalyse: Um sicher zu gehen, dass alle notwendigen Vorkehrungen für den Projekterfolg getroffen wurden, wird eine Risiko-Analyse nach dem S:PRIME Verfahren vorgeschlagen.

131 Analytische QS-Maßnahmen
Analytische QS-Maßnahmen haben die Prüfung, Bewertung und den Nachweis der Qualität des Prüfgegenstandes zum ziel. Analytische Maßnahmen sind z. B. : Selbstprüfung = Prüfung eines Prüfobjekts durch den Ersteller Verifizierung = Prüfung eines Prüfobjekts durch einen Prüfer Prozessprüfung = Prüfung von Aktivitäten der Projektabwicklung Ergebnisprüfung = Prüfung eines Zwischen- oder Endergebnisses Test = Ausführung eines Programms mit der Absicht, Fehler zu finden Validierung = Überprüfung des fertigen Systems oder seiner Teile durch den Anwender bzw. Auftraggeber oder einen Experten, um festzustellen, ob es so funktioniert, wie erwartet diese Art der Prüfung findet nicht in Form von Reviews sondern im Rahmen des Akzeptanz- Tests statt)

132 Ausprägung der Prüfaktivitäten
Hier ist zu unterscheiden, ob eine Prüfung der Nachweisführung nach außen dient oder intern zur Feststellung des Bearbeitungsendes erfolgt. Die Prüfung am Bearbeitungsende ist eine Selbstprüfung. Hier ist vom Qualitätsbeauftragten festzulegen, welcher Art diese Selbstprüfung ist und welchen QS-Vorschriften sie genügen soll: Keine Vorgaben (außer Nachvollziehbarkeit), Dokumentation in freier Form Checklisten, Dokumentation gemäß Checkliste Genaue Spezifikation und Vorbereitung, Durchführung und Ausführung der Prüfung, Dokumentation gemäß Anforderungen an ein QS-Review bzw. an einen Modultest. Nach der Selbstprüfung wird das Arbeitsergebnis aus dem Status „in Bearbeit-ung“ in den Status „vorgelegt“ versetzt, der vom Ersteller selbst vergeben wird. Die (formelle) Prüfung wird nach den Regelungen der QS durchgeführt. Sie stellt eine auch für Außenstehende nachvollziehbare Nachweisführung dar, dass das Prüfobjekt die gestellten Anforderungen erfüllt. Das Prüfobjekt rückt nach erfolgreicher Nachweisführung in den Status „akzeptiert“ vor. Die Prüfung wird gemäß Prüfspezifikation und Prüfprozedur durchgeführt (vgl. Qualitätsplan).

133 Prüfobjekte und QS-Maßnahmen (Beispiel Airbus Ausschnitt)

134 Prüfplan - Inhalt (Beispiel Airbus)
Allgemeines zum Prüfplan Zielsetzung Reichweite Ergänzende Dokumente Geplante Prüfungen Teilprojekt Basis Teilprojekt Integration Paisy Teilprojekt Reporting Teilprojekt Berechtigungskonzept Abnahmegremium für Meilensteinabnahmen

135 Geplante Reviews - Beispiel
(I) = inhaltliche Prüfung (A) = Abgabetermin (F) = Formale Prüfung (R) = Reviewtermin

136 Zusammenwirken von Entwicklung und Qualitätssicherung

137 Kommunikationsplanung
Die Kommunikationsplanung ist die Voraussetzung dafür, dass die Projektbeteiligten die für sie relevanten Informationen rechtzeitig und zuverlässig erhalten (s. dazu Modul Projektberichtswesen). Die Kommunikationsplanung wird im Kommunikationsmanagementplan dokumentiert. Darin ist folgendes enthalten (PMBOK): Erfassungs- und Ablagesystem: welche Verfahren werden eingesetzt, um die Informationen zu sammeln und zu speichern. Verteiler: wer erhält welche Informationen in welcher Form. Beschreibung der Informationen: Format, Inhalt, Detaillierungsgrad. Termine: wann werden die verschiedenen Berichte erstellt. Verfahren für den Zugang zu Informationen zwischen den geplanten Berichten.

138 Informationsfluss-Matrix (Beispiel)
Als hilfreich hat sich die Informationsfluss-Matrix erwiesen, die die wichtigen Informationen über die Informationsstruktur übersichtlich darstellt. Wer an Wen? Projektleiter Projektteam Auftraggeber/ Lenkungsaus-schuss Projektbüro X Wöchentliche Projektsitzung Monatlicher Statusbericht Ist-Daten wöchentlich Keine Meldung Änderungs-anträge Anforderung von Budget/ Ressourcen, Änderungsanträge Entscheidung über Budget/ Ressourcen,

139 Ablauf der Projektdokumentation (Beispiel)
Der Mitarbeiter – TH32RX – erstellt ein Arbeitsergebnis und führt die Selbstprüfung durch. Der Teilprojektleiter überprüft das Arbeitsergebnis und stellt es in den Ordner ‚Neue Ergebnisse‘. Diese werden zu den geplanten Reviewterminen überprüft und bei Akzeptanz vom Qualitäts- beauftragten in den Ordner ‚Akzeptierte Ergebnisse‘ eingestellt. Der Qualitätsbeauftragte überführt die akzeptierten Ergebnisse in die Projektakte, auf die die ProjektMitarbeiter nur lesenden Zugriff haben.


Herunterladen ppt "Modul Projektplanung Literatur:"

Ähnliche Präsentationen


Google-Anzeigen