loading

OUR BLOG

17
Mai

Wer findet das kreativste Konsensmodell?

Die Suche nach dem einfallsreichsten Konsensmodell geht weiter…

Auch wenn Proof-of-Work, über das wir  in unserem ersten Beitrag zu Proof-Modellen (hier) berichtet haben, nachwievor das bekannteste und meistverwendetste Konsensmodell ist, gibt es allerlei Abwandlungen und Mischformen . Nichts ist in Stein gemeißelt und die Suche nach energieschonenderen und sicheren Lösungen ist noch lange nicht vorbei. Neben Lösungen, die die Blockchain als Web-of-Trust durch Vertrauenspersonen (wie auch schon hier dargestellt), gibt es hier einige andere innovative Ansätze:

Tangle

IOTA verwendet keine Blockchain, hat aber technisch ein ähnliches System (hier das Whitepaper). Jeder User, der eine Transaktion durchführen will, muss zwei andere Transaktionen bestätigen. Dadurch können zugleich verschiedene Transaktionen an verschiedenen Stellen bestätigt werden und das System soll mit steigender Teilnehmerzahl schneller statt langsamer werden. Das System ist besonders geeignet für Gegenden, in denen es Internetprobleme gibt, weil die Geräte auch mit Bluetooth oder anderen Systemen miteinander verbunden werden können und damit Transaktionen dennoch ausgeführt werden können.

 

Konsensmodell Tangle - aus dem Whitepaper von IOTA

Konsensmodell Tangle – aus dem Whitepaper von IOTA

 

Proof-of-Membership (PoM)

Das Proof-of-Membership Konsensmodell schränkt im Vergleich zu PoW oder PoS die Gruppe derer, die bestätigen, dass eine Transaktion so stattgefunden hat, wie behauptet, auf eine offene Gruppe von Mitgliedern oder sogar eine geschlossene Gruppe von vertrauenswürdigen Mitgliedern aus.

Dieses Modell wird derzeit noch nicht verwendet, befindet sich aber in Diskussion.

Proof-of-Importance (PoI)

Der Proof-of-Importance wurde von NEM erfunden um zu verhindern, dass jene belohnt werden, die das beste Equipment haben oder am meisten Coins. Der PoI belohnt jene, die am meisten für die Community tun. Es basiert darauf, wie viele Transaktionen ein User hat und mit wem. Ziel ist es, den Reichtum an jene auszuschütten, die in der Community am meisten aktiv sind. Harvesting ist das Wort das anstelle von Mining verwendet wird und die Importance eine Users wird durch einen “trust Score” bewertet, der sich daraus berechnet, wie viel der User das Netzwerk benutzt. Harvesting kann jeder betreiben, der 10.000 Xem besitz, die als angestammt angesehen (vested) werden. Egal welche Summe von Token gekauft wird, wird immer 10% pro Tag als angestammtes Kapital angesehen, sodass nach 10 Tagen die gesamte Summe dazu zählt.

Proof-of-Play (PoP)

Bisher wird Proof-of-Play erst von einem einzigen Coin als Konsensmodell verwendet – MotoCoin (hier das Whitepaper). Anstelle der komplizierten Rechenaufgabe, die ein Computer zu lösen hat, wird gemined indem eine 2D-Motorrad-Simulation manuell gespielt wird. Es ist keine spezielle Hardware erforderlich, der Energieverbrauch ist deutlich geringer als beim klassischen minen und eine Attacke durch 51% gilt als unmöglich, weil es sehr teuer wäre genug erfahrene Spieler zu gewinnen und diese den Coin dann wohl lieber minen als zerstören wollen würden.

Konsensmodell Proof-of-Play - aus dem Whitepaper von MotoCoin

Konsensmodell Proof-of-Play – aus dem Whitepaper von MotoCoin

Proof-of-Elapsed-Time (PoET)

Intel hat vor einigen Jahren den Algorithmus für Proof-of-Elapsed Time entwickelt. Dieser basiert darauf, dass eine vertrauenswürdige Laufzeitumgebung gibt, in der ein Zufallsgenerator oder ein Lotterie-basiertes System entscheidet, wer den nächsten Block finalisiert. Dafür wird eine zufällig verteilte Leader Wahl unter allen verfügbaren Teilnehmern durchgeführt, für die alle Beteiligten verifizieren können, ob diese Wahl manipulationsfrei gelaufen ist. Die Wahl funktioniert so, dass jeder Validierer bei der Software um eine Wartezeit anfragt und jener, der die kürzeste Wartezeit bekommt, die Lotterie gewinnt und der Leader wird. Wenn ein Validierer behauptet, der Leader zu sein und den Block erstellt, wird damit auch ein Beweis erstellt, den die anderen einfach verifizieren können. Dieser Beweis enthält auch die Information, dass dem Validierer tatsächlich die kürzeste zugewiesen war und dass er die vom Protokoll vorgeschriebene Zeit gewartet hat, bevor er den nächsten Block gemined hat. Dadurch, dass der Zufall die Wartezeiten generiert, wird sichergestellt, dass die Rolle des Leader zufällig auf die Teilnehmer verteilt wird.

09
Mai

Proof-Alternativen für die Blockchain-Technologie

Proof-Alternativen: Byzantinisches Problem, Delegierte und vertrauensvolle Systeme

Neben Proof-of-Work und Proof-of-Stake (die wir schon in unserem vorherigen Artikel behandelt haben) gibt es allerlei Abwandlungen und Mischformen. Die folgenden beiden Modelle versuchen über Delegierte, Zeugen und Sprecher vertrauensvolle Systeme zu erstellen:

Proof-Verfahren: Delegated Byzantine Fault Tolerance

Dieser von NEO verwendete Algorithmus kombiniert die Vorteile von Proof-of-Stake und den Lösungen des byzantinischen Problems. Es wird eine Anzahl von Delegierten definiert, die einen Konsens über eine Order des Speakers erreichen müssen. Obwohl sowohl die Delegierten als auch die Speaker unehrlich sein können, wird mit einer Konsensrate von 66,66% abgesichert, dass die Buchungen korrekt sind. Innerhalb einer festgesetzten Zeit sendet ein Consensus Node eine Transaktion mit den Signaturen des Senders an das gesamte Netzwerk. Der erste Speaker sieht sich die Buchung an und sendet seinen Vorschlag; dieser Vorschlag wird wiederum von den Delegierten validiert. Wenn die Delegierten zustimmen und den Bock signieren, wird der Block in die Blockchain gehängt. Wenn der Prozess die festgesetzte Zeit überschreitet, wird eine neue Konsensrunde gestartet.

Das byzantinische Problem

Warum reicht eine Konsensrate von 66,66%? Die Basis dafür ist das sogenannte byzantinische Problem.

Der Legende nach hatten osmanische Generäle im Jahr 1453 n. Chr. bei der Belagerung von Konstantinopel (Byzanz) ein Kommunikationsproblem. Während sie an verschiedenen Stellen um die Stadt lagerten und nur mit Boten kommunizieren konnten, wussten sie bei der Planung ihres Angriffs, dass einige der Generäle Verräter waren und bewusst die Planung torpedieren würden.

Im Jahre 1982 veröffentlichten Lamport, Shostak und Pease – entspannte 500 Jahre später –  Lösungen für dieses Problem (hier ihre Publikation).

Grundannahmen dieser Lösung sind die Folgenden: Der Befehlshaber schickt allen Generälen den selben Befehl und die loyalen Generäle befolgen jeweils den Befehl, den sie erhalten. Alle schicken untereinander jeweils ebenfalls die Befehle, wobei bekannt ist, dass die illoyalen diese Befehle verfälschen und die loyalen nicht. Damit können die Leutnants die eingehenden Befehle als Wahl behandeln, also jenen Befehl ausführen, der ihnen am öftesten zugetragen wird.

Eine Lösung besagt, dass solange der Anteil der verräterischen Generäle kleiner als ein Drittel ist, die Lösung tolerant ist gegen den Byzantinischen Fehler.

Die zweite Lösung benötigt nicht fälschbare Signaturen; diese erhält Fehlertoleranz bei beliebiger Anzahl verräterischer Generäle.

Auf Basis diese Lösung reicht also eine Zustimmung von zwei Drittel der Speaker und Delegierten, die nicht fälschbaren Signaturen erhöhen die Fehlertoleranz.

Delegated Proof-of-Stake (DPoS)

DPoS versucht die Nachteile des Proof-of-Work und des Proof-of-Stake auszugleichen, indem ein Layer technologischer Demokratie eingezogen wird. Die Echtheit von Transaktionen wird von auserwählten Zeugen bestätigt. Diese Zeugen werden von den Eigentümern der Coins bestimmt. Es kann eine unbeschränkte Anzahl von Zeugen bestimmt werden, solange zumindest 50 % der Mitglieder der Meinung sind, dass mit den gewählten Zeugen ausreichend Dezentralisierung gewährleistet ist.

Zusätzlich werden auf die gleiche Art Delegierte gewählt, die dafür verantwortlich sind das Netzwerk zu erhalten und sogar Änderungen am Netzwerk vorschlagen können.

Damit soll nicht nur aktuelle Funktionalität und Sicherheit gewährleistet werden, sollten Änderungen notwendig werden, so können diese ebenfalls einfach abgestimmt werden.

28
Feb
Die Blockchain ist die neue Wunderwaffe der Informatik.

Blockchain: Proof of Whaaat?

Blockchain Einführung

Die Blockchain ist die neue Wunderwaffe der Informatik. Basierend auf einem White Paper des mysteriösen Satoshi Nakamoto aus dem Jahr 2008 ging der Bitcoin 2009 als erstes Produkt über die Blockchain. Seitdem sind 1442 weitere Währungen entstanden (Stand 17.1.2018). Die Technologie wird durch Ethereum weiter ausgebaut, sodass auf der Blockchain nicht nur “money from thin air” sondern auch andere Anwendungsfälle entstehen.

Die Blockchain ist die neue Wunderwaffe der Informatik.

Die Blockchain ist die neue Wunderwaffe der Informatik

Nun werden

  • Energieüberschüsse lokal weiterverkauft (zB Microgrid),
  • Identitäten ortsunabhängig verfügbar gemacht (id2020),
  • Geschäftssitze von Unternehmen in einem Land gegründet (e-Residency aus Estland) oder
  • Daten dezentral und trotzdem sicher gespeichert werden (IPFS)

um nur einige Konzepte zu nennen. Und den Anwendungsfällen sind keine Grenzen gesetzt. Glaubt man den Visionären der Szene, gibt es bald

  • “Self-Owned-Cars” beispielsweise von Toyota – Autos, die sich selbst gehören und sich anstelle von Ueber oder Taxis selbständig anbieten uns von A nach B zu fahren – oder sogar
  • “Self-Owned-Forests” – Wälder, die über eine Artificial Intelligence App sich selbst besitzen und verwalten können (zB Terra0).

Die über die Blockchain gehandelten Werte bewegen sich aktuell sehr intensiv, schwankten im Sommer 2017 um den ein Milliarden Dollar Bereich und bewegt sich aktuell um den Jahreswechsel zwischen zwei und 5,5 Milliarden Dollar.

Beachtliche Chancen, beachtliche Summen, aber warum eigentlich wird die Blockchain als so sicher angesehen, dass derartig astronomische Werte darin gehandelt werden?

Kette von verschlüsselten Transaktionen

Die Blockchain ist – vereinfacht gesagt – eine Kette von verschlüsselten Transaktionen, die in sogenannten Blocks gespeichert werden. Jeder dieser Blocks wird mit einer Chiffre versehen und nimmt jeweils auf die vorherige Transaktion Bezug. Dadurch greifen diese Blöcke wie Puzzlesteine ineinander und können im Nachhinein nicht unbemerkt verändert werden. Diese Kette wird von einer Vielzahl von sogenannten Minern kontinuierlich berechnet und weiter abgespeichert. Die Sicherheit der Blockchain entsteht dadurch, dass ein Hacker, der Blocks verändern möchte, diese Blöcke bei der Mehrheit der Miner verändern müsste. Wollte er eine Veränderung im Nachhinein machen, müsste er zusätzlich nach jedem Block den er verändern möchte, auch alle darauffolgenden Blöcke ändern.

Um sicherzustellen, dass die Transaktionen nicht manipuliert werden können, werden diese nicht nur zentral berechnet und gespeichert, sondern gibt es zahlreiche Miner, die die Kette der Blöcke abspeichert und sich jeweils auf den aktuellen Stand einigt.

Verschiede Blockchains haben verschiedene Konsensverfahren, die sicherstellen, dass die Kette unverfälscht ist und Geldbeträge nicht doppelt ausgegeben werden können.

Die beiden bekanntesten Verfahren sind Proof-of-Work (das beispielsweise von Bitcoin verwendet wird) und Proof of Stake (das von Ethereum verwendet wird).

Proof-of-Work (PoW)

Dieses Konzept ist vereinfacht der Nachweis der Lösung eines schwierigen mathematischen Problems. Schwierig heißt in diesem Fall, dass die Berechnung zeitlich relativ aufwendig ist und dadurch die Kosten der Berechnung hoch sind. Diese Aufgabe wird von den Minern übernommen, wobei jener, der die Aufgabe am schnellsten löst und damit den Block “findet”, ein festgelegte Anzahl von Münzen bekommt. Da die Aufgabe so gestellt ist, dass die gefundene Lösung sehr leicht überprüft werden kann, wird die Korrektheit durch die anderen Miner überprüft, von allen übernommen und die nächsten Blöcke mit diesem mathematisch verknüpft. Dieses Schema wird beispielsweise von dem Bitcoin benutzt.

Der Nachteil von Proof of Work ist, dass ziemlich viel Rechenleistung aufgewendet wird und und Kritiker dies als Energieverschwendung sehen.

Proof-of-Stake (PoS)

Anstelle des aufwendigen Systems von Proof-of-Work reicht es bei Proof-of-Stake, dass eine Transaktion von mehreren Nutzern bestätigt wird und in die Blockchain geschrieben wird. Die Wahrscheinlichkeit, einen Block zu finden, steigt hier nicht über die größere Rechenleistung, sondern über die größere Anzahl der gehaltenen Münzen. Anstelle des Minings tritt das Forging, eine Transaktionsgebühr wird demjenigen zugesprochen, der den letzten Block “gefunden” hat.

27
Feb
Blockchain, Smart Contracts und ihre anwendung

Blockchain und die Anwendungsbereiche

Generell lässt sich sagen: Wenn Transaktionen für einen Personenkreis sicher und nachvollziehbar abgelegt werden sollen, ist die Blockchain eine gute Wahl.

Hierzu zählen Fahrzeugbriefe genauso wie die interne Leistungsverrechung in Konzernen und der Garantieschein für ein gekauftes Elektrogerät.

blockchain_Fotolia_132389717_M

Blockchain, Smart Contracts und ihre Anwendung | © Akarat Phasura/Fotolia

Durch Smart Contracts sind die Anwendungsgebiete der Blockchain schier explodiert: Smart Contracs eignen sich überall dort, wo Eingangs- oder Ausgangsparameter eines Vertrags durch ein elektronisches Systems verarbeitet werden. Beispiele sind:

  • Ausstellen von Tickets (z. B. Nahverkehr, Flugtickets)
  • Auftragsmanagement mit Dienstleistern, die ihre Ergebnisse (Fotos, Texte, Source-Code, Übersetzungen, Gutachten, Mess-Ergebnisse, …) in digitaler Form liefern
  • Jede Art von Makler-Dienstleistungen (Wohnungsmarkt, Gebrauchtwagen, Job-Börsen, Taxi-Dienste, Programmatic Advertising, …)

Darüber hinaus werden Smart Contracs zunehmend Bedeutung im Bereich der IoT erreichen. Beispiele hierfür sind:

  • Mietwagen, die den Motor nur starten, wenn die Kreditkarte des Fahrers belastet werden kann
  • Hotelzimmertüren, die sich nur für den bezahlenden Gast öffnen, ohne Check-In, ohne Keycard
  • WLANs, die für sehr geringes Entgelt von Fremden mitgenutzt werden können
27
Feb
Die Blockchain-Technologie und Industriezweige

In welchen Industriezweigen wird Blockchain-Technologie bereits angewendet?

Der erste Anwendungsfall für die Blockchain-Technologie  war Bitcoin. Dieses Netzwerk hat mittlerweile eine Marktkapitalisierung von ca. 20.000.000.000 US$ und kann damit als stabil und langlebig bezeichnet werden. Tatsächlich ist es seit dem Start der Blockchain niemandem gelungen einen Block oder ein Bitcoin zu fälschen. In Regionen ohne stabile Währungen löst Bitcoin langsam den US$ als Leitwährung ab. Das liegt zum Teil auch daran, dass Bitcoin-Überweisungen weltweit für sehr geringe Gebühren und in Sekundenschnelle möglich sind.

blockchain_Fotolia_123598726_S

Die Blockchain-Technologie und Industriezweige | © zapp2photo/Fotolia

Die Möglichkeit, ohne Intermediäre, Geldsummen zu transferieren hat dann zu den ersten industriellen Anwendungen der Blockchain geführt: Banken wickeln heute bereits sogenannte Inter-Bank-Transfers, also das Verschieben großer Geldsummen über private Blockchain Netzwerke ab.

Im öffentlichen Bereich werden Blockchains heute insbesondere da verwendet, wo Sachverhalte über eine lange Zeit, öffentlich zugänglich und absolut fälschungssicher dokumentiert werden müssen. So haben beispielsweise Schweden und Honduras ihre Katasterämter auf Blockchain umgestellt. Damit konnte sicher gestellt werden, dass Land-Titel nicht nur für jeden Bürger einsehbar wurden, sondern auch jeder Besitzwechsel lückenlos und sicher nachvollzogen werden kann.

Weitere Anwendungen der Blockchain finden sich heute in der Kreditwirtschaft und in der Crowd-Funding Industrie. Auch ist zu beobachten, dass insbesondere in der Softwareindustrie, freie Mitarbeiter über Smart Contracts gebunden werden: Sie erhalten eine Aufgabe (Entwicklung einer bestimmten Funktionalität) und beweisen dem Smart Contract gegenüber, dass sie diese Aufgabe erfüllt haben. Der Vertrag selbst schüttet dann den vereinbarten Betrag an den Mitarbeiter aus, ohne dass eine Buchhaltung involviert wird. Dieses Einsparpotenzial bei der Buchhaltung wird derzeit ebenfalls von Unternehmen gesehen, die vornehmlich mit digitalen Gütern handeln. Beispiele hierfür sind Fotoagenturen und Content Netzwerke.

26
Okt
PMO und Project Office in der Organisation

Das Project Management Office – PMO – in IT Projekten

Das Project Management Office – PMO umfasst sowohl

  • die Definition von Methoden und Prozessen für ein durchgängiges einheitliches Projektvorgehen,
  • die einheitliche Steuerung und
  • das Reporting,
  • als auch die operative Unterstützung des Projektmanagements.

In größeren Unternehmen besteht das PMO aus einer eigenen Abteilung, die eine zentralisierte Rolle im Unternehmen hat. In kleineren Unternehmen besteht ein PMO häufig aus einer Einzelperson oder einem kleinen Team. Das PMO ist dann meist nur für einzelne Projekte zuständig und sorgt für die Entlastung der Projektleitung. In diesem Fall handelt es sich hier eher um Project Office (Projektbüro) als um PMO. Das Projekt Office besteht so lange wie das Projekt selbst, d. h., es besteht nicht auf Unternehmens-, sondern auf Projektebene.

PMO und Project Office in der Organisation

PMO in größeren Unternehmen als eigene Abteilung. In kleineren Unternehmen ist das PMO nur für einzelne Projekte zuständig und heisst Project Office (Projektbüro).

Beide Rollen bzw. Einheiten können gleichzeitig bestehen, es gibt doch Unterschiede bezüglich der Einsatzdauer und des Aufgabenbereichs. Grundsätzlich können PMO als allgemeiner Koordinator und PO als spezifische Einheit betrachtet werden.

Das Project Office (Projektbüro) arbeitet als operative Unterstützung des Projektleiters direkt in den Projekten und wird oftmals ad hoc, während das Projekt bereits läuft berufen. Pos sind für die Projektdokumentation, das Projektreporting, sowie für administrative Aufgaben innerhalb des Projektteams zuständig.

Das PMO arbeitet an Standards, Richtlinien, Prozessen und Methoden für den Einsatz in Projekten. Das PMO ist generell projektübergreifend tätig, kann aber bei Bedarf auch einzelne Projekte direkt unterstützen.

Der Einsatz des PMO verbessert die Zielerreichung einzelner Projekte, und optimiert gleichzeitig die Prozesse für einheitliches Projektportfoliomanagement.

Der Einsatz des Project Office führt zu einer Entlastung des Projektmanagers und des Projektteams, was wiederum zur Erhöhung der Effektivität in der Projektarbeit führt.

Beide Rollen bzw. Einheiten können gleichzeitig bestehen, es gibt doch Unterschiede bezüglich der Einsatzdauer und des Aufgabenbereichs. Grundsätzlich können das PMO als allgemeiner Koordinator und das PO als spezifische Einheit betrachtet werden. Beide können helfen, ein Projekt kontinuierlich am Laufen zu halten, und dadurch Nutzen stiften, dass Projekte schneller umgesetzt werden, geringere Kosten entstehen und durch Prozesssicherheit höhere Qualität erzielt wird.

Ist in einem Unternehmen ein PMO vorhanden, so wird dieses Vorgehensmodelle für Projekte erarbeiten. Solche Vorgehensmodelle beschreiben die beispielsweise die Art und Frequenz des Berichtswesens, die Projektdokumentation und eine einheitliche Projektstruktur. Die Projektleiter in solchen Unternehmen sind gehalten, diese Regeln anzuwenden, auch wenn projektbezogene Ausnahmen im Rahmen pragmatischer Arbeit immer erlaubt sein müssen.

Anders verhält es sich in Unternehmen ohne PMO: hier wird das Vorgehensmodell üblicherweise innerhalb des Projekts erarbeitet und festgelegt. Der Projektleiter ist damit letztlich für das Vorgehensmodell verantwortlich, während der PO es lediglich anwendet und bestenfalls optimiert.

Aufgaben des Project Office (Projektbüro) in IT Projekten

  • Erstellen von Standards und Templates für
    • die Projektdokumentation
    • das Reporting
  • Unterstützung des operativen Projektmanagements bei
    • der Planung,
    • dem Reporting und
    • dem Controlling.
  • Unterstützung des Projektteams bei administrativen Aufgaben: In einem Projekt fallen zahlreiche administrative Tätigkeiten – wie z. B. Dokumentation-, Berichts- und Bestellwesen – an. Ein PO kann diese Aufgaben vom Produktivteam fernhalten. So kann das PO des Teams von administrativen Aufgaben entlasten, was wiederum zur Erhöhung der Effektivität der Projektarbeit führt.

Aufgaben des Projekt Management Office – PMO

In IT Projekten hat das PMO, zusätzlich zu den eben beschriebenen Aktivitäten desProject Office (Projektbüro) folgende Aufgaben:

  • Definition einer unternehmensweiten Projektmanagement Kultur mit
    • geeigneten Tools und
    • Infrastruktur-Unterstützung, um das Wissen aus und in den Projekten transparent zur Verfügung zu stellen.
  • Sicherstellen des Einklangs der Projekte mit der Unternehmensstrategie: Das PMO sorgt dafür, dass die durchgeführten Projekte an der Unternehmensstrategie ausgerichtet sind. Diese Aufgabe beinhaltet unter anderem die Vorbereitung von Entscheidungsgrundlagen zur Projektauswahl und zur Priorisierung von Projekten.
  • Erstellen von projekteinheitlichen Regeln für
    • Projektmanagementmethoden,
    • Prozesse und Workflows für Projektkalkulation, Risiko- und Problemkontrolle, Anforderungskontrolle.
  • Unterstützung bei der Multi-Projektplanung mit
    • Koordination der unterschiedlichen Projekte und
    • Priorisierung.

Das Project Management Office – PMO nach PMI

Nach der Definition im Project Management Body of Knowledge (PMBOK Guide) des Project Management Institute (PMI), das PMO ist eine organisatorische Einheit, die das Management von Projekten, die zu seinem Bereich gehören, zentralisiert und koordiniert. Ein PMO wird auch als ‚Programm Management Office‘, ‚Projektoffice‘, oder ‚Programmoffice‘ bezeichnet.“

http://www.pmi.org/Learning/knowledge-shelf/project-management-offices.aspx

09
Okt
Risikomanagement in IT und Software Projekte

Risikomanagement in IT und Software-Projekten

Das Risikomanagement in IT und Software-Projekten ist der wichtigste Faktor für die Absicherung, die Schadenminimierung und schließlich für den erfolgreichen Abschluss der Projekte. Unter Risikomanagement werden alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung zusammengefasst.

Risikomanagement in IT und Software Projekte

Die wichtigsten Schritte in Risikomanagement

IT und Software Projekte erweisen in ihr Laufzeit eine Vielzahl von Risiken. Die Risikohöhe nimmt mit der Größe und Komplexität der geplanten Software und mit der Anzahl der Schnittstellen zu anderen Systemen überproportional zu. Deshalb ist es wichtig, dass alle Risikofaktoren in die Vorphase und in die Planung und Überwachung des Projekts mit einbezogen werden.

Zu den Risikofaktoren eines IT Projekts zählen sowohl Allgemeine als auch Spezielle Risikofaktoren.

Allgemeine Risikofaktoren, relevant für das Risikomanagement in IT und Software-Projekten

  • unzureichende Unterstützung durch die Geschäftsführung
  • Spannungen und Konflikte im Projektteam
  • Fehlende Motivation im Projektteam
  • Fehlende Benutzerakzeptanz
  • mangelhafte Informations- und Kommunikationsstrategie
  • unzureichende Fachkompetenz der Teammitglieder

Spezielle Risikofaktoren(fachliche und methodische Risiken)

  • fehlende und unklare Zielsetzung des Projekts
  • unrealistische Terminvorgaben
  • fehlende Planung, Termin- und Kostenüberwachung
  • mangelhafter Überblick des Projektstands und Fortschritts
  • Schnittstellenprobleme (Fehlende Dokumentation, Inkompatibilitätsprobleme)
  • unzureichende Tests und fehlende Qualitätskontrolle

Das Vorgehen beim Risikomanagement in IT und Software-Projekten besteht aus folgenden Schritten

  • Identifikation der Ursachen
  • Analyse
  • Risikobewertung
  • Priorisierung anhand der Auswirkungen und der Eintrittswahrscheinlichkeit
  • Einleitung von Maßnahmen
  • Konsequente Verfolgung der Risiken (Monitoring)

 

Risikobewertung

Die Risikobewertung dient der Priorisierung und anschließend der kontinuierlichen Überwachung. Sie ist die Grundvoraussetzung für eine gezielte Steuerung und Behebung oder Minimierung des Risikos durch Maßnahmen. Die Risiken werden hinsichtlich ihrer Eintrittswahrscheinlichkeit und Auswirkung bewertet und priorisiert.

Risikobewertung in IT und Software-Projekten

Priorisierung nach Risikobewertung in IT und Software-Projekten

1. Niedrige Priorität: Das Risiko ist definitiv nicht Projektgefährdend, muss doch überwacht werden.

2. Mittlere Priorität: Das Risiko ist wahrscheinlich nicht Projektgefährdend, muss doch intensiv überwacht werden.

3. Hohe Priorität: Das Risiko gefährdet das Projekt. Die Maßnahmen zur schrittweisen Behebung oder Reduzierung des Risikos, müssen geplant und Zeitnah eingeleitet werden.

4. Höchste Priorität: Sofortige Maßnahmen müssen in diesem Fall eingeleitet werden. Das Risiko kann große Projekt- oder sogar Unternehmensweite Schaden verursachen.

Voraussetzungen für erfolgreiches Risikomanagement in IT und Software Projekte

Kontinuität

Die Risiken müssen identifiziert und intensiv verfolgt werden. Potenzielle neue Risiken müssen immer wieder überprüft und erkannt werden.

Offene Kommunikationskultur

Im Unternehmen muss eine offene Kommunikationskultur gelebt werden, damit im Rahmen des Risikomanagements die Maßnahmen in unterschiedlichen Bereichen des Unternehmens ausweiten zu können. In diesem Zusammenhang jemand, der Risiken meldet, darf auf keinem Fall vor beruflichen Konsequenzen fürchten.

Vollständige Integration im Entwicklungsprozess

In der gesamten Laufzeit eines Projekts muss Risikomanagement fester Bestandteil der Prozesse sein.

28
Sep
Tester und Testmanager in Scrum

Tester und Testmanager in Scrum

Tester und Testmanager gibt es zwar als Rollen in Scrum Prozess nicht, allerdings ist Scrum nur ein Softwareentwicklung-Framework, das keine technischen Praktiken diktiert. Nun, da Scrum Teams übergreifende Teams sind, gehören Tester bzw. Testmanager dazu.  So wird beim agilen Prozess die Unabhängigkeit zwischen Entwicklungs- und Testmannschaft, die bei den klassischen Methoden die Regel ist, aufgegeben.
Tester und Testmanager sind hier Teile des Scrum Teams. Statt auf freigegebene Anforderungs- und Designdokumente zu warten, sind sie im agilen Team zu Kommunikation, Interaktion und aktiver Mitarbeit aufgerufen. Auch wenn sie keinen Code schreiben, müssen Tester bei der Automatisierung von Regressionstests und anderen Automatisierungstests sehr eng mit den Programmierern zusammenarbeiten.

Sobald ein Programmierer eine User Story implementiert, sollte der Tester bereits die Testfälle anhand der Akzeptanzkriterien vorbereitet haben, um mit den Tests der Story beginnen zu können.

Tester, Testmanager, Produckt Owner und Entwickler in Scrum

Abbildung der Testing Aufgaben im Scrum Prozess

Erst wenn alle User Stories implementiert und die Tests erfolgreich abgeschlossen sind, kann ein Sprint als erfolgreich abgeschlossen betrachtet werden. Hier ist natürlich die Continuous Integration Umgebung sehr wichtig, um die Änderungen der Entwicklung sofort dem Testing zur Verfügung zu stellen.

Aufgaben der Tester und Testmanager in einem Scrum Team

  • Analysieren der User Stories auf ihre Qualität und Vollständigkeit
  • Mitdefinieren der Akzeptanzkriterien
  • Prüfen der Akzeptanzkriterien auf Testbarkeit
  • Sicherstellen von Testdaten
  • Sicherstellen der Rückverfolgung zwischen User Story und Test
  • Beteiligung an der Sprint-Planung und den Daily Scrum Meetings
  • Funktionales Testen der User Stories
  • Usability Tests
  • Explorarives Testing
  • Mitarbeit mit den Programmierern bei der Implementierung von Unittests
  • Ausführung einer Kombination von Unitests und explorativen Tests. So werden schnell Fehler gefunden, die allen von Unitests nicht gefunden werden können.
  • Performance und Security Tests

Damit die Sprints erfolgreich getestet werden, ist der Betrieb einer Continuous Integration Umgebung, in der automatisierte Unit-, Integrations- und Systemtests die Implementierung der User Stories begleiten, notwendig.

Entwickler, Tester und Testmanager in Scrum

Abbildung von Testing mit Scrum

Die Implementierung von den Unit-, Integrations- und Systemtests übernehmen die Entwickler, Tester arbeiten mit. Um diese Tätigkeiten qualitativ auszuführen bedarf es  guter Kommunikation, analytischer Kenntnisse und methodisches Vorgehen.

Und selbstverständig … Agiles Testen, Tester und Testmanager folgen den Prinzipien des agilen Manifests und wenden die agilen Prinzipien auf das Testen an.

Siehe das Agile Manifest.

21
Sep
Kanban Board (Aktivitäten, Entwickeln, Testen, Relaese, Aufgaben,Bug, Feature)

Scrum oder Kanban

Beide Projektmanagement-Frameworks dienen dem agilen Softwareentwicklungsprozess und unterstützen die Philosophie, dass sich Prozesse und Tools den Individuen und deren Interaktionen unterordnen müssen.

Es sind beides Frameworks zur Ablaufplanung, die auf dem “Just-in-Time”-Prinzip aus der Lagerverwaltung des Leankonzepts basieren. Das Team als zentrale Instanz sagt, wann und wie viel Arbeit in einem bestimmten Zeitraum zu schaffen ist und verpflichtet sich auf die Fertigung. Die Teammitglieder “ziehen” Arbeit heran, wenn sie bereit sind, und bekommen sie nicht von außen „zugeschoben“, wie bei den klassischen Methoden.

Der kontinuierliche und erfahrungsgestützte Verbesserungsprozess, wie es das Kaizen-Prinzip aus dem Leankonzept vorgibt, ist ein wichtiger Bestandteil beider Frameworks.

Scrum oder Kanban?

Scrum hat seine Vorzüge dort, wo es darum geht, sehr flexibel und agil auf geänderte Anforderungen einzugehen.

Kanban stellt das Ziel in den Vordergrund, Probleme im Projekt transparent zu machen und zeitnah effizient zu lösen.

Ähnlichkeiten von Scrum und Kanban

  • beide Frameworks haben ihre Wurzeln in dem Leankonzept und sind agil
  • Beide haben als Basis das Pull-Prinzip (Hol-Prinzip): Die anfallende Arbeit verteilt nicht ein „Supervisor“, sondern die Teammitglieder holen sich ihre Arbeit, um den Produktionsfluss möglichst fließend zu halten
  • Im Brennpunkt stehen bei beiden Flexibilität und maximaler Kundennutzen: schnell und oft ausführbare Software liefern
  • Beide bemühen sich auf kontinuierliche Prozessverbesserung durch Transparenz
  • Die Teams sind selbstorganisierte Teams

Unterschiede

  • Bei Scrum gibt es 3 Rollen(Product-Owner/Scrum Master/Team), und Spielregeln(Dailyscrum, Sprints, Produktbacklog). Kanban Schreibt keine Rollen vor
  • Während es bei Scrum Iterationen mit festem Zeitschema, die sogenannten Sprints gibt, sind bei Kanban die Iterationen mit festem Zeitschema optional
  • Der Prozess ist bei Scrum zeitgetrieben, während es bei Kanban ereignisgetrieben ist
  • Das Team gibt bei Scrum, in der Sprintplanung, sein Commmitment für die Abarbeitung eines bestimmten Arbeitpakets innerlalb des Sprints, während bei Kanban keine bestimmte Arbeitspaketgröße vorgeschrieben ist und das Commitment optional ist
  • Das Schätzen des Aufwands ist bei Scrum vorgeschrieben, während bei Kanban das Schätzen optional ist
  • Bei Scrum gibt es ein priorisiertes Produktbacklog, bei Kanban ist die Priorisierung der Tasks optional
  • In Scrum gehört das Sprintbacklog einem bestimmten Team, ein Kanbanboard kann von mehreren Teams bearbeitet werden
  • Ein Scrumboard wird für jeden Sprint neu eingesetzt, ein Kanbanboard bleibt durchgehend bestehen

Ein Beispiel des KanbanBoards

kanbanboard

Das Kanbanboard besteht aus einem einfachen Whiteboard und Haftnotizen. Jeder Notiz auf dem Board repräsentiert eine Aufgabe und das Stadium der Abarbeitung.

 

Kanban entstammt dem Japanischen. Dort heißt かんばん (看板) so viel wie „Karte“, „Tafel“ oder „Beleg“. Alternative Namen für Kanban sind Hol-, Zuruf- oder Pull-Prinzip. Quelle: Wikipedia

14
Sep
Scrum Grafik (Scrum Master, Product Owner, Product Backlog, Sprint Backlog, Sprint, Daily Scrum)

Klassisches Projektmanagement und Scrum

Klassisches Projektmanagement basiert sich auf Wasserfall Methoden und die Rolle „Projektmanager“ trägt die Verantwortung für den Erfolg des Projekts. Der klassische Projektmanager ist derjenige, der ein Projekt inhaltlich und zeitlich plant und vorantreibt, das Projektbudget verwaltet, die Umsetzung leitet, mit den Stakeholdern kommuniziert und alle erfolgsrelevanten Rahmenbedienungen des Projekts berücksichtigt.

Rollen bei Scrum

Bei Scrum gibt es die Rolle „Projektmanager“ nicht mehr. Dafür gibt es die Rollen „Product Owner“ und „Scrum Master“. Die Aufgaben des klassischen Projektmanagers werden auf diese beiden Rollen verteilt.

Der „Product Owner“ ist für die Vision, die inhaltliche Beschreibung der Anforderungen, die Planung in enger Zusammenarbeit mit dem Team, die Steuerung der Umsetzung und das Budget verantwortlich.

Der „Scrum Master“ sorgt für optimale Arbeitsbedienungen, räumt Hindernisse und Störer aus dem Weg und unterstützt das Team bei fachlichen Problemen.

Klassisches Projektmanagement und Scrum

Die Rolle „Team“ ist bei Scrum sehr wichtig, da es für die Einhaltung der Planung und die Umsetzung, durch das Commitement verantwortlich ist.

Die Verantwortung für den Erfolg eines Projekts tragen bei Scrum alle drei Rollen zussammen.

Der klassische Projektmanager ist durch seine Kenntnisse fähig, beide Rollen zu erfüllen. Man sollte hier prüfen, welcher Teil der Rollen einem am besten liegt:

Treibt man ein Projekt gerne inhaltlich voran, hat kreative Ideen für neue Produkte und kann gut die Budgets verwalten, dann sollte man die „Product Owner“-Rolle wählen. Ist man hingegen eher der „Kümmerer“ und versteht die Technik gut, dann sollte man am besten die „Scrum Master“-Rolle einnehmen.

Es gibt jedoch größere Projekte, die zusätzlich zu den Rollen „Product Owner“ und „Scrum Master“ auf klassisches Projektmanagement angewiesen sind. Ein Projektmanager ist bei größeren Vorhaben eine Notwendigkeit, da es hier nicht nur um die Umsetzung eines Produkts, sondern mehrerer Produkte mit mehreren Schnittstellen geht.

Diese Person sollte dann die Gesamtplanung des Projekts verantworten, die Stakeholder steuern, die Schnittstellen zu anderen Produkten oder Projekten berücksichtigen, Maßnahmen zur Infrastruktur und den erfolgreichen Betriebsübergang treffen, um das Projekt erfolgreich abschließen zu können.

Nächste Seite »
Copyright © 2018 galaniprojects GmbH | Anastasia Galani - Business Consulting. All rights reserved. | Datenschutz und Impressum