Risk Management - sapacaFaceRecognition/Documentation GitHub Wiki
Die risk prob von 0% hat sich mit der Zeit entwickelt und sind nur noch wegen Archivzwecken da
| Risk Name | Risk Description | Risk Probability of Occurrence | Risk Impact (1-10) | Risk Factor | Risk Mitigation | Person in Charge |
|---|---|---|---|---|---|---|
| Klausurenphase | Zeitplanung des Projekts wird negativ,durch Klausurenphase beeinflusst. | 75% | 10 | 7.5 | - Frühzeitige Planung von Aufgaben - Detailierte Planung - Weniger Requirements - Weniger prokrastinieren, mehr lernen | C |
| Unrealistische Zeitschätzung | Projekt kommt in Verzug durch unrealistische Zeitschätzung | 50% | 8 | 4 | - Aufgaben in kleine Tasks zerlegen, einfacher abzuschätzen - Im Vorfeld über Aufgaben informieren, um diese besser abschätzen zu können- Zeit zum Testen planen | S |
| Fehlendes Wissen,Teammitglieder | Fehlendes Wissen der Teammitglieder,führt dazu, dass UCs evtl nicht vollständig implementiert werden können. | 25% | 9 | 2.25 | - Ständige Kommunikation zw. Mitgliedern - Genaue Einschätzung der einzelnen Requirements | P |
| Falsche/Unnötige Funktionen werden implementiert | Falsche/Unnötige Funktionen werden implementiert, dadurch wird Zeit verloren | 25% | 7 | 1.75 | - Bei Implementierung auf Requirements achten | P |
| Ausfall Mitglieder | Mitglieder fallen z.B. wg. Krankheit aus | 20% | 7 | 1.4 | - Detailierte Beschreibung der Aufgaben - Ständiger Austausch zw. Mitgliedern | S |
| Response Zeit der Anwendung zu hoch | Response Time der Face Detection/get Attributes wird > 5s, da Algorithmus hohe Komplexität hat | 25% | 4 | 1 | - Saubere Implementierung, v.a. keine unnötigen Funktionsaufrufe, Konstanten aus Schleife ziehen | C |
| Fehler beim Mergen | Durch fehlerhaftes Mergen von Branches auf GitHub können Fehler auf dem Master Branch entstehen | 5% | 5 | 0.25 | - Sauberes Mergen von Branches - Mergen auf neuen branch | C |
| UC/Requirements nicht umsetzbar | UC/Req werden definiert, die aber wegen fehlendem Wissen oder technischer Unmöglichkeit nicht umgesetzt werden können | 0% | 10 | 0 | - Genaue Einschätzung der Req/UC - Umsetzbarkeit prüfen - Zu komplexe UC/Req streichen | P |
| Änderung der Requirements | Requirements werden mehrfach abgeändert und dadurch wird Zeit verloren | 0% | 9 | 0 | - Genaue Definition der Requirements - Ständige Evaluierung der Requirements | C |