Guruh raqami: 15-18 Variant raqami: Savollar

Dasturiy ta’minot tizimlarini loyixalash: Yakuniy Nazorat
Bajardi: Jumamuratov Sardor

Guruh raqami: 315-18

Variant raqami: 7

Savollar:

1. 
   Baholash usullari va ularning sinflanishi
   
2. 
   DT loyihalash modellari
   
3. 
   Ko’prik andoza(Bridge)
   

Javoblar:

1. 
   Baholash usullari va ularning sinflanishi
   
   
   

1. Algoritmik modellashtirish. Usul oldindan bajarilgan loyihalar bo'yicha statistik ma'lumotlarni tahlil qilishga asoslanadi, shu bilan birga loyihaning murakkabligi dasturiy mahsulotning ba'zi miqdoriy ko'rsatkichlariga (odatda dastur kodining o'lchamiga) bog'liqligini aniqlaydi. Ushbu ko'rsatkich ma'lum bir loyiha uchun baholanadi, undan so'ng model yordamida kelajakdagi xarajatlar bashorat qilinadi.
2. Ekspert baholari. Yaratilayotgan dasturiy mahsulot hajmini biladigan dasturiy ta'minotni ishlab chiqish texnologiyasi bo'yicha bir nechta mutaxassislar o'rtasida so'rov o'tkazilmoqda. Ularning har biri loyihaning murakkabligini o'z bahosini beradi. Keyin barcha baholar taqqoslanadi va muhokama qilinadi. Ushbu jarayon dastlabki ish hajmining yakuniy versiyasi bo'yicha kelishuvga erishilgunga qadar takrorlanadi.
3. Analogiya bo'yicha baholash. Ushbu usul, agar yaratilayotgan dasturiy ta'minotni qo'llash sohasida ushbu kabi loyihalar allaqachon amalga oshirilgan bo'lsa, qo'llaniladi. Usul rejalashtirilgan loyihani o'xshash xususiyatlarga ega bo'lgan avvalgi loyihalar bilan taqqoslashga asoslangan. Bu mutaxassis ma'lumotlaridan yoki saqlangan loyiha ma'lumotlaridan foydalanadi. Mutaxassislar yangi va avvalgi loyihalar o'rtasidagi farqlar asosida yuqori, past va katta ehtimollik bilan mehnatga oid hisob-kitoblarni hisoblashadi. Qiyoslash chuqurligiga qarab baholash ancha batafsil bo'lishi mumkin. Modelning zaifligi shundan iboratki, yangi loyiha bilan oldingilar o'rtasidagi o'xshashlik darajasi, qoida tariqasida, unchalik katta emas.
Sizning loyihangizning ish hajmini va shunga o'xshash hajmdagi avvalgi loyihalar bilan solishtirish uchun sizning tashkilotingizda to'plangan tarixiy ma'lumotlardan foydalanish eng yaxshi variantdir. Biroq, bu faqat quyidagi sharoitlarda mumkin:
· Tashkilot avvalgi loyihalarning real natijalarini aniq hujjatlashtiradi;
· Oldingi loyihalardan kamida bittasi (va afzalroq bo'lsa bir nechta) o'xshash tabiatga va hajmga ega;
· Hayotiy tsikl, ishlatilgan rivojlanish usullari va vositalari, yangi loyihaning loyiha guruhining malakasi va tajribasi ham avvalgi loyihalarda bo'lganlarga o'xshaydi.

4. Parkinson qonuni. Ushbu qonunga ko'ra, ish uchun sarf qilingan kuchlar loyihaga sarflangan vaqt davomida teng taqsimlanadi. Bu erda loyiha xarajatlarini baholash mezonlari dasturiy mahsulotning maqsadli bahosi emas, balki inson resurslari hisoblanadi. Agar besh kishilik loyihani 12 oy ichida yakunlash kerak bo'lsa, uni amalga oshirish qiymati 60 kishi-oyda hisoblanadi.

5. Shartnomani yutib olish maqsadida baholash. Loyiha xarajatlari mijoz uchun mavjud bo'lgan mablag 'mavjudligi bilan belgilanadi. Shuning uchun loyihaning murakkabligi yaratilayotgan mahsulotning funktsional xususiyatlariga emas, balki mijozning byudjetiga bog'liq. Qabul qilingan byudjetdan tashqariga chiqmaslik uchun talablarni o'zgartirish kerak.
Har bir baholash usuli kuchli va zaif tomonlariga ega. Katta loyihalarda ishlash uchun ularni keyinchalik taqqoslash uchun bir nechta baholash usullarini qo'llash kerak. Agar natijalar butunlay boshqacha bo'lsa, unda aniqroq taxmin qilish uchun etarli ma'lumot yo'q. Bunday holda, qo'shimcha ma'lumotlardan foydalanish kerak, so'ngra baholashni takrorlash kerak va hokazo turli xil usullarning natijalari etarlicha yaqin bo'lguncha.
Ta'riflangan baholash usullari, agar kelajakdagi tizim talablari hujjatlashtirilgan bo'lsa, amal qiladi. Bunday holda, ishlab chiqilayotgan tizimning funktsional xususiyatlarini aniqlash mumkin. Biroq, ko'plab loyihalarda xarajatlar smetasi faqat talab qilinadigan tizim talablariga asoslanadi. Bunday holda, loyiha xarajatlar smetasida ishtirok etadigan shaxslar ishlash uchun minimal ma'lumotga ega bo'lishadi. Talablarni tahlil qilish va spetsifikatsiyani yaratish qimmatga tushadi. Shuning uchun menejerlar butun loyiha uchun byudjetni tasdiqlashdan oldin ham ularni amalga oshirish uchun smeta tuzishlari kerak.
Ushbu sohadagi amaliyot shundan iboratki, mustaqil baholash (ya'ni rivojlanish guruhidan mustaqil bo'lgan odamlar tomonidan amalga oshiriladigan baholash) odatda noto'g'ri. Ishonchli bahoni olishning yagona usuli bu vakolatli guruh - loyiha menejeri, etakchi me'morlar, ishlab chiquvchilar va sinov mutaxassislari bilan birgalikda modelning ko'p vaqt va sezgirligini tahlil qilishning bir necha takrorlanishidan o'tishi. Loyihani muvaffaqiyatli yakunlash uchun jamoa keyinchalik mehnat xarajatlari smetasida muallifligini tan olishi kerak.
Dasturiy ta'minotni ishlab chiqish murakkabligini yaxshi baholash:
· Loyiha menejeri va me'morlar, ishlab chiquvchilar va ishni bajarishga mas'ul bo'lgan sinovchilar guruhlari tomonidan yaratilgan va saqlangan;
Barcha ijrochilar shuhratparast, ammo bajarilishi mumkin deb qabul qilishadi;
· Batafsil va oqilona baholash modeliga asoslangan;
· O'xshash jarayonlar, texnologiyalar, atrof-muhit, sifat talablari va xodimlarning malakasini o'z ichiga olgan o'xshash loyihalar ma'lumotlariga asoslanadi;
· Barcha asosiy xavf zonalari aniq ko'rinadigan va muvaffaqiyat ehtimoli xolisona baholanadigan tarzda batafsil tavsiflanadi.
Ideal smetani yaxshi tasdiqlangan mehnat modelidan ekstrapolyatsiya qilish va bir xil etuk jarayonlar va vositalardan foydalangan holda bir xil jamoa tomonidan tayyorlangan ko'plab shunga o'xshash loyihalar tajribasidan foydalanish orqali olish mumkin. Jamoa yangi loyihaga kirganda, bu amalda kamdan-kam uchraydigan bo'lsa-da, keyinchalik loyihaning hayot tsiklida yaxshi natijalarga odatiy tarzda erishish mumkin.
Dasturiy ta'minotni ishlab chiqish murakkabligini algoritmik modellashtirishda asosan ikkita modellashtirish yondashuvi mavjud: nazariy modellar va statistik modellar, ular quyida muhokama qilinadi. Dasturiy ta'minotni ishlab chiqishning murakkabligini aniqlash uchun modellarning aksariyati beshta asosiy parametr funktsiyasiga tushirilishi mumkin:
· Dastlabki kod satrlari soni yoki ushbu funktsiyani amalga oshirish uchun zarur bo'lgan funktsiya punktlari soni bilan o'lchanadigan yakuniy mahsulotning o'lchami (qo'lda yozilgan komponentlar uchun);
· Yakuniy mahsulotni olish uchun foydalaniladigan jarayonning xususiyatlari, xususan, unumsiz faoliyatni oldini olish qobiliyati (qayta ishlash, byurokratik kechikishlar, o'zaro ta'sirlar xarajatlari);
· Dasturiy ta'minotni ishlab chiqishda ishtirok etadigan xodimlarning imkoniyatlari, xususan ularning kasbiy tajribasi va loyiha sohasini bilishi;
Dasturiy ta'minotni ishlab chiqish va jarayonlarni avtomatlashtirishni samarali amalga oshirish uchun ishlatiladigan vositalar va texnikalardan iborat muhit;
· Mahsulotning kerakli sifati, shu jumladan uning funktsionalligi, ishlashi, ishonchliligi va moslashuvchanligi.
Ushbu parametrlar orasidagi bog'liqlik, bir tomondan, hisoblangan mehnat zichligi, boshqa tomondan, quyidagicha yozilishi mumkin:

Mehnat zichligi = (Xodimlar) • (Atrof-muhit) • (Sifat) • (Hajmi).

Ushbu modellarda mehnat zichligini baholashda eng ta'sirchan omil bu dasturiy mahsulot hajmi. Dasturiy ta'minotni ishlab chiqishning murakkabligini baholash tartibi quyidagi bosqichlardan iborat:
1. Ishlab chiqarilayotgan mahsulot hajmini baholash;
2. Mehnat intensivligini odam-oy yoki odam-soat bo'yicha baholash;
3. kalendar oylarida loyihaning davomiyligini taxmin qilish;
4. loyiha xarajatlari smetasi.
Mahsulot o'lchamlari tizim talablarini bilishga asoslangan. Ushbu baholashning ikkita asosiy usuli mavjud.
· Xuddi shunday. Agar ilgari shunga o'xshash loyiha bilan shug'ullanishingizga to'g'ri kelgan bo'lsa va uning taxminlari ma'lum bo'lsa, unda siz ulardan boshlab taxminan loyihangizni taxmin qilishingiz mumkin.
Bo'yicha ma'lum algoritmlarga muvofiq hajmini hisoblash orqali

dastlabki ma'lumotlar asosida - tizim talablari.

· Dasturiy ta'minot hajmini baholash muammolari.
· Muammo ishlab chiquvchilar va / yoki buyurtmachilar tomonidan ba'zi faktlar o'tkazib yuborilganligi yoki buzilganligi sababli yaxshi tushunilmasligi mumkin.
· Tarixiy ma'lumotlarning etishmasligi yoki umuman yo'qligi kelajakdagi taxminlar uchun asos yaratishga imkon bermaydi.
· Loyihalash tashkilotida baholash jarayonini amalga oshiradigan standartlar mavjud emas (yoki standartlar mavjud bo'lsa, ularga hech kim amal qilmaydi); natijada, baholash jarayonini amalga oshirishda moslik etishmayapti.
· Loyiha menejerlari loyihaning boshida talablarni qo'lga kiritish yaxshi bo'lardi, deb o'ylashadi, mijozlar esa talablar spetsifikatsiyasini ishlab chiqish vaqtga loyiq emas deb hisoblashadi.
· Xatolar baholash va namoyish etish o'rniga yashirinishga moyil bo'lib, natijada haqiqiy ishlash to'g'risida noto'g'ri taassurot paydo bo'ladi.
· Baholash imkoniyatlari sezilarli darajada baholash jarayonida ishtirok etayotgan sub'ektlarga bog'liq.
· Menejerlar, tahlilchilar, ishlab chiquvchilar, sinovchilar va mahsulotni amalga oshiruvchilar baholash jarayoni va mahsulotni takomillashtirish imkoniyatlari to'g'risida turli xil fikrlarga ega bo'lishlari mumkin.
Loyiha bosqichiga qarab dasturiy ta'minotning narxini va hajmini baholashning to'g'riligi quyidagi jadval bilan belgilanadi (6.1-rasm). Dastur hajmi uchun asosiy o'lchov birliklari:
· Kod satrlari soni (LOC - Kod satrlari);
· Funktsional punktlar (FP - Funktsiya punktlari).
Kod satrlari soni tarixiy jihatdan eng taniqli va yaqin vaqtgacha eng keng tarqalgan o'lchov birligi hisoblanadi. Biroq, undan foydalanishda bir qator savollar tug'iladi:
· Haqiqatan ham yozilishidan yoki shunchaki ishlab chiqilishidan oldin kod satrlari sonini qanday aniqlash mumkin?
· Agar mahsulotning murakkabligi, dasturchining qobiliyati (uslubi) yoki ishlatilayotgan dasturlash tilining imkoniyatlari hisobga olinmasa, qanday qilib kod satrlari ko'rsatkichi mehnat miqdorini aks ettirishi mumkin?
· Kod satrlari sonidagi farqni qanday qilib teng ish hajmiga aylantirish mumkin?
Ushbu va boshqa savollar o'lchov birligi sifatida kod satrlarini "yomon obro'ga" olib keldi, garchi ular hali ham eng ko'p qo'llanilmoqda. LOC va harakat o'rtasidagi munosabatlar chiziqli emas. Dasturlashning yangi tillari paydo bo'lishiga qaramay, yigirma yil davomida dasturchilarning o'rtacha mahsuldorligi o'zgarishsiz qoldi va har bir dasturchiga yiliga 3000 satr kod satrini tashkil etdi. Bu shuni ko'rsatadiki, rivojlanish tsikliga sarflanadigan vaqtni dasturchilarning samaradorligini sezilarli darajada oshirish hisobiga erishish mumkin emas. Va bu dasturlash tili yaxshilanishi, menejerlik harakati yoki ortiqcha ish vaqtiga bog'liq emas. Aslida, dasturiy ta'minotning funktsional xususiyatlari va sifati to'plami kod satrlari soni emas, balki eng muhim ahamiyatga ega.
LOCni o'lchov birligi sifatida ishlatishning afzalliklari:
· Keng tarqalgan va oson moslashuvchanlik;
· Turli xil rivojlanish guruhlarida o'lcham va ko'rsatkichlarni o'lchash usullarini taqqoslash qobiliyati;
· Yakuniy mahsulot bilan to'g'ridan-to'g'ri bog'lanish;
· Loyiha tugashidan oldin oson baholash;
· Dasturiy ta'minot hajmini ishlab chiquvchi nuqtai nazariga qarab baholash - yaratilgan mahsulotni fizik baholash (yozilgan kod satrlari soni).
LOC-dan foydalanishning kamchiliklari:
· Dasturiy ta'minot hajmini rivojlanishning dastlabki bosqichida baholashda LOC-lardan foydalanish qiyin;
· Dasturlash kodlari satrlari dasturlash tillarining turlariga, dizayn uslublariga, dasturchining uslubiga va qobiliyatiga qarab farq qilishi mumkin;
· Kodlar bo'yicha skorlash usullarini qo'llash sanoat standartlari (masalan, ISO) bilan tartibga solinmagan;
· Dasturiy ta'minotni ishlab chiqish to'g'ridan-to'g'ri dastur kodining o'lchamiga bog'liq bo'lmagan yuqori xarajatlar bilan bog'liq bo'lishi mumkin - "doimiy xarajatlar", masalan, kodlashning to'g'ridan-to'g'ri xarajatlariga kiritilmagan talablar xususiyatlari va foydalanuvchi hujjatlari;
Dasturchilar LOC-ning yuqori ko'rsatkichlarini qo'lga kiritganligi uchun, agar rahbariyat uni yuqori mahsuldorlik belgisi deb xato deb hisoblasa, haqsiz ravishda mukofotlanishi mumkin. ammo batafsil ishlab chiqilgan loyiha bo'lmaydi; mahsulot yaratishda manba kodi maqsad emas - funktsional xususiyatlar va ishlash ko'rsatkichlari asosiy rol o'ynaydi;
LOC sonini hisoblashda avtomatik va qo'lda yaratilgan kodni ajratib ko'rsatish kerak - bu vazifa oddiy hisoblashdan ko'ra murakkabroq, bu kompilyator tomonidan tuzilgan listing asosida yoki kod satrlarini hisoblovchi yordamchi dastur yordamida amalga oshiriladi;
· Ishlatilgan platformalar yoki tillar boshqacha bo'lsa, normallashtirishni amalga oshirishda LOC ko'rsatkichlarini qo'llash mumkin emas;
· Ishlab chiqilgan dasturiy ta'minotga nisbatan LOC yordamida hisobga olishning yagona usuli bu o'xshash dasturiy mahsulotlarning funktsional xususiyatlarini taqqoslashga asoslangan analogiya usulidan foydalanish yoki mutaxassislarning fikrlaridan foydalanish (ammo bu usullar aniqlari qatoriga kirmaydi);
· Kod ishlab chiqaruvchilari ko'pincha haddan tashqari ko'p miqdordagi kod ishlab chiqaradilar, natijada LOC qiymatlari buziladi.
Ushbu mulohazalarning natijasi funktsional nuqtalar sifatida ishlay boshlagan boshqa o'lchov birligiga bo'lgan ehtiyojni anglash edi.

2.