Waterfall – Kaskad modeli

Kaskad modelining tashkiloti

Kaskad modeli, Waterfall (sharshara) nomi bilan ham tanilgan — dasturiy ta'minot yaratishda eng taniqli yondashuvlardan biri. Modelning muallifi Uinston Royce. 1970 yilda u o'z innovatsiyasining mohiyatini uning afzalliklari va kamchiliklari batafsil ko'rsatgan maqolasida bayon qildi. Unga ko'ra, ushbu model iterativ modelga qayta ishlanishi mumkinligini ham tushuntirdi. Boshlang'ich kaskad modelida rivojlanish bosqichlari quyidagi tartibda amalga oshiriladi:

• Talablarni aniqlash va kelishish;
• Loyihani tasdiqlash;
• Kodlash;
• Dasturiy ta'minotning ishlaydigan versiyasini yaratish;
• Sinov va nosozliklarni tuzatish;
• Dasturni o'rnatish;
• Qo'llab-quvvatlash.

Kaskad modeliga ko'ra, ishlab chiquvchilar boshqacha harakat qiladi — har bir qadamni birma-bir bajargan holda. Boshlanish uchun dasturiy ta'minot talablarini aniqlash va kelishish ishlarini tugatish kerak, ro'yxatning bajarilishi kerak bo'lgan qismi sifatida.

Bundan keyin loyiha yaratish va tasdiqlashga o'tishadi, natijada avval kelishilgan dasturiy ta'minot talablarini amalga oshirish usullari bilan bog'liq hujjatlar yoziladi.

Projektlash tugallanganda, ishlab chiquvchilar amalga oshirishga kirishadi. Keyin kodni birlashtirish — loyihaning turli ishtirokchilari tomonidan bajarilgan alohida qismlarni integratsiyalash amalga oshiriladi.

Keyingi bosqichda mahsulotni sinov va nosozliklarni tuzatish jarayoni olib boriladi. Bu yerda ilgari topilgan xatolar bartaraf etiladi.

Oxirida, dastur o'rnatiladi va uning qo'llab-quvvatlanishi ta'minlanadi. Bu, zarur bo'lganda, funksionallikka o'zgartirishlar kiritishni va topilgan xatolarni bartaraf etishni o'z ichiga oladi.

Kaskad modeli haqiqiy ishlab chiqishning keyingi bosqichiga o'tish uchun faqat avvalgi vazifa tugatilgandan keyin ketma-ket o'tishni nazarda tutadi. Qayta orqaga qaytish yoki bosqichlar orasidagi ketma-ketlikning buzilishi ko'zda tutilmaydi.

Afzalliklari va kamchiliklari

Vaql vaqti bilan kaskad modeli uning yetarli moslashuvchan emasligi uchun tanqid qilinadi. Ko'p muhannolar uni yoqtirmaydi, chunki unda loyiha boshqarish maqsadi ustunlik qiladi, garchi muddatlarga rioya qilish, rivojlanish xarajatlari va sifati ancha muhimroq bo'lsa ham.

Lekin, agar katta loyihalar haqida gap ketayotgan bo'lsa, ularda boshqarish haqiqatdan ham ko'pincha ahamiyatli bo'ladi, chunki bu loyiha xavfini kamaytiradi va ishda shaffoflikni oshiradi.

Kamchiliklariga qaramay, PMBOK 3-versiyasida faqat “kaskad modelining” metodikasi rasmiy ko'rsatilgan. Bosqcha variantlar, shu jumladan, iterativ loyihalarni olib borish, unda taklif qilinmaydi.

Kaskad modelining afzalliklari:

• Jamoada rivojlanishni nazorat qilish osonroq. Buyurtmachi hozirda dasturchilar nimada ishlayotganini biladi, u muddatlarni va loyihaning budjetini o'zgartirishi mumkin.
• Rivojlanish narxi birinchi bosqichda tasdiqlanadi. Barcha bosqichlarda kelishilganidan so'ng, dasturiy ta'minot uzluksiz yoziladi.
• Tajriba kerak bo'lmagan testchilar kerak emas. Sinov bosqichi uchun dasturiy hujjatlarni ishlatish mumkin.

Kaskad modelining kamchiliklari:

• Sinov rivojlanish tugagan bosqichda boshlangani uchun, xato topilishi yoki uni tuzatishi dastlabki bosqichda topilganda qimmatroq bo'ladi. Chunki testchilar xatoni faqat dasturchi kodni yozib bitirgandan keyin topishadi, kopirayterlar esa hujjatlarni yozishni tugatishadi.
• Buyurtmachi mahsulot bilan rivojlanish tugallangandan keyin tanishadi. Shuning uchun, u mahsulotni faqat u deyarli tayyor bo'lganida baholay oladi. Agar natija unga yoqmasa, loyihaning budjet qiymati sezilarli darajada oshib ketadi, bunda tuzatishga muhtoj.
• Texnik hujjatlar qancha ko'p bo'lsa, ishni tugatishga shunchalik uzoq. Bunday hujjatlar ko'proq o'zgarishlar va kelishuvlarni talab qiladi.

“Sharshara” tibbiyot va kosmik sohalarida ko'p qo'llaniladi, u yerda yangi dasturiy ta'minotga talablarni tuzish mumkin bo'lgan keng hujjatlar bazasi mavjud.

Kaskad modelini ishlatishda asosiy narsa — chuqur talablar tuzish. Sinov vaqtida butun loyihaga salbiy ta'sir ko'rsatuvchi biron joyda xato bo'lmasligi kerak.