Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Baustein RM-10: Überblick

Ähnliche Präsentationen


Präsentation zum Thema: "Baustein RM-10: Überblick"—  Präsentation transkript:

1 Baustein RM-10: Überblick

2 Inhalte des Bausteins Was ist ein „Risiko“?
Beispiele für allgemeine Risiken Beispiele für Risiken in der IV Beispiele für Risiken bei der Software Entwicklung Was kann man gegen Risiken tun? Qualität der Projektarbeit erhöhen Risiko - Ursache und Wirkung Ist Risiko-Management wichtig für IV-Projekte? Softwareentwicklung - reife und unreife Organisationen Methodisches Risiko-Management Dimensionen des Risikos Risiko-Management Subprozesse Risiko-Management senkt Kosten Diskussion der Teilnehmer, um festzustellen, welches Verständnis sie derzeit vom Testen haben. Die Fragen werden an der Tafel oder am Flipchart abgearbeitet. Wenn es verschiedene mögliche Antworten gibt, wird gezählt, wie viele Teilnehmer welche Antwort bevorzugen.

3 Was bedeutet „Risiko“? (1)
Risiko (ialienisch): Wagnis, Gefahr (Brockhaus) The possibility of loss, injury, disadvantage, or destruction (Websters Dictionary) Risk is a combination of the probability of a negative event and its consequences (Project Management scaleable Methodology Guide, James R. Chapman, 1997) Strictly speaking, risk involves only the possibility of suffering harm or loss. In the project context, however, risk identification is also concerned with opportunities (positive outcomes) as well as threats (negative outcomes). (A Guide to the Projct Management Body of Knoiwledge, Project Management Institute 2000) „Man muß nichts riskiren, wo nichts zu gewinnen ist“ (Ludmilla Assing, Varnhagen von Ense‘s Nachlaß, Leipzig 1865) 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 Entwicklungs-prozeß 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.

4 Was bedeutet „Risiko“? (2)
Risiken sind allen menschlichen Aktivitäten inhärent, die mit Kreativität und Entdeckungen von Neuland verbunden sind als Haupterfolgsfaktor anerkannt Ein Problem oder eine Gelegenheit, die sich noch nicht materialisiert haben dies impliziert, dass mehrfache Handlungen möglich sind mit verschiedenen Belohnungen oder Bestrafungen Entwicklungsorientierte Umgebungen wertschätzen das Eingehen von Risiken (Verfolgung von Chancen), ignorieren aber ein wenig das Risiko Management (Taktiken zur Problemabwehr) Quelle: S:PRIME Trainingsunterlagen

5 Beispiele für allgemeine Risiken/Chancen (1)
Technologische Risiken/Chancen Bau eines Kernkraftwerks: Risiko: Das AKW kann außer Kontrolle geraten ( z. B. Tschernobyl, Harrisburg) Chance: Die Stromversorgung des Landes kann unabhängiger von den Ölscheichs werden Bau einer Chemiefabrik/Raffinerie in einem Entwicklungsland: Risiko: Durch technische Störfälle können Umweltschäden angerichtet werden (z. B. Sandoz, Iguazu) Chance: Durch profitable Verarbeitung von Rohstoffen wird Kaufkraft erzeugt und größere Unabhängigkeit von den Industrieländern erreicht Bauen in Erdbebengebieten: Risiko: Bei einem großen Beben besteht die Gefahr, dass Gebäude einstürzen Chance: Durch bebauen gefährdeter Gebiete wird Raum für die stetig wachsende Bevölkerung geschaffen (z. B. Japan) Juran definiert Produktqualität in allgemeinen Worten als „geeignet zum Gebrauch“ (fitness for use). Nach Juran könnten wir also sagen: „Ein Qualitätssoftwareprodukt ist ein solches, das den Anforderungen des Anwenders genügt, so wie sie in der Spezifikation beschrieben sind.“ Aber es gibt oft Qualitätsfaktoren, die vom Kunden/Anwender einfach vorausgesetzt werden, ohne daß sie je Eingang in die Systemspezifikation finden. Es gibt auch Qualitätsfaktoren, an denen der Kunde/Anwender nicht direkt interessiert ist, die aber entscheidend wichtig für den Softwareentwickler sind. Es reicht also nicht aus, das Entwicklungsprojekt einfach gemäß Spezifikation abzuwickeln. Ein guter Projektleiter wird seinen Kunden auf diese nicht offenbaren Faktoren hinweisen und versuchen, ihn zu überzeugen, für ihre Berücksichtigung Geld auszugeben. Dies steht im Einklang mit der allgemeinen Definition der Qualität gemäß ISO 9001 („festgestellte und vermutete Bedürfnisse zu befriedigen“). Man kann aber auch zuviel des Guten tun: Für nicht erwünschte Faktoren „Goldrandprogrammierung“ wird kein Anwender bereit sein zu zahlen. Ein Softwareentwicklungsprojekt produziert aber nicht nur die Software selbst sondern auch eine Reihe von Zwischenergebnissen (oder Teilergebnissen) sowie mit der Software in enger Verbindung stehende Produkte wie Dokumentation, Handbücher etc. Auch diese müssen den Qualitätsansprüchen genügen.

6 Beispiele für allgemeine Risiken/Chancen (2)
Ökologische Risiken/Chancen Bau eines Stausees: Risiko: Durch zu hohe Wasserentnahme trocknet der Unterlauf des Flusses weitgehend aus, außerdem kann der Staudamm brechen Chance: Durch Bewässerung umliegenden Landes wird mehr Nahrung erzeugt (z. B. Assuan) Abholzungen von Wäldern: Risiko: Durch Abholzen des tropischen Regenwaldes werden Klimaänderungen hervorgerufen und Arten vernichtet Chance: Durch Holzexport wird Kaufkraft geschaffen, gerodete Flächen ergeben Ackerland Einsatz von genmanipuliertem Saatgut: Risiko: Durch unkontrollierten Einsatz können unerwünschte Nebenwirkungen auftreten Chance: Neu gezüchtete Arten tragen mehr Frucht und sind resistenter gegen Keime

7 Beispiele für allgemeine Risiken/Chancen (3)
Wirtschaftliche Risiken/Chancen Aktienkauf: Risiko: Die Kurse fallen oder das Unternehmen geht sogar pleite. Chance: Mit dem „richtigen Riecher“ lässt sich schnell Geld verdienen Unternehmensgründung: Risiko: Das Unternehmen überlebt die ersten 5 Jahre nicht (kritische Grenze für Neugründungen) Chance: Mit einer guten Idee kann man schnell reich werden, sogar, wenn man nur Verluste macht (z. B. viele Firmen am sog. „Neuen Markt“) Kreditvergabe: Risiko: Je höher ein Objekt beliehen wird, desto schneller kommt die Pleite, wenn sich die Rahmenbedingungen ändern (z. B. Donald Trump, Schneider) Chance: Je schlechter die Bonität des Schuldners ist, desto höher können die Zinsen für einen Kredit sein und desto mehr verdient die Bank potentiell.

8 Beispiele für allgemeine Risiken/Chancen (4)
Persönliche Risiken/Chancen Autofahren: Risiko: Pro Jahr gibt es in Deutschland ca Verkehrstote, insbesondere bei Nebel kommt es immer wieder zu schweren Massenkarambolagen Chance: Das Auto schafft Mobilität. Auch Behinderte haben so die Chance, unabhängig von anderen zu entfernteren Zielen zu gelangen. Bunjee Jumping, Free Climbing: Risiko: Gelegentlich reißt mal ein Seil oder ein Kletterer stürzt ab. Chance: Wenn man die „Prüfung“ erfolgreich bestanden hat, steigt oft das Selbstwertgefühl, das Eingehen hoher Wagnisse führt zur Ausschüttung von Endomorphinen. Zigaretten rauchen: Risiko: Der Zusammenhang zwischen Zigarettenrauchen und Krebs ist inzwischen wohl bekannt. Chance: Insbesondere junge Frauen haben das Gefühl, endlich emanzipiert zu sein, wenn sie in der Öffentlichkeit rauchen können.

9 Risiken und Chancen Im weiteren Verlauf des Kurses werden wir uns auf negative Risiken konzentrieren, da diese oft vernachlässigt oder übersehen werden. Chancen hingegen werden meist leichter erkannt und wahrgenommen. Um aber Chancen erfolgreich nutzen zu können, muss man auch wissen, was alles passieren kann, um einen vom Erreichen des Ziels fernzuhalten und Vorkehrungen dagegen treffen. Wir verlassen jetzt die Betrachtung allgemeiner Risiken und wenden uns den Risiken der IV zu, insbesondere den Risiken bei der Abwicklung von IV-Projekten

10 Beispiele für Risiken in der Informationsverarbeitung (IV)
Ausfall des Zentralcomputers zur Hauptarbeitszeit Unerlaubter Zugriff auf geschützte Daten Hackerangriff auf Website Feuer im Rechenzentrum Einschleusen von Viren Kriminelle Aktivitäten von Programmierern (z. B. Manipulation von Bankkonten) Datenverlust durch Überalterung der Speichermedien Es gibt eine Reihe von Faktoren, die die Qualität eines Softwareprodukts beeinflussen. Leider wird dieses Thema in der Literatur nicht einheitlich behandelt. Fast jedes Buch über Qualitätsmanagement, das man aufschlägt, definiert andere Faktoren bzw. Zerlegungen in Teilfaktoren, obwohl natürlich auch ein gewisser Kern gleich ist. Auch die Definitionen der Faktoren sind unterschiedlich. Für die obigen Faktoren gelten folgende Definitionen (im wesentlichen nach Trauboth, Software-Qualitätssicherung, Oldenbourg 1996): Funktionalität: Eignung eines Systems, seine spezifizierten Funktionen in Übereinstimmung mit den vorgegebenen Randbedingungen auszuführen. Zuverlässigkeit: Eignung eines Systems, während einer vorgegebenen Anwendungsdauer fehlerfrei zu funktionieren. Nutzbarkeit: Eignung eines Systems, den zu seiner Nutzung erforderlichen Aufwand für die vorgesehenen Benutzer gering zu halten und das Beurteilen der Handhabung durch die Benutzer positiv zu beeinflussen. Effizienz: Ausmaß der Inanspruchnahme von Betriebsmitteln durch das System bei vorgegebenem Funktionsumfang. Wartbarkeit: Eignung eines Systems, den Aufwand für das Erkennen von Fehlerursachen und ihre Korrektur, sowie die für die Durchführung von Änderungen mit dem vorgesehenen Personal innerhalb eines gegebenen Zeitraums bei Verfügbarkeit entsprechender Werkzeuge gering zu halten. Übertragbarkeit: Eignung eines Systems für seinen Einsatz in einer veränderten technischen Umgebung. Bevor diese allgemeinen Qualitätsmerkmale meßbar oder beobachtbar werden, müssen sie in der Regel weiter zerlegt und konkretisiert werden. Das ist schwierig und keineswegs allgemeingültig gelöst.

11 Beispiele für Risikoquellen in der Softwareentwicklung
Unklare Projektdefinition Einsatz von ungeprüfter oder unreifer Technologie Zu große und zu komplexe Projekte Unerfahrene Mitarbeiter Zu ehrgeizige Entwicklungsziele Mangelnde Managementunterstützung Beschäftigung von Unterauftragnehmern Zu optimistische Aufwandsschätzung Vgl. Trauboth, „Software Qualitätssicherung“, Oldenbourg 1996 Planerische- bzw. administrative sowie konstruktive QS-Maßnahmen sind Präventivmaßnahmen, die vor Beginn eines Projekts oder einer Projektphase durchgeführt werden müssen. Sie dienen dazu, mögliche Fehler zu vermeiden, bzw. die Fehlermöglichkeit einzuschränken. Analytische QS-Maßnahmen (‚Testen‘ im Sinne von Hetzel) haben die Prüfung, Bewertung und den Nachweis der Qualität des Prüfgegenstandes zum Ziel. Ein Unterpunkt der analytischen Maßnahmen ist beispielsweise das Testen im Sinne von Myers. Zur Durchführung derartiger Prüfungen gibt es verschiedene Verfahren, wie z. B. Inspection, Walk-Through, Review, Audit, Modultest, Integrationstest, Systemtest, Akzeptanztest.

12 Was kann man gegen Risiken tun?
Risiko-Management: Risiko-Management bedeutet keinesfalls, Risiken überhaupt zu vermeiden, etwa durch Unterlassung einer riskanten Aktivität. Es bedeutet vielmehr, Risiken bewusst und in systematischer Weise gegenüber zu treten, in dem man unnötige Risiken vermeidet und sorgfältig diejenigen managt (d. h. Vorkehrungen trifft, die die Wahrscheinlichkeit des Eintretens reduzieren und/oder das Risiko bei Eintreten leichter beherrschbar machen), die man bereit ist einzugehen. Risiko-Management hat auch nichts mit „Trouble Shooting“ zu tun. Risiko-Management ergreift Maßnahmen, bevor sich ein Risiko manifestiert hat. Trouble Shooting ergreift Maßnahmen, nachdem etwas schief gelaufen ist.

13 Qualität der Projektarbeit erhöhen
vorherrschende Philosophie der Qualitätssicherung orientierte QS??? Management Risiko- orientierte QS Prozess- Zertifizierungs- orientierte QS Anwendungs- orientierte QS Keine QS 60‘er 70‘er 80‘er 90‘er 00‘er Jahrzehnt

14 Risiko: Ursache und Wirkung
Konsequenzen Kosten explodieren Termine können nicht gehalten werden Funktionalität entspricht nicht den Anforderungen Projekte werden gestoppt Kunde ist unzufrieden eigenes Image sinkt Mitarbeiter sind unzufrieden häufiger Wechsel der Mitarbeiter Risikofaktoren Ziele Entscheidungsträger Nutzer Budget/Kosten Entwicklungsprozess Entwicklungsumgebung Mitarbeiter neue Technologien

15 Diskussion: Stand des Risiko-Managements
Wie ist der Stand des Risiko-Managements in Ihrem Unternehmen? Wissen Sie, was mangelndes Risiko-Management Ihr Unternehmen kostet? Falls Risiken gemanagt werden: Wird methodisch vorgegangen? Falls Risiken gemanagt werden: Wird Risiko- Management durch Werkzeuge unterstützt? vgl. Fragebogen: Software-Risiko-Management Fakten liegen aus den USA vor. Die folgenden Folien basieren auf Untersuchungen der Firma Aonix, San Francisco und des bekannten Produktivitätsforschers Capers Jones (Software Quality: Analysis and Guidelines for Success, International Thomson Computer Press, 1997) Die aufgestellten Berechnungen beleuchten die ganze Tragweite der Problematik. Aonix kommt zu dem Schluß (sicherlich zu erwarten, da die Firma unter anderem Testwerkzeuge herstellt, darunter z. B. Validator/Req ein Werkzeug zum Testen der Anforderungen ), daß bei dem üblichen Qualitätsniveau der amerikanischen Software (Industrieunternehmen) der Testaufwand mit herkömmlichen Methoden so groß wäre, daß er gar nicht zu leisten ist. Man begnügt sich deshalb damit, fehlerhafte Software als etwas Gott Gegebenes hinzunehmen (statt Gott könnte hier auch Bill Gates stehen, dessen sehr erfolgreiche aber fehlerhafte Software ja sattsam bekannt ist). In Deutschland dürften die Verhältnisse ähnlich liegen, wenn auch die Zahlen andere wären.

16 Ist Risiko-Management wichtig für IV-Projekte? (1)
„Trotz aller neuen angeblich besseren Technologien wie Client/Server, Objektorientierung und CASE steigen die Risiken der Software-Entwicklung. Im Jahre 1995 wurden ca. 250 Milliarden $ für Projekte in den USA ausgegeben. Davon gingen 81 Milliarden $ an gescheiterten Projekten verloren. Außerdem wurden 59 Milliarden $ für Kostenüber-schreitungen draufgezahlt. Somit fielen lediglich 110 Milliarden $ oder 48% auf fruchtbaren Boden. Der Rest wurde umsonst ausgegeben.“ Zitiert nach Harry Sneed: Software-Risikoanalyse (Notwendigkeit, Methodik und Anwendung aus: Software Management`99, Teubner, Stuttgart-Leipzig

17 Ist Risiko-Management wichtig für IV-Projekte? (2)
„Alles deutet darauf hin, dass mit neuen Technologien die Risiken steigen. Verteilte OO-Projekte haben eine um 139% größere Wahrscheinlichkeit zu scheitern und eine um 156% größere Wahrscheinlichkeit ihr Budget zu überschreiten als konventionelle Projekte. Je mehr neue Technologien eingesetzt werden, um so größer sind die Risiken. Deshalb kommt der Risikoanalyse immer mehr Bedeu-tung zu. Eine gründliche Risikoanalyse ist inzwischen zum unerlässlichen Instrument der Projektplanung geworden.“ Zitiert nach Harry Sneed: Software-Risikoanalyse (Notwendigkeit, Methodik und Anwendung aus: Software Management`99, Teubner, Stuttgart-Leipzig

18 Ist Risiko-Management wichtig für IV-Projekte? (3)
Aus Mr. Tompkins‘ Tagebuch: Risiko-Management: Managen Sie Projekte, indem Sie ihre Risiken managen. Führen Sie akribisch Buch über die Risiken jedes Projekts. Setzen Sie sich mit den ursächlichen Risiken auseinander, statt nur die unerwünschten Folgen am Ende zu sehen. Schätzen Sie für jedes Risiko die Wahrscheinlichkeit seines Auftretens und die mutmaßlichen Kosten ab. Antizipieren Sie für jedes Risiko das allererste Symptom, mit dem es sich vermutlich ankündigen wird. Ernennen Sie einen Risikobeauftragten, einen Mitarbeiter, den Sie von der „Das-Schaffen-Wir-Haltung“ entbinden. Richten Sie zwanglose (vielleicht sogar anonyme) Kanäle ein, über die schlechte Nachrichten bis in die höchsten Hierarchie- Ebenen hinauf kommuniziert werden können. Aus dem vorher Gesagten sollte eines jetzt ganz klar sein: Qualität eines Produkts ( z. B. Software) bzw. eines Prozesses ( z. B. Software-entwicklung) fällt leider nicht vom Himmel und ist auch nicht gratis. Für uns heißt das: Wenn man Qualität erreichen will, muß man diese managen. Dazu dient das Qualitätsmanagement. Qualitätsmanagement wird durch ein Qualitätsmanagementsystem (QMS) implementiert, d.h. die Gesamtheit aller Menschen, Prozesse, Methoden und Werkzeuge, die sicherstellen sollen, daß Produkte und Dienstleistungen erzeugt werden, die den Qualitätsanforderungen des Unternehmens genügen. Ziel all dieser Bemühungen ist der Kunde und seine Zufriedenheit. „Qualität ist kein Ereignis; Qualität ist eine Gewohnheit“. Das wußte schon Aristoteles. Qualität läßt sich nicht hinterher in ein Produkt hinein prüfen, sondern sie muß von Anfang an eingebaut werden. Alles andere wird in der Regel sehr teuer. Am besten ist es deshalb, wenn alle Projektarbeit von vornherein im Rahmen eines QMS stattfindet, das beispielsweise auf der internationalen Qualitätsnorm ISO 9001 aufgebaut ist. Wenn so gearbeitet wird, sind die Chancen sehr groß, daß ein Prüfer (Tester) bei einer Qualitätsüberprüfung feststellt, daß alle Qualitätsanforderungen erfüllt sind. Quelle: Tom DeMarco, Der Termin, Hanser Verlag 1998

19 Softwareentwicklung - Merkmale unreifer Organisationen
Improvisation - Prozesse sind undefiniert oder werden ignoriert Notfallmaßnahmen - man verläßt sich auf einzelne Helden Pläne werden umgestoßen, oder es werden Kompromisse gemacht bezüglich Funktionalität Fertigstellungsplanung Qualitätssicherung Es gibt keine Basis für objektives urteilen Heldenmärchen: “Man bekommt eine gute Beurteilung, wenn man Notfallmaßnahmen durchführt. Das Resultat ist sichtbar: es kann quantifiziert werden. Wenn man jedoch gleich alles richtig macht, ist das nicht sichtbar. Man hat einfach die Anforderungen erfüllt. Das ist der Job. Aber wenn man zuerst alles durcheinander bringt und dann später korrigiert, dann wird man ein Held.” (W. E. Deming, Out of the Crisis, Cambridge University Press 1986). Deming ist einer der Gurus der amerikanischen Schule des Qualitätsmanagements. Die Beobachtung, die er hier zum Besten gibt, kommt aus seinem Frust über die Tatsache, daß gutes Management oft weniger Ansehen genießt als schlechtes. Wenn ein IV Bereich oder ein Projekt schlecht gemanaged ist, gibt es dauernd etwas zu retten. Das ist die Chance, sich zu profilieren. “Wenn ich nicht gewesen wäre, wäre alles den Bach hinunter gegangen”. Wenn dagegen alles perfekt funktioniert, ist das völlig unspektakulär. Niemand hat eine Chance, sich zu profilieren. Es kann sogar noch passieren, daß man wegen relativ harmloser Verstöße gegen die Regeln zur Rechenschaft gezogen wird. Schließlich muß es ja irgend etwas zu kritisieren geben, denn perfektes Management oder Projekt-Management sind so selten, daß die meisten an seiner Existenz zweifeln.

20 Softwareentwicklung -Merkmale reifer Organisationen
Gesteuert: Prozesse sind definiert und werden organisationsweit gesteuert Arbeitsausführung basiert auf definierten/geplanten Prozessen Klar: Klare Verteilung von Rollen und Verantwortlichkeiten Exakte Kommunikation untereinander Objektiv: Leistung und Qualität werden überwacht und analysiert Realistisch: Pläne und Budgets basieren auf Vergangenheitserfahrungen Pläne werden normalerweise erreicht Liefertermine Funktionalität Qualität Diskussion mit der Gruppe: Würden Sie die Organisationen, aus denen Sie kommen, eher als “reif” oder als “unreif” bezeichnen? Ist es besser, in einer reifen Organisation zu arbeiten und falls ja, warum? Das erklärte Ziel des Qualitätsmanagements ist es jedenfalls, den Reifegrad von Organisationen zu verbessern.

21 Das (Software-) Capability Maturity Model (SW-CMM) des SEI
“jeder ist ständig damit beschäftigt, alles zu verbessern” Produktivität Optimierend & Qualität steigen “wir legen Regeln fest aufgrund von Erfahrungen aus der Vergangenheit” Gesteuert ”wir wählen unter unseren Praktiken aus durch die Ergebnisse, die sie produzieren” Definiert “wir befolgen die Regeln, außer, wenn wir in Panik geraten” Wiederholbar Risiko nimmt ab Das CMM (Prozeß-Reifegrad Modell) wurde vom Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsbourgh entwickelt. Es basiert auf allgemeinen Arbeiten von Philip Crosby und speziell auf den Softwareentwicklungsprozeß bezogenen Arbeiten von Watts Humphrey. Das Modell besteht aus 5 Reifegradstufen, die jede ihrerseits wieder aus sog. Kernprozessen (Key Process Areas) bestehen, z. B. auf Stufe 2 die Kernprozesse Management der Anforderungen Software-Projektplanung Software-Projektüberwachung und -steuerung Software-Subkontrakmanagement Software-Qualitätssicherung Software-Kkonfigurationsmanagement. Dieses Modell und das darauf basierende Assessmentverfahren (Verfahren zur Messung und Beurteilung der Qualität des Entwicklungsprozesses) sind in den USA sehr populär. In Europa wird meist ein anderes Assessmentverfahren verwendet, das ebenfalls auf dem CMM beruht: das Bootstrap Verfahren (entwickelt im Rahmen eines europäischen Esprit Projekts). “wir machen das, wozu wir im Augenblick Lust haben” Ad Hoc Quelle: Technical Report CMM/SEI TR - 025, „Key Practises of the Capability Maturity Model, Mark C. Paulk et al., Software Engineering Institute der Carnegie Mellon Universotät

22 Wo steht das Risiko-Management im SW-CMM?
Produktivität & Qualität steigen PA: Quantitative Process Management: Risiko-Management quantitativ PA: Integrated Software Management:Risiko-Management qualitativ PA: Software Project Planning: Risikoidentifikation und -bewertung PA: Software Project Tracking and Oversight: Risikoüberwachung Risiko nimmt ab Während das CMM den Softwareentwicklungsprozeß insgesamt brauchbar beschreibt, weist es auf dem Gebiet des Testens leider einige Schwächen auf. Beispielsweise fehlen: Das Konzept des Testreifegrades wird nicht behandelt Es gibt keine adäquate Einbeziehung von Testpraktiken in den Prozeß der kontinuierlichen Verbesserung Testfragen werden bei den Kernprozessen nicht adäquat berücksichtigt Qualitätsbezogene Kriterien wie z. B. Testbarkeit, Kriterien für Angemessen- heit von Tests, Testplanung, Software-Zertifizierung werden nicht adäquat berücksichtigt Um diese Mängel beheben, hat man zwei Wege eingeschlagen: Einerseits existiert eine internationale Arbeitsgruppe, die einen Vorschlag für einen neuen Kernprozeß “Testen” gemacht hat, was zur Folge hat, daß mehrere andere Kernprozesse des CMM, die Anteile des Testens enthalten, neu definiert werden müssen. Andererseits wurde unter der Leitung von C. R. Carlson am Illinois Institute of Technology ein Parallelmodell, das Testing Maturity Model (TMM) entwickelt, welches wesentlich aussagekräftiger ist als das erweiterte CMM. Das TMM kann von verschiedenen Gruppen verwendet werden: von einem internen Assessment Team, um den momentanen Testreifegrad zu bestimmen vom oberen Management, um ein Testprozeßverbesserungsprogramm zu ijnitiieren von Entwicklungsteams, um die Testfähigkeiten zu verbessern von Anwendern und Kunden, um ihre Rolle im Testprozeß zu definieren Quelle: Technical Report CMM/SEI TR - 025, „Key Practises of the Capability Maturity Model, Mark C. Paulk et al., Software Engineering Institute der Carnegie Mellon Universotät

23 Diskussion: Risiko-Management Methoden
Die meisten Firmen setzen keine Risiko-Management Methode ein: Warum ist das so? Gibt es Vorteile eines methodischen Ansatzes? Gibt es Nachteile eines methodischen Ansatzes? Beispielsweise berichtet die Firma SPR (Software Productivity Research, Burlington, USA), daß von ihren 600 Kunden Testen im engeren Sinne (s. Myers), die einzige qualitätssichernde Maßnahme ist, die alle mehr oder weniger einsetzen. (vgl. Jones S. 403) Es ergibt sich folgendes Bild: Allgemeine Formen des Testens Unterprogramm testen % Modultest 99% Systemtest 95% Testen neuer Funktionalität 90% Regressionstest 70% Integrationstest 50% Spezielle Formen des Testens Virusschutz testen 45% Belastungstests 35% Performanztest 30% Sicherheitstest 15% Plattformtest 5% Jahr 2000 Test (Zahlen stammen von 1996 und früher) 5% Testen durch Unabhängige 3% Einbeziehen von Anwendern Akzeptanztest 35% Beta Test 30% Labortest 1% Clean Room statistische Tests 1%

24 Vor- und Nachteile des Einsatzes einer Methode
Vorteile: Der Prozess des Risiko-Managements wird definiert Der Risiko-Management Prozess wird wiederholbar Es wird sicher gestellt, daß Komponenten mit hohem Risiko ausreichend beachtet werden Es wird vermieden, dass etwas vergessen wird ( z. B. unzureichender Test von wichtigen Systemkomponenten) Individuelle Unterschiede (Erfahrung der Projektleiter) werden reduziert Risiko-Management wird ein ‚intelligenter‘ Vorgang Metriken für Management und Kontrolle des Risiko-Management Prozesses werden bereit gestellt Eine Basis für die Teilautomatisierung des Risiko-Managements wird geliefert Nachteile: keine Es gibt wohl keinen Grund, der einer rationalen Argumentation stand halten würde, weshalb man nicht methodisch vorgehen sollte. Dabei gibt es - wie allgemein bei der Softwareentwicklung - nicht die eine, allgemein selig machende Methode, die jeder einsetzen sollte. Insbesondere ist wichtig, daß man - auch wenn man Testen nicht im erweiterten Sinne von Hetzel versteht - sich nicht nur auf das dynamische Testen von Programmen beschränkt. Die statischen Testmethoden (Review, Inspektion) leisten für die Reduktion der Anzahl der Fehler mehr als fast jede Form des dynamischen Testens. Ob man dies dann ‚Testen‘ nennen will oder ‚Dokumententest‘ oder allgemein ‚QS-Maßnahmen‘, ist letztlich egal. Wenn man Artikel oder Bücher über das Testen liest, muß man dies immer berücksichtigen, da der Sprachgebrauch nicht einheitlich ist. Innerhalb des Unternehmens sollte aber klar definiert sein, was unter testen zu verstehen ist. Dazu hilft die Methode.

25 Wann ist der richtige Zeitpunkt für eine erste Risikoanalyse?
Projektidee Projektauftrag Projekt zurückgestellt Erstellen Linienmaßnahme Voruntersuchungs- Vorhaben abgelehnt Entscheidung auftrag Projektantrag der Projektkoordi- abgelehnt nation Linienmaßnahme Entscheidung über Vorunter- Erstellung suchung Projektantrag Durchführung Voruntersuchung Die Risikoanalyse wird hier als Teil des Testmanagements behandelt, um die Methode TEST Rx TM zu beschreiben. Das ist auch richtig, denn zu Beginn der Testplanung müssen die Risiken bekannt sein, um die Ressourcen adäquat zuordnen zu können. Wir dürfen aber nicht vergessen, daß Testen analytische Qualitätssicherung bedeutet, eine Aktivität, die erst nach Beginn der Projektarbeit startet. Risikoanalyse muß idealerweise ein Bestandteil der Projektvorbereitung sein als Aktivität im Rahmen der Voruntersuchung. Hier ist der rechte Zeitpunkt, um zu entscheiden, ob es überhaupt Sinn macht, das Projekt unter den gegebenen Bedingungen durchzuführen bzw. welche konstruktiven Qualitätssicherungsmaßnahmen (z. B. Ausbildung, Verbesserung der Prozesse) durchgeführt werden müssen, um die Basis für einen Projekterfolg zu schaffen. Damit rückt auch die Aktivität 2.3 „Risiken modifizieren (optional)“ in ein anderes Licht. Zur Zeit der Testplanung mag es bereits zu spät sein, grundlegende Änderungen durchzuführen, deshalb hier „optional“. Zur Zeit der Projektvorbereitung ist die Erkenntnis, daß es so nicht geht, hingegen von elementarer Bedeutung und die Tätigkeit ist keineswegs optional. Der scheinbare Widerspruch klärt sich auf, wenn man den Begriff „Management“ näher untersucht: Ein Manager sollte ein Generalist sein, der das Ganze oder einen möglichst großen Teil davon überschaut. Das Gegenteil davon ist der Spezialist, der von einer Sache besonders viel versteht. Insofern ist es richtig, wenn der Spezialist „Tester“ aus seiner Sicht die Risikoanalyse als wichtige Aktivität erkennt und sie als Voraussetzung einer adäquaten Testplanung ansieht. Der Spezialist „Projektmanager“, der soweit Generalist sein muß, daß er auch untergeordnete Aktivitäten wie z. B. Qualitätsmanagement und Testmanagement überschaut, ohne dort Fachmann sein zu müssen, weiß, daß die Risikoanalyse eine entscheidende strategische Waffe zur erfolgreichen Durchführung von Projekten darstellt. Projektantrag erstellen: Projektziele Voruntersuchungs- Projektbegründung auftrag Projektbudget Aufnahme in Projektorganisation Projektliste Projekt (grob- )planung Risikofaktoren

26 Dimensionen des Risikos
Projektstruktur Projektgröße Erfahrung mit der Technologie Qualitative Risikogleichung: Perry identifiziert drei Risikodimensionen: Projektstruktur: Je strukturierter ein Projekt ist, desto geringer ist das Risiko. Deshalb unterliegen Projekte, die Methoden wie Projektmanagement, Qualitätsmanagement, Testmanagement, Vorgehensmodell für die Entwicklung, etc. anwenden, einem geringeren Risiko. Projektgröße: Die Projektgröße ist direkt proportional dem Risiko. Je größer ein Projekt ist in bezug auf Kosten, Mitarbeiteranzahl, Zeit, Anzahl einbezogener Funktionsbereiche etc., desto größer ist das Risiko. Erfahrung mit der Technologie: Erfahrung mit der Technologie ist umgekehrt proportional dem Risiko. Je mehr Erfahrung das Entwicklungsteam mit der Hardware, dem Betriebssystem, der Datenbank, dem Netz, der Entwicklungsmethode, den Entwicklungswerkzeugen, dem Anwendungsgebiet etc. hat, desto geringer ist das Risiko. Der „Faktor“ wurde nur eingesetzt, um aus der Proportionalität eine Gleichung zu machen. Diese allgemeine Gleichung sagt natürlich noch nichts darüber aus, wie denn nun das Risiko gemessen werden kann. Um dies möglich zu machen und damit verschiedene Situationen bzw. verschiedene Projekte vergleichbar zu machen, bedarf es noch einen erheblichen Denkaufwands. Abgenommen haben uns diesen Aufwand die Anbieter kommerzieller Risikobeurteilungssoftware. Ein besonders interessantes Verfahren ist das S:PRIME Verfahren (Software: Risk Identification, Mapping and Evaluation) der kanadischen Firma GrafP Technologies Inc. R Größe Struktur Erfahrung *

27 Risiko-Management: Subprozesse
Die Subprozesse im Risiko-Management Risiko-Management planen Risiken identifizieren Qualitative Risikoanalyse Quantitative Risikoanalyse Entwickeln von Maßnahmen Verfolgung der Risikoentwicklung Die folgende Darstellung lehnt sich an das PMBOK® des Project Management Institute Inc. Newton Square, PA, USA an Quelle: A Guide To The Project Management Body Of Knowledge, Project Management Institute Das 1969 gegründete PMI ist die führende Non-Profit-Forschungs- und Certifizierungsinstitution der Welt zum Thema Projekt-Management.

28 Risikomanagement senkt Kosten
Jedes eintretende Risiko verursacht - direkt oder indirekt - Kosten Ziel: alle Risiken, die direkt zu signifikanten finanziellen Schaden führen identifizieren und beheben erst im zweiten Schritt alle anderen analysieren und ggf. beheben

29 Motivation für Risiko-Management
Höhere Sicherheit (Termintreue) Senkung der Kosten Projektkosten Produktkosten höhere Qualität der Produkte steigende Zufriedenheit auf Kunden- und Mitarbeiterseite höhere Transparenz Steigerung des eigenen Images

30 Diskussion Überblick


Herunterladen ppt "Baustein RM-10: Überblick"

Ähnliche Präsentationen


Google-Anzeigen