|
-rasm. Bir vaqtning o'zida muhandislik muhitida ko'plab qurilish guruhlari
|
| bet | 2/4 | | Sana | 16.12.2023 | | Hajmi | 119,66 Kb. | | #120685 |
Bog'liq DT LOYIHA MUSTAQIL ISH9.6-rasm. Bir vaqtning o'zida muhandislik muhitida ko'plab qurilish guruhlari.
Talablar
9.7-rasm. Bir vaqtning o'zida muhandislik muhitida ko'plab sinov guruhlari.
parallel ravishda, dasturiy ta'minotni ishlab chiqishning hayot aylanishi sezilarli darajada qisqarishi mumkin. Mahsulotni ishlab chiqish vazifasi kichikroq vazifalarga bo'linadi, shunda bu vazifalarning har biri bir-biridan mustaqil ravishda bajarilishi mumkin. Shunday qilib, bir-biriga bog'liq bo'lmagan jamoalar mahsulotning har bir qismini boshqa jamoalar ishlab chiqayotganini bilmasdan turib ishlashlari mumkin. Ushbu mexanizm ko'plab jamoalarning doimiy ishlashini osonlashtiradi. Mahsulotning ushbu qismlari tugallangandan so'ng, ular to'liq mahsulotni tayyorlash uchun yig'iladi (9.6-rasm).
Dasturiy ta'minotni ishlab chiqishda dasturiy mahsulotni ajratish qiyin. Dasturiy ta'minotning ko'p qismlari parallel ravishda tuzilishi yoki sinovdan o'tkazilishi uchun ishlab chiqiladigan dasturiy mahsulotni taqsimlash to'g'risida qaror loyihalash bosqichida qabul qilinadi. Bir vaqtning o'zida ishlab chiqishni ta'minlash uchun dasturiy ta'minot mahsuloti qismlarning har biri boshqa qismlar bilan birlashtirilishi mumkin bo'lgan aniq interfeyslarga ega bo'lgan tarzda bo'linadi. Ushbu qismlarni sinab ko'rish uchun ushbu interfeyslar uchun qo'g'irchoq qismlardan foydalaniladi, shuning uchun qismni sinab ko'rish mumkin (shuningdek, test oracle deb ham ataladi). Ushbu qismlar har bir mustaqil jamoa tomonidan ishlab chiqilgandan so'ng, ular to'liq dasturiy mahsulotni yaratish uchun birlashtiriladi. Xuddi shunday, sinov uchun har bir sinov qismi boshqa jamoaga tayinlanadi, shunda ular o'z qismlarini parallel ravishda sinab ko'rishlari va shu bilan sinov tsiklining uzunligini qisqartirishlari mumkin (9.7-rasm).
Dasturiy ta'minotning hayot aylanish jarayonlari
Turli xil jarayon modellarida turli xil jarayon bosqichlari yoki bosqichlari aniqlangan bo'lsa ham, jarayon bosqichlari eng yaxshi sharshara modeli bilan ifodalanadi. Ratsional birlashtirilgan jarayonda fazalar ish oqimlari bilan matritsada ifodalanadi. Ushbu ish oqimlari bir bosqichda tugamaydi, aksincha ular bir nechta bosqichlarni kesib o'tadi. Bu hayot siklining aksariyat holatlarida to'g'ri keladi, chunki ko'plab jarayonlar tsikllarda tugaydi va shuning uchun ular tabiatan chiziqli emas. Bu yerda biz hayot aylanish jarayonlarini batafsil muhokama qilamiz.
Dasturiy ta'minotga qo'yiladigan talablar
Loyihani boshlash tugallangandan va ish bayonnomasi (SOW) imzolangandan so'ng, loyiha jamoasi mijozdan dasturiy ta'minot talablarini yig'ishni boshlaydi. Talablar to'plangandan so'ng, ularni tizimni modellashtirish uchun mos qilish uchun ishlab chiqish kerak. Dasturiy ta'minotga bo'lgan talablar uchun qo'llaniladigan ba'zi usullar orasida aniqlash usullari va tahlil usullari mavjud.
Dasturiy mahsulot ishlab chiqarish uchun siz yaxshi talablarni olishingiz kerak. Bu erda muammo boshlanadi. Dasturiy ta'minot mahsulotlariga qo'yiladigan talablar hech qachon aniq bo'lmaydi. Ko'pincha talablar hozirda qo'lda bajariladigan jarayonlarni dasturiy ta'minotdan foydalanadiganlar bilan almashtirishdir. Lekin bu hammasi emas. Rahbariyat strategik ustunlikka erishish uchun dasturiy ta'minotdan foydalanishni xohlaydi. Masalan, menejment dasturiy ta'minotni qo'llash orqali inventarizatsiyani joriy darajadan sezilarli darajada kamaytirishi mumkinligiga ishonadi. Endi bunday kutishni aniq belgilash mumkin emas. Dasturiy ta'minot inventarizatsiyani yaxshiroq boshqarish uchun ko'rinish va vositalarni taqdim etishi mumkinligi haqiqat bo'lishi mumkin, ammo dasturiy ta'minotdan foydalanish inventarni ma'lum foizga kamaytirishga yordam beradi, deb aytish mumkin emas. Xuddi shunday, odamlar dasturiy mahsulot amalga oshirilgandan so'ng ularning ish yuki kamayishini kutishadi. Ko'pgina hollarda bu to'g'ri, lekin dastlab dasturiy ta'minot tizimiga juda ko'p asosiy ma'lumotlar kiritilishi kerak va bu dasturiy mahsulotni joriy qilishning dastlabki bosqichida juda ko'p mehnat talab qiladi. Bunday hollarda noto'g'ri taxminlar bajarilmaydi va foydalanuvchilar o'z kutganlarini qondira olmagani uchun loyiha jamoasini ayblay boshlaydilar.
Talablarni yig'ish va undan keyingi talablarni boshqarish qiyin vazifadir. Bu ikkala vazifa ham yaxshi va izchil bajarilishi uchun yaxshi jarayon belgilanishi kerak. Talablarni yig'ish bir joydan boshqasiga farq qiladi. Ba'zi joylarda talablarni olish uchun foydalanuvchi intervyulari va ko'plab rasmiy usullar qo'llaniladi. Boshqa joylarda norasmiy usullar qo'llaniladi. Bundan tashqari, dasturiy mahsulot hajmi talablarni to'plash uchun qanday usullarni qo'llashga ham ta'sir qiladi. Talablarni boshqarish bilan bog'liq jarayonlarning o'zgaruvchanligini kamaytirish uchun yaxshi talablarni yig'ish shablonlari yordam berishi mumkin.
Talablarni yig'ishdagi ba'zi qiyinchiliklarga noaniq talablar, talablarni olishda qiyinchilik, talablarni tushunishda qiyinchilik va bu talablarni mos dasturiy ta'minot dizayniga tarjima qilish kiradi. Loyiha davomida talablarga o'zgartirishlar kiritiladi. Bu dasturiy ta'minotni ishlab chiqishni qiyinlashtiradi. O'zgartirilgan talablarni kiritish qiyin taklifdir. Faraz qilaylik, dizayn qilingan va loyiha qurilish bosqichida va keyin o'zgartirish so'rovi kelganini tasavvur qiling. Dasturiy ta'minot me'mori dizaynda katta o'zgarishlar talab qilinishini his qiladi. Uning buni qilishdan boshqa iloji yo'q, chunki o'zgartirish so'rovi qabul qilingan. U dizayndagi o'zgarishlarni amalga oshirish uchun vaqt talab etadi. Qurilish guruhi o'z ishini to'xtatishi kerak, chunki dizayndagi bu o'zgarish koddagi ko'plab o'zgarishlarga olib keladi. Aslida, loyiha jamoasi tomonidan ko'p qayta ishlash kerak. Loyiha davomida bunday qayta ishlash ko'p marta amalga oshirilishi mumkin. Bu dizayn va kod o'zgarishlarini nosozliklar uchun himoyasiz qiladi. Shunday qilib, ko'plab qayta ishlash talablarini boshdan kechirgan bunday dasturiy mahsulotda ko'proq nuqsonlarni kutish mumkin.
Bu stsenariy alohida holat emas. Ammo, aslida, bu ko'pgina dasturiy ta'minot loyihalarida keng tarqalgan kasallikdir.
An'anaga ko'ra, dasturiy ta'minotni ishlab chiqish loyihalari uchun palapartishlik modeli qabul qilingan. Loyihada bosqichlarni qat'iy taqsimlash mavjud. Talablar bosqichi birinchi va qachon keladi
tugallangandan so'ng, talablar bosqichi tugashini belgilash uchun imzo qo'yiladi (garchi haqiqatda talabni o'zgartirish so'rovlari doimiy ravishda keladi). Keyinchalik dasturiy ta'minotni loyihalash bosqichi keladi. U tugallangandan so'ng, imzo qo'yiladi. Keyin qurilish bosqichi keladi. Bu erda kodlash amalga oshiriladi. Keyin, sinov bosqichida qurilgan dasturiy ta'minot sinovdan o'tkaziladi. Sinov tugallangandan so'ng, o'tish bosqichi (shuningdek, joylashtirish yoki chiqarish bosqichi sifatida ham tanilgan) keladi va bu bosqich tugagandan so'ng, dasturiy ta'minot mijoz saytida amalga oshiriladi. Jonli efir bosqichi tugagach, dasturiy ta'minot ishlab chiqarish bosqichiga o'tadi.
Ushbu yondashuv ko'p jihatdan yaxshi. Bu ishlab chiqarilayotgan dasturiy ta'minotning yaxshi sifatini ta'minlaydi. Bu yaxshi tashkil etilgan. Ammo bu yondashuvning bitta katta kamchiligi bor. Ushbu yondashuv o'zgaruvchan biznes talablarini o'z ichiga olmaydi. Bugungi notinch ishbilarmonlik muhitida narsalar tez o'zgaradi. Shunday qilib, dasturiy ta'minotga bo'lgan talab bugun juda yaxshi ko'rinsa ham, ertaga u unchalik yaxshi ko'rinmasligi mumkin. Ertaga talab qilinadigan o'zgarishlarni kiritmasdan, ishlab chiqilayotgan dasturiy ta'minot o'tirgan o'rdak bo'lishi mumkin.
Xo'sh, talab o'zgarishlari kasalligiga qarshi kurashish uchun qanday yaxshi yondashuv bo'lishi mumkin? Yillar davomida ko'plab tashkilotlar ushbu ko'p yillik muammoni hal qilish uchun dasturiy ta'minot loyihalarini boshqarish bo'yicha ba'zi yangi yondashuvlarni taklif qilishdi va amaliyotda qo'llashdi. Ulardan ba'zilari iterativ model, agile usullar, spiral usul va ekstremal dasturlashni o'z ichiga oladi. Ushbu yondashuvlarning barchasida talablarni boshqarishga asosiy o'tish shundan iboratki, talablar aniq bo'lgandan keyin noaniq yoki noma'lum talablar kiritilishi uchun iterativ tarzda to'planishi va ishlab chiqilishi kerak. Birgalikda biz ularni iterativ rivojlanish modellari deb atashimiz mumkin.
Iterativ model dasturiy ta'minot loyihalariga mos keladi, chunki dasturiy ta'minot loyihasini boshlash uchun mijozning barcha talablarini to'plash o'rniga faqat kichik talablar to'plami olinadi. Shunday qilib, agar oxirgi foydalanuvchilar o'zlarining aniq talablari haqida aniq bilmasalar ham, loyihani bir nechta ma'lum talablar bilan boshlash mumkin. Dasturiy ta'minot ushbu talablar to'plami uchun ishlab chiqilishi va yaratilishi va oxirgi foydalanuvchilarga etkazib berilishi mumkin. Bu tadbirlarning barchasi bir necha hafta yoki bir necha oylik qisqa tsiklda amalga oshiriladi. Keyin, keyingi talablar to'plamini olish mumkin va keyingi iteratsiya ushbu talablar to'plamidan kelib chiqqan holda amalga oshirilishi mumkin. Foydalanuvchilar natijalarni juda erta ko'rishdan xursand bo'lib, loyiha jamoasiga ko'proq ishonch hosil qilishadi. Bu, albatta, yaxshi biznes ma'nosini beradi.
Talablarni boshqarish haqida biz 10-bobda batafsil bilib olamiz.
|
| |
