Systemudvikling (eng, systems engineering) som disciplin, omfatter mange aspekter som systemtænkning, arkitektur, processer og terminologi. Den moderne systemudvikling har i høj grad været udviklet af NASA flere årtier tilbage, hvorefter den har spredt sig til mange andre brancher som forsvar, luftfart, medicin, it og kompleks systemudvikling. Denne udbredelse drives af, at systemerne vokser i størrelse og kompleksitet, som igen får udviklingsarbejdet til at vokse eksponentielt, da flere og flere elementer kombineres og taler med hinanden. Systemgrænserne vokser hermed voldsomt, og grænseflader kræver koordinering mellem diverse udviklingsgrupper, hvilket kræver god projekt- og teknisk ledelse.

Kompleksiteten afspejles også i en ofte brugt definition af begrebet system:

Et system er en sammensætning af dele eller elementer, der interagerer og samarbejder om at danne en samlet helhed, og som ofte frembringer adfærd eller resultater, som de enkelte dele ikke kan opnå alene.

Som det fremgår, at det svært at arbejde med systemer, og det kræver i høj grad, at man mestrer mange tilhørende processer. Denne artikel giver et overblik over to meget anvendte standarder, og deres indhold. Et alternativt syn er CMMI, som dækker mange af de samme emner.

ISO 15288

ISO 15288 er en international standard for system- og softwareudvikling. Den fastlægger en fælles ramme og et sæt af processer til at styre hele livscyklussen for menneskeskabte systemer – fra idé og udvikling til produktion, drift og afvikling.

Figur: Oversigt over den tekniske udvikling, som ISO 15288 tager udgangspunkt i.

ISO 12207

ISO 12207 ligner ISO 15288 meget, og dækker de samme discipliner, men har alene fokus på softwarekomponenter og software-baserede elementer. De to standarder fungerer godt sammen, hvor de dækker hver deres felt. Dette samarbejde blev styrket ved sidste opdatering af de to, hvor de fik harmoniseret deres procesmodeller og terminologi, som beskrevet herunder.

Den harmoniserede procesmodel og praktisk anvendelse

Standarden inddeler livscyklusprocesserne i fire hovedkategorier:

1. ·         Organisatoriske projektprocesser: Styrer virksomhedens overordnede ressourcer, portefølje og projektstyring.
2. ·         Aftaleprocesser: Håndterer køb og salg mellem organisationer (f.eks. leverandør- og kundeanskaffelse).
3. ·         Projektprocesser: Styrer det daglige arbejde i et specifikt projekt (f.eks. risikostyring, planlægning og kvalitet).
4. ·         Tekniske processer: Dækker selve ingeniørarbejdet (f.eks. kravspecifikation, design, integration, verifikation og validering).

Dette er vist på figuren herunder (med de originale engelske tekster).

Figur: Den harmoniserede procesmodel. De organisatoriske projektprocesser er røde, aftaleprocesser er orange, projektprocesser er blå og tekniske processer er grønne.

Figuren skal ses som en forståelsesmodel og ikke som en sekventiel proces foreskrevet af standarden. ISO understreger netop, at processerne kan anvendes iterativt og samtidigt samt rekursivt på systemets elementer, og at 15288 ikke foreskriver en bestemt udviklingsmetode eller livscyklusmodel.

I praksis foregår flere processer hele tiden. Eksempelvis kører Risk Management, Configuration Management, Decision Management og Information Management parallelt med krav, arkitektur, design, integration og verifikation.

Man vil også typisk iterere, og udnytte den opnåede viden:

indtil løsningen er tilstrækkeligt moden.

Standardens formål er netop at skabe et fælles proces- og begrebsramme gennem hele et systems livscyklus snarere end at foreskrive én bestemt udviklingsmetode.

Organisatoriske projektprocesser

Der indgår seks processer i denne gruppe, som etablerer de organisatoriske betingelser, som projekter og programmer arbejder indenfor.

Life Cycle Model Management (Styring af livscyklusmodeller)

Formål: At organisationen etablerer, vedligeholder og forbedrer de modeller og processer, der anvendes til systemudvikling. Der er tale om en slags metatænkning over den måde, hvor systemudviklingen sker, så organisationen arbejder bedst muligt.

Typiske emner som kan indgå:

• udviklingsmodeller
• stage-gate-modeller
• V-model (skal ikke læses som ”vandfaldsmodel”, som er en projektmodel)
• agile/hybride modeller
• engineering standarder
• standardiserede workflows.

Svarer på: "Hvordan arbejder vi systematisk med systems engineering?"

Infrastructure Management (Infrastrukturstyring)

Formål: At sikre den nødvendige infrastruktur til gennemførelse af projekterne.

Typiske emner er:

• IT
• udviklingsværktøjer
• laboratorier
• testfaciliteter
• produktionsudstyr
• kommunikationssystemer.

Svarer på: "Hvordan understøtter vores infrastruktur bedst muligt vores projekter?"

Portfolio Management Process (Porteføljestyring)

Formål: At sikre at organisationen vælger, prioriterer og styrer de rigtige projekter.

Dette omfatter eksempelvis:

• prioritering af projekter
• ressourcetildeling
• investeringer
• business cases
• strategisk alignment
• stop/go-beslutninger.

Svarer på: "Hvordan bruger vi bedst muligt vores ressourcer?"

Human Resource Management (Kompetence- og ressourcestyring)

Formål: At sikre, at organisationen har de nødvendige menneskelige kompetencer.

Typiske emner er:

• kompetencebehov
• bemanding
• uddannelse
• træning
• kompetenceudvikling
• specialistkompetencer
• videndeling.

Svarer på: "Hvordan får vi den optimale bemanding og kompetence?"

Quality Management (Kvalitetsstyring)

Formål: At etablere organisationens rammer for at sikre kvalitet i processer og leverancer.

Typiske emner er:

• kvalitetsmål
• kvalitetsprocedurer
• audits
• kvalitetsopfølgning
• løbende forbedringer.

Svarer på: "Hvilken kvalitet skal vi opnå og opnår vi denne?"

Knowledge Management (Videnstyring)

Formål: At sikre at relevant organisatorisk viden bliver opsamlet, bevaret, delt og genanvendt.

Eksempelvis gennem metoder som:

• lessons learned / retrospektives
• tekniske erfaringer
• designprincipper
• best practices
• ekspertviden.

Svarer på: "Hvilken viden er vigtig for os, og hvordan bevarer og bruger vi den?"

Aftaleprocesser

Denne gruppe omfatter to processer som er relateret til kunde-leverandør relationen. Afhængig af organiseringen kan begge parter være både interne og eksterne.

Acquisition (Anskaffelsesprocessen)

Formål: At anskaffe et produkt, en ydelse eller et system, som opfylder køberens behov.

Typisk omfatter processen:

• definere hvad der skal anskaffes
• fastlægge krav og acceptkriterier
• vælge leverandør
• etablere aftale eller kontrakt
• følge leverandørens leverancer
• acceptere den endelige leverance.

Svarer på: "Hvordan sikrer vi, at vi køber det rigtige system på de rigtige betingelser?"

Supply (Leveranceprocessen)

Formål: At levere et produkt eller en service til en kunde i overensstemmelse med en aftale.

Typiske områder:

• analysere kundens behov
• udarbejde tilbud
• etablere leveranceaftale
• planlægge leverancen
• gennemføre aftalen
• overdrage produkt/system
• dokumentere opfyldelse.

Svarer på: "Hvordan sikrer vi, at vi leverer det aftalte?"

Projektprocesser

Gruppen af projektprocesser omfatter i alt otte processer. Hvor de herover beskrevne processer har fokus på organisationen, så har denne gruppe fokus på styringen af det konkrete systemprojekt.

Project Planning (Projektplanlægning)

Formålet er: At etablerer planer for gennemførelse af projektet.

Dette omfatter typisk:

• aktiviteter
• tidsplan
• milepæle
• ressourcer
• ansvar
• tekniske reviews
• leverancer
• risici.

Svarer på: "Hvordan opnår vi projektets mål?"

Project Assessment and Control (Projektevaluering og -styring)

Formål: At sammenholde faktiske resultater med projektplanerne og iværksætte korrigerende handlinger. Dette er baseret på klassisk PDCA (Plan-Do-Check-Act).

Man overvåger eksempelvis:

• tid
• økonomi
• modenhed
• kvalitet
• tekniske resultater
• risici.

Svarer på: "Hvilken fremdrift har vi i forhold til projektets plan?"

Decision Management (Beslutningsstyring)

Formål: At tage strukturerede beslutninger mellem alternative løsninger.

Et eksempel på dette er: Tre forskellige systemarkitekturer vurderes efter:

• performance
• cost
• risiko
• sikkerhed
• levetid
• maintainability.

Resultatet er en dokumenteret beslutning og dens rationale.

Svarer på: "Hvad er den bedste løsning?"

Risk Management (Risikostyring)

Formål: At identificere og håndtere risici gennem projektets/systemets livscyklus.

Risici kan være:

• tekniske
• kommercielle
• projektmæssige
• operationelle
• sikkerhedsrelaterede (cybersikkerhed såvel som personsikkerhed).

Svarer på: "Hvilke risici eksisterer og hvordan håndterer vi dem bedst?"

Configuration Management (Konfigurationsstyring)

Formål: At sikre kontrol over hvilke versioner og konfigurationer, der udgør systemet.

Et eksempel på et emne er: Hvilken hardware, firmware, software og dokumentation udgør systemversion 1.3?

Typiske elementer:

• configuration identification
• baseline
• change control
• configuration status
• versionsstyring
• configuration audits.

Svarer på: "Hvad udgøres systemet af, og hvordan styrer vi indholdet?"

Information Management (Informationsstyring)

Formål: At styre projektets og systemets information.

Det kan omfatte mange forskellige typer af informationer eksempelvis:

• specifikationer
• tegninger
• modeller
• testresultater
• beslutningsgrundlag
• dokumentation
• adgang og distribution.

Svarer på: "Hvilke informationer er vigtige for os og hvordan finder vi dem?"

Measurement (Måleprocessen)

Formål: At etablere og anvende målinger til støtte for ledelse og tekniske beslutninger.

Det er vigtigt at måle det, som er vigtigt for projektets styring. Eksempler på dette er:

• fejlrate
• udviklingsprogression
• systemperformance
• kravdækning
• test coverage
• estimeringspræcision
• modenhed.

Svarer på: "Hvad har vi brug for at vide, og hvordan måler vi det?"

Quality Assurance (Kvalitetssikring)

Formål: At skabe tillid til, at processer og leverancer opfylder de relevante krav.

Det kan eksempelvis ske gennem:

• reviews
• audits
• compliance-kontrol
• proceskontrol
• opfølgning på afvigelser.

Svarer på: "Kan vi stole på vores processer og arbejdsprodukter?"

Tekniske processer

Dette er den klart største gruppe, som består af hele 14 processer. De kan underinddeles i følgende fire kategorier, som følger en typisk udviklingslivscyklus:

• Konceptudvikling (kunde- og interessentkrav)
• Systemudvikling (systemkrav, arkitektur og design)
• Systemrealisering (implementering, integration, verifikation og validering)
• Systemanvendelse (idriftsættelse, drift, vedligehold, udfasning).

Hver proces er beskrevet herunder.

Business or Mission Analysis (Forretnings- eller missionsanalyse)

Formål: At forstå forretningsbehovet og etablere vejen til det tekniske system.

Der identificeres eksempelvis:

• problem/opportunity
• mission
• business objectives
• operational concept
• alternative løsningsretninger.

Svarer på: " Hvilket problem skal systemet egentlig løse?"

Stakeholder Needs and Requirements Definition (Definition af interessentbehov og -krav)

Formål: At omsætte forretningsbehovet til konkrete krav, der dækker alle interessenter (herunder brugerne).

Et eksempel er, at en operatør forventer: "Jeg skal kunne diagnosticere systemfejl uden at åbne maskinen". Det skal omsættes til dokumenterede stakeholder needs og requirements.

Svarer på: ”Hvad har brugere og andre interessenter behov for?"

System Requirements Definition (Definition af systemkrav)

Formål: At omsætte stakeholderkrav til tekniske krav til systemet.

Et eksempel er: (Stakeholderbehov:) Maskinen skal være hurtig. (Systemkrav:) Systemet skal gennemføre proces X på maksimalt Y sekunder efter succesfuld opstart.

Det centrale er, at kravene bliver teknisk realiserbare og verificerbare.

Svarer på: ”Hvad skal systemet implementere?"

System Architecture Definition Process

Formål: At fastlægge systemets overordnede struktur (systemarkitektur).

Et system kan være opdelt i flere systemer, afhængig af dets kompleksitet. Systemer omfatter

• mekanik
• elektronik
• embedded software/firmware
• cloud
• brugerinterface
• databaser.

Arkitekturen definerer blandt andet systemelementer og deres relationer/interfaces.

Svarer på: ”Hvad er systemets arkitektur?"

Design Definition (Designdefinition)

Formålet er: At konkretisere arkitekturen til en tilstrækkelig detaljeret løsning.

Dette omfatter typiske emner som:

• komponenter
• interfaces
• egenskaber
• designprincipper
• nødvendige designbeslutninger.

Svarer på: ”Hvordan skal løsningen konkret realiseres?"

System Analysis (Systemanalyse)

Formålet er: At analysere systemets egenskaber og understøtte tekniske beslutninger.

Ved at udpege central tekniske egenskaber, skabes fokus på det, som er vigtigst. Det kunne være:

• performance
• reliability
• capacity
• trade-off-analyser
• RAM-analyser
• sensitivitet.

Svarer på: ”Hvad skal vi have teknisk fokus på i realisering af løsningen?"

Implementation (Implementering)

Formål: At omsætte designet til faktiske systemelementer.

Disse systemelementer kunne frembringes:

• software programmeres
• elektronik fremstilles
• mekaniske komponenter produceres
• konfigurationer etableres
• systemdata struktureres.

Svarer på: ”Hvordan kan vi fysisk eller digitalt realisere løsningen?" 

Integration (Integration)

Formål: At de enkelte systemelementer gradvist kombineres til det samlede system.

Der anvendes i praksis mange forskellige betegnelser for bestanddelene. Et eksempel er:

Component → subsystem → system → system-of-systems

Et centralt fokus er interfaces mellem systemelementerne.

Svarer på: ”Hvordan styrer vi de enkelte systemelementer, så de kan samles til systemer?"

Verification (Verifikation)

Formål: At afgøre om systemet eller systemelementet opfylder de specificerede krav.

Eksempel: (Krav:) "Systemet skal kunne levere 100 enheder/time." (Verifikation:) Test viser 104 enheder/time. Kravet er dermed verificeret, forudsat at testen og kriterierne er valide.

Svarer på: ”Byggede vi systemet rigtigt?"

Transition (Overgang/idriftsættelse)

Formålet er: At flytte systemet fra udviklingsmiljøet til det operationelle miljø.

Dette kan eksempelvis omfatte:

• installation
• commissioning
• deployment
• aktivering
• oplæring
• overdragelse.

Nogle anvender DevOps, hvor dette sker løbende.

Svarer på: ”Kan systemet fungere i et operationelt miljø?"

Validation (Validering)

Formål: At afgøre, om systemet faktisk opfylder det tilsigtede behov i anvendelseskonteksten.

Man kan godt have et system, som verificerer korrekt mod alle krav, men som alligevel ikke løser brugerens reelle problem tilfredsstillende.

Svarer på: ”Byggede vi det rigtige system?"

Operation (Drift)

Formål: At systemet anvendes til sit tilsigtede formål.

Dette omfatter typisk:

• operationel anvendelse
• overvågning
• håndtering af driftshændelser
• performance
• brugerunderstøttelse.

Svarer på: ”Kan systemet fungere for kunden og dens brugere?"

Maintenance (Vedligeholdelse)

Formål: At opretholde systemets evne til at levere den ønskede funktion.

Dette kræver typisk indsatser, som omfatter:

• preventive maintenance
• corrective maintenance
• modificering
• opgraderinger
• reparation
• levetidsplanlægning / obsolescence management.

Svarer på: ”Hvad er nødvendigt at investere i systemet?"

Disposal (Udfasning og bortskaffelse)

Formål: At håndtere systemet ved afslutningen af dets levetid.

Det er vigtigt, at den sidste fase også håndteres systematisk, herunder:

• decommissioning
• demontering
• datasletning
• genbrug
• destruktion
• miljømæssig korrekt bortskaffelse.

Svarer på: ”Hvad skal vi gøre for at ophøre systemet?"​​​​​​

Opsummering

Formålet med ovennævnte er at skabe en fælles, struktureret ramme for styring og frembringelse af systemer gennem hele deres livscyklus. Standarderne kan anvendes fra den første idé og behovsafdækning gennem udvikling, produktion og drift til vedligeholdelse og endelig udfasning.