Livscyklusmodeller

Ledende forfattere: Kevin Forsberg, Rick Adcock, Medvirkende forfattere: Kevin Forsberg, Rick Adcock, Medvirkende forfattere: Kevin Forsberg, Rick Adcock: Alan Faisandier

Livscyklusmodellen er et af nøglebegreberne inden for systemteknik (SE). En livscykluslivscyklus for et systemsystem består generelt af en række stadierstadier, der reguleres af et sæt ledelsesbeslutninger, som bekræfter, at systemet er modent nok til at forlade et stadie og gå ind i et andet.

Temaer

Hver del af SEBoK er opdelt i vidensområder (KA’er), som er grupperinger af information med et beslægtet tema. KA’erne er på deres side opdelt i emner. Denne KA indeholder følgende emner:

• System Life Cycle Process Drivers and Choices
• System Life Cycle Process Models: Vee
• System Life Cycle Process Models: Vee
• System Life Cycle Process Models: Iterativ
• Integration af proces- og produktmodeller
• Lean Engineering

Se artiklen Matrix of Implementation Examples for en kortlægning af casestudier og vignetter, der indgår i del 7, til emnerne i del 3.

Type af produkter/tjenester med merværdi

Den generiske livscyklusmodel viser blot den enkelttrinstilgang til at gå gennem faserne i et systems livscyklus. Værditilvækst (som et produkt, en tjenesteydelse eller begge dele) er et fælles formål for alle virksomheder, uanset om de er offentlige eller private, med eller uden gevinst for øje eller uden gevinst for øje. Værdi skabes ved at levere og integrere systemets elementer i et produkt eller en tjenesteydelse i overensstemmelse med systembeskrivelsen og ved at bringe det i produktiv brug. Disse værdimæssige overvejelser vil føre til forskellige former for den generiske livscyklusforvaltningsmetode i figur 1. Nogle eksempler er følgende (Lawson 2010):

• En produktionsvirksomhed producerer møtrikker, bolte og låseskiver og sælger derefter deres produkter som værdiforøgende elementer til brug for andre virksomheder; til gengæld integrerer disse virksomheder disse produkter i deres mere omfattende værdiforøgende system, som f.eks. et fly eller en bil. Deres krav vil normalt være specificeret på forhånd af kunden eller af industristandarder.

• En engros- eller detailhandelsvirksomhed tilbyder produkter til sine kunder. Dens kunder (enkeltpersoner eller virksomheder) erhverver produkterne og anvender dem som elementer i deres systemer. Virksomhedens støttesystem vil sandsynligvis udvikle sig opportunistisk, efterhånden som der opstår nye infrastrukturkapaciteter eller efterspørgselsmønstre.

• En kommerciel servicevirksomhed som f.eks. en bank sælger en række produkter som tjenester til sine kunder. Dette omfatter løbende konti, opsparingskonti, lån og investeringsforvaltning. Disse tjenester tilfrjer mervrdi og indgres i enkeltpersoners eller virksomheders kundesystemer. Servicevirksomhedens støttesystem vil sandsynligvis også udvikle sig opportunistisk, efterhånden som nye infrastrukturkapaciteter eller efterspørgselsmønstre dukker op.

• En offentlig servicevirksomhed forsyner borgerne med tjenester, der varierer meget, men kan omfatte tjenester som sundhedspleje, motorveje og veje, pensioner, retshåndhævelse eller forsvar. Hvor det er relevant, bliver disse tjenester til infrastrukturelementer, der anvendes i større omfattende systemer, der er af interesse for enkeltpersoner og/eller virksomheder. Større initiativer, som f.eks. et næste generation af flyvekontrolsystem eller et krisestyringssystem for et storbyområde (orkan, tyfon, jordskælv, tsunami, oversvømmelse, brand), vil være tilstrækkeligt komplekse til at følge en evolutionær udviklings- og implementeringsstrategi. På det elementære niveau vil der sandsynligvis være forud specificerede livscyklusser med et enkelt gennemløb.

• For fly- og bilsystemer vil der sandsynligvis være en forud specificeret livscyklus med flere gennemløb for at udnytte tidlige kapaciteter i det første gennemløb, men med en arkitektur, der tilføjer yderligere værdiskabende kapaciteter i senere gennemløb.

• En diversificeret softwareudviklingsvirksomhed leverer softwareprodukter, der opfylder interessenternes krav (behov), og leverer således tjenester til produktbrugerne. Den skal udvikles til at have kapaciteter, der kan skræddersys til at blive udnyttet i forskellige kunders livscyklustilgange, og også med produktliniefunktioner, der hurtigt og nemt kan anvendes til lignende udviklinger af kundesystemer. Dens forretningsmodel kan også omfatte at give kunden støtte til systemets livscyklus og evolutionsmuligheder.

I disse eksempler er der systemer, som forbliver stabile over rimeligt lange perioder, og systemer, som ændrer sig hurtigt. Den mangfoldighed, som disse eksempler og deres processer repræsenterer, illustrerer, hvorfor der ikke findes en ensartet proces, der kan bruges til at definere en specifik systemlivscyklus. Forvaltnings- og ledelsestilgange skal tage hensyn til den type systemer, der er tale om, deres lang levetid og behovet for hurtig tilpasning til uforudsete ændringer, hvad enten det drejer sig om konkurrence, teknologi, ledelse eller missionsprioriteter. Til gengæld påvirker forvaltnings- og ledelsestilgangene typen og antallet af livscyklusmodeller, der anvendes, samt de processer, der vil blive anvendt inden for en bestemt livscyklus.

Der findes flere inkrementelle og evolutionære tilgange til sekvensering af livscyklusstadierne for at håndtere nogle af de spørgsmål, der er rejst ovenfor. Vidensområdet Livscyklusmodeller opsummerer en række inkrementelleinkrementelle og evolutionæreevolutionære livscyklusmodeller, herunder deres vigtigste styrker og svagheder, og diskuterer også kriterier for valg af den bedst egnede tilgang.

Kategorier af livscyklusmodeller

Den generiske systemlivscyklusmodel i figur 1 passer ikke udtrykkeligt til alle situationer. Et simpelt, præcedentielt, opfølgende system har måske kun brug for én fase i definitionsfasen, mens et komplekst system kan have brug for mere end to. Med build-upon systemer (vs. throwaway) prototyperprototyper, kan en stor del af udviklingen finde sted i definitionsfasen. Systemintegrationintegration, verifikationverifikationverifikation og valideringvalidering kan følge efter implementering eller anskaffelse af systemelementerne. Med software, især ved test-først- og daglige builds, er integration, verifikation og validering sammenvævet med implementeringen af elementerne. Med den kommende tredje industrielle revolution med tredimensional udskrivning og digital fremstilling (Whadcock 2012) kan ikke kun den indledende udvikling, men også den indledende produktion foregå i konceptfasen.

Software er et fleksibelt og formbart medium, som letter iterativ analyse, design, konstruktion, verifikation og validering i højere grad, end det normalt er muligt for de rent fysiske komponenter i et system. Hver gentagelse af en iterativ udviklingsmodel tilføjer materiale (kode) til den voksende softwarebase, hvor den udvidede kodebase afprøves, omarbejdes om nødvendigt og påvises at opfylde kravene til baseline.

Software kan købes, sælges, leveres og opgraderes elektronisk overalt i verden inden for rækkevidde af digital kommunikation, hvilket gør dens logistik væsentligt anderledes og mere omkostningseffektiv end hardware. Det slides ikke, og dets rettelser ændrer dets indhold og adfærd, hvilket gør regressionstest mere kompleks end ved rettelser af hardware. Dets diskrete karakter gør, at testning af det ikke kan regne med analytisk kontinuitet som med hardware. Tilføjelse af 1 til 32767 i et 15-bit register giver ikke 32768, men i stedet 0, som det opleves i alvorlige situationer, f.eks. ved brug af Patriot-missilet.

Der findes et stort antal potentielle livscyklusproceslivscyklusprocesmodeller. De falder i tre hovedkategorier:

1. primært præspecificerede og sekventielle processer (f.eks. vandfaldsmodellen med et enkelt trin)
2. primært evolutionære og samtidige processer (f.eks. lean development, den rationelle ensartede proces og forskellige former for vee- og spiralmodeller)
3. primært interpersonelle og emergente processer (f.eks. agil udvikling, scrum, ekstrem programmering (XP), den dynamiske systemudviklingsmetode og innovationsbaserede processer)

Den fremkomst af integrerede, interaktive hardware-software-systemer gjorde på forhånd specificerede processer potentielt skadelige, da de mest effektive menneske-systemgrænseflader havde en tendens til at opstå med brugen af dem, hvilket førte til yderligere procesvarianter, såsom soft SE (Warfield 1976, Checkland 1981) og menneske-systemintegrationsprocesser (Booher 2003, Pew og Mavor 2007). Indtil for nylig har processtandarder og modenhedsmodeller forsøgt at dække alle muligheder. De har omfattet omfattende processer for anskaffelsesstyring, udvælgelse af leverandører, anmeldelser og revisioner, kvalitetssikring, konfigurationsstyring og dokumentstyring, som i mange tilfælde ville blive overdrevent bureaukratiske og ineffektive. Dette førte til indførelsen af mere lean (Ohno 1988; Womack et al. 1990; Oppenheim 2011) og agile (Beck 1999; Anderson 2010) tilgange til samtidige hardware-software-menneskelige faktorer-tilgange som f.eks. de samtidige vemodeller (Forsberg 1991; Forsberg 2005) og Incremental Commitment Spiral Model (Pew og Mavor 2007; Boehm og Lane 2007).

I den næste artikel om System Life Cycle Process Drivers and Choices vil disse variationer over temaet livscyklusmodeller blive identificeret og præsenteret.

Systems Engineering Responsibility

Uanset hvilke livscyklusmodeller der anvendes, omfatter systemingeniørens rolle hele livscyklussen for det system af interesse, der er af interesse. Systemingeniører orkestrerer udviklingen og udviklingen af en løsning, fra definitionen af krav til drift og i sidste ende indtil systemet tages ud af drift. De sikrer, at domæneeksperter inddrages på passende vis, at alle fordelagtige muligheder udnyttes, og at alle væsentlige risici identificeres og om muligt mindskes. Systemingeniøren arbejder tæt sammen med projektlederen om at skræddersy den generiske livscyklus, herunder centrale beslutningsgatesbeslutningsgates, til at opfylde behovene i deres specifikke projekt.

Systemtekniske opgaver er normalt koncentreret i begyndelsen af livscyklussen; men både kommercielle og offentlige organisationer anerkender dog behovet for SE i hele systemets livscyklus. Ofte er denne løbende indsats at modificere eller ændre et system, et produkt eller en tjeneste, efter at det er kommet i produktion eller er taget i brug. Derfor er SE en vigtig del af alle livscyklusfaser. I produktions-, støtte- og udnyttelsesfaserne (PSU) udfører SE f.eks. analyse af ydeevne, grænsefladeovervågning, analyse af fejl, logistikanalyse, sporing og analyse af foreslåede ændringer. Alle disse aktiviteter er afgørende for den løbende støtte af systemet.

Alle projektledere skal sikre, at det forretningsmæssige aspekt (omkostninger, tidsplan og værdi) og det tekniske aspekt af projektcyklussen forbliver synkroniseret. Ofte er det det tekniske aspekt, der styrer projektet. Det er systemingeniørernes ansvar at sikre, at de tekniske løsninger, der overvejes, er i overensstemmelse med omkostnings- og tidsplanmålene. Dette kan kræve samarbejde med brugerne og kunderne om at revidere målene, så de passer ind i forretningsgrænserne. Disse spørgsmål er også årsagen til, at der er behov for beslutningsporte med passende mellemrum i hele projektforløbet. Selv om arten af disse beslutningsporte vil variere i forhold til de ovennævnte hovedkategorier, vil de alle omfatte validering i processen mellem udviklerne og slutbrugerne. Ved validering i processen stilles spørgsmålet: “Vil det, vi planlægger eller skaber, tilfredsstille interessenternes behov?” In-process validering begynder ved projektets initialisering under afdækning af brugernes behov og fortsætter gennem daglige aktiviteter, formelle decision gate reviews, levering af det endelige produkt eller den endelige løsning, drift og i sidste ende til systemafslutning og bortskaffelse.

Works Cited

Anderson, D. 2010. Kanban. Sequim, WA: Blue Hole Press.

Beck, K. 1999. Extreme Programming Explained. Boston, MA: Addison Wesley.

Boehm, B. og J. Lane. 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering” (Brug af den inkrementelle forpligtelsesmodel til at integrere systemanskaffelse, systemteknik og softwareudvikling). CrossTalk. Oktober 2007: 4-9.

Booher, H. (red.) 2003. Håndbog om integration af menneskelige systemer. Hoboken, NJ, USA: Wiley.

Checkland, P. 1999. Systems Thinking, Systems Practice, 2nd ed. Hoboken, NJ, USA: Wiley.

Cusumano, M., og D. Yoffie. 1998. Competing on Internet Time, New York, NY, USA: The Free Press.

Forsberg, K. og H. Mooz. 1991. “The Relationship of System Engineering to the Project Cycle”, Proceedings of INCOSE, oktober 1991.

Forsberg, K., H. Mooz, og H. Cotterman. 2005. Visualizing Project Management, 3rd ed. Hoboken, NJ: J. Wiley & Sons.

ISO/IEC/IEEE. 2015.Systems and software engineering – system life cycle processes.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC 15288:2015.

Lawson, H. 2010. En rejse gennem systemlandskabet. London, UK: College Publications.

Ohno, T. 1988. Toyota Production System. New York, NY: Productivity Press.

Oppenheim, B. 2011. Lean for Systems Engineering. Hoboken, NJ: Wiley.

Pew, R. og A. Mavor (eds.). 2007. Human-System Integration in The System Development Process: A New Look. Washington, DC, USA: The National Academies Press.

Warfield, J. 1976. Systems Engineering. Washington, DC, USA: US Department of Commerce (DoC).

Whadcock, I. 2012. “En tredje industriel revolution”. The Economist. April 21, 2012.

Womack, J.P., D.T. Jones, og D. Roos 1990. The Machine That Changed the World: The Story of Lean Production. New York, NY, USA: Rawson Associates.

Primære referencer

Blanchard, B.S., og W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5. udgave. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualisering af projektledelse, 3. udgave. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. En rejse gennem systemlandskabet. London, UK: College Publications.

Pew, R. og A. Mavor (Eds.). 2007. Human-System Integration in The System Development Process: A New Look. Washington, DC, USA: The National Academies Press.

Supplerende referencer

Chrissis, M., M. Konrad, og S. Shrum. 2003. CMMI: Retningslinjer for procesintegration og produktforbedring. New York, NY, USA: Addison Wesley.

Larman, C. og B. Vodde. 2009. Skalering af lean og agil udvikling. New York, NY, USA: Addison Wesley.

De følgende tre bøger er ikke refereret i SEBoK-teksten, og de er heller ikke systemtekniske “tekster”; de indeholder dog vigtige systemtekniske erfaringer, og læsere af denne SEBOK opfordres til at læse dem.

Kinder, G. 1998. Skib af guld i det dybe blå hav. New York, NY, USA: Grove Press.

Dette er en fremragende bog, der følger en idé fra dens begyndelse til dens endelige vellykkede gennemførelse. Selv om systemteknik ikke behandles, er den tydeligt illustreret i hele processen fra den tidlige projektdefinition til den alternative konceptudvikling til den fasevise udforskning og “tankeeksperimenter” til håndteringen af udfordringer undervejs. Den viser også problemet med ikke at forudse kritiske problemer uden for det sædvanlige projekt- og ingeniørområde. Det tog ca. fem år at finde og bjærge de 24 tons guldbarrer og mønter fra det sunkne skib i det 2 500 meter dybe hav, men det tog ti år at vinde den juridiske kamp mod de advokater, der repræsenterede forsikringsselskaberne, som hævdede ejerskab på grundlag af 130 år gamle forsikringspolicer, som de udstedte til guldets ejere i 1857.

McCullough, D. 1977. Vejen mellem havene: Oprettelsen af Panamakanalen (1870 – 1914). New York, NY, USA: Simon & Schuster.

Og selv om “systemteknik” ikke nævnes, fremhæver denne bog mange systemtekniske spørgsmål og illustrerer behovet for SE som en disciplin. Bogen illustrerer også faren ved at anvende et tidligere vellykket koncept (havniveaukanalen, der blev anvendt i Suez et årti tidligere) i en lignende, men anderledes situation. Ferdinand de Lesseps stod i spidsen for både Suez- og Panama-projekterne. Bogen illustrerer faren ved at mangle en faktabaseret projektcyklus og meningsfulde beslutningsporte i hele projektcyklussen. Det viser også faren ved at give projektstatus uden synlighed. Efter fem år af det tiårige projekt fik investorerne at vide, at projektet var mere end 50 procent færdigt, mens det i virkeligheden kun var 10 procent af arbejdet færdigt. Den anden udviklingsrunde under Stevens i 1904 fokuserede på at “flytte jord” i stedet for at grave en kanal, et systemteknisk koncept, der var afgørende for kanalens færdiggørelse. The Path Between the Seas vandt National Book Award for historie (1978), Francis Parkman-prisen (1978), Samuel Eliot Morison-prisen (1978) og Cornelius Ryan-prisen (1977).

Shackleton, Sir E.H. 2008. (Oprindeligt udgivet i af William Heinemann, London, 1919). South: The Last Antarctic Expedition of Shackleton and the Endurance. Guilford, CT, USA: Lyons Press.

Dette er den fantastiske historie om Shackletons og Endurance’s sidste ekspedition til Antarktis i 1914 til 1917. Den systemtekniske lektie er den løbende, daglige risikovurdering, som kaptajnen, ekspeditionslederen og besætningen foretog, mens de lå fanget i den arktiske is i 18 måneder. Alle 28 besætningsmedlemmer overlevede.

Relevante videoer

• NASA’s Approach to Systems Engineering- Space Systems Engineering 101 w/ NASA