Elinkaarimallit

Lead Authors: Kevin Forsberg, Rick Adcock: Alan Faisandier

Elinkaarimalli on yksi systeemitekniikan (SE) keskeisistä käsitteistä. Järjestelmäjärjestelmän elinkaaren elinkaari koostuu yleensä sarjasta vaiheitavaiheita, joita säätelevät joukko hallintopäätöksiä, jotka vahvistavat, että järjestelmä on riittävän kypsä poistumaan yhdestä vaiheesta ja siirtymään toiseen.

Teemat

Jokainen SEBoK:n osa on jaettu tietämysalueisiin (KA), jotka ovat tiedon ryhmittymiä, joihin liittyy tietty teema. KA:t on puolestaan jaettu aiheisiin. Tämä KA sisältää seuraavat aiheet:

• Systeemin elinkaariprosessin ajurit ja valinnat
• Systeemin elinkaariprosessin mallit: Vee
• System Life Cycle Process Models: Iteratiivinen
• Prosessi- ja tuotemallien integrointi
• Lean Engineering

Katso artikkelista Toteutusesimerkkien matriisi, jossa kartoitetaan osaan 7 sisältyvien tapaustutkimusten ja vinjettien vastaavuus osassa 3 käsiteltyihin aiheisiin.

Lisäarvotuotteiden/-palveluiden tyypit

Yleisessä elinkaarimallissa esitetään vain yksivaiheinen toimintatapa, jolla eteneminen tapahtuu systeemien elinkaaren vaiheiden kautta. Arvon lisääminen (tuotteena, palveluna tai molempina) on kaikkien yritysten yhteinen tavoite, olivatpa ne julkisia tai yksityisiä, voittoa tavoittelevia tai voittoa tavoittelemattomia. Arvoa tuotetaan tarjoamalla ja integroimalla järjestelmän osat tuotteeksi tai palveluksi järjestelmän kuvauksen mukaisesti ja siirtämällä se tuottavaan käyttöön. Nämä arvoa koskevat näkökohdat johtavat kuvassa 1 esitetyn yleisen elinkaaren hallinnan lähestymistavan eri muotoihin. Joitakin esimerkkejä ovat seuraavat (Lawson 2010):

• Tuotantoyritys tuottaa muttereita, pultteja ja aluslevytuotteita ja myy sitten tuotteensa lisäarvoa tuottavina elementteinä muiden yritysten käyttöön; nämä yritykset puolestaan integroivat nämä tuotteet kattavampaan lisäarvoa tuottavaan järjestelmäänsä, kuten lentokoneeseen tai autoon. Niiden vaatimukset ovat yleensä asiakkaan tai alan standardien ennalta määrittelemiä.

• Tukkukauppaa tai vähittäiskauppaa harjoittava yritys tarjoaa tuotteita asiakkailleen. Sen asiakkaat (yksityishenkilöt tai yritykset) hankkivat tuotteet ja käyttävät niitä järjestelmiensä elementteinä. Yrityksen tukijärjestelmä kehittyy todennäköisesti opportunistisesti uusien infrastruktuurikyvykkyyksien tai kysyntämallien ilmaantuessa.

• Kaupallinen palveluyritys, kuten pankki, myy asiakkailleen erilaisia tuotteita palveluina. Näihin kuuluvat käyttötilit, säästötilit, lainat ja sijoitusten hoito. Nämä palvelut tuovat lisäarvoa ja ne liitetään osaksi yksityishenkilöiden tai yritysten asiakasjärjestelmiä. Palveluyrityksen tukijärjestelmä kehittyy todennäköisesti myös opportunistisesti uusien infrastruktuurikyvykkyyksien tai kysyntämallien ilmaantuessa.

• Hallinnon palveluyritys tarjoaa kansalaisille palveluita, jotka vaihtelevat laajasti, mutta joihin voi kuulua palveluita, kuten terveydenhoito, valtatiet ja maantiet, eläkkeet, lainvalvonta tai puolustus. Tarvittaessa näistä palveluista tulee infrastruktuurielementtejä, joita hyödynnetään laajemmissa, yksilöitä ja/tai yrityksiä kiinnostavissa järjestelmissä. Suuret aloitteet, kuten seuraavan sukupolven lennonjohtojärjestelmä tai suurkaupunkialueen kriisinhallintajärjestelmä (hurrikaani, taifuuni, maanjäristys, tsunami, tulva, tulipalo), ovat riittävän monimutkaisia, jotta niiden kehittämisessä ja käyttöönotossa voidaan noudattaa evolutiivista lähestymistapaa. Elementtitasolla on todennäköisesti ennalta määritellyt yhden läpiviennin elinkaaret.

• Lentokone- ja ajoneuvojärjestelmissä on todennäköisesti ennalta määritellyt usean läpiviennin elinkaaret, jotta ensimmäisellä läpiviennillä voidaan hyödyntää alkuvaiheen kyvykkyyksiä, mutta ne on suunniteltu siten, että myöhemmissä läpiviemisissä voidaan lisätä lisäarvoa tuovia kyvykkyyksiä.

• Monipuolinen ohjelmistokehitysyritys tuottaa ohjelmistotuotteita, jotka täyttävät sidosryhmien vaatimukset (tarpeet), ja näin ollen se tarjoaa palveluja tuotteiden käyttäjille. Sitä on kehitettävä siten, että sillä on kyvykkyyksiä, jotka voidaan räätälöidä hyödynnettäviksi asiakkaiden eri elinkaarilähestymistavoissa, ja myös sellaisia tuotelinjan kyvykkyyksiä, joita voidaan nopeasti ja helposti soveltaa asiakkaiden samankaltaisiin järjestelmäkehityksiin. Sen liiketoimintamalliin voi myös kuulua järjestelmän elinkaarituen ja kehitysvalmiuksien tarjoaminen asiakkaalle.

Näissä esimerkeissä on järjestelmiä, jotka pysyvät vakaina kohtuullisen pitkiä aikoja, ja sellaisia, jotka muuttuvat nopeasti. Näiden esimerkkien ja niiden prosessien edustama monimuotoisuus havainnollistaa, miksi ei ole olemassa yhtä ainoaa prosessia, jota voidaan käyttää tietyn järjestelmän elinkaaren määrittelyyn. Johtamisen ja johtajuuden lähestymistavoissa on otettava huomioon kyseessä olevien järjestelmien tyyppi, niiden pitkäikäisyys ja tarve nopeaan sopeutumiseen ennakoimattomiin muutoksiin, olipa kyse sitten kilpailussa, teknologiassa, johtajuudessa tai tehtävän painopisteissä tapahtuvista muutoksista. Johtamis- ja johtajuuslähestymistavat puolestaan vaikuttavat siihen, minkä tyyppisiä ja kuinka monta elinkaarimallia otetaan käyttöön ja mitä prosesseja kussakin elinkaaressa käytetään.

Elinkaaren vaiheiden jaksottamiseen on olemassa useita asteittaisia ja evolutiivisia lähestymistapoja, joilla voidaan käsitellä joitakin edellä esitetyistä kysymyksistä. Elinkaarimallit-tietämysalueella esitetään yhteenveto useista inkrementaalis-krementaalisista ja evolutiivisevolutionaarisista elinkaarimalleista, mukaan lukien niiden tärkeimmät vahvuudet ja heikkoudet, ja siinä käsitellään myös kriteerejä, joiden perusteella voidaan valita parhaiten sopiva lähestymistapa.

Elinkaarimallin luokat

Kuvassa 1 esitetty yleinen järjestelmän elinkaarimalli ei nimenomaisesti sovi kaikkiin tilanteisiin. Yksinkertainen, edeltäjä- ja seuraajajärjestelmä voi tarvita vain yhden vaiheen määrittelyvaiheessa, kun taas monimutkainen järjestelmä voi tarvita enemmän kuin kaksi vaihetta. Kun kyseessä ovat build-upon-järjestelmät (vs. throwaway-järjestelmät) prototyypitprototyypit, suuri osa kehityksestä voi tapahtua määrittelyvaiheessa. Järjestelmän integrointiintegrointi, verifiointiverifiointi ja validointiValidointi voi seurata järjestelmän osien toteuttamista tai hankintaa. Ohjelmistoissa, erityisesti testit ensin ja päivittäinen rakentaminen, integrointi, verifiointi ja validointi kietoutuvat yhteen elementtien toteutuksen kanssa. Kolmiulotteisen tulostuksen ja digitaalisen valmistuksen kolmannen teollisen vallankumouksen (Whadcock 2012) myötä alkukehityksen lisäksi myös alkutuotanto voidaan toteuttaa jo konseptivaiheessa.

Ohjelmisto on joustava ja muokattava väline, joka helpottaa iteratiivista analyysia, suunnittelua, rakentamista, verifiointia ja validointia suuremmassa määrin kuin se on yleensä mahdollista järjestelmän puhtaasti fyysisten komponenttien osalta. Jokainen iteratiivisen kehitysmallin toisto lisää materiaalia (koodia) kasvavaan ohjelmistopohjaan, jossa laajennettua koodipohjaa testataan, työstetään tarvittaessa uudelleen ja osoitetaan sen täyttävän perustason vaatimukset.

Ohjelmistoja voidaan ostaa, myydä, toimittaa ja päivittää sähköisesti missä päin maailmaa tahansa digitaalisen tiedonsiirron ulottumattomissa, mikä tekee niiden logistiikasta huomattavasti erilaista ja kustannustehokkaampaa kuin laitteistojen. Se ei kulu ja sen korjaukset muuttavat sen sisältöä ja käyttäytymistä, mikä tekee regressiotestauksesta monimutkaisempaa kuin laitteistokorjausten kanssa. Sen erillisen luonteen vuoksi sen testauksessa ei voida luottaa analyyttiseen jatkuvuuteen kuten laitteistojen testauksessa. Kun 15-bittisen rekisterin 32767:ään lisätään 1, ei saada tulokseksi 32768 vaan 0, kuten vakavissa tilanteissa, kuten Patriot-ohjuksen käytössä, on koettu.

Potentiaalisia elinkaariprosessin elinkaariprosessin malleja on suuri määrä. Ne jakautuvat kolmeen pääryhmään:

1. ensisijaisesti ennalta määritellyt ja peräkkäiset prosessit (esim. yksivaiheinen vesiputousmalli)
2. ensisijaisesti evolutiiviset ja samanaikaiset prosessit (esim. Lean-kehitys, rationaalinen yhtenäistetty prosessi ja vee- ja spiraalimallien erilaiset muodot)
3. ensisijaisesti ihmissuhteiden väliset ja emergenssissä syntyvät prosessit (esim. ketterä kehitys, scrum, extreme programming (XP), dynaaminen järjestelmäkehitysmenetelmä ja innovaatiopohjaiset prosessit)

Integroitujen, vuorovaikutteisten laitteisto-ohjelmistojärjestelmien ilmaantuminen teki ennalta määritellyistä prosesseista potentiaalisesti haitallisia, sillä tehokkaimmilla ihmisen ja järjestelmän välisillä rajapinnoilla oli taipumus ilmaantua sen käytön myötä, mikä johti prosessien lisävariaatioihin, kuten pehmeään SE:hen [soft SE] (Warfield 1976, Checkland 1981) ja ihmisen ja järjestelmän integraatioprosesseihin [human-system integration processes] (Booher 2003, Pew ja Mavor 2007). Viime aikoihin asti prosessistandardit ja kypsyysmallit ovat pyrkineet kattamaan kaikki mahdollisuudet. Niihin on sisältynyt laajoja prosesseja hankintojen hallintaa, hankintalähteiden valintaa, tarkastuksia ja auditointeja, laadunvarmistusta, konfiguraationhallintaa ja asiakirjahallintoa varten, joista olisi monissa tapauksissa tullut liian byrokraattisia ja tehottomia. Tämä johti siihen, että rinnakkaisiin laitteisto-ohjelmisto-inhimilliset tekijät -lähestymistapoihin, kuten rinnakkaisiin vee-malleihin (Forsberg 1991; Forsberg 2005) ja Incremental Commitment Spiral Model -malliin (Pew ja Mavor 2007; Boehm ja Lane 2007), otettiin käyttöön kevyempiä (Ohno 1988; Womack et al. 1990; Oppenheim 2011) ja ketterämpiä (Beck 1999; Anderson 2010) lähestymistapoja.

Seuraavassa artikkelissa Järjestelmän elinkaariprosessin ajurit ja valinnat nämä elinkaarimallien variaatiot tunnistetaan ja esitellään.

Systeemitekniikan vastuu

Käytetyistä elinkaarimalleista riippumatta järjestelmäinsinöörin rooli kattaa koko kiinnostuksen kohteena olevan järjestelmän elinkaaren. Järjestelmäinsinöörit organisoivat ratkaisun kehittämistä ja kehittymistä vaatimusten määrittelystä käytön kautta aina järjestelmän käytöstä poistumiseen asti. He varmistavat, että toimialan asiantuntijat ovat asianmukaisesti mukana, että kaikki edulliset mahdollisuudet hyödynnetään ja että kaikki merkittävät riskit tunnistetaan ja mahdollisuuksien mukaan lievennetään. Järjestelmäinsinööri työskentelee tiiviissä yhteistyössä projektipäällikön kanssa räätälöidessään yleistä elinkaarta, mukaan lukien keskeiset päätöksentekoportaat, vastaamaan kyseisen hankkeen tarpeita.

Järjestelmäsuunnittelun tehtävät keskittyvät yleensä elinkaaren alkuun, mutta sekä kaupalliset että julkishallinnon organisaatiot tunnustavat SE:n tarpeen koko järjestelmän elinkaaren ajan. Usein tämä jatkuva työ on järjestelmän, tuotteen tai palvelun muokkaamista tai muuttamista sen jälkeen, kun se on otettu tuotantoon tai otettu käyttöön. Näin ollen SE on tärkeä osa kaikkia elinkaaren vaiheita. Esimerkiksi tuotanto-, tuki- ja käyttövaiheissa SE suorittaa suorituskykyanalyysejä, rajapintojen seurantaa, vika-analyysejä, logistiikka-analyysejä, seurantaa ja ehdotettujen muutosten analysointia. Kaikki nämä toiminnot ovat olennaisia järjestelmän jatkuvan tuen kannalta.

Kaikkien projektipäälliköiden on varmistettava, että liiketoiminnallinen näkökulma (kustannukset, aikataulu ja arvo) ja projektisyklin tekninen näkökulma pysyvät synkronoituina. Usein tekninen näkökulma ohjaa projektia. Järjestelmäsuunnittelijoiden vastuulla on varmistaa, että harkittavat tekniset ratkaisut ovat sopusoinnussa kustannus- ja aikataulutavoitteiden kanssa. Tämä voi edellyttää työskentelyä käyttäjien ja asiakkaiden kanssa tavoitteiden tarkistamiseksi siten, että ne sopivat liiketoiminnan rajoihin. Nämä seikat vaikuttavat myös siihen, että päätöksentekoportaat on sijoitettava sopivin väliajoin koko projektisyklin ajalle. Vaikka näiden päätöksentekoportaiden luonne vaihtelee edellä mainittujen pääluokkien mukaan, jokainen sisältää prosessin sisäistä validointiaprosessin sisäistä validointia kehittäjien ja loppukäyttäjien välillä. Prosessin sisäisessä validoinnissa kysytään: ”Täyttääkö se, mitä suunnittelemme tai luomme, sidosryhmien tarpeet?”. Prosessin sisäinen validointi alkaa projektin alkuvaiheessa käyttäjien tarpeiden selvittämisen yhteydessä ja jatkuu päivittäisissä toiminnoissa, muodollisissa päätöksentekoportaiden tarkasteluissa, lopullisen tuotteen tai ratkaisun toimittamisessa, toiminnassa ja lopulta järjestelmän sulkemisessa ja hävittämisessä.

Works Cited

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

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

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

Booher, H. (toim.) 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. ja D. Yoffie. 1998. Competing on Internet Time, New York, NY, Yhdysvallat: The Free Press.

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

Forsberg, K., H. Mooz ja 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. Matka järjestelmien maiseman läpi. 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. ja A. Mavor (toim.). 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. ”Kolmas teollinen vallankumous”. The Economist. April 21, 2012.

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

Primary References

Blanchard, B.S., ja W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5. painos. 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, 3. painos. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Järjestelmätekniikan käsikirja, versio 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Matka läpi systeemimaiseman. London, UK: College Publications.

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

Lisäviitteet

Chrissis, M., M. Konrad, and S. Shrum. 2003. CMMI: Prosessien integrointia ja tuotteiden parantamista koskevat ohjeet. New York, NY, USA: Addison Wesley.

Larman, C. ja B. Vodde. 2009. Scaling Lean and Agile Development. New York, NY, USA: Addison Wesley.

Seuraaviin kolmeen kirjaan ei viitata SEBoK-tekstissä, eivätkä ne ole systeemitekniikan ”tekstejä”; ne sisältävät kuitenkin tärkeitä systeemitekniikan oppeja, ja tämän SEBOKin lukijoita kehotetaan lukemaan ne.

Kinder, G. 1998. Kultalaiva syvässä sinisessä meressä. New York, NY, USA: Grove Press.

Tämä on erinomainen kirja, jossa seurataan idean syntymistä sen lopulta onnistuneeseen toteuttamiseen. Vaikka systeemitekniikkaa ei käsitellä, sitä havainnollistetaan selkeästi koko prosessissa hankkeen varhaisesta määrittelystä vaihtoehtoisen konseptin kehittämiseen, vaiheittaiseen tutkimiseen ja ”ajatuskokeiluihin” sekä matkan varrella ilmeneviin haasteisiin vastaamiseen. Se osoittaa myös ongelman, joka liittyy siihen, että kriittisiä ongelmia ei ennakoida tavanomaisen hanke- ja suunnittelualan ulkopuolella. Kultaharkkoja ja kolikoita sisältävien 24 tonnin kultaharkkojen ja -kolikoiden löytäminen ja talteenotto 2500 metrin syvyydessä uponneesta laivasta kesti noin viisi vuotta, mutta kesti kymmenen vuotta voittaa oikeustaistelu vakuutusyhtiöitä edustavien lakimiesten kanssa, jotka vaativat omistusoikeutta 130 vuotta vanhojen vakuutusten perusteella, jotka he olivat myöntäneet kullan omistajille vuonna 1857.

McCullough, D. 1977. Tie merten välissä: Panaman kanavan luominen (1870 – 1914). New York, NY, USA: Simon & Schuster.

Vaikka ”systeemitekniikkaa” ei mainita, tässä kirjassa tuodaan esiin monia systeemitekniikan kysymyksiä ja havainnollistetaan SE:n tarvetta tieteenalana. Kirja havainnollistaa myös vaaran, joka aiheutuu siitä, että aiemmin menestyksekkäästi toteutettua konseptia (Suezissa kymmenen vuotta aiemmin käytettyä merenpinnan tasalla olevaa kanavaa) sovelletaan samankaltaiseen mutta erilaiseen tilanteeseen. Ferdinand de Lesseps johti sekä Suezin että Panaman hankkeita. Se havainnollistaa vaaran, joka aiheutuu tosiasioihin perustuvan hankesyklin ja mielekkäiden päätöksentekoportaiden puuttumisesta koko hankesyklin ajan. Se korostaa myös vaaraa, joka aiheutuu siitä, että hanketilanne ei ole näkyvissä. Kun kymmenen vuotta kestäneestä hankkeesta oli kulunut viisi vuotta, sijoittajille kerrottiin, että hanke oli yli 50-prosenttisesti valmis, vaikka todellisuudessa vain 10 prosenttia töistä oli tehty. Stevensin johdolla vuonna 1904 toteutetussa toisessa kehityskierroksessa keskityttiin kanavan kaivamisen sijasta ”lian siirtämiseen”, mikä oli kanavan valmistumisen kannalta keskeinen systeemitekninen käsite. The Path Between the Seas voitti historian National Book Award -palkinnon (1978), Francis Parkman -palkinnon (1978), Samuel Eliot Morison -palkinnon (1978) ja Cornelius Ryan -palkinnon (1977).

Shackleton, Sir E.H. 2008. (Alun perin julkaistu teoksessa William Heinemann, Lontoo, 1919). South: Shackletonin ja Endurancen viimeinen Etelämanner-retki. Guilford, CT, USA: Lyons Press.

Tämä on hämmästyttävä tarina Shackletonin ja Endurance-aluksen viimeisestä Etelämanner-retkikunnasta vuosina 1914-1917. Järjestelmätekniikan oppi on kapteenin, retkikunnan johtajan ja miehistön jatkuva, päivittäinen riskien arviointi, kun he makasivat loukussa arktisessa jäässä 18 kuukautta. Kaikki 28 miehistön jäsentä jäivät henkiin.

Relevant Videos

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