System Life Cycle Process Models: Vee

Lead Authors: Vee: Dick Fairley, Kevin Forsberg, Közreműködő szerzők: Dick Fairley, Kevin Forsberg: Ray Madachy

Nagyszámú életciklus-folyamatmodell létezik. Amint azt a Rendszeréletciklus-folyamatok mozgatórugói és döntések című cikkben tárgyaltuk, ezek a modellek három fő kategóriába sorolhatók: (1) elsősorban előre meghatározott és szekvenciális folyamatok; (2) elsősorban evolúciós és egyidejű folyamatok (pl. a racionális egységes folyamat, valamint a Vee- és a spirálmodell különböző formái); és (3) elsősorban interperszonális és kötetlen folyamatok (pl. agilis fejlesztés, Scrum, extrém programozás (XP), a dinamikus rendszerfejlesztési módszer és az innováció-alapú folyamatok).

Ez a cikk kifejezetten a Vee-modellre, mint az előre meghatározott és szekvenciális folyamatok elsődleges példájára összpontosít. Ebben a vitában fontos megjegyezni, hogy a Vee-modell és a Vee-modell változatai mind a rendszermérnöki (SE) tevékenységek ugyanazon alapkészletével foglalkoznak. A legfontosabb különbség e modellek között az, ahogyan a fent említett SE-tevékenységeket csoportosítják és ábrázolják.

A Vee-modell rendszertervezésre és -fejlesztésre való alkalmazásának általános következményeit az alábbiakban tárgyaljuk; annak pontosabb megértéséhez, hogy ez az életciklus-modell hogyan hat a rendszertervezési tevékenységekre, lásd a 3. rész többi tudásterületét (KA).

Egy elsődlegesen előre specifikált és szekvenciális folyamatmodell: A Vee-modell

A Vee-modell szekvenciális változata az 1. ábrán látható. Magja a tervek, specifikációk és termékek szekvenciális előrehaladását foglalja magában, amelyeket alapértelmezettek és a konfigurációkezelés alá helyeznek. A függőleges, kétfejű nyíl lehetővé teszi a projektek számára az egyidejű lehetőség- és kockázatelemzéseket, valamint a folyamatos folyamaton belüli validálást. A Vee-modell magában foglalja az INCOSE Systems Engineering Handbook “Generic Life Cycle Stages” táblázatában felsorolt első három életciklusszakaszt: feltáró kutatás, koncepció és fejlesztés (INCOSE 2012).

1. ábra. A szekvenciális Vee-modell bal oldala (Forsberg, Mooz és Cotterman 2005). Újranyomtatva a John Wiley & Sons Inc. engedélyével. Minden egyéb jog a szerzői jog tulajdonosának fenntartva.

A Vee-modell az INCOSE Systems Engineering Handbook (INCOSE 2012) életciklusfázisok és azok céljainak vagy tevékenységeinek meghatározását támogatja, amint az az alábbi 2. ábrán látható.

2. ábra. Példa a szakaszokra, azok céljaira és főbb döntési kapukra. (SEBoK Original)

Az INCOSE Systems Engineering Handbook 3.2.2 tartalmazza a Vee-diagram részletesebb változatát (2012, 3-4. ábra, 27. o.), amely az életciklus-tevékenységeket beépíti az általánosabb Vee-modellbe. Az Egyesült Államok Védelmi Beszerzési Egyetemén (DAU) kidolgozott hasonló diagram az alábbi 3. ábrán látható.

3. ábra. A Vee tevékenységdiagram (Prosnik 2010). Kiadta a Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

Application of the Vee Model

Lawson (Lawson 2010) részletezi az egyes életciklus-fázisok tevékenységeit, és megjegyzi, hogy hasznos egy általános életciklus-fázismodell felépítését figyelembe venni bármely típusú érdekeltségi rendszer (SoI) esetében, ahogy azt a 4. ábra ábrázolja. Ez a (T) modell azt jelzi, hogy egy vagy több definíciós szakasz megelőzi a termelési szakasz(oka)t, ahol két vagy több rendszerelem megvalósítása (beszerzése, rendelkezésre bocsátása vagy fejlesztése) megtörtént.

4. ábra. A rendszeréletciklus-modellek általános (T) szakaszos felépítése (Lawson 2010). Harold Lawson engedélyével újranyomtatva. Minden egyéb jog a szerzői jog tulajdonosát illeti meg.

Az 5. ábra az általános életciklus szakaszokat mutatja be a különböző érdekelt felek számára, a szabványügyi szervezettől (ISO/IEC) a kereskedelmi és kormányzati szervezetekig. Bár ezek a szakaszok részletesen különböznek egymástól, mindegyik hasonló szekvenciális formátumú, amely a 2. ábra szerinti alapvető tevékenységeket hangsúlyozza (meghatározás, gyártás és felhasználás/visszavonás).

5. ábra. Az életciklusmodellek összehasonlítása (Forsberg, Mooz és Cotterman 2005). Újranyomtatva a John Wiley & Sons engedélyével. Minden egyéb jog a szerzői jogtulajdonosé.

Fontos megjegyezni, hogy az életciklus során számos tevékenység iterálódik. Ez egy példa a rekurzióra (glosszárium)rekurzió (glosszárium), ahogyan azt a 3. rész Bevezetés című fejezetében tárgyaltuk.

Az életciklus szakaszainak és a programmenedzsment fázisának alapjai

Ezért a tárgyalásért fontos megjegyezni, hogy:

• A szakaszszakasz kifejezés a rendszer különböző állapotaira utal az életciklus során; egyes szakaszok időben átfedhetik egymást, például a használati szakasz és a támogatási szakasz. A szakasz kifejezést az ISO/IEC/IEEE 15288 használja.

• A szakasz kifejezés a program különböző lépéseire utal, amelyek a rendszer életciklusát támogatják és irányítják; a szakaszok általában nem fedik egymást. A “fázis” kifejezést számos jól bevált modellben a “szakasz” kifejezés egyenértékűjeként használják.”

ProgrammenedzsmentA programmenedzsment fázisokat, mérföldköveketmérföldköveket és döntési kapukatdöntési kapukat alkalmaz, amelyeket a rendszer különböző szakaszokon keresztül történő fejlődésének értékelésére használnak. A szakaszok tartalmazzák a célok elérése érdekében végzett tevékenységeket, és a szakaszok sorrendjének, valamint az egyes szakaszok közötti átmeneteknek az ellenőrzésére és kezelésére szolgálnak. Minden egyes projekt esetében elengedhetetlen az adott projektekben használt fogalmak és kapcsolódó definíciók meghatározása és közzététele a félreértések minimalizálása érdekében.

Egy tipikus programprogram a következő szakaszokból áll:

• Az előtanulmányi szakasz, amely azonosítja a felhasználói igények új, üzleti szempontból ésszerű megoldásokkal történő kielégítésének potenciális lehetőségeit.
• A megvalósíthatósági szakasz az alternatív koncepciók megvalósíthatóságának vizsgálatából áll, hogy a végrehajtási szakasz megkezdése előtt elérjük a második döntési kaput. A megvalósíthatósági fázis során azonosítják az érdekelt felek igényeit és a rendszer követelményeit, azonosítják és tanulmányozzák az életképes megoldásokat, és virtuális prototípusokat (glosszárium)prototípusokat (glosszárium) lehet megvalósítani. Ebben a fázisban a továbblépésről szóló döntés alapja:
  • megvalósítható-e egy koncepció, és alkalmasnak tekinthető-e egy azonosított fenyegetés elhárítására vagy egy lehetőség kihasználására;
  • megfelelően érett-e egy koncepció ahhoz, hogy indokolja egy új termék vagy termékcsalád további fejlesztését; és
  • meg kell-e hagyni egy ajánlatkérésre válaszul létrehozott javaslatot.
• A végrehajtási fázis a rendszer életciklusának négy szakaszához kapcsolódó tevékenységeket foglalja magában: fejlesztés, gyártás, felhasználás és támogatás. A végrehajtási tevékenységekhez jellemzően két döntési kapu és két mérföldkő kapcsolódik. Az első mérföldkő lehetőséget biztosít a vezetés számára a végrehajtási tervek felülvizsgálatára, mielőtt zöld utat adna. A második mérföldkő lehetőséget biztosít az előrehaladás felülvizsgálatára, mielőtt döntés születik a gyártás megkezdéséről. A végrehajtás során a döntési kapuk segítségével meghatározható, hogy a kifejlesztett SoI-t le kell-e gyártani, és hogy javítani kell-e rajta, vagy ki kell-e vonni a forgalomból.

Ezek a programirányítási nézetek nem csak a SoI-ra, hanem annak elemeire és szerkezetére is vonatkoznak.

Élettartam szakaszok

A Vee-modell változatai az életciklus ugyanazon általános szakaszaival foglalkoznak:

• Az új projektek jellemzően egy feltáró kutatási fázissal kezdődnek, amely általában a koncepció meghatározásának tevékenységeit foglalja magában, különösen az üzleti vagy küldetéselemzés témáit és az érdekelt felek igényeinek és követelményeinek megértését. Ezek érnek, ahogy a projekt a feltáró szakaszból a koncepció szakaszból a fejlesztési szakaszba jut.
• A gyártási szakasz magában foglalja a rendszer meghatározásának és a rendszer megvalósításának tevékenységeit, valamint a rendszer követelményeinek (glosszárium)követelmények (glosszárium) és architektúrájának (glosszárium)architektúra (glosszárium) fejlesztését az ellenőrzésen és validáláson keresztül.
• A hasznosítási szakasz magában foglalja a rendszer telepítésének és üzemeltetésének tevékenységeit.
• A támogatási fázis magában foglalja a rendszer karbantartásának, logisztikájának, valamint a termék- és élettartam-menedzsmentnek a tevékenységeit, amelyek olyan tevékenységeket foglalhatnak magukban, mint az élettartam meghosszabbítása vagy a képességek frissítése, korszerűsítése és modernizálása.
• A nyugdíjazási szakasz magában foglalja az ártalmatlanítás és a nyugdíjazás tevékenységeit, bár egyes modellekben az olyan tevékenységeket, mint az élettartam meghosszabbítása vagy a képességfrissítések, frissítések és korszerűsítések a “nyugdíjazási” szakaszba csoportosítják.

Az egyes szakaszokra vonatkozó további információk az alábbi szakaszokban találhatók (további részletekért lásd a fenti 3. rész további cikkeire mutató linkeket). Fontos megjegyezni, hogy ezeket az életciklus szakaszokat és az egyes szakaszokban végzett tevékenységeket rendszertechnikai irányítási folyamatok támogatják.

Feltáró kutatási szakasz

A felhasználói követelmények elemzése és egyeztetése a feltáró kutatási szakasz részét képezi, és kritikus fontosságú a sikeres rendszerek fejlesztése szempontjából. A felhasználói igények megfelelő megértése nélkül minden rendszer azzal a veszéllyel jár, hogy rossz problémák megoldására épül. A feltáró kutatási szakasz első lépése a felhasználói (és az érdekelt felek) követelmények és korlátozások meghatározása. Ennek a folyamatnak kulcsfontosságú része a felhasználói követelmények teljesíthetőségének megállapítása, beleértve a technológiai felkészültség értékelését is. Mint sok SE-tevékenység esetében, ez is gyakran iteratív módon történik, és az érdekelt felek igényeit és követelményeit az új információk rendelkezésre állása esetén felülvizsgálják.

A Nemzeti Kutatási Tanács nemrégiben készült tanulmánya (National Research Council 2008) az amerikai légierő projektjei fejlesztési idejének csökkentésére összpontosított. A jelentés megjegyzi, hogy “egyszerűen fogalmazva, a rendszertervezés a felhasználói igényeknek a rendszer és annak architektúrája meghatározásába való átültetése egy iteratív folyamat révén, amely hatékony rendszertervezést eredményez”. Az érintettek iteratív bevonása kritikus fontosságú a projekt sikeréhez.

A projekt első és utolsó döntési kapujának kivételével a kapukat egyszerre hajtják végre. Lásd az alábbi 6. ábrát.

6. ábra. A fejlesztési fázisok ütemezése. (SEBoK Original)

Koncepciófázis

A koncepciófázis során alternatív koncepciókat hoznak létre, hogy meghatározzák az érdekelt felek igényeinek leginkább megfelelő megközelítést. Az alternatívák elképzelésével és modellek létrehozásával, beleértve a megfelelő prototípusokat is, tisztázzák az érdekeltek igényeit és kiemelik a mozgatórugókat. Ez a rendszerfejlesztés inkrementális vagy evolúciós megközelítéséhez vezethet. Több különböző koncepciót lehet párhuzamosan vizsgálni.

Kidolgozási szakasz

A koncepció szakaszában azonosított kiválasztott koncepció(ka)t a legalacsonyabb szintig részletesen kidolgozzák, hogy az érdekeltek igényeinek megfelelő megoldás szülessen.

Az érdekeltek igényei. Ebben a szakaszban létfontosságú a felhasználók bevonásának folytatása a folyamaton belüli validáláson keresztül (a felfelé mutató nyíl a Vee-modelleken). A hardverek esetében ez gyakori programfelülvizsgálatokkal és (adott esetben) az ügyfél rezidens képviselőjével (képviselőivel) történik. Az agilis fejlesztésnél az a gyakorlat, hogy az ügyfél képviselőjét integrálják a fejlesztőcsapatba.

Termelési szakasz

A termelési szakaszban a SoI-t megépítik vagy legyártják. A gyártási problémák megoldása, a gyártási költségek csökkentése, illetve a termék vagy a SoI képességeinek javítása érdekében szükség lehet a termék módosítására. E módosítások bármelyike befolyásolhatja a rendszerkövetelményeket, és szükségessé teheti a rendszer újraminősítésétminősítését, újraellenőrzésétminősítését vagy újraérvényesítésétérvényesítését. Minden ilyen módosítás a módosítások jóváhagyása előtt SE-értékelést igényel.

Hasznosítási szakasz

A termék életciklus-menedzsmentjének jelentős aspektusa a támogató rendszerek biztosítása, amelyek létfontosságúak a termék működésének fenntartásában. Míg a szállított termék vagy szolgáltatás a beszerző számára a szűk értelemben vett érdekeltségi rendszernek (NSOI) tekinthető, a beszerzőnek a támogató rendszereket is be kell építenie egy tágabb értelemben vett érdekeltségi rendszerbe (WSOI). Ezeket a támogató rendszereket olyan rendszereszközöknek kell tekinteni, amelyeket szükség esetén az NSOI működésével kapcsolatban felmerült helyzetre válaszul aktiválnak. A támogató rendszerek összességének gyűjtőneve az integrált logisztikai támogatási rendszer (ILS).

A rendszertermékek és -szolgáltatások meghatározásakor, előállításakor és működtetésekor elengedhetetlen a holisztikus szemlélet. A 7. ábrán a rendszertervezés és -fejlesztés, valamint az ILS-követelmények közötti kapcsolatot ábrázoljuk.

7. ábra. Az ILS és a rendszeréletciklus kapcsolata (Eichmueller és Foreman 2009). Újranyomtatva az ASD/AIA S3000L Irányítóbizottság engedélyével. Minden egyéb jog a szerzői jog tulajdonosát illeti meg.

A megbízhatósági követelmények, amelyek a karbantarthatóság és tesztelhetőség igényét eredményezik, hajtóerőt jelentenek.

Támogatási szakasz

A támogatási szakaszban a SoI olyan szolgáltatásokat kap, amelyek lehetővé teszik a folyamatos működést. Módosításokat lehet javasolni a támogathatósági problémák megoldására, az üzemeltetési költségek csökkentésére vagy a rendszer élettartamának meghosszabbítására. Ezek a módosítások SE értékelést igényelnek, hogy elkerüljék a rendszer képességeinek elvesztését működés közben. A megfelelő műszaki folyamat a karbantartási folyamat.

Kivonási szakasz

A kivonási szakaszban a SoI-t és a hozzá kapcsolódó szolgáltatásokat kivonják az üzemeltetésből. Az SE tevékenységei ebben a szakaszban elsősorban az ártalmatlanítási követelmények teljesítésének biztosítására összpontosítanak. Valójában az ártalmatlanítás tervezése a koncepció szakaszában a rendszer meghatározásának részét képezi. A 20. században szerzett tapasztalatok többször megmutatták, hogy milyen következményekkel járt, ha a rendszer nyugdíjazását és ártalmatlanítását nem vették figyelembe a kezdetektől fogva. A 21. század elején számos ország megváltoztatta a törvényeit, hogy a SoI létrehozóját tegye felelőssé a rendszer megfelelő életciklus végi ártalmatlanításáért.

Élettartam-felülvizsgálatok

A projekt előrehaladásának ellenőrzésére különböző típusú felülvizsgálatokat terveznek. A leggyakrabban alkalmazottakat az alábbiakban soroljuk fel, bár az elnevezések nem általánosak:

• A rendszerkövetelmények felülvizsgálatát (SRR) a rendszerkövetelmény-készlet ellenőrzésére és érvényesítésére tervezik, mielőtt a részletes tervezési tevékenységeket megkezdenék.
• A tervezés előzetes felülvizsgálataA tervezés előzetes felülvizsgálata (PDR) a rendszerkövetelmények, a tervezési artefaktumok és az igazoló elemek ellenőrzésére és validálására szolgál az első mérnöki ciklus végén (más néven a “tervezéstől a tervezésig” kapu).
• A kritikus tervellenőrzéstkritikus tervellenőrzés (CDR) a rendszerkövetelmények, a tervezési artefaktumok és az igazoló elemek ellenőrzésére és validálására tervezik az utolsó mérnöki ciklus végén (a “build-to” és “code-to” tervek e felülvizsgálat után kerülnek kiadásra).
• Az integrációintegrációs, ellenőrzésihitelesítési és érvényesítésihitelesítési felülvizsgálatokat a komponensek magasabb szintű alrendszerekké és elemekké történő összeállítása során tervezik. A felülvizsgálatok sorozatát tartják annak biztosítására, hogy minden megfelelően integrálódjon, és hogy objektív bizonyíték legyen arra, hogy minden követelményt teljesítettek. Folyamaton belüli validálást is kell végezni, hogy a rendszer, ahogyan fejlődik, megfelel az érdekelt felek követelményeinek (lásd a 7. ábrát).
• A végső validálási felülvizsgálatot az integrációs fázis végén végzik.
• A rendszer típusától és a kapcsolódó kockázatoktól függően a munka megfelelő előrehaladásának ellenőrzése érdekében egyéb, irányítással kapcsolatos felülvizsgálatok is tervezhetők és végezhetők.

8. ábra. A Vee-modell jobb oldala (Forsberg, Mooz és Cotterman 2005). Újranyomtatva a John Wiley & Sons Inc. engedélyével. Minden más jog a szerzői jog tulajdonosának fenntartva.

Hivatkozott munkák

Eichmueller, P. és B. Foreman. 2010. S3000LTM. Brüsszel, Belgium: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).

Faisandier, A. 2012. Rendszerek architektúrája és tervezése. Belberaud, Franciaország: Sinergy’Com.

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

INCOSE. 2012. Systems Engineering Handbook (Rendszermérnöki kézikönyv): A Guide for System Life Cycle Processes and Activities, 3.2.2. verzió. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.

Lawson, H. 2010. Utazás a rendszerszintű tájakon keresztül. London, UK: College Publications, Kings College, UK.

Primary References

Beedle, M., et al. 2009. “Az agilis kiáltvány: Principles behind the Agile Manifesto”. in The Agile Manifesto . Hozzáférés 2014. december 04. www.agilemanifesto.org/principles.html

Boehm, B. és R. Turner. 2004. Az agilitás és a fegyelem egyensúlyban tartása. New York, NY, USA: Addison-Wesley.

Fairley, R. 2009. Managing and Leading Software Projects (Szoftverprojektek irányítása és vezetése). New York, NY, USA: J. Wiley & Sons.

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

INCOSE. 2012. Systems Engineering Handbook (Rendszermérnöki kézikönyv): A Guide for System Life Cycle Processes and Activities, 3.2.2. verzió. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.

Lawson, H. 2010. Utazás a rendszerszintű tájakon keresztül. Kings College, UK: College Publications.

Pew, R., and A. Mavor (eds.) 2007. Ember-rendszer integráció a rendszerfejlesztési folyamatban: 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.

Kiegészítő hivatkozások

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

Baldwin, C. and K. Clark. 2000. Design Rules (Tervezési szabályok): The Power of Modularity. Cambridge, MA, USA: MIT Press.

Beck, K. 1999. Extreme Programming Explained (Az extrém programozás magyarázata). New York, NY, USA: Addison Wesley.

Beedle, M., et al. 2009. “Az agilis kiáltvány: Principles behind the Agile Manifesto”. in The Agile Manifesto . Hozzáférés 2010. Elérhető: www.agilemanifesto.org/principles.html

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus és P. Gruenbacher (szerk.). 2005. Értékalapú szoftverfejlesztés. New York, NY, USA: Springer.

Boehm, B. 1988. “A szoftverfejlesztés spirális modellje”. IEEE Computer 21(5): 61-72.

Boehm, B. 2006. “Néhány jövőbeli tendencia és következményei a rendszer- és szoftverfejlesztési folyamatokra”. Systems Engineering. 9(1): 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah és R. Madachy. 1998. “A WinWin spirálmodell használata: A Case Study.” IEEE Computer. 31(7): 33-44.

Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (in press). A spirálmodell átölelése: Sikeres rendszerek létrehozása az inkrementális elköteleződés spirálmodelljével. Boston, MA, USA: Addison Wesley.

Castellano, D.R. 2004. “Top Five Quality Software Projects (Öt legjobb minőségű szoftverprojekt)”. CrossTalk. 17(7) (2004. július): 4-19. Elérhető az alábbi címen: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Rendszergondolkodás, rendszerszemléletű gyakorlat. New York, NY, USA: Wiley.

Crosson, S. és B. Boehm. 2009. “A szoftver életciklus horgonypontjainak kiigazítása: Lessons Learned in a System of Systems Context”. Proceedings of the Systems and Software Technology Conference, 2009. április 20-23., Salt Lake City, UT, USA.

Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010. “Agilis szoftverfejlesztés: Current Research and Future Directions.” Chapter in B. Boehm, J. Lane, S. Koolmanjwong, and R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.

Dorner, D. 1996. A kudarc logikája. New York, NY, USA: Basic Books.

Forsberg, K. 1995. “‘Ha én ezt meg tudnám csinálni, akkor én is meg tudnám…’ Rendszertechnika a kutatás-fejlesztési környezetben”. Proceedings of the Fifth Annual International Council on Systems Engineering (INCOSE) International Symposium. 1995. július 22-26. St. Louis, MO, USA.

Forsberg, K. 2010. “A projektek nem a követelményekkel kezdődnek”. Proceedings of the IEEE Systems Conference, 2010. április 5-8., San Diego, CA, USA.

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

Goldratt, E. 1984. A cél. 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. Emergencia. New York, NY, USA: Perseus Books.

ISO/IEC. 2010. Rendszer- és szoftvertervezés, 1. rész: Útmutató az életciklus-menedzsmenthez. Genf, Svájc: Nemzetközi Szabványügyi Szervezet (ISO)/Nemzetközi Elektrotechnikai Bizottság (IEC), ISO/IEC 24748-1:2010.

ISO/IEC/IEEE. 2015. Rendszer- és szoftvertervezés — Rendszeréletciklus-folyamatok. Genf, Svájc: 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. Genf, Svájc: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).

Jarzombek, J. 2003. “Top Five minőségi szoftverprojektek”. CrossTalk. 16(7) (2003. július): 4-19. Elérhető a következő címen: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

Kruchten, P. 1999. A racionális egységesített folyamat. New York, NY, USA: Addison Wesley.

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

Madachy, R. 2008. Szoftverfolyamatok dinamikája. Hoboken, NJ, USA: Wiley.

Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. “Architecture Reviews: Gyakorlat és tapasztalat.” IEEE Software. 22(2): 34-43.

National Research Council of the National Academies (USA). 2008. Pre-Milestone A és korai fázisú rendszertervezés. Washington, DC, USA: The National Academies Press.

Osterweil, L. 1987. “A szoftverfolyamatok is szoftverek”. Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.

Poppendeick, M. és T. Poppendeick. 2003. Lean szoftverfejlesztés: egy agilis eszköztár. New York, NY, USA: Addison Wesley.

Rechtin, E. 1991. System Architecting (Rendszerarchitektúra): Komplex rendszerek létrehozása és építése. Upper Saddle River, NY, USA: Prentice-Hall.

Rechtin, E., and M. Maier. 1997. A rendszerarchitektúra művészete. Boca Raton, FL, USA: CRC Press.

Schwaber, K. és M. Beedle. 2002. Agilis szoftverfejlesztés a Scrum segítségével. Upper Saddle River, NY, USA: Prentice Hall.

Spruill, N. 2002. “Top Five minőségi szoftverprojektek”. CrossTalk. 15(1) (2002. január): 4-19. Elérhető a következő címen: 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) (2005. szeptember): 4-13. Elérhető: http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

Warfield, J. 1976. Társadalmi rendszerek: Planning, Policy, and Complexity. New York, NY, USA: Wiley.

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

Releváns videók=

• Alapvető bevezetés a rendszertervezésbe (V-módszer)
• Basic Introduction to Systems Engineering (V-method) Part 2 of 2