Kontent qismiga oʻtish

Dasturiy taʼminot yaratish

Vikipediya, ochiq ensiklopediya

Dasturiy taʼminotni yaratish – dasturiy injiniring sohasining bir yoʻnalishi boʻlib, kodlash, tekshirish, modul testlari, integratsiya testlari va nosozliklarni bartaraf etish orqali batafsil ishlaydigan, maʼnoli dasturiy ta’minotni yaratish jarayoni. Bu yoʻnalish boshqa barcha dasturiy injiniring sohalari bilan bogʻliq boʻlib, ayniqsa dasturiy taʼminotni loyihalash va sinovdan oʻtkazish bilan chambarchas aloqador[1].

Murakkablikni minimallashtirish

[tahrir | manbasini tahrirlash]

Murakkablikni minimallashtirish zarurati, asosan, koʻpchilik odamlarning murakkab tuzilmalar va ma’lumotlarni oʻzlarining ishchi xotiralarida saqlash qobiliyati cheklanganligi bilan bogʻliq. Murakkablikni minimallashtirish uchun aqlli emas, balki oddiy va tushunarli kod yaratishga eʼtibor qaratiladi. Murakkablikni minimallashtirish standartlardan foydalanish va kodlashning turli xil maxsus usullarini qoʻllash orqali amalga oshiriladi va bu jarayon qurilishga yoʻnaltirilgan sifat texnikalaridan foydalanish bilan ham qoʻllab-quvvatlanadi[2].

Kutilayotgan oʻzgarishlar

[tahrir | manbasini tahrirlash]

Oʻzgarishlarni oldindan koʻra bilish dasturiy ta’minot muhandislariga kengaytiriladigan dasturiy taʼminotni yaratishga yordam beradi va ular asosiy tuzilmani buzmasdan dasturiy mahsulotni takomillashtira oladilar[2] . 25 yil davomida olib borilgan tadqiqotlar shuni koʻrsatdiki, qayta ishlash xarajatlari talablarni birinchi marta toʻgʻri belgilashga nisbatan 10 barobardan 100 barobargacha (kichikroq loyihalar uchun 5 barobardan 10 barobargacha) qimmatroq boʻlishi mumkin[3].

Tasdiqlash uchun konstruksiyalash

[tahrir | manbasini tahrirlash]

Tasdiqlash uchun konstruksiyalash deganda dasturiy taʼminot muhandislari tomonidan, shuningdek, mustaqil sinov va operatsion faoliyat davomida nosozliklarni osonlik bilan aniqlash mumkin boʻlgan tarzda dasturiy taʼminot yaratish tushuniladi. Tasdiqlash uchun qurilishni qoʻllab-quvvatlaydigan oʻziga xos usullar kodni koʻrib chiqishni qoʻllab-quvvatlash uchun kodlash standartlariga rioya qilish, birliklarni sinovdan oʻtkazish, avtomatlashtirilgan sinovlarni qoʻllab-quvvatlash uchun kodni tashkil etish va murakkab yoki qiyin tushuniladigan til tuzilmalaridan cheklangan foydalanish va boshqalar kiradi[2].

Qayta ishlatish

[tahrir | manbasini tahrirlash]

Tizimli qayta foydalanish dasturiy taʼminotning unumdorligi, sifati va narxini sezilarli darajada yaxshilashga imkon beradi. Qayta foydalanish ikkita bir-biri bilan chambarchas bogʻliq jihatlarga ega[2]:

  • Takroriy foydalanish uchun qurilish: qayta ishlatiladigan dasturiy taʼminot obyektlarini yaratish.
  • Qayta foydalanish bilan qurilish: yangi yechimni qurishda dasturiy taʼminot vositalaridan qayta foydalanish.

Yaratishdagi standartlar

[tahrir | manbasini tahrirlash]

Tashqi (xalqaro tashkilotlar tomonidan yaratilgan) yoki ichki (korporativ darajada yaratilgan) qurilish masalalariga bevosita taʼsir koʻrsatadigan standartlarga quyidagilar kiradi[2]:

Dasturiy ta'minot ishlab chiqish jarayoni bir necha asosiy bosqichlarga bo'linadi:

  • Talablarni yig'ish — foydalanuvchi talablarini tushunish va tahlil qilish.
  • Kodlash — dasturiy kodlarni yozish va sinovdan o'tkazish.
  • Test qilish va nazorat — mahsulotning sifatini oshirish uchun sinovlar o'tkazish[4].
  • Texnik xizmat — mahsulotni doimiy ravishda qo'llab-quvvatlash va yangilash.

Jarayonni boshqarish

[tahrir | manbasini tahrirlash]

Yaratish modeli

[tahrir | manbasini tahrirlash]

Dasturiy ta’minotni ishlab chiqish uchun koʻplab modellar yaratilgan boʻlib, ularning baʼzilari boshqalaridan koʻra koʻproq qurilishga urgʻu beradi. Baʼzi modellar qurilish nuqtai nazaridan chiziqliroqdir, masalan, sharshara va bosqichma-bosqich yetkazib berish hayotiy sikli modellari. Ushbu modellarda qurilishga faqat muhim zaruriy ishlar – batafsil talablar boʻyicha ishlar, keng koʻlamli loyihalash ishlari va batafsil rejalashtirishdan keyin sodir boʻladigan faoliyat sifatida qaraladi[1].

Jarayonni rejalashtirish

[tahrir | manbasini tahrirlash]

Dasturiy taʼminotni yaratish usulini tanlash jarayonni rejalashtirish faoliyatining asosiy jihatidir. Yaratish usulini tanlash jarayon shart-sharoitlarining qay darajada ekanligiga taʼsir qiladi (masalan. Talablar tahlili, Dasturiy ta’minotni loyihalash va boshqalar) amalga oshiriladi, ular qanday tartibda bajariladi va qurilish ishlari boshlanishidan oldin ular qanday darajada bajarilishi kutiladi[1].

Jarayonni hisoblash

[tahrir | manbasini tahrirlash]

Koʻpgina yaratish jarayoni faoliyati va artefaktlarni oʻlchash mumkin, jumladan kod ishlab chiqilgan, kod oʻzgartirilgan, kod qayta ishlatilgan, kod vayron qilingan, kod murakkabligi, kod tekshiruvi statistikasi, nosozliklarni tuzatish va nosozliklarni topish stavkalari, kuch va rejalashtirish. Ushbu oʻlchashlar jarayonni boshqarish, qurilishda sifatni taʼminlash, yaratish jarayonini takomillashtirish maqsadlarida va boshqa sabablarga koʻra foydali boʻlishi mumkin[1].

Amaliy maslahatlar

[tahrir | manbasini tahrirlash]

Dasturiy taʼminotni yaratish koʻplab amaliy mulohazalarga asoslanadi:

Dasturiy taʼminot dizayni

[tahrir | manbasini tahrirlash]

Dasturiy taʼminot dizaynidagi kutilmagan boʻshliqlarni hisobga olish uchun dasturiy taʼminotni yaratish vaqtida dasturiy taʼminot dizaynining tafsilotlarini toʻldirish uchun kichikroq yoki kattaroq miqyosda baʼzi dizayn modifikatsiyalari amalga oshirilishi kerak[5].

Dasturiy taʼminot tillari

[tahrir | manbasini tahrirlash]

Konstruksiya tillari muloqotning barcha shakllarini oʻz ichiga oladi, ular orqali inson kompyuterga bajariladigan muammoning yechimini aniqlashi mumkin. Ularga konfiguratsiya tillari, asboblar toʻplami tillari va dasturlash tillari kiradi[6]:

  • Konfiguratsiya tillari – bu dasturiy taʼminot muhandislari yangi yoki maxsus dasturiy taʼminotni oʻrnatish uchun oldindan belgilangan variantlarning cheklangan toʻplamidan tanlaydigan tillardir.
  • Vositalar toʻplami tillari ilovalarni asboblar toʻplamidan yaratish uchun ishlatiladi va konfiguratsiya tillariga qaraganda murakkabroqdir.
  • Skriptlash tillari – skriptlarni qoʻllab-quvvatlaydigan ilova dasturlash tillarining bir turi boʻlib, ular koʻpincha tuzilgan emas, balki sharhlanadi.
  • Dasturlash tillari konstruksiya tillarining eng moslashuvchan turi boʻlib, ular uchta umumiy belgi turlaridan foydalanadi:
    • Til belgilari, xususan, murakkab dasturiy tuzilmalarni ifodalash uchun matnning soʻzsimon qatorlaridan foydalanish va bunday soʻzsimon qatorlarning gap sintaksisiga ega boʻlgan qoliplarga birikishi bilan ajralib turadi.
    • Soʻzlar va matn satrlarining intuitiv, kundalik maʼnolariga kamroq va aniq, bir maʼnoli va rasmiy (yoki matematik) taʼriflar bilan qoʻllab-quvvatlanadigan taʼriflarga koʻproq tayanadigan rasmiy belgilar.
    • Vizual belgilar, ular ham lingvistik, ham rasmiy qurilishning matnga yoʻnaltirilgan belgilariga kamroq tayanadi va buning oʻrniga asosiy dasturiy taʼminotni ifodalovchi vizual obyektlarni toʻgʻridan-toʻgʻri vizual talqin qilish va joylashtirishga tayanadi.

Uch yil va undan ortiq vaqt davomida ishlatayotgan tilda ishlaydigan dasturchilar, xuddi shu tilda yangi boʻlgan tajribaga ega dasturchilarga qaraganda, taxminan 30 foizga koʻproq mahsuldir. C++, Java, Smalltalk va Visual Basic kabi yuqori darajadagi tillar assembly va C kabi quyi darajadagi tillarga qaraganda 5-15 baravar yuqori mahsuldorlik, ishonchlilik, soddalik va tushunarlilikni beradi[7].

Quyidagi mulohazalar dasturiy taʼminot konstruktsiyasini kodlash faoliyatiga tegishli[8]:

  • Tushunarli manba kodini yaratish usullari, shu jumladan nomlash va manba kodi sxemasi. Bir tadqiqot shuni koʻrsatdiki, oʻzgaruvchilarning nomlari 10 dan 16 tagacha belgidan iborat boʻlsa, dasturni debaglash uchun zarur boʻlgan kuch minimallashtiriladi[9].
  • Sinflar, sanab oʻtilgan turlar, oʻzgaruvchilar, nomlangan oʻzgarmaslar va boshqa oʻxshash obyektlardan foydalanish:
    • NASA tomonidan oʻtkazilgan tadqiqot shuni koʻrsatdiki, kodni yaxshi omilli sinflarga joylashtirish funksional dizayn yordamida ishlab chiqilgan kodga nisbatan kodning qayta ishlatilishi ikki baravar koʻpaytirishi mumkin[10][11].
    • Bir tajriba shuni koʻrsatdiki, massivlarga tasodifiy emas, balki ketma-ket kiruvchi dizaynlar kamroq oʻzgaruvchilarga va kamroq oʻzgaruvchi havolalarga olib keladi[12].
  • Boshqaruv tuzilmalaridan foydalanish:
    • Bir tajriba shuni koʻrsatdiki, chiqish bilan halqalar boshqa turdagi halqalarga qaraganda tushunarliroqdir[13].
    • Halqa va shartlarda uyalash darajasi boʻyicha oʻtkazilgan tadqiqotlar shuni koʻrsatdiki, dasturchilar uyalashning uchdan ortiq darajasini tushunishda qiynalishadi[13][14].
    • Boshqaruv oqimining murakkabligi past ishonchlilik va tez-tez xatolar bilan bogʻliqligi koʻrsatilgan[14].
  • Xatolik shartlari bilan ishlash – ham rejalashtirilgan xatolar, ham istisnolar (masalan, notoʻgʻri maʼlumotlarni kiritish)
  • Kod darajasidagi xavfsizlik buzilishlarining oldini olish (masalan, buferning oshib ketishi yoki massiv indeksining oshib ketishi)
  • Qayta ishlatiladigan resurslarga (jumladan, mavzular yoki maʼlumotlar bazasi bloklariga) kirishda istisno mexanizmlari va intizomdan foydalanish orqali resurslardan foydalanish
  • Manba kodini tashkil etish (bayonnomalar va dasturlarga)[11]:
    • Yuqori kogezion tartiblar past kogezion tartiblarga qaraganda kamroq xatoliklarga moyil ekanligi isbotlandi. 450 ta tartibni oʻrganish shuni koʻrsatdiki, yuqori kogezion tartiblarning 50 foizi kam kogezion tartiblarning atigi 18 foiziga nisbatan nosozlikdan xoli edi. Boshqa 450 ta dasturni oʻrganish shuni koʻrsatdiki, eng yuqori ulanish koeffitsiyentiga ega dasturlar eng past ulanish koeffitsiyentiga ega dasturlarga qaraganda 7 baravar koʻp xatoliklarga ega va tuzatish 20 baravar qimmatga tushadi.
    • Tadqiqotlar dastur oʻlchamlari va undagi xatolar darajasi oʻrtasidagi korrelyatsiya boʻyicha noaniq natijalarni koʻrsatgan boʻlsa-da, bir tadqiqotda 143 satrdan kam kodli dasturlarni tuzatish kattaroq dasturlarga qaraganda 2,4 baravar arzonroq ekanligi aniqlandi. Boshqa bir tadqiqot shuni koʻrsatdiki, dastur oʻrtacha 100 dan 150 gacha kod satriga ega boʻlganda kodni oʻzgartirish kerak edi. Boshqa bir tadqiqot shuni koʻrsatdiki, dasturdagi maʼlumotlarning tarkibiy murakkabligi va hajmi, uning oʻlchamidan qatʼi nazar, xatolar bilan bogʻliq.
    • Dasturlar orasidagi interfeyslar dasturning eng kam uchraydigan sohalaridan biridir. Bir tadqiqot shuni koʻrsatdiki, barcha xatolarning 39 foizi odatlar oʻrtasidagi aloqa xatolari edi.
    • Ishlatilmagan parametrlar xatolik darajasining oshishi bilan bogʻliq. Bir tadqiqotda bitta oʻzgaruvchisi boʻlmagan dasturlarning atigi 17-29 foizi xatoga yoʻl qoʻymagan boʻlsa, foydalanilmagan oʻzgaruvchisi boʻlmagan dasturlarning 46 foizi xatoga yoʻl qoʻymagan.
    • Dastur parametrlari soni maksimal 7 ta boʻlishi kerak, chunki tadqiqotlar shuni koʻrsatdiki, odamlar odatda bir vaqtning oʻzida yettidan ortiq maʼlumotni kuzatib bora olmaydilar.
  • Manba kodini tashkil etish (sinflar, paketlar yoki boshqa tuzilmalarga). Cheklovni hisobga olgan holda, sinfdagi maʼlumotlar aʼzolarining maksimal soni 7±2 dan oshmasligi kerak. Tadqiqotlar shuni koʻrsatdiki, bu raqam inson boshqa vazifalarni bajarayotganda eslab qolishi mumkin boʻlgan diskret elementlar soni hisoblanadi. Irsiyatni koʻrib chiqishda irsiy daraxtdagi darajalar soni cheklangan boʻlishi kerak. Chuqur irsiy daraxtlarning buzilishlar darajasining oshishi bilan sezilarli darajada bogʻliqligi aniqlandi. Sinfdagi tartiblar sonini hisobga olgan holda, u imkon qadar kichik boʻlishi kerak. C++ dasturlari boʻyicha oʻtkazilgan tadqiqotda dasturlar soni va nosozliklar soni oʻrtasidagi bogʻliqlik aniqlandi[10].
  • Kod hujjatlari
  • Kodni sozlash

Dasturiy taʼminotni testlash

[tahrir | manbasini tahrirlash]

Qurilmani sinovdan oʻtkazishdan maqsad buzilishlarni kodga kiritish vaqti bilan buzilishlarni aniqlash vaqti oʻrtasidagi farqni kamaytirishdir. Baʼzi hollarda qurilish sinovlari kod yozilgandan soʻng amalga oshiriladi. Test-first dasturlashda test keyslari kod yozilishidan oldin yaratiladi. Qurilish sinovning ikki shaklini oʻz ichiga oladi, ular koʻpincha kodni yozgan dasturiy taʼminot muhandisi tomonidan amalga oshiriladi[1]:

Qayta ishlatish

[tahrir | manbasini tahrirlash]

Dasturiy taʼminotdan qayta foydalanishni amalga oshirish nafaqat aktivlar kutubxonalarini yaratish va ulardan foydalanishni oʻz ichiga oladi. Bu qayta foydalanish jarayonlari va faoliyatini dasturiy taʼminotning hayotiy sikliga integratsiya qilish orqali qayta foydalanish amaliyotini rasmiylashtirishni talab qiladi. Kodlash va testlash jarayonida dasturiy taʼminotni yaratishda qayta foydalanish bilan bogʻliq vazifalar quyidagilardan iborat[1]:

  • Qayta ishlatiladigan birliklarni, maʼlumotlar bazalarini, test protseduralarini yoki test maʼlumotlarini tanlash
  • Kod yoki testning qayta ishlatilishini baholash.
  • Yangi kod, test protseduralari yoki test maʼlumotlari haqida qayta foydalanish haqida xabar berish.

Dasturiy taʼminot sifati

[tahrir | manbasini tahrirlash]

Kodni yaratishda uning sifatini taʼminlash uchun ishlatiladigan asosiy usullar quyidagilardan iborat[15]:

  • Birlik sinovi va integratsion sinov. Bir tadqiqot shuni koʻrsatdiki, birlik sinovida va integratsiya sinovida nuqsonlarni aniqlashning oʻrtacha koʻrsatkichlari mos ravishda 30% va 35% ni tashkil qiladi.[16].
  • Test-first dasturlash
  • Taʼkidlar va himoya dasturlaridan foydalanish
  • Debugging
  • Tekshirishlar. Bir tadqiqot shuni koʻrsatdiki, rasmiy kod tekshiruvlarining oʻrtacha nuqsonlarni aniqlash darajasi 60% ni tashkil qiladi. Nuqsonlarni topish xarajatlariga kelsak, tadqiqot shuni koʻrsatdiki, kodni oʻqish sinovdan koʻra soatiga 80% koʻproq nosozliklarni aniqladi. Boshqa bir tadqiqot shuni koʻrsatdiki, sinovdan oʻtkazish orqali dizayn nuqsonlarini aniqlash tekshiruvdan foydalanishdan koʻra olti baravar qimmatroqdir. IBM tomonidan oʻtkazilgan tadqiqot shuni koʻrsatdiki, kod tekshiruvi orqali nuqsonni topish uchun atigi 3,5 soat kerak boʻldi, sinov orqali esa 15-25 soat kerak boʻldi. Microsoft maʼlumotlariga koʻra, kod tekshiruvidan foydalangan holda nuqsonni topish va tuzatish uchun 3 soat, sinovdan foydalangan holda nuqsonni topish va tuzatish uchun esa 12 soat vaqt ketadi. 700 ming satrlik dasturda kodni koʻrib chiqish sinovdan bir necha barobar tejamkor ekanligi maʼlum qilindi[16]. Tadqiqotchilar shuni aniqladiki, rasmiy tekshiruvda 2-3 dan ortiq tekshiruvchining boʻlishi aniqlangan nuqsonlar sonini oshirmaydi, garchi natijalar tekshirilayotgan material turiga qarab farq qiladi[17].
  • Texnik sharhlar. Bir tadqiqot shuni koʻrsatdiki, norasmiy kodni koʻrib chiqish va stol tekshiruvidagi nuqsonlarni aniqlashning oʻrtacha koʻrsatkichlari mos ravishda 25% va 40% ni tashkil qiladi. [1] Yoʻriqnomalar nuqsonlarni aniqlash darajasi 20% – 40% ekanligi aniqlandi, ammo loyiha bosimi oshganda ham qimmat boʻlishi aniqlandi. Kodni oʻqish NASA tomonidan sinov uchun soatiga 3,3 ta kamchilikni va soatiga 1,8 ta kamchilikni aniqlash uchun topildi. Shuningdek, u turli xil sinovlarga qaraganda loyiha hayoti davomida 20% – 60% koʻproq xatolarni topadi. Tekshiruv yigʻilishlari boʻyicha 13 ta sharhni oʻrganish shuni koʻrsatdiki, kamchiliklarning 90 foizi koʻrib chiqish yigʻilishiga tayyorgarlik koʻrish paytida, atigi 10 foizi esa yigʻilish paytida aniqlangan[17].
  • Statik tahlil (IEEE1028)

Tadqiqotlar shuni koʻrsatdiki, nuqsonlarni aniqlashning yuqori darajasiga erishish uchun ushbu usullarning kombinatsiyasidan foydalanish kerak. Boshqa tadqiqotlar shuni koʻrsatdiki, turli odamlar turli nuqsonlarni topishga moyil. Bir tadqiqot shuni koʻrsatdiki, juft dasturlashning ekstremal dasturlash amaliyoti, stolda tekshirish, birliklarni sinovdan oʻtkazish, integratsiyani sinovdan oʻtkazish va regressiya sinovidan oʻtkazish 90% nuqsonlarni aniqlash darajasiga erishishi mumkin[16]. Tajribali dasturchilar ishtirokida oʻtkazilgan tajriba shuni koʻrsatdiki, ular test orqali 15 ta xatodan oʻrtacha 5 tasini (eng yaxshi holatda 9) topa olishdi[18].

80% xatolar loyiha mashgʻulotlari va dasturlarining 20% da toʻplangan. 50% xatolik loyiha sinflarining 5% ida topiladi. IBM 425 ta sinfdan faqat 31 tasini tuzatish yoki qayta yozish orqali mijoz tomonidan eʼlon qilingan kamchiliklarni oʻn baravarga bir baravarga kamaytirishga va oʻzining IMS tizimida texnik xizmat koʻrsatish byudjetini 45 foizga kamaytirishga muvaffaq boʻldi. Loyiha dasturlarining taxminan 20 foizi ishlab chiqish xarajatlarining 80 foizini tashkil qiladi. IBM tomonidan oʻtkazilgan klassik tadqiqot shuni koʻrsatdiki, OS/360 ning kam sonli xatolarga moyil dasturlari eng qimmat obyektlar edi. Ularda 1000 ta kod satriga taxminan 50 ta nuqson bor edi va ularni tuzatish butun tizimni ishlab chiqish uchun kerak boʻlganidan 10 baravar qimmatga tushadi[18].

Qurilish jarayonidagi asosiy faoliyat alohida qurilgan tartiblar, sinflar, komponentlar va quyi tizimlarning integratsiyalashuvidir. Bundan tashqari, maʼlum bir dasturiy tizim boshqa dasturiy yoki apparat tizimlari bilan integratsiya qilinishi kerak boʻlishi mumkin. Qurilish integratsiyasi bilan bogʻliq muammolarga komponentlar integratsiya qilinadigan ketma-ketlikni rejalashtirish, dasturiy taʼminotning oraliq versiyalarini qoʻllab-quvvatlash uchun poydevor yaratishdan oldin komponentlar boʻyicha sinov darajasi va sifatli ishlarni aniqlash kiradi[1].

Dasturiy taʼminot texnologiyalari

[tahrir | manbasini tahrirlash]

Obyektga yoʻnaltirilgan ishlash vaqti muammolari

[tahrir | manbasini tahrirlash]

Obyektga yoʻnaltirilgan tillarda maʼlumotlarni abstraksiyalash, enkapsulyatsiya, modullilik, irsiyat, polimorfizm va aks ettirish kabi dasturlarning moslashuvchanligi va moslashuvchanligini oshiruvchi bir qator ishlash vaqti mexanizmlari qoʻllab-quvvatlanadi[19][20].

  1. 1,0 1,1 1,2 1,3 1,4 1,5 1,6 SWEBOK „Chapter 4: Software Construction“, Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, 2004 — 4–1–4–5-bet. ISBN 0-7695-2330-7. 
  2. 2,0 2,1 2,2 2,3 2,4 SWEBOK 2014, s. 3-3.
  3. McConnell 2004, Chapter 3.
  4. „IBM Software Development Overview“ (2023-yil 8-noyabr).
  5. SWEBOK 2014, s. 3-5.
  6. SWEBOK 2014, s. 3-5 - 3-6.
  7. McConnell 2004, Chapter 4.
  8. SWEBOK 2014, s. 3-6.
  9. McConnell 2004, Chapter 11.
  10. 10,0 10,1 McConnell 2004, Chapter 6.
  11. 11,0 11,1 McConnell 2004, Chapter 7.
  12. McConnell 2004, Chapter 12.
  13. 13,0 13,1 McConnell 2004, Chapter 16.
  14. 14,0 14,1 McConnell 2004, Chapter 19.
  15. SWEBOK 2014, s. 3-7.
  16. 16,0 16,1 16,2 McConnell 2004, Chapter 20.
  17. 17,0 17,1 McConnell 2004, Chapter 21.
  18. 18,0 18,1 McConnell 2004, Chapter 22.
  19. SWEBOK 2014, s. 3-8.
  20. Thayer 2013, ss. 140–141.