System Life Cycle Process Models: Vee

Lead Authors: Dick Fairley, Kevin Forsberg: Ray Madachy

Elinkaariprosessimalleja on suuri määrä. Kuten System Life Cycle Process Drivers and Choices -artikkelissa käsiteltiin, nämä mallit jakautuvat kolmeen pääluokkaan: (1) ensisijaisesti ennalta määritellyt ja peräkkäiset prosessit, (2) ensisijaisesti evolutiiviset ja samanaikaiset prosessit (esim. rationaalinen yhtenäinen prosessi ja Vee- ja spiraalimallin eri muodot) ja (3) ensisijaisesti ihmissuhteiden väliset ja rajoittamattomat prosessit (esim. ketterä kehitys, Scrum, äärimmäinen ohjelmointi (Extreme Programming, XP), dynaaminen järjestelmäkehitysmenetelmä ja innovaatiokehitykseen perustuvat prosessit).

Tässä artikkelissa keskitytään nimenomaisesti Vee- malliin, joka on ensisijainen esimerkki ennalta määritellyistä ja peräkkäisistä prosessista. Tässä keskustelussa on tärkeää huomata, että Vee-malli ja Vee-mallin muunnelmat käsittelevät kaikki samaa järjestelmäsuunnittelun (SE) perustoimintoja. Keskeinen ero näiden mallien välillä on tapa, jolla ne ryhmittelevät ja esittävät edellä mainitut SE-toiminnot.

Vee-mallin käytön yleisiä vaikutuksia järjestelmäsuunnitteluun ja -kehitykseen käsitellään jäljempänä; jos haluat tarkemman käsityksen siitä, miten tämä elinkaarimalli vaikuttaa systeeminsuunnittelutoimintoihin, katso muut osaamisalueet (KA) osassa 3.

Ensisijaisesti ennalta määritetty ja peräkkäinen prosessimalli: Vee-malli

Vee-mallin sekventiaalinen versio on esitetty kuvassa 1. Sen ytimeen kuuluu peräkkäinen eteneminen suunnitelmista, määrittelyistä ja tuotteista, jotka perustetaan ja asetetaan konfiguraationhallinnan piiriin. Pystysuora, kaksipäinen nuoli mahdollistaa sen, että projektit voivat suorittaa samanaikaisia mahdollisuus- ja riskianalyysejä sekä jatkuvaa prosessin sisäistä validointia. Vee-malli kattaa INCOSE Systems Engineering Handbookin ”Generic Life Cycle Stages” -taulukossa luetellut kolme ensimmäistä elinkaaren vaihetta: kartoittava tutkimus, konsepti ja kehittäminen (INCOSE 2012).

Kuva 1. Vee-menetelmä. Sequential Vee -mallin vasen puoli (Forsberg, Mooz ja Cotterman 2005). Uudelleen painettu John Wiley & Sons Inc:n luvalla. Kaikki muut oikeudet pidätetään tekijänoikeuden omistajalta.

Vee-malli tukee INCOSE Systems Engineering Handbookin (INCOSE 2012) määritelmää elinkaaren vaiheista ja niiden tarkoituksista tai toiminnoista, kuten alla olevassa kuvassa 2 on esitetty.

Kuva 2. Toimintavaiheen vaiheet. Esimerkki vaiheista, niiden tarkoituksista ja tärkeimmistä päätösporteista. (SEBoK Original)

INCOSE Systems Engineering Handbook 3.2.2 sisältää yksityiskohtaisemman version Vee-kaaviosta (2012, kuvat 3-4, s. 27), joka sisällyttää elinkaaren aikaiset toiminnot yleisempään Vee-malliin. Samankaltainen kaavio, joka on kehitetty Yhdysvaltain Defense Acquisition Universityssä (DAU), näkyy alla olevassa kuvassa 3.

kuva 3. Vee-toimintakaavio (Prosnik 2010). Julkaisija: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

Vee-mallin soveltaminen

Lawson (Lawson 2010) käsittelee tarkemmin kunkin elinkaaren vaiheen toimintoja ja toteaa, että on hyödyllistä harkita geneerisen elinkaaren vaiheiden mallin rakennetta minkä tahansa tyyppiselle etuuskohteena olevalle järjestelmälle (System-of-interest (SoI, System-of-Interest, SoI), sellaisena kuin se on kuvattu kuvassa 4. Tämä (T)-malli osoittaa, että yksi tai useampi määrittelyvaihe edeltää tuotantovaihetta (-vaiheita), jossa kahden tai useamman järjestelmäelementin toteutus (hankinta, toimittaminen tai kehittäminen) on toteutettu.

Kuva 4. Järjestelmän elinkaaren vaiheet. Järjestelmän elinkaarimallien yleinen (T) vaiherakenne (Lawson 2010). Uudelleen painettu Harold Lawsonin luvalla. Kaikki muut oikeudet pidätetään tekijänoikeuden omistajalla.

Kuvassa 5 on esitetty geneeriset elinkaaren vaiheet erilaisille sidosryhmille standardointiorganisaatiosta (ISO/IEC) kaupallisiin ja valtion organisaatioihin. Vaikka nämä vaiheet eroavat toisistaan yksityiskohdiltaan, niillä kaikilla on samanlainen peräkkäinen muoto, jossa korostuvat kuvassa 2 esitetyt ydintoiminnot (määrittely, tuotanto ja käyttö/poistaminen).

kuva 5. Elinkaarimallien vertailua (Forsberg, Mooz ja Cotterman 2005). Uudelleen painettu John Wiley & Sonsin luvalla. Kaikki muut oikeudet pidätetään tekijänoikeuden omistajalta.

On tärkeää huomata, että monet elinkaaren aikaiset toiminnot ovat iteratiivisia. Tämä on esimerkki rekursiosta (sanasto)rekursiosta (sanasto), jota käsiteltiin osan 3 johdannossa.

Elinkaaren vaiheiden ja ohjelmanhallintavaiheen perusteet

Tämän keskustelun kannalta on tärkeää huomioida, että:

  • Käsitteellä vaihevaihe viitataan järjestelmän erilaisiin tiloihin elinkaaren aikana; jotkin vaiheet voivat olla ajallisesti päällekkäisiä, kuten esimerkiksi hyödyntämisvaihe ja tuki- ja ylläpitovaihe. Termiä vaihe käytetään ISO/IEC/IEEE 15288:ssa.
  • Termi vaihe viittaa ohjelman eri vaiheisiin, jotka tukevat ja hallitsevat järjestelmän elinkaarta; vaiheet eivät yleensä ole päällekkäisiä. Termiä ”vaihe” käytetään monissa vakiintuneissa malleissa vastineena termille ”vaihe.”

OhjelmanhallintaOhjelmanhallinnassa käytetään vaiheita, virstanpylväitävirstanpylväitä ja päätöksentekoportaitapäätöksentekoportaita, joita käytetään arvioimaan järjestelmän kehitystä sen eri vaiheiden kautta. Vaiheet sisältävät toimintoja, jotka suoritetaan tavoitteiden saavuttamiseksi, ja niiden avulla valvotaan ja hallitaan vaiheiden järjestystä ja vaiheiden välisiä siirtymiä. Kunkin projektin osalta on olennaista määritellä ja julkaista vastaavissa projekteissa käytettävät termit ja niihin liittyvät määritelmät sekaannusten minimoimiseksi.

Tyypillinen ohjelmaohjelma koostuu seuraavista vaiheista:

  • esiselvitysvaihe, jossa tunnistetaan potentiaalisia mahdollisuuksia vastata käyttäjien tarpeisiin uusilla ratkaisuilla, jotka ovat liiketoiminnallisesti järkeviä.
  • Toteutettavuusvaiheessa tutkitaan vaihtoehtoisten konseptien toteutettavuus, jotta voidaan päästä toiselle päätöksentekoportaalille, ennen kuin aloitetaan toteutusvaihe. Toteutettavuusvaiheessa tunnistetaan sidosryhmien vaatimukset ja järjestelmävaatimukset, tunnistetaan ja tutkitaan toteuttamiskelpoisia ratkaisuja ja voidaan toteuttaa virtuaalisia prototyyppejä (sanasto)prototyyppejä (sanasto). Tässä vaiheessa päätös etenemisestä perustuu:
    • onko konsepti toteuttamiskelpoinen ja katsotaanko sen kykenevän torjumaan tunnistettua uhkaa tai hyödyntämään tilaisuutta;
    • onko konsepti riittävän kypsä perustellakseen uuden tuotteen tai tuotelinjan jatkokehittämisen; ja
    • hyväksytäänkö tarjouspyynnön perusteella laadittu ehdotus.
  • Toteutusvaihe sisältää järjestelmän elinkaaren neljään vaiheeseen liittyvät toimet: kehittäminen, tuotanto, käyttö ja tuki. Tyypillisesti toteutustoimintoihin liittyy kaksi päätösporttia ja kaksi välitavoitetta. Ensimmäinen virstanpylväs antaa johdolle mahdollisuuden tarkastella toteutussuunnitelmia ennen kuin se antaa vihreää valoa. Toinen virstanpylväs tarjoaa mahdollisuuden tarkastella edistymistä ennen kuin tehdään päätös tuotannon aloittamisesta. Toteutuksen aikaisia päätösportteja voidaan käyttää sen määrittämiseen, tuotetaanko kehitetty SoI ja parannetaanko sitä vai poistetaanko se käytöstä.

Nämä ohjelmanhallinnan näkemykset koskevat SoI:n lisäksi myös sen elementtejä ja rakennetta.

Elinkaaren vaiheet

Vee-mallin muunnelmat käsittelevät samoja yleisiä elinkaaren vaiheita:

  • Uudet hankkeet alkavat tyypillisesti kartoittavalla tutkimusvaiheella, joka sisältää yleensä konseptin määrittelyn toimet, erityisesti liiketoiminnan tai tehtävän analyysin aiheet ja sidosryhmien tarpeiden ja vaatimusten ymmärtämisen. Nämä kypsyvät sitä mukaa, kun projekti etenee kartoittavasta vaiheesta konseptivaiheesta kehitysvaiheeseen.
  • Tuotantovaiheeseen kuuluvat järjestelmän määrittelyn ja järjestelmän toteuttamisen toiminnot sekä järjestelmävaatimusten (sanasto)vaatimusten (sanasto)vaatimusten (sanasto) ja arkkitehtuurin (sanasto)arkkitehtuurin (sanasto) kehittäminen verifioinnin ja validoinnin kautta.
  • Hyötykäyttövaiheeseen kuuluvat järjestelmän käyttöönoton ja järjestelmän käytön toiminnot.
  • Tukivaiheeseen kuuluvat järjestelmän ylläpitoon, logistiikkaan sekä tuotteen ja käyttöiän hallintaan liittyvät toiminnot, joihin voi sisältyä toimintoja, kuten käyttöiän pidentäminen tai kyvykkyyksien päivitykset, päivitykset ja modernisointi.
  • Hävittämisvaihe sisältää hävittämiseen ja käytöstä poistamiseen liittyvät toiminnot, vaikka joissakin malleissa käyttöiän pidentämisen tai toimintakyvyn päivitysten, päivitysten ja nykyaikaistamisen kaltaiset toiminnot on ryhmitelty ”käytöstä poistamisen” vaiheeseen.

Lisätietoa kustakin vaiheesta on jäljempänä olevissa osioissa (ks. linkit edellä oleviin osan 3 lisäartikkeleihin, joista löytyy lisätietoa). On tärkeää huomata, että näitä elinkaaren vaiheita ja kunkin vaiheen toimintoja tuetaan järjestelmätekniikan hallintaprosesseilla.

Tutkimusvaihe

Käyttäjävaatimusten analysointi ja sopiminen on osa tutkimusvaihetta, ja se on kriittinen tekijä menestyksekkäiden järjestelmien kehittämisessä. Ilman asianmukaista ymmärrystä käyttäjien tarpeista on vaarana, että mikä tahansa järjestelmä rakennetaan ratkaisemaan vääriä ongelmia. Ensimmäinen vaihe kartoittavassa tutkimusvaiheessa on määritellä käyttäjän (ja sidosryhmien) vaatimukset ja rajoitukset. Keskeinen osa tätä prosessia on selvittää käyttäjien vaatimusten täyttämisen toteutettavuus, mukaan lukien teknologian valmiuden arviointi. Kuten monissa SE-toimissa, tämäkin tehdään usein iteratiivisesti, ja sidosryhmien tarpeita ja vaatimuksia tarkastellaan uudelleen sitä mukaa kuin uutta tietoa saadaan.

National Research Councilin hiljattain tekemässä tutkimuksessa (National Research Council 2008) keskityttiin Yhdysvaltain ilmavoimien hankkeiden kehitysajan lyhentämiseen. Raportissa todetaan, että ”yksinkertaisesti sanottuna järjestelmäsuunnittelu on käyttäjän tarpeiden muuntamista järjestelmän ja sen arkkitehtuurin määrittelyksi iteratiivisen prosessin avulla, joka johtaa tehokkaaseen järjestelmäsuunnitteluun”. Sidosryhmien iteratiivinen osallistuminen on kriittinen tekijä projektin onnistumisen kannalta.

Projektin ensimmäistä ja viimeistä päätösporttia lukuun ottamatta portit suoritetaan samanaikaisesti. Katso alla olevaa kuvaa 6.

Kuva 6. Porttipäätteet. Kehitysvaiheiden aikataulutus. (SEBoK Original)

Konseptivaihe

Konseptivaiheessa luodaan vaihtoehtoisia konsepteja, jotta voidaan määrittää paras lähestymistapa sidosryhmien tarpeiden täyttämiseksi. Vaihtoehtoja visioimalla ja luomalla malleja, mukaan lukien asianmukaiset prototyypit, selvitetään sidosryhmien tarpeita ja tuodaan esiin ajavat kysymykset. Tämä voi johtaa asteittaiseen tai evolutionaariseen lähestymistapaan järjestelmän kehittämisessä. Useita eri konsepteja voidaan tutkia rinnakkain.

Kehitysvaihe

Konseptivaiheessa yksilöityä valittua konseptia (valittuja konsepteja) työstetään yksityiskohtaisesti alimmalle tasolle asti, jotta saadaan aikaan ratkaisu, joka vastaa sidosryhmien tarpeitaSidosryhmien vaatimukset. Koko tämän vaiheen ajan on tärkeää jatkaa käyttäjien osallistumista prosessin sisäisen validoinnin avulla (ylöspäin suuntautuva nuoli Vee-malleissa). Laitteistoissa tämä tapahtuu usein toistuvilla ohjelmakatselmuksilla ja asiakkaan edustajan (tai edustajien) läsnäololla (tarvittaessa). Ketterässä kehityksessä käytäntönä on, että asiakkaan edustaja integroidaan kehitystiimiin.

Tuotantovaihe

Tuotantovaiheessa SoI rakennetaan tai valmistetaan. Tuotemuutoksia voidaan tarvita tuotanto-ongelmien ratkaisemiseksi, tuotantokustannusten alentamiseksi tai tuotteen tai SoI:n ominaisuuksien parantamiseksi. Mikä tahansa näistä muutoksista voi vaikuttaa järjestelmävaatimuksiin ja voi vaatia järjestelmän uudelleenkvalifiointikvalifiointikvalifiointia, uudelleenvalifiointikvalifiointikvalifiointia tai uudelleenvalidointikvalifiointikvalifiointia. Kaikki tällaiset muutokset edellyttävät SE-arviointia ennen muutosten hyväksymistä.

Käyttövaihe

Tuotteen elinkaaren hallinnan merkittävä näkökohta on sellaisten tukijärjestelmien käyttöönotto, jotka ovat elintärkeitä tuotteen toiminnan ylläpitämiseksi. Vaikka toimitettua tuotetta tai palvelua voidaan pitää hankkijan kannalta suppeana intressijärjestelmänä (NSOI), hankkijan on myös sisällytettävä tukijärjestelmät laajempaan intressijärjestelmään (WSOI). Nämä tukijärjestelmät olisi nähtävä järjestelmäomaisuutena, joka aktivoidaan tarvittaessa vastauksena NSOI:n toiminnassa ilmenneeseen tilanteeseen. Tukijärjestelmien kokonaisuuden yhteisnimitys on integroitu logistiikkatukijärjestelmä (ILS-järjestelmä).

Järjestelmätuotteita ja -palveluita määriteltäessä, tuotettaessa ja käytettäessä on olennaista kokonaisvaltainen näkemys. Kuvassa 7 on kuvattu järjestelmän suunnittelun ja kehittämisen suhde ILS-vaatimuksiin.

Kuva 7. Järjestelmän suunnittelun ja kehittämisen suhde ILS-vaatimuksiin. ILS:n suhde järjestelmän elinkaareen (Eichmueller ja Foreman 2009). Uudelleen painettu ASD/AIA S3000L -ohjauskomitean luvalla. Kaikki muut oikeudet pidätetään tekijänoikeuden omistajalla.

Luotettavuusvaatimukset, joista seuraa huollettavuuden ja testattavuuden tarve, ovat ohjaavia tekijöitä.

Tukivaihe

Tukivaiheessa SoI:lle tarjotaan palveluita, jotka mahdollistavat jatkuvan käytön. Muutoksia voidaan ehdottaa tukevuusongelmien ratkaisemiseksi, käyttökustannusten vähentämiseksi tai järjestelmän käyttöiän pidentämiseksi. Nämä muutokset edellyttävät SE-arviointia, jotta vältetään järjestelmän kykyjen menetys käytön aikana. Vastaava tekninen prosessi on ylläpitoprosessi.

Poistamisvaihe

Poistamisvaiheessa SoI ja siihen liittyvät palvelut poistetaan käytöstä. SE-toiminnot keskittyvät tässä vaiheessa ensisijaisesti sen varmistamiseen, että hävittämisvaatimukset täyttyvät. Itse asiassa hävittämisen suunnittelu on osa järjestelmän määrittelyä konseptivaiheessa. 1900-luvulla saadut kokemukset ovat toistuvasti osoittaneet, millaisia seurauksia oli siitä, että järjestelmän käytöstä poistamista ja hävittämistä ei ollut otettu huomioon alusta alkaen. 2000-luvun alkupuolella monet maat ovat muuttaneet lakejaan siten, että SoI:n luoja on vastuussa järjestelmän asianmukaisesta loppusijoituksesta.

Elinkaarikatselmukset

Hankkeen etenemisen valvomiseksi suunnitellaan erityyppisiä katselmuksia. Yleisimmin käytetyt on lueteltu seuraavassa, vaikka nimet eivät olekaan yleispäteviä:

  • Järjestelmävaatimuskatselmus (System Requirements Review, SRR) suunnitellaan järjestelmän vaatimusjoukon todentamiseksi ja validoimiseksi ennen yksityiskohtaisten suunnittelutoimien aloittamista.
  • Suunnittelun ennakkokatselmusSuunnittelun ennakkokatselmus (PDR) suunnitellaan järjestelmän vaatimusjoukon, suunnittelun artefaktien ja perusteluelementtien todentamiseksi ja validoimiseksi ensimmäisen suunnittelusilmukan lopussa (tunnetaan myös nimellä ”design-to”-portti).
  • Kriittinen suunnittelukatselmusKriittinen suunnittelukatselmus (CDR, Critical Design Review) suunnitellaan todennettavaksi ja validoitavaksi järjestelmävaatimusten joukon, suunnittelun artefaktien ja perusteluelementtien osalta viimeisen suunnittelusilmukan lopussa (”build-to” ja ”code-to” -suunnitelmat vapautetaan tämän katselmuksen jälkeen).
  • IntegrointiIntegraatiointegrointi-, verifiointi-verifiointi- ja validointi- ja validaatiokatselmukset suunnitellaan sitä mukaa, kun komponentit kootaan korkeamman tason osajärjestelmiksi ja elementeiksi. Katselmusten sarja järjestetään sen varmistamiseksi, että kaikki integroituu oikein ja että on objektiivista näyttöä siitä, että kaikki vaatimukset on täytetty. Vee-mallin oikea puoli (Forsberg, Mooz ja Cotterman 2005). Jäljennös John Wiley & Sons Inc:n luvalla. Kaikki muut oikeudet pidätetään tekijänoikeuden haltijalla.

    Works Cited

    Eichmueller, P. ja B. Foreman. 2010. S3000LTM. Bryssel, Belgia: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).

    Faisandier, A. 2012. Systems Architecture and Design. Belberaud, Ranska:

    Forsberg, K., H. Mooz ja H. Cotterman. 2005. Visualizing Project Management, 3rd ed. New York, NY, USA: J. Wiley & Sons.

    INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (Järjestelmän elinkaaren prosessien ja toimintojen opas), versio 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.

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

    Primary References

    Beedle, M., et al. 2009. ”Ketterä manifesti: Principles behind the Agile Manifesto”. teoksessa The Agile Manifesto . Accessed December 04 2014 at www.agilemanifesto.org/principles.html

    Boehm, B. and R. Turner. 2004. Ketteryyden ja kurinalaisuuden tasapainottaminen. New York, NY, USA: Addison-Wesley.

    Fairley, R. 2009. Managing and Leading Software Projects. New York, NY, USA: J. Wiley & Sons.

    Forsberg, K., H. Mooz ja H. Cotterman. 2005. Visualizing Project Management. 3rd ed. New York, NY, USA: J. Wiley & Sons.

    INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, versio 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.

    Lawson, H. 2010. Matka läpi systeemimaiseman. Kings College, 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.

    Royce, W.E. 1998. Software Project Management: A Unified Framework. New York, NY, USA: Addison Wesley.

    Lisäviitteet

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

    Baldwin, C. ja K. Clark. 2000. Design Rules: The Power of Modularity. Cambridge, MA, USA: MIT Press.

    Beck, K. 1999. Extreme Programming Explained. New York, NY, USA: Addison Wesley.

    Beedle, M., et al. 2009. ”Ketterä manifesti: Principles behind the Agile Manifesto”. in The Agile Manifesto . Luettu 2010. Saatavissa: www.agilemanifesto.org/principles.html

    Biffl, S., A. Aurum, B. Boehm, H. Erdogmus ja P. Gruenbacher (toim.). 2005. Value-Based Software Engineering. New York, NY, USA: Springer.

    Boehm, B. 1988. ”A Spiral Model of Software Development”. IEEE Computer 21(5): 61-72.

    Boehm, B. 2006. ”Some Future Trends and Implications for Systems and Software Engineering Processes”. Systems Engineering. 9(1): 1-19.

    Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah ja R. Madachy. 1998. ”WinWin-spiraalimallin käyttö: A Case Study.” IEEE Computer. 31(7): 33-44.

    Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (painossa). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Boston, MA, USA: Addison Wesley.

    Castellano, D.R. 2004. ”Top Five Quality Software Projects”. CrossTalk. 17(7) (heinäkuu 2004): 4-19. Saatavilla osoitteessa: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

    Checkland, P. 1981. Systeemiajattelu, systeemikäytäntö. New York, NY, USA: Wiley.

    Crosson, S. ja B. Boehm. 2009. ”Ohjelmiston elinkaaren ankkuripisteiden mukauttaminen: Lessons Learned in a System of Systems Context”. Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.

    Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010. ”Ketterä ohjelmistokehitys: Current Research and Future Directions.” Luku teoksessa B. Boehm, J. Lane, S. Koolmanjwong ja R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.

    Dorner, D. 1996. The Logic of Failure. New York, NY, USA: Basic Books.

    Forsberg, K. 1995. ”’If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment”. Proceedings of the Fifth Annual International Council on Systems Engineering (INCOSE) International Symposium. 22.-26. heinäkuuta 1995. St. Louis, MO, USA.

    Forsberg, K. 2010. ”Projektit eivät ala vaatimuksista.” Proceedings of the IEEE Systems Conference, 5-8 April 2010, San Diego, CA, USA.

    Gilb, T. 2005. Competitive Engineering. Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.

    Goldratt, E. 1984. The Goal. Great Barrington, MA, USA: North River Press.

    Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. New York, NY, USA: Wiley.

    Holland, J. 1998. Emergenssi. New York, NY, USA: Perseus Books.

    ISO/IEC. 2010. Järjestelmä- ja ohjelmistotekniikka, osa 1: Guide for Life Cycle Management. Geneve, Sveitsi: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.

    ISO/IEC/IEEE. 2015. Systems and Software Engineering — System Life Cycle Processes. Geneve, Sveitsi: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

    ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneve, Sveitsi: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).

    Jarzombek, J. 2003. ”Top Five Quality Software Projects”. CrossTalk. 16(7) (heinäkuu 2003): 4-19. Saatavilla osoitteessa: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

    Kruchten, P. 1999. Rational Unified Process. New York, NY, USA: Addison Wesley.

    Landis, T. R. 2010. Lockheed Blackbird -perhe (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.

    Madachy, R. 2008. Software Process Dynamics. Hoboken, NJ, USA: Wiley.

    Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. ”Arkkitehtuuriarvostelut: Practice and Experience. IEEE Software. 22(2): 34-43.

    National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering. Washington, DC, USA: The National Academies Press.

    Osterweil, L. 1987. ”Myös ohjelmistoprosessit ovat ohjelmistoja”. Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.

    Poppendeick, M. ja T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit. New York, NY, USA: Addison Wesley.

    Rechtin, E. 1991. System Architecting: Creating and Building Complex Systems. Upper Saddle River, NY, USA: Prentice-Hall.

    Rechtin, E. ja M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, USA: CRC Press.

    Schwaber, K. ja M. Beedle. 2002. Ketterä ohjelmistokehitys Scrumin avulla. Upper Saddle River, NY, USA: Prentice Hall.

    Spruill, N. 2002. ”Top Five Quality Software Projects.” CrossTalk. 15(1) (tammikuu 2002): 4-19. Saatavilla osoitteessa: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.

    Stauder, T. 2005. ”Top Five Department of Defense Program Awards”. CrossTalk. 18(9) (syyskuu 2005): 4-13. Saatavissa: http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

    Warfield, J. 1976. Societal Systems: Planning, Policy, and Complexity. New York, NY, USA: Wiley.

    Womack, J. ja D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.

    Asiaankuuluvat videot=

    • Systeemitekniikan perusteet (V-menetelmä)
    • Systeemitekniikan perusteet (V-menetelmä) Osa 2 2:sta

    < Edellinen Artikkeli | Vanhempi Artikkeli | Seuraava Artikkeli >
    SEBoK v. 2.3, julkaistiin 30.10.2020
    .

Vastaa

Sähköpostiosoitettasi ei julkaista.