Livscykelmodeller

Ledande författare: Kevin Forsberg, Rick Adcock, Medverkande författare: Alan Faisandier

Livscykelmodellen är ett av de viktigaste begreppen inom systemteknik (SE). En livscykellivscykeln för ett systemsystem består i allmänhet av en serie stadierstadier som regleras av en uppsättning ledningsbeslut som bekräftar att systemet är tillräckligt moget för att lämna ett stadie och gå in i ett annat.

Topics

Varje del av SEBoK är indelad i kunskapsområden (KAs), som är grupperingar av information med ett relaterat tema. KAs är i sin tur indelade i ämnen. Denna KA innehåller följande ämnen:

• Systemlivscykelprocessens drivkrafter och val
• Systemlivscykelprocessens modeller: Vee
• Processmodeller för systemets livscykel: Iterativ
• Integration av process- och produktmodeller
• Lean Engineering

Se artikeln Matrix of Implementation Examples (matris för genomförandeexempel) för en mappning av de fallstudier och vinjetter som ingår i del 7 till de ämnen som behandlas i del 3.

Typ av mervärdesprodukter/-tjänster

Den generiska livscykelmodellen visar bara det enstegs tillvägagångssätt som används för att gå igenom stadierna i ett systems livscykel. Att skapa mervärde (som en produkt, en tjänst eller båda) är ett gemensamt syfte för alla företag, oavsett om de är offentliga eller privata, vinstdrivande eller icke-vinstdrivande. Värde skapas genom att tillhandahålla och integrera systemets beståndsdelar i en produkt eller tjänst i enlighet med systembeskrivningen och genom att överföra den till produktiv användning. Dessa värdeöverväganden kommer att leda till olika former av det generiska tillvägagångssättet för livscykelhantering i figur 1. Några exempel är följande (Lawson 2010):

• Ett tillverkningsföretag producerar muttrar, bultar och låsbrickor och säljer sedan sina produkter som mervärdeselement som kan användas av andra företag; dessa företag integrerar i sin tur dessa produkter i sitt mer omfattande mervärdessystem, t.ex. ett flygplan eller en bil. Deras krav kommer i allmänhet att vara förspecificerade av kunden eller av industristandarder.

• Ett grossist- eller detaljhandelsföretag erbjuder produkter till sina kunder. Dess kunder (privatpersoner eller företag) förvärvar produkterna och använder dem som beståndsdelar i sina system. Företagets stödsystem kommer sannolikt att utvecklas på ett opportunistiskt sätt i takt med att nya infrastrukturfunktioner eller efterfrågemönster uppstår.

• Ett kommersiellt tjänsteföretag, t.ex. en bank, säljer en mängd olika produkter som tjänster till sina kunder. Detta inkluderar löpande konton, sparkonton, lån och investeringsförvaltning. Dessa tjänster ger ett mervärde och ingår i individers eller företags kundsystem. Tjänsteföretagets stödsystem kommer sannolikt också att utvecklas opportunistiskt, i takt med att ny infrastrukturkapacitet eller nya efterfrågemönster uppstår.

• Ett statligt tjänsteföretag förser medborgarna med tjänster som varierar kraftigt, men som kan omfatta tjänster som hälsovård, motorvägar och vägar, pensioner, brottsbekämpning eller försvar. I förekommande fall blir dessa tjänster infrastrukturelement som används i större omfattande system som är av intresse för individer och/eller företag. Större initiativ, t.ex. nästa generations flygledningssystem eller ett krishanteringssystem för storstadsområden (orkaner, tyfoner, jordbävningar, tsunamis, översvämningar, bränder), kommer att vara tillräckligt komplexa för att följa en evolutionär utvecklings- och driftsinriktning. På elementnivå kommer det sannolikt att finnas förspecificerade livscykler med en enda passage.

• För flyg- och fordonssystem skulle det sannolikt finnas en förspecificerad livscykel med flera passager för att dra nytta av tidig kapacitet i den första passagen, men som är utformad för att lägga till ytterligare värdeskapande kapacitet i senare passager.

• Ett diversifierat programvaruutvecklingsföretag tillhandahåller programvaruprodukter som uppfyller intressenternas krav (behov), och tillhandahåller därmed tjänster till produktanvändarna. Det måste utvecklas för att ha kapacitet som kan skräddarsys för att användas i olika kunders livscykelstrategier och även med produktlinjekapacitet som snabbt och enkelt kan tillämpas på liknande systemutvecklingar hos kunderna. Dess affärsmodell kan också innefatta att förse kunden med stöd för systemets livscykel och utvecklingsmöjligheter.

I dessa exempel finns det system som förblir stabila under rimligt långa tidsperioder och system som förändras snabbt. Den mångfald som representeras av dessa exempel och deras processer illustrerar varför det inte finns någon enhetlig process som kan användas för att definiera en specifik systemlivscykel. Förvaltnings- och ledarskapsstrategier måste ta hänsyn till vilken typ av system det rör sig om, deras livslängd och behovet av snabb anpassning till oförutsedda förändringar, oavsett om det rör sig om konkurrens, teknik, ledarskap eller uppdragsprioriteringar. I sin tur påverkar förvaltnings- och ledarskapsstrategierna typen och antalet livscykelmodeller som används samt de processer som kommer att användas inom en viss livscykel.

Det finns flera inkrementella och evolutionära strategier för sekvensering av livscykelstadierna för att hantera några av de frågor som tagits upp ovan. Kunskapsområdet Livscykelmodeller sammanfattar ett antal inkrementellainkrementella och evolutionäraevolutionära livscykelmodeller, inklusive deras huvudsakliga styrkor och svagheter, och diskuterar också kriterier för att välja det bäst passande tillvägagångssättet.

Kategorier av livscykelmodeller

Den generiska systemlivscykelmodellen i figur 1 passar inte uttryckligen alla situationer. Ett enkelt, prejudicerande uppföljningssystem kan behöva endast en fas i definitionsfasen, medan ett komplext system kan behöva mer än två. För system som byggs upp (jämfört med prototyper som kastas bort) kan en stor del av utvecklingen ske under definitionsfasen. Systemintegrationintegration, verifieringverifiering och valideringvalidering kan följa på genomförandet eller förvärvet av systemelementen. När det gäller mjukvara, särskilt vid testning först och dagliga byggen, är integrering, verifiering och validering sammanvävda med implementeringen av element. Med den kommande tredje industriella revolutionen med tredimensionell utskrift och digital tillverkning (Whadcock 2012) kan dessutom inte bara den inledande utvecklingen utan även den inledande produktionen ske under konceptstadiet.

Mjukvara är ett flexibelt och formbart medium som underlättar iterativ analys, design, konstruktion, verifiering och validering i högre grad än vad som vanligtvis är möjligt för de rent fysiska komponenterna i ett system. Varje upprepning av en iterativ utvecklingsmodell tillför material (kod) till den växande programvarubasen, där den utökade kodbasen testas, omarbetas vid behov och visas uppfylla kraven för baslinjen.

Mjukvara kan köpas, säljas, levereras och uppgraderas elektroniskt var som helst i världen inom räckhåll för digital kommunikation, vilket gör att logistiken skiljer sig avsevärt från och är mer kostnadseffektiv än för hårdvara. Den slits inte ut och dess korrigeringar ändrar dess innehåll och beteende, vilket gör regressionstestning mer komplicerad än med hårdvarufixar. Dess diskreta natur gör att testningen inte kan räkna med analytisk kontinuitet som med hårdvara. Om man adderar 1 till 32767 i ett 15-bitarsregister får man inte 32768, utan i stället 0, vilket man upplever i allvarliga situationer, t.ex. vid användning av Patriot-missilen.

Det finns ett stort antal potentiella modeller för livscykelprocessenLivscykelprocessmodeller. De faller in i tre huvudkategorier:

1. primärt förspecificerade och sekventiella processer (t.ex. vattenfallsmodellen med ett enda steg)
2. primärt evolutionära och samtidiga processer (t.ex. lean development, den rationella enhetliga processen och olika former av vemodellerna och spiralmodellerna)
3. primärt mellanmänskliga och framväxande processer (t.ex. agil utveckling, scrum, extrem programmering (XP), den dynamiska systemutvecklingsmetoden och innovationsbaserade processer)

Uppkomsten av integrerade, interaktiva hårdvaru- och mjukvarusystem gjorde förspecificerade processer potentiellt skadliga, eftersom de effektivaste gränssnitten mellan människa och system tenderade att uppstå i samband med användningen av dem, vilket ledde till ytterligare processvarianter, t.ex. mjukt SE (Warfield 1976, Checkland 1981) och processer för integrering av människa och system (Booher 2003, Pew och Mavor 2007). Fram till nyligen har processstandarder och mognadsmodeller försökt täcka alla eventualiteter. De har inkluderat omfattande processer för förvärvshantering, källurval, granskningar och revisioner, kvalitetssäkring, konfigurationshantering och dokumenthantering, som i många fall skulle bli alltför byråkratiska och ineffektiva. Detta ledde till införandet av mer lean (Ohno 1988; Womack et al. 1990; Oppenheim 2011) och agila (Beck 1999; Anderson 2010) tillvägagångssätt för samtidiga tillvägagångssätt för hårdvara, mjukvara och mänskliga faktorer, t.ex. de samtidiga vee-modellerna (Forsberg 1991; Forsberg 2005) och Incremental Commitment Spiral Model (Pew och Mavor 2007; Boehm och Lane 2007).

I nästa artikel om System Life Cycle Process Drivers and Choices kommer dessa variationer på temat livscykelmodeller att identifieras och presenteras.

Systems Engineering Responsibility

Oavsett vilka livscykelmodeller som används omfattar systemingenjörens roll hela livscykeln för det intressanta systemet. Systemingenjörer organiserar utvecklingen och utvecklingen av en lösning, från definitionen av krav till drift och slutligen till dess att systemet tas ur bruk. De ser till att domänexperter involveras på rätt sätt, att alla fördelaktiga möjligheter utnyttjas och att alla betydande risker identifieras och, när det är möjligt, minskas. Systemingenjören har ett nära samarbete med projektledaren för att skräddarsy den generiska livscykeln, inklusive viktiga beslutsgrindarbeslutsgrindarbeslutsgrindar, för att möta behoven i deras specifika projekt.

Systemtekniska uppgifter koncentreras vanligtvis i början av livscykeln; dock erkänner både kommersiella och statliga organisationer behovet av SE under hela systemets livscykel. Ofta handlar detta pågående arbete om att modifiera eller ändra ett system, en produkt eller en tjänst efter det att den har kommit i produktion eller tagits i drift. Följaktligen är SE en viktig del av alla livscykelstadier. Under produktions-, stöd- och användningsfaserna (PSU) utför SE till exempel prestandaanalyser, gränssnittsövervakning, felanalyser, logistikanalyser, spårning och analys av föreslagna ändringar. Alla dessa aktiviteter är viktiga för det löpande stödet till systemet.

Alla projektledare måste se till att affärsaspekten (kostnad, tidsplan och värde) och den tekniska aspekten av projektcykeln förblir synkroniserade. Ofta är det den tekniska aspekten som styr projektet. Det är systemingenjörernas ansvar att se till att de tekniska lösningar som övervägs är förenliga med kostnads- och tidsplaneringsmålen. Detta kan kräva att man samarbetar med användarna och kunderna för att revidera målen så att de ryms inom affärsmässiga ramar. Dessa frågor är också orsaken till behovet av att beslutsgrindarna är lämpligt placerade under hela projektcykeln. Även om karaktären på dessa beslutsgrindar kommer att variera beroende på de viktigaste kategorierna ovan, kommer var och en av dem att inbegripa validering inom processen mellan utvecklarna och slutanvändarna. Vid validering i processen ställs frågan: ”Kommer det vi planerar eller skapar att tillfredsställa intressenternas behov?” Validering inom processen börjar vid projektets initiering under upptäckten av användarnas behov och fortsätter genom dagliga aktiviteter, formella granskningar av beslutsgrindar, leverans av slutprodukten eller lösningen, drift och slutligen till systemavslutning och bortskaffande.

Works Cited

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

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

Boehm, B. och J. Lane. 2007. ”Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering”. CrossTalk. Oktober 2007: 4-9.

Booher, H. (red.) 2003. Handbook of Human Systems Integration. Hoboken, NJ, USA: Wiley.

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

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

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

Forsberg, K., H. Mooz och 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 resa genom systemlandskapet. London, UK: College Publications.

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

Oppenheim, B. 2011. Lean för systemteknik. Hoboken, NJ: Wiley.

Pew, R. och A. Mavor (red.). 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 industriell revolution”. The Economist. April 21, 2012.

Womack, J.P., D.T. Jones och D. Roos 1990. Maskinen som förändrade världen: The Story of Lean Production. New York, NY, USA: Rawson Associates.

Primära referenser

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

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3rd Ed. 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 resa genom systemlandskapet. London, UK: College Publications.

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

Att ytterligare referenser

Chrissis, M., M. Konrad och S. Shrum. 2003. CMMI: Riktlinjer för processintegration och produktförbättring. New York, NY, USA: Addison Wesley.

Larman, C. och B. Vodde. 2009. Skalning av lean och agil utveckling. New York, NY, USA: Addison Wesley.

De följande tre böckerna refereras inte i SEBoK-texten och är inte heller systemtekniska ”texter”; de innehåller dock viktiga systemtekniska lärdomar och läsare av denna SEBOK uppmuntras att läsa dem.

Kinder, G. 1998. Guldskeppet i det djupblå havet. New York, NY, USA: Grove Press.

Detta är en utmärkt bok som följer en idé från början till dess framgångsrika genomförande. Även om systemteknik inte diskuteras illustreras den tydligt i hela processen från tidig projektdefinition till alternativ konceptutveckling till fasad utforskning och ”tankeexperiment” till att ta itu med utmaningar längs vägen. Den visar också på problemet med att inte förutse kritiska problem som ligger utanför det vanliga projektets och teknikens räckvidd. Det tog ungefär fem år att lokalisera och bärga de 24 ton guldtackor och mynt från det sjunkna fartyget i det 2 500 meter djupa havet, men det tog tio år att vinna den rättsliga striden med de advokater som företrädde försäkringsbolagen som hävdade äganderätten på grundval av 130 år gamla försäkringar som de utfärdade till guldägarna 1857.

McCullough, D. 1977. Vägen mellan haven: skapandet av Panamakanalen (1870-1914). New York, NY, USA: Simon & Schuster.

Och även om ”systemteknik” inte nämns, belyser denna bok många systemtekniska frågor och illustrerar behovet av systemteknik som en disciplin. Boken illustrerar också faran med att tillämpa ett tidigare framgångsrikt koncept (havsnivåkanalen som användes i Suez tio år tidigare) i en liknande men annorlunda situation. Ferdinand de Lesseps ledde både Suez- och Panamaprojekten. Boken illustrerar faran med att sakna en faktabaserad projektcykel och meningsfulla beslutsgrindar under hela projektcykeln. Det visar också på faran med att tillhandahålla projektstatus utan synlighet. Efter fem år av det tioåriga projektet fick investerarna veta att projektet var mer än 50 procent färdigt, när det i själva verket bara var 10 procent av arbetet färdigt. Den andra utvecklingsomgången under Stevens 1904 fokuserade på att ”flytta jord” i stället för att gräva en kanal, ett systemtekniskt koncept som var avgörande för att kanalen skulle kunna färdigställas. The Path Between the Seas vann National Book Award for history (1978), Francis Parkman Prize (1978), Samuel Eliot Morison Award (1978) och Cornelius Ryan Award (1977).

Shackleton, Sir E.H. 2008. (Ursprungligen publicerad i av William Heinemann, London, 1919). South: Den sista Antarktisexpeditionen med Shackleton och Endurance. Guilford, CT, USA: Lyons Press.

Detta är den fantastiska berättelsen om Shackletons och Endurance sista Antarktisexpedition 1914-1917. Den systemtekniska lärdomen är den kontinuerliga, dagliga riskbedömning som kaptenen, expeditionsledaren och besättningen gjorde när de låg instängda i den arktiska isen i 18 månader. Alla 28 besättningsmedlemmar överlevde.

Relevanta videor

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