Riskfaktorer - M0hammed-1brahim/frugalCompany GitHub Wiki
Risklista – Webbutvecklingsprojekt (Frugal Company)
Risklistan hjälper till att förutse och hantera tekniska, funktionella och organisatoriska risker under hela projektets livscykel.
# | Risknamn | Beskrivning | Sannolikhet (1–5) | Konsekvens (1–5) | Prioritet | Bevakningsstrategi | Konsekvensstrategi | Sannolikhetsstrategi |
---|---|---|---|---|---|---|---|---|
1 | Frontend är hårdkodad mot produkter | Produkter är hårtkodade i HTML istället för databas – svårt att byta backend utan omskrivning. | 4 | 5 | 20 | Granska beroenden, dokumentera frontenddelar. | Separera frontend och datalager, använd komponentstruktur. | Iterativt byta till databaskopplingar i små steg. |
2 | Cart-funktion beroende av statisk data | Cart-logik använder fasta ID:n och kategorier – kan krascha vid datamodelländring. | 3 | 5 | 15 | Testa med olika produktdata varje iteration. | Gör cart oberoende av hårdkodad data, inför serversidevalidering. | Generalisera cart-hantering från början. |
3 | Tillgänglighetsbrister (WCAG) | Knappar saknar tillgängliga namn, låg kontrast – underkänns av WCAG-tester. | 5 | 4 | 20 | Automatiska tester (Lighthouse) i varje release. | Refaktorera UI med semantiska element och färgkontrast. | Lägga till WCAG-checklistor i kodgranskningar. |
4 | Databaslogik saknar stöd för sortering/filter | SQL-backend stödjer inte filtrering/sortering som efterfrågas i frontend. | 3 | 4 | 12 | Säkerställ API-stöd tidigt för filtrering. | Lägg in ORDER BY , WHERE i SQL redan från början. |
Skriv funktioner som är utbyggbara från början. |
5 | Ingen felhantering för cart- eller db-fel | Saknade produkter eller buggar i cart ger krascher utan feedback till användare. | 2 | 4 | 8 | Loggning & fallbackmeddelanden vid fel. | Använd try-catch och visa användarvänliga felmeddelanden. | Skriv enhetstester för edge cases (saknad data, trasig input). |
6 | Bristande säkerhet vid inloggning | Inloggningssystem saknar lösenordskryptering eller validering – känslig data kan exponeras. | 4 | 5 | 20 | Säkerhetsgranskning i varje release. | Implementera kryptering, använd HTTPS och datavalidering. | Använd beprövade bibliotek för auth och session-hantering. |
7 | Krav ej implementerade i tid | Funktionella krav (t.ex. produktalternativ, inloggning) ej implementerade före deadline. | 3 | 4 | 12 | Sprint-review varje vecka med checklistor. | Prioritera MVP-krav först, flytta lågprioriterade krav till backlog. | Dela upp stora krav i mindre delmål och jobba agilt. |
8 | Oklara ansvarsroller i teamet | Ingen ansvarig för testning, deployment eller kodgranskning – kan leda till buggar eller förseningar. | 2 | 3 | 6 | Använd GitHub issues med ansvariga. | Dokumentera processer (t.ex. release-steg, testplaner). | Tilldela roller tidigt, t.ex. "testansvarig", "dokumentation". |
9 | För hög komplexitet i cart-logik | Många beroenden och villkor i cart.php gör testning och felsökning svår. |
3 | 3 | 9 | Dela upp cart-logik i separata funktioner. | Dokumentera varje del av logiken tydligt. | Refaktorera tidigt och skriv enhetstester för varje funktion. |
Notiser: Kraven med alternativ produkter genom databasen och cart-funktionalitet som ska elimineras tidigt i koden efter skapandet av hårtkodad frontend i kod basen. Det gör så att det blir svårt att byta till databasen med samma kod och logic. Ex. utvalda produkter och borttagning av dessa produkter inom cart-funktion.