Wer schreibt, der bleibt! IT-Projektmanagement. Externe und interne IT-Projekte zum Erfolg führen! 2. April Rainer Bohnert

Transkript

1 Externe und interne IT-Projekte zum Erfolg führen! 2. April 2009 Rainer Bohnert

2 Agenda» Einführung: Was ist ein Projekt / Was ist Projektmanagement» Was sind IT-Projekte» Projektvorbereitung» Projektplanung» Projektdurchführung: Kommunikation Dokumentation Änderungsmanagement Qualitätsmanagement» Exkurs: Softwareauswahl / Auswahl von IT-Dienstleistern 2009, Rainer Bohnert 2

3 Vorstellung» Politikwissenschaft und Informationswissenschaft» 7 Jahre Erfahrung in und IT-Qualitätsmanagement» Projektplanung und durchführung, Projektberatung und evaluation» PMP (Project Management Professional) 2009, Rainer Bohnert 3

4 Was ist ein Projekt» Von Menschen ausgeführt» Hat nur begrenzte Ressourcen» Wird geplant, ausgeführt und kontrolliert» Besitzt eine gewisse Komplexität» Zeitlich begrenzt» Einzigartig in Bezug auf das Endergebnis» In Schritten zunehmende Konkretisierung des Ergebnisses (Der Umfang des Projektes bleibt gleich, das Ergebnis wird erst im Projektverlauf definiert) 2009, Rainer Bohnert 4

5 Was ist Projektmanagement» Die Anwendung von Wissen, Fertigkeiten, Werkzeugen und Methoden in den einzelnen Projektaktivitäten, um die Anforderungen, die an ein Projekt gestellt werden, zu befriedigen 2009, Rainer Bohnert 5

6 Das magische Dreieck Qualität Kosten / Aufwand Zeit 2009, Rainer Bohnert 6

7 Wann ist ein Projekt erfolgreich? Die vom Auftraggeber gewünschte Leistung wird:» Innerhalb des vorgegebenen Zeitrahmens» Im vorgesehenen Budget» In der geforderten Qualität erbracht 2009, Rainer Bohnert 7

8 Kritische Erfolgsfaktoren» Klare Projektziele» Klare Prozesse im Projektmanagement:» Laufendes Projektcontrolling» Klare Kompetenzen, eindeutige Verantwortlichkeiten» Engagierter Projektsponsor» Einsatz geeigneter Methoden und Hilfsmittel» Geeignete Projektorganisation» Qualifikation der Mitarbeiter» Führungsstil der Projektleiter» Informationsfluss zu allen Betroffenen 2009, Rainer Bohnert 8

9 IT-Projekte

10 Elemente von IT-Projekten 2009, Rainer Bohnert 10

11 Anforderungsanalyse und fachliche Konzeption» Anforderungen (funktional und nichtfunktional) Wer schreibt, der bleibt!» Fachliche Beschreibung der Lösung» Prozesse» Use Cases (durch Software unterstützte Prozess-Schritte)» Fachliches Datenmodell» Fachlicher Systemüberblick innen und außen» Fachliche Architektur» Anforderungen unbedingt schriftlich festhalten» Anforderungen unbedingt schriftlich fortschreiben 2009, Rainer Bohnert 11

12 Technische Konzeption» Technischer Systemüberblick innen und außen» Software-Architektur (Module, Schichten, Komponenten, etc.)» Technisches Datenmodell» Systemarchitektur (Hardware)» Betriebsdokumentation» Vorlage für die Implementierung, Design für Implementierung 2009, Rainer Bohnert 12

13 Realisierung» Inhalte der Realisierung: Programmieren Testen (Entwicklertest) Dokumentieren» Ergebnisse Code Dokumentation 2009, Rainer Bohnert 13

14 Integration und Test» Ergebnis: Fertiges System» Inhalte von Integration & Test Systemintegration: Kopplung mit Nachbarsystemen, Zusammenführen einzelner Module, System ist als Ganzes vollständig. Systemtest (gesamt, funktional): Fachliche Tester testen das System so, wie es später im Produktionsbetrieb genutzt werden soll. 2009, Rainer Bohnert 14

15 Wasserfallmodell Aufwand Definition Lastenheft Entwicklung Umsetzung Risiko Test Evaluation Zeit 2009, Rainer Bohnert 15

16 Änderung der Anforderungen beim Wasserfallmodell» Abblocken Wer schreibt, der bleibt!» Schneller im Projekt sein. Dadurch gibt es weniger Zeit für Änderungen in den Anforderungen» Änderung annehmen und in die Software einbauen (Kosten!) 2009, Rainer Bohnert 16

17 Iterative (Software) Entwicklung Wasserfallmodell Definition Lastenheft Entwicklung Umsetzung Test Evaluation time vs Definition Lastenheft Entwicklung Umsetzung Test Evaluation Entwicklung in immerwiederkehrenden Zyklen Definition Lastenheft Entwicklung Umsetzung Test Evaluation Definition Lastenheft Entwicklung Umsetzung Test Evaluation 2009, Rainer Bohnert 17

18 Vor- und Nachteile Wasserfall» Hohe Sicherheit für Software- Anbieter» Gesamtblick (aber: zu viele Details)» Große Mengen an Konzeption» Geringere Flexibilität» Nutzen erst bei Einführung» Deckel drauf bekommen» Übersichtliche Struktur» Entspricht Denkweise: Geld für definierte Leistung Iterativ» Früher Nutzen für Kunden» Besseres, qualifizierteres Feedback» Kosten für Übergangslösungen» Schwieriger zu managen» Geringeres Einführungsrisiko 2009, Rainer Bohnert 18

19 Projektvorbereitung

20 Der Projektverlauf in der Übersicht 2009, Rainer Bohnert 20

21 Die Vorstudie» Ein Business Case legt wesentliche Punkte eines Projekts grob fest: Kosten Ziel (Leistungsumfang) Zeitrahmen (ROI)» Eine Studie im Vorfeld gibt es z. B. in folgenden Fällen bei größeren Vorhaben wenn die Aufgabenstellung noch nicht ganz klar ist wenn genauer nachvollzogen werden soll, ob sich die Investition lohnt.» Eine Studie dient dem Nachweis von Machbarkeit und Nutzen eines Software-Projekts. Sie legt in der Regel fest: Die wichtigsten Anforderungen an eine Software Eine grobe Skizze der technischen Realisierung 2009, Rainer Bohnert 21

22 Der Projektauftrag» Das neue Projektmanagement kommt ins Spiel: ein Auftrag für das Projekt wird erteilt» Im Projekt wird der Projektauftrag vervollständigt bzw. geschrieben um Ziele und Aufgabenstellung für das Projekt glasklar festlegen» Ein Auftrag muss schriftlich fixiert sein» Verbindlichkeit schaffen: der Auftraggeber unterschreibt den Auftrag. 2009, Rainer Bohnert 22

23 Projektinitialisierung» Das Kernteam MUSS besetzt sein!» Ziele klären» Qualitätskriterien klären / Qualitätssicherungsplan beginnen -> im Verlauf konkretisieren» Organisation des Projekts festlegen, incl. Ansprechpartner des Auftraggebers» Projektstruktur festlegen (Projektstrukturplan)» Schätzung validieren» Planung: Grobplanung, Feinplanung für die ersten Schritte» Infrastruktur etablieren» Struktur für das Controlling aufsetzen» Im Projekthandbuch festhalten. 2009, Rainer Bohnert 23

24 Festgelegte Projektorganisation Kunde :Hr. H Lenkungskreis Auftraggeber: Fr. S, Hr. W QS Kunde PL Kunde PL Auftraggeber PM / QA Dr. K Hr. P Hr. B Hr. S Hr. B Projektteam Kunde Projektteam Auftraggeber Projektleitung Herr K Herr K Herr E Herr B Herr T Fr. K Hr. W Hr. S Hr. J Kommunikation Die Kommunikation läuft über Herrn P, Herrn B Die Projektleiter / Projektmanagement berichtet und eskaliert an den Lenkungskreis 2009, Rainer Bohnert 24

25 Projektinitialisierung I» Projektinfrastruktur» Räume, Arbeitsmittel (Rechner, Drucker, Telefone, Videokonferenz ).» Software-Umgebungen (Entwicklung, Test, Qualitätssicherung)» Projektlaufwerk / Projektablage» Office-Tools, Druckstückerzeugung/PDF, Konfigurations-Management, Softwarewerkzeuge» Kommunikationstools wie Wiki, BSCW, Verteiler, etc.» Nutzungskonzepte für die Tools: Ein Tool allein reicht oft nicht, es muss auch festgelegt sein, wie es im Projekt eingesetzt werden soll.» Namenskonventionen: Namensgebung von Ordnern und Dateien. 2009, Rainer Bohnert 25

26 Projektinitialisierung II» Projekthandbuch» Projektinhalt Ggf. Vorgeschichte, übergeordnetes Ziel, Business Case Kurze Darstellung des Projektinhalt Referenz auf Auftrag bzw. Vertrag und Angebot Ergebnisse, ggf. detaillierter als im Angebot Kriterien des Auftraggebers für Qualität/Zufriedenheit Kriterien des Teams für Zufriedenheit Projektstrukturplan» Risiken Referenz auf die Projektablage Vorgehen zum Risikomanagement (z. B. Führen einer Risikoliste mit regelmäßiger Aktualisierung) 2009, Rainer Bohnert 26

27 Projektinitialisierung III» Projektorganisation Organigramm Eskalationswege Aufgabenverteilung: wer hat welchen Hut auf? AKV Aufgaben, Kompetenzen, Verantwortlichkeiten Teamliste, Erreichbarkeiten ( , Telefon, Handy) Regelmäßige Meeting-Termine 2009, Rainer Bohnert 27

28 Kick-Off I» Ziele des Kick-Offs Bewussten Startpunkt für die Projektarbeit setzen: Jetzt geht s los! Das Team auf ein gemeinsames Ziel einschwören. Das gesamte Team kennen lernen / Teambuilding Team über die wichtigsten Inhalte der Projektinitialisierung informieren, auf Stand zum Arbeiten bringen. 2009, Rainer Bohnert 28

29 Kick-Off II» Inhalte des Kick-Offs Projektziele, Inhalt des Projektauftrags Projektstruktur Projektvorgehen und Planung kommunizieren: wichtige Meilensteine Wichtige Standards festlegen Verantwortlichkeiten, Rollen kommunizieren, Organigramm Verhaltens- und Kommunikationsregeln des Teams, ggf. erarbeiten. 2009, Rainer Bohnert 29

30 Projektplanung

31 Warum planen?» Auch ein falscher Plan ist besser als kein Plan!» Alternative: totaler Blindflug» Ein Plan zeigt einen Weg, wie man das Ziel erreichen kann. Er weist die Machbarkeit nach.» Ein Plan ist die Grundlage, um ein Projekt zu steuern Ohne Steuerung und Plan erkennt man erst zu Projektende, ob sich der Projekterfolg einstellt Mit Steuerung: Gefährdungen sind früh erkennbar, man kann auf darauf reagieren» Ein Plan wird im Projektverlauf ständig besser und erhöht die Sicherheit, das Projekt zum Erfolg zu führen. 2009, Rainer Bohnert 31

32 Grobplanung» Bekannte Meilensteine» Genauigkeit: Wochen/Monate» Ausgangspunkt: Werte aus Schätzung» Vorgegeben: Software-Engineering Vorgehensmodell 2009, Rainer Bohnert 32

33 Grobplanung» Verteilen der geschätzten Aufwände auf die Planelemente:» Tipp: Falls nicht in der Schätzung ausgewiesen, können die Aufwände über einen Verteilungsschlüssel (vgl. Schätzung) errechnet werden. 2009, Rainer Bohnert 33

34 Grobplanung April Mai Juni Juli August Testplanung Testdatendefinition Testfalldefinition Testdatenbeschaffung Durchführung erste Lasttests Verfügbarkeit Testsystem Inbetriebnahme Testsystem Testzyklen 1 Verfügb. int. Testsystem Testzyklen 2 Verfügb. Produktivsystem Bereitstellung zur Abnahme Abnahme Planung / Überwachung , Rainer Bohnert 34

35 Grobplanung» Aus einzelnen Dauern der Planelemente» Danach: Wiederholte Durchführung der Planung, bis die Planung zufriedenstellend ist: Projektinhalte schieben Teamgröße verändern Meilensteine schieben Crashing / Parallelisierung» Niemals geschätzte Aufwände ändern! 2009, Rainer Bohnert 35

36 Feinplanung» WER macht WANN WAS?» Im Plan finden sich: Arbeitspakete und Aktivitäten Meilensteine Zuordnung zu Personen und Terminen 2009, Rainer Bohnert 36

37 Feinplanung» Ausgangspunkt ist der Kalender (Tage oder Wochen)» Rahmenbedingungen eintragen: Bekannte Meilensteine, MA- Verfügbarkeit, Urlaube, Feiertage» Konkrete Tätigkeiten und konkretes Vorgehen festlegen (Detaillierung folgt)» Abhängigkeiten der Aktivitäten einplanen» Personen zuordnen Auf Kontinuität achten: Durchgängigkeit, Know-how Transfer zwischen den Projektphasen Einlernen bei Tätigkeiten berücksichtigen, gleichartige Tätigkeiten durchgängig besetzen 2009, Rainer Bohnert 37

38 Weitere Rahmenbedingungen der Feinplanung» Zulieferungen von außerhalb des Projekts: Meilensteine, deren Erreichung nachgefragt wird Wer schreibt, der bleibt!» Qualitätssicherung: Konkrete QS-Aufgaben planen (Review, Abnahmebegleitung, ) Pauschale Aufwände für begleitende Tätigkeiten eher klein halten (Risikoliste führen, )» Pufferzeiten: Mit minimaler Teamstärke planen, genügend Kapazitäten (Personal, Zeit) für maximalen Aufwand vorhalten» Projektleitung, Projektmanagement, Chefdesign Fester Anteil über die Projektlaufzeit einplanen, ggf. auch zu einem prozentualen Anteil 2009, Rainer Bohnert 38

39 Projektdurchführung

40 Projektkommunikation Meetings und Berichte

41 3 / 3 Regel» 1/3 Kommunikation» 1/3 Dokumentation» 1/3 Inhaltliche Arbeit 2009, Rainer Bohnert 41

42 Projektsitzungen» Ziel festlegen und aufschreiben!» Verantwortlichen festlegen» Verantwortlicher verschickt Einladung» Termin, Ort, Zeitrahmen» Teilnehmer Wer muss denn wirklich dabei sein?» Regelmäßige Agenda / Gleichbleibende Berichte» Wer moderiert, wer führt Protokoll?» Technik 2009, Rainer Bohnert 42

43 Während der Sitzungen» Handy aus!» Protokoll führen Wenn die Ergebnisse dokumentiert werden müssen Wenn weitere Personen unterrichtet werden müssen Wenn Ergebnisse Kosten verursachen, deren Ursache man dokumentieren werden soll» Die anderen ausreden lassen» Sich selbst kurz fassen» Zur Sache reden, nicht zur Person» Maximal 1 ½ h pro Woche» Bei Telefonkonferenzen: Unbedingt ausführlich vorbereiten, straff moderieren 2009, Rainer Bohnert 43

44 Protokolle und Statusberichte» Immer die gleiche Form» Reines Ergebnisprotokoll / Unmittelbar protokollieren» Teilnehmerliste + Verteiler» Termine auch als solche kennzeichnen» Freitag / Montag» Ampel -Metapher 2009, Rainer Bohnert 44

45 Risikomanagement

46 Risikomanagement» Ein Risiko ist ein Problem, das noch nicht eingetreten ist» Risiken sind in der Regel einfacher zu bekämpfen als die Probleme!» (es gibt auch positive Risiken) 2009, Rainer Bohnert 46

47 Risikomanagement» Risikomanagement ist ein ständiger Prozess.» Risikomanagement geht alle im Projekt an.» Verantwortlich für Risikomanagement: Projektleiter, Qualitätssicherer oder Risk Owner.» Risiken ändern sich ständig und müssen immer wieder neu bewertet werden. 2009, Rainer Bohnert 47

48 Der Risikozyklus 2009, Rainer Bohnert 48

49 Die Risikomatrix» Auschließen» Gegenmaßnahmen vorab einplanen Auswirkungen» Beobachten Eintrittswahrscheinlichkeit» Laufende Beobachtung im Projektverlauf (ständiger TOP auf der Agenda) 2009, Rainer Bohnert 49

50 Änderungsmanagement

51 Das Änderungsverfahren (Change Request) Wer schreibt, der bleibt! Änderungen formulieren Änderungen abschätzen Änderungen entscheiden Änderungen bearbeiten» Was genau ist das Problem?» Was genau ist die Lösung?» Wer will das, wer bezahlt das?» Wer ist davon betroffen?» Was ist die Konsequenz, wenn der CR nicht umgesetzt wird? 2009, Rainer Bohnert 51

52 Das Änderungsverfahren (Change Request) Wer schreibt, der bleibt! Änderungen formulieren Änderungen abschätzen Änderungen entscheiden Änderungen bearbeiten» Konsequenzen aus Umsetzung ermitteln: Zeit Budget Fachliche, technische Auswirkungen» Priorisierung des CR vornehmen: Wie wichtig ist er im Vergleich zu anderen CRs?» Gemeinsam durch Projektleitung, Dienstleister und Auftraggeber 2009, Rainer Bohnert 52

53 Das Änderungsverfahren (Change Request) Wer schreibt, der bleibt! Änderungen formulieren Änderungen abschätzen Änderungen entscheiden Änderungen bearbeiten» Möglichkeiten: Zulassen Ablehnen Zurückstellen» Entscheidung durch Projektleiter (kleinere CRs) oder Lenkungskreis (größere CRs) 2009, Rainer Bohnert 53

54 Das Änderungsverfahren (Change Request) Wer schreibt, der bleibt! Änderungen formulieren Änderungen abschätzen Änderungen entscheiden Änderungen bearbeiten» In Projektplanung einarbeiten (Terminänderungen, Ressourcenzuweisung, Budgetänderung...) 2009, Rainer Bohnert 54

55 Qualitätssicherung

56 Die Grünen in Baden-Württemberg Wahlparteitag 2002 Wer schreibt, der bleibt!» Ermittlung Beispiel: der Delegierten pro Ortsverband mit Hilfe von Excel» 10 Delegierte sind zum Parteitag zugelassen Je größer der Ortsverband, je mehr Delegierte» Kleiner Ortsverband 1 hat Anrecht auf 1,1 (2) Aber: Mindestdelegiertenzahl (2) für kleine Delegierte Ortsverbände» Großer Ortsverband 2 hat Anrecht auf 8,9 Laut Satzung dürfen nur 200 Delegierte an dem (durch Parteitag Runden teilnehmen 9) Delegierte» Ergibt: 11 Einladungen zum Parteitag Rundungsfunktion von Excel wurde nicht korrekt implementiert und schon gar nicht getestet Systematische Fehlerursachen:» Im Ergebnis wurden 202 statt 200 Einladungen» (Vermutlich) fehlende detaillierte versandt Spezifikation» Kein Test der Software» Der Wahlparteitag musste wiederholt werden!» Und das kurz vor der Wahl! Quelle: Süddeutsche Zeitung 2009, Rainer Bohnert 56

57 Der Begriff Qualität» Was macht denn Software so richtig gut?» Was ist Ihre Lieblingssoftware und was gefällt Ihnen daran?» Welche Software gefällt Ihnen nicht? Warum? 2009, Rainer Bohnert 57

58 Qualität...» Hängt von der Erwartungshaltung des Nutzers ab» Hängt von sonstigen Eigenschaften und Kontext ab: Spiel, das öfter mal abstürzt Office-Programm, das öfter mal abstürzt» Aber: es gibt auch klar messbare Kriterien» Die Zufriedenheit des Kunden hängt aber nicht nur von der Software ab 2009, Rainer Bohnert 58

59 Maßnahmen zur Qualitätssicherung Wer schreibt, der bleibt!» Ein gutes Ergebnis erzielt man, indem man die richtigen Dinge tut.» Ein gutes Ergebnis erzielt man nicht durch Prüfungen. Prüfungen stellen sicher, dass keine Fehler passiert sind.» Es gibt konstruktive und analytische Maßnahmen zur Qualitätssicherung. Mehr Qualität erzeugen kann man nur mit konstruktiven Maßnahmen. Analytische Maßnahmen (Tests) stellen nur sicher, dass ein Qualitätsstandard erreicht ist. 2009, Rainer Bohnert 59

60 Qualität in das Projekt hineinplanen» Qualitätssicherung ist zu Projektbeginn wichtig» In der Projektinitialisierung werden die wesentliche Weichenstellungen für das Projekt vorgenommen: Das Team wird zusammen gestellt Ziele werden fixiert Die Projektplanung wird festgelegt» Hier ist der Qualitätssicherer der Sparringspartner des Projektleiters. Wer schreibt, der bleibt! 2009, Rainer Bohnert 60

61 Beispiele für Qualitätssicherungsmaßnahmen I Wer schreibt, der bleibt!» Reviews (analytisch) Code Reviews Dokumentenreviews Workshops, zu denen externe Experten eingeladen werden. (Zwischenergebnisse werden vorgestellt und diskutiert)» Tests (analytisch) Funktionale Tests, auch als Regressionstests Lasttests etc.» Durchstich fachlich technisch 2009, Rainer Bohnert 61

62 Beispiele für Qualitätssicherungsmaßnahmen II» Aufbau einer insgesamt gut nutzbaren Entwicklungsumgebung (Editoren, Build-Werkzeuge, Code-Analyzer, Test-Frameworks, Anbindung an das Konfigurationsmanagement, Modellierungswerkzeuge, Generatoren, Debugger, etc.)» Ausbildungsmaßnahmen für Mitarbeiter Schulungen Workshops Vorträge Team-Rotation» Verbesserung der Kommunikation Spezielle Meetings, Statusrunden Vorträge über Fachthemen 2009, Rainer Bohnert 62

63 Beispiele für Qualitätssicherungsmaßnahmen III» Guidelines, Richtlinien Coding-Richtlinien Styleguides gemeinsame Glossare Richtlinien zur Erstellung von Dokumenten Wer schreibt, der bleibt!» Entwickeln von Checklisten, Templates Operationalisieren die Richtlinien/Guidelines 2009, Rainer Bohnert 63

64 Beispiele für Qualitätssicherungsmaßnahmen IV Wer schreibt, der bleibt!» Projektablage (Verzeichnis oder Konfigurations-Management) organisieren» Dafür sorgen, das man Informationen wieder finden kann: Konventionen für die Ablage von Dokumenten Beschaffen eines Such-Tools Händischer Index (z. B. HTML) über die wichtigsten Dokumente 2009, Rainer Bohnert 64

65 Qualitätskriterien für Software I: Funktionalität Wer schreibt, der bleibt!» Angemessenheit: Kann man mit der Anwendung das machen, was man mit ihr tun will? Ist der Funktionsumfang richtig?» Genauigkeit: Liefert die Anwendung die richtigen Ergebnisse in der gewünschten Präzision?» Zussamenarbeit: Arbeitet die Anwendung korrekt mit anderen Systemen zusammen?» Sicherheit: Schützt die Anwendung die enthaltenen Daten und Funktionen gegen unautorisierten Missbrauch? 2009, Rainer Bohnert 65

66 Qualitätskriterien für Software II: Verlässlichkeit Wer schreibt, der bleibt!» Grad der Entwicklung: Stürzt die Software wegen Fehlern nur selten ab?» Fehlertoleranz: Bleibt die Software funktionsfähig, auch wenn falsche Eingaben gemacht werden oder interne Fehler auftreten?» Wiederherstellbarkeit: Wenn die Software abgestürzt ist, lassen sich später die Software und die Daten wiederherstellen? 2009, Rainer Bohnert 66

67 Qualitätskriterien für Software III: Usability Wer schreibt, der bleibt!» Verständlichkeit: Versteht man, was die Software macht und ob sie das richtige macht, wenn man mit ihr arbeitet?» Lernbarkeit: Ist die Nutzung der Software leicht zu erlernen?» Bedienbarkeit: Kann man die Software leicht bedienen?» Attraktivität: Macht es Spaß, mit der Software zu arbeiten? 2009, Rainer Bohnert 67

68 Qualitätskriterien für Software IV: Effizienz Wer schreibt, der bleibt!» Antwortverhalten: Ist die Software schnell genug, verarbeitet sie schnell genug die Daten?» Ressourcenverbrauch: Geht die Software sparsam genug mit den Ressourcen, insbesondere der Hardware, um? 2009, Rainer Bohnert 68

69 Qualitätskriterien für Software V: Wartbarkeit Wer schreibt, der bleibt!» Verständlichkeit: Wie schnell finde ich die Stelle im Code, die ich ändern will?» Änderbarkeit: Wenn ich die Stelle gefunden habe, wie leicht lässt sich etwas ändern?» Stabilität: Haben Änderungen nur begrenzte Auswirkungen?» Testbarkeit: Wie leicht kann ich die Software testen? 2009, Rainer Bohnert 69

70 Qualitätskriterien für Software VI: Portierbarkeit Wer schreibt, der bleibt!» Anpassbarkeit: Kann man die Software durch Änderung an dafür vorgesehenen Stellen an eine andere Umgebung anpassen?» Installierbarkeit: Lässt sich die Software in einer bestimmten Umgebung einfach installieren?» Genügsamkeit: Verträgt sich die Software mit anderen Systemen oder blockiert sie z. B. gemeinsam genutzte Ressourcen?» Austauschbarkeit: Lässt sich die Software gegen eine andere Software austauschen, die für den gleichen Zweck gemacht ist? 2009, Rainer Bohnert 70

71 Software Testen

72 Warum testen? t 0» Sicherstellen, dass die verschiedenen Objekte der Software korrekt miteinander interagieren» Sicherstellen, dass alle Komponenten des Systems korrekt miteinander interagieren» Sicherstellen, dass alle Anforderungen an die Software erfüllt worden sind» Sicherstellen, dass alle Issues / Fehler, die im Entwicklungsprozess und im Testprozess aufgekommen sind, auch in der Entwicklung berücksichtigt wurden» Abnahme des Projektes t z 2009, Rainer Bohnert 72

73 Wann testen: Fehlerträchtigkeit Fehlerbehebungskosten Anforderungen Entwurf Implementation Wartung t 0 t z 2009, Rainer Bohnert 73

74 Modellhaftes Vorgehen Alle Tests abgeschlossen / Inbetriebnahme des Systems Dokumentation der Testergebnisse Auswertung der Tests Ausführen der Tests Design der Tests:» Entwicklung der Testcases» Implementation der Tests in Testsoftware» Identifikation von Nutzergruppen für Beta Tests Planung:» Welche Tests werden von wem mit welchem Zeithorizont wann im Projekt durchgeführt?» Wie wird mit den Testergebnissen umgegangen? (wer berichtet was, wie an wen) 2009, Rainer Bohnert 74

75 Was lässt sich überhaupt testen I» Funktionale Tests Black Box Tests White Box Tests» Verlässlichkeit System- und Datensicherheit Stress Tests Daten- / Datenbanktests - Volumetests Geschäftszyklentests Integration im Gesamtsystem Strukturtests» Wie verhält sich das System, wenn wenig Hardwareressourcen verfügbar sind?» Was passiert, wenn die maximale Anzahl der geplanten Nutzer zugreift?» Was passiert, wenn diese Nutzer gleichzeitig Datenbanktransaktionen durchführen?» Was passiert, wenn alle Szenarien gleichzeitig auftreten? 2009, Rainer Bohnert 75

76 Was lässt sich überhaupt testen II» Performance Tests Performance Benchmarking Load Tests» Wartbarkeit Code Review Konfigurationstests Installationstests Ausfallsicherheit / System Recovery» Kann der Nutzer bestimmte (typische) Aufgaben erfüllen» Entspricht die Nutzeroberfläche anerkannten Usabilitykriterien (Microsoft-Standards, DIN etc.)» Usability Tests Experimente / Interviews Analyse gemäß Usability Kriterien 2009, Rainer Bohnert 76

77 Warum testen?» Schnellerer Übergang zum produktiven System» Niedrigere Kosten im Systembetrieb und gleichzeitig:» Höhere Sicherheit vor Systemausfällen und damit:» Höhere Produktqualität 2009, Rainer Bohnert 77

78 Vorbereitung der Tests» Testcaseentwicklung» Testhandbuchentwicklung» Set-up der Testumgebung» Testcaseimplementation» Was ist zu testen?» Warum ist zu testen?» Wie wird getestet?» Von wem wird getestet?» Was wird an welcher Stelle des Projektes wie getestet?» Wie wird mit Ergebnissen umgegangen?» Innerhalb welchen Zeithorizontes und mit welchen Aufwänden?» Durchführung der Tests, Auswertung der Ergebnisse, Dokumentation 2009, Rainer Bohnert 78

79 Wie werden Testcases entwickelt?» Funktionale Anforderungen Use Case Reports / Business Modelling» Nicht funktionale Anforderungen Usabilityanforderungen Anforderungen an Systemverlässlichkeit Performanceanforderungen Anforderungen an die Wartbarkeit / Unterstützbarkeit des Systems Vorgaben zur Systementwicklung Dokumentation der Software Zulieferungen von Dritten Vorgaben zu Schnittstellen des Systems Lizenzrechtliche / andere rechtliche Einschränkungen und Vorgaben Vorgaben zu einzuhaltenden Standards und Normen 2009, Rainer Bohnert 79

80 Anhang

81 Formulare und Vorlagen» (englisch eher für sehr große Projekte) 2009, Rainer Bohnert 81

82 Literatur» ur Hier vor allem die Bücher (alle) von Tom di Marco sowie die Veröffentlichungen des PMI» kompakt (Taschenbuch) von Pascal Mangold 2009, Rainer Bohnert 82

83 Software» (auf deutsch)» (besser, vollständiger, leichter lesbar aber auf englisch) 2009, Rainer Bohnert 83

84 Vielen Dank! Rainer Bohnert Lentzeallee Berlin Telefon: 030 / Mobil: 0173 / Fax: 030 / rb@rainerbohnert.de 2009, Rainer Bohnert 84