Forbrugsregnskab
Offentliggjort til orientering. Må ikke anvendes som gældende procedure, jf. P-01 § 3.
Softwareudvikling, release og ændringsstyring
Beskriver udvikling, test, frigivelse og ændring af IT-platformen.
1Formål og omfang
Proceduren beskriver, hvordan IT-platformen, der er produktionsudstyret for forbrugsregnskaberne, udvikles, testes, frigives og ændres. Udvikling og ændringer skal være planlagte, testede og godkendte, og regnskabslogikken skal være verificeret mod lovkrav. Drift, sikkerhed og backup kontrolleres løbende. Proceduren gælder al udvikling, uanset om den udføres af Dansk Forbrugsregnskab eller eksterne leverandører.
2Roller
| Rolle | Ansvar |
|---|---|
| Produkt- og platformansvarlig (Dansk Forbrugsregnskab) | Ejer backlog, prioritering, kravspecifikation, acceptkriterier, accepttest og frigivelse; ejer driftsaftale med Azure og udviklingspartner |
| Udviklingspartner (Foundry IX — teknisk/projektledelse, frontend) | Design, implementering, enheds-/integrationstest, kodegennemgang, deployment efter aftale, teknisk dokumentation, ugentlig status i projektstyringsværktøjet |
| Regnskabsansvarlig / teknisk ansvarlig | Faglig verifikation af regnskabs- og målerlogik (testcases, referenceregnskaber) |
| Kvalitetsansvarlig | Sikrer, at release-registreringer foreligger; auditerer processen |
3Planlægning (8.3.2)
Arbejdet planlægges i projektstyringsværktøjet med ugentlige milepæle. For hver milepæl fastlægges mål, måldato og afhængigheder. Opgaver registreres med kilde (krav, kundemøde eller driftsfund) og status, og fremdriften følges ugentligt.
4Krav (8.3.3)
Krav dokumenteres som opgaver i projektstyringsværktøjet med acceptkriterier. Kravkilder: lovgivning (lejelov, individuel måling, BEK 545, EED, GDPR), kundeaftaler, designprincippet om enkelhed for slutbrugeren, sikkerhedskrav (adgangsstyring pr. rolle: beboer, installatør, ejendomsadministrator, global administrator; kryptering; logning) og ikke-funktionelle krav (ydelse, tilgængelighed, backup). Modstridende eller uklare krav afklares, før udvikling starter.
5Design, udvikling og styring (8.3.4)
- Arkitekturbeslutninger dokumenteres i kodebasen eller projektstyringsværktøjet; regnskabsmodulets beregningsregler er beskrevet i en fagspecifikation.
- Kode versioneres i git; ændringer udvikles på branches og integreres via pull requests efter review. Automatiske tests kører ved hver integration.
- Miljøer: udvikling og produktion. Produktionsdata anvendes ikke i udvikling; testdata er syntetiske eller pseudonymiserede (GDPR).
- Ved afslutning af hver cyklus gennemgås status mod plan og krav sammen med udviklingspartneren.
6Verifikation og validering (8.3.4 c–d, 7.1.5.1)
Før en ny version tages i brug, testes den i fire trin:
- Automatiske test. Koden testes automatisk ved hver ændring, og alle test skal bestås.
- Referenceregnskaber. Et fast sæt regnskaber med kendt, korrekt resultat, vedligeholdt i kodebasen, beregnes igen og skal give samme resultat til øre. Når der findes en fejl i produktion, tilføjes et referenceregnskab, der dækker fejlen.
- Accepttest. De nye funktioner afprøves mod acceptkriterierne, som beboere, administratorer og montører vil bruge dem. Resultatet dokumenteres i projektstyringsværktøjet.
- Sikkerhed og backup. Ved ændringer i adgang, kryptering eller infrastruktur gennemgås sikkerheden, og ved større releases testes det, at data kan genskabes fra backup.
7Frigivelse (8.3.5, 8.6)
- Alle acceptkriterier opfyldt og accepttest dokumenteret.
- Automatiske test og referenceregnskaber bestået; resultat vedlagt.
- Release registreret i projektstyringsværktøjet: version, ændringer, kendte begrænsninger og evt. behov for genberegning eller kundeinformation.
- Frigivelse godkendt af ledelsen (dato, version, registreret i projektstyringsværktøjet).
8Ændringsstyring (8.3.6, 8.5.6)
- Alle ændringer (nye funktioner, fejlrettelser, konfigurations- og infrastrukturændringer i produktion, ændringer i ordregrundlagsparametre med bred effekt) registreres som en opgave (issue) i projektstyringsværktøjet med begrundelse og godkendelse.
- Ændringer, der påvirker allerede udsendte regnskaber, behandles efter P-03 (afvigende output).
9Drift, sikkerhed og kontinuitet
- Produktion kører i Microsoft Azure. Adgang styres via sikkerhedsgrupper med mindst-privilegium og gennemgås halvårligt.
- Alarmer for tilgængelighed, fejlrate, ingestion-stop og databaseforbrug tilgår ledelsen og udviklingspartneren.
- Backup: automatisk daglig backup / point-in-time restore af databasen; opbevaring 35 dage; restore-test mindst årligt, dokumenteret i projektstyringsværktøjet.
- Krypteringsnøgler til målere og hemmeligheder opbevares i Azure Key Vault; adgang logges.
- Sikkerhedshændelser og databrud håndteres efter GDPR-proceduren og registreres i R-04.
10Dokumentation og registreringer (8.3.2 j, 7.5)
Kravspecifikationer og acceptkriterier (projektstyringsværktøjet), arkitekturspecifikation (repository), testrapporter og referenceregnskabs-resultater, releases med godkendelser, ændringsanmodninger (projektstyringsværktøjet), ugentlige statusrapporter, backup/restore-test, adgangsgennemgang.
RRevisionshistorik
| Version | Dato | Ændring | Udarbejdet | Godkendt |
|---|---|---|---|---|
| 0.1 | 16.09.2026 | Udkast | MNP | — |
Udskrevet — ukontrolleret kopi. Seneste gengivelse: https://quality.danfor.dk/docs/P-08/