Kan man vara agil i en regulatorisk kostym?

Introduktion

Agila utvecklingsmetoder har sedan länge kortat leveranstider, förbättrat produktiviteten, ökat kvaliteten och gjort kunderna nöjdare inom programvaruutveckling. Företag med säkerhetskritiska produkter har även börjat anamma agila metoder. Men säkerhetskritisk utveckling har många regulatoriska krav som gör det svårt att applicera agil utveckling enligt konstens alla regler. Vår erfarenhet är att det är få bolag som lyckats väl. En viktig anledning är att de inte har tillräcklig förståelse för agila metoder eller vad de regulatoriska kraven innebär och då är det svårt att foga dem samman. Men om du skapar dig denna förståelse och fokuserat bearbetar de frågeställningarna som vi belyser i denna artikel så kan du bli AGILARE och mer effektiv än vad du är i dag!

Regulatorisk utveckling

För att kunna sälja säkerhetskritiska system måste producenten kunna visa att den programvara som ingår i systemet är tillräckligt säker, att risken att systemet kan orsaka farliga situationer ligger på en accepterad nivå. För att troligöra detta krävs uppfyllnad av standarder för säkerhetskritiska system som ställer speciella krav på hur programvaran utvecklas och underhålls.

Exempel på standarder är IEC61508 som anpassats för tillämpning i en rad olika domäner (ex: 26262 bil, 62304 medicinsk utrustning och 62061 maskiner).
Generaliserat kan de flesta säkerhetskritiska standarder summeras i fem principer för programvara:

1. Säkerhetskraven ska adressera programvarans bidrag till hantering av systemrisker
2. Säkerhetskraven skall hållas intakta under nedbrytning och implementering
3. Säkerhetskraven ska vara uppfyllda och verifierade
4. Riskfyllt beteende av programvaran ska identifieras och reduceras till acceptabel nivå
5. Nivån på säkerhetsaktiviteterna skall stå i proportionerligt till systemets risknivå

Dessutom finns organisatoriska förväntningar rörande policy, kultur, kvalitetssystem, processbeskrivningar, roller och ansvar, utbildning och kvalifikation.

Agil utveckling

Allt för många kommer med åsikter kring agil utveckling som delvis bygger på missförstånd.
”Man får inte dokumentera i agile – det går inte för oss”,  eller
”Vi är agila, vi har morgonmöte och en tavla över pågående aktiviteter – det passar utmärkt för säkerhetskritisk utveckling”. Två exempel på uttalanden som vi möter i vår vardag.

För att förstå agil utveckling  behöver man känna till:

• Agila Manifestet
• Agila Principer
• Metoder och verktyg (Scrum, XP, DSDM, SAFe, LeSS, Kanban, Devops, m.fl.)

Vilka principer och verktyg man väljer att fokusera på skall kopplas till de effekter man är ute efter:

• För snabbare utveckling kan Lean SW vara rätt verktyg
• För att öka kvaliteten kan TDD eller XP vara det som ger bäst effekt
• För att säkra leveranstider kan Scrum ge önskat resultat

Hur agila kan vi vara?
Agil utveckling är inte antingen eller utan en glidande skala. Varje bolag måste hitta var på denna skala man bör befinna sig. Att systemet är säkerhetskritiskt är bara är en av många faktorer som påverkar hur agil man bör vara. 

Några av dessa faktorer är:

• Hur många ingår i utvecklingen av programvaran – ju fler utvecklare desto mer struktur krävs
• Geografiska placeringen av utvecklarna  - om teamet inte befinner sig på samma plats försvåras det agila arbetet
• Utvecklarnas erfarenhet – oerfarna kräver ett mer uppstyrt/dokumenterat arbetssätt
• Systemets komplexitet – både systemnivå och programvarunivå påverkar mängden inledande arbete och dokumentation som krävs
• Rör det sig om ett helt nytt system eller en modifiering av en existerande produkt? Ett helt nytt system kräver mer inledande arbete (teknisk lösning, arkitektur, planering, mm) i jämförelse med vidareutveckling av befintliga produkter
• Leverantörer kräver avtal, specifikationer och uppföljning, omfattning beroende på relation, erfarenhet, kommunikationskultur och antal
• Säkerhetskritiskt, kräver uppfyllnad av olika standarder, vilket innebär mer struktur

Agil utveckling och regulatorisk utveckling – inte utan konflikt

För att leva upp till kraven i de säkerhetskritiska standarderna, se tidigare punkter 1-5, förväntas bla:

• Dokumentation
  • Produktdokumentation (ex: krav, arkitektur, design, och testrapporter)
  • Processdokumentation (ex: processbeskrivningar, mallar)
  • Projektdokumentation (ex: planer, granskningsrapporter)
• Dubbelriktad spårbarhet mellan krav, arkitektur, kod och test
• Granskningar av kod och dokumentation
• Fokus på risk aktiviteter
• Oberoende granskning av efterlevnad
• Validerade verktyg

Mycket av dessa förväntningar står i konflikt med delar ur det ”Agila Manifestet”

Det finns ett antal andra specifika problemområden som man behöver hantera:

• Strukturen i de regulatoriska standarderna inbjuder till silos med många överlämningar. Det är tyvärr vanligt att säkerhetskoncept, systemkrav, mjukvarukrav, funktionsbeskrivning och design & kodning görs av olika team (Safetyteam, Systemarkitekt, SW Arkitekt, Produkt ägare och utvecklingsteam).
• De säkerhetskritiska standarderna är skrivna med fokus på implementering och verifiering  av krav, arkitektur via mjukvarukomponenter. Agil utveckling har ortogonalt fokus – implementering av funktioner som skär igenom delar av krav och olika komponenter. Så utmaning är att få taktning och spårbarhet och mellan krav och komponenter och de funktioner som implementeras både vad gäller verktyg och process.
• Vid agil utveckling är tidplan och resurser låsta och flexibiliteten skapas genom justering av funktionsinnehåll. När den givna tiden är slut skall man ha implementerat det viktigaste (kundnytta). Vid  regulatorisk utveckling går det inte att prioritera bort den del av produkten som har säkerhetskritisk funktionalitet  för att tiden tagit slut. Detta ger en mer komplex prioritering.
• Avslutningsvis är det svårt att leverera ofta till kund. Det kan dels vara beroende av hårdvara men framförallt kräver säkerhetskritiska system omfattande verifiering och validering innan produkten kan tas i bruk.

Det finns metoder som försöker kombinera  agilt med säkerhetskritisk utveckling, ex SafeScrum som är en metod för att använda Scrum tillsammans ISO 61508. Men eftersom SafeScrum ser det säkerhetsrelaterade (ex. krav och arkitektur) som statiskt och skall genomföras innan utvecklingen börjar, blir det agila arbetssättet ytterst begränsat.

Strategi för att få till en agil utvecklingsmodell vid säkerhetskritisk utveckling

För att få en agil utvecklingsmodell bör man utreda två frågeställningar:

• Hur kan vi leva upp till regulatoriska krav på ett så agilt sätt som möjligt?
• Vilka och hur kan vi applicera agila principer (trots) regulatoriska krav?

Regulatoriska krav på ett agilt sätt

Vilka delar av produkten är säkerhetskritisk och skall uppfylla de regulatoriska kraven? Är det hela systemet eller kan vi definiera arkitekturen på ett sådant sätt att vi kan isolera det säkerhetskritiska till specifika delar? Att förstå produktens användning och hur systemet samverkar med sin omgivning är centralt för att etablera en effektiv systemarkitektur.

Det finns som sagt en hel del extra förväntningar (safety krav, produktdokumentation, spårbarhet). Alla dessa aktiviteter och dokument som skall göras/skrivas för beaktas med följande frågor:

• Vad måste tas fram initialt? (ex någon nivå av safety case, krav och arkitektur)
• Vad kan göras löpande i det iterativa flödet (krav, implementering och planer)
• Vad kan göras informellt i de löpande sprintarna och formellt efter sista sprinten (formella granskningar av krav, arkitektur o design + test rapport)
• Vad kan göras som specifika aktiviteter i utvalda iterationer (ex speciella tester)

Kan nya möten/dokument undvikas utan istället få med det i existerande aktiviteter/dokument. (ex kan delar av QA göras i retrospektiven? Kan risker följa upp på projektmöte istället för egna risk-möten?)

En av de största utmaningarna för att kunna arbeta agilt med den omfattande dokumentation (krav, arkitektur och projektplaner) är att hitta balansen mellan hur mycket utredning, specifikation och planering som behöver göras innan utvecklingen startar, vad som kan göras löpande samt hur mycket dokumentation som kan göras i efterhand. Det sparar både tid och ökar kvaliteten att inte ha hela pusslet klart utan att låta den växa fram. I de tidiga faserna är konsistensen, att rätt objekt finns och hänger ihop, viktigare än att de skall vara kompletta. Men att starta för tidigt utan tillräcklig förståelse kan bli väldigt kostsamt då det kan leda till att man måste göra om stora delar sent i projektet.

En viktig aspekt är vem som gör det säkerhetskritiska arbetet? Det görs det ibland av safety managers/ingenjörer parallellt med utvecklingsprojekten – ett mer agilt sätt är att se till att det sker tillsammans med övriga i projektet – att dessa personer blir del av teamen – även om de har fokus på safety. Lite på samma sätt som testare i ett utvecklingsteam fokuserar på test. Men det behövs fortsatt en central funktion som ser till den övergripande systemsäkerheten och behåller en oberoende ställning mot utvecklingsteamen.

Avslutningsvis förväntar sig de flesta standarderna ett etablerat arbetssätt. Men det behöver inte bli tjocka pärmar utan det finns mer effektiva sätt att få arbetssättet att sitta i väggarna.

Agila Principer i en regulatorisk värd

Även om utvecklingen är säkerhetskritisk finns ett antal principer som man kan anamma för ett mer agilt arbetssätt:

Kundfokus - hur säkerställer vi en kontinuerlig dialog med kunden? Många gånger har man inte möjlighet att ha kunden tillgänglig utan en egen proxy måste skapas – Produktägaren. En viktig lärdom är att för att täcka in komplexa system är detta snarare är en funktion än en individ. Säkerhetskrav behöver också täckas av denna produktägarfunktion. För att inte arbeta för länge utan riktig kundåterkoppling är det viktigt att definiera en ”MVP” (Minimum Viable Product) dvs den minimala produkt som ändå är tillräckligt stor för att få kundåterkoppling. Den kan vara för begränsad användning men ändå ge skarp användarerfarenheter. Ur ett säkerhetskritiskt perspektiv får kanske inte produkten användas skarpt, då gäller det att skapa ett så verklighetstroget scenario som möjligt för att kunden ändå skall kunna ge återkoppling.

Prioritering – en central aspekt i utvecklingen är att få till en löpande prioritering av arbetet. Produktägarfunktionen måste balansera prioriteringen av kundnytta och systemförståelse med information från utveckling för kostnad, utvecklingsordning och tillgänglig kompetens. Denna prioritering behöver sedan var tydlig för hela projektet. Ur säkerhetskritiskt perspektiv måste det innehåll som är del av säkerhetskonceptet prioriteras tidigt för det går inte att prioritera bort i det fall tiden är slut och funktionalitet skall avgränsas.

Planering -  agilt arbete är både inkrementell (stegvis utveckling) och iterativ (stegvis förfining). Se  Mona lisa exempel [Thomas/Patton]

För att lyckas med detta krävs planering – både att få den övergripande planeringen på plats och sedan etablera modell för den löpande planeringen.  För säkerhetskritisk utveckling behöver det övergripande arbetet/planeringen vara mer omfattande då man behöver etablera mer strukturer. Den löpande planeringen behöver hantera:

• Kontroll över vilka krav/funktioner som är klara och redo att utvecklas och vad behöver mer utredning
• Nedbrytning av större uppgifter för att de inte skall löpa över flera sprintar
• Beroenden och synkronisering mellan olika team

Ändringar - hur kan vi etablera ett arbetsflöde där man strukturerat kan ta in, utvärdera och inkludera ändringar? Ett sätt är att efter varje sprint i samband med sprint-review och demo öppna för synpunkter/återkoppling och ändringar. Det är viktigt att tydliggöra att ändringar av fungerande funktionalitet går ut över ännu ej realiserad funktionalitet. Att avgöra om det är bättre med färre riktigt bra funktioner än många fungerande funktioner är ett affärsbeslut. Det bör inte vara ett  beslut för ett utvecklingsteam (speciellt då utvecklingsteam är längre ifrån produktförståelse när det gäller många säkerhetskritiska produkter). En annan  viktig aspekt är att ha olika kontrollnivå på ändring om det är implementerat eller ej.

Agila utvecklingsprinciper

• Designen kräver kontinuerlig justering/förbättring. När strukturen känns besvärlig är det dags att omdesigna – att vänta gör det bara svårare
• Håll koden ren – refaktorera kontinuerligt. Dålig kod saktar ner utveckling och skapar fel
• En gemensam kodbas där alla strävar efter att leverera dagligen
• Kodbasen med tillhörande dokumentation skall alltid vara i levererbart skick - tillåt aldrig att kvaliteten degenererar
• Unit tester, helst framtagna i förväg som sämst parallellt med koden. Ett riktmärke på coverage är att koden skall kunna återskapas med unit test casen som guide.

Visualisera, en bild säger mer en tusen ord, system, arkitektur, planer och progress mår bra av att visualiseras. Det förbättrar dialogen inom och mellan teamen.

Tvärfunktionella team, med tydligt mandat att besluta över sina funktioner. Som komplement behöver komponentägarskap definieras för att inte de enskilda komponenterna degenererar. Komponentägaren skall gärna fungera som ”maintainer rollen” i open source utveckling. Beslut på rätt ställe ökar engagemang och åtagande. Dessutom minskar beroenden och överlämnanden. Men högpresterande team är inget man får direkt utan kräver fokuserat arbete.

Minimera dokumentation, i säkerhetskritisk utveckling finns krav på att mycket (produkt, process och projekt) skall dokumenteras och granskas. Men det går att påverka detaljnivå och effektivitet i hantering. Att ta fram dokument för överlämning (Krav-Design-Kod-Test) utan diskussion resulterar ofta i hög detaljnivå, vilket är dyrt att ta fram och underhålla. Tvärfunktionella team kan minska antalet överlämnanden och för de överlämningar som kvarstår bör dessa innefatta både diskussion och dokument. Fokus måste ligga på att dokumentationen ska vara värdefull för utvecklarna, testarna och organisationen och inte enbart vara något man gör för att få sin produkt certifierad. Ett effektivt dokumenterat system och arbetssätt är avslutningsvis en av förutsättningarna för en långsiktigt framgångsrik utveckling.

Leverera ofta, (fungerade mjukvara) är en utmaning för säkerhetskritiska produkter som inte kan sättas i bruk i halvfärdigt skick. Men även om produkten inte är färdig eller säker att använda finns många fördelar med att leverera ofta, även om det bara är till interna intressenter. Det bygger förståelse, ökar samsyn och synliggör kvalitet och status.

Kontinuerligt lärande, tillsammans med ständig förbättring är en viktig agil princip. Att få till retrospektiv som trimmar teamets arbetssätt är viktigt. Att våga ändra och förbättra är centralt för högpresterande team och projekt. Det kräver att man tvärs igenom organisationen tillåter misslyckanden så länge vi gör det snabbt och lär av det! Alternativet är att hinder blir kvar och genererar frustration och hindrar produktivitet.

Sammanfattning

Säkerhetskritisk utveckling kräver avsteg från det agila manifestet och de agila principerna. Men det går ändå att få en utvecklingsmodell som uppfyller de regulatoriska kraven och samtidigt är relativt agil. Vi är övertygade om att en organisation som arbetar igenom de två frågeställningarna:

• Hur kan vi leva upp till regulatoriska krav på ett så agilt sätt som möjligt?
• Vilka och hur kan vi applicera agila principer (trots) regulatoriska krav?

kommer kunna etablera ett långt mer agilt och framgångsrikt arbetssätt.